From: Marco Costalba Date: Mon, 04 Jun 2007 11:20:00 GMT Subject: Re: [ANNOUNCE] qgit new "smart browsing" feature Message-ID: In-Reply-To: <200706040921.55861.andyparkins@gmail.com> On 6/4/07, Andy Parkins 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.