Re: More qgit defects

Marco Costalba· Apr 30, 2006, 10:13 UTC · lore

On 4/30/06, Pavel Roskin <proski@gnu.org> wrote:

Show 26 quoted lines

> 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

Pavel Roskin· May 1, 2006, 02:20 UTC · re: Marco Costalba · lore

Hello, Marco!

On Sun, 2006-04-30 at 12:13 +0200, Marco Costalba wrote:

Show 6 quoted lines

> 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.

Show 6 quoted lines

> 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