[ANNOUNCE] qgit new "smart browsing" feature

[ANNOUNCE] qgit new "smart browsing" feature

[Marco Costalba]

I've pushed a patch series to
git://git.kernel.org/pub/scm/qgit/qgit4.git that implement a new and
much improved way to browse a repo.

What
-------

- Possibility to switch from revision message to diff content in
bottom left pane of main view

- Possibility to jump to next/previous revision with link labels at
the pane corners

- Optional use of mouse wheel to perform all of the above actions


How
------

In the bottom left pane two labels have been added. Both contain some
links, a default one (big) and a secondary one (small), mouse wheel
action performs the default link action when scrolled out, above or
below the content view.

Links could be switched right clicking on them by the means of a popup
context menu.

Finally in Edit->settings menu a check box called 'Show always
revision message as first' has been added. When checked (suggested),
on jumping to a new revision the log message is shown first,
regardless of the previous pane content.


Notes
--------

Care has been taken to allow the wheel browsing experience to be as
natural as possible, in particular a way to avoid to switch when user
just wants to scroll has been implemented. Also, getting a responsive
scroll and switch command avoiding false positives was not immediate.

I have found, to my surprise, that more the natural behaviour was
obtained more the code amount was big. At the end a quite not trivial
class has been added just to let the user browsing without thinking on
how to do it.

Hope you enjoy it. Of course feedback is, a always, welcomed.


Marco

Re: [ANNOUNCE] qgit new "smart browsing" feature

[Andy Parkins]

On Sunday 2007 June 03, Marco Costalba wrote:

> Care has been taken to allow the wheel browsing experience to be as
> natural as possible, in particular a way to avoid to switch when user
> just wants to scroll has been implemented. Also, getting a responsive
> scroll and switch command avoiding false positives was not immediate.

I'm really sorry to say it Marco, but it's really disturbing.  You've 
obviously made great efforts to make it useable, but it just isn't.  The 
scroll wheel behaviour being inconsistent is just annoying.  Sometimes 
scrolling works, sometimes it doesn't, sometimes it switches content, 
sometimes it doesn't.  It's obviously based on timeouts for the different 
functions, but that just means that I have no idea what a particular 
operation will do at any given time.

I'm not sure I like the labels with arrows either; and the fonts changing size 
and visibility is inconsistent and discomfiting.

On the plus side - I do like the idea of being able to perform these 
operations; jumping from revision to revision, or from log to patch is nice.  
However, I think it is unwise to invent a new graphical metaphor for an 
operation that already exists - the tabbed widget.  Similarly, the up and 
down are obvious candidates for toolbar buttons - an already established 
visual.

So - I think that the non-standard methods should be dropped (sorry); and be 
replaced with tabs for the patch/log switch and toolbar buttons for the 
up/down.  Also, the scroll-to-switch, while an interesting idea, gives 
unpredictable behaviour and so is uncomfortable to use.

Sorry for being so negative; it's a shame after your obvious hard work.



Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: [ANNOUNCE] qgit new "smart browsing" feature

[Marco Costalba]

On 6/4/07, Andy Parkins <andyparkins@gmail.com> wrote:
> On Sunday 2007 June 03, Marco Costalba wrote:
>
> > Care has been taken to allow the wheel browsing experience to be as
> > natural as possible, in particular a way to avoid to switch when user
> > just wants to scroll has been implemented. Also, getting a responsive
> > scroll and switch command avoiding false positives was not immediate.
>
> I'm really sorry to say it Marco, but it's really disturbing.  You've
> obviously made great efforts to make it useable, but it just isn't.  The
> scroll wheel behaviour being inconsistent is just annoying.  Sometimes
> scrolling works, sometimes it doesn't, sometimes it switches content,
> sometimes it doesn't.  It's obviously based on timeouts for the different
> functions, but that just means that I have no idea what a particular
> operation will do at any given time.
>

Thanks for your comment. I will try to do the following:

- Allow to remove this possibility by unchecking a proper flag in
settings dialog.

- Change the color of the arrows, as example highlighting, when the
switch behavior became active, i.e. at the top and bottom of scroll
bar. So the user will know what a scroll action will do.

> I'm not sure I like the labels with arrows either; and the fonts changing size
> and visibility is inconsistent and discomfiting.
>

Ok I can use same font for both labels, not a biggie. Regarding the
arrows, any other idea to tell to the user something will happen when
scrolling is welcomed.

> On the plus side - I do like the idea of being able to perform these
> operations; jumping from revision to revision, or from log to patch is nice.
> However, I think it is unwise to invent a new graphical metaphor for an
> operation that already exists - the tabbed widget.

The tabbed widget is here to stay. I do not plan to remove it. But the
tabbed widget is also slower then a well behaved scroll swicth or link
clicking.

>  Similarly, the up and
> down are obvious candidates for toolbar buttons - an already established
> visual.
>

This could be added, but it seems not needed to me given that for the
suer is faster to click on the previous/next revision in the revision
list then reaching the toolbar.

> So - I think that the non-standard methods should be dropped (sorry); and be
> replaced with tabs for the patch/log switch and toolbar buttons for the
> up/down.  Also, the scroll-to-switch, while an interesting idea, gives
> unpredictable behaviour and so is uncomfortable to use.
>
> Sorry for being so negative; it's a shame after your obvious hard work.
>

Thanks for your comments. They are much more valuable and useful then
a 'yes...it seems more or less nice'.

Thanks
Marco


P.S: Scrolling is not based on timeouts. The rule is: if user starts a
scroll action while not at the extremes of the content then only a
scroll will occur. If the user starts a scroll action from one extreme
of the view (top or bottom) and the scroll direction goes toward out
of the screen then a switch will occur.

Re: [ANNOUNCE] qgit new "smart browsing" feature

[Andy Parkins]

On Monday 2007 June 04, Marco Costalba wrote:

> The tabbed widget is here to stay. I do not plan to remove it. But the
> tabbed widget is also slower then a well behaved scroll swicth or link
> clicking.

Ah - I've not explained myself clearly.  What I mean is _another_ tab widget, 
instead of the scroll-to-switch.  It can't possibly be slower, as it's the 
same amount of work for Qt...  So it would look like this (excuse rubbish 
ASCII art):

 +-----------------------------+
 |                             |
 | <rev list here>             |
 |                             |
 |                             |
 +-----------------------------+
 | Log | Patch |               |
 +-----|       |---------------+
 | <diff goes here>            |
 |                             |
 +-----------------------------| 

At the moment, you have a label in the top left of the text window that is 
mouse-clicked to change mode; I'm suggesting replacing that with a tab widget 
as above where you mouse click to change mode.  It's no more operations, 
doesn't include a strange floating label and is a more standard and 
recognisable user interface.

If you still wanted up and down buttons, they could very easily go to the far 
right of the log|patch tabs, similar to the "close" button on the top tabs.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: [ANNOUNCE] qgit new "smart browsing" feature

[Marco Costalba]

On 6/4/07, Andy Parkins <andyparkins@gmail.com> wrote:
> On Monday 2007 June 04, Marco Costalba wrote:
>
> > The tabbed widget is here to stay. I do not plan to remove it. But the
> > tabbed widget is also slower then a well behaved scroll swicth or link
> > clicking.
>
> Ah - I've not explained myself clearly.  What I mean is _another_ tab widget,
> instead of the scroll-to-switch.  It can't possibly be slower, as it's the
> same amount of work for Qt...  So it would look like this (excuse rubbish
> ASCII art):
>
>  +-----------------------------+
>  |                             |
>  | <rev list here>             |
>  |                             |
>  |                             |
>  +-----------------------------+
>  | Log | Patch |               |
>  +-----|       |---------------+
>  | <diff goes here>            |
>  |                             |
>  +-----------------------------|
>
> At the moment, you have a label in the top left of the text window that is
> mouse-clicked to change mode; I'm suggesting replacing that with a tab widget
> as above where you mouse click to change mode.  It's no more operations,
> doesn't include a strange floating label and is a more standard and
> recognisable user interface.
>
> If you still wanted up and down buttons, they could very easily go to the far
> right of the log|patch tabs, similar to the "close" button on the top tabs.
>
>
Andy,

  I have to say that I really like your idea!

Now I really don't know what to do!  :-)

Probably I will create a new branch called andy_gui where I'll
implement your idea, while continue to refine the current approach. As
example one enanchment I would like to implement is to keep the labels
normally hidden and show the top (bottom) one only when user scrolls
to the top (bottom) boundary of the view so that we could resolve two
issues: knowing when a scrolling action will cause a switch (i.e. only
when the corresponding label is visible) and do not have the arrows
when not needed.

Another enanchment could be to have only one link per label instead of
two and right clicking on it to show a popup menu with available
alternatives.

Of course at the end there will remain only one! The winner will be,
of course, chosen by a democratic polling among us.


Comments?


Thanks
Marco

P.S: Your approach is simple and good, the only downside is the screen
estate taken by the tab bar. But I agree it's absolutly not a biggie.

Re: [ANNOUNCE] qgit new "smart browsing" feature

[Andy Parkins]

On Monday 2007, June 04, Marco Costalba wrote:

>   I have to say that I really like your idea!

Hurrah!  See - even a blind golfer knocks one in eventually :-)

> Probably I will create a new branch called andy_gui where I'll
> implement your idea, while continue to refine the current approach.

Great stuff.  If I get a moment, I'll try and chip in with some patches.

> As example one enanchment I would like to implement is to keep the
> labels normally hidden and show the top (bottom) one only when user
> scrolls to the top (bottom) boundary of the view so that we could
> resolve two issues: knowing when a scrolling action will cause a
> switch (i.e. only when the corresponding label is visible) and do not
> have the arrows when not needed.

That's certainly an improvement.  I think in many cases both labels will 
be visible - especially in log mode - because most log messages fit 
completely inside one window.

> P.S: Your approach is simple and good, the only downside is the
> screen estate taken by the tab bar. But I agree it's absolutly not a
> biggie.

Yeah, that is a bit of a drawback.  How about not putting the tabs on 
the top or bottom, but on the left or right?  In fact if you put them 
on the right, they'd be almost exactly where your jump labels would be.

Maybe this is only better for me, but I tend to have more left-to-right 
real estate available in the lower half of the screen, primarily 
because the log messages tend to be limited to 80 columns, but the 
revision list contains the ever-widening graph.


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: [ANNOUNCE] qgit new "smart browsing" feature

[Marco Costalba]

On 6/4/07, Andy Parkins <andyparkins@gmail.com> wrote:
> On Monday 2007, June 04, Marco Costalba wrote:
>
> > P.S: Your approach is simple and good, the only downside is the
> > screen estate taken by the tab bar. But I agree it's absolutly not a
> > biggie.
>
> Yeah, that is a bit of a drawback.  How about not putting the tabs on
> the top or bottom, but on the left or right?  In fact if you put them
> on the right, they'd be almost exactly where your jump labels would be.
>

Andy, another point scored for you!

I will do exactly that!


Now the only drawback it remains (more "mental" then real) is that the
user already scrolls down to read the message / patch and, at the end,
it's easier to just continue scrolling to jump to next/previous
revision then move the mouse to point the tab, click, and go back to
start scrolling again: a finger against a double hand movment + click.

Yes, I know, I'm veeery lazy ;-)


Marco

Re: [ANNOUNCE] qgit new "smart browsing" feature

[Marco Costalba]

On 6/4/07, Andy Parkins <andyparkins@gmail.com> wrote:
> On Monday 2007, June 04, Marco Costalba wrote:
>
> >   I have to say that I really like your idea!
>
> Hurrah!  See - even a blind golfer knocks one in eventually :-)
>
> > Probably I will create a new branch called andy_gui where I'll
> > implement your idea, while continue to refine the current approach.
>
> Great stuff.  If I get a moment, I'll try and chip in with some patches.
>

Hi Andy,

  feel free to go wild.


I've just pushed a patch series that implements your tab widget idea.

I've found that, luckily, the required change is small, so small that
I didn't create a new development branch but just a couple of check
boxes in 'Edit->Settings-Browse' dialog from where you can
enable/disable all these new fancy toys and play with them.

Have fun and let me know!

Marco

Re: [ANNOUNCE] qgit new "smart browsing" feature

[Andy Parkins]

On Tuesday 2007 June 05, Marco Costalba wrote:

> I've just pushed a patch series that implements your tab widget idea.

I like it a lot.  I also like having the settings. I always appreciate 
software that lets me work how I like.

> Have fun and let me know!

I've experienced a few occasions when the wheel scroll goes a bit strange.  
I've not figured exactly what I did to trigger it, but it was something like 
this: when scrolling up and down a lot, and causing the page flip to the 
message view, suddenly the scroll didn't work for normal upward scrolling.  I 
flipped pages again and it started working.

I'll try and narrow down exactly what I'm doing and be more precise.

For now, latest qgit is in /usr/local/bin, so will be getting daily use.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: [ANNOUNCE] qgit new "smart browsing" feature

[Marco Costalba]

On 6/6/07, Andy Parkins <andyparkins@gmail.com> wrote:
> On Tuesday 2007 June 05, Marco Costalba wrote:
>
>
> I've experienced a few occasions when the wheel scroll goes a bit strange.
> I've not figured exactly what I did to trigger it, but it was something like
> this: when scrolling up and down a lot, and causing the page flip to the
> message view, suddenly the scroll didn't work for normal upward scrolling.  I
> flipped pages again and it started working.
>
> I'll try and narrow down exactly what I'm doing and be more precise.
>

Thanks I'll appreciate.

This wheel scroll thing turned out to be really not trivial, BTW your
tabbed panes are far easier to implement. There are many little nasty
details to take care of to make it work correctly.


> For now, latest qgit is in /usr/local/bin, so will be getting daily use.
>

Great.


Marco