[ANNOUNCE] qgit new "smart browsing" feature

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

On Sunday 2007 June 03, Marco Costalba wrote:

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

On 6/4/07, Andy Parkins <andyparkins@gmail.com> wrote:

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.

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.

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.

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.

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.

On Monday 2007 June 04, Marco Costalba wrote:

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

On 6/4/07, Andy Parkins <andyparkins@gmail.com> wrote:

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.

On Monday 2007, June 04, Marco Costalba wrote:

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

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

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.

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

On 6/4/07, Andy Parkins <andyparkins@gmail.com> wrote:

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

On 6/4/07, Andy Parkins <andyparkins@gmail.com> wrote:

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

On Tuesday 2007 June 05, Marco Costalba wrote:

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

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

On 6/6/07, Andy Parkins <andyparkins@gmail.com> wrote:

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.

Great.

Marco