[HN Gopher] A peculiarity of the X Window System: Windows all th...
___________________________________________________________________
A peculiarity of the X Window System: Windows all the way down
Author : ingve
Score : 50 points
Date : 2024-03-06 06:33 UTC (1 days ago)
(HTM) web link (utcc.utoronto.ca)
(TXT) w3m dump (utcc.utoronto.ca)
| robertknight wrote:
| 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-....
| pjmlp wrote:
| Yeah it was already the way of doing GUIs in 16 bit days.
| rob74 wrote:
| 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 wrote:
| 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 wrote:
| 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=36...
|
| [2]:
| https://devblogs.microsoft.com/oldnewthing/20050315-00/?p=36...
| pillusmany wrote:
| 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)
| adzm wrote:
| 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 wrote:
| > 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/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/document
| ation/applicationservice...)
| Stratoscope wrote:
| 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 wrote:
| 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.
| AceJohnny2 wrote:
| I remember when Qt introduced the "alien windows" concept, in
| 2007:
| 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 wrote:
| 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 wrote:
| 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_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.)
| ironmagma wrote:
| '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://people.freedesktop.org/~daniels/lca2013-wayland-x11....
| Animats wrote:
| 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.
| taeric wrote:
| 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 wrote:
| 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.
| kazinator wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| That's also the behavior on Windows
| emi2k01 wrote:
| It's also the behavior on Linux with X11 (haven't tried
| Wayland)
| jhallenworld wrote:
| Well I think this is desired behavior. But what if you grab
| a scrollbar (so that the mouse button is held down), and
| drift out of the window? I thought some versions of Windows
| didn't handle this well, the scroll bar would jump back
| home or something unless you kept pointing at it.
| ben7799 wrote:
| 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.
___________________________________________________________________
(page generated 2024-03-07 23:00 UTC)