Adding Glue to a Desktop Environment | Hacker News Reader

Adding Glue to a Desktop Environment

venam.nixers.net

104 pointszdw36 comments

One more thing not shown: Attach GDB to a GUI program by clicking on it. I have this in my setup:

    python
    import gdb
    import subprocess
    class AttachOnClick(gdb.Command):
        def __init__(self):
            super(AttachOnClick, self).__init__('attach_onclick', gdb.COMMAND_RUNNING, gdb.COMPLETE_NONE)

        def invoke(self, arg, from_tty):
            if not from_tty:
                print('Only supported in interactive mode (from tty)')
                return
            if arg:
                print('No arguments supported')
                return
            xprop = subprocess.Popen(['xprop'], stdout=subprocess.PIPE)
            awk = subprocess.Popen(['awk', '/^_NET_WM_PID/{print $3}'], stdin=xprop.stdout, stdout=subprocess.PIPE)
            xprop.stdout.close()
            try:
                bpid = awk.communicate(timeout=60)[0]
            except subprocess.TimeoutExpired:
                print('No click within 60 seconds, giving up')
                xprop.terminate()
                awk.terminate()
                awk.wait(1)
                xprop.wait(1)
                return
            awk.wait(1)
            xprop.wait(1)
            spid = bpid.decode('ASCII').strip()
            if not spid:
                print('No pid could be obtained')
                return
            cmd = 'attach ' + spid
            gdb.execute(cmd, True)

    AttachOnClick()

    end

Then you can type attach_onclick at the gdb command prompt and just click on a window to attach to it.

For being written in 2019, I am surprised that the article had no mention of the existence of Wayland. On my systems I have already moved off of Xorg onto Sway¹ as my compositor and window manager and have no intention of going back. Sway has a great programability via it's own swaymsg IPC protocol that allows me to do all the manipulations that I would care to do, and even works on my dual-paned HiDPI 5K monitor.

¹ https://swaywm.org

Oh. I was planning on trying out i3 for the first time this weekend. I assume you’d recommend swaywm instead, given that it says its basically a drop in replacement for i3? What else does it give you that i3 doesn’t, or make it a better choice than i3? Besides being a wayland compositor; or is that the main reason to choose it?

I came from i3, so I pretty much copied over my i3 config mostly intact. Had to add the output configuration for non-default resolutions. Had to add environment GDK_BACKEND=wayland to applications to tell them to use wayland instead of x11 via Xwayland such as firefox (65 and newer has wayland enbaled by default), vlc, gedit, terminal and anything else that supports wayland.

Downsides to Sway is that's it has only just entered beta and doesn't really have nice packaged/maintained releases yet. Also I use X11 gnome-panel overlay on top of the swaybar panel, because I wanted a real taskbar, which is kind of a hack and also why I know about the window manipulation features.

Thanks!

Presumably yeah, because i3 doesn't work on Wayland.

A friend of mine recently tried out Wayland and swaywm and blogged about it here: https://a3nm.net/blog/wayland.html. It might interest you :).

Sway should have all the benefits that come with being a Wayland compositor, like security and less screen tearing. It's also got a few extra features. Here's a few that I find neat:

Window drag-and-drop (a bit janky still, but functional)

Including other files in the config file (this is important for my idiosyncratic usage)

Input/output configuration. Since Sway doesn't have Xorg running, it's responsible for configuring keyboard/mouse/monitors. This is well documented and very simple to do for simple use cases (and more complex use cases can be supported via IPC). I much prefer this to the clusterfuck you get with X.

You also lose a couple features from i3 though:

Layout save/restore (this feature won't be ported, but it's possible to achieve the same effect using IPC).

Tools like xbindkeys, xdotool don't work. If you find some unusual case where you can't set up a keybinding in the sway config, you're out of luck. This is the cost of Wayland's security advantages.

I went back to i3 after trying sway because I couldn't get screen sharing to work in video calls, no matter what I tried.

There were a few other bugs, but that was the only show stopper for me.

For being an article about X windows tools, I don't see why the author would need to.

Is this even that compelling? X forwarding always sucked for me unless I was on the same switch as the source device.

We're glad you like it :)

I can’t wait until it supports Vulkan and thus runs on Nvidia.

It’s 2019 and I still want network transparency and a system not driven by security nazis.

Network transparency isn't as useful now that most apps use toolkits like gtk or qt instead of raw X drawing primitives. The toolkits render the UI into a pixel buffer, which takes a lot of bandwidth over the network.

That is not an excuse to don’t make the protocol network transparent.

If people can stream an HD game to their living room TV I don’t think a desktop application have to be much different.

There's video compression going on when they do that. If that's what you want, VNC works just fine.

No one is really interested in doing the work for you, but we're interested in helping you if you want to put in the work yourself. It's possible in theory and wouldn't even be terribly difficult.

I want to use Wayland so bad, sadly I like millions of other people have an Nvidia graphics card so am stuck with X11 for the foreseeable future. Sadly this problem will be recognized as "wontfix" by both Wayland developers and Nvidia.

FWIW I couldn't get Sway to compile on a totally vanilla Debian installation.

Discussion unlock question: in a default install how do you take a screenshot using Sway/Wayland?

Not sure what you mean by default install, but there are Wayland compatible screenshot programs out there such as Green Recorder¹.

¹https://github.com/foss-project/green-recorder

I am not. There are some of us who disagree "Wayland is the future". Some of us believe Xorg is great, tried and tested through many battles over the last 20 years. I have no intention or interest in switching to Wayland in the near future, too.

Oh, come on. I'm all into retrocomputing, and think there's a place for riced-out Apple ][ emulators, but X-Windows was terrible in comparison to other window systems 20 years ago, and it still is.

microM8 Apple II Emulator: https://paleotronic.com/software/microm8/

The X-Windows Disaster: https://medium.com/@donhopkins/the-x-windows-disaster-128d39...

X window managers are as complex and dug into a pit of pointless complexity as the Space Shuttle: https://news.ycombinator.com/item?id=5861229

The fundamental problem with X is that it ignored the brilliant idea behind "AJAX", that you should send not a fixed protocol but executable code (like PostScript or JavaScript) to the server to be interpreted in a sandbox.

Plus the fact that it has a terrible antique-device-dependent imaging model that views every device like a MicroVAX framebuffer on acid.

At the time of the transition from X10 to X11, all these problems and solutions were well and widely known and debated, but X11 chose to ignore those ideas.

But other competing window systems like NeWS didn't have those problems, and used much better solutions, which were only later re-discovered, re-implemented and re-branded in yet another layer with the advent of web servers, browsers, HTML, JavaScript, canvas, and "AJAX".

https://news.ycombinator.com/item?id=13783967

NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:

- used PostScript code instead of JavaScript for programming.

- used PostScript graphics instead of DHTML and CSS for rendering.

- used PostScript data instead of XML and JSON for data representation.

But now that there's another Web Browser layer slapped on top of X-Windows (and the terms "client" and "server" switched places), you're stuck with two competing mutually incompatible window managers nested inside of each other, one for the outside frames around apps, and one for the inside tabs around web pages, that don't cooperate with each other, and operate uncannily differently.

So none of your desktop apps benefit from any of the features of the web browser (unless they include their own web browser like Electron).

And you can't write lightweight apps in a couple pages of script like "Big Brother Eyes" that run in the shared window server, without requiring their own separate external app with a huge runtime like Electron.

https://www.donhopkins.com/home/archive/news-tape/fun/eye/ey...

Nor can you easily integrate desktop applications and widgets and web pages together with scripts, the way HyperCard, OpenDoc, CyberDog and HyperLook enabled.

https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...

Here's how the web browser and window manager should work together seamlessly:

https://news.ycombinator.com/item?id=18837730

And this is why a modern window manager should be written in JavaScript, leverage HTML, Canvas and WebGL, and support Accessibility APIs, as well as screen scraping, pattern recognition, screen casting, virtual desktops, overlays, drawing and image composition, input event synthesis, journaling, macros, runtime user customization and scripting, programming by demonstration, tabbed windows, pie menus, etc:

https://news.ycombinator.com/item?id=18797587

Think of it like augmented reality for virtualizing desktop user interfaces and web pages.

Brother, I'm sorry, but your post was very hard to understand, because you touched on many different subjects and linked several different comments from different times.

I'd like to point out my like of X11 over Wayland is not based on "retrocomputing". I'll try to clarify what I meant.

I know of X11's shortcomings, I have my own pet peeves with it, yet my issues with X are very different from the usual complaints you see in the wild. Although I agree X11 is pretty bad, when compared to Wayland it's like comparing a modern smartphone to a Symbian. I have issues with:

- the async way X11 operates; many, many times I've had clicks that lag a few milliseconds and end up pointing to the wrong window

- the whole event propagation model is awful, making it either an insecure system or a pretty cumbersome system to hook into events

- the over-using of the UNIX philosophy everywhere makes X11 feel like a bunch of brittle parts stuck together with cheap glue; none of the systems know much about each other

- the fact the client needs to be trusted on most of the properties it sets is simply stupid; some clients, to this day, still do not set, for example, _NET_WM_PID and for some reason Xorg developers decided it was a good idea to allow such important Atoms to be OPTIONAL. There are MANY simple tasks that are next to impossible under X11, like figuring out which window has the focus. This is RIDICULOUS

- some of its' internals must be so heavily intertwined together that I still get occasional crashes for reasons completely unrelated to window management or the GUI system

- toolkits; here is probably the number one reason there won't be a year of desktop on Linux: no one coming from any other OS understands why widgets look different, be it an user or a programmer who just wants to make a simple GUI app.

With all that said, the issue with Wayland is that it does not fix any of that. Worse, for some of those issues, it makes it even more difficult to work with.

I come from WINAPI/GDI, and before starting with X11 coding, I loathed it. I now see Windows GDI + WINAPI as the best designed GUI system I've coded for. Even with ALL OF ITS' SHORTCOMINGS, I can do everything I could imagine with windows objects: move windows, focus, unfocus, get keyboard input, change colors, change fonts, change text captions, completely hook into how client AND non-client area is drawn, override event procedures... The list goes on, WINAPI+GDI is a complete, consistent system; and because of politics, X11 devs time and time again refuse to make a solid system like it.

And Wayland comes from all those caveats and does not fix them: it maintains the same stupid politics and makes things EVEN HARDER to work with. It's akin to developing for an Android-like OS on a desktop computer. And the REASONS used to explain why Wayland exists are simply propaganda: they say X11 is old and unmaintainable, the code is awful, yadda, yadda. Those people must have never looked into the X11 codebase, because it's one of the most well-written and well commented pieces of code I've seen in my whole life. Here, take a look:

https://github.com/mirror/xserver/blob/master/dix/events.c

So, in conclusion, we do not need Wayland, we need X12, to fix the caveats, quit the over-engineered UNIX-everywhere design decisions, have a standard toolkit and event model, have a standard way for IPC and inter-window communication, sane defaults etc. Wayland is not the answer; Wayland is akin to shooting your only cow because it was infested with ticks! You don't kill the cow, you give her medicine so it gets better, because if you kill her, you'll also lose your daily milk supply! That is not smart.

With Xorg on his way out, are there similar options for Wayland? I quite like being able to use xbindkeys with xautomation or xdotool in basically every Xorg WM. I might try Wayland once there is a tiling WM that supports the Master layout (like dwm).

What makes you think Xorg is on his way out?

Xorg developers want to eventually replace it with Wayland

And what makes you think Xorg is male? ;)

It's probably a language thing that stayed in translation. At least Spanish doesn't have gender-less pronouns, so every object, living or not, has a "gender". In any case, it makes more sense for Xorg to be male than female.

Check out Simon Schneegans' useful and beautiful application launcher, Gnome-Pie, which he's been developing for many years, and is rearchitecting as OpenPie for Wayland.

Gnome-Pie 0.4 (7 years ago): https://vimeo.com/35385121

Gnome-Pie (6 years ago): https://vimeo.com/30618179

Gnome-Pie 0.6.1 (3 years ago): https://vimeo.com/125339537

Wayland Gnome-Pie 2 (WIP) (1 year ago): https://vimeo.com/224827490

He's written all about Gnome-Pie and the concepts behind it on his site:

http://gnome-pie.simonschneegans.de

And his Bachelor Thesis analyzes Gnome-Pie and realizes some really innovative and cool looking forms of pie menus:

http://simmesimme.github.io/news/2012/10/10/bachelor-thesis

Including the Coral Menu (6 years ago): https://vimeo.com/51072812

And the Trace Menu (6 years ago): https://vimeo.com/51073078

He discusses the problems of Wayland properly supporting pie menus and other non-traditional, deeply customizable user interfaces here: http://simmesimme.github.io/news/2017/07/09/gnome-pie-071

>Wayland – in it’s current state – makes applications such as Gnome-Pie hardly possible. Due to security concerns, applications are much more isolated. There is a good summary on the cairo-dock forums. Here are the big bummers: [...]

More recently he's written about his latest ideas for bringing pie menus to the modern Linux desktop with OpenPie, with a new architecture that solves some of the problems with Wayland, and enables any application to use pie menus and other novel types of menus:

OpenPie: http://simmesimme.github.io/news/2018/05/31/openpie

>With the advent of Wayland Gnome-Pie will slowly die. OpenPie is my new concept for bringing (pie-) menus to the Linux desktop. In this post I will give a motivation and describe the planned software architecture.

I've written more about the work he and other people have done with pie menus here:

Pie Menus: A 30 Year Retrospective: https://medium.com/@donhopkins/pie-menus-936fed383ff1

Interestingly enough, I use cwm on OpenBSD and I have never run into half of those tools. The interaction simulation ones could be used to fuzz user input in graphical applications for crashes. Has anyone tried this before?

Practical use I've found for some of these tools: Shell script that detects when any app is full screen (ex: Kodi, or Steam in Big Picture mode) and prevents Xscreensaver from activating.

And you can write your own. I use i3wm and was not satisfied how it handles Window Titles by default, so I wrote my own daemon for renaming windows automatically, which makes a huge difference for me: https://github.com/kissgyorgy/i3-window-title-changer

Unfortunately the opening sentence "Windows are objects living in the X server" is increasingly untrue as the world migrates to Wayland.

It is in the context of X servers, which is the context of the article.

Reply on news.ycombinator.com