[HN Gopher] RubyWM - an X11 window manager in pure Ruby
___________________________________________________________________
RubyWM - an X11 window manager in pure Ruby
Author : unripe_syntax
Score : 212 points
Date : 2024-01-22 08:51 UTC (14 hours ago)
(HTM) web link (rubyflow.com)
(TXT) w3m dump (rubyflow.com)
| vidarh wrote:
| Hah. I didn't think this was quite HN worthy at this point - the
| code is still a mess, and has plenty of bugs.
|
| It is however the wm I actually _use_ since I got frustrated with
| bspwm and did a _very_ minimalist rewrite of TinyWM [1] in Ruby
| [2] and expanded it from there. It was painful the first few days
| until I 'd had time to add multiple desktops and the start of a
| tiling mode. But at this point, it's "almost" pleasant _for me_.
|
| The warnings are real, though, apart from the initial hyperbole -
| this _is_ likely to break for you in all kinds of horrible ways
| still.
|
| [EDIT2: As for a real example of the ways it can/will break:
| Right now, for some reason, after a restart without changing a
| single line, it's failing to grab super+buttons to move/resize
| windows; it doesn't really _matter_ as I have keybindings for it
| and mostly use those, but, yeah, I 'm doing something wrong
| _somewhere_ and last time this happened the problem just went
| away by itself]
|
| I use _very_ few applications beyond (my own) terminal, (my own)
| polybar replacement, (my own) file manager, and a browser, and so
| once Chrome and my own apps mostly started working ok I 've had
| very little incentive to make sure it behaves nicely with
| anything else and I _know_ the distinction between different EWMH
| window types is incomplete and broken - just not in ways that
| usually affect my own use.
|
| EDIT: Also a couple of quick notes on "design choices" to the
| extent this has been "designed" rather than accreted: As you can
| see in e.g. desktop.rb, quite a few places I've chosen to query
| and filter the top-level WindowManager class for a list of
| windows matching a given set of criteria. I did that on an
| experimental basis out of the idea that it was a waste of time to
| track precise state across multiple objects given that the total
| set of windows will always remain "small".
|
| So the Window objects know the bare minimum state of the
| underlying X11 window that it _needs_ to track, and the
| WindowManager class knows how to map an X11 window id to a Window
| object.
|
| Other than that I _avoid tracking state_ as much as possible, and
| even where I track state I try to avoid the need for full
| precision.
|
| The one other place I _must_ track state is the layout classes.
| Currently, only the basic tiling layout, which keeps a tree (that
| is currently a binary tree, but the array of nodes is there
| because I at one point thought I might allow more nodes) where
| the leaves keep track of which nodes have a defined place in the
| layout.
|
| But even there, on updating the layout, I then crudely diff the
| currently known set of windows vs. the set of windows the layout
| believes are present and remove/add as needed.
|
| I make a best effort to place new windows on map requests, but if
| anything breaks for any reason, the layout will "catch" up
| automatically and new windows will be placed. Given I use this
| daily while it is in flux and often broken because I've made a
| change and is testing it "live" on my desktop, this has turned
| out to be very helpful on occasion.
|
| I can't make up my mind if this method (of constantly querying
| for attributes of every window) is a crude hack or quite elegant,
| but it works.
|
| Many other things are not "designed". This is mostly very far
| from a good example of how to actually do things. E.g.
| "find_closest" used to pick a window to move to when you want to
| move directionally in a tiling layout is pretty much guaranteed
| to be possible to do much better with fewer lines of code once I
| actually get around to sitting down and thinking about it - the
| current version was cobbled together in a hurry because I was
| tired of not having the functionality and it "mostly works" as
| expected even though it's stupid.
|
| [1] https://github.com/mackstann/tinywm/blob/master/tinywm.c
|
| [2]
| https://gist.github.com/vidarh/1cdbfcdf3cfd8d25a247243963e55...
| yxhuvud wrote:
| I raise with a wayland client in crystal:
| https://github.com/yxhuvud/wayland_client
|
| Very basic though, you'd have to provide your own functionality
| to print any text..
| vidarh wrote:
| I see C in there; that's cheating ;) (my WM uses a pure-Ruby
| X11 client library - there are no external C dependencies
| other than those of the Ruby implementation itself).
|
| Though I sympathise - the sheer amount of effort to work with
| these, be it X11 or Wayland, is really annoying; the pure
| Ruby X11 gem I use is more lines of code than the window
| manager itself...
| yxhuvud wrote:
| Yeah, I link against C libs because reimplementing the
| protocol seemed like a pain in the ass. The prevailing
| strategy seems to be to generate code based on XML protocol
| specs, and I'd prefer to avoid that crap. That would
| probably be less painful in Ruby as then the code could
| just be generated at runtime based on the XML.
|
| Also since all the prepackaged wayland libs are heavy users
| of functions declared as `static inline` I have to create
| shims for those as they are not linkable. That part is a
| pain in the ass but pretty simple to resolve :)
|
| And yeah, there is so much to set up just to get a bare
| minimum going. I guess that would be true in X11 too.
| vidarh wrote:
| Oh, I absolutely don't judge you for those. Frankly part
| of the reason I went for a pure Ruby version instead of
| xlib was that the Xlib bindings for Ruby are _also_ in an
| awful state, and someone else had done enough of the job
| on the pure Ruby bindings that it felt like it was doable
| incrementally as I needed various calls and not much
| worse than wrapping Xlib or xcb.
|
| I like that there are no other dependencies, but I'd have
| sacrificed that if it was sufficiently much easier than
| the route I ended up taking (e.g. my terminal did start
| out linking to Xlib and using a tiny C extension; it's
| since been ripped out in favour of the pure Ruby
| bindings, since why not now that it's available, but it
| was a perfectly ok solution to start with).
| nixpulvis wrote:
| Parsing all those XML specs at runtime seems really slow
| and wasteful, surely this there's a better way, no?
| bendhoefs wrote:
| The code generation is certainly a build step. This kind
| of code generation is common for interfaces defined
| outside of a project's programming language.
| roenxi wrote:
| Could we please have a comment about why this is an X11 WM
| rather than a Wayland compositor? Technical issues or a
| stylistic choice?
| p_l wrote:
| Outside of any personal preferences of author, Wayland
| compositors are just more complex. Even with availability of
| libraries like wlroots.
|
| After all, a Wayland WM is not just a WM, it also has to run
| and handle display server including talking with HW if you
| want any sensible performance.
| kaba0 wrote:
| Because a window manager on X is roughly the equivalent of
| a Gnome extension. That's just a design question where we
| draw boundaries.
| vidarh wrote:
| It's an interesting question...
|
| Writing a Wayland compositor from scratch means writing the
| whole display server. Wlroots readme describes it as "about
| 60,000 lines of code you were going to write anyway".
|
| For comparison my wm is <1k lines.
|
| So they're not equivalent - writing a Wayland compositor from
| scratch is more like writing the whole X server first, before
| even starting the WM.
|
| I could use wlroots or another compositor as a starting
| point. I did look at it, but I'm still on X, and have no
| compelling reason to switch. Yet, anyway, and that adds to
| the "cost" for me in terms of disruption.
|
| Where I could translate TinyWM into a few dozen lines of Ruby
| in a couple of hours and switch to actually using it and
| build from there, and "just" suffer some nuisance that I can
| slowly chip away at when I have time, even getting a basic
| wlroots binding + minimal compositor running seemed like a
| far more complex project.
|
| I'm itching to figure out how to eat my way further down the
| stack, but I can't justify spending time on it unless I see a
| viable way of doing it (relatively) piecemeal.
|
| E.g. I can restart my wm without exiting my X session, and so
| without losing any open applications. That gets far more
| disruptive for replacing the X server (whether by another X
| server or a Wayland compositor), and also allows for a far
| faster cycle - I can spot a problem, fix it, restart the WM
| and keep working without having to close everything...
|
| I think _if_ I was to do a Waylabd compositor, a first step
| would be to put things like window management beyond an IPC
| boundary, just like with X.
| yxhuvud wrote:
| > I think if I was to do a Waylabd compositor, a first step
| would be to put things like window management beyond an IPC
| boundary, just like with X.
|
| Isn't that already the case, by protocol definition? At
| least compositor and clients talk to each other over a pipe
| of some sort. It is actually a bit problematic because the
| way it is done put noticeable restrictions on both sides on
| processing things in time, because if it is full then shit
| hit the fan.
| vidarh wrote:
| Not in Wayland, no. The only boundary is between the
| client and compositor. With X there is a boundary between
| the client and server, and between the server, wm, and
| compositor.
|
| With Wayland the compositor serves the same function as
| both the X server, wm, and compositor in one. There's
| nothing inherent stopping the addition of extensions to
| allow the same split as in X (but the server/compositor
| split probably wouldn't be worth keeping - the WM is
| easier to split out because it's far less latency
| sensitive)
| kaba0 wrote:
| That's not true in this respect. This all is just an
| implementation detail, not mandated one way or another by
| Wayland.
| vidarh wrote:
| While it's not mandated, as I pointed out ("There's
| nothing inherent stopping the addition of extensions to
| allow the same split as in X"), I'm not aware of a single
| Wayland compositor for which it isn't true. If there is
| one, I'd love to hear about it.
| markstos wrote:
| TinyWM for wlroots is also less than 1,000 LoC. ( https://g
| ithub.com/swaywm/wlroots/blob/master/tinywl/tinywl.... )
|
| > I can restart my wm without exiting my X session
|
| Sway also has a "reload" feature that preserves all open
| applications.
| vidarh wrote:
| Yikes. This is a great illustration of why I've steered
| clear of Wayland, when even _with_ wlroots you end up
| with that much code to do that little.
|
| TinyWM for X is 50 lines.
|
| > Sway also has a "reload" feature that preserves all
| open applications.
|
| As far as I understand, sway's reload just reloads the
| configuration. If Sway crashes, or you kill Sway's
| process, there's nothing left holding the sockets to the
| clients open, or managing the display - that's equivalent
| to killing the X server, not the wm.
|
| With an X wm, as long as your x session isn't set up to
| quit when the wm quits, you can brutally shut down the
| wm, or it can crash, and the windows stay open, and you
| can restart your wm - or start another wm entirely -
| without losing any windows.
| yjftsjthsd-h wrote:
| FWIW, there is some effort to let QT applications survive
| compositor crash in a way that would be even more
| resilient than with X11:
| https://www.phoronix.com/news/Qt-Wayland-Compositor-
| Restart
|
| Of course, that's a new feature they're working on, only
| helps QT apps, and requires the toolkit to track state
| (and by the same virtue, looks like it would have worked
| fine with X11 if they wanted to). So this is more of an
| interesting related tidbit rather than a disagreement.
| zokier wrote:
| > I think if I was to do a Waylabd compositor, a first step
| would be to put things like window management beyond an IPC
| boundary, just like with X.
|
| Afaik river does something in that direction
| https://github.com/riverwm/river
|
| > Dynamic layouts generated by external, user-written
| executables. A default rivertile layout generator is
| provided.
|
| > Scriptable configuration and control through a custom
| Wayland protocol and separate riverctl binary implementing
| it.
| vidarh wrote:
| i3wm, bspwm, etc, and many others have provided APIs like
| that "forever". The problem is that they're async and sit
| "besides" or "after" the actual window management.
|
| E.g. one of the things I disliked about bspwm was that
| while I could get a feed of events and act on them, I
| couldn't _intercept_ and modify or reject requests, so
| e.g. when a new window opened, bspwm would place it, and
| issue an event, and before my script could reconfigure
| the window it 'd already be visible, so to get a floating
| desktop the way I wanted I ended up with windows flashing
| up in one location and then moving.
|
| Put another way: The plethora of Wayland compositors is a
| strong demonstration of how these compositors don't give
| sufficient control via their external APIs, or people
| would write window managers for one or more of those
| compositors instead of writing more compositors.
| wiz21c wrote:
| web site looks like a blank page... :-/
| bArray wrote:
| Same, the wayback machine produces this:
| https://web.archive.org/web/20240122090024/https://rubyflow....
|
| Which points to this GitHub:
| https://github.com/vidarh/rubywm/tree/master
|
| I was hoping for some screenshots and I can't seem to find any
| easily. Would appreciate some screenshots/recording of it
| working to get a taste of it!
| vidarh wrote:
| There is _zero_ window decoration other than a 1pixel
| unshaped border, so there 's not actually much to show, but
| here's an example of one of my tiling desktops w/a couple of
| my terminal windows running (one of the windows is st rather
| than my own):
|
| https://m.galaxybound.com/@vidar/111739055121708028
|
| Here is one I did that shows a couple of file manager windows
| and my terminal and desktop switcher on my floating desktop:
|
| https://m.galaxybound.com/@vidar/111799111872848650
| bArray wrote:
| > There is zero window decoration other than a 1pixel
| unshaped border, so there's not actually much to show, but
| here's an example of one of my tiling desktops w/a couple
| of my terminal windows running (one of the windows is st
| rather than my own):
|
| Minimalism usually means fewer problems and bugs, it's not
| a bad thing.
|
| > Here is one I did that shows a couple of file manager
| windows and my terminal and desktop switcher on my floating
| desktop:
|
| Looks quite nice! I would suggest to add a few pictures to
| the GitHub.
| vidarh wrote:
| Well, at this point you get few features but still lots
| of bugs ;) But yes, the minimalism is very much
| intentional - I have no interest in letting it grow all
| that much, and no interest in lots of decoration (I might
| add support for _some_ ; especially inspired by how
| Katriawm does it [1] - it basically just slaps images on
| each side in separate windows - it's high "bang for the
| bucks" in terms of flexibility for very little effort)
|
| > Looks quite nice! I would suggest to add a few pictures
| to the GitHub.
|
| So many keeps asking, so I guess I've have to add some...
|
| [1]
| https://www.uninformativ.de/git/katriawm/file/README.html
| tuyiown wrote:
| This title would perfectly fit in hn 2011 archives
|
| _(after thought edit: I didn 't meant this as a snarky
| dismissal, just a funny observation)_
| vidarh wrote:
| I'll provide plenty more ca. 2011 level Ruby enthusiasm over
| the coming months - I have my editor, terminal, file manager
| and more to get pushed to or updated at Github.. :)
| aidog wrote:
| Great to hear!
|
| I wonder if your ruby compiler project would benefit from the
| now official pure ruby parser? [1]
|
| [1] https://github.com/yui-knk/lrama
| vidarh wrote:
| My Ruby compiler project has unfortunately been languishing
| for years due to lack of time. I keep hoping to do some
| more on it as I got it to the point where it was self-
| compiling, but it's not very high on my list at the moment
| (my list is _long_ )
|
| That said, lrama is "just" the parser generator, is it not?
| As far as I understand, the Prism parser built using Lrama
| still produces a C library, and requires Ruby's parse.y as
| input, and parse.y alone is twice the size of my entire
| compiler...
|
| Both Lrama and Prism are great projects, and I might've be
| tempted if that was a "missing piece" to turn the compiler
| into something production-ready, but frankly updating the
| parser to handle more modern syntax is the easiest bit of
| what remains. The really big pieces are supporting Regex's
| and floats (Ruby's regexp implementation is roughly the
| size of my entire current compiler...), and a bunch of bug
| fixing. Whether I'll ever find time to get it there or not,
| we'll see.
| aidog wrote:
| Interesting. I see! MRuby (Compilable Ruby for embedded
| systems etc) and Webasm Ruby might be fun areas for
| further projects :)
| vidarh wrote:
| Yeah, I've toyed with Mruby, and it's great. Same
| w/webasm support for Ruby. I think overall the huge
| improvements in the Ruby ecosystem kinda drove my own
| down the priority list - it was mostly educational to
| start with, but the better the various other Ruby
| implementations got the less of an incentive I got to try
| to turn it into anything more than that (and doing so
| would be a massive undertaking). Hitting the "self-
| compiling" milestone felt like it was a decent place to
| pause it, but I'd still love to find time to take it a
| few steps further. At least fixing the most egregious
| bugs (the compiler itself has various temporary
| workarounds for bugs to allow it to compile itself
| without triggering them, and I'm not happy about leaving
| it in a state where I can't at least strip those
| workarounds out).
| ajsnigrutin wrote:
| You can take all those archives, do an 's/Ruby/Rust/g', and you
| get the current news :)
| szundi wrote:
| I love these peculiar projects
| BaculumMeumEst wrote:
| I've been an X11 holdout since forever, but after nvidia
| proprietary drivers broke for the millionth time on a system
| upgrade, I switched over to Nouveau and the "Hyprland" tiling
| compositor on Wayland. It's the only setup that felt worth the
| upgrade to me. Setup was easy, animations are very slick (scroll
| down on the link below for a sample), and I've had no bugs or
| quirks. Highly recommend checking it out if you're bored or
| curious.
|
| https://hyprland.org/
| vidarh wrote:
| It looks great, but to me this is pretty much the opposite of
| what I want _to use_ - the demo video at least is so busy, and
| full of transitions and other distractions.
|
| There was a time I'd absolutely have loved something like that
| (and had _all_ the window effects turned on when the first
| compositors started arriving) and it looks very cool, but other
| than translucency I 've progressively stripped back everything.
|
| I'll never try to compete with something like that on either
| effects or features. I might add some very minor eye candy. But
| that's fine - one of the things I've always loved about the
| Linux/Unix desktop is how you can get everything from the most
| minimalist to the effects-laden, and I've used wm's pretty much
| everywhere on that spectrum myself too over the years.
|
| I sympathise re: drivers - that or the browsers finally
| abandoning X would be the only things that'd give me enough
| reason to switch. But I'd be more likely to switch if I get
| around to scratching the itch of yet another homegrown
| minimalist step down the stack... (I have a weird urge to write
| a Frankencompositor that supports Wayland clients _and_ enough
| to support an out-of-band X11 style window manager and the
| brutally insecure X11 style event snooping and injection;
| partly because it 'd really irritate some Wayland purists - I'm
| resisting that urge for now because it'd be a massive time-
| suck)
| maksut wrote:
| I am eyeing river wm. Because it has pluggable layout manager
| and controller via custom wayland protocols. Which means I
| can implement just those parts in my favourite lang to
| scratch the itch. Kudos to you going for the whole wm :)
| vidarh wrote:
| An X11 wm is childs play compared to a Wayland compositor.
| I have been eyeing River and various other Wayland options
| too, in case I find myself compelled to switch to Wayland
| at some point, but the sheer complexity of the Wayland side
| has held me back.
| bitwize wrote:
| Given that X11 is going away, the server (except for
| Xwayland) is unmaintained, and in a few years modern
| software just won't support it at all... the sooner you
| switch, the better.
| vidarh wrote:
| There are plenty of Wayland compositors that supports X
| backends, so app support for X is moot because 1) most of
| the apps I run are my own - the only thing I really
| depend on is browsers, and 2) once Chrome _and_ Firefox
| abandons X entirely, and _no other browsers based on
| their engines_ supports X, there are options to run them
| with a Wayland compositor with an X backend in "kiosk
| mode" that basically gives them a single window just like
| before.
|
| So that leaves how long I will have a working X server,
| and frankly I suspect I'll have ended up writing a
| display server years before that becomes an issue
| (whether that'll be X or Wayland or a mix, who knows, but
| I doubt I'll be able to resist very long).
|
| It's just not a concern that's anywhere near the top of
| my list (or the top 100 of my list)
| yjftsjthsd-h wrote:
| I go back and forth on this kind of thing; if the better
| option really is EOL, is it better to keep using it until
| it actually breaks, or is it better to take the pain up
| front? I don't have an actual answer in the general case,
| but on the bright side Xorg is still not dead even though
| the pro-Wayland crowd says so at every single
| opportunity; it has a nonzero number of maintainers, gets
| commits on a slow but regular cadence, and appears likely
| to continue working for the forseeable future. If we
| assume for a moment that the X server will really
| actually die when Red Hat stops maintaining it
| (questionable; the BSDs appear more attached to it than
| RH), that _merely_ gives us until the end of RHEL 9
| around 2032, which is far enough away that I feel
| comfortable not worrying about it.
|
| Also, as sibling comment points out, a simple solution
| exists in the form of rootful xwayland; we can keep a
| working X11 environment and just swap out the actual
| rendering layer.
|
| Or put differently: "Given that X11 is going away, the
| server (except for Xwayland) is unmaintained," just isn't
| true, and even if it was it wouldn't necessarily justify
| the claims you make on that basis.
| csdvrx wrote:
| > It looks great, but to me this is pretty much the opposite
| of what I want to use - the demo video at least is so busy,
| and full of transitions and other distractions.
|
| They are optional: you can make them last 100 ms, or just
| remove them.
|
| Such "eyecandy" enable new uses: for example, all my windows
| are full screen, on they own desktop. No titlebar, no nothing
| because that's a waste of space. A quick animation when I
| change desktop helps me keep a mental map.
|
| Also, hyprland great strength is it makes it not just
| possible but very easy to have a keyboard-centric workflow:
| you mix the tiling window manager strength with the
| traditional "windows" you can move with your mouse. F1 gets
| me to desktop 1 where my terminals live, Shift+F1 can send
| whatever window I'm using on desktop 1 to share it with the
| terminal for a while, Win + Left lets me adjust the tiling
| and Win + J lets me change from horizontal to vertical tiling
|
| Last year was my year of Linux on the desktop, and I think
| I'll stay on Linux if only for hyprland.
|
| > I have a weird urge to write a Frankencompositor that
| supports Wayland clients and enough to support an out-of-band
| X11 style window manager and the brutally insecure X11 style
| event snooping and injection; partly because it'd really
| irritate some Wayland purists
|
| Check hyprctl: you can get a list of windows. With hyprland
| key bindings + basic shell scripts using hyprctl and ydotool
| to send key or mouse events, it's already possible!
|
| From one of my simple scripts: `hyprctl dispatch focuswindow
| $WINDOW_ID | wl-paste | wl-copy -c` replaced `ydotool type
| "`wl-paste`"`
| vidarh wrote:
| > They are optional: you can make them last 100 ms, or just
| remove them.
|
| I'd rather have a codebase that doesn't have them so that I
| can work on a codebase that is tiny and focused on what I
| want when I want to change something. And I would need to
| make changes to the code base for it to suit me - see
| below.
|
| > Also, hyprland great strength is it makes it not just
| possible but very easy to have a keyboard-centric workflow:
|
| I already have a keyboard-centric workflow that does the
| things you list. There's nothing new in any of that. I have
| a floating desktop; I can move and resize them with the
| keyboard. I can move the tiling windows with the keyboard.
| I can swap individual windows, or swap entire subtrees, or
| flip their direction. All of that is trivial on almost any
| tiling wm.
|
| > Check hyprctl: you can get a list of windows. With
| hyprland key bindings + basic shell scripts using hyprctl
| and ydotool to send key or mouse events, it's already
| possible!
|
| This has the same flaw that was one of the reasons why I
| ditched bspwm - it allows getting events from it's 2nd
| socket - but not to intercept requests and being able to
| rewrite and choose whether to honor the requests or not. It
| does not have the flexibility I had in mind.
|
| It has a lot of great functionality, but none of the things
| that I care about provide more than I already have, and
| some would set me back to the point I'd have to rewrite
| stuff again - and frankly just the build process for
| hyprland makes me break out in hives...
| dingdingdang wrote:
| I for one will not be running this sort of low performance setup
| when PhpWM would obviously be an order of magnitude faster.
|
| *it really would though
| HeckFeck wrote:
| > *it really would though
|
| I imagine the vast optimisations that came in PHP7, likely at
| Meta and Wordpress's behest, would be to thank for that.
| wharvle wrote:
| Eh, it's been fast in the real world for quite a while. I
| think it's due to two main things:
|
| 1) Startup time had to be fast because of how it worked in
| its most common use case (yes, yes, FPM, but still) which
| tends to encourage or require making everything fast.
|
| 2) Writing C modules for PHP is relatively easy and it has a
| culture of anything halfway important being in C, going back
| to the early days of the language. The answer for how to be
| _really_ fast with real-world workloads in almost every
| scripting language is basically "get out of it and into C
| ASAP" but PHP's culture embraces that more than most.
| exikyut wrote:
| Rock: PHP X11 PoC that I poked at a couple years ago (which
| doesn't use libx11/libxcb, but talks directly to
| /tmp/.X11-unix/X0)
|
| Hard place: _crowd of Wayland pitchforks thundering in the
| distance_
|
| Effort analysis: <negative beeping>
|
| Itch: scratch?
|
| Me: _annoyed twitching_
| vidarh wrote:
| As you can see if you dig into my code and then look at the X
| protocol implementation [1], the (incomplete) pure Ruby X11
| binding takes up more lines of code than the WM. I was
| tempted to write the code to generate it from the XML spec,
| but a lot of the scaffolding for the current X11 binding
| predated my own work and it seemed like it'd be more and more
| painful work to write the generator than bite the bullet and
| do it manually (I don't expect to/care about supporting the
| whole protocol anyway). So a PHP version would be totally
| viable, just tedious.
|
| [1] https://github.com/vidarh/ruby-x11
| tonyg wrote:
| If you do ever return to the idea of generating the X11
| protocol code, you might find https://github.com/tonyg/xcb-
| shim interesting. I wrote it to simplify X11 implementation
| generally. I've used it just once, so far, though, to build
| a Squeak Smalltalk native X11 protocol implementation.
| vidarh wrote:
| That's really useful, thank you. I have been considering
| massaging the Ruby version into a different structure as
| while the current one is fairly nice in some respects
| (such as providing support for both parsing and
| generating both "sides" of the protocol, entertaining my
| delusion of possible writing an X server), it also could
| definitely be faster and smaller...
| tonyg wrote:
| Do get in touch if you do pick this up again, I'd be
| interested in collaborating or at least keeping track of
| how it goes; it was a bit lonely figuring out how to do X
| for Squeak in a vacuum :-)
| vidarh wrote:
| I know this is a joke, but, this goes right back to the first
| time I deployed Ruby and had "the speed discussion" with
| people. We deployed a Ruby queueing server that used 10x as
| much CPU in the Ruby code than our preceding C version spent in
| its code (that wording is careful). It was also 1/10th the LOC
| and had more features, and given we spent ca 1/10th of a
| 2006-era Xeon core in user space, it felt like a worthwhile
| sacrifice - the vast majority of time was spent in the kernel
| handling IO.
|
| It was what made me fall in love with Ruby: There are so many
| spaces where the time is spent elsewhere and the time spent
| doing things slowly in Ruby (though much faster than it used to
| be) doesn't matter.
|
| Like a window manager.
|
| I've even made performance tradeoffs that makes it _much
| slower_ : On every adjustment of the layout, I iterate over
| _every single window_ the WM knows about to filter a list of
| the wm 's on this desktop, that are visible, and compare that
| to a serialized list of _every single window_ that exists in
| the layout tree.
|
| Because it's fast enough, and it saves bothering to keep proper
| track of state, and makes some of the code simpler.
|
| Knowing when you can afford to pick the slow options on purpose
| is powerful.
|
| Knowing when you can't afford to, is also important.
| HeckFeck wrote:
| You show me your Ruby and I reply with my Perl:
|
| https://sourceforge.net/projects/perlwm/
|
| Last updated in 2004, just needs a touch of polish and she will
| be as good as new.
| j4yav wrote:
| Behold it in all its glory:
| https://perlwm.sourceforge.net/shots.html
| rollcat wrote:
| Using Emacs to write Perl to configure your WM... Why not cut
| out the middle man, and https://github.com/ch11ng/exwm
| superkuh wrote:
| And because it's Perl I bet it runs pefectly on Perl
| interpreters shipped on OSes today.
| csdvrx wrote:
| > And because it's Perl I bet it runs pefectly on Perl
| interpreters shipped on OSes today.
|
| That's a superpower (software that will not bitrot): last
| month for a new project, I hesitated between C and perl but
| chose perl.
| DoesntMatter22 wrote:
| Why exactly does perl not rot?
| petercooper wrote:
| I run RubyFlow and it's just a community link posting site for
| Rubyists, so feel free to update this to the URL of the actual
| project if you wish: https://github.com/vidarh/rubywm/tree/master
| .. RubyFlow runs on a teeny tiny Heroku instance so may not be
| too great at handling your traffic. It's about fifteen years old
| though and a single Ruby file, so I should probably rewrite it!
| ;-)
| mberning wrote:
| It sounds perfect :)
| yebyen wrote:
| Is this really the same 16 year old RubyFlow that authenticates
| against GitHub? I found a copy looking for the source but it
| looks like it is literally 16 years old, and I'm thinking
| there's just no way the OIDC flow has been standing intact for
| that amount of time without any update... really? :D
| petercooper wrote:
| The version you'll have seen is the original version that I
| "leaked" to someone else who wanted to run a similar site. I
| said they could make the code public, but I didn't want to
| maintain or stand by it. It underwent an entire rewrite about
| ten years ago which is the version that's live now and the
| auth flow has remained the same within that timeframe, at
| least, but https://github.com/omniauth/omniauth-github does
| the heavy lifting and has been updated as a dependency in
| that time.
| yebyen wrote:
| Awesome, I was fishing for open source links, I salute you
| thanks for sharing :)
| bradley_taunt wrote:
| Always happy to see new options in the WM space!
|
| My only gripe (and this goes for almost any open source project)
| is this: please include screenshots! Any program/service that has
| front-facing UI should have visual references, instead of making
| users build/run everything just to "see" it.
| vidarh wrote:
| I'll see about adding, some, but see links elsewhere in this
| thread to a couple, and note that you can't really see much of
| this wm, as in the style of e.g. bspwm it has no window
| decorations whatsoever beyond a 1 pixel rectangle.
| joshspankit wrote:
| Maybe a simple animation of one or two main actions?
| hulitu wrote:
| > it has no window decorations whatsoever beyond a 1 pixel
| rectangle
|
| Then we don't need any screenshot. We can do this with TWM,
| FVWM and MWM (and others).
| entropie wrote:
| > it has no window decorations whatsoever beyond a 1 pixel
| rectangle
|
| My favourite!
|
| As a rubyist using xmonad for years now (no real clue about
| haskell) I am thrilled.
| vidarh wrote:
| That's great. I still suggest caution even you try to test
| it, but having that a background with wms like that makes
| you less likely than most to hose your setup...
| jzb wrote:
| At this point HN should prompt people when submitting links.
| "Are there screenshots at the link? No? Go back and add them,
| then submit."
| gwhl wrote:
| There is/was Subtle which I used to use a long time ago:
| http://subforge.org/projects/subtle/
| vidarh wrote:
| I think I've looked at Subtle, and it's interesting and worth a
| look, though it has design tradeoffs that doesn't fit me (and I
| wanted something entirely in Ruby rather than "just" scriptable
| in Ruby) But that's cool - my thought on this is that I'd
| rather have many tightly focused options than huge sprawling
| ones...
| danjoredd wrote:
| Def needs screenshots. Need to know what it looks like to decide
| if I want to try it out or not!
| vidarh wrote:
| That's fair - but frankly if you are concerned about what it
| looks like, you almost certainly won't like it (and that's
| fine).
| hartator wrote:
| GitHub search doesn't work on this repo:
| https://github.com/search?q=repo%3Avidarh%2Frubywm%20x11&typ...
|
| Sad that Microsoft is slowly degrading GitHub experience.
| YorickPeterse wrote:
| Or maybe it's just a case of a job queue used for indexing new
| repositories being full. Not every instance of "X doesn't work"
| is the result of malicious intent.
| hartator wrote:
| Used to work instantaneously.
| dewey wrote:
| Just like things are not instantly in the search index on
| Google and other websites doesn't mean someone is being evil by
| degrading the user experience.
| hartator wrote:
| It used to work with new repo without an indexing delay. It's
| not evil, but it just means they don't care.
| larusso wrote:
| Thanks for this. Just skimmed over the code and seems to be a
| very readable project.
| vidarh wrote:
| Thanks. I'm not happy about the WindowManager class in
| particular, but it's slowly getting there.
| tombert wrote:
| I don't run Linux anymore, and I am waiting for Apple to
| officially drop Intel support before swapping my laptop over, but
| one of my many software "bucket list" projects is to use a high
| level language to build a window manager. I was thinking about
| starting by porting DWM to some form of Lisp.
|
| I love seeing these kinds of projects because it further
| validates that such an idea is feasible.
___________________________________________________________________
(page generated 2024-01-22 23:00 UTC)