5 ms·

GTK still misses: 1. Anything close to AdjustWindowRectEx() function. See: https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-adjustwindowre

GTK still misses: 1. Anything close to AdjustWindowRectEx() function. See: https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-adjustwindowrectex 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-position-of-decorated-gtkwindow-on-screen 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?

chrisseaton 6y ago
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.
- dima55 6y ago
  The application cannot decide where its window ends up. Every used a tiling WM?
  - chrisseaton 6y ago
    > 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?
  - ComputerGuru 6y ago
    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.
deleted 6y ago
[deleted]
ATsch 6y ago
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.
- skeletal88 6y ago
  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?
  - war1025 6y ago
    It's done by the window manager, which is integrated directly into Wayland. The tight coupling of the two is a semi-contentious issue.
  - sho_hn 6y ago
    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.
    - saagarjha 6y ago
      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?
      - sho_hn 6y ago
        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.
dilandau 6y ago
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.
haecceity 6y ago
Maybe it's not the responsibility of the toolkit library to manage window placement?

chrisseaton 6y ago

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.

dima55 6y ago
The application cannot decide where its window ends up. Every used a tiling WM?
- chrisseaton 6y ago
  > 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?
- ComputerGuru 6y ago
  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.

deleted 6y ago

[deleted]

ATsch 6y ago

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.

skeletal88 6y ago
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?
- war1025 6y ago
  It's done by the window manager, which is integrated directly into Wayland. The tight coupling of the two is a semi-contentious issue.
- sho_hn 6y ago
  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.
  - saagarjha 6y ago
    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?
    - sho_hn 6y ago
      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.

dilandau 6y ago

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.

haecceity 6y ago

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