How X Window Managers Work, and How to Write One (2014) • Hacker News Board

Re: How X Window Managers Work, and How to Write One (2014)

#71

Post by qwerty456127 » Wed, Nov 03, 2021, 10:07 AM UTC

Seirdy wrote: post #65

qwerty456127 wrote: post #62

Earlier quoted context omitted.

What are, if any, use cases where one would need a compositor? Other than transparent window decorations, wobbling windows and overlay dock? These are kinda cool but not worth any additional complexity or hardware resources IMHO. I have never seen any screen tearing in my life by the way. Despite I have always been generally using decade-old PCs with lowest-end (mostly built-in) GPUs and Raspberry Pi is the only way…

If you try scrolling in a web browser, especially fast scrolling in small increments, you're likely to experience screen tearing or other problems in the "smoothness". Compositors are included by default on most X desktop environments primarily for this reason. The delays and latencies for me have been noticeably lower when using Sway on ARM, which is quite surprising because I was expecting the opposite. I hadn't ev…

> If you try scrolling in a web browser, especially fast scrolling in small increments, you're likely to experience screen tearing or other problems in the "smoothness". Compositors are included by default on most X desktop environments primarily for this reason.

I see. Curious that I have never noticed anything like this though. I have always been disabling compositors as I realized I don't really care if my panel is transparent. Perhaps the problem just doesn't affect Intel graphics (Raspberry Pi browsing is slow anyway so fast scrolling just doesn't exist there).

UPDATE: I've just realized I've actually seen screen tearing many times - always within specific Windows apps ran with Wine, e.g. Total Commander.

Re: How X Window Managers Work, and How to Write One (2014)

#72

Post by AshamedCaptain » Wed, Nov 03, 2021, 10:13 AM UTC

perth wrote: post #39

jcelerier wrote: post #32

Earlier quoted context omitted.

Setting DPI in .Xresources had worked fine for me since 2014 except for Firefox and Chrome which took a year or so to adapt

Try to set two different DPIs in that.

You certainly can, but the problem is that there is no agreed standard from the toolkits to do it. E.g. Qt has its own way.

Re: How X Window Managers Work, and How to Write One (2014)

#73

Post by II2II » Wed, Nov 03, 2021, 10:13 AM UTC

loxias wrote: post #24

fyrn- wrote: post #2

Maybe don't write an Xorg window manager right as the replacemeant for Xorg starts to take off though

> replacemeant for Xorg WHY. What's the compelling reason for Wayland? How will it make my life better? As someone who's used Linux as their only computing environment for 20 years, I'm terrified of my Xorg being taken away. It works! I understand it! And, I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd. There's what feels like a rising attitude in the F/OSS community o…

I have been using Linux for over 25 years. I am not going to shed any tears over the loss of X, though I am concerned that some edge cases will be missed in the transition to Wayland or XWayland. The latter is why I am holding off on switching. Let others figure out and fix those edge cases for me.

As for systemd, it appears to be an entirely different type of transition. I won't go as far as saying it is unnecessarily complicated since many Linux distributions had a complicated startup to begin with. However, it is complicated compared to Net/OpenBSD. In contrast, I have always seen X as complex. It is easier to deal with these days since they have smoothed over the sharp edges, but I don't know if it is a case of those edges being sanded down or covered up. It also doesn't cover up the complexities of the many different toolkits one encounters, which you will encounter under X if you use older software.

Re: How X Window Managers Work, and How to Write One (2014)

#74

Post by Seirdy » Wed, Nov 03, 2021, 10:14 AM UTC

sprash wrote: post #66

Seirdy wrote: post #42

Earlier quoted context omitted.

Fedora, Ubuntu, OpenSUSE, RHEL/Rocky, and Debian all have their default desktops on Wayland. Both GNOME and KDE have already switched and will keep legacy X around for compatibility purposes for another few years. On the more minimal side to compete with X-based window managers: Sway is very mature and River is turning out nicely. All that's left is an Openbox alternative. I believe there are a few, but I'm not famil…

This is not an organic transition. Major organizations seems to "push" it but there is not much "pull". Compare this to the "transition" from CVS/SVN to git. There was no need to even advertise git. People saw it and wanted it. The X11 ecosystem is more than just GNOME, KDE and i3 and porting XFCE will not be enough to "move on" (For me it is the small things like Xdotool, Xsel, Xcalib, etc. that are holding me back)…

Xdotool and xsel have had Wayland equivalents for years: see ydotool/wtype and wl-clipboard.

The reason why major orgs have had to push for Wayland is the same as the reasons they had to push for HTTPS and TLSv1.2, unique passwords, keeping software up to date, etc: using outdated and insecure software with significant attack surface has real costs even if it's convenient.

Re: How X Window Managers Work, and How to Write One (2014)

#75

Post by DonHopkins » Wed, Nov 03, 2021, 10:18 AM UTC

jcelerier wrote: post #32

perth wrote: post #28

Earlier quoted context omitted.

Well it doesn't rely on using a giant buffer for multiple monitors so it supports hidpi scaling. Have you ever tried hidpi on xorg? It's a mess, even on Ubuntu where they tried their best to clean it up. The xorg apps from the compatibility layer still suffer from it, probably until they update to Wayland. Sidenote: Google tried to use xorg for ChromeOS and ended up writing their own UI system for hidpi scaling among…

Setting DPI in .Xresources had worked fine for me since 2014 except for Firefox and Chrome which took a year or so to adapt

https://donhopkins.medium.com/the-x-windows-disaster-128d398...

>My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?”

>Of course, HP claims X has a mode which allows you to run X in the overlay planes and “see through” to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn’t actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they’ve only tested it on the simpler, less advanced configurations. When you’ve got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.

Re: How X Window Managers Work, and How to Write One (2014)

#76

Post by DonHopkins » Wed, Nov 03, 2021, 10:23 AM UTC

https://donhopkins.medium.com/the-x-windows-disaster-128d398...

>As a result, one of the most amazing pieces of literature to come out of the X Consortium is the “Inter Client Communication Conventions Manual,” more fondly known as the “ICCCM”, “Ice Cubed,” or “I39L” (short for “I, 39 letters, L”). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late — by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.

>The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn’t work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It’s so difficult, that many of the benefits just aren’t worth the hassle of compliance. And when one program doesn’t comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.

>In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry’s standard naked emperor.

>Using these toolkits is like trying to make a bookshelf out of mashed potatoes. - Jamie Zawinski

Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, the Andrew Window Manager, and NeWS, and an old friend):

https://blog.dshr.org/2018/05/recreational-bugs.html

>"You will get a better Gorilla effect if you use as big a piece of paper as possible." -Kunihiko Kasahara, Creative Origami.

Re: How X Window Managers Work, and How to Write One (2014)

#77

Post by Hendrikto » Wed, Nov 03, 2021, 10:24 AM UTC

loxias wrote: post #24

fyrn- wrote: post #2

Maybe don't write an Xorg window manager right as the replacemeant for Xorg starts to take off though

> replacemeant for Xorg WHY. What's the compelling reason for Wayland? How will it make my life better? As someone who's used Linux as their only computing environment for 20 years, I'm terrified of my Xorg being taken away. It works! I understand it! And, I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd. There's what feels like a rising attitude in the F/OSS community o…

> I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd.

Systemd is neither unnecessary nor stupid. And I am sure, if you really think about it, you know this yourself. It would not have been adopted so widely and quickly if it were.

Systemd offers countless advantages over previous init systems: https://www.reddit.com/r/archlinux/comments/4lzxs3/comment/d...

Re: How X Window Managers Work, and How to Write One (2014)

#78

Post by arein3 » Wed, Nov 03, 2021, 10:26 AM UTC

loxias wrote: post #60

danachow wrote: post #48

Earlier quoted context omitted.

Then what is your complaint? No one is stopping you from using X for as long as you like. Meanwhile the majority of users that want sane, modern handling of HiDPI can move on.

> Then what is your complaint? What complaint? Why do you think I'm complaining? I wanted to know what's so fundamentally wrong with X to warrant a massive developer effort to replace it. Based on the comments here, I have my answer: Nothing's wrong with X. Also, something lighter weight is desired for embedded platforms. Some fraction of the population, like you, wants their display system to render in terms of poin…

if you buy a high pixel density display (ex a 15 inch laptop with a 4k display) then you need to be able to map 2 real pixels to 1 logical pixel (what apple did with retina displays)

Re: How X Window Managers Work, and How to Write One (2014)

#79

Post by qwerty456127 » Wed, Nov 03, 2021, 10:27 AM UTC

Seirdy wrote: post #70

vidarh wrote: post #64

Earlier quoted context omitted.

The first ARM dates to 1985. I don't know if there was ever an X11 server for Acorn RISC-OS, but there were for similar era Amiga's. But that misses the point, which was that current era ARM chips are orders of magnitude faster than the old 68k family Unix terminals and 486's I ran X on through much of the 90's. You're right, compositors weren't a thing, but we're also talking CPUs several orders of magnitude slower,…

I am only familiar with ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for. In my own tests and from others who have tried the same, DWM & Co were noticeably slower; I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines. The difference will widen as Vulkan support in Wayland compositors seems to be outp…

> ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for

Are they SO slow on the tasks they are not optimized for they can't even beat a 25-year-old GPU like S3 Trio?

> I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines.

Why does it have to be? What do we get for this cost? The only things in which I would find a modern Linux better than a 90s Linux are full UTF-8 support, modern crypto and hardware drivers availability.

> The difference will widen as Vulkan

I don't know a single person (among many dozens of Linux users I personally know) who would need it. I can only imagine movie makers using Blender or something like that

Re: How X Window Managers Work, and How to Write One (2014)

#80

Post by Zababa » Wed, Nov 03, 2021, 10:29 AM UTC

5e92cb50239222b wrote: post #45

josefx wrote: post #37

Earlier quoted context omitted.

> So having your problems ignored is something you'll have to get used to if you choose to use hardware that requires proprietary drivers 3..2..1 and the floss copy pasta has arrived a bit delayed but still as expected. Might want to check if the server your bot is running on is a bit overcapacity to fix that delay. Still not going to amputate my leg over a stubbed toe even if RMS considers the toe cancer. > GBM is t…

I really don't see why a bunch of unpaid volunteers should bother to support the only player in town that refuses to play nicely and tries to strong-arm everybody else to use its technically inferior solution. Here's a nice write-up. I can imagine how nice it is to spend all your waking time trying to improve the Linux graphics stack and then listen to all the bullshit that we see in this discussion. https://drewdeva…

> I can imagine how nice it is to spend all your waking time trying to improve the Linux graphics stack and then listen to all the bullshit that we see in this discussion.

Is this really surprising? End users want their stuff to keep working with minimal changes. End users don't know and/or don't care that X is hard to maintain. They seen wayland coming, and they're scared that some of their stuff that they currently use will break. How exactly do you expect people to react to:

> Maybe Wayland doesn’t work for your precious use-case. More likely, it does work, and you swallowed some propaganda based on an assumption which might have been correct 7 years ago. Regardless, I simply don’t give a shit about you anymore.