gtk_window_set_position seems to be gone
Let the window manager move the windows to were it thinks they should go. I.e. do nothing, which is essentially what you should’ve done before as well.
Give a reason why you say I shouldn’t do anything? I want to know a way to center. If you know of any share if not explain why it would be very constructive thank you
1 Like
Positioning top level windows is not the toolkit’s job. In various windowing systems we don’t even have the concept of global/screen coordinates, so any toolkit cannot know how to “center” a window on the screen. At most, a toolkit can position a window relative to another one—i.e. you could position a popup at the center of its parent.
Even on windowing systems that have global coordinates and allow positioning top levels, this is highly discouraged; toolkits don’t have access to the whole stacking order and geometry of all the existing windows, and don’t have the logic to deal with screen-relative constraints. Plus, there are tiling window managers, where the concept of “centering a window on the screen” is pointless by design; and there are tools that control window positioning according to user-provided rules, like Devil’s Pie, which would render any decision an app developer might make pointless.
You should leave window positioning to the windowing system, where it belongs.
so this was removed gtk_window_set_position (window, GTK_WIN_POS_CENTER). and will never have a replacement
Correct, the API was removed.
Never is a very long time. It’s not planned to have a replacement in GTK, and a replacement API—even with “symbolic” positions—would require a lot of work in the underlying windowing systems in order to exist.
1 Like
I’m trying to work out the reasoning behind this decision. Handing off the task of window positioning to a window manager is all well and good if the window manager then does something with that responsibility. Other than MS Windows, I’ve seen no sign of a window manager that does.
One of the things I’ve come to rely on while working is applications remembering where they were last time I used them. With three monitors, it’s essential. Otherwise, I spend far too much time searching across an expanse of screens to find that dialog box I just opened. This is one of the reasons I keep rejecting Linux as an OS.
Why not wait until at least one Linux window manager actually takes user-friendly window positioning seriously before dropping support for it at the toolkit level? I can’t be the only one who likes a bit of predictability when it comes to positioning application windows.
I suppose I should be grateful, though, that all this stuff is FOSS as it means I don’t have to move to GTK 4 if it lacks essential features.
As I’ve said above, not all windowing systems have a concept of global coordinates or allow direct positioning of the windowing from an application. Wayland, for instance, does not. All windows have their own coordinate space, with the origin placed in the top-left corner. There is no way, down to the protocol level, to allow GTK to position a window using screen coordinates. This means that GTK cannot possibly implement this functionality.
This functionality needs to be negotiated between toolkits and desktop environments; GNOME definitely wants to be able to deal with session management, but it’s a very complicated task, and it most definitely does not belong to the application to restore its own position across sessions. What happens when the previously occupied region is already occupied? What happens when you launch two instances of an application? What happens when the geometry of the screens changes across sessions? What happens when you update your desktop and the UI layout has changed?
Of course, I’m only considering the case of well-behaved, benign applications. Hostile applications could do even worse, like positioning on top of another application, and preventing you from accessing it; or overlapping a system dialog, and doing things like intercepting your passwords. Or position themselves right outside of the visible screen and stealing all focus.
In other words: an application has a (by design) limited view of the environment in which it’s been executed. The only component that has a complete view is the window manager. As such, it’s the role of the window manager to position windows and to restore their location.
Because it’s not just a matter of window managers: the preferred windowing system API on Linux does not have this functionality, and as such, a toolkit using it cannot maintain it.
Of course, you can delay moving to GTK4 as long as you like. A word of advice: it’s extremely unlikely (though not impossible) that this functionality will ever be added again, considering that we’re moving in the direction of self-contained application with minimal privileges all across the board.
If you are using a platform and a windowing system that allows you to position windows directly, then you’re also free to use platform-specific API to do that; all that GTK4 removed was the generic, platform-agnostic API, given that it wasn’t portable or sustainable any more.
1 Like
Well, I don’t know anything about Wayland, not being a Linux guy, but using GtkD (based on GTK3) on Windows, I was able to do quite a bit of window management… unless, of course, that term means something different than what I think it means. (Which wouldn’t surprise me. It wouldn’t be the first term that changed its meaning since I first started using computers in 1985.)
I’ve written it up in a series of blog posts which you may or may not have seen. It starts with: 0091: Where’s My Window? and continues on through to 0096: Hardware III – Keyboard and Pointer, hitting the high points of window positioning for config files along the way.
Is that what you’re talking about?
Not entirely.
What you can do with GTK4:
- know the location of the mouse pointer within your top level window
- get enter/leave notification on your top level window
- get the size of your top level window and then set it again
What you cannot do with GTK4 using GTK API:
- get the screen coordinates of the pointer
- move the pointer to a set of coordinates (“warping”)
- move your top level window to a set of screen coordinates
You’re, of course, entirely able to use platform-specific API to achieve the same, since those operations are not portable on all backends supported by GTK.
I’d really like to know how this stuff can be accomplished now that it’s been removed from GTK. What would I be looking for? Can you steer me in the right direction for Linux? Windows? OSX? FreeBSD?
Whatever API your platform uses. On Windows, for instance, you would need to get the HANDLE out of the GdkSurface of the top level GtkWindow, and then use the native Windows API to move it. The same thing would apply to X11 (XID), or macOS (NSView).
I have studied GTK from GTK 1.2 until 4 and realized that something is not at its place from release to release.
In GTK4 seems that everything became over complicated which makes new comers to give up on GTK.
Who knows maybe I am overreacting right now, but new GTK users will somehow disappear.
I think that’s an overreaction, and it’s not really relevant for the discussion in this topic.
The API has been reorganised, and we reduced the amount of different ways to achieve something by removing some of the API that we were stringing along from GTK 1, 2, and 3, and replacing them with a single class, concept, or event entry point. Key shortcuts, for instance, are now handled by a single GtkShortcut class; all input events use gestures and event controllers, instead of random signals on widgets; complex widgets are all built on top of widgets, instead of having native windowing system surfaces; the windowing system API has been reduced and mapped on top of Wayland, instead of the mess that is Xlib; and backends are free to provide proper API, instead of re-implementing the X11 design on top of their native windowing system.
Yes, if you’ve “studied GTK from 1.2 until 4” you’ll see a lot of changes, but newcomers have no experience with older versions of GTK—that’s why they are newcomers.
2 Likes
Is there any reference where I can read about this changes, other than the migrating from GTK3 to GTK4 page?
The migration guide lists all the changes—and if it doesn’t, it’s a bug, so please: feel free to open an issue for all missing migration notes you can find.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.