https://bugs.kde.org/show_bug.cgi?id=469192
--- Comment #23 from Sergio <sergio.calleg...@gmail.com> --- Thanks Nate for the extended answer! >> and there seems little that can be done on the KDE side. > On the contrary, Plasma's wayland session is improving rapidly, while its X11 > session is frozen in stone, > never to get any better ever again. The same is true of the X server upstream. In fact, I think that we meant the same thing. When I say that there is little that can be done on the KDE side, I mean that Plasma progressed vigorously on all it could do alone, but that there are remaining issues (often annoying ones) coming from things that are not in control of the KDE developers. From a total outsider, the impression is that: (i) those who decide on the protocols tend to prevent the introduction of some mechanisms because they have some strong views on the policies that should be adopted and not having a mechanism appears as a powerful way to prevent some policies (`setWindowIcon` is an excellent example); and (ii) coordination with toolkit developers is too loose, maybe because of imbalance on how the toolkits are considered. >> - why cannot there be a standard way to do session restore so plasma cannot >> do it? > It's still a work in progress; see > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18. > Once that's accepted, > we'll add support for it. Excellent news, particularly for systems that cannot sleep. Yet, again for an outsider, it seems amazing that 15 years after the initial release of the wayland protocols, the ability to save-restore a session in a standard way is still on the drawing board. >> - why cannot there be a cross-toolkit env variable to decide if >> applications should use X11 or Wayland and every toolkit has its own way, >> so launching applications via `ssh -X` which should work just fine using >> Xwayland does never work? > Because there are multiple toolkits and they never came to an agreement about > a common environment variable to use. This sounds like > it could be a good candidate for a new Wayland protocol. This is particularly nasty. One does ssh -X from host A to host B and launches an application on B. Because the application does not know it should run on X11, since there is no standard way to tell it to run on X11, it may end up believing it should use wayland. If the user has a wayland session on B, the application opens on the screen of B with no error reported on the ssh terminal session. That may get unnoticed and the application may stay there even for days, using resources, amplifying the attack surface of B, whatever. When the user unlocks B not remembering that there is such application, that application window may get unexpectedly exposing to others in the room. >> - why can we have scaling only by 75-100-125-150 etc., what was the issue >> with specifying DPIs that enabled a much finer tuning; > You can set any scale value you want in the relevant KDE system settings > page, not just multiples of 25%. Particularly interested in this. In the KDE system settings -> display configuration, I can move the scale slider only by multiples of 25%, how do I unlock that? >> - why isn't there a single cross-toolkit env variable to control scaling? > See above. But why is this needed? Because in principle everything should, as you say, just work. But if adjustments are required having to remember "GDK_SCALE" "GDK_DPI_SCALE", "QT_SCALE_FACTOR" or whatever other variable is a mess. > LibreOffice with the QT VCL works just fine for me with a multi-monitor > system where one monitor has 225% scale and another > has 110% scale; I was using it this way just today. If it's not working for > you, it sounds like your system is misconfigured. No, unfortunately there is a confirmed bug about this setup. See: https://bugs.documentfoundation.org/show_bug.cgi?id=141578 >> - why Java applications won't obey scaling anyway so big commercial >> applications (MATLAB to mention one) are now almost unusable >> unless you use weird hacks like passing them through Xpra? > Without knowing which apps, I can't answer that question, but I suspect based > on other scaling-related questions that your system is > misconfigured based on old habits from X11 that aren't translating to a > Wayland world. Unfortunately, many large cross-platform scientific applications use java front-ends (MATLAB, SCILAB to mention two that almost everybody knows) and all AWT/Swing applications cannot do scaling properly on Wayland (while it was obeying the DPI setup in X11). AWT/Swing can do scaling but only at integer factors which almost invariably makes things either too big or too small. The only reasonable way to use these applications is via `xpra`'s `run_scaled` helper that kills performance and blurs the display slightly. To me, and I think for many in the scientific community, large Java based scientific applications are the largest obstacle to completing the migration to Wayland. This is definitely one of those trade-offs mentioned at the beginning, where KDE developers cannot help. If you would like to experiment, please try scilab, that is open source. >> - why cannot applications decide their own icon, so a lot of stuff remains >> with the generic "W" icon and Qt's `setWindowIcon` has been >> broken *by policy*? > I think you just answered your own question. But there is a draft Wayland > protocol that would implement this functionality: > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/269 Unfortunately, the fact that there is a draft protocol does not mean it will be merged. There seems to be a lot of resistance against this one (and I really tend to find it rather ideological). You surely know the discussion in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/52. Even from the protocol developers more open to it the attitude is "[even if this is merged] This [ext] protocol won't be something you can expect to see everywhere. I'd suspect gnome would not implement this". I would not bet on this. Seems a classical example of not providing mechanisms as a way to force a policy. > This isn't an X11/Wayland thing; there *is* a standard way to set a System > Tray icon and KDE implements it. Looks like there is a difference in between how this is managed in X11 and in Wayland. For X11, the application can pass either the pixmap file or the pixmap data for the tray icon. On Wayland, only the pixmap file. This is not friendly to containerized (flatpack) applications where the file is not available out of the container. Please see the discussion on https://github.com/flathub/com.github.KRTirtho.Spotube/pull/51 for an example of an applications that had to go back to being X11 only. The thread is long, the important part is at the end. I apologize for having slightly abused of this bug report to provide some links and practical cases. Hope you'll find them interesting, though. -- You are receiving this mail because: You are watching all bug changes.
