1. 21

  2. 8

    Great article! At first I thought it was going to be about another type of glue, more like the Unix shell. I feel that there’s something that the shell has that desktop environments lack – programmability, composability, the fact that it’s much easier to create a command-line tool than a graphical tool – that I’d like to see more of in new-thinking DE and WMs instead of just Yet Another Tiling Window Manager.

    1. 7

      The day I discovered wmctrl and xdotool was life-changing.
      Low-tier life-changing, but definitely life-changing.

      I even have some old, never-finished Ruby wrappers built around them that was purpose-build to aid in a single project, very much in line with what the article suggests: Set up my window placement for each project I work on across various monitor layouts and WMs, via a hotkey, or running a command from dmenu (or at login if I wanted, but I never want that, personally).

      One relic from that still gets used on my desktop, and I have since used the two for other things.

      In one case I was able to brute-force my way through a form on a mis-configured government website that kept kicking me out to page 1 of a multi-step form, depending on which of their servers was serving my request. And of course none of the data persisted, or would re-reappear when I jumped between the different servers, but I simply xdotool’d a bit and only had to hit a hotkey to fill out the dozen-or-so fields on each page, and submit, until it worked.

      1. 3

        This is a really cool article, but it also makes me sad.

        In particular I can’t see any reason why there shouldn’t be some kind of unified programmatic interface to desktop environments.

        Apple has AppleScript, Windows has Powershell, and clearly this article shows that it’s doable in UNIX as well, but to be frank it’s a mess.

        That’s sad, and entirely avoidable. IMO the FreeDesktop project is slowly working their way up the stack to get to this point - things like Dbus are a good start….

        1. 3

          Why do you consider it a “mess”? The idea is to compose a larger environment from small tools. It seems to work fairly well?

          1. 4

            The tools presented work great for the level of abstraction they interface with, but I want ultimately to interface with higher level elements like applications, the desktop environment itself, and the like.

            More concretely, being able to reach in at the X11 level and push bits around is fantastic and SUPER useful for all kinds of things, but there are other avenues of usefulness and exploration that are impossible or difficult to implement using these tools alone.

            This is one of those conceptual gulf problems. UNIX people who’ve never worked with an environment that provides first class application scripting have a hard time wrapping their heads around what it can do and why it’s desirable.

          2. 2

            unified programmatic interface to desktop environments.

            I could be wrong, but my understanding is that Wayland is this (at a very high level). Wayland also renders all/most of the utilities in this article useless, since they only work on X11.

            1. 6

              Wayland is an interface to the display server specifically — it’s a bare bones, async protocol designed with speed in mind.

              D-Bus is indeed more like this. An interface to the whole environment, to user applications, to everything. GTK exposes windows and actions automatically, so you can already do a little bit of AppleScripty things with D-Bus. But applications really have to provide their own interfaces for this to be as powerful as AppleScript.

              1. 1

                or, X11 renders wayland useless

                1. 1


                  Useless or just broken?

                  1. 4

                    Useless. The protocol they use to talk to the X server does not exist in Wayland. To me, broken implies that they could be fixed. These tools would require fixes so extensive that they would be new tools. In some cases, what they do is not (currently) possible on Wayland so there is no ‘fix’.

                    1. 2

                      What is the difference? Many of the mechanisms these tools use are not portable to the Wayland model, and there’s no X server to talk to in any case.

                      There’s ongoing work to establish new sorts of protocols by which Wayland client can describe each other and inter operate, but these protocols are all “user-space”, similar to EWMH hints/atoms/actions. Work is ongoing to standardize these protocols; see this HN comment from @SirCmpwn for context.

                      1. 1

                        I should have written “not needed anymore as superior mechanisms of interactions are available”.

                2. 1

                  I wrote some xdotool scripts last year: cwm-w-mv, to move the window to the side of the screen, and cwm-w-tile, to improve on cwm’s tiling feature.

                  I have since moved on from cwm to dwm, and no longer need it, but still interesting example of what the author is talking about.

                  Other useful parts are wm-brightness and wm-volume, to control the brightness and volume from my laptop’s media keys, and dmenu_uni to insert those ever-important emojis! 😎😎