Every window system has windows, as an entity. Usually we think of these as being used for, well, windows and window like things; application windows, those extremely annoying pop-up modal dialogs that are always interrupting you at the wrong time, even perhaps things like pop-up menus. In its original state, X has more windows than that. Part of how and why it does this is that X allows windows to nest inside each other, in a window tree, which you can still see today with ‘
xwininfo -root -tree‘.One of the reasons that X has copious nested windows is that X was designed with a particular model of writing X programs in mind, and that model made everything into a (nested) window. Seriously, everything. In an old fashioned X application, windows are everywhere. Buttons are windows (or several windows if they’re radio buttons or the like), text areas are windows, menu entries are each a window of their own within the window that is the menu, visible containers of things are windows (with more windows nested inside them), and so on.
↫ Chris Siebenmann
This is wild.
This sounds pretty normal, except for the use of the term “window” instead of “widget”. I guess the point is that it’s a hierarchy of nested paintable, interactive surfaces. I think most UI toolkits do something like this.
giddie,
That’s what I was thinking as well. In win32 world, everything is a window too. Unless you use a framework that renders it’s own GUI components, native windows components use window handles for everything windows, buttons, textboxes, scrollbars, etc. Even things that aren’t visual can require window handles because the messages need to be sent to “hwnd” handles.
I haven’t used them in a long time, but just like X, there are win32 tools let you navigate the window tree…
https://www.youtube.com/watch?v=WL8rk7pNGo0
Uhm, how ELSE would you do it?
ddjones,
Well, you’re right. This is an obvious way to do it when the OS is rendering components. This used to be the norm for both windows and unix software. For example visual basic would allow you to build entire applications using OS primitives in the window tree.
This had the advantage of having software components rendered in a user selected theme set in the operating system.
The opposite way to handle it is to let the application/toolkit render it’s own interface. Often times these would feel totally out of place, like java software, GTK software, etc on windows looked like obvious ports (well because they were). Other applications just like winamp just went wild with their own themes.
Over time the flexibility of toolkits that could render their own interfaces won out and applications using native OS primitives have gotten rarer. The toolkits have evolved to look better and especially post “metro” era (ie windows 8) it’s quite common for applications (even microsoft’s own software) to deviate from the OS standard controls.
In short, these days most toolkits render the interfaces themselves into a single window and the operating system has no knowledge about the application’s GUI structure. This has the effect of interfering with some kinds of accessibility applications, screen readers, input helpers, automation tools, etc. I’m not saying this is good or bad, but just saying this is where we are.
It’s bad. GUIs on every system have either never gotten better, or have actively gotten worse since 2013. From a user angle, there are endless failures at any kind of consistency and intuitiveness. Everyone using their own APIs/toolkits for UIs instead of using OS native APIs/toolkits has always been problematic, but the disease seems to have become the norm now, with, you’ve pointed out, OS vendors themselves refusing to keep things normal and unified. Their API/kits regressed in usability to serve marketing and design fads (like the “flat” or “minimalist” design fad) and stupidly short periods of development and testing between major revisions containing arbitrary changes just to push sales of hardware.
This talk about windows made me remember an obscure bug on X. If you leave a menu open or a right click menu (from a program that uses a native x11 window to draw them), then the DE won’t be able to lock the screen. Something about the (lack of a) security model of X, the popup window takes over some functionality required by the DEs to locks the screen, and the DE have to wait for it to close. They oficial fix is… to use wayland.
The reason is that the lock screens won’t start if another window is grabbing the keyboard, otherwise it would leak information. Or something like that.
Yeah, it was a problem more details here https://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/
There were a lot of security issues with the screen locks on X.org. I got off of it as soon as it was practical. By far the least secure windows environment since Win 9x’s enter password or cancel dialog
Bill Shooter of Bul,
Thanks for the link. I felt the author was being somewhat disingenuous when implying that X servers can’t be fixed. Obviously they can be, but it requires adding new privilege levels to X. His point should not have been that it can’t be done (which is wrong), but that nobody’s done it.
I also take issue with his “fake screen locker”, although a valid point, that can happen on wayland, windows, macos too. Heck could even be done from a website. This was the reason why windows uses “ctrl-alt-del” to login.
Someone would need to run their own software
Accidentally submitted before finishing and can’t edit… I did intend to say that I agree with you about X being old and being time to replace it with a cleaner solution. I’m fine moving on from X, the only condition is that its replacement must work for the use cases I care about. I think this is very reasonable.
Reading this article was honestly difficult for me because in X11-land you never know what the hell the terms “server” and “client” mean. And no, I don’t care if X11 “takes the perspective of the stuff that draws the things to the screen and accepts input”. This is like saying that “taking the perspective of a browser” magically makes a browser a server. So stupid. X11 should have been rejected as a windowing system right there and then by any sane person who came across this nonsense. By this was the 80s and people where doing weird drugs back then: https://www.youtube.com/watch?v=L7btKdFOs5w&t=40s
I agree that anything is possible in software and that “it cannot be fixed” is never absolutely true.
That said, I think the implication here is that the heart surgery required to fix the problems in X11 are substantial enough and would break enough stuff that it would essentially not be the same system anymore. The X11 developers essentially came to that conclusion and decided that, if changes of that scale were required, it was easier just to start from scratch. That is how we got Wayland.
Since X was not fixed and Wayland was, a lot of the resistance to Wayland are the use cases is explicitly disallows.
There are other problems with Wayland. I am not trying to ignite that war here. Rather, it is a good example of the inevitable problems that arise when you try to fix software that has fundamental problems. Somebody will always ask you to re-enable spacebar heating.
https://m.xkcd.com/1172/
tanishaj,
I agree with most of your points, although I would not say the wayland’s problems were inevitable though. A poor roadmap that disallowed features that would prove to be quite important caused unnecessary turbulence. Leadership placing more emphasis on user needs earlier on could have been a significant help. Ideally we’d learn from these mistakes, but honestly every generation seems inclined to repeat them. I guess it is human nature.
BTW the above post wasn’t meant to be a reply in this thread.
kurkosdr,
+1. I’ve always disliked the terminology. You run client software on the user side, and server software on the remote side. I don’t even care that we initiate connections from the server…it’s still the server IMHO.
Woulda, coulda, shoulda.
We actually made good use of ssh & X11 it at the time to connect to unix labs from home, so I’m glad we had it. But still, a new X11 replacement wouldn’t have happened in a vacuum and presumably there would have been a new alternative way to do our work remotely. For all I know, something else might have been better. The trick is finding the balance between long term stability and the latest and greatest.
@krukosdr If your mind is locked into “server – big computer, client – small computer/terminal”, and can’ think about the actual role in client/server architecture, then programming is not for you. It requires abstract thinking.
Anyhow already the initial post is uninformed. In X11, besides widgets which have their own window, we also have gadgets, which are windowless.
https://www.oreilly.com/openbook/motif/vol6a/Vol6a_html/ch03.html
(check section 4.3.3 Gadget Management)
https://www.x.org/releases/X11R7.5/doc/Xt/Xt.html
(check section 12.3.6. Use of Rectangle Objects)
In that case the client program is responsible for handling events and drawing the gadgets within a single window. This was used as an optimization in cases when programs had thousands of widgets and having so many windows was a drag on X server. In reality, X11 was well optimized and having many windows was rarely a problem. So gadgets were not so popular as programming abstraction; it solved a problem few people have.
dpeterc,
I am a programmer and I believe kurkosdr is too. We know about socket programing, but to us one installs a “client” on the user’s machine and the server is the side serving many users regardless of who sends the tcp syn packet.
FTP is a good example, the “FTP server” is the side hosting the files even though the FTP server traditionally initiates TCP connections to the client. (a later extension called passive ftp reverses the connection direction).
Or you have some VOIP protocols where a call comes in on a socket connection initiated by the server, I would argue that in such cases, just because you are receiving a call instead of placing it, that doesn’t suddenly make your VOIP client software a server.
I agree with kurkosdr, it just adds confusion when X11 reverses the terminology from a user’s perspective. Of course you are entitled to disagree.
Actually most windowing toolkits work this way. For instance, to create a button in Win32 you call the “CreateWindow” function:
https://learn.microsoft.com/en-us/windows/win32/controls/create-a-button