On 9/14/23 06:36 AM, Ian McInerney wrote:
On Thu, 14 Sep 2023, 00:17 Neal Gompa, <ngomp...@gmail.com
<mailto:ngomp...@gmail.com>> wrote:
On Wed, Sep 13, 2023 at 7:02 PM Steven A. Falco <stevenfa...@gmail.com
<mailto:stevenfa...@gmail.com>> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
