{"thread":{"id":"8415","subject":"[ANNOUNCE] qgit new \"smart browsing\" feature","startedAt":"2007-06-03T20:39:51Z","lastAt":"2007-06-07T05:11:37Z","messageCount":10,"participants":["Marco Costalba","Andy Parkins"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"43909","messageId":"e5bfff550706031339v5ffda0a6u6f520f0c7b49f442@mail.gmail.com","threadId":"8415","inReplyTo":null,"subject":"[ANNOUNCE] qgit new \"smart browsing\" feature","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-06-03T20:39:51Z","receivedAt":"2007-06-03T20:39:51Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"I've pushed a patch series to\ngit://git.kernel.org/pub/scm/qgit/qgit4.git that implement a new and\nmuch improved way to browse a repo.\n\nWhat\n-------\n\n- Possibility to switch from revision message to diff content in\nbottom left pane of main view\n\n- Possibility to jump to next/previous revision with link labels at\nthe pane corners\n\n- Optional use of mouse wheel to perform all of the above actions\n\n\nHow\n------\n\nIn the bottom left pane two labels have been added. Both contain some\nlinks, a default one (big) and a secondary one (small), mouse wheel\naction performs the default link action when scrolled out, above or\nbelow the content view.\n\nLinks could be switched right clicking on them by the means of a popup\ncontext menu.\n\nFinally in Edit->settings menu a check box called 'Show always\nrevision message as first' has been added. When checked (suggested),\non jumping to a new revision the log message is shown first,\nregardless of the previous pane content.\n\n\nNotes\n--------\n\nCare has been taken to allow the wheel browsing experience to be as\nnatural as possible, in particular a way to avoid to switch when user\njust wants to scroll has been implemented. Also, getting a responsive\nscroll and switch command avoiding false positives was not immediate.\n\nI have found, to my surprise, that more the natural behaviour was\nobtained more the code amount was big. At the end a quite not trivial\nclass has been added just to let the user browsing without thinking on\nhow to do it.\n\nHope you enjoy it. Of course feedback is, a always, welcomed.\n\n\nMarco\n"},{"id":"43956","messageId":"200706040921.55861.andyparkins@gmail.com","threadId":"8415","inReplyTo":"e5bfff550706031339v5ffda0a6u6f520f0c7b49f442@mail.gmail.com","subject":"Re: [ANNOUNCE] qgit new \"smart browsing\" feature","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-06-04T08:21:54Z","receivedAt":"2007-06-04T08:21:54Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Sunday 2007 June 03, Marco Costalba wrote:\n\n> Care has been taken to allow the wheel browsing experience to be as\n> natural as possible, in particular a way to avoid to switch when user\n> just wants to scroll has been implemented. Also, getting a responsive\n> scroll and switch command avoiding false positives was not immediate.\n\nI'm really sorry to say it Marco, but it's really disturbing. You've \nobviously made great efforts to make it useable, but it just isn't. The \nscroll wheel behaviour being inconsistent is just annoying. Sometimes \nscrolling works, sometimes it doesn't, sometimes it switches content, \nsometimes it doesn't. It's obviously based on timeouts for the different \nfunctions, but that just means that I have no idea what a particular \noperation will do at any given time.\n\nI'm not sure I like the labels with arrows either; and the fonts changing size \nand visibility is inconsistent and discomfiting.\n\nOn the plus side - I do like the idea of being able to perform these \noperations; jumping from revision to revision, or from log to patch is nice. \nHowever, I think it is unwise to invent a new graphical metaphor for an \noperation that already exists - the tabbed widget. Similarly, the up and \ndown are obvious candidates for toolbar buttons - an already established \nvisual.\n\nSo - I think that the non-standard methods should be dropped (sorry); and be \nreplaced with tabs for the patch/log switch and toolbar buttons for the \nup/down. Also, the scroll-to-switch, while an interesting idea, gives \nunpredictable behaviour and so is uncomfortable to use.\n\nSorry for being so negative; it's a shame after your obvious hard work.\n\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"43967","messageId":"e5bfff550706040420j22852e4btc41a88c79bffc49f@mail.gmail.com","threadId":"8415","inReplyTo":"200706040921.55861.andyparkins@gmail.com","subject":"Re: [ANNOUNCE] qgit new \"smart browsing\" feature","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-06-04T11:20:00Z","receivedAt":"2007-06-04T11:20:00Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 6/4/07, Andy Parkins wrote:\n> On Sunday 2007 June 03, Marco Costalba wrote:\n>\n> > Care has been taken to allow the wheel browsing experience to be as\n> > natural as possible, in particular a way to avoid to switch when user\n> > just wants to scroll has been implemented. Also, getting a responsive\n> > scroll and switch command avoiding false positives was not immediate.\n>\n> I'm really sorry to say it Marco, but it's really disturbing. You've\n> obviously made great efforts to make it useable, but it just isn't. The\n> scroll wheel behaviour being inconsistent is just annoying. Sometimes\n> scrolling works, sometimes it doesn't, sometimes it switches content,\n> sometimes it doesn't. It's obviously based on timeouts for the different\n> functions, but that just means that I have no idea what a particular\n> operation will do at any given time.\n>\n\nThanks for your comment. I will try to do the following:\n\n- Allow to remove this possibility by unchecking a proper flag in\nsettings dialog.\n\n- Change the color of the arrows, as example highlighting, when the\nswitch behavior became active, i.e. at the top and bottom of scroll\nbar. So the user will know what a scroll action will do.\n\n> I'm not sure I like the labels with arrows either; and the fonts changing size\n> and visibility is inconsistent and discomfiting.\n>\n\nOk I can use same font for both labels, not a biggie. Regarding the\narrows, any other idea to tell to the user something will happen when\nscrolling is welcomed.\n\n> On the plus side - I do like the idea of being able to perform these\n> operations; jumping from revision to revision, or from log to patch is nice.\n> However, I think it is unwise to invent a new graphical metaphor for an\n> operation that already exists - the tabbed widget.\n\nThe tabbed widget is here to stay. I do not plan to remove it. But the\ntabbed widget is also slower then a well behaved scroll swicth or link\nclicking.\n\n> Similarly, the up and\n> down are obvious candidates for toolbar buttons - an already established\n> visual.\n>\n\nThis could be added, but it seems not needed to me given that for the\nsuer is faster to click on the previous/next revision in the revision\nlist then reaching the toolbar.\n\n> So - I think that the non-standard methods should be dropped (sorry); and be\n> replaced with tabs for the patch/log switch and toolbar buttons for the\n> up/down. Also, the scroll-to-switch, while an interesting idea, gives\n> unpredictable behaviour and so is uncomfortable to use.\n>\n> Sorry for being so negative; it's a shame after your obvious hard work.\n>\n\nThanks for your comments. They are much more valuable and useful then\na 'yes...it seems more or less nice'.\n\nThanks\nMarco\n\n\nP.S: Scrolling is not based on timeouts. The rule is: if user starts a\nscroll action while not at the extremes of the content then only a\nscroll will occur. If the user starts a scroll action from one extreme\nof the view (top or bottom) and the scroll direction goes toward out\nof the screen then a switch will occur.\n"},{"id":"43971","messageId":"200706041309.54279.andyparkins@gmail.com","threadId":"8415","inReplyTo":"e5bfff550706040420j22852e4btc41a88c79bffc49f@mail.gmail.com","subject":"Re: [ANNOUNCE] qgit new \"smart browsing\" feature","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-06-04T12:09:50Z","receivedAt":"2007-06-04T12:09:50Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2007 June 04, Marco Costalba wrote:\n\n> The tabbed widget is here to stay. I do not plan to remove it. But the\n> tabbed widget is also slower then a well behaved scroll swicth or link\n> clicking.\n\nAh - I've not explained myself clearly. What I mean is _another_ tab widget, \ninstead of the scroll-to-switch. It can't possibly be slower, as it's the \nsame amount of work for Qt... So it would look like this (excuse rubbish \nASCII art):\n\n +-----------------------------+\n | |\n | |\n | |\n | |\n +-----------------------------+\n | Log | Patch | |\n +-----| |---------------+\n | |\n | |\n +-----------------------------| \n\nAt the moment, you have a label in the top left of the text window that is \nmouse-clicked to change mode; I'm suggesting replacing that with a tab widget \nas above where you mouse click to change mode. It's no more operations, \ndoesn't include a strange floating label and is a more standard and \nrecognisable user interface.\n\nIf you still wanted up and down buttons, they could very easily go to the far \nright of the log|patch tabs, similar to the \"close\" button on the top tabs.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"43988","messageId":"e5bfff550706040915v3689e8afwb3dffd5d4caf137a@mail.gmail.com","threadId":"8415","inReplyTo":"200706041309.54279.andyparkins@gmail.com","subject":"Re: [ANNOUNCE] qgit new \"smart browsing\" feature","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-06-04T16:15:48Z","receivedAt":"2007-06-04T16:15:48Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 6/4/07, Andy Parkins wrote:\n> On Monday 2007 June 04, Marco Costalba wrote:\n>\n> > The tabbed widget is here to stay. I do not plan to remove it. But the\n> > tabbed widget is also slower then a well behaved scroll swicth or link\n> > clicking.\n>\n> Ah - I've not explained myself clearly. What I mean is _another_ tab widget,\n> instead of the scroll-to-switch. It can't possibly be slower, as it's the\n> same amount of work for Qt... So it would look like this (excuse rubbish\n> ASCII art):\n>\n> +-----------------------------+\n> | |\n> | |\n> | |\n> | |\n> +-----------------------------+\n> | Log | Patch | |\n> +-----| |---------------+\n> | |\n> | |\n> +-----------------------------|\n>\n> At the moment, you have a label in the top left of the text window that is\n> mouse-clicked to change mode; I'm suggesting replacing that with a tab widget\n> as above where you mouse click to change mode. It's no more operations,\n> doesn't include a strange floating label and is a more standard and\n> recognisable user interface.\n>\n> If you still wanted up and down buttons, they could very easily go to the far\n> right of the log|patch tabs, similar to the \"close\" button on the top tabs.\n>\n>\nAndy,\n\n I have to say that I really like your idea!\n\nNow I really don't know what to do! :-)\n\nProbably I will create a new branch called andy_gui where I'll\nimplement your idea, while continue to refine the current approach. As\nexample one enanchment I would like to implement is to keep the labels\nnormally hidden and show the top (bottom) one only when user scrolls\nto the top (bottom) boundary of the view so that we could resolve two\nissues: knowing when a scrolling action will cause a switch (i.e. only\nwhen the corresponding label is visible) and do not have the arrows\nwhen not needed.\n\nAnother enanchment could be to have only one link per label instead of\ntwo and right clicking on it to show a popup menu with available\nalternatives.\n\nOf course at the end there will remain only one! The winner will be,\nof course, chosen by a democratic polling among us.\n\n\nComments?\n\n\nThanks\nMarco\n\nP.S: Your approach is simple and good, the only downside is the screen\nestate taken by the tab bar. But I agree it's absolutly not a biggie.\n"},{"id":"43997","messageId":"200706042004.01819.andyparkins@gmail.com","threadId":"8415","inReplyTo":"e5bfff550706040915v3689e8afwb3dffd5d4caf137a@mail.gmail.com","subject":"Re: [ANNOUNCE] qgit new \"smart browsing\" feature","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-06-04T19:03:59Z","receivedAt":"2007-06-04T19:03:59Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2007, June 04, Marco Costalba wrote:\n\n> I have to say that I really like your idea!\n\nHurrah! See - even a blind golfer knocks one in eventually :-)\n\n> Probably I will create a new branch called andy_gui where I'll\n> implement your idea, while continue to refine the current approach.\n\nGreat stuff. If I get a moment, I'll try and chip in with some patches.\n\n> As example one enanchment I would like to implement is to keep the\n> labels normally hidden and show the top (bottom) one only when user\n> scrolls to the top (bottom) boundary of the view so that we could\n> resolve two issues: knowing when a scrolling action will cause a\n> switch (i.e. only when the corresponding label is visible) and do not\n> have the arrows when not needed.\n\nThat's certainly an improvement. I think in many cases both labels will \nbe visible - especially in log mode - because most log messages fit \ncompletely inside one window.\n\n> P.S: Your approach is simple and good, the only downside is the\n> screen estate taken by the tab bar. But I agree it's absolutly not a\n> biggie.\n\nYeah, that is a bit of a drawback. How about not putting the tabs on \nthe top or bottom, but on the left or right? In fact if you put them \non the right, they'd be almost exactly where your jump labels would be.\n\nMaybe this is only better for me, but I tend to have more left-to-right \nreal estate available in the lower half of the screen, primarily \nbecause the log messages tend to be limited to 80 columns, but the \nrevision list contains the ever-widening graph.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"44038","messageId":"e5bfff550706042250q6f4034d0y15c65516375fcf4a@mail.gmail.com","threadId":"8415","inReplyTo":"200706042004.01819.andyparkins@gmail.com","subject":"Re: [ANNOUNCE] qgit new \"smart browsing\" feature","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-06-05T05:50:53Z","receivedAt":"2007-06-05T05:50:53Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 6/4/07, Andy Parkins wrote:\n> On Monday 2007, June 04, Marco Costalba wrote:\n>\n> > P.S: Your approach is simple and good, the only downside is the\n> > screen estate taken by the tab bar. But I agree it's absolutly not a\n> > biggie.\n>\n> Yeah, that is a bit of a drawback. How about not putting the tabs on\n> the top or bottom, but on the left or right? In fact if you put them\n> on the right, they'd be almost exactly where your jump labels would be.\n>\n\nAndy, another point scored for you!\n\nI will do exactly that!\n\n\nNow the only drawback it remains (more \"mental\" then real) is that the\nuser already scrolls down to read the message / patch and, at the end,\nit's easier to just continue scrolling to jump to next/previous\nrevision then move the mouse to point the tab, click, and go back to\nstart scrolling again: a finger against a double hand movment + click.\n\nYes, I know, I'm veeery lazy ;-)\n\n\nMarco\n"},{"id":"44093","messageId":"e5bfff550706051148v57715bb1q88987e3fc6410899@mail.gmail.com","threadId":"8415","inReplyTo":"200706042004.01819.andyparkins@gmail.com","subject":"Re: [ANNOUNCE] qgit new \"smart browsing\" feature","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-06-05T18:48:03Z","receivedAt":"2007-06-05T18:48:03Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 6/4/07, Andy Parkins wrote:\n> On Monday 2007, June 04, Marco Costalba wrote:\n>\n> > I have to say that I really like your idea!\n>\n> Hurrah! See - even a blind golfer knocks one in eventually :-)\n>\n> > Probably I will create a new branch called andy_gui where I'll\n> > implement your idea, while continue to refine the current approach.\n>\n> Great stuff. If I get a moment, I'll try and chip in with some patches.\n>\n\nHi Andy,\n\n feel free to go wild.\n\n\nI've just pushed a patch series that implements your tab widget idea.\n\nI've found that, luckily, the required change is small, so small that\nI didn't create a new development branch but just a couple of check\nboxes in 'Edit->Settings-Browse' dialog from where you can\nenable/disable all these new fancy toys and play with them.\n\nHave fun and let me know!\n\nMarco\n"},{"id":"44142","messageId":"200706060930.49621.andyparkins@gmail.com","threadId":"8415","inReplyTo":"e5bfff550706051148v57715bb1q88987e3fc6410899@mail.gmail.com","subject":"Re: [ANNOUNCE] qgit new \"smart browsing\" feature","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-06-06T08:30:47Z","receivedAt":"2007-06-06T08:30:47Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 June 05, Marco Costalba wrote:\n\n> I've just pushed a patch series that implements your tab widget idea.\n\nI like it a lot. I also like having the settings. I always appreciate \nsoftware that lets me work how I like.\n\n> Have fun and let me know!\n\nI've experienced a few occasions when the wheel scroll goes a bit strange. \nI've not figured exactly what I did to trigger it, but it was something like \nthis: when scrolling up and down a lot, and causing the page flip to the \nmessage view, suddenly the scroll didn't work for normal upward scrolling. I \nflipped pages again and it started working.\n\nI'll try and narrow down exactly what I'm doing and be more precise.\n\nFor now, latest qgit is in /usr/local/bin, so will be getting daily use.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"44227","messageId":"e5bfff550706062211i7a216606l8da5e9a6f1281559@mail.gmail.com","threadId":"8415","inReplyTo":"200706060930.49621.andyparkins@gmail.com","subject":"Re: [ANNOUNCE] qgit new \"smart browsing\" feature","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-06-07T05:11:37Z","receivedAt":"2007-06-07T05:11:37Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 6/6/07, Andy Parkins wrote:\n> On Tuesday 2007 June 05, Marco Costalba wrote:\n>\n>\n> I've experienced a few occasions when the wheel scroll goes a bit strange.\n> I've not figured exactly what I did to trigger it, but it was something like\n> this: when scrolling up and down a lot, and causing the page flip to the\n> message view, suddenly the scroll didn't work for normal upward scrolling. I\n> flipped pages again and it started working.\n>\n> I'll try and narrow down exactly what I'm doing and be more precise.\n>\n\nThanks I'll appreciate.\n\nThis wheel scroll thing turned out to be really not trivial, BTW your\ntabbed panes are far easier to implement. There are many little nasty\ndetails to take care of to make it work correctly.\n\n\n> For now, latest qgit is in /usr/local/bin, so will be getting daily use.\n>\n\nGreat.\n\n\nMarco\n"}]}