Make colors configurable

[thequux]

As requested by @mrpingo, colors should be configurable.

[mrpingo]

Great!!

I like those colors and the gradient that match perfectly with my light&blue theme, but I switch to a black&red when the light allows. So changing color palette wile keeping the gradient would be fantastic.

;)

[thequux]

OK, that gives me something to start with. I'm thinking of a theme-based approach, where you define a theme in a file in .config/wattbar/theme-something.conf and use a -t something parameter to pick which theme to use. The theme would look somthing like:

charge  #0088FF
0%  #FF0000
50% #FFFF00
100%    #00FF00

Would this meet your needs?

Also, do you switch themes often enough that you'd need to switch themes at runtime, or would setting parameters once at startup be enough? For the former, I could probably provide a DBus interface, but that'll take at least two weekends.

[mrpingo]

That would suit all my needs.

I switch themes depending on light intensity and temperature of that light, so yes I switch a couple of times by day. What I am doing now is launching a script with a keybind that kills xbattbar with the one theme palette and start another instance with another palette, pretty simple.

So dont bother for now with dbus. I can do "ln -s dark|light.config_theme config_file" and start wattbar -c ~/.config/wattbar/config_file for example as I used to do with other theme programs.

To be totally versatile with all the possibilities and all the themes I think it would need 3 more variables, one to set the charge, discharge and no charge backgroud color so it match when is charging, no charging (I can stop charging the battery at for example 55% to taking care of it) and discharging (but those three should be static?).

charge      #0088FF
charge_bg   #002288
nocharge_bg #888800
discharging_bg  #444400
0%      #FF0000
50%     #FFFF00
100%        #00FF00

[thequux]

I really like the background color being a darker version of the foreground color, so that's a possibility that we'd need to maintain.

I suppose that, for full generality, we could do something like

[charging]
0%  #0088FF #002288

[discharging]
0%  #FF0000 #444400
50% #FFFF00 #440000
100%    #00FF00 #440000

[nocharge]
0%  #888800

The first hex code on each line is the foreground color, and the second is the background. If the background isn't specified, it defaults to the foreground color at half-brightness.

BTW, to make sure that I understand how UPower reports the status of your battery when it stops charging, could you send the output of the following command?

gdbus introspect -y -d org.freedesktop.UPower -o /org/freedesktop/UPower/devices/DisplayDevice -p

There shouldn't be anything sensitive in the output, but if you're concerned, you can email it to <my username>@<my username>.com.

[mrpingo]

Here!

Not charging and not discharging:

node /org/freedesktop/UPower/devices/DisplayDevice {
  interface org.freedesktop.UPower.Device {
    properties:
      readonly s NativePath = '';
      readonly s Vendor = '';
      readonly s Model = '';
      readonly s Serial = '';
      readonly t UpdateTime = 1714941897;
      readonly u Type = 2;
      readonly b PowerSupply = true;
      readonly b HasHistory = false;
      readonly b HasStatistics = false;
      readonly b Online = false;
      readonly d Energy = 27.629999999999999;
      readonly d EnergyEmpty = 0.0;
      readonly d EnergyFull = 46.5;
      readonly d EnergyFullDesign = 0.0;
      readonly d EnergyRate = 0.0067570975417502238;
      readonly d Voltage = 0.0;
      readonly i ChargeCycles = 0;
      readonly d Luminosity = 0.0;
      readonly x TimeToEmpty = 0;
      readonly x TimeToFull = 0;
      readonly d Percentage = 59.0;
      readonly d Temperature = 0.0;
      readonly b IsPresent = true;
      readonly u State = 5;
      readonly b IsRechargeable = false;
      readonly d Capacity = 0.0;
      readonly u Technology = 0;
      readonly u WarningLevel = 1;
      readonly u BatteryLevel = 1;
      readonly s IconName = 'battery-good-charging-symbolic';
  };
};

Discharging:

node /org/freedesktop/UPower/devices/DisplayDevice {
  interface org.freedesktop.UPower.Device {
    properties:
      readonly s NativePath = '';
      readonly s Vendor = '';
      readonly s Model = '';
      readonly s Serial = '';
      readonly t UpdateTime = 1714945385;
      readonly u Type = 2;
      readonly b PowerSupply = true;
      readonly b HasHistory = false;
      readonly b HasStatistics = false;
      readonly b Online = false;
      readonly d Energy = 27.620000000000001;
      readonly d EnergyEmpty = 0.0;
      readonly d EnergyFull = 46.5;
      readonly d EnergyFullDesign = 0.0;
      readonly d EnergyRate = 0.55200000000000005;
      readonly d Voltage = 0.0;
      readonly i ChargeCycles = 0;
      readonly d Luminosity = 0.0;
      readonly x TimeToEmpty = 180130;
      readonly x TimeToFull = 0;
      readonly d Percentage = 59.0;
      readonly d Temperature = 0.0;
      readonly b IsPresent = true;
      readonly u State = 2;
      readonly b IsRechargeable = false;
      readonly d Capacity = 0.0;
      readonly u Technology = 0;
      readonly u WarningLevel = 1;
      readonly u BatteryLevel = 1;
      readonly s IconName = 'battery-good-symbolic';
  };
};

I like too, and the background to be a darker version of the color as you said, so nocharge background would be a darker version of the nocharge color? I would appreciate to set it myself so I calibrate the bright of the background and I would need that nocharge background variable. Or I missunderstood you and you set it by another variable like the charging/discharging background?

[thequux]

Indeed, all of the points along the gradient would have an optional background color. If you include it, it's used as is. If you don't, it defaults to the foreground color darkened by 50%.

I also realized that, thanks to Servo, Rust has a nice library for parsing CSS colors, and the library I'm using for color calculations can easily do the conversions between color spaces. I'm already doing the calculations in OkLab anyway, so supporting HSV colors is trivial. This also implies that, once Wayland supports color spaces other than sRGB (HDR, anyone?) it'll be quite a small change to support them.

Also, because wayland is awesome like that, it's almost no work at all to support transparency. I just checked; if I include an alpha channel, the bar is partially transparent. I have my doubts on whether that's desired, but considering that it's literally a single line of code to support properly, I see no reason why not.

[mrpingo]

Those are great news. Transparency will become in handy for example when you fullscreen a program that perhaps you want to be wattbar in overlay but don't want to saturate totally the background like in movies. I missed it in xbattbar for example.

Another thing to improve is to launch wattbar just for one monitor or both independently (clone) if you have an external one, so if you restart wattbar doesn't fill the sum of the length provided by both outputs, what is really annoying.

Just brainstorming here. :)

[thequux]

It should put one bar per display. This used to be irritating with X, because the Xinerama extension treated your entire desktop as one giant rectangle and made each output a viewport into that rectangle (which was a massive improvement on the original concept of multiple screens; you opened up a window on a particular screen and that's where it would stay forevermore). I made an attempt at supporting multiple desktops correctly in xbattbar3, but gave it up as too much of a hassle.

Wayland, on the other hand, has native support for multiple displays, and so the easiest approach is the correct one :-D

In other news, I just pushed a commit with theming support. It uses precisely the syntax we came up with, except that you can use CSS color syntax in addition to just #RRGGBB (e.g., hsl(120deg 100% 50%))

Give it a try and send me your theme when you've got one you like. I'll include it in the source tree (if you're comfortable licensing it under the MIT license, that is)

[mrpingo]

I have just one word: "A-MA-ZING"

This is everything I wanted. Simple, but smart and ultracustomizable. You can now add flourishes, animations, whatever.. this is just that beautiful that I have been spending all the afternoon playing with colors like a painter. Now everything match, is native, is smart, as it should always be.

My themes are not finished because I couldnt play too much with it yet and this opens up so many posibilities that I need to try them all so it would take some time to polish them while using the battery, but as you requested, am narrowing them to:

Blue-ish Light theme:

[charging]
0%  #0000FF
25% #000044 #555588
50% #000044 #EEEEFF
100%    #0000FF #FFDDFF

[discharging]
0%  #000044 #0000FF
25% #FFFF00 #8888AA
50% #000044
100%    #0000FF

[nocharge]
0%  #000044 #EEEEFF

Red-ish Dark theme:

[charging]
0%  #FF00FF #220022
25% #FFFF00 #880088
50% #FF0000 #880000
100%    #FF00FF #880088

[discharging]
0%  #440000 #110011
25% #FFFF00 #880000
50% #FF0000
100%    #FF00FF

[nocharge]
0%  #AA0000 #440000

You nailed and made me very happy and I really appreciate very much your effort.

A last comment: I dont have to kill the bar and relaunch when I rotate my laptop (the output rotates) in tablet mode. Is this the nirvana or just wayland? x_x

Uninstalling xbattbar in 3, 2, 1...

Thanks!

[thequux]

I have just one word: "A-MA-ZING"

Excellent! I'm glad you like it; hearing praise from users is part of what keeps maintainers like me releasing our stuff as open source.

A last comment: I dont have to kill the bar and relaunch when I rotate my laptop (the output rotates) in tablet mode. Is this the nirvana or just wayland? x_x

That works? O_O

After trying it, it only partially works: I don't take the screen rotation into consideration when calculating the bar's width, so you only see the middle of the bar. No worries, that should be easy enough to fix; I just didn't consider that case when writing the code. I'll fix it before the 1.0 release, which I'm aiming for Sunday or so (though it might slip to next weekend)

it would take some time to polish them while using the battery

You may find my super-secret debugging flag useful... if you pass the command line flag --mock-upower it pretends to charge over the course of 5 seconds or so, but always reports that it's discharging. So, you can quickly see how a particular gradient effect works.

BTW, if you'd like to contribute, I could use some help writing documentation; an explanation of the theme format and command line flags in the README or in a separate documentation.md file would be outstanding.

[mrpingo]

You are right. After taking a second look I saw that the bar was not dynamically resized and is truncated by the "new" width as you mentioned.

You may find my super-secret debugging flag useful... if you pass the command line flag --mock-upower it pretends to charge over the course of 5 seconds or so, but always reports that it's discharging. So, you can quickly see how a particular gradient effect works.

Aha! You may consider to publish publicly your super-secret debugging flag to try out the theme before setting it up. Also consider to do the charge version of it for completeness.

BTW, if you'd like to contribute, I could use some help writing documentation; an explanation of the theme format and command line flags in the README or in a separate documentation.md file would be outstanding.

I am glad you asked. I will do both if you like, but I need to settle up some real life thing before, that it would take one week or so. I will work on it on batches as I am having spare time. Also I might have some questions regarding the procedure since I never worked with git before (but I am willing to learn). Also I want to bring your project to Gentoo repos by writing an ebuild so the community can take advantage of it if you are ok with it.