git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: More qgit defects
       [not found]                 ` <1146390144.13634.9.camel@dv>
@ 2006-04-30 10:13                   ` Marco Costalba
  2006-05-01  2:20                     ` Pavel Roskin
  0 siblings, 1 reply; 2+ messages in thread
From: Marco Costalba @ 2006-04-30 10:13 UTC (permalink / raw)
  To: Pavel Roskin; +Cc: ydirson, git

On 4/30/06, Pavel Roskin <proski@gnu.org> wrote:
> On Sun, 2006-04-30 at 05:26 -0400, Pavel Roskin wrote:
> > No, something still feels wrong.  I think even the gurus of GUI cannot
> > decide what to do if many frames need to be on screen.  Do you know that
> > many graphic designers hate GIMP for the overuse of dockable toplevel
> > windows?  Krita prefers dockable frames.  Photoshop uses non-dockable
> > child windows, I believe.
> >
> > The difference for qgit is that is generally wants bigger windows.
> > Whether the revision tree or the patch, having more space allows the
> > frame to present a better picture to the users.
>
> Replying to myself, sorry.  How about tabs?
>
> One tab for the main view.  Basically what we have now.
>
> Then tabs for revisions.  We can have more than one revision open, with
> the comment and with the patch, and and with affected files.  They will
> have the GUI centered on the change made by the revision.  StGIT commits
> would have an editable comment.
>
> Then tabs for files.  Again, possibly more than one.  Each tab about a
> specific file.  The file history, annotations, maybe even an editor for
> the file.
>
> The idea was inspired by Azureus.
>

Throwing in the tabs is a *very* big change, but, just to discuss....I
agree on the note that in qgit we have three different approaches:
fixed frames (revisions, file tree, affected files), detachable frames
(patch) and separate windows (annotations).

This is a bit strange and could give an odd GUI feeling.

I like the tab idea because it's clear and simple and fixes the 'many
approaches' problem. What I would suggest is, at least at first step,
do not change the main view and have only three tabs:

Tab1: Main view with revisions, file tree (hide able), affected files.
Tab2: Patch view with patch stat and diffs
Tab3: File history + file content/annotation view

In other words just put the frames/windows as are now in browse able
tabs. In this way main view still gives a good amount of information
without requiring changing the tab and the tabs are reserved for 'big
space' needed infos only.


   Marco

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: More qgit defects
  2006-04-30 10:13                   ` More qgit defects Marco Costalba
@ 2006-05-01  2:20                     ` Pavel Roskin
  0 siblings, 0 replies; 2+ messages in thread
From: Pavel Roskin @ 2006-05-01  2:20 UTC (permalink / raw)
  To: Marco Costalba; +Cc: ydirson, git

Hello, Marco!

On Sun, 2006-04-30 at 12:13 +0200, Marco Costalba wrote:
> Throwing in the tabs is a *very* big change, but, just to discuss....I
> agree on the note that in qgit we have three different approaches:
> fixed frames (revisions, file tree, affected files), detachable frames
> (patch) and separate windows (annotations).
> 
> This is a bit strange and could give an odd GUI feeling.

Agreed.

> I like the tab idea because it's clear and simple and fixes the 'many
> approaches' problem.

I'm glad you liked my idea!  And thank you for copying to the list.
qgit is meant for most git users, and they should have their voices
heard.

> What I would suggest is, at least at first step,
> do not change the main view and have only three tabs:
> 
> Tab1: Main view with revisions, file tree (hide able), affected files.
> Tab2: Patch view with patch stat and diffs
> Tab3: File history + file content/annotation view

Absolutely.  It's easier to make changes incrementally than to rewrite
everything and hunt bugs for months.  This change alone would make it
easier to work with qgit.

Once qgit can deal with more than one patch view and more than one file
view, this would provide the fix for qgit's "jumpiness".  Mere selection
of objects in listboxes shouldn't affect other tabs.

> In other words just put the frames/windows as are now in browse able
> tabs. In this way main view still gives a good amount of information
> without requiring changing the tab and the tabs are reserved for 'big
> space' needed infos only.

That would be great.  I'm eagerly waiting for new commits to test :-)

-- 
Regards,
Pavel Roskin

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2006-05-01  2:20 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <1145484284.22097.10.camel@dv>
     [not found] ` <e5bfff550604220416v592128fcj25185bbda3b4e493@mail.gmail.com>
     [not found]   ` <1146115210.30763.40.camel@dv>
     [not found]     ` <e5bfff550604270026q68ba8a4clfaf1b274a5b312cf@mail.gmail.com>
     [not found]       ` <1146163863.5133.37.camel@dv>
     [not found]         ` <e5bfff550604281021k60e0c0ebk7a89eb0c9c569c2a@mail.gmail.com>
     [not found]           ` <1146383451.12323.41.camel@dv>
     [not found]             ` <e5bfff550604300111n6db883d5w98c863efaab15b00@mail.gmail.com>
     [not found]               ` <1146389204.12323.90.camel@dv>
     [not found]                 ` <1146390144.13634.9.camel@dv>
2006-04-30 10:13                   ` More qgit defects Marco Costalba
2006-05-01  2:20                     ` Pavel Roskin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).