Re: More qgit defects

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: More qgit defects

From: Marco Costalba <hidden>
Date: 2016-06-15 22:42:24

On 4/30/06, Pavel Roskin [off-list ref] wrote:
On Sun, 2006-04-30 at 05:26 -0400, Pavel Roskin wrote:
quoted
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

Re: More qgit defects

From: Pavel Roskin <hidden>
Date: 2016-06-15 22:42:25

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help