Consider making wormc a thinner client

[lambdadog]

I imagine this will only ever pop up when developing on worm for most users, but when working on #70 I spent a while attempting to debug why the new config options weren't working, and it was due to my rcfile using my system wormc, rather than ~/devel/worm/wormc.

That said, it would also be of benefit to reduce down configuration to a "single source of truth" -- currently to add a configuration option you:

1. add a new IPC atom in src/atoms.nim
2. add it to the Config type in src/types.nim
3. implement boilerplate for the option in src/wormc.nim
4. implement the setter for the option in src/events/clientmessage.nim
5. and finally, you can actually use the configuration option in your code

You could get rid of 1 and 3 in a single step (as well as what I mention above, avoiding errors from an easy-to-make mistake) by simply having wormc take its input and send it directly to worm which handles it in its entirety.

[codic13]

Certainly not a bad idea, I just did it with regular atoms as that's how it's traditionally done in X11.

[codic13]

The benefit of the current way, however, is that worm itself only accepts well-formed atoms, so there's not much room for the WM itself to crash with a malformed command on some edge case (compared to wormc; I'd much rather have wormc crash than my whole environment)

[lambdadog]

I mean the fact is, worm can crash from wormc calls already. Setting either of the values in button-offset to -1, for example, I believe will crash worm.

That said I feel that it's certainly possible to have robust enough error handling without making things awful -- you could probably factor out a lot of the IPC code in clientmessage.nim then use that extra breathing room to just ensure input is well validated.

[codic12]

I mean the fact is, worm can crash from wormc calls already. Setting either of the values in button-offset to -1, for example, I believe will crash worm.

😬 should get that fixed. I do agree though, I think this might be something useful to look at in the future, but not an immediate priority because it doesn't really affect the user experience.

[insomniacUNDERSCORElemon]

Maybe I'm interpreting this issue wrong, but I'm interested* in making/modifying a really minimalist floating WM and am not seeing of where/how Worm renders the window controls etc w/floating mode. Especially with wm.nim being 1K+ LoC. Is Pixie part of that issue? Or just a side-effect of having more functionality/tweaks?

Technical (more of an X11 thing I guess): could text (for title and panels, best w/opaque outline/shadow) be rendered over other contents (be it the parent window or other windows) without needing compositing? This doesn't seem possible (at least not currently) with XFWM.

*= I don't have Nim "legs" yet (not sure if there's a Nim-specific metaphor. Crown isn't fitted?). Probably over my head (the goal, not the crown). Sorry.

[codic12]

*= I don't have Nim "legs" yet (not sure if there's a Nim-specific metaphor. Crown isn't fitted?). Probably over my head (the goal, not the crown). Sorry.

No idea ;)

I think this is the wrong issue for you, this is about changes to the client used to interact with worm.

The problem with wm.nim being so big is code duplication. Each button takes maybe 10 lines of code to draw + title. There are 3 + title. That's 4 * 10 = 40. There are 3 regions of the titlebar to draw buttons. 40 * 3 = 120. It's really not something I like and I am definitely looking into significantly refactoring that code.however, just look in the renderTop function, and through the mess you will find your answers ;)

Technical (more of an X11 thing I guess): could text (for title and panels, best w/opaque outline/shadow) be rendered over other contents (be it the parent window or other windows) without needing compositing? This doesn't seem possible (at least not currently) with XFWM.

I'm not quite sure what you're asking, but "faux transparency" is certainly possible, and everyone used it about 20 years ago, at a time where many people used software rendering or rather underpowered graphics cards. On X this is easy. Just need to grab the appropriate part of the framebuffer using similar techniques to screenshot tools - eg look at scrot as an example. It is slow to re-render this way when you are moving it around though - but again, not fully sure what you're asking.