{"thread":{"id":"8393","subject":"Improved git-gui blame viewer","startedAt":"2007-06-02T04:17:23Z","lastAt":"2007-06-05T21:47:21Z","messageCount":12,"participants":["Shawn O. Pearce","Matthijs Melchior","Martin Waitz","Alex Riesen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"43785","messageId":"20070602041723.GD7044@spearce.org","threadId":"8393","inReplyTo":null,"subject":"Improved git-gui blame viewer","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-06-02T04:17:23Z","receivedAt":"2007-06-02T04:17:23Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"A long time ago Linus Torvalds <torvalds@linux-foundation.org> wrote:\n> \n> On Sun, 18 Mar 2007, Shawn O. Pearce wrote:\n> > Linus Torvalds <torvalds@linux-foundation.org> wrote:\n> > > \n> > > Of course, the git gui blame colorization is clearly done by somebody who \n> > > is still actively popping LSD with both fists and didn't realize that the \n> > > 60's are long done, but that's another issue.\n> > \n> > git-gui is open source.  I'd be happy to take a patch.  Or,\n> > since that is horribly messy Tcl/Tk code, just a better color\n> > suggestion. :-)\n> \n> I would suggest:\n> \n>  - some special color for \"currently selected\" (which defaults to being \n>    the first one coming out of the blame thing, of course). \n> \n>    I'd suggest \"black text on pale green background\", but that may be just \n>    me.\n> \n>  - some *stable* graduated color for the rest. I don't think it \n>    necessarily needs to be \"older\" vs \"newer\", and in fact I'd suggest \n>    just two slightly different shades of gray for the background - just \n>    pick alternating shades for each blame entry that comes in (and leave \n>    un-blamed lines white).\n\nI finally got the git-gui code to the point where cleaning up the\nuser interface was possible without sending myself to the nut house.\n\nI tried out Linus' suggestions for coloring, and I like them.  Enough\nthat they are now sitting in my `pu` branch on repo.or.cz/git-gui.git.\n\nThere's also a whole slew of other improvements to the blame viewer,\nlike being able to dig through history by clicking on commit ids,\nand tooltips when you mouse over a region of the file.\n\nBehavior on Windows is actually quite good; its less so on Mac\nOS X.  I'm fighting Tk there a little bit more than I should be.\nUntested on Linux, so I'd love to hear some feedback on it.\n\n  git://repo.or.cz/git-gui.git      pu\n  http://repo.or.cz/r/git-gui.git   pu\n \n-- \nShawn.\n"},{"id":"43800","messageId":"f3rhme$2h9$1@sea.gmane.org","threadId":"8393","inReplyTo":"20070602041723.GD7044@spearce.org","subject":"Re: Improved git-gui blame viewer","fromName":"Matthijs Melchior","fromEmail":"mmelchior@xs4all.nl","sentAt":"2007-06-02T10:44:29Z","receivedAt":"2007-06-02T10:44:29Z","isPatch":false,"sender":{"key":"mmelchior@xs4all.nl","avatar":null},"body":"Shawn O. Pearce wrote:\n> A long time ago Linus Torvalds <torvalds@linux-foundation.org> wrote:\n>> On Sun, 18 Mar 2007, Shawn O. Pearce wrote:\n>>> Linus Torvalds <torvalds@linux-foundation.org> wrote:\n>>>> Of course, the git gui blame colorization is clearly done by somebody who \n>>>> is still actively popping LSD with both fists and didn't realize that the \n>>>> 60's are long done, but that's another issue.\n>>> git-gui is open source.  I'd be happy to take a patch.  Or,\n>>> since that is horribly messy Tcl/Tk code, just a better color\n>>> suggestion. :-)\n>> I would suggest:\n>>\n>>  - some special color for \"currently selected\" (which defaults to being \n>>    the first one coming out of the blame thing, of course). \n>>\n>>    I'd suggest \"black text on pale green background\", but that may be just \n>>    me.\n>>\n>>  - some *stable* graduated color for the rest. I don't think it \n>>    necessarily needs to be \"older\" vs \"newer\", and in fact I'd suggest \n>>    just two slightly different shades of gray for the background - just \n>>    pick alternating shades for each blame entry that comes in (and leave \n>>    un-blamed lines white).\n> \n> I finally got the git-gui code to the point where cleaning up the\n> user interface was possible without sending myself to the nut house.\n> \n> I tried out Linus' suggestions for coloring, and I like them.  Enough\n> that they are now sitting in my `pu` branch on repo.or.cz/git-gui.git.\n> \n> There's also a whole slew of other improvements to the blame viewer,\n> like being able to dig through history by clicking on commit ids,\n> and tooltips when you mouse over a region of the file.\n> \n> Behavior on Windows is actually quite good; its less so on Mac\n> OS X.  I'm fighting Tk there a little bit more than I should be.\n> Untested on Linux, so I'd love to hear some feedback on it.\n> \n>   git://repo.or.cz/git-gui.git      pu\n>   http://repo.or.cz/r/git-gui.git   pu\n>  \n\nI have got this on Debian Etch and given the command 'make install'\nin the pu branch while git-core 1.5.2 is installed.\n\nAbout git-gui says:\n\tgit-gui version 0.7.2.39.ge6a1\n\tgit version 1.5.2\n\tTcl/Tk version 8.4.12\n\nThe colors look much better.\n\nThe behavior has some rough edges. I don't like the following:\n  When clicking on a link in the left column, the file as present in\n  that commit is loaded, positioned at the top. I would like for the\n  line where I clicked is to stay at the same position on the screen,\n  so I do not have to find it again.\n\n  Also, when returning I would like most lines on the screen stay the\n  same.\n\n  When clicking on a light gray line to become a green line, then\n  adjacent areas are not correctly colored.  A few adjacent entries\n  become all same gray... [Look around git-gui.sh:340]\n\n\n  Something I want for the normal window, in the Staged and Unstaged\n  file lists, high-lite the last entry selected so it becomes easy to\n  click on the next one and I can see more clearly what is displayed\n  in the bottom area.\n\n\nThanks for your efforts!\n\nRegards,\n\tMatthijs Melchior.\n"},{"id":"43941","messageId":"20070604060720.GF4507@spearce.org","threadId":"8393","inReplyTo":"f3rhme$2h9$1@sea.gmane.org","subject":"Re: Improved git-gui blame viewer","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-06-04T06:07:20Z","receivedAt":"2007-06-04T06:07:20Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Matthijs Melchior <mmelchior@xs4all.nl> wrote:\n> The colors look much better.\n\nThank Linus.  He's not a user inteface guy, but his idea was actually\npretty good.  ;-)\n \n> The behavior has some rough edges. I don't like the following:\n>   When clicking on a link in the left column, the file as present in\n>   that commit is loaded, positioned at the top. I would like for the\n>   line where I clicked is to stay at the same position on the screen,\n>   so I do not have to find it again.\n\nMe too.  Unfortunately I'm fighting with Tk to make this work.\nRight now I've got the code written to do this, and I see it happen\ninternally, but then something causes Tk to reset the viewport back\nto the top.  Arrrrrrgh.  I haven't pushed it out because it doesn't\nwork.\n \n>   Also, when returning I would like most lines on the screen stay the\n>   same.\n\nDitto.\n\n>   When clicking on a light gray line to become a green line, then\n>   adjacent areas are not correctly colored.  A few adjacent entries\n>   become all same gray... [Look around git-gui.sh:340]\n\nThis (I think) is because of the way the color selections are\nbeing done.  git-gui is being stupid and just alternating colors to\ncommits as they come in from `git blame --incremental`.  The thing\nabout the incremental blame is I can receive data for any part of\nthe file at any time.  So in general what happens is I get data for\none part of the file, give it color A, then data for another part,\ngive it color B, and then get data for part that is right next to the\nfirst A and assign it A again.  So you see chunks where there is no\nalternating...\n\n>   Something I want for the normal window, in the Staged and Unstaged\n>   file lists, high-lite the last entry selected so it becomes easy to\n>   click on the next one and I can see more clearly what is displayed\n>   in the bottom area.\n\nI'm not sure I understand what you are looking for here.  Right now\ngit-gui should be inverting the foreground/background colors on\nthe file that is \"selected\" (shown in the lower diff view pane).\nSo the background should be black, and the foreground white.\nIs this not happening?  Or are you looking for something else?\n\n-- \nShawn.\n"},{"id":"43951","messageId":"20070604073827.GF16637@admingilde.org","threadId":"8393","inReplyTo":"20070604060720.GF4507@spearce.org","subject":"Re: Improved git-gui blame viewer","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2007-06-04T07:38:27Z","receivedAt":"2007-06-04T07:38:27Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Mon, Jun 04, 2007 at 02:07:20AM -0400, Shawn O. Pearce wrote:\n> >   When clicking on a light gray line to become a green line, then\n> >   adjacent areas are not correctly colored.  A few adjacent entries\n> >   become all same gray... [Look around git-gui.sh:340]\n> \n> This (I think) is because of the way the color selections are\n> being done.  git-gui is being stupid and just alternating colors to\n> commits as they come in from `git blame --incremental`.  The thing\n> about the incremental blame is I can receive data for any part of\n> the file at any time.  So in general what happens is I get data for\n> one part of the file, give it color A, then data for another part,\n> give it color B, and then get data for part that is right next to the\n> first A and assign it A again.  So you see chunks where there is no\n> alternating...\n\nIf you use three colors you can always select one which is different\nto the hunk above and below.  But I don't know if that would be\nvisually appealing...\n\nAnother nice thing would be a smooth gradient for each hunk.\nThen we could use the same colors for every hunk, but the top of each\nhunk would be a little bit lighter/darker than the bottom so that\nit is easy to see the border.  Is that doable in Tk?\nPerhaps a simple small line between hunks is enough, too?\n\n-- \nMartin Waitz\n"},{"id":"43957","messageId":"20070604082156.GI4507@spearce.org","threadId":"8393","inReplyTo":"20070604073827.GF16637@admingilde.org","subject":"Re: Improved git-gui blame viewer","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-06-04T08:21:56Z","receivedAt":"2007-06-04T08:21:56Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Martin Waitz <tali@admingilde.org> wrote:\n> \n> On Mon, Jun 04, 2007 at 02:07:20AM -0400, Shawn O. Pearce wrote:\n> > >   When clicking on a light gray line to become a green line, then\n> > >   adjacent areas are not correctly colored.  A few adjacent entries\n> > >   become all same gray... [Look around git-gui.sh:340]\n> \n> If you use three colors you can always select one which is different\n> to the hunk above and below.  But I don't know if that would be\n> visually appealing...\n\nThat's actually not a bad idea.  But to make that work I have to\ndo the coloring by line chunks, not commits.  Given how bad the\ncurrent by-commit coloring is, the 3 coloring by line chunks is\nprobably the best bet.  It would resemble what gitweb does, but\nwe'd be using 3 colors in git-gui vs. the 2 in gitweb.  We could\ndo worse.\n \n> Another nice thing would be a smooth gradient for each hunk.\n> Then we could use the same colors for every hunk, but the top of each\n> hunk would be a little bit lighter/darker than the bottom so that\n> it is easy to see the border.  Is that doable in Tk?\n\nI think so, but its ugly.  The viewer is actually 4 text widgets\ncrammed next to each other.  I can set the background color of a\nline by giving it a tag, so to do a gradient I have to assign a\ndifferent background color to each line by giving each line its\nown tag (ick).  Worse, in a 3 line chunk I can only do 3 colors.\nThat fails your \"smooth\" concept.  ;-)\n\n> Perhaps a simple small line between hunks is enough, too?\n\nThat would be messy.  I can certainly cause a few pixels of spacing\nto show up between chunks, but I'm reading the data \"live\" from the\nblame engine and putting it on screen.  Adding space betwen chunks\nas I get it will cause the data to \"reflow\" while you are trying to\nread it.  I can probably account for it with the scrollbar and adjust\nit accordingly, but at some point you will wind up seeing the text\nin the viewer pane moving around and expanding as the padding gets\ntossed in.\n\n\nBTW, I just got the jump-to-original line and restore-view-on-back\nfeatures that Matthijs was asking about working properly.  Apparently\na call to Tk's \"update\" (basically just let Tk pump its event loop)\nis needed after I've finished reading the file content, but before I\nadjust the view.  Its in my pu branch now (gitgui-0.7.2-58-gf9e96fd).\n\n-- \nShawn.\n"},{"id":"43961","messageId":"20070604084852.GG16637@admingilde.org","threadId":"8393","inReplyTo":"20070604082156.GI4507@spearce.org","subject":"Re: Improved git-gui blame viewer","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2007-06-04T08:48:52Z","receivedAt":"2007-06-04T08:48:52Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Mon, Jun 04, 2007 at 04:21:56AM -0400, Shawn O. Pearce wrote:\n> I think so, but its ugly.  The viewer is actually 4 text widgets\n> crammed next to each other.  I can set the background color of a\n> line by giving it a tag, so to do a gradient I have to assign a\n> different background color to each line by giving each line its\n> own tag (ick).  Worse, in a 3 line chunk I can only do 3 colors.\n> That fails your \"smooth\" concept.  ;-)\n\nyeah, if each line has a solid background that does not work :-(\n\n> > Perhaps a simple small line between hunks is enough, too?\n> \n> That would be messy.  I can certainly cause a few pixels of spacing\n> to show up between chunks, but I'm reading the data \"live\" from the\n> blame engine and putting it on screen.  Adding space betwen chunks\n> as I get it will cause the data to \"reflow\" while you are trying to\n> read it.  I can probably account for it with the scrollbar and adjust\n> it accordingly, but at some point you will wind up seeing the text\n> in the viewer pane moving around and expanding as the padding gets\n> tossed in.\n\nWell, it would work if you could just draw a one-pixel line (in some\nsubtle gray) inbetween lines, without changing the layout.\n\n> BTW, I just got the jump-to-original line and restore-view-on-back\n> features that Matthijs was asking about working properly.  Apparently\n> a call to Tk's \"update\" (basically just let Tk pump its event loop)\n> is needed after I've finished reading the file content, but before I\n> adjust the view.  Its in my pu branch now (gitgui-0.7.2-58-gf9e96fd).\n\nnice :-)\n\n-- \nMartin Waitz\n"},{"id":"43986","messageId":"81b0412b0706040910w1894770bm593e0e54fbb3c44@mail.gmail.com","threadId":"8393","inReplyTo":"20070602041723.GD7044@spearce.org","subject":"Re: Improved git-gui blame viewer","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-04T16:10:54Z","receivedAt":"2007-06-04T16:10:54Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 6/2/07, Shawn O. Pearce <spearce@spearce.org> wrote:\n>\n> I finally got the git-gui code to the point where cleaning up the\n> user interface was possible without sending myself to the nut house.\n>\n\nVery-very nice :) Does not seem to save sizes and positions of\nblame and file browser windows, though. It did before, I believe\nin .git/config.\n\nBTW, saving windows positions in .git/config was scary: I\nconsidered it user domain (yes, I _am_ afraid of using\ngit-config too).\nMaybe it could be something like either ~/.git-gui or .git/guiconfig?\n"},{"id":"44004","messageId":"4664838C.8000109@xs4all.nl","threadId":"8393","inReplyTo":"20070604060720.GF4507@spearce.org","subject":"Re: Improved git-gui blame viewer","fromName":"Matthijs Melchior","fromEmail":"mmelchior@xs4all.nl","sentAt":"2007-06-04T21:26:36Z","receivedAt":"2007-06-04T21:26:36Z","isPatch":false,"sender":{"key":"mmelchior@xs4all.nl","avatar":null},"body":"Shawn O. Pearce wrote:\n> Matthijs Melchior <mmelchior@xs4all.nl> wrote:\n....\n> \n>>   Something I want for the normal window, in the Staged and Unstaged\n>>   file lists, high-lite the last entry selected so it becomes easy to\n>>   click on the next one and I can see more clearly what is displayed\n>>   in the bottom area.\n> \n> I'm not sure I understand what you are looking for here.  Right now\n> git-gui should be inverting the foreground/background colors on\n> the file that is \"selected\" (shown in the lower diff view pane).\n> So the background should be black, and the foreground white.\n> Is this not happening?  Or are you looking for something else?\n> \n\nNo, I am not looking for something else...., the inverting you describe\ndoes not happen on my machine....\n\nI am now running Debian git-core 1.5.2.1-1 with 'make install' done\nin the origin/pu branch of git-gui.\n'About git-gui' now says:\n\tgit-gui version 0.7.2.58-gf9e9\n\tgit version 1.5.2.1\n\tTcl/Tk version 8.4.12\n\nIf you explain where this inverting is taking place, I can do some\nexperiments to find out more [use gray background i.s.o. inverting...]\nMaybe it has something to do with Desktop themes, I use the standard\nGnome theme.\n\nThanks,\n\tMatthijs Melchior.\n"},{"id":"44032","messageId":"20070605042855.GA9513@spearce.org","threadId":"8393","inReplyTo":"4664838C.8000109@xs4all.nl","subject":"Re: Improved git-gui blame viewer","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-06-05T04:28:55Z","receivedAt":"2007-06-05T04:28:55Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Matthijs Melchior <mmelchior@xs4all.nl> wrote:\n> Shawn O. Pearce wrote:\n> > I'm not sure I understand what you are looking for here.  Right now\n> > git-gui should be inverting the foreground/background colors on\n> > the file that is \"selected\" (shown in the lower diff view pane).\n> > So the background should be black, and the foreground white.\n> > Is this not happening?  Or are you looking for something else?\n> > \n> \n> No, I am not looking for something else...., the inverting you describe\n> does not happen on my machine....\n\nI'm wrong.  Its not inverting.  Its bold if its selected, and normal\nif its not selected.  Perhaps your font is already a bold weight\nso you aren't seeing a difference between the selected item and\nthe non-selected items.\n \n> I am now running Debian git-core 1.5.2.1-1 with 'make install' done\n> in the origin/pu branch of git-gui.\n> 'About git-gui' now says:\n> \tgit-gui version 0.7.2.58-gf9e9\n> \tgit version 1.5.2.1\n> \tTcl/Tk version 8.4.12\n> \n> If you explain where this inverting is taking place, I can do some\n> experiments to find out more [use gray background i.s.o. inverting...]\n> Maybe it has something to do with Desktop themes, I use the standard\n> Gnome theme.\n\nAround line 1803 of git-gui.sh we setup the in_diff tag for the\n$ui_index and $ui_workdir Tk widgets.  That tag is applied to the\nfile that is in the diff viewer.  Perhaps adding a background to\nthe tag would get you an improved interface?\n\n-- \nShawn.\n"},{"id":"44033","messageId":"20070605043824.GB9513@spearce.org","threadId":"8393","inReplyTo":"81b0412b0706040910w1894770bm593e0e54fbb3c44@mail.gmail.com","subject":"Re: Improved git-gui blame viewer","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-06-05T04:38:24Z","receivedAt":"2007-06-05T04:38:24Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Alex Riesen <raa.lkml@gmail.com> wrote:\n> On 6/2/07, Shawn O. Pearce <spearce@spearce.org> wrote:\n> >\n> >I finally got the git-gui code to the point where cleaning up the\n> >user interface was possible without sending myself to the nut house.\n> >\n> \n> Very-very nice :) \n\nThanks.  I'm not done yet.  There's a lot of interesting navigation\nI still want to get in, like visting the parent of a changed line,\ninstead of the commit that changed that line.  I also want to let\nyou open commits in a new window, rather than the current one.\n\n> Does not seem to save sizes and positions of\n> blame and file browser windows, though. It did before, I believe\n> in .git/config.\n\nActually we have never saved the window sizes/positions of the \nblame and browser windows, only the main commit window.  Though\nyou may have been seeing a bug where we restored the main commit\nwindow's saved geometry on a browser or blame window if the latter\nwas started from the command line...\n\n> BTW, saving windows positions in .git/config was scary: I\n> considered it user domain (yes, I _am_ afraid of using\n> git-config too).\n> Maybe it could be something like either ~/.git-gui or .git/guiconfig?\n\nI'm apparently not afraid of git-config editing file(s).  I have\nyet to see a failure from it.  I guess I'm lucky, but will now\nsuffer a failure tomorrow when I'm least expecting it.  ;-)\n\nDon't we use git-config to edit the config file in git-branch?\nIn git-remote?  git-gui has *always* used git-config to store\nits data.  You are sort of asking me to replace a working config\nsystem with a new one that hasn't been tested...\n\nNow moving the git-gui config to say ~/.gitgui-config and\n.git/gitgui-config may have a good argument, as then git-gui\nis editing its own files.  Unless the user changes user.name\nor user.email through git-gui, in which case we have to edit\n.git/config or ~/.gitconfig anyway...\n\n-- \nShawn.\n"},{"id":"44063","messageId":"81b0412b0706050336nc610ea7t98797504ef25cfc@mail.gmail.com","threadId":"8393","inReplyTo":"20070605043824.GB9513@spearce.org","subject":"Re: Improved git-gui blame viewer","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-05T10:36:49Z","receivedAt":"2007-06-05T10:36:49Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 6/5/07, Shawn O. Pearce <spearce@spearce.org> wrote:\n> Don't we use git-config to edit the config file in git-branch?\n\nNot routinely. Seldom, even\n\n> In git-remote?  git-gui has *always* used git-config to store\n> its data.  You are sort of asking me to replace a working config\n> system with a new one that hasn't been tested...\n\nJust divert the data someplace else.\n\n> Now moving the git-gui config to say ~/.gitgui-config and\n> .git/gitgui-config may have a good argument, as then git-gui\n> is editing its own files.\n\nGood argument on its own\n\n>  Unless the user changes user.name\n> or user.email through git-gui, in which case we have to edit\n> .git/config or ~/.gitconfig anyway...\n\nYes, then of course (in this case the user is even aware).\n"},{"id":"44104","messageId":"4665D9E9.8050409@xs4all.nl","threadId":"8393","inReplyTo":"20070605042855.GA9513@spearce.org","subject":"Re: Improved git-gui blame viewer","fromName":"Matthijs Melchior","fromEmail":"mmelchior@xs4all.nl","sentAt":"2007-06-05T21:47:21Z","receivedAt":"2007-06-05T21:47:21Z","isPatch":false,"sender":{"key":"mmelchior@xs4all.nl","avatar":null},"body":"Shawn O. Pearce wrote:\n> Matthijs Melchior <mmelchior@xs4all.nl> wrote:\n>   \n>> Shawn O. Pearce wrote:\n>>     \n>>> I'm not sure I understand what you are looking for here.  Right now\n>>> git-gui should be inverting the foreground/background colors on\n>>> the file that is \"selected\" (shown in the lower diff view pane).\n>>> So the background should be black, and the foreground white.\n>>> Is this not happening?  Or are you looking for something else?\n>>>\n>>>       \n>> No, I am not looking for something else...., the inverting you describe\n>> does not happen on my machine....\n>>     \n>\n> I'm wrong.  Its not inverting.  Its bold if its selected, and normal\n> if its not selected.  Perhaps your font is already a bold weight\n> so you aren't seeing a difference between the selected item and\n> the non-selected items.\n>  \n>   \n>> I am now running Debian git-core 1.5.2.1-1 with 'make install' done\n>> in the origin/pu branch of git-gui.\n>> 'About git-gui' now says:\n>> \tgit-gui version 0.7.2.58-gf9e9\n>> \tgit version 1.5.2.1\n>> \tTcl/Tk version 8.4.12\n>>\n>> If you explain where this inverting is taking place, I can do some\n>> experiments to find out more [use gray background i.s.o. inverting...]\n>> Maybe it has something to do with Desktop themes, I use the standard\n>> Gnome theme.\n>>     \n>\n> Around line 1803 of git-gui.sh we setup the in_diff tag for the\n> $ui_index and $ui_workdir Tk widgets.  That tag is applied to the\n> file that is in the diff viewer.  Perhaps adding a background to\n> the tag would get you an improved interface?\n>   \nYes, this is the problem.\n\nI will send you a patch to change the background of the selected file\nto lightgray.\n\nI have included in that patch some softer colors for the headers of\nthe three involved widgets. I hope you like these.\n\nThanks.\n\n-- \nRegards,\n----------------------------------------------------------------  -o)\nMatthijs Melchior                                       Maarssen  /\\\\\nmmelchior@xs4all.nl                                  Netherlands _\\_v\n---------------------------------------------------------------- ----\n"}]}