Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
On 2016-12-19 11:44 AM, Michael Haggerty wrote: This patch series changes a bunch of details about how remote-tracking references are rendered in the commit list of gitk: I don't see this series in git v2.12.0-rc0, nor in Paul's gitk repo. I hope this is an oversight, and not that the series got dropped for some reason. M. * Omit the "remote/" prefix on normal remote-tracking references. They are already distinguished via their two-tone rendering and (usually) longer names, and this change saves a lot of visual clutter and horizontal space. * Render remote-tracking references that have more than the usual three slashes like origin/foo/bar ^^^ rather than origin/foo/bar (formerly remotes/origin/foo/bar) ^^^ ^^^ , where the indicated part is the prefix that is rendered in a different color. Usually, such a reference represents a remote branch that contains a slash in its name, so the new split more accurately portrays the separation between remote name and remote branch name. * Introduce a separate constant to specify the background color used for the branch name part of remote-tracking references, to allow it to differ from the color used for local branches (which by default is bright green). * Change the default background colors for remote-tracking branches to light brown and brown (formerly they were pale orange and bright green). I understand that the colors of pixels on computer screens is an even more emotional topic that that of bikesheds, so I implemented the last change as a separate commit, the last one in the series. Feel free to drop it if you don't want the default color change. Along the way, I did a bunch of refactoring in the area to make these changes easier, and introduced a constant for the background color of "other" references so that it can also be adjusted by users. (Unfortunately, these colors can only be adjusted by editing the configuration file. Someday it would be nice to allow them to be configured via the preferences dialog.) It's been a while since I've written any Tcl code, so I apologize in advance for any howlers :-) This branch applies against the `master` branch in git://ozlabs.org/~paulus/gitk. Michael Michael Haggerty (13): gitk: when processing tag labels, don't use `marks` as scratch space gitk: keep track of tag types in a separate `types` array gitk: use a type "tags" to indicate abbreviated tags gitk: use a type "mainhead" to indicate the main HEAD branch gitk: fill in `wvals` as the tags are first processed gitk: simplify regexp gitk: extract a method `remotereftext` gitk: only change the color of the "remote" part of remote refs gitk: shorten labels displayed for modern remote-tracking refs gitk: use type "remote" for remote-tracking references gitk: introduce a constant otherrefbgcolor gitk: add a configuration setting `remoterefbgcolor` gitk: change the default colors for remote-tracking references gitk | 114 --- 1 file changed, 76 insertions(+), 38 deletions(-)
Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
On 2016-12-22 03:15 AM, Michael Haggerty wrote: On 12/21/2016 08:07 PM, Marc Branchaud wrote: On 2016-12-20 07:05 PM, Michael Haggerty wrote: On 12/20/2016 04:01 PM, Marc Branchaud wrote: [...] Please don't change the remotebgcolor default. Also, perhaps the default remoterefbgcolor should be set remoterefbgcolor $headbgcolor ? I say this because when I applied the series, without the last patch, I was miffed that the remote/ref colour had changed. This is a one-time inconvenience that gitk developers will experience. I doubt that users jump backwards and forwards in gitk versions very often. In what way do you mean it's restricted to gitk developers? Maybe I misunderstood your objection. While developing this, I realized that the very first time your run gitk (i.e., when you don't already have a configuration file), it writes the then-current default colors into your configuration file. If you later switch gitk versions to a version with different default colors, the colors from the first-run version are preserved (unless the names of the variables used to hold the colors are changed). So if you would run the tip version of my branch first, then the parent of that version, you would continue to see the colors as modified by the final commit. If you then switch to the master version, the remote branch names go back to green (because it goes back to using `headbgcolor` again), but the remote prefix stays light brown. I thought you were unhappy about some form of this unexpected persistence problem. But this problem will mostly be experienced by gitk developers who jump back and forth between versions. A normal user probably mostly moves forward through version numbers, and only occasionally. Such a user, jumping from master to the tip of my branch (assuming they haven't customized anything), would see * local branches stay lime * remote branch prefixes stay pale orange (they don't change to light brown because the pale orange color from master is stored in their configuration file) * remote branch names change from lime to brown (because the `remoterefbgcolor` configuration setting didn't exist before) Patch 12 introduces remoterefbgcolor, with a specific default value. Prior to that, the "ref part" of remote refs was rendered with headbgcolor. Users who changed their headbgcolor are used to seeing the "ref part" of remote refs in the same color as their local heads. Applying patch 12 changes the "ref part" color of remote refs, for such users. All I'm saying is that make the remoterefbgcolor default be $headbgcolor avoids this. For somebody who thinks that most people will want local and remote-tracking branch names to be rendered in the same color, your suggestion would be an improvement. But for somebody like me who thinks it is a good idea to render remote-tracking branch names in a different color than local branch names, this is a feature, not a bug. Even a user who explicitly configured `headbgcolor` to, say, purple, wasn't necessarily expressing a wish to have remote-tracking branch names rendered in purple. Until now they had no choice to set these colors separately! So even for somebody who configured this setting before, I think that having the remote-tracking branch names change color when the user upgrades to this version is a good thing, because it lets the user know that these two things can now be colored independently. If they don't like the new default brown color, such a user knows where to change it (even to make it agree with `headbgcolor` if they want that). But I understand that this is a matter of personal preference. I have but one "vote" :-) I think we understand each other, and that we disagree. I don't feel strongly about it though, so if you want to go this way that's fine by me. Your case would be helped if the various ref colours were exposed in the preferences dialog. Someone who upgrades to your gitk and doesn't like the default remoterefbgcolor has to track down the right setting, close all running gitk instances, and hand-edit ~/.gitk. But I think improving gitk's colour-preferences dialog is a bit beyond the scope of your topic... M.
Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
On 12/21/2016 08:07 PM, Marc Branchaud wrote: > On 2016-12-20 07:05 PM, Michael Haggerty wrote: >> On 12/20/2016 04:01 PM, Marc Branchaud wrote: >>> [...] >>> Please don't change the remotebgcolor default. >>> >>> Also, perhaps the default remoterefbgcolor should be >>> set remoterefbgcolor $headbgcolor >>> ? >>> >>> I say this because when I applied the series, without the last patch, I >>> was miffed that the remote/ref colour had changed. >> >> This is a one-time inconvenience that gitk developers will experience. I >> doubt that users jump backwards and forwards in gitk versions very often. > > In what way do you mean it's restricted to gitk developers? Maybe I misunderstood your objection. While developing this, I realized that the very first time your run gitk (i.e., when you don't already have a configuration file), it writes the then-current default colors into your configuration file. If you later switch gitk versions to a version with different default colors, the colors from the first-run version are preserved (unless the names of the variables used to hold the colors are changed). So if you would run the tip version of my branch first, then the parent of that version, you would continue to see the colors as modified by the final commit. If you then switch to the master version, the remote branch names go back to green (because it goes back to using `headbgcolor` again), but the remote prefix stays light brown. I thought you were unhappy about some form of this unexpected persistence problem. But this problem will mostly be experienced by gitk developers who jump back and forth between versions. A normal user probably mostly moves forward through version numbers, and only occasionally. Such a user, jumping from master to the tip of my branch (assuming they haven't customized anything), would see * local branches stay lime * remote branch prefixes stay pale orange (they don't change to light brown because the pale orange color from master is stored in their configuration file) * remote branch names change from lime to brown (because the `remoterefbgcolor` configuration setting didn't exist before) > Patch 12 introduces remoterefbgcolor, with a specific default value. > Prior to that, the "ref part" of remote refs was rendered with > headbgcolor. Users who changed their headbgcolor are used to seeing the > "ref part" of remote refs in the same color as their local heads. > Applying patch 12 changes the "ref part" color of remote refs, for such > users. > > All I'm saying is that make the remoterefbgcolor default be $headbgcolor > avoids this. For somebody who thinks that most people will want local and remote-tracking branch names to be rendered in the same color, your suggestion would be an improvement. But for somebody like me who thinks it is a good idea to render remote-tracking branch names in a different color than local branch names, this is a feature, not a bug. Even a user who explicitly configured `headbgcolor` to, say, purple, wasn't necessarily expressing a wish to have remote-tracking branch names rendered in purple. Until now they had no choice to set these colors separately! So even for somebody who configured this setting before, I think that having the remote-tracking branch names change color when the user upgrades to this version is a good thing, because it lets the user know that these two things can now be colored independently. If they don't like the new default brown color, such a user knows where to change it (even to make it agree with `headbgcolor` if they want that). But I understand that this is a matter of personal preference. I have but one "vote" :-) Michael
Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
On 2016-12-20 07:05 PM, Michael Haggerty wrote: On 12/20/2016 04:01 PM, Marc Branchaud wrote: On 2016-12-19 11:44 AM, Michael Haggerty wrote: This patch series changes a bunch of details about how remote-tracking references are rendered in the commit list of gitk: Thanks for this! I like the new, compact look very much! That said, I remember when I was a new git user and I leaned heavily on gitk to understand how references worked. It was particularly illuminating to see the remote references distinctly labeled, and the fact that they were "remotes/origin/foo" gave me an Aha! moment where I came to understand that the refs hierarchy is more flexible than just the conventions coded into git itself. I eventually felt free to create my own, private ref hierarchies. I am in no way opposed to this series. I just wanted to point out that there was some utility in those labels. It makes me think that it might be worthwhile for gitk to have a "raw-refs" mode, that shows the full "refs/foo/bar/baz" paths of all the heads, tags, and whatever else. It could be a useful teaching tool for git. Yes, I understand that the longer names might be useful for beginners, and the full names even more so. However, I think once a user has that "aha!" moment, the space wasted on all the redundant words is a real impediment to gitk's usability. It is common to have a few references on a single commit (especially if you pull from multiple remotes), in which case the summary line is completely invisible (and therefore its context menu is unreachable). I don't like the idea of dumbing down the UI permanently based on what users need at the very beginning of their Git usage. I agree. Would it be possible to use the short names in the UI but to add the full names to a tooltip or to the context menu? I don't know -- my Tk-fu is weak. * Omit the "remote/" prefix on normal remote-tracking references. They If you re-roll, s:remote/:remotes/:. Thanks. are already distinguished via their two-tone rendering and (usually) longer names, and this change saves a lot of visual clutter and horizontal space. * Render remote-tracking references that have more than the usual three slashes like origin/foo/bar ^^^ rather than origin/foo/bar (formerly remotes/origin/foo/bar) ^^^ ^^^ , where the indicated part is the prefix that is rendered in a different color. Usually, such a reference represents a remote branch that contains a slash in its name, so the new split more accurately portrays the separation between remote name and remote branch name. *Love* this change! :) * Introduce a separate constant to specify the background color used for the branch name part of remote-tracking references, to allow it to differ from the color used for local branches (which by default is bright green). * Change the default background colors for remote-tracking branches to light brown and brown (formerly they were pale orange and bright green). Please don't change the remotebgcolor default. Also, perhaps the default remoterefbgcolor should be set remoterefbgcolor $headbgcolor ? I say this because when I applied the series, without the last patch, I was miffed that the remote/ref colour had changed. This is a one-time inconvenience that gitk developers will experience. I doubt that users jump backwards and forwards in gitk versions very often. In what way do you mean it's restricted to gitk developers? Patch 12 introduces remoterefbgcolor, with a specific default value. Prior to that, the "ref part" of remote refs was rendered with headbgcolor. Users who changed their headbgcolor are used to seeing the "ref part" of remote refs in the same color as their local heads. Applying patch 12 changes the "ref part" color of remote refs, for such users. All I'm saying is that make the remoterefbgcolor default be $headbgcolor avoids this. But, honestly, I don't feel strongly about it. M.
Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
On 12/20/2016 04:01 PM, Marc Branchaud wrote: > On 2016-12-19 11:44 AM, Michael Haggerty wrote: >> This patch series changes a bunch of details about how remote-tracking >> references are rendered in the commit list of gitk: > > Thanks for this! I like the new, compact look very much! > > That said, I remember when I was a new git user and I leaned heavily on > gitk to understand how references worked. It was particularly > illuminating to see the remote references distinctly labeled, and the > fact that they were "remotes/origin/foo" gave me an Aha! moment where I > came to understand that the refs hierarchy is more flexible than just > the conventions coded into git itself. I eventually felt free to create > my own, private ref hierarchies. > > I am in no way opposed to this series. I just wanted to point out that > there was some utility in those labels. It makes me think that it might > be worthwhile for gitk to have a "raw-refs" mode, that shows the full > "refs/foo/bar/baz" paths of all the heads, tags, and whatever else. It > could be a useful teaching tool for git. Yes, I understand that the longer names might be useful for beginners, and the full names even more so. However, I think once a user has that "aha!" moment, the space wasted on all the redundant words is a real impediment to gitk's usability. It is common to have a few references on a single commit (especially if you pull from multiple remotes), in which case the summary line is completely invisible (and therefore its context menu is unreachable). I don't like the idea of dumbing down the UI permanently based on what users need at the very beginning of their Git usage. Would it be possible to use the short names in the UI but to add the full names to a tooltip or to the context menu? >> * Omit the "remote/" prefix on normal remote-tracking references. They > > If you re-roll, s:remote/:remotes/:. Thanks. >> are already distinguished via their two-tone rendering and (usually) >> longer names, and this change saves a lot of visual clutter and >> horizontal space. >> >> * Render remote-tracking references that have more than the usual >> three slashes like >> >> origin/foo/bar >> ^^^ >> >> rather than >> >> origin/foo/bar (formerly remotes/origin/foo/bar) >> ^^^ ^^^ >> >> , where the indicated part is the prefix that is rendered in a >> different color. Usually, such a reference represents a remote >> branch that contains a slash in its name, so the new split more >> accurately portrays the separation between remote name and remote >> branch name. > > *Love* this change! :) > >> * Introduce a separate constant to specify the background color used >> for the branch name part of remote-tracking references, to allow it >> to differ from the color used for local branches (which by default >> is bright green). >> >> * Change the default background colors for remote-tracking branches to >> light brown and brown (formerly they were pale orange and bright >> green). > > Please don't change the remotebgcolor default. > > Also, perhaps the default remoterefbgcolor should be > set remoterefbgcolor $headbgcolor > ? > > I say this because when I applied the series, without the last patch, I > was miffed that the remote/ref colour had changed. This is a one-time inconvenience that gitk developers will experience. I doubt that users jump backwards and forwards in gitk versions very often. I do find it strange that gitk writes a color selection to its configuration file *even if the user has left it at its default*. Normally I would expect only user-changed settings to be written to the config file, and other values to use the default that is built into the program. For example, such an approach would have made the transition from "green" to "lime" easier. > [...] Thanks for your feedback! Michael
Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
On 2016-12-20 05:17 PM, Paul Mackerras wrote: On Tue, Dec 20, 2016 at 10:01:15AM -0500, Marc Branchaud wrote: On 2016-12-19 11:44 AM, Michael Haggerty wrote: This patch series changes a bunch of details about how remote-tracking references are rendered in the commit list of gitk: Thanks for this! I like the new, compact look very much! That said, I remember when I was a new git user and I leaned heavily on gitk to understand how references worked. It was particularly illuminating to see the remote references distinctly labeled, and the fact that they were "remotes/origin/foo" gave me an Aha! moment where I came to understand that the refs hierarchy is more flexible than just the conventions coded into git itself. I eventually felt free to create my own, private ref hierarchies. I am in no way opposed to this series. I just wanted to point out that there was some utility in those labels. It makes me think that it might be worthwhile for gitk to have a "raw-refs" mode, that shows the full "refs/foo/bar/baz" paths of all the heads, tags, and whatever else. It could be a useful teaching tool for git. Do you think we should have a checkbox in the preferences dialog to select whether to display the long form or the short form? Mmmm, more knobs! No, I don't think that's necessary. Such a setting would probably just confuse people. Plus it's not something anyone is likely to want to change anyway. Maybe if there were an "Advanced" tab in the settings dialog, but even then it seems like overkill. I suspect there are better ways to teach people about the refs hierarchy than cluttering up gitk. These may even already exist -- I've been a git user for 8 years now, so I'm sure my perspective of the learning curve is skewed. M.
Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
On Tue, Dec 20, 2016 at 10:01:15AM -0500, Marc Branchaud wrote: > On 2016-12-19 11:44 AM, Michael Haggerty wrote: > >This patch series changes a bunch of details about how remote-tracking > >references are rendered in the commit list of gitk: > > Thanks for this! I like the new, compact look very much! > > That said, I remember when I was a new git user and I leaned heavily on gitk > to understand how references worked. It was particularly illuminating to > see the remote references distinctly labeled, and the fact that they were > "remotes/origin/foo" gave me an Aha! moment where I came to understand that > the refs hierarchy is more flexible than just the conventions coded into git > itself. I eventually felt free to create my own, private ref hierarchies. > > I am in no way opposed to this series. I just wanted to point out that > there was some utility in those labels. It makes me think that it might be > worthwhile for gitk to have a "raw-refs" mode, that shows the full > "refs/foo/bar/baz" paths of all the heads, tags, and whatever else. It > could be a useful teaching tool for git. Do you think we should have a checkbox in the preferences dialog to select whether to display the long form or the short form? Paul.
Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
On 2016-12-19 11:44 AM, Michael Haggerty wrote: This patch series changes a bunch of details about how remote-tracking references are rendered in the commit list of gitk: Thanks for this! I like the new, compact look very much! That said, I remember when I was a new git user and I leaned heavily on gitk to understand how references worked. It was particularly illuminating to see the remote references distinctly labeled, and the fact that they were "remotes/origin/foo" gave me an Aha! moment where I came to understand that the refs hierarchy is more flexible than just the conventions coded into git itself. I eventually felt free to create my own, private ref hierarchies. I am in no way opposed to this series. I just wanted to point out that there was some utility in those labels. It makes me think that it might be worthwhile for gitk to have a "raw-refs" mode, that shows the full "refs/foo/bar/baz" paths of all the heads, tags, and whatever else. It could be a useful teaching tool for git. * Omit the "remote/" prefix on normal remote-tracking references. They If you re-roll, s:remote/:remotes/:. are already distinguished via their two-tone rendering and (usually) longer names, and this change saves a lot of visual clutter and horizontal space. * Render remote-tracking references that have more than the usual three slashes like origin/foo/bar ^^^ rather than origin/foo/bar (formerly remotes/origin/foo/bar) ^^^ ^^^ , where the indicated part is the prefix that is rendered in a different color. Usually, such a reference represents a remote branch that contains a slash in its name, so the new split more accurately portrays the separation between remote name and remote branch name. *Love* this change! :) * Introduce a separate constant to specify the background color used for the branch name part of remote-tracking references, to allow it to differ from the color used for local branches (which by default is bright green). * Change the default background colors for remote-tracking branches to light brown and brown (formerly they were pale orange and bright green). Please don't change the remotebgcolor default. Also, perhaps the default remoterefbgcolor should be set remoterefbgcolor $headbgcolor ? I say this because when I applied the series, without the last patch, I was miffed that the remote/ref colour had changed. Plus I think there's utility in having local and remote branch names in the same colour, again especially for new users. It helps emphasize their similarities, and demystify some of git's internal magic. M. I understand that the colors of pixels on computer screens is an even more emotional topic that that of bikesheds, so I implemented the last change as a separate commit, the last one in the series. Feel free to drop it if you don't want the default color change. Along the way, I did a bunch of refactoring in the area to make these changes easier, and introduced a constant for the background color of "other" references so that it can also be adjusted by users. (Unfortunately, these colors can only be adjusted by editing the configuration file. Someday it would be nice to allow them to be configured via the preferences dialog.) It's been a while since I've written any Tcl code, so I apologize in advance for any howlers :-) This branch applies against the `master` branch in git://ozlabs.org/~paulus/gitk. Michael Michael Haggerty (13): gitk: when processing tag labels, don't use `marks` as scratch space gitk: keep track of tag types in a separate `types` array gitk: use a type "tags" to indicate abbreviated tags gitk: use a type "mainhead" to indicate the main HEAD branch gitk: fill in `wvals` as the tags are first processed gitk: simplify regexp gitk: extract a method `remotereftext` gitk: only change the color of the "remote" part of remote refs gitk: shorten labels displayed for modern remote-tracking refs gitk: use type "remote" for remote-tracking references gitk: introduce a constant otherrefbgcolor gitk: add a configuration setting `remoterefbgcolor` gitk: change the default colors for remote-tracking references gitk | 114 --- 1 file changed, 76 insertions(+), 38 deletions(-)
Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
On 12/19/2016 11:53 PM, Philip Oakley wrote: > From: "Michael Haggerty" >> This patch series changes a bunch of details about how remote-tracking >> references are rendered in the commit list of gitk: >> > [...] >> * Introduce a separate constant to specify the background color used >> for the branch name part of remote-tracking references, to allow it >> to differ from the color used for local branches (which by default >> is bright green). >> >> * Change the default background colors for remote-tracking branches to >> light brown and brown (formerly they were pale orange and bright >> green). >> >> I understand that the colors of pixels on computer screens is an even >> more emotional topic that that of bikesheds, so I implemented the last >> change as a separate commit, the last one in the series. Feel free to >> drop it if you don't want the default color change. > > Just to say that there was an issue with the bright green (lime) a while > back when 'green' changed its colour. > > dscho reported in > (https://github.com/git-for-windows/git/issues/300#issuecomment-133702654 > 26 Aug 2015) > > "[T]his is a change in Tk 8.6 described here (http://wiki.tcl.tk/1424): > From > Tcl/Tk 8.6 on, Tk uses Web colours instead of X11 ones, where they > conflict." > > In particular the old bright green version of 'green' became a darker > green, > with the old colour becoming named lime. > > For me, I needed to change my colour scheme (to a lime) as I could not read > the refs against the darker colour. > > Anyway, that's the background as I know it. Thanks for the context. In fact, it was this color change that got me looking at this code in the first place. For anyone still suffering from the "green background of branch labels in gitk got too dark" problem: The default color in gitk was made lighter again in 66db14c "gitk: Color name update", 2015-10-25 But your own configuration might still have "green" written in it, from the days when "green" was still bright. If so, change the value for `headbgcolor` to `lime` in `~/.config/git/gitk`. It would be nice if these colors were adjustable via the "Preferences -> Colors" dialog. Michael
Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
From: "Michael Haggerty" This patch series changes a bunch of details about how remote-tracking references are rendered in the commit list of gitk: [...] * Introduce a separate constant to specify the background color used for the branch name part of remote-tracking references, to allow it to differ from the color used for local branches (which by default is bright green). * Change the default background colors for remote-tracking branches to light brown and brown (formerly they were pale orange and bright green). I understand that the colors of pixels on computer screens is an even more emotional topic that that of bikesheds, so I implemented the last change as a separate commit, the last one in the series. Feel free to drop it if you don't want the default color change. Just to say that there was an issue with the bright green (lime) a while back when 'green' changed its colour. dscho reported in (https://github.com/git-for-windows/git/issues/300#issuecomment-133702654 26 Aug 2015) "[T]his is a change in Tk 8.6 described here (http://wiki.tcl.tk/1424): From Tcl/Tk 8.6 on, Tk uses Web colours instead of X11 ones, where they conflict." In particular the old bright green version of 'green' became a darker green, with the old colour becoming named lime. For me, I needed to change my colour scheme (to a lime) as I could not read the refs against the darker colour. Anyway, that's the background as I know it. -- Philip
