On 9/14/23 06:36 AM, Ian McInerney wrote:
On Thu, 14 Sep 2023, 00:17 Neal Gompa, <ngompa13@xxxxxxxxx <mailto:ngompa13@xxxxxxxxx>> wrote: On Wed, Sep 13, 2023 at 7:02 PM Steven A. Falco <stevenfalco@xxxxxxxxx <mailto:stevenfalco@xxxxxxxxx>> wrote: > > On 9/13/23 05:23 PM, Neal Gompa wrote: > > Right. And I want to stress we are not dropping support for X11 > > applications. Anything running as an X client in a desktop should work > > as it has before. > > I'm not convinced KiCad will work in that scenario, so please let me summarize what I've read here, and please correct me if I have any of this wrong. > > The thing being removed is "Plasma(X11)", which is a native X11 stack; i.e. no Wayland or Xwayland is involved when using Plasma(X11). This mode is well supported by KiCad, and additionally it works well with my multi-monitor setup. > > Should the change proposal be accepted, "Plasma(X11)" will be removed, leaving "Plasma(Wayland)" as the only available KDE mode. Also, all X11 applications will then be forced to use XWayland rather than X11, at least under KDE. > > Assuming my summary is correct, here are my personal problems: > > Problem 1: The KiCad team says they don't support XWayland (nor do they support pure Wayland) because of bugs. > >From what I've read through the issues, the ultimate problem is in GTK, not wxWidgets, as there is in fact a supported Wayland protocol for mouse warping[1]. Does this issue exist when using wxQt instead of wxGTK? Admittedly, I'm not sure of the state of things with wxWidgets and the backends... [1]: https://wayland.app/protocols/pointer-constraints-unstable-v1 <https://wayland.app/protocols/pointer-constraints-unstable-v1> Speaking as a member of the KiCad core development team, I am not convinced that extension will be easy to use. When I looked at it a few weeks ago, it still seemed to have portability problems between compositors/WM implementations. (See here for my conclusion https://github.com/wxWidgets/wxWidgets/issues/23778#issuecomment-1680398578 <https://github.com/wxWidgets/wxWidgets/issues/23778#issuecomment-1680398578>). As a project, we already have to deal with enough problems from supporting MSW, macOS and Linux that having to now workaround quirks in different graphics stacks is not something we have the time or developer effort to do. We would rather be actually creating the features all our users need for their work instead of having to fight with the graphics stacks all the time. And aside from the mouse warping, we also want the ability to control where windows are placed on the screen. We are a multi-window application, and our users usually have a preferred setup for how the windows are arranged on their screen. Right now, we can save/restore that for them, but my understanding of the Wayland spec is that this is not allowed and so we are at the mercy of the desktop to put the windows where it wants. -Ian
I've written a bug [1] stating that window placement appears to be ignored. Specifically the following command ignores the requested placement under Plasma(Wayland) but the placement is honored under Plasma(X11). That is a big problem in a multi-screen environment: /usr/bin/konsole --qwindowgeometry 675x678+3754+870 & Steve [1] https://bugzilla.redhat.com/show_bug.cgi?id=2239016 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
