{"thread":{"id":"8323","subject":"[RFH] QGit: how to cram a patch in a crowded screen","startedAt":"2007-05-26T08:46:21Z","lastAt":"2007-06-04T15:41:19Z","messageCount":13,"participants":["Marco Costalba","Andy Parkins","Jan Hudec","Pavel Roskin","Alex Riesen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"43337","messageId":"e5bfff550705260146q51350f40q1c80cfe8079f47c6@mail.gmail.com","threadId":"8323","inReplyTo":null,"subject":"[RFH] QGit: how to cram a patch in a crowded screen","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-05-26T08:46:21Z","receivedAt":"2007-05-26T08:46:21Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"Me and Pavel were discussing about usability improvements in the new\nqgit (Qt4 based) that is going to replace the current Qt3 based one.\n\nCurrently there are no released tarballs, just a git repo:\n\ngit://git.kernel.org/pub/scm/qgit/qgit4.git\n\nbut it's already quite stable and feature complete and works also under Windows.\n\nThe biggest issue Pavel pointed out is that the main view does not\nshow patch content.\n\nCurrently qgit is tab based, so you have the main view tab with\nrevision header info:\nhttp://digilander.libero.it/mcostalba/qgit4_1.png\n\nOr without header info ('toggle 'h' key) for bigger screen estate\ngiven to the revisions list:\nhttp://digilander.libero.it/mcostalba/qgit4_2.png\n\nThen to see the patch you have to switch to 'patch tab' ('p' key and\n'r' key to go back to revisions list tab):\nhttp://digilander.libero.it/mcostalba/qgit4_3.png\n\nIn case you need to give a deep look at the patch maybe it's worth\ntoggling the split view with 's' key:\nhttp://digilander.libero.it/mcostalba/qgit4_4.png\n\nForm any tab you can navigate with 'i' (move up one) and 'n', 'k'\n(move down one) so that if you are interested in patch content only\nyou can avoid going back ('r') to main tab and stay in patch tab while\nbrowsing the repo.\n\nBut for Pavel this is not enough, and I agree with him, because you\ncannot see both the list and the patch content in one view.\n\nLong time ago qgit was using independent overlapping windows to show\neach kind of content, something similar to what git-gui uses now, then\nI switched to tabs because I found myself spending more time in\narranging windows then in browsing contents.\n\nThe legacy way to do it is the gitk way: patch content below revision\nlog messages.\n\nI tried to study that approach and to understand why it is practical\nand handy, at least if you don't need to see the patch at full screen,\nas I need in case I really want understand a difficult patch, but\nprobably this is a my limitation.\n\nWhat I found, the 'secret' of space screen saving also with patch\ncontent, is that when you look at the patch, scrolling down the\nbottom-left pane, the revision logs and messages automatically fade\naway because are scrolled out of the pane.\n\nSo it seems that you can see revision list + log messages + patch\ncontent, but indeed what you see is revision list + log messages + *a\ncouple of patch lines* _OR_ revision list + patch content.\n\nA natural consequence of this could be the introduction of another\nshortcut to toggle messages and patch content in main view bottom left\npane....\n\n\n\nAfter all this long introduction here we come to the subject of the e-mail.\n\nWe need some help, in terms of ideas, to better arrange the\ninformation to be shown in main view so to improve repo browsability.\n\nI could implement almost anything good comes up in this thread. But\nstill I don't figure out myself what is the best solution.\n\nAny suggestion is greatly appreciated.\n\nMarco\n\nP.S: To be a clone of gitk is not necessarily a design spec.\n"},{"id":"43339","messageId":"200705261034.53723.andyparkins@gmail.com","threadId":"8323","inReplyTo":"e5bfff550705260146q51350f40q1c80cfe8079f47c6@mail.gmail.com","subject":"Re: [RFH] QGit: how to cram a patch in a crowded screen","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-26T09:34:52Z","receivedAt":"2007-05-26T09:34:52Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Saturday 2007, May 26, Marco Costalba wrote:\n\n> We need some help, in terms of ideas, to better arrange the\n> information to be shown in main view so to improve repo browsability.\n>\n> I could implement almost anything good comes up in this thread. But\n> still I don't figure out myself what is the best solution.\n>\n> Any suggestion is greatly appreciated.\n\nWhile reading this I was reminded of something Linus said recently. The \ndefault form for exchanging patches is _not_ the diff; it's the email. \nThe reason for this is that emails contain author information, log \ninformation and patch information. I've often thought that one thing \nwe can be reasonably sure of is that the log message will be small. \nPerhaps then, the best thing would be to show each revision in a \nsimilar manner to how one would view the patch as an email as Pavel \nsuggests: all in one. My patches that made the header information \nappear in a box were a stumble in that direction, making the header \nlook a bit like an email header, what about going one step further and \nincluding the patch in that window as well?\n\nFor example, the log view widget would show:\n\n
\n\n\n\nAll visually distinct to improve searching by eye (perhaps including \nclear separators between files patched). Then the file list could \ninclude a \"
\" psuedo-file that would jump back to the top of the \nviewer.\n\nI think a key feature would be that the log message shows up fast, and \nthen the patch is loaded in the background - sometimes patches are big, \nbut you still want to hop around revisions without waiting for the \nwhole patch to load before you leap to the next view point.\n\nHere's another option, keeping the patch tab, but putting the tab widget \nin the log view window. That way the list would be visible and you \nwould just switch between the log and the patch.\n\nAnd another idea: make the log window a tree widget, of sorts, a bit \nlike kate in KDE is, each section would begin collapsed (perhaps), it \nwould look like:\n\n +
\n + \n + \n\nAnd clicking on the + would expand that section; then for the patch \nitself:\n\n + \n + \n + \n + \n\nIn this way the user could get an overview of all the changed files, and \ncould view the changes for whatever subset they wanted. It would \nprobably be nice to default the header and log message to expanded, \nwith the option to collapse them.\n\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"43367","messageId":"e5bfff550705261344l604543e7h64c20c1fc0979f20@mail.gmail.com","threadId":"8323","inReplyTo":"200705261034.53723.andyparkins@gmail.com","subject":"Re: [RFH] QGit: how to cram a patch in a crowded screen","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-05-26T20:44:28Z","receivedAt":"2007-05-26T20:44:28Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 5/26/07, Andy Parkins wrote:\n>\n> For example, the log view widget would show:\n>\n>
\n> \n> \n>\n> All visually distinct to improve searching by eye (perhaps including\n> clear separators between files patched). Then the file list could\n> include a \"
\" psuedo-file that would jump back to the top of the\n> viewer.\n>\n\nThis seems really gitk like. Not that I don' t like it, but _if_ it's\npossible I would prefer something a little bit more original.\n\n>\n> Here's another option, keeping the patch tab, but putting the tab widget\n> in the log view window. That way the list would be visible and you\n> would just switch between the log and the patch.\n>\n\nYes. More or less along the lines of an handful of patches I've just\npushed to git://git.kernel.org/pub/scm/qgit/qgit4.git\n\nNow user can toggle between revision commit message and patch content\nwith the menu entry 'View->toggle message/diff', or with shortcut 'm'\nor also with mouse clicking on top right links 'Diff->' and 'Log->'.\n\nThere is also a check box in 'Edit->settings' called 'Show always\nrevision message as first' that, if set, let automatically to switch\nto revision message when browsing on a new revision.\n\nWith this, browsing on a repo reading both log message and patch it's\na matter of 2 clicks or 2 shortcuts per revision, one for changing\nrevision (and read the log message) and another to view the patch\ncontent.\n\nThis is a good speedup from before when we needed 3 commands, one for\nselecting the rev, one for switching to patch tab and viewing the diff\nand one for switching back to main list.\n\n\nComments? like/dislike?\n\nThanks\nMarco\n"},{"id":"43438","messageId":"20070527153852.GA30365@efreet.light.src","threadId":"8323","inReplyTo":"e5bfff550705261344l604543e7h64c20c1fc0979f20@mail.gmail.com","subject":"Re: [RFH] QGit: how to cram a patch in a crowded screen","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-05-27T15:38:52Z","receivedAt":"2007-05-27T15:38:52Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sat, May 26, 2007 at 22:44:28 +0200, Marco Costalba wrote:\n> On 5/26/07, Andy Parkins wrote:\n> >\n> >For example, the log view widget would show:\n> >\n> >
\n> >\n> >\n> >\n> >All visually distinct to improve searching by eye (perhaps including\n> >clear separators between files patched). Then the file list could\n> >include a \"
\" psuedo-file that would jump back to the top of the\n> >viewer.\n> \n> This seems really gitk like. Not that I don' t like it, but _if_ it's\n> possible I would prefer something a little bit more original.\n\nIMHO there's no point in being original. The gitk way works well, because it\nrequires only one action -- scrolling -- throughout reading of the whole\ncommit (description + patch). With any kind of tabs, there's always an extra\naction for switching.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"43439","messageId":"e5bfff550705270856o195b9075u1c99a05e79d69742@mail.gmail.com","threadId":"8323","inReplyTo":"20070527153852.GA30365@efreet.light.src","subject":"Re: [RFH] QGit: how to cram a patch in a crowded screen","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-05-27T15:56:05Z","receivedAt":"2007-05-27T15:56:05Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 5/27/07, Jan Hudec wrote:\n> On Sat, May 26, 2007 at 22:44:28 +0200, Marco Costalba wrote:\n> > On 5/26/07, Andy Parkins wrote:\n> > >\n> > >For example, the log view widget would show:\n> > >\n> > >
\n> > >\n> > >\n> > >\n> > >All visually distinct to improve searching by eye (perhaps including\n> > >clear separators between files patched). Then the file list could\n> > >include a \"
\" psuedo-file that would jump back to the top of the\n> > >viewer.\n> >\n> > This seems really gitk like. Not that I don' t like it, but _if_ it's\n> > possible I would prefer something a little bit more original.\n>\n> IMHO there's no point in being original.\n\nTrue. But there's no point also in avoiding experimenting a little bit.\n\nI've pushed some patches to use different ways to switch between diff\nand messages, please read the last patch log message for a summary of\nthe changes.\n\nIf interested give it a try. it would be grat to hear your comment on that also.\n\nThanks\nMarco\n\nP.S: Perhaps the current gitk way is the best, but you'll never know\nif you never try something different.\n"},{"id":"43634","messageId":"200705301408.37929.andyparkins@gmail.com","threadId":"8323","inReplyTo":"e5bfff550705261344l604543e7h64c20c1fc0979f20@mail.gmail.com","subject":"Re: [RFH] QGit: how to cram a patch in a crowded screen","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-30T13:08:36Z","receivedAt":"2007-05-30T13:08:36Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Saturday 2007 May 26, Marco Costalba wrote:\n\nI've been using the latest qgit for a couple of days. Thought I'd comment on \nthe changes.\n\n> > All visually distinct to improve searching by eye (perhaps including\n> > clear separators between files patched). Then the file list could\n> > include a \"
\" psuedo-file that would jump back to the top of the\n> > viewer.\n>\n> This seems really gitk like. Not that I don' t like it, but _if_ it's\n> possible I would prefer something a little bit more original.\n\nI thought of a reason why I like qgit's separation of log and patch. Some \nrevisions have very large patches. In those cases, it's nice to have the \nchoice not to pay for the expensive patch display when all you want is to \nview the log message.\n\nMy vote is definitely for keeping separate log and patch viewer.\n\n> Now user can toggle between revision commit message and patch content\n> with the menu entry 'View->toggle message/diff', or with shortcut 'm'\n> or also with mouse clicking on top right links 'Diff->' and 'Log->'.\n\nI like the principle; but I'm not sure about the floating \"Diff->\" \nand \"Log->\"; it seems to me that the GUI metaphor for exactly this sort of \nthing is well established - the tabbed display. Why invent yet another way \nof switching a window between different views?\n\n> There is also a check box in 'Edit->settings' called 'Show always\n> revision message as first' that, if set, let automatically to switch\n> to revision message when browsing on a new revision.\n\nI have no objection to this. I can imagine cases when both automatic-switch \nand leave-it-as-it-is would be what I want - so it has to be an option.\n\n> With this, browsing on a repo reading both log message and patch it's\n> a matter of 2 clicks or 2 shortcuts per revision, one for changing\n> revision (and read the log message) and another to view the patch\n> content.\n\nYou don't mention it here, but the change I'm not keen on is the scroll-down \nto switch feature. Often, I over-scroll to be sure that I have hit the \nbottom of a scroll box. When I do that with the scroll-to-switch feature, \nsuddenly the view changes. I'm finding it quite disconcerting.\n\n> Comments? like/dislike?\n\nApart from the minor niggles I've mentioned above; I do like it.\n - It feels more stable - in my day-to-day usage, far less of the screen\n changes, so you don't feel that you're jumping between different modes\n - Being able to see the patch and the revision list at the same time is\n very nice.\n\nWhile we're on wishes, here's a couple:\n - It's hard to spot the boundaries between files in the the patch viewer.\n It would be great if the\n diff --git a/vserver/Makefile b/vserver/Makefile\n index 2581254..17d8934 100644\n lines had a different coloured background.\n - The margin at the front of the log message lines puts the header block and\n log text at different horizontal positions on the screen. I think it would\n be nicer if they were at the same position.\n\nMaybe I'll scratch those itches myself; but thought I'd mention them in case \nyou get to them before me :-)\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"43652","messageId":"e5bfff550705301118k4ca8720bna260e171f0eb83ca@mail.gmail.com","threadId":"8323","inReplyTo":"200705301408.37929.andyparkins@gmail.com","subject":"Re: [RFH] QGit: how to cram a patch in a crowded screen","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-05-30T18:18:21Z","receivedAt":"2007-05-30T18:18:21Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 5/30/07, Andy Parkins wrote:\n> On Saturday 2007 May 26, Marco Costalba wrote:\n>\n> I've been using the latest qgit for a couple of days. Thought I'd comment on\n> the changes.\n>\n\nThanks!\n\n\n>\n> > Now user can toggle between revision commit message and patch content\n> > with the menu entry 'View->toggle message/diff', or with shortcut 'm'\n> > or also with mouse clicking on top right links 'Diff->' and 'Log->'.\n>\n> I like the principle; but I'm not sure about the floating \"Diff->\"\n> and \"Log->\"; it seems to me that the GUI metaphor for exactly this sort of\n> thing is well established - the tabbed display. Why invent yet another way\n> of switching a window between different views?\n>\n\nThis 'Diff->' and \"Log\"thing are going to change a lot this week-end!\n\nMy (crazy) idea is:\n\n- Let switch from message to diff content scrolling down after the end\nof message.\n\n- Let switch from diff to message content scrolling up before the\nstart of diff content\n\n- Let browse from one revision to the previous one (going down by one)\nscrolling down after the end of diff content.\n\n- Let browse from one revision to the next one (going up by one)\nscrolling up before the start of message content.\n\n\nSo I imagine two labels for each content type:\n\n- for message content a top right label called \"Up\" and one in bottom\nright position called \"Diff\"\n\n- for diff content a top right label called \"Log\" and one in bottom\nright position called \"Down\"\n\n\nI plan also to change the labels in something more intuitive with\nscroll action, as example adding an up and down direction little\narrows next to them.\n\n\nBut that's not the end of the story: my mind went really mad while\nthinking about this!\n\nBecause I normally browse new patches going from the oldest to the\nearliest (going up), and for each patch I look before the message and\nthen (optionally) the content I 've wondered a nightmare like this:\n\nRevision message pane:\n-Up right position: one link label called \"Up\"\n-Down right position: two links called \"Diff\"and (in small font) \"Down\"\n\nDiff content pane:\n-Up right position: two links called \"Log\"and (in small font) \"Up\"\n-Down right position: two links called \"Up\"and (in small font) \"Down\"\n\nScrolling action defaults to bigger font label for either scroll direction.\n\nIt is possible to quickly switch each label couple: the big font label\nbecame the smallest so to change scroll action in case of changing\nrepository browsing direction.\n\nDirectly clicking on each label of course produces the correspondent effect.\n\n\nTo much smoke??\n\n\n>\n> You don't mention it here, but the change I'm not keen on is the scroll-down\n> to switch feature. Often, I over-scroll to be sure that I have hit the\n> bottom of a scroll box. When I do that with the scroll-to-switch feature,\n> suddenly the view changes. I'm finding it quite disconcerting.\n>\n\nThat's a problem of finding a suitable filter. There is already one\nimplemented that let you switch only once, you can keep scrolling but\nthe content will not change a second time, you need to stop scrolling\nfor a while to \"rearm\" the scroll action.\n\n\n> While we're on wishes, here's a couple:\n> - It's hard to spot the boundaries between files in the the patch viewer.\n> It would be great if the\n> diff --git a/vserver/Makefile b/vserver/Makefile\n> index 2581254..17d8934 100644\n> lines had a different coloured background.\n\nYes. I agree. Thanks.\n\n> - The margin at the front of the log message lines puts the header block and\n> log text at different horizontal positions on the screen. I think it would\n> be nicer if they were at the same position.\n>\n\nYes.\n\n> Maybe I'll scratch those itches myself; but thought I'd mention them in case\n> you get to them before me :-)\n>\n>\n\nPlease, fell free to go head, I will be involved in implementing this\ncrappy scrolling thing toy this week end :-)\n\nThanks\nMarco\n\nP.S: In case someone wonders what's the goal of this label madness. It\nis to be able to browse a repo in either both sequential directions,\nup or down, using only the mouse wheel.\n"},{"id":"43667","messageId":"1180571013.3582.32.camel@dv","threadId":"8323","inReplyTo":"e5bfff550705301118k4ca8720bna260e171f0eb83ca@mail.gmail.com","subject":"Re: [RFH] QGit: how to cram a patch in a crowded screen","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-05-31T00:23:33Z","receivedAt":"2007-05-31T00:23:33Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Wed, 2007-05-30 at 21:18 +0300, Marco Costalba wrote:\n> My (crazy) idea is:\n> \n> - Let switch from message to diff content scrolling down after the end\n> of message.\n...\n\nI'll appreciate if you follow standard conventions for standard GUI\nactions and don't change the behavior of such basic keys as arrows.\n\nIt would be better to use something more advanced for application\nspecific behavior. I belong to the post-vi generation, so my mind\ncannot easily associate letters (like 'i' and 'k') with up and down\nactions. But we could use some key combinations with obvious\n\"directional meaning\", such as Ctrl-arrows.\n\nI've said it before, and it's worth repeating - any key must be\ndiscoverable through the GUI. No key or feature should be discovered by\naccident - it would be a sign of bad design.\n\n> So I imagine two labels for each content type:\n> \n> - for message content a top right label called \"Up\" and one in bottom\n> right position called \"Diff\"\n...\n> I plan also to change the labels in something more intuitive with\n> scroll action, as example adding an up and down direction little\n> arrows next to them.\n\nI'm afraid it would misuse the paradigm of labels. It should be\nbuttons, perhaps in the toolbar.\n\n> P.S: In case someone wonders what's the goal of this label madness. It\n> is to be able to browse a repo in either both sequential directions,\n> up or down, using only the mouse wheel.\n\nIt may be a cool feature, but users don't expect the mouse wheel to\nchange anything other than position of the text. Switching the revision\nby the scrolling the wheel would be a feature discovered by accident.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"43674","messageId":"e5bfff550705302139q224ab949h7086478ab0045a8c@mail.gmail.com","threadId":"8323","inReplyTo":"1180571013.3582.32.camel@dv","subject":"Re: [RFH] QGit: how to cram a patch in a crowded screen","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-05-31T04:39:50Z","receivedAt":"2007-05-31T04:39:50Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 5/31/07, Pavel Roskin wrote:\n> On Wed, 2007-05-30 at 21:18 +0300, Marco Costalba wrote:\n> > My (crazy) idea is:\n> >\n> > - Let switch from message to diff content scrolling down after the end\n> > of message.\n> ...\n>\n> I'll appreciate if you follow standard conventions for standard GUI\n> actions and don't change the behavior of such basic keys as arrows.\n>\n> It would be better to use something more advanced for application\n> specific behavior. I belong to the post-vi generation, so my mind\n> cannot easily associate letters (like 'i' and 'k') with up and down\n> actions. But we could use some key combinations with obvious\n> \"directional meaning\", such as Ctrl-arrows.\n>\n> I've said it before, and it's worth repeating - any key must be\n> discoverable through the GUI. No key or feature should be discovered by\n> accident - it would be a sign of bad design.\n>\n\nyes I agree with you. The only thing that until now stopped me to add\nbuttons to tool bar is that it seems to me already over crowded. But I\nagree keys should be discoverable. Also regarding arrow keys, they\nstill have the same good old action to go up and down in text content,\nand will keep that.\n\n\n> > So I imagine two labels for each content type:\n> >\n> > - for message content a top right label called \"Up\" and one in bottom\n> > right position called \"Diff\"\n> ...\n> > I plan also to change the labels in something more intuitive with\n> > scroll action, as example adding an up and down direction little\n> > arrows next to them.\n>\n> I'm afraid it would misuse the paradigm of labels. It should be\n> buttons, perhaps in the toolbar.\n>\n\nThe idea of labels comes from using gmail, where in long threads you\ncan see the following with a coloured label with an arrow and the name\nof the sender.\n\nThe labels, used in this way and decorated with small up and down\narrows, give more the meaning of \"scroll down to see what's next\" then\nusing a button, but when yhe machinery is implemented it should be\nstraightforward change from labels to buttons and test also with them.\n\n\n> > P.S: In case someone wonders what's the goal of this label madness. It\n> > is to be able to browse a repo in either both sequential directions,\n> > up or down, using only the mouse wheel.\n>\n> It may be a cool feature, but users don't expect the mouse wheel to\n> change anything other than position of the text. Switching the revision\n> by the scrolling the wheel would be a feature discovered by accident.\n>\n\nYes, this problem is still open. I think the key is the graphical\nrapresentation of the labels/butons and their placement inside the\nwindow to give the user the hint that when scrolling with the mouse\nhe'll reach what's advertised in the label. Again gmail use of \"go to\nnext thread\" labels gave me some ideas.\n\n\nThanks\nMarco\n"},{"id":"43681","messageId":"81b0412b0705310227x36dba9f8je19f7c295d7d194c@mail.gmail.com","threadId":"8323","inReplyTo":"1180571013.3582.32.camel@dv","subject":"Re: [RFH] QGit: how to cram a patch in a crowded screen","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-31T09:27:59Z","receivedAt":"2007-05-31T09:27:59Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 5/31/07, Pavel Roskin wrote:\n> specific behavior. I belong to the post-vi generation, so my mind\n> cannot easily associate letters (like 'i' and 'k') with up and down\n\nThat's because 'i' is not \"up\" and 'k' is not \"down\".\n'j' is \"down\" and 'k' is \"up\" :-P\n"},{"id":"43695","messageId":"20070531195633.GA3252@efreet.light.src","threadId":"8323","inReplyTo":"e5bfff550705270856o195b9075u1c99a05e79d69742@mail.gmail.com","subject":"Re: [RFH] QGit: how to cram a patch in a crowded screen","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-05-31T19:56:33Z","receivedAt":"2007-05-31T19:56:33Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sun, May 27, 2007 at 17:56:05 +0200, Marco Costalba wrote:\n> On 5/27/07, Jan Hudec wrote:\n> >On Sat, May 26, 2007 at 22:44:28 +0200, Marco Costalba wrote:\n> >> On 5/26/07, Andy Parkins wrote:\n> >> >\n> >> >For example, the log view widget would show:\n> >> >\n> >> >
\n> >> >\n> >> >\n> >> >\n> >> >All visually distinct to improve searching by eye (perhaps including\n> >> >clear separators between files patched). Then the file list could\n> >> >include a \"
\" psuedo-file that would jump back to the top of the\n> >> >viewer.\n> >>\n> >> This seems really gitk like. Not that I don' t like it, but _if_ it's\n> >> possible I would prefer something a little bit more original.\n> >\n> >IMHO there's no point in being original.\n> \n> True. But there's no point also in avoiding experimenting a little bit.\n> \n> I've pushed some patches to use different ways to switch between diff\n> and messages, please read the last patch log message for a summary of\n> the changes.\n> \n> If interested give it a try. it would be grat to hear your comment on that \n> also.\n\nI have to say that I like the gitk way better. There is the issue of\nover-scrolling. I often want to quickly scan through the diff, so I scroll\npretty quickly and it switches over when I reach the end.\n\nI understand the reason to not calculate the diff until it's requested.\nI think I might like it if only message is shown initially and when user\nscrolls at -- or rather past -- the end, the diff would be APPENDED to it.\nThat way the scrolling would look more natural, while still only generating\nthe diff only on request.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"43801","messageId":"e5bfff550706020437i3f54d459rdbe9070fe03a28c9@mail.gmail.com","threadId":"8323","inReplyTo":"20070531195633.GA3252@efreet.light.src","subject":"Re: [RFH] QGit: how to cram a patch in a crowded screen","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-06-02T11:37:03Z","receivedAt":"2007-06-02T11:37:03Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 5/31/07, Jan Hudec wrote:\n>\n> I have to say that I like the gitk way better. There is the issue of\n> over-scrolling. I often want to quickly scan through the diff, so I scroll\n> pretty quickly and it switches over when I reach the end.\n>\n\nOk. \"Smart Browsing\" ;-) patch series pushed to qgit4.\n\nRefer to patches logs for a little documentation.\n\nPlease give feedback if this patch series it's not smart enough for you.\n\nThanks\nMarco\n"},{"id":"43984","messageId":"20070604154119.GA3299@efreet.light.src","threadId":"8323","inReplyTo":"e5bfff550706020437i3f54d459rdbe9070fe03a28c9@mail.gmail.com","subject":"Re: [RFH] QGit: how to cram a patch in a crowded screen","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-06-04T15:41:19Z","receivedAt":"2007-06-04T15:41:19Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sat, Jun 02, 2007 at 13:37:03 +0200, Marco Costalba wrote:\n> On 5/31/07, Jan Hudec wrote:\n> >\n> >I have to say that I like the gitk way better. There is the issue of\n> >over-scrolling. I often want to quickly scan through the diff, so I scroll\n> >pretty quickly and it switches over when I reach the end.\n> >\n> \n> Ok. \"Smart Browsing\" ;-) patch series pushed to qgit4.\n> \n> Refer to patches logs for a little documentation.\n> \n> Please give feedback if this patch series it's not smart enough for you.\n\nI think it feels quite good. And leaves room for additional pages. Ie. merge\ncould have the \"interesting\" (--cc) diff and diff against each parent in\nturn.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"}]}