Could they? The X11 devs thought otherwise and that’s why Wayland is here.
1 Like
There’s someone attempting it here: phoenix - A modern X server written from scratch
All GUI applications receive their input from the display server, regardless of how they are packaged or which framework they are using.
So in assuming that KWin, or a component it delegates do, does the mapping, it should apply to all windows that receive events from it.
Would be interesting to know what causes this.
Could be a limitation of the nesting, a decision by the window manager, potentially even a bug in either of the involved components.
A client should normally be able to center a splashscreen on top of their main window.
Your workaround with two processes sounds even less likely to work since two programs now need their windows to line up.
1 Like
I believe it really depends on where you look, I see it as this, Your always gonna have distros like Arch, And Gentoo for those power users, While you have the stuff like Ubuntu and SteamOS for people less eager to tinker, I don’t believe there’s a world where the power user would be left behind, I don’t believe immutable distros would replace normal distros, I believe they can coexist. This is all just my opinion and I could be wrong, However I just really can’t see it getting to the point of ruining Linux’s appeal
2 Likes
This is indeed an interesting approach in various aspects.
Much leaner architecture by going for the same hardware interfaces already widely used by Wayland compositors, allowing them share a lot of the work done for those, potentially even contributing in some way.
On the protocol/API side they are essentially doing what Wine is doing for Windows apps.
They start with a minimal viable subset and then add features as they see applications fail or misbehave-
Obviously with the advantage over Wine that a lot of the applications are actually available in source form and can be studied in detail when such an incompatibility happens.
However, unlike Wine, they do want to deviate from established behavior to improve security/privacy.
In my opinion this is their most ambitious goal as it will result in some breakage on purpose and less obvious then Wayland being different by design.
1 Like
Part of this sounds like overthinking. Because an application that spawns a window should have global coordinates regardless of what it displays. Stuff should be nested to avoid cases you mention.
One could also consider it the opposite. Driving feature development based on requirements and constraints, especially given the wide range of both across the spectrum of use cases.
The point about the global 2D coordinate system was that this is not always feasible, e.g. differently oriented 2D surfaces in 3D space.
If a situations is simple enough to allow that then the compositor for such a system can of course announce the availability of such a feature. The clients can then react to that announcement instead of silently failing operations or getting nonsensical data.
One interesting development in this context is the provision of virtual address spaces called Zones, quite like using virtual memory spaces instead of physical ones.
This increases the number of systems which can provide that, e.g. the aforementioned 2D surfaces in 3D space or tiles of a tiling window manager.
Again with the advantage of availability being detectable early on (when connecting to the display manager).
Yes, correct.
Most applications work with a single primary window and have only sub windows which might need to be shown relative to that, potentially making this window known to helper processes via xdg_foreign
See also the Zonessystem mentioned above for another approach of nesting/grouping applications together in a flexible and detectable way.
1 Like
I believe it is some sort of window grouping that causes the offset main game window in Wayland. The splash and main game windows are seen as a group and because the splash is already in the centre, the main window is not allowed to also be in the centre (even though the splash window is no longer displayed).
1 Like
Thanks for the in-depth clarification.
1 Like
Yes, that might be the cause or part of it. Would explain why it works when you have two processes.
Might also work if the splash screen showed up on top of the primary window to indicate progress while the main content is prepared.
Maybe the window managers receives the “hide” of the first window after the “show” request of the second.
Could also depend on the chosen approach for XWayland integration. Some handle X11 window management as part of the Wayland window manager, some delegate it to a dedicated X11 window manager.
1 Like
Traditional mutable distributions (like Fedora, Ubuntu, Debian, and Arch Linux) still represent the vast majority of the Linux landscape, likely accounting for over 90% of available distributions. – Google Search
Having recently moved entirely off W to Ubuntu I can think of a lot of reasons why !!!
I have enormous respect for power users (and dare I say, software geeks). They are primarily responsible for having brought Linux (and so many apps) to where it / they are today … so I get your concern.
But I would think with the many Linux distro’s out there you can (and prolly always will) find one you can “tinker” and play with. The fact that a ‘standard’ is being focused on (for people like me and a gazillion others) is a good thing (and a long time coming). Why issue concern about growth when there really is no ‘down side’.
There is however a huge positive side. Linux is moving from power user exclusivity (those with time to learn complex tech stuff & deep dive into an o/s) to main stream basic users, (people who need a reliable and simple system to just use) and that is a very, very good thing for Linux and for us. I for one am ecstatic about it.
2 Likes
Firstly, welcome to Linux!
I’m actually more for standards than most on Linux - developing a cross platform game is challenging given the variety of distros, desktop environments, file system layouts, library versions etc. etc.
I’m also all for ease of use. I remember compiling an early version of KDE when it was in alpha thinking it was great that a proper user interface was coming to Linux. More recently, before I used the last few versions of Kubuntu, I used Mint whose Cinnamon desktop is renowned for its friendliness for beginners which I appreciated even though I had many years experience using Linux.
All that to say I have no problem with Linux improving ease of use and being beginner friendly. It is just that I would be sad if the configurability of it were to be diminished. I think Linux should be able to support both new and power users.
1 Like
I had an exchange with the GTK people a few years ago about a similar topic. I was told, in no uncertain terms, that GTK 4.0 would be taking window placement methods out of its API. But it seems to be disappearing from other GUI toolkits and window managers, too.
But, we’re lucky that a few freelancers are still working on such things. Like the guy who wrote Remember Window Positions for KDE. As long as window manager and toolkit developers don’t actively block such addons, we’ll still be able to use our multi-monitor set-ups without going completely mad.
What I still don’t understand is why they’d remove such functionality. At first, I thought it might be because they were trying to make everything work on a phone, but that would be nuts… wouldn’t it?
2 Likes
In the end GTK 4 released with traditional API.
Indeed.
Restoring windows (position, state, etc) is now also part of the standard desktop protocols.
Has been in testing for over a year and matching implementations in at least KWin, Mutter, Qt, GTK and Chromium.
Hard to tell. GTK developers might prefer to only have API that works on all targets or have UI/UX design considerations which influence their API design.
Maybe.
There is obviously a certain appeal to be able to target mobile devices, however they are certainly aware that GTK is, at least for the moment, mostly used on desktop/laptop systems.
Still, a push for mobile could influence architecture, feature and API design decisions.
Linux isn’t monolithic. There are distros that can be completely built from the ground up and others that hold your hand and restrict direct access to be more beginner friendly plus everything in between. As someone who needs to sometimes provide IT support to less tech savvy family, the idea of immutable distros is very welcome for when the inevitable issues come along.
I’m more concerned, however, about Red Hat (IBM) and systemd railroading the Linux community towards more rigid homogeneity, as well as further corporate capture of, and influence over, FOSS projects.
Totally agree with your take. I am annoyed and disgusted with the obsession most developers seem to have with security versus operability. Wayland is a prime example.In development for more than 8-9 years released on an unsuspecting public as the default with many issues still not resolved. Linux is inherently more secure than other systems, so why this almost zealot like obsession with security? It bewilders me and many others too.
To be fair this is rarely used in any discussions as it rarely applies to the subject at hand.
Yes, the base model of operations is to opt-in rather to opt-out, i.e whitelisting some access instead of blacklisting others.
And that is so because it separates privilege domains by default, e.g. processes running as the user, processes running as a system services and potentially even some running as root.
Nowadays we can even go further and confine processes in various ways, e.g. running them inside a sandbox with strictly defined system access capabilties.
Because it makes sense to apply the already established and proven concept of privilege separation on other levels than just file access.
In either case it is the user’s decision to allow certain operations, e.g. by permitting a system wide change or permitting screen and/or input capture.
You could run everything on the highest privilege level, e.g. processes as root and windows through X11, but that should probably be an explicit decision rather than the default.
3 Likes
Systemd is used because it works so much better then the alternatives.
The only power they had was better code.
If you don’t like systemd build a compelling replacement.
3 Likes
Sorry no, it doesn’t make any sense when functions are impaired or removed completely, and that is exactly what has happened. My question which nobody has yet given a satisfactory answer to is “why is security prioritised over function in an inherently secure o/s”?"