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

["Marco Costalba" <mcostalba@gmail.com>]

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.