Hacker News Reader

Comment by paol | Hacker News Reader

I believe X Windows owes much of its incredible longevity to the "provide mechanism not policy" mantra that its designers took very seriously.

Having the toolkit in the server would necessarily force it to define and enforce lots of policy. This increases complexity, increases dependency (coupling) on part of the clients, and after all that you still have the problem that policy simply doesn't age well.

It still boggles my mind a bit that a display stack designed in the 1980s has remained viable to this day. Sure, it's a patchwork, and it's finally being replaced, but it works.

View on HN

A lot of software seems to work best just before it's replaced, and the replacement takes years to catch up. I hope for the best but fear for the worst in the X case.

> its incredible longevity

I get your point, but see it completely differently as GUI programmer. X was steaming pile of s*t. Its "longlevity" was spend cleaning up the mess.

Designers had this stupid idea to do drawing over remote connection, and produced broken design around that. Direct memory access, DRI, OpenGL, screen buffers... Non of that was part of X, but is vitally necessary for GUI.

There is no compatibility in X server design. Good luck running remote X session today. Everyone uses VNC.

Apart from thin clients, X remote display has historically been used for combining applications from multiple systems on a single display. Those systems could be computers, lab hardware, or anything else.

Indeed, over 25+ years that I've known, and I'd be surrounded by that in the office, not VNC (but some X2go).

The single rubbish X server I've known is (or was) Xceed (or however it's spelt) which people inexplicably used rather than Cygwin's; the first question to ask someone with classes of Emacs problems was whether they were using it.

Or the other way around: multiplexing one X11 application across multiple displays.

On the Usenix trade show floor one year, somebody made a horse racing client that opened connections on multiple X11 servers, and animated horses racing from screen to screen. Many different companies with X11 workstations or terminals were running it at the same time, and horses were running between different brands of computers on the trade show floor, which made a nice point! (About network race conditions ;) It was just black and white, and the graphics were dead simple, so it worked great on everybody's hardware.

Multi Player SimCityNet was implemented in TCL/Tk on X11, which supported opening multiple X11 servers at the same time, even with different kinds of displays, and using shared memory if running locally. Of course there was a limit to how many people could play at once, and it required a reasonably fast network, and every player had to grant full access to their server to the client. And anyone could type TCL expressions into the chat window and hit escape to execute them, so it probably wasn't very secure, and certainly was easy to cheat: "sim Funds 9999999<esc>"

https://www.youtube.com/watch?v=_fVl4dGwUrA

https://www.donhopkins.com/home/catalog/simcity/simcity-anno...

https://www.donhopkins.com/home/catalog/simcity/simcitynet.h...

>SimCityNet: a Cooperative Multi User City Simulation

>SimCityNet is an animated interactive system simulation game, providing a set of rules and tools for planning and building a complex dynamic simulated city. Several people on different workstations can participate in the same game, cooperating and coordinating their actions over the net. Working together, you can zone land use, hook up the power grid, build roads, bridges, parks and stadiums, raise taxes, and even summon disasters, causing the city to grow and thrive, or crumble and die. SimCityNet features multiple city views and maps with overlays, simultaneous editing and user interface interaction, "voting panels" for group decision making, and multimedia communication and annotation features ("bridges between players").

>The multi user interface supports communication via three media in parallel: text, sound, and graphics. It includes a scrolling text log for telegram messages, a networked audio server for sound effects and voice intercom, and shared cursors and graphical overlays for pointing, gesturing, annotating and editing the map.

is the demo still available for download somewhere? the FTP link on that page is broken.

We had effective direct-manipulation GUIs long before OpenGL, so that can't be it, though we did have DMA and graphics buffers in the '80s and DRI wasn't relevant.

The WinForms API also survives from the mid 80s, and is interestingly different. I believe the classic controls were originally drawn in the kernel?

You probably mean Win16/Win32, not WinForms. But it only survives in the sense that it’s still there, not in the sense that it’s still useful. How many applications created in the last five years use Win32 for anything but creating a top-level window (usually via Chromium/Electron)?

> How many applications created in the last five years use Win32 for anything but creating a top-level window (usually via Chromium/Electron)?

I think that you're in a bubble for that one. Many business domain-specific applications are still directly written against Win32 even today. UWP didn't manage to catch up for now either.

Electron usage is mostly only in startup-y apps and some IDEs.

No experience is universal, so I'm curious in what industry you encounter Win32. Or do you mean WinForms? I often work with industrial manufacturing companies in Europe, with a mindset about as far from that of Silicon Valley startups as you can imagine. You usually won't find Electron there. Many "legacy" projects are in WinForms. But for newer stuff, I see lots of WPF and Qt projects, both of which don't use native controls.

Qt has more impact as far as I can see. However, where I went, I didn't see it resulting with anything deployed to production yet...

That is also my experience.

Outside games, most modern Windows applications, specially in the areas you mention, I have also seen WPF/Qt, with plain old Win32 just as glue for underlying OS APIs.

There are still some odd ones that keep doing MFC, or enjoy a mix of Delphi/C++ Builder.

The only old style C Win32 applications I have seen in the wild during the last decade tend to be surviving applications from the 90's, done by companies not so much into Windows C++ frameworks.

How many Windows applications have been created in the last five years at all?

Not much of a PC gamer, are you? :)

We were talking about widget libs and non-cross-platform apps, so PC games didn't come to mind for both reasons.

I still mourn the days of shareware.

Sorry for the pedantry, but you're thinking of the Windows API, specifically the user interface bit (user32.dll as of Windows 95 and NT but it existed before) which is based on GDI which is hardware accelerated. It still exists but it rarely used for new applications today, but it was certainly in use for a very long time.

WinForms was briefly promoted as a successor, based on GDI+. It was quickly abandoned, as was GDI+ which never got hardware acceleration, in favour of WPF which is based on DirectX which is obviously hardware accelerated. But in that small time it caught on and continues to be used for new projects because it's a simpler programming model than WPF and it's not obvious in Visual Studio that it's been abandoned (it's not quite deprecated).

One can use WPF just like WinForms, with code behind and plain drag-and-drop of components.

The problem is that when beginners start searching for tutorials they usually land on MVVM, data binding and how WinForms style is a bad practice and they end up feeling overwhelmed.

Ironically MVVM is also possible to do in WinForms, but the capabilities aren't as rich as in WPF, so very few end up going that route.

WinForms is much more recent than that. It was introduced along with the .NET Framework around 2000.

The original classic controls were implemented in USER.EXE (which was actually a DLL) starting in Windows 1.0 around 1985. WinForms wrapped these controls and others in a .NET interface.

MS Windows is definitely a good counterpoint to this blog post. Whatever the kernel/userspace split (which has changed over time), the basic Windows model is that the logic & code of the windowing system is all in the 'server' (i.e. the OS libraries, sometimes including kernel-space code).

The 'clients' (Windows applications) don't have to do their own font rendering, widget drawing, etc, they can use several different 'server' APIs to do so. Even so, the framework has proved remarkably long-lasting, with decades-old programs still capable of running on modern systems.

Actually the logic and windowing happens in each client in user space, which is why you can’t build alternative window managers, and Microsofts policy of compatibility ‘shims’ and hacks that allow chosen old software (and they choose a lot of software) to work on modern systems has nothing to do with it.

Have a quick search online, and you'll find plenty of alternative window managers for Windows. But it's besides the point, because both styles of graphical windowing systems can support alternative window managers.

The Windows ‘solution’ is really fragile and dangerous because it involves injecting code into all programs.

If there’s a vulnerability the whole system is compromised, if there’s instability the whole system crashes and if part of the system is separated out, like what Windows does with windows belonging to elevated processes, these windows follow the original rules set by Microsoft.

It makes a lot of sense for multiple applications share the same toolkit implemented in a "user interface manager", the same way they all share a "window manager", running locally with the window server. Of course the browser is now a "user interface manager" itself. It also makes a lot of sense to use a web browser as the window manager and user interface manager itself: instead of running it on top of another window system, the web browser should be the window system and window manager.

Simon Schneegans, the author of Gnome Pie, and creator of the Coral Menu and Trace Menu, wrote some interesting thoughts about "Open Pie", and the evolution of Gnome-Pie for Wayland towards being a shared "pie menu user interface manager" that applications use via D-Bus.

Gnome-Pie: Homepage of Gnome-Pie, the slick application launcher for Linux.

http://schneegans.github.io/gnome-pie

Gnome-Pie

https://vimeo.com/30618179

The Trace-Menu

https://vimeo.com/51073078

The Coral-Menu

https://vimeo.com/51072812

OpenPie! Gnome-Pie will die.

http://schneegans.github.io/news/2018/05/31/openpie

>On Wayland, there are at least six major issues which make applications such as Gnome-Pie basically impossible. I have described these issues in one of my previous posts in more detail - here they are listed again:

>No client side window placement - Menus cannot be opened at cursor location

>No global input grabbing - When a menu is opened, you will still be able to Alt-Tab to another application, etc.

>No global key bindings - No global hot-keys from within Gnome-Pie. Only cumbersome configuration in your window manager

>No mouse pointer warping - Leads to problems when menus are opened close to screen edges

>No client side application management - No Alt-Tab window list features

>No sending fake keyboard events - No simulated key strokes or deferred activation anymore

>However, I still believe that many users would benefit from efficient and eye-candy (pie-) menus on Linux. Particularly, the very inspiring article on pie menus by Don Hopkins convinced me, that creating a follow-up project for Gnome-Pie would be a pretty awesome idea.

>"My goals are to enable developers, designers, and users to easily create and edit their own pie menus, and provide free software, tested designs, smart editors, automatic layout, support and guidance to help people come up with fun, easily used, memorable, Fitts-friendly designs." - Don Hopkins

>I got reminded that I once had the idea of OpenPie, a novel architecture for Gnome-Pie. Now I realized that this new architecture can solve at least some of the problems listed above.

>Introducing: OpenPie

>The main component of OpenPie will be a daemon running in the background listening on the D-Bus for incoming menu-open requests. Any application can send such a requests - a menu will pop up, the user is going to make a selection and the OpenPie daemon will report the selected menu item back to the application.

[He goes on to describe how OpenPie will use the D-Bus interface, and support new menu types.]

Reply on news.ycombinator.com