More robust button rendering/styling

[lambdadog]

For users largely using worm as a floating WM like myself, the button styling and rendering are okay, but not great. Typically I'd like my buttons to change on hover (to indicate that if I click, I will be clicking them and not the space surrounding them) and with everything else having active and inactive coloration, it'd be nice if the buttons could have the same. With the default config's coloration, for example, a black button disappears on a foreground window but looks perfect on a background window.

Some thought needs to be put into how to achieve this however -- ideally you could just give SVG elements a class like worm-fill or worm-stroke and worm could change their colors dynamically, but looking at pixie it doesn't look like this kind of behavior is exposed in any way.

It's still probably technically doable -- just separate out a codepath for SVG files, parse the XML, find all elements with class worm-{fill,stroke}, and set their fill or stroke value or whatever the case may be to the selected color, then render back to text and pass to decodeSvg -- but it wouldn't be particularly clean.

Perhaps worth looking into upstream contributions to pixie's SVG support? SVGs in the browser support styling, with CSS being able to set certain values (including fill and stroke), but since Pixie isn't a browser it does seem like there possibly ought to be a way to pass styles in when rendering an SVG that's not CSS.

[codic12]

I think the easiest way, because there is also support for non-SVG formats, would be to just add parameters (wormc-close-hover-path, etc)

[lambdadog]

It feels like that would be a bit of a parameter explosion, but that would likely be simplest.

[codic12]

notes to myself: I think the easiest way to implement this is just to check MotionNotify events. Keep an array storing the coordinates of the four points (relative to the root window; this should be very easy to calculate by using the x / y properties relative to the parent frame,
and then add the size of the parent frame and it's y-offset; then simply calculate the other 3 points as shown in diagram) that make up squares, which worm buttons are located in, cached. When you get a new motionnotify, simply check if the x and y coordinates are within those 4 points.

[codic12]

f436318 lays the foundation for this.

[codic12]

maybe it isn't so easy... ;)

[codic12]

Little kinks to work out and a lil' bit more testing to do, but seems to work just fine, nice. (the weird not properly rounded circle is not because of worm, but rather because I quickly opened it up in gimp and increased the exposure, which did not like the antialiasing on an 16x16 image.

also, it is "so easy", I was just going in the wrong direction, it's easier than I expected it to be!

simplescreenrecorder-2022-04-21_23.38.40.mp4

.

[codic12]

Needs some documentation and aliasing the old versions to prevent breakage of existing configs, but otherwise looks to work just fine in c46e61b.