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.