-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider making wormc a thinner client #71
Comments
Certainly not a bad idea, I just did it with regular atoms as that's how it's traditionally done in X11. |
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) |
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. |
😬 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. |
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. |
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 ;)
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. |
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:
src/atoms.nim
src/types.nim
src/wormc.nim
src/events/clientmessage.nim
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.
The text was updated successfully, but these errors were encountered: