Hacker News Reader

Comment by c-smile | Hacker News Reader

GTK still misses:

1. Anything close to AdjustWindowRectEx() function. See: https://docs.microsoft.com/en-us/windows/win32/api/winuser/n...

2. MoveWindow(window,rect) where rect is window frame rectangle. Instead GTK has 6 other functions that do something close but no one of them do MoveWindow.

See: https://stackoverflow.com/questions/58103333/set-frame-posit...

Windows has these functions, MacOS has their direct equivalents, but GTK does not have such, IMO basic, functionality.

Will we have anything like that in GTK4?

View on HN

Wayland does not allow clients to make decisions such as the precise placement of windows for security and sanity reasons, so I do not think that these will ever be added.

Then Wayland is kind of stupid. Why is that restriction needed or why do the developers think that it is a good idea to have it?

For example, when the user has arranged the windows of an application in some way, and then wants to save and then restore the placement of windows, how should it be done by the application?

> how should it be done by the application?

It shouldn't be done by the application. It's the window manager's job to manage windows.

As a user, I absolutely do not want applications to be able to put themselves wherever _they_ want. The windows go where _I_ want, and the window manager gives me a single place where I can manage all that.

More specifically, I want to give some applications the ability to place windows where they want, warp the mouse, grab certain keys globally, snoop input, and so on. And I want to give other applications a small sandbox where they can't steal focus or hurt anything.

X11 could have been evolved in this direction by sandboxing applications within little mini-universes within the existing protocol. Windows solved this problem without breaking compatibility: https://en.wikipedia.org/wiki/User_Interface_Privilege_Isola...

I have a fundamental philosophical disagreement with the Wayland and GNOME camp. They believe that they can enumerate all interesting use cases and that each app should fit in one of their pre-defined boxes. I'm old school and believe in making systems that provide mechanism, not policy, and that give applications the ability to do unanticipated things.

>I want to give some applications the ability to place windows where they want, warp the mouse, grab certain keys globally, snoop input, and so on.

This is already how it works. The plan with GNOME and wayland is to put those in the xdg desktop portal so they can be subject to whatever security policy is appropriate. Really, nothing has changed here in regards to how much mechanism is provided or not.

And FYI, X11 can already be sandboxed using those methods in combination with firejail: https://firejail.wordpress.com/documentation-2/x11-guide/

Why don't you propose a protocol to solve the issues you have? If it solves a problem other users have it would get adopted I'm sure (except maybe GNOME).

I'm not a Wayland developer but it's what I observed in the issue tracker of my WM. A limitation is often overcome by a protocol and a basic implementation after. If you put the work in, the wlroots and KDE people are always very nice and will help you get started.

https://github.com/wayland-project/wayland-protocols/tree/ma...

https://github.com/swaywm/wlr-protocols/tree/master/unstable

They did propose a protocol: X11 plus sandboxing, modeled after the windows approach to sandboxing.

And they are free to continue adding features and maintaining their preferred software choices. Nobody else seems to want to do it. IIRC the X11 maintainers are the same people who started Wayland.

> https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fed...

> Once we are done with this we expect X.org to go into hard maintenance mode fairly quickly. The reality is that X.org is basically maintained by us and thus once we stop paying attention to it there is unlikely to be any major new releases coming out and there might even be some bitrot setting in over time. We will keep an eye on it as we will want to ensure X.org stays supportable until the end of the RHEL8 lifecycle at a minimum, but let this be a friendly notice for everyone who rely the work we do maintaining the Linux graphics stack, get onto Wayland, that is where the future is.

But we were talking about Wayland here. You're free of course to fantasize about hypothetical scenarios or propose features to software nobody wants to maintain.

One of the problems is that X is effectively being deprecated in favor of something that isn't X 2.0: it has different goals, different targets, different ideologies, and not to mention different architecture.

Eg Wayland is unashamedly Linux-centric (mind you, definitely not the same as Linux exclusive), while X most definitely isn't. One was designed to allow for remote rendering, one wasn't. One integrates the window manager functionality and one doesn't. The list of course goes on.

The things you list have not really been true in the real world for a long time. Modern Xorg uses the same Linux exclusive APIs as Wayland, is not network transparent, relies heavily on window manager and compositor features, etc. Modern Xorg and Wayland are more or less conceptually identical. Wayland just replaces the X server with a UNIX socket and has a clean slate for APIs.

1. You're conflating X and Xorg.

2. Network transparency is still there and I use it everyday. The problem is toolkits (GTK and others) who decided it would be 'simpler' to redo everything themselves in a canvas. Of course the result of not taking advantages of X primitives was a massive slowdown over the network.

3. Wayland sits at an odd place, not having the advantages of being a proper protocol in the sense of X (complete abstraction from the substrate), while at the same time not having the advantages of being a direct API to hardware (simplicity, performance).

Or, in another words, Wayland is the same as the modern X, minus the legacy core that couldn't be removed from X because it is not extension (anyone using stippled unaliased lines yet?) and plus sandboxing.

Yeah, the end game for this seems pretty horrible. Wayland (still) doesn’t work, and is user-hostile (at least for this user). The BSD’s and most applications I use seem to be sticking with x.org.

Maybe this is the end of portable, open source video stacks.

I have found that “OK, why don’t you just do xyz if you think you’re so smart” shuts down interesting discussion, and that’s what you’ve been doing here. Would you be willing to not do that or explain why you think that isn’t the case here?

No, it does not shut down discussion, it shuts down bikeshedding. There's a large peanut gallery with strong opinions how they would do it, but because they never did something similar, they have no idea what they are talking about and what trade-offs are involved.

Unsurprisingly, people who know these things, for example because they develop it, may disagree with the peanut gallery and do it in a way they consider the best.

I would much rather hear a reason why something wouldn’t work than the responses saying “ok, how would you do it” and “ok, well someone would have done that if it was legitimate but they didn’t”.

It's not that simple; explaining one reason why something would not work means re-examing many of the underlying assumptions and not many like to go deeper than that one problem at hand in isolation. The "ok, how would you do it" forces thinking about underlying issues, because the solution you propose has to account for factors you otherwise wouldn't think of.

It is not a new problem either; this video is 9 years old already: https://www.youtube.com/watch?v=ZTdUmlGxVo0. It is almost one hour long, but well worth to watch to see the two different approaches to clash.

On Mac OS, you can ask the WM to store the geometry for you and recreate it. It's exposed to devs via the NSApplicationWindow (or something) API and then backed by a protocol between the app and the windowing server, leaving the latter in ultimate control.

Wayland doesn't have an equivalent protocol yet, but this is also how it would be idiomatically done there.

But of course macOS also has APIs on NSWindow to move it around, as well as accessibility and AppleScript APIs to do it as a user in a scriptable way. Why the limitation?

Wayland does have some ways (meaning protocols) to do explicit positioning, e.g. relative to a parent owned by the same client (for popups), that have been standardized.

The primary limitation is not to allow clients to set their x,y in the global scene (or even look them up), but there are proposed protocols that allow global positioning in a semantic sense like "I would like to be at the left edge" or "I am an overlay type thing" (z positioning). Some of those are in production use internally to Wayland-based desktop shells, e.g. KDE's Plasma, or used in communities like sway/wlroots+addons (e.g. dmenu implementations).

Why not do x,y? It means you don't have this sort of level positioning code in the apps, which are very expensive or impossible to fix after the fact (apps stop being maintained, etc.) when new ideas come up. Say you want to apply a transform to client windows - scale them, or put them into a 3D sphere in a HMD. Wayland compositors have full flexibility there because the apps don't make assumptions.

> Say you want to apply a transform to client windows - scale them, or put them into a 3D sphere in a HMD. Wayland compositors have full flexibility there because the apps don't make assumptions.

Except that macOS can do all this regardless? WindowServer can do all sorts of transformations on windows, fully independent of the position the window has set for itself. That's how all the fancy Mission Control/Exposé animations work.

With wayland, you can do this and the apps won't notice because of the limits placed upon them earlier: https://www.youtube.com/watch?v=_FjuPn7MXMs

Can macOS do it?

The point of this demo is not practical usability today, but to demonstrate, that global positioning on the desktop as we know today might get much more complex in future. So why shut the door?

macOS can place windows wherever it likes, see Mission Control. It has APIs that can literally reach across processes so you can draw a window’s content as a little “view” in your window if you like, and apply the rich set of CoreAnimation transformations to it. What happens in a case like that is that the window gets placed in a new coordinate system that is orthogonal to its “original coordinates” (since of course it has no idea what would be going on without changes to the application frameworks) and moved and rendered freely. (Again, Mission Control was added with zero work or cooperation on the part of applications, even though they had the “window move” APIs from day one, which was many years prior. I would be entirely unsurprised if one could make a demo like the one you just showed fairly “easily”, barring private APIs and accessibility permissions and such.)

Interesting, thank you.

Yes and users have to unplug monitors to find windows that have done this.

> Why the limitation?

Because users don’t want it? We have window managers and some of us are using automatic window managers. The very idea of movewindow doesn’t make any sense in a lot of topologies.

Why do you care? You don’t write or use any software that would need this anyway, do you?

Is that allowed even when sandboxed?

Either way, allowing it from applications is a lot different than allowing it from user scripts or accessibility tools in terms of potential for misuse.

Moving your own window around? Of course, I don't see why not: you can literally do this from JavaScript if you own the window…

In javascript you can't set your window to be borderless and transparent and be drawn on top of everything else so that you can intercept clicks or trick users into clicking on something.

> why do the developers think that it is a good idea to have it?

Because it has little utility and a lot of risk; Baddies use this to trick people. It is also so hard to use it correctly/meaningfully in many display topologies (mostly multihead+multidpi, but also tiling, virtual desktops, etc) without querying that topology that there’s no big hurry to offer an API that users don’t want and nobody can use correctly.

> For example, when the user has arranged the windows of an application in some way, and then wants to save and then restore the placement of windows, how should it be done by the application?

It shouldn’t: Putting that logic into every application is bloat at best, and a lot harder than just writing down x/y coordinates and screen numbers to a file (ever had to unplug a monitor to find a window on a Mac or windows desktop? Never happens on Unix!) so it makes sense to centralise it:

This is the job of the window manager and really, its only job. There are lots of window managers on Unix because users have varying needs here (I like using a lot of accessibility tools- If you could move my windows I might never find them again!)

> ever had to unplug a monitor to find a window on a Mac

…no? I’m not sure why this would be an issue specific to those?

To those what?

You can use positioners to request a location for your popup window relative to your toplevel window:

https://wayland-book.com/xdg-shell-in-depth/popups.html

You just don't get to set the absolute position of your window. The precise position and making sure it isn't going off of the edge of the screen is the responsibility of the compositor.

This is good because it ensures proper security sandboxing and makes sure clients still work even when the windowing paradigm changes, e.g. with multiple desktops or window tiling. Developers hardcoding such assumptions is what caused much of the pain of Xorg so it's understandable that they want to make sure it does not happen again.

It's done by the window manager, which is integrated directly into Wayland. The tight coupling of the two is a semi-contentious issue.

I might generally agree, but there are some very cool applications of this feature. The rhythm game Rhythm Doctor moves the window in sync with the music. [1] Surprisingly it even worked on i3wm via Wine. I would be sad if similar things couldn't be done in the future, even if they aren't enabled by default.

[1] starts at 0:40 https://www.youtube.com/watch?v=5-kZ1xcxhx4)

Which is sad because I remember reading a wine developer saying that they need such a feature for menus.

Maybe it's not the responsibility of the toolkit library to manage window placement?

I think this is because of the separation between window manager and GUI toolkit.

Which I think is a terrible thing to have separate, for the functionality reasons you're illustrating.

But that's why.

The application cannot decide where its window ends up. Every used a tiling WM?

> The application cannot decide where its window ends up.

Yes that's how it works. I think there may be some APIs that let you 'hint' to the WM from the application, but it's possibly entirely up to the WM how to interpret those hints.

> Every used a tiling WM?

Sorry not sure what you're asking here. A tiling WM yes could possibly ignore the hints or interpret them in its own way. But not everyone is using a tiling WM, if that's what you're asking?

That should be on the person using a tiling window manager. The whole problem with development this side of the mobile revolution is the regression not to the mean but to the least common denominator and it's what made Windows 8 so horrible.

If a WM might exist that chooses to ignore the positioning call, that doesn't mean everyone should be robbed of that functionality.

StatusIcon and AppIndicator is extremely annoying.

Clientside decorations, ridiculous headerbar, button+hamburger menus, etc, etc. They are trying their absolute hardest to copy Mac os, and making sure everyone's stuff breaks in the meantime.

Reply on news.ycombinator.com