11 ms·

A peculiarity of the X Window System: Windows all the way down

194 points by ingve 3y ago

cbsmith 3y ago
I never thought of this as a peculiarity of the X Window System (though the client-server aspect of it was a lot of what made X, X), but I keep forgetting that this is not something modern developers know about.
robertknight 3y ago
This is not unique to X. Windows for example uses the same kind of "HWND" object for buttons as for top-level windows. Windows doesn't have the same client/server overhead as X though. In Qt, there is an option to use either native windows for individual widgets or "alien" windows, in which only the top level widget is a native window - https://doc.qt.io/qt-6/qwidget.html#native-widgets-vs-alien-widgets https://doc.qt.io/qt-6/qwidget.html#native-widgets-vs-alien-....
- pjmlp 3y ago
  Yeah it was already the way of doing GUIs in 16 bit days.
- rob74 3y ago
  Yup... I was working on a password manager application for Windows a few years ago, which was easy for most applications using the native UI because of all controls having window handles - and was then disappointed that it didn't work in cross platform apps such as Firefox.
- wruza 3y ago
  GTK also uses windows for input-related widgets. It’s simply convenient to have a separate window context. Although these windows are GDK windows, which may or may not have system windows underneath, afair.
- raphlinus 3y ago
  Good further reading on this change is "Windowless controls are not magic"[1] from Raymond Chen, and the followup "Windows are not cheap objects"[2]. It's a fascinating tradeoff space. I think fine-grained windows worked reasonably well on limited hardware but did not scale to super-rich applications like web browsers, or a more sophisticated imaging model where widgets need to be composited with alpha-transparency. [1]: https://devblogs.microsoft.com/oldnewthing/20050211-00/?p=36473 https://devblogs.microsoft.com/oldnewthing/20050211-00/?p=36... [2]: https://devblogs.microsoft.com/oldnewthing/20050315-00/?p=36183 https://devblogs.microsoft.com/oldnewthing/20050315-00/?p=36...
  - pillusmany 3y ago
    90s apps used these Windows handle controls and it was not a performance problem. On computers 100 slower than today and with 1000 times less memory. BTW, the current Windows Task Manager still shows the total HANDLE count on the CPU page. They were not used in apps with complex UIs because native controls were hard to skin and didn't work very well when their size was very small (as complex UIs tend to need)
    - bitwize 3y ago
      > 90s apps used these Windows handle controls and it was not a performance problem. For a while there, at least on Windows 3.1 and before, possibly some Windows 9x versions -- you had a GDI heap and USER heap of 64k each (one 16-bit x86 segment). If you allocated too many HANDLEs, you could blow one of these heaps. So it still made sense to be judicious about how many windows you created. Most Web browsers and word processors, for instance, drew their documents in the client area and did not use subwindows to position text elements.
    - adzm 3y ago
      Note the HANDLE count is kernel objects; windows and graphics objects will show as USER and GDI respectively. Each of these has its own heap and limits.
    - Someone 3y ago
      > 90s apps used these Windows handle controls and it was not a performance problem. That depends on the overhead per window. Microsoft Windows could use nested windows because it had separate Graphics objects to store such things as the current drawing pen, its position and the current font to use for drawing (https://learn.microsoft.com/en-us/windows/win32/api/gdiplusgraphics/nl-gdiplusgraphics-graphics https://learn.microsoft.com/en-us/windows/win32/api/gdiplusg...) In comparison, on the classic Mac every window had a GrafPort that defined a boundary region, a clipping region, the current pen position, size, drawing pattern, etc. The Mac could have such heavy-weight window objects because it didn’t nest windows. Instead, each window had a single list of controls that were much lighter-weight. my gut feeling says separating the drawing state from windows as in MS Windows is the better choice, but I also think having separate entities called “windows” and “controls” as on the Mac is the better choice. (its documentation is ‘less than stellar’, but it appears GrafPort still exists: https://developer.apple.com/documentation/applicationservices/grafport https://developer.apple.com/documentation/applicationservice...)
- Stratoscope 3y ago
  Traditional Microsoft Windows apps do have one oddity here: the "client" and "non-client" areas. The non-client area included stuff like the title bar, min/max/close buttons and system menu icon, and resizing borders. The client area was where your app would put its content, including any child windows like buttons and list boxes. Many of the window messages for the client area had corresponding non-client messages, for example WM_PAINT and WM_NCPAINT. All of these messages would arrive in your GetMessage/DispatchMessage loop, but you would generally ignore the WM_NC versions and DispatchMessage would send them to the Windows code for default processing. OS/2 Presentation Manager took a more elegant approach here (but probably slower). You had one main window and everything inside it - both "client" and "non-client" stuff - was child windows. So you just had one set of messages for everything, no WM_NCxxxx messages at all. The client area was a child window, with other child windows for the non-client doodads.
  - Dwedit 3y ago
    Non-client area also applies to controls (non-top-level windows) as well. For example, the border on a text box is part of the nonclient area of that window.
  - fragmede 3y ago
    Oh god, WM_PAINT. that takes me back. I'm not convinced that css is better, given how many lives were wasted trying to get a responsive 3 column view to work before flex box, but here we are.
    - ale42 3y ago
      And something behind still needs WM_PAINT to display the thing styled by CSS... at least if it's displayed on a Windows machine
  - barrkel 3y ago
    One object receiving different messages for painting its innards vs its chrome isn't particularly ugly. Most apps don't want to customize the chrome so they'll let the base class handle those messages, but the option is there. Windows is kinda smalltalk-like in its window message system.
- AceJohnny2 3y ago
  I remember when Qt introduced the "alien windows" concept, in 2007: https://web.archive.org/web/20080205085059/http://labs.trolltech.com/blogs/2007/08/09/qt-invaded-by-aliens-the-end-of-all-flicker/ https://web.archive.org/web/20080205085059/http://labs.troll... As they say, they had to do it to eliminate flicker. Which goes to show that if your elegant design can't scale, it will be corrupted until it can. Something something "worse is better"
- codedokode 3y ago
  Windows (unlike X) had built-in windows classes (for example: buttons, checkboxes, input fields) that you could use to turn a window into a standard control. That's why idea "everything is a window" worked well in Windows.
- kragen 3y ago
  i assume by 'windows' you mean 'microsoft windows', because otherwise your comment makes no sense smalltalk has worked this way since at least 01976, but the word they used instead of 'window' was 'view'. see for example steve burbeck's 01992 'how to use model-view-controller' which is describing smalltalk-80 https://www.researchgate.net/publication/238719652_Applications_programming_in_smalltalk-80_how_to_use_model-view-controller_mvc https://www.researchgate.net/publication/238719652_Applicati... > Views are designed to be nested. Most windows in fact involve at least two views, one nested inside the other. The outermost view, known as the topView is an instance of StandardSystemView or one of its subClasses. The StandardSystemView manages the familiar label tab of its window. Its associated controller, which is an instance of StandardSystemController, manages the familiar moving, framing, collapsing, and closing operations available for top level windows. Inside a topView are one or more subViews and their associated controllers which manage the control options available in those views. The familiar workspace for example has a StandardSystemView as a topView, and a StringHolderView as its single subView. A subView may, in turn, have additional subViews although this is not required in most applications. so it's not a peculiarity of x-windows; it's how windows/icon/menu/pointer guis have been built since the beginning. (i'd say 'it's how guis have been built since the beginning' but of course sketchpad, grail, nls/augment, and genesys didn't work this way, and they were certainly graphical user interfaces, even if very different in style.)
  - samatman 3y ago
    > i assume by 'windows' you mean 'microsoft windows' Yes of course he did, and you don't have to guess, because the phrase "Windows for example uses" makes Windows a singular noun, compare with "windows for example use". There is no possible ambiguity in the post you replied to.
    - kragen 3y ago
      sam, knock it off find a hobby other than harassing me on hn if you can't control yourself, take a break from hn (most recent previous incident, though not the only one: https://news.ycombinator.com/item?id=39402249 https://news.ycombinator.com/item?id=39402249)
- omnibrain 3y ago
  The Start button is (or at least used to be) a Window. And in the first Release of they forgot to remove the window control menu - the thing that opens/used to open when you click the program icon on the top left corner. Obviously there was no program icon to click, but you could use a shortcut to open it. Then you could select "move" and move the start button on the task bar or even close it. After you closed it, it was gone and you had to kill explorer.exe via task manager and restart it, to get it back. I can't remember the shortcut, it must have been something like alt+-. In older programs this menu is still around and you can still use it to close programs, like you did in Windows 3.1 days. Even doubleclicking the icon in the top left corner still works to close those programs.
  - ale42 3y ago
    As far as I remember, Alt+- opens the menu of an MDI child window. For the current window (which is generally more useful, MDI applications being very rare these days), it's Alt+Space as mentioned by several people.
  - ankurdhama 3y ago
    I still use the window menu shortcut Alt+space and then C to close the window, it is more easy to press compare to Alt+f4 (such a non-ergonomic key combination, compare to macOS cmd+w)
    - WorldMaker 3y ago
      Ctrl+Q works in most (though yes, certainly not consistently all) Windows applications. Cmd+Q is also what you'd use on macOS to quit an entire application (Cmd+W is close single window), so the cross-platform ergonomics/muscle memory are actually somewhat preserved. Most Windows applications that still use MDI for some reason or that have tabbed browsing interfaces (appropriately) generally use Ctrl+W for window or tab closing, respectively.
  - toast0 3y ago
    > I can't remember the shortcut, it must have been something like alt+-. It's alt+SPACE. Very handy if you manage to get a window off screen, you that menu almost always shows up on screen, and you can select Move (possibly by hitting m), and then move (or drag) your mouse and the window comes back.
- fsckboy 3y ago
  >Windows doesn't have the same client/server o̶v̶e̶r̶h̶e̶a̶d̶ ̶a̶s̶ ̶X̶ ̶t̶h̶o̶u̶g̶h̶ ...features and functionality as X, regretably
- asveikau 3y ago
  > Windows doesn't have the same client/server overhead as X though. Yes it does. You think they run that in the same address space? When there are multiple processes with different privilege levels running their UIs? Maybe this comment was accurate for Win3.1, but for a long time there is absolutely a client server architecture behind it. Anyway one of my favorite uses of HWND is to use a non visible window as a worker thread mechanism. Each HWND is tied to a message pump in the thread that owns it. So you can send it messages, and boom, you have a thread API...
  - p_l 3y ago
    On all "Classic" Windows and on NT from NT4 until DWM in Vista, GDI was not client-server instead it would draw directly to VRAM With some kernel assistance on NT (before NT4, GDI calls were handled by separate server process). This is why misbehaving application could get you the famous "trailing window" effect where moving a window would leave partly painted trace of it behind - you had to wait for some other coffee to properly repaint that other area. With DWM, your GDI windows are backed by memory that at most will be a texture in DirectX, which will be then composited by DWM (equivalent of X11 extensions to capture window drawing into pixmap instead of lowest common denominator implementation of DIX/DDX that would draw immediately to framebuffer)
ironmagma 3y ago
'Programming X is like reading one of those French philosophers where afterwards you start wondering whether you really know anything for sure.' [1] [1] Thomas Thurman - https://www.youtube.com/watch?v=GWQh_DmDLKQ https://www.youtube.com/watch?v=GWQh_DmDLKQ https://people.freedesktop.org/~daniels/lca2013-wayland-x11.pdf https://people.freedesktop.org/~daniels/lca2013-wayland-x11....
- deleted 3y ago
  [deleted]
Animats 3y ago
Confusingly, in classic X Window terminology, the "server" is the display manager running on the user's workstation, and the "client" is the application running on a remote machine that wants to display something. This article uses that terminology.
- lproven 3y ago
  Because that is the correct terminology in this context.
- taeric 3y ago
  Honestly, this isn't that confusing. I think even back in the day, it didn't take long to understand the reasoning behind this naming.
- ssl-3 3y ago
  It's OK terminology. In networking, clients usually initiate the connection to a server, a server is usually intended to be able to serve multiple clients, and servers tend not to talk much with other servers that might exist on a network. And that's how it be with the X Window System.
  - starspangled 3y ago
    Well, and obviously X is providing a windowing and drawing service to the clients. Doesn't matter who initiates the connection or the M:Nness of the communication, X is providing the service to the applications, and they are not performing any service for X.
    - lproven 3y ago
      Yup. Compare: Windows Services for Linux.
- kazinator 3y ago
  It's the reverse that would be confusing. Your "web client" would have to be called an "X server"! I suspect the X terminology is confusing to two groups of people: 1. Those who are used to the idea that when the computer and the display are separated by distance, the local display is a mirror of the remote machine's desktop, courtesy of a service on that machine to which the local display connects as a client. X isn't a remote desktop mirroring protocol, though; those people have the wrong model. 2. Those who are used to the idea that a server is something that runs in the background (daemon), not visible in the desktop. How can the X desktop be the server, when it's shoving pixels in your face, right in the foreground? Well, you know, someone serving you a punch also does it in your face.
jhallenworld 3y ago
An interesting part of the X protocol is XGrabPointer (and XGrabKeyboard). These force events to be delivered relative to a particular window instead of to the focus window. Cascading menus can be implemented by making a stack of such grabs: push when you open a submenu, pop when you ESC back to parent. Anyway, so it's very useful that everything in X is a window, because it works well with this input grabbing. Also it's nice for borders: the border was one outer window, and the drawing area was a smaller inner window. I don't quite remember anymore, but I think a bad part about using the X's windows is that the coordinates were limited. Sure you only need 12-bits or so for screen coordinates, but it's convenient if you had 64-bits to handle any possible clipping or relative offset situation.
- dmazzoni 3y ago
  I don't think that's unique to X windows, though - pretty much all GUI platforms have a similar concept, otherwise any time you accidentally drag your mouse outside of a window you'd start sending events to another application. On MS Windows it's called "Capture".
  - mschuster91 3y ago
    > otherwise any time you accidentally drag your mouse outside of a window you'd start sending events to another application. macOS does precisely that. Open a Chrome window and put a Finder window over it, then move your mouse and do a scroll gesture - the target will always be whatever is below the mouse cursor at that moment, even if you don't actively select the window.
    - marwis 3y ago
      That's also the behavior on Windows
      - emi2k01 3y ago
        It's also the behavior on Linux with X11 (haven't tried Wayland)
ben7799 3y ago
For it's time the way X did things was incredibly elegant and it worked really well and did things that seemed very sophisticated long before other systems could handle remote desktops. There's a lot of stuff that seems hackish about modern stuff, but the needs are different. (Perhaps it seems worse to me when the modern stuff is grafted on top of X) The thing that I remember being horrific about X was the abuse of pointers in some of the toolkits like Motif. When GTK came along it seemed a lot easier to write to. As did Tk.
- rwmj 3y ago
  XView (https://en.wikipedia.org/wiki/XView https://en.wikipedia.org/wiki/XView) was a really great way to write GUI applications from C programs. It extensively (ab-)used varargs: frame = (Frame)xv_create (NULL, FRAME, FRAME_LABEL, argv[0], XV_WIDTH, 200, XV_HEIGHT, 100, NULL); panel = (Panel)xv_create (frame, PANEL, NULL); (void) xv_create (panel, PANEL_BUTTON, PANEL_LABEL_STRING, "Quit", PANEL_NOTIFY_PROC, quit, NULL); xv_main_loop (frame);
crotchfire 3y ago
Another awesome aspect of X11: Xembed. Since it's "windows all the way down" you can have apps (rather than the window manager or root window) be the parent of other app windows. Two nifty examples of this: * https://tools.suckless.org/tabbed/ https://tools.suckless.org/tabbed/ * https://surf.suckless.org/ https://surf.suckless.org/
- odiroot 3y ago
  AFAIK this is how audio plugins are embedding themselves in DAWs on Linux. No idea how that's gonna work on Wayland.
- Dwedit 3y ago
  Win32 does allow you to change a top-level window into a child window of another process. You just get terrible performance if you actually attempt to do this. For a more practical way to simulate a top-level window being a child window of another program, you make the top-level window Borderless, and perform all the necessary window management to maintain position, dimensions, and Z-order.
  - ptx 3y ago
    Why do you get terrible performance? I vaguely recall reading that doing this ties the input queues together, so that all (input?) messages get dispatched to both processes, which then both need to have their message loops respond in a timely fashion. Is that it? Anyway, I believe the Microsoft Management Console (MMC) actually does this. The content windows (at least in some cases) belong to a different process than the surrounding UI. Also, WebView2 (the new Chromium-based Edge webview) runs out-of-process, but maybe it does some things in the embedding process to improve performance?
    - Dwedit 3y ago
      Microsoft Management Console loads DLLs into the process, it does not use a separate process for the snap-in. (Just checked this in a debugger) As for why there would be bad performance for putting a window into another process's window, I can only speculate. It takes something like 10000+ CPU cycles for Windows to finish switching to a different thread or process. If this is happening for every message that is handled by both the parent and the child window, that would be a lot of overhead. I haven't checked if the Out-of-process webview is the EXE that owns the window or not.
LASR 3y ago
I mean if we disregard the name, this is a very common architecture. Everything is a DOM node etc.
kelnos 3y ago
> ou can still find this many-window style is in some old fashioned X window managers, such as fvwm. When fvwm puts a frame around a window (such as the ones visible on windows on my desktop), the specific elements of the frame (the title bar, any buttons in the title bar, the side and corner drag-to-resize areas, and so on) are all separate X sub-windows. This isn't even really that old-fashioned. Any X11 WM that draws server-side-decorations is going to do this to some extent. I didn't realize fwvm uses so many windows for its decorations, but at the very least, a WM is often going to reparent the window created by the client as a child of a WM-created window, where the titlebar and drag-handle-borders will be drawn. I imagine GNOME/X11 generally doesn't do this anymore, due to their bizarre obsession with client-side decorations. But any (IMO) sane WM that agrees with me that it's a good user experience to make all windows look visually similar, will do something like this.
- NekkoDroid 3y ago
  > But any (IMO) sane WM that agrees with me that it's a good user experience to make all windows look visually similar, will do something like this. Have you looked at Discord on Linux? It ~~not using~~ trying not to use CSD just looks fucking terrible and has been one of my main grips with it... If an app isn't designed around having SSDs (or is something like a game) it just looks majorly out of place.
- adastra22 3y ago
  It's how Windows does it. My memory is getting hazy, but I'm pretty sure it's how macOS Classic did too back in the day. OP is one of today's lucky 10,000 I guess.
dusted 3y ago
I was surprised the first time I wrote a GUI framework in C, and i happened to be like this as well, everything on the screen just happens to have the properties which a window has.. A position, bounds, a drawing call, some child elements. So it emerges naturally that everything is, at the very least, a window. So yea, I'd argue this is not some strange quirk of the X-Window system, but rather a natural property which the wise hackers decided not to spend extra effort on trying to tame.

194 points by ingve 3y ago

I never thought of this as a peculiarity of the X Window System (though the client-server aspect of it was a lot of what made X, X), but I keep forgetting that this is not something modern developers know about.

robertknight 3y ago

This is not unique to X. Windows for example uses the same kind of "HWND" object for buttons as for top-level windows. Windows doesn't have the same client/server overhead as X though. In Qt, there is an option to use either native windows for individual widgets or "alien" windows, in which only the top level widget is a native window - https://doc.qt.io/qt-6/qwidget.html#native-widgets-vs-alien-widgets https://doc.qt.io/qt-6/qwidget.html#native-widgets-vs-alien-....

pjmlp 3y ago
Yeah it was already the way of doing GUIs in 16 bit days.
rob74 3y ago
Yup... I was working on a password manager application for Windows a few years ago, which was easy for most applications using the native UI because of all controls having window handles - and was then disappointed that it didn't work in cross platform apps such as Firefox.
wruza 3y ago
GTK also uses windows for input-related widgets. It’s simply convenient to have a separate window context. Although these windows are GDK windows, which may or may not have system windows underneath, afair.
raphlinus 3y ago
Good further reading on this change is "Windowless controls are not magic"[1] from Raymond Chen, and the followup "Windows are not cheap objects"[2]. It's a fascinating tradeoff space. I think fine-grained windows worked reasonably well on limited hardware but did not scale to super-rich applications like web browsers, or a more sophisticated imaging model where widgets need to be composited with alpha-transparency. [1]: https://devblogs.microsoft.com/oldnewthing/20050211-00/?p=36473 https://devblogs.microsoft.com/oldnewthing/20050211-00/?p=36... [2]: https://devblogs.microsoft.com/oldnewthing/20050315-00/?p=36183 https://devblogs.microsoft.com/oldnewthing/20050315-00/?p=36...
- pillusmany 3y ago
  90s apps used these Windows handle controls and it was not a performance problem. On computers 100 slower than today and with 1000 times less memory. BTW, the current Windows Task Manager still shows the total HANDLE count on the CPU page. They were not used in apps with complex UIs because native controls were hard to skin and didn't work very well when their size was very small (as complex UIs tend to need)
  - bitwize 3y ago
    > 90s apps used these Windows handle controls and it was not a performance problem. For a while there, at least on Windows 3.1 and before, possibly some Windows 9x versions -- you had a GDI heap and USER heap of 64k each (one 16-bit x86 segment). If you allocated too many HANDLEs, you could blow one of these heaps. So it still made sense to be judicious about how many windows you created. Most Web browsers and word processors, for instance, drew their documents in the client area and did not use subwindows to position text elements.
  - adzm 3y ago
    Note the HANDLE count is kernel objects; windows and graphics objects will show as USER and GDI respectively. Each of these has its own heap and limits.
  - Someone 3y ago
    > 90s apps used these Windows handle controls and it was not a performance problem. That depends on the overhead per window. Microsoft Windows could use nested windows because it had separate Graphics objects to store such things as the current drawing pen, its position and the current font to use for drawing (https://learn.microsoft.com/en-us/windows/win32/api/gdiplusgraphics/nl-gdiplusgraphics-graphics https://learn.microsoft.com/en-us/windows/win32/api/gdiplusg...) In comparison, on the classic Mac every window had a GrafPort that defined a boundary region, a clipping region, the current pen position, size, drawing pattern, etc. The Mac could have such heavy-weight window objects because it didn’t nest windows. Instead, each window had a single list of controls that were much lighter-weight. my gut feeling says separating the drawing state from windows as in MS Windows is the better choice, but I also think having separate entities called “windows” and “controls” as on the Mac is the better choice. (its documentation is ‘less than stellar’, but it appears GrafPort still exists: https://developer.apple.com/documentation/applicationservices/grafport https://developer.apple.com/documentation/applicationservice...)
Stratoscope 3y ago
Traditional Microsoft Windows apps do have one oddity here: the "client" and "non-client" areas. The non-client area included stuff like the title bar, min/max/close buttons and system menu icon, and resizing borders. The client area was where your app would put its content, including any child windows like buttons and list boxes. Many of the window messages for the client area had corresponding non-client messages, for example WM_PAINT and WM_NCPAINT. All of these messages would arrive in your GetMessage/DispatchMessage loop, but you would generally ignore the WM_NC versions and DispatchMessage would send them to the Windows code for default processing. OS/2 Presentation Manager took a more elegant approach here (but probably slower). You had one main window and everything inside it - both "client" and "non-client" stuff - was child windows. So you just had one set of messages for everything, no WM_NCxxxx messages at all. The client area was a child window, with other child windows for the non-client doodads.
- Dwedit 3y ago
  Non-client area also applies to controls (non-top-level windows) as well. For example, the border on a text box is part of the nonclient area of that window.
- fragmede 3y ago
  Oh god, WM_PAINT. that takes me back. I'm not convinced that css is better, given how many lives were wasted trying to get a responsive 3 column view to work before flex box, but here we are.
  - ale42 3y ago
    And something behind still needs WM_PAINT to display the thing styled by CSS... at least if it's displayed on a Windows machine
- barrkel 3y ago
  One object receiving different messages for painting its innards vs its chrome isn't particularly ugly. Most apps don't want to customize the chrome so they'll let the base class handle those messages, but the option is there. Windows is kinda smalltalk-like in its window message system.
AceJohnny2 3y ago
I remember when Qt introduced the "alien windows" concept, in 2007: https://web.archive.org/web/20080205085059/http://labs.trolltech.com/blogs/2007/08/09/qt-invaded-by-aliens-the-end-of-all-flicker/ https://web.archive.org/web/20080205085059/http://labs.troll... As they say, they had to do it to eliminate flicker. Which goes to show that if your elegant design can't scale, it will be corrupted until it can. Something something "worse is better"
codedokode 3y ago
Windows (unlike X) had built-in windows classes (for example: buttons, checkboxes, input fields) that you could use to turn a window into a standard control. That's why idea "everything is a window" worked well in Windows.
kragen 3y ago
i assume by 'windows' you mean 'microsoft windows', because otherwise your comment makes no sense smalltalk has worked this way since at least 01976, but the word they used instead of 'window' was 'view'. see for example steve burbeck's 01992 'how to use model-view-controller' which is describing smalltalk-80 https://www.researchgate.net/publication/238719652_Applications_programming_in_smalltalk-80_how_to_use_model-view-controller_mvc https://www.researchgate.net/publication/238719652_Applicati... > Views are designed to be nested. Most windows in fact involve at least two views, one nested inside the other. The outermost view, known as the topView is an instance of StandardSystemView or one of its subClasses. The StandardSystemView manages the familiar label tab of its window. Its associated controller, which is an instance of StandardSystemController, manages the familiar moving, framing, collapsing, and closing operations available for top level windows. Inside a topView are one or more subViews and their associated controllers which manage the control options available in those views. The familiar workspace for example has a StandardSystemView as a topView, and a StringHolderView as its single subView. A subView may, in turn, have additional subViews although this is not required in most applications. so it's not a peculiarity of x-windows; it's how windows/icon/menu/pointer guis have been built since the beginning. (i'd say 'it's how guis have been built since the beginning' but of course sketchpad, grail, nls/augment, and genesys didn't work this way, and they were certainly graphical user interfaces, even if very different in style.)
- samatman 3y ago
  > i assume by 'windows' you mean 'microsoft windows' Yes of course he did, and you don't have to guess, because the phrase "Windows for example uses" makes Windows a singular noun, compare with "windows for example use". There is no possible ambiguity in the post you replied to.
  - kragen 3y ago
    sam, knock it off find a hobby other than harassing me on hn if you can't control yourself, take a break from hn (most recent previous incident, though not the only one: https://news.ycombinator.com/item?id=39402249 https://news.ycombinator.com/item?id=39402249)
omnibrain 3y ago
The Start button is (or at least used to be) a Window. And in the first Release of they forgot to remove the window control menu - the thing that opens/used to open when you click the program icon on the top left corner. Obviously there was no program icon to click, but you could use a shortcut to open it. Then you could select "move" and move the start button on the task bar or even close it. After you closed it, it was gone and you had to kill explorer.exe via task manager and restart it, to get it back. I can't remember the shortcut, it must have been something like alt+-. In older programs this menu is still around and you can still use it to close programs, like you did in Windows 3.1 days. Even doubleclicking the icon in the top left corner still works to close those programs.
- ale42 3y ago
  As far as I remember, Alt+- opens the menu of an MDI child window. For the current window (which is generally more useful, MDI applications being very rare these days), it's Alt+Space as mentioned by several people.
- ankurdhama 3y ago
  I still use the window menu shortcut Alt+space and then C to close the window, it is more easy to press compare to Alt+f4 (such a non-ergonomic key combination, compare to macOS cmd+w)
  - WorldMaker 3y ago
    Ctrl+Q works in most (though yes, certainly not consistently all) Windows applications. Cmd+Q is also what you'd use on macOS to quit an entire application (Cmd+W is close single window), so the cross-platform ergonomics/muscle memory are actually somewhat preserved. Most Windows applications that still use MDI for some reason or that have tabbed browsing interfaces (appropriately) generally use Ctrl+W for window or tab closing, respectively.
- toast0 3y ago
  > I can't remember the shortcut, it must have been something like alt+-. It's alt+SPACE. Very handy if you manage to get a window off screen, you that menu almost always shows up on screen, and you can select Move (possibly by hitting m), and then move (or drag) your mouse and the window comes back.
fsckboy 3y ago
>Windows doesn't have the same client/server o̶v̶e̶r̶h̶e̶a̶d̶ ̶a̶s̶ ̶X̶ ̶t̶h̶o̶u̶g̶h̶ ...features and functionality as X, regretably
asveikau 3y ago
> Windows doesn't have the same client/server overhead as X though. Yes it does. You think they run that in the same address space? When there are multiple processes with different privilege levels running their UIs? Maybe this comment was accurate for Win3.1, but for a long time there is absolutely a client server architecture behind it. Anyway one of my favorite uses of HWND is to use a non visible window as a worker thread mechanism. Each HWND is tied to a message pump in the thread that owns it. So you can send it messages, and boom, you have a thread API...
- p_l 3y ago
  On all "Classic" Windows and on NT from NT4 until DWM in Vista, GDI was not client-server instead it would draw directly to VRAM With some kernel assistance on NT (before NT4, GDI calls were handled by separate server process). This is why misbehaving application could get you the famous "trailing window" effect where moving a window would leave partly painted trace of it behind - you had to wait for some other coffee to properly repaint that other area. With DWM, your GDI windows are backed by memory that at most will be a texture in DirectX, which will be then composited by DWM (equivalent of X11 extensions to capture window drawing into pixmap instead of lowest common denominator implementation of DIX/DDX that would draw immediately to framebuffer)

ironmagma 3y ago

'Programming X is like reading one of those French philosophers where afterwards you start wondering whether you really know anything for sure.' [1] [1] Thomas Thurman - https://www.youtube.com/watch?v=GWQh_DmDLKQ https://www.youtube.com/watch?v=GWQh_DmDLKQ https://people.freedesktop.org/~daniels/lca2013-wayland-x11.pdf https://people.freedesktop.org/~daniels/lca2013-wayland-x11....

deleted 3y ago
[deleted]

Animats 3y ago

Confusingly, in classic X Window terminology, the "server" is the display manager running on the user's workstation, and the "client" is the application running on a remote machine that wants to display something. This article uses that terminology.

lproven 3y ago
Because that is the correct terminology in this context.
taeric 3y ago
Honestly, this isn't that confusing. I think even back in the day, it didn't take long to understand the reasoning behind this naming.
ssl-3 3y ago
It's OK terminology. In networking, clients usually initiate the connection to a server, a server is usually intended to be able to serve multiple clients, and servers tend not to talk much with other servers that might exist on a network. And that's how it be with the X Window System.
- starspangled 3y ago
  Well, and obviously X is providing a windowing and drawing service to the clients. Doesn't matter who initiates the connection or the M:Nness of the communication, X is providing the service to the applications, and they are not performing any service for X.
  - lproven 3y ago
    Yup. Compare: Windows Services for Linux.
kazinator 3y ago
It's the reverse that would be confusing. Your "web client" would have to be called an "X server"! I suspect the X terminology is confusing to two groups of people: 1. Those who are used to the idea that when the computer and the display are separated by distance, the local display is a mirror of the remote machine's desktop, courtesy of a service on that machine to which the local display connects as a client. X isn't a remote desktop mirroring protocol, though; those people have the wrong model. 2. Those who are used to the idea that a server is something that runs in the background (daemon), not visible in the desktop. How can the X desktop be the server, when it's shoving pixels in your face, right in the foreground? Well, you know, someone serving you a punch also does it in your face.

jhallenworld 3y ago

An interesting part of the X protocol is XGrabPointer (and XGrabKeyboard). These force events to be delivered relative to a particular window instead of to the focus window. Cascading menus can be implemented by making a stack of such grabs: push when you open a submenu, pop when you ESC back to parent. Anyway, so it's very useful that everything in X is a window, because it works well with this input grabbing. Also it's nice for borders: the border was one outer window, and the drawing area was a smaller inner window. I don't quite remember anymore, but I think a bad part about using the X's windows is that the coordinates were limited. Sure you only need 12-bits or so for screen coordinates, but it's convenient if you had 64-bits to handle any possible clipping or relative offset situation.

dmazzoni 3y ago
I don't think that's unique to X windows, though - pretty much all GUI platforms have a similar concept, otherwise any time you accidentally drag your mouse outside of a window you'd start sending events to another application. On MS Windows it's called "Capture".
- mschuster91 3y ago
  > otherwise any time you accidentally drag your mouse outside of a window you'd start sending events to another application. macOS does precisely that. Open a Chrome window and put a Finder window over it, then move your mouse and do a scroll gesture - the target will always be whatever is below the mouse cursor at that moment, even if you don't actively select the window.
  - marwis 3y ago
    That's also the behavior on Windows
    - emi2k01 3y ago
      It's also the behavior on Linux with X11 (haven't tried Wayland)

ben7799 3y ago

For it's time the way X did things was incredibly elegant and it worked really well and did things that seemed very sophisticated long before other systems could handle remote desktops. There's a lot of stuff that seems hackish about modern stuff, but the needs are different. (Perhaps it seems worse to me when the modern stuff is grafted on top of X) The thing that I remember being horrific about X was the abuse of pointers in some of the toolkits like Motif. When GTK came along it seemed a lot easier to write to. As did Tk.

rwmj 3y ago
XView (https://en.wikipedia.org/wiki/XView https://en.wikipedia.org/wiki/XView) was a really great way to write GUI applications from C programs. It extensively (ab-)used varargs: frame = (Frame)xv_create (NULL, FRAME, FRAME_LABEL, argv[0], XV_WIDTH, 200, XV_HEIGHT, 100, NULL); panel = (Panel)xv_create (frame, PANEL, NULL); (void) xv_create (panel, PANEL_BUTTON, PANEL_LABEL_STRING, "Quit", PANEL_NOTIFY_PROC, quit, NULL); xv_main_loop (frame);

crotchfire 3y ago

Another awesome aspect of X11: Xembed. Since it's "windows all the way down" you can have apps (rather than the window manager or root window) be the parent of other app windows. Two nifty examples of this: * https://tools.suckless.org/tabbed/ https://tools.suckless.org/tabbed/ * https://surf.suckless.org/ https://surf.suckless.org/

odiroot 3y ago
AFAIK this is how audio plugins are embedding themselves in DAWs on Linux. No idea how that's gonna work on Wayland.
Dwedit 3y ago
Win32 does allow you to change a top-level window into a child window of another process. You just get terrible performance if you actually attempt to do this. For a more practical way to simulate a top-level window being a child window of another program, you make the top-level window Borderless, and perform all the necessary window management to maintain position, dimensions, and Z-order.
- ptx 3y ago
  Why do you get terrible performance? I vaguely recall reading that doing this ties the input queues together, so that all (input?) messages get dispatched to both processes, which then both need to have their message loops respond in a timely fashion. Is that it? Anyway, I believe the Microsoft Management Console (MMC) actually does this. The content windows (at least in some cases) belong to a different process than the surrounding UI. Also, WebView2 (the new Chromium-based Edge webview) runs out-of-process, but maybe it does some things in the embedding process to improve performance?
  - Dwedit 3y ago
    Microsoft Management Console loads DLLs into the process, it does not use a separate process for the snap-in. (Just checked this in a debugger) As for why there would be bad performance for putting a window into another process's window, I can only speculate. It takes something like 10000+ CPU cycles for Windows to finish switching to a different thread or process. If this is happening for every message that is handled by both the parent and the child window, that would be a lot of overhead. I haven't checked if the Out-of-process webview is the EXE that owns the window or not.

LASR 3y ago

I mean if we disregard the name, this is a very common architecture. Everything is a DOM node etc.

kelnos 3y ago

> ou can still find this many-window style is in some old fashioned X window managers, such as fvwm. When fvwm puts a frame around a window (such as the ones visible on windows on my desktop), the specific elements of the frame (the title bar, any buttons in the title bar, the side and corner drag-to-resize areas, and so on) are all separate X sub-windows. This isn't even really that old-fashioned. Any X11 WM that draws server-side-decorations is going to do this to some extent. I didn't realize fwvm uses so many windows for its decorations, but at the very least, a WM is often going to reparent the window created by the client as a child of a WM-created window, where the titlebar and drag-handle-borders will be drawn. I imagine GNOME/X11 generally doesn't do this anymore, due to their bizarre obsession with client-side decorations. But any (IMO) sane WM that agrees with me that it's a good user experience to make all windows look visually similar, will do something like this.

NekkoDroid 3y ago
> But any (IMO) sane WM that agrees with me that it's a good user experience to make all windows look visually similar, will do something like this. Have you looked at Discord on Linux? It ~~not using~~ trying not to use CSD just looks fucking terrible and has been one of my main grips with it... If an app isn't designed around having SSDs (or is something like a game) it just looks majorly out of place.
adastra22 3y ago
It's how Windows does it. My memory is getting hazy, but I'm pretty sure it's how macOS Classic did too back in the day. OP is one of today's lucky 10,000 I guess.

dusted 3y ago

I was surprised the first time I wrote a GUI framework in C, and i happened to be like this as well, everything on the screen just happens to have the properties which a window has.. A position, bounds, a drawing call, some child elements. So it emerges naturally that everything is, at the very least, a window. So yea, I'd argue this is not some strange quirk of the X-Window system, but rather a natural property which the wise hackers decided not to spend extra effort on trying to tame.