wxAUI does not work properly on Wayland. (Issue #23906)
dsa-t
Description
Docking wxAUI panels does not work, and moving toolbars do not work properly on Wayland.
aui sample:
https://github.com/wxWidgets/wxWidgets/assets/37658952/bc453ab8-1116-42e8-b4b0-f0b9c9d7015e
Platform and version information
- wxWidgets version you use: 3.2.3 (proposed)
- wxWidgets port you use: wxGTK
- OS and its version: Ubuntu 23.04
- GTK version: 3.24.37-1ubuntu1
- Which GDK backend is used: Wayland
- Environment: gnome-shell version: 44.3-0ubuntu1.1
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ian McInerney
This doesn't surprise me too much. The AUI infrastructure probably doesn't play nice with all the compartmentalization wayland has done for the windows. Each AUI tearout is a wxFrame, so it is in essence a new window to the compositor (which is also why it annoyingly positions them at the top left always instead of where it is teared out, which is what the AUI manager is trying to set it to).
The lack of docking indicators might be due to issues with screen coordinates. Does Wayland provide global window coordinates, or is everything done locally for each window in relation to the window's origin?
I don't know how feasible it will be to get the AUI working across the whole screen, but maybe it is possible to get it working if the panes only live on top of the main window (perhaps there is a way to tell the compositor to treat the panes as subwindows so that we can at least position and have proper coordinates for?)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Niels De Graef
For the docking parts, see https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/204
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Yes, wxAUI is unfortunately completely broken under Wayland. I don't even know yet how much time will be needed to make it work there but it's clearly not a trivial effort.
@sethhillbrand Sorry to ping you here too, but I wrote an email about this to you some time ago, followed by another one a couple of days back, and never got any reply, so I'm not sure if you got it and just wanted to triple-check it by mentioning you here too.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
paulcor
Known problem. #18372
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
hungrymonkey
Do you want to join in the debate?
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247#note_2105977
I believe this comment is the strongest argument against global coordinates. Join in. You have a use case which needs to be in wayland. You might as well join the mega thread to pick apart all use cases within the global coordinate system. Share code examples etc.
If an application relies on something that is clearly stated as a hint, I would argue it is buggy and it's up to the app author to fix
I wish it was that simple, but what the protocol states to be optional or a hint or whatever does not matter in practice. Applications and users decide what's actually optional - if 10 applications work on all the popular compositors but don't work in one with a novel approach to window management, then that compositor is considered broken, not the applications. Whether or not the compositor is technically speaking doing something that's legal according to the protocol is irrelevant.
This very MR shows that more generally, when the functionality to make $thing work is missing in the environment, that is not considered an application bug but something that needs to be fixed in the environment. That environment is Wayland right now, and will become compositors that don't honor the hint then.
That's not to say that I consider that approach wrong! It's often exactly what's needed and I find it amazing when someone takes the time and effort to push Wayland upstream to become better and more suitable for more apps and use cases - but with protocols like this you really have to work with the assumption that they're mandatory from the start, because it's very likely that will happen.
With the new protocol, we piggy-back on xdg-output. Each output has a coordinate system, and the given coordinates are relative to that. That should address this issue (and not apply to any compositor that isn't following the traditional desktop metaphor). Does that address this issue, or do I misunderstand what the problem is?
That's still defining a global coordinate system, just in a different way. An application that wants to place a window to the left of its main window will check whether or not there's enough space next to the main window on the current output, and if there's an output to the left, place the window there. It'll have to do more checks and calculations, but aside from that nothing really changes.
To maybe get my point across about global coordinate spaces, let's take a look at scrolling window managers. A compositor implementing such a paradigm could have an infinite / scrolling horizontal space per workspace, and a workspace per output. With such a setup, what do you tell the application about the position of its window? How do you interpret "place this window on the left output, at the position 300,100" to fit into that coordinate system? How would the compositor know that the app wants the window to be placed next to the window on the center output, and adjacent to each other in general?
They do need to know where the output edges are, but the xdg-output protocol provides that information
It doesn't take exclusive zones into account. If the user has a 200px panel on the right side of the screen, the app doesn't know about that and will try to place stuff in that place. Or as a more common example, if the user has a 50px dock on the left, and the app places two windows, one left, one right. The compositor will now move the left window to the right so that it's not behind the panel - but now the two windows from the app are overlapping. That's not a good result. And the compositor again doesn't know that it should resize the windows to both fit on the screen, because it doesn't know they're related to each other.
as far as virtual keyboards are concerned, the compositor could tweak a client's placement hint to correct for that
Sure, it can move windows out of the way. But your goal is to open multiple windows at once, and have them laid out in a way so that you can see all of their content, right? That breaks if the compositor moves the windows away from their position hints for any reason.
The preferred output would be whatever the application's main window is currently on, at least for most such apps
That doesn't work for placing the main window, for obvious reasons.
.> In practice, I do not thing is is an issue, as most apps only create new windows as per user's request, and the user doesn't do many things at once
Those two assumptions fall in the water once an application takes a few seconds to create a window. We've had complaints about this happening in real world scenarios.
But if they do that to place their initial window in a random place, the compositor still knows where the user wanted it originally and can just ignore the client's request
How would the compositor know whether this application is abusing the protocol, or actually using it for the legit use cases?
Yes, they could do that - but wouldn't that just be a bug in an application that needs to be fixed?
It would not be a bug in the application, as the application has no way to know what the other output is there for. Users of compositors that deal with outputs in a more "traditional" way would likely want the window to be placed on that second output... The only place where this kind of decision can be made is in the compositor. To make that decision, it needs to know what the application actually wants to do.
Yes, but codifying even more context would make this unmaintainable for sure. If a client suggests "I'd like position X/Y on output Z" and the request can't be honored for some reason, I would expect the compositor to make a smart decision to place the new window roughly in the vicinity where the app wanted, possibly following other WM rules like not occluding other windows
"where the app wanted" is not a thing that is well described by a position in the absolute coordinate space. What's going across the wire with this is the means to an end, not the goal the application wanted to achieve.
I really think this would address 99% of all usecases that current apps have already
Whether or not it works for apps is not in question here, it certainly would work for many. The question here is whether or not this works for compositors, and if it's maintainable for compositors going into the future. While it's not a requirement that every protocol works for all current compositors, this doesn't work for quite a few of them, and restricts future extensions to the compositors that it does work for.
Embedding Surfaces
if the windows are embedded, the application is effectively only usable on one screen
That's why I mentioned !204. Note that I don't mean embedding as in "run a nested compositor, with its own window management etc", but more something like QDockWidgets.
Furthermore, if a window has been dragged out to a new screen or ordered in a position, the app can not restore its place outside of the main window once it is started again, forcing the user to reorder windows every single time the app is launched
That's why I mentioned !18.
There's also the annoying fact that some of these apps paint their GUI with multiple processes
That is indeed annoying, embedding is probably not a good solution for those apps.
Relative to other windows placement
this becomes really complicated the longer you think about it, especially with regards to having multiple screens attached
Maybe I'm not doing a good job at showing that, but while the API for absolute window positioning looks simpler, it is so much more complicated in practice - for both applications and compositors. Apps have to implement window management logic, and the compositor has to take that into account for its own window management logic, and has to have workarounds for apps that are broken, abuse the protocol or just use it in a way that doesn't work for the compositor's coordinate space.
It would also have the same issues as relative-to-output placement of windows
What issues specifically do you mean?
and would offer less legacy compatibility
It certainly shouldn't be completely ignored, but applications already need porting from the "do what you want" paradigm to take into account that only the first request before the app presented its first frame is valid, and ofc depending on the specifics (like with the current state of the proposal) they'd need to adopt a new API for setting window positions.
As long as this is not something that can be done automagically in the toolkit, I don't think legacy compatibility is a big issue. For such no-, or nearly-no-changes backwards compatibility, Xwayland exists, and will stay around for a very long time to come.
Applications could also use it, since they know screen geometries, to get their windows pretty much wherever they want to have them
Applications don't know where their windows are, they don't know the compositor's internal coordinate space, they don't get to specify anything more than a direction and they don't get to specify any hints at all without having a window of their own application (or of a cooperating process) to be relative to. I think the risk of abuse is pretty low.
Edit: also, sorry for this absolute wall of text. Maybe we should split the "possible alternatives" discussion into a new thread
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
oneeyeman1
@hungrymonkey ,
If I may... ;-)
I tried to convince Wayland devs to consider a very small and widely popular use case of:
Dialog dlg( this, .... );
dlg.Center(); // or CenterOnScreen()
dlg.ShowModal();
What I have been told is that this code needs to go away and whatever the compositor will decide to place the dialog in - it will happen. Whether the developer will like it or not.
The best use case I came up with was the DB credentials one.where the user will have an expectancy to see it at the center of the screen.
Still, NO!!!
So we can argue all we want - Wayland devs will do their own thing and disregard this.
Thank you.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
hungrymonkey
@hungrymonkey , If I may... ;-)
I tried to convince Wayland devs to consider a very small and widely popular use case of:
Dialog dlg( this, .... ); dlg.Center(); // or CenterOnScreen() dlg.ShowModal();What I have been told is that this code needs to go away and whatever the compositor will decide to place the dialog in - it will happen. Whether the developer will like it or not.
The best use case I came up with was the DB credentials one.where the user will have an expectancy to see it at the center of the screen.
Still, NO!!!
So we can argue all we want - Wayland devs will do their own thing and disregard this.
Thank you.
I kinda figured about you may say that. I think you misunderstand. All these issues will be discovered by a third group which is the users themselves.
At this point, we are arguing different definitions. Wayland is a too low level project to even mention the word screen or surface. Screens can be VR machines, Eink, or even some type of dot as long a you can send a bag of pixels to it.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247#note_2115999
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247#note_2116270
An explanation why that is a bad thing would have been nice, but after that discussion I can pretty much guess ;-)
While I of course do not agree with that decision, I really do appreciate the quick and clear response, that is a lot better than long uncertainty periods. And there definitely has been no lack of feedback.
I have a different proposal @ !249 that you may like better, but without any solution at all a lot of Wayland porting progress will be blocked for these large multi-window and MDI applications. So I will convert this protocol to move into the ext namespace, so compositors which want to implement it could implement it.
It seems like the common disconnect between many groups is that one group wants a distinct feature but the other group want to provide the intended use case behind the feature only. I believe this transition will have lots of mandatory bike shedding.
https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/99
I believe DE will be receptive to a MVP when they have a clear milestone to get rid of X11 maintenance. From their public reactions, I believe almost all use cases are on the table to be blockers except a certain IHV display vendor.
There are protocols on that list that mutter doesn't support either and might not be supported ever. Just because there is a protocol in the xdg namespace doesn't mean that it must be implemented by anyone.
I'm extremely annoyed by this crowd of people who keep perpetuating this meme that people working on wayland things are hindering progress whenever something is not merged and takes a long time to land.
If we add a protocol like this, there is no going back. We will be stuck with it forever and have to live with this pain for the next 30 years when someone finally manages to write a successor to wayland that's willing to break backwards compatibility again like wayland did.
However, if someone implemented the session-management protocol we'd have a nice way to restore client windows. Even if this in the future won't be enough for all clients, this is progress and we can still reconsider other possibilities.
Again: as soon as there is some very general, permissive API, we cannot ever go to a more focused, restrictive API.First, mentioning "alternatives" without generating concrete protocol proposals is essentially stop energy
It is not. If you come to any project, hack something up that's not acceptable to the maintainers, the maintainers do not have to provide an implementation of the same feature that conforms to their standards. If you want a feature, you have to put in the work.
Second, who should be motivated to try to create a protocol if ANY of the members can kill it in a heartbeat?
Protocols which work for everyone do not get killed in a heartbeat. In fact, this is literally the first time ever that I saw a NAK.
Let's turn this around: why should someone get forced to implement a feature that they do not agree with at all? If anyone could push any protocol into this repo, what purpose would it serve?
This repo is about generating consensus where possible.Also, even looking at the history of this repository is demoralizing: 76 merge requests, of which two thirds of them are >5 months old. Half of them are >1 year old. The rate of stalls is so high it's ridiculous
There are good reasons for this:
Proposing a protocol is easy. Implementing it in 3 projects is not.
Sometimes you just have an idea and want feedback from different parties.
Some ideas don't work out and the MR is not closed.
People don't always have enough time/resources to follow through.You're trying to make it sound like the MRs are not getting merged because we like to NAK things and are unnecessarily harsh with reviews and quality requirements. But again, you need to create a protocol, find consensus, implement it in 3 projects and that is a huge amount of work.
Heck, !223 (merged) just marks an existing protocol as stable and should have been a no-brainer! It's sitting there for three months.
Did you figure out how to do it without backwards compatibility issues? I had an idea: !223 (comment 1991329)
Will you implement this?
This is really ridiculous, but if you want to discuss project governance, do so in a new issue. You seem to have all the time in the world to do this kind of stuff.
Either way, I would thank Matthias because he is pushing the issue.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/249
Either way, I am not here to debate the merits of whatever feature you want or their rebuttal. I believe you are both right, but both decisions will affect users.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Thanks for bringing this to our attention, but it's just a sad, sad story. I don't see any point in participating in MR 247 discussion at all, as it was already effectively rejected. I do applaud Matthias's efforts and his tact and diplomacy because I certainly wouldn't have been able to write that a discussion was friendly, when after reading just the first 10% of it I've already seen the arguments against this MR just reeking of bad faith.
As for MR 249, I don't think it's very useful to comment on it neither, as it seems clear that it's not going to be accepted in the current form, although bits of it might survive (at least I don't see any remotely reasonable arguments for them not to, but then I'm not a Wayland developer).
And, most importantly, whatever we could say would have at most zero weight in this discussion anyhow because the people taking the decisions there seem to attach negligible weight to the actual applications needs, with just about everything else being more important.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dsa-t
xdg-toplevel-drag was merged 5 months ago and is supported in KWin 6.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Thanks for the link! The protocol looks pretty simple and it would be nice to add support for using it, but it's not going to be trivial to use it in parallel with the existing code, which would still be used for the other platforms and when using X11.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Daniel Collins
solemnwarning left a comment (wxWidgets/wxWidgets#23906)Would it be possible to make use of the xdg-toplevel-drag API before GTK supports it (i.e. is there a way wxWidgets can bypass GTK and talk to the Wayland display server)?
For the time being, I've reworked the (native) wxNotebook detaching and docking in my application to use an alternate path based on drag-n-drop rather than mouse capture and moving windows when it detects a Wayland session is in use, which prevents the window from following the cursor, but at least it can tell which window the pointer is over. I haven't (yet) started applying the effort to wxAuiNotebook, but suspect it should be possible there too.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23906)Yes, it is possible in theory, although it may not be pretty, see what I had to do in #25721 to work around GTK. We still do need to do this, of course, and the fact that this protocol is already supported by both GNOME and KDE is very encouraging.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Daniel Collins
solemnwarning left a comment (wxWidgets/wxWidgets#23906)I'm thinking about working on wxAuiNotebook dragging under Wayland and wanted to check what changes would/wouldn't be accepted into wxWidgets as a patch.
My application subclasses wxAuiNotebook and does an unhealthy amount of monkey-patching of its events to implement detachable tabs - when the tab is dragged outside of the tab area it gets moved into a temporary, semi-transparent frame which tracks the mouse position, if the mouse then re-enters the tab bar of any window, the tab is inserted into that notebook and the built-in dragging code is re-activated, if the mouse button is released outside of a tab area, then it sets up a new frame with toolbars/etc and moves the tab to it.
As far as I could tell when implementing this, there is no built-in way for wxAuiNotebook to do this, so if I'm going to add potentially more methods of handling DnD to wxAuiNotebook, then I'd ideally like to add hooks for an application to be able to dock/detach windows too and eventually dispose of my version.
The API I developed is unusual compared to other wxWidgets controls, so first I'd like to check if it (or something similar) would even be accepted into wxAuiNotebook, I've included relevant snippets of documentation below:
/** * @brief wxAuiNotebook-derived control that allows detatching tabs by dragging. * * This control is a wxAuiNotebook with an unhealthy amount of shimming and monkey patching * to enable dragging tabs between windows and even dragging them away to form new ones. * * When dragging a tab around within the wxAuiNotebook tab area, the base class handles * everything. When we detect the user trying to drag the tab outside of the control, we * create a new wxFrame to hold the page, move the page wxWindow into it and trick the * control into not doing anything else, while we handle moving the new wxFrame around with * the mouse until the user either re-inserts it back into a DetachableNotebook, or lets * go of the button to create a new window containing the page. * * This class introduces the following extra events on top of wxAuiNotebook: * * EVT_PAGE_DETACHED * * Raised when a tab is detatched from the DetachableNotebook control, but still being * dragged. After this point the page is no longer directly owned by the DetachableNotebook * and no further events will come directly from it. The DetachableNotebook *MAY* be * destroyed by the owner after this point. * * EVT_PAGE_DROPPED * * Raised when a tab that has been detatched is "dropped" somewhere other than the tab bar * of a suitable DetachableNotebook control. This event *MUST* be handled and should deal * with relocating the page into a new/existing window. * * This event is not (necessarily) raised from the DetachableNotebook control. A pointer to * a different wxEvtHandler to dispatch the event through may be provided to the * DetachableNotebook constructor to allow destroying the DetachableNotebook when a tab has * been detatched from it. */ /** * @brief Construct a new DetachableNotebook. * * @param parent See wxAuiNotebook. * @param id See wxAuiNotebook. * @param page_drop_group If not NULL, is an opaque pointer identifying a * group of DetachableNotebook controls which allow * tabs to be moved between them. * @param detached_page_handler If not NULL, is a wxEvtHandler to dispatch * events from detatched pages. * @param pos See wxAuiNotebook. * @param size See wxAuiNotebook. * @param style See wxAuiNotebook. */ DetachableNotebook(wxWindow *parent, wxWindowID id = wxID_ANY, const void *page_drop_group = NULL, wxEvtHandler *detached_page_handler = NULL, const wxPoint &pos = wxDefaultPosition, const wxSize &size = wxDefaultSize, long style = wxAUI_NB_DEFAULT_STYLE);
Getting the above working under Wayland will require several changes to how wxAuiNotebook works:
- When a tab is dragged under Wayland, rather than capturing the mouse and tracking screen position, we must set up an actual DnD with temporary
wxDropTargetobjects set up on each notebook where the tab may be docked. You can see this implemented on top ofwxNotebookhere. - When a tab is dragged under Wayland, and and
xdg-toplevel-dragis available, set up the floating window and tell the window manager to move it with the mouse for us... assuming this doesn't conflict with the actual DnD operation. - When a tab is dragged under Wayland, and and
xdg-toplevel-dragisn't available, fall back to some other way of showing that a window is being dragged, my application doesn't do this yet, but I did briefly experiment with usingwxDropSource::SetIcon()to provide either a placeholder image or a screenshot of the tab being dragged. - Add events to manage the drag lifecycle outside of the
wxAuiNotebook, potentially after thewxAuiNotebookhas been destroyed!
There is at least one shortcoming with the above:
- When the mouse button is released outside of a tab bar to detach the window, it just gets created wherever the window manager feels like it since we can't use screen-space co-ordinates to place it under the mouse.
I'd appreciate any feedback on how well this fits into wxWidgets and suggestions on how this could work better going forward :)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
RobertRoeb
RobertRoeb left a comment (wxWidgets/wxWidgets#23906)I have no idea how Wayland allows for dragging windows around, but for me, DnD is made for dragging around content between different apps. But if that really is the only way, why not. I am right that this would work on MSW and OSX as well?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Daniel Collins
solemnwarning left a comment (wxWidgets/wxWidgets#23906)Using DnD for this works on other platforms too, but I don't do it there because its just a hacky work-around with other weirdness.
Wayland has no concept of any co-ordinate space outside of the frame, so once you capture the mouse you can't figure out which window the cursor is over or where on that window it is. Unless there is some API we could be using for that? Then maybe we could map the wx "screen" co-ordinates into some made-up space containing each top-level window so at least figuring out where the mouse is over multiple windows is possible.
You could also skip mouse capture and handle mouse enter/leave/motion events over each window, however this would require recursively intercepting the mouse events for every child window, unless wxWidgets has some other method of doing it?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23906)Sorry, I still didn't have time to look into this, so I don't know how are we going to use xdg-toplevel-drag. If it can be transparently used internally when dragging windows, i.e. if it can just become an implementation detail behind our existing DnD API, then I agree that it would make sense to rework wxAUI to use DnD instead of manually handling mouse capture/dragging because this is better than using 2 completely different approaches for Wayland and all the other platforms.
But if it can't, it would probably make sense to come up with a new API for dragging windows, which could be implemented both for Wayland (using this protocol) and for all the others (using existing wxAUI code). And this API could/should be generic enough to satisfy your needs too, i.e. provide the necessary events/hooks.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.