[RFC] qgit with tabs

[RFC] qgit with tabs

[Marco Costalba]

Hi all,

   I have pushed some patches that add tabs to qgit UI.

I don't expect a new release any time soon, but I am interested to
hear comments, especially on the usability front, so to be able to
steer new development in advance.

With new UI I found myself more and more using keyboard bindings
instead of mouse:

- r, p, f to switch to revisions list, patch and file views respectively

- t to toggle tree view

- s to toggle split view (very useful IMHO)


NOTE:
Due to some repacking on a dumb host probably you need to re-clone:

git clone http://digilander.libero.it/mcostalba/scm/qgit.git
cd qgit
autoreconf -i
./configure
make
make install-strip


          Marco

Re: [RFC] qgit with tabs

[Pavel Roskin]

Hello, Marco!

Quoting Marco Costalba <mcostalba@gmail.com>:

>    I have pushed some patches that add tabs to qgit UI.

That's _really_ appreciated.

> I don't expect a new release any time soon, but I am interested to
> hear comments, especially on the usability front, so to be able to
> steer new development in advance.

Just one thing for now.  Double click on a file on the "rev list" tab should
show the patch (what Ctrl-P would do), not the whole file.  That would be more
compatible with gitk, and it's what I normally need if I just browse the latest
changes in the rev list.

> With new UI I found myself more and more using keyboard bindings
> instead of mouse:
>
> - r, p, f to switch to revisions list, patch and file views respectively
>
> - t to toggle tree view
>
> - s to toggle split view (very useful IMHO)

The later is very useful, but a bit hard to discover without checking the menu. 
Maybe it should be a button in the toolbar.

> NOTE:
> Due to some repacking on a dumb host probably you need to re-clone:

I don't think re-clone should be needed.  I didn't re-clone, yet I could update.

On the other hand, that host sometimes returns something that crashes
git-http-fetch.  Sorry, no time to debug it right now.  I guess it returns
error messages in HTML without reporting error 404, but git-http-fetch should
be more robust anyway.

--
Regards,
Pavel Roskin

Re: [RFC] qgit with tabs

[Marco Costalba]

Hi Pavel,

>
> Just one thing for now.  Double click on a file on the "rev list" tab should
> show the patch (what Ctrl-P would do), not the whole file.  That would be more
> compatible with gitk, and it's what I normally need if I just browse the latest
> changes in the rev list.
>

Well, double click activates the current top entry in context menu.

This behaviour has not changed from past releases. To show the patch
perhaps you may, as always, double click on the selected revision, in
revisions list.

FWIK gitk does not have a file content viewer.

Thanks
Marco

Re: [RFC] qgit with tabs

[Pavel Roskin]

Quoting Marco Costalba <mcostalba@gmail.com>:

> > Just one thing for now.  Double click on a file on the "rev list" tab
> should
> > show the patch (what Ctrl-P would do), not the whole file.  That would be
> more
> > compatible with gitk, and it's what I normally need if I just browse the
> latest
> > changes in the rev list.
> >
>
> Well, double click activates the current top entry in context menu.

That's a good thing.  But I think that the top entry should be different.

> This behaviour has not changed from past releases.

I know.  But as the more prominent issues are sorted out, minor things become
more visible.

> To show the patch
> perhaps you may, as always, double click on the selected revision, in
> revisions list.

Sure, but I often want to see what changed in a particular file.

And of course I only mean the subwindow dislaying the files affected by the
patch.  The file tree should still have file annotation bound to the double
click.

> FWIK gitk does not have a file content viewer.

That's true.  The reason may be because changes are more interesing than the
whole file in the context of git (as opposed to the context of an editor or a
compiler).

--
Regards,
Pavel Roskin

Re: [RFC] qgit with tabs

[Marco Costalba]

Hi Pavel,

>
> Sure, but I often want to see what changed in a particular file.
>
> And of course I only mean the subwindow dislaying the files affected by the
> patch.  The file tree should still have file annotation bound to the double
> click.
>

I understand your reasons, but I have some doubts about this change:

1) The context menu is currently shared between the tree and the file
list, splitting in two subcases adds some crap to the code (ok, this
is not the real doubt ;-)  )

2) The context menu is currently shared between the file list in main
view and the file list in patch view. The file list in patch view, of
course, does not need a double click, a single click is enough to
select corresponding file's diff. In main view you currently need a
single click _plus_  a 'p' key press to change the view. So we should
add another subcase here.

3) It is true that double clicking on a revision switch to the patch
view at top position (if no file is selected), but it's also true that
you can select the file's related diff directly in patch view with a
single click on the right column file list.

4) Once a file is selected, as example with a single click, you can
browse through rev list and the selection is preserved, it means that
anytime you switch to patch view page the content will be _already_
centered on the correct diff.

5) Double clicking on a file name is currently the only way (without
opening the menu) to show the file content tab, with your suggested
change we will have two ways to switch to patch view and no one to
switch to file view.

6) Selecting from the tree view is very slow if you have to search for
the correct file, it is fast only if the file is already selected, but
in this case is faster to press 'p' key ;-)


       Marco

Re: [RFC] qgit with tabs

[Pavel Roskin]

Hi, Marco!

On Sun, 2006-05-14 at 00:38 +0200, Marco Costalba wrote:
> Hi Pavel,
> 
> >
> > Sure, but I often want to see what changed in a particular file.
> >
> > And of course I only mean the subwindow dislaying the files affected by the
> > patch.  The file tree should still have file annotation bound to the double
> > click.
> >
> 
> I understand your reasons, but I have some doubts about this change:
> 
> 1) The context menu is currently shared between the tree and the file
> list, splitting in two subcases adds some crap to the code (ok, this
> is not the real doubt ;-)  )

Actually, "Get revision/patch" and "External diff" shouldn't be in the
popup used in the tree, or at least they should only appear for the
files affected by the currently selected patch.

"External diff" may be a good candidate for the toolbar if you find out
how to feed a multi-file patch to kompare (I guess you'll need two
temporary directories populated with differing files).

> 2) The context menu is currently shared between the file list in main
> view and the file list in patch view. The file list in patch view, of
> course, does not need a double click, a single click is enough to
> select corresponding file's diff. In main view you currently need a
> single click _plus_  a 'p' key press to change the view. So we should
> add another subcase here.

Yes.  It should be perfectly OK to have different menus for different
contexts.

> 3) It is true that double clicking on a revision switch to the patch
> view at top position (if no file is selected), but it's also true that
> you can select the file's related diff directly in patch view with a
> single click on the right column file list.

That's true.  But I still find myself double clicking on the file in the
file list and expecting to see the patch for the file.  It's very
natural.  

If I see the list of the recent patches, I see the descriptions and the
affected files.  If I'm interested to see what changed in the file, it's
only natural for me to double-click the corresponding entry in the list.

Full history of a file is a much more advanced operation, and it's not
something I need to do often while browsing recently merged changes.

> 4) Once a file is selected, as example with a single click, you can
> browse through rev list and the selection is preserved, it means that
> anytime you switch to patch view page the content will be _already_
> centered on the correct diff.

That's useful, but irrelevant.

> 5) Double clicking on a file name is currently the only way (without
> opening the menu) to show the file content tab, with your suggested
> change we will have two ways to switch to patch view and no one to
> switch to file view.

That's a good thing.  That's called consistency.  git is about patches,
so showing the patches should be the default whenever practical.

The file viewer is a great feature, and it should be discoverable, but
it doesn't mean it should pop up when users expect something else.

> 
> 6) Selecting from the tree view is very slow if you have to search for
> the correct file, it is fast only if the file is already selected, but
> in this case is faster to press 'p' key ;-)

That's true, but we are talking about double click behavior.  Every
reasonable person can learn shortcuts, but the software should work
predictably even if operated by the mouse.

-- 
Regards,
Pavel Roskin

Re: [RFC] qgit with tabs

[Marco Costalba]

On 5/18/06, Pavel Roskin <proski@gnu.org> wrote:
>
> > 3) It is true that double clicking on a revision switch to the patch
> > view at top position (if no file is selected), but it's also true that
> > you can select the file's related diff directly in patch view with a
> > single click on the right column file list.
>
> That's true.  But I still find myself double clicking on the file in the
> file list and expecting to see the patch for the file.  It's very
> natural.
>
> If I see the list of the recent patches, I see the descriptions and the
> affected files.  If I'm interested to see what changed in the file, it's
> only natural for me to double-click the corresponding entry in the list.
>

Ok. patch pushed.

Perhaps I'm not using gitk a lot so I still have to get used to this
new file double clicking behaviour.

  Marco

Re: [RFC] qgit with tabs

[Pavel Roskin]

Quoting Marco Costalba <mcostalba@gmail.com>:

> > If I see the list of the recent patches, I see the descriptions and the
> > affected files.  If I'm interested to see what changed in the file, it's
> > only natural for me to double-click the corresponding entry in the list.
> >
>
> Ok. patch pushed.

Working fine here.  Thank you!

--
Regards,
Pavel Roskin

Re: [RFC] qgit with tabs

[Paul Mackerras]

Marco Costalba writes:

> FWIK gitk does not have a file content viewer.

It does now, actually.

Paul.

Re: [RFC] qgit with tabs

[Marco Costalba]

On 5/20/06, Paul Mackerras <paulus@samba.org> wrote:
> Marco Costalba writes:
>
> > FWIK gitk does not have a file content viewer.
>
> It does now, actually.
>
> Paul.
>

Yes, I've checked the current gitk version only _after_ email was sent.

Sorry for this.

   Marco