[Interest] 2017

[Shawn Rutledge]

> On 3 Jan 2017, at 12:45, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> I haven't given that much thought, but yes, I think the idea would be to have a "rootless" Wayland compositor that displays windows alongside native windows, much like Xquartz can do. An important appeal to the XQuartz maintainer I spoke with is that it would make XQuartz obsolete because it could in principle be replaced by XWayland. Done right that should provide a more complete X11 implementation requiring less maintenance effort.
> As to remote use: I thought that wasn't the point of Wayland at all?

No they keep saying it’s not the point (optimizing for that would impose limitations).  They keep saying to go on using X11 or VNC or whatever existing solution you like.  But then, if Wayland will eventually make X11 obsolete, that will be impractical at some point, right?  Besides the fact that X11-over-network doesn’t work well with every application anyway.  (The best applications for that are old-school: using X resources sparingly and reusing them properly, sending text across and asking the X server to render it, and so on.  Qt hasn’t been optimized for that in ages.)  Personally I think a good eventual solution would be to leverage the application server's GPU (the client machine in X terminology) both for rendering and for compression, and send compressed frames (or frame diffs) over the network, using some compression technique which both runs well on the GPU and is as close to lossless as possible.  But it won’t scale to lots of users either, if the GPU usage ends up being too high.

Oh well, maybe X11 will realistically be around for another couple of decades anyway.

Another alternative of course is to use some other client-server protocol such that only the “model” of MVC is on the server, and UI rendering instructions are sent across the network instead of actual rendered graphics.  For example load QML over the network and run it locally.  For some reason we aren’t putting much emphasis on that as a primary use case yet, but I wonder if anybody in the field is doing much of that?

> It's still using the adapted KDE platform plugin which makes it possible to map KDE's font roles to different font sizes so applications automatically stop using the same (big!) font size for most of the GUI if they don't explicitly specify smaller font sizes. This is on 10.9, so the system font is Lucida Grande. The platform theme also adds the XDG icon directory to the icon theme search path, and that makes icons appear in the native widget style dialog buttons because the code only checks if the buttons have an icon set or not, and render it if they do. That should probably be corrected one way or another but I'm not yet sure how.
> 
> Shawn, do you think it's worth reporting this on the bug tracker? I would guess that the same happens however you make an icon theme available, be it through an embedded resource or an XDG-style icon directory, no?

Sure, but it will get triaged to a pretty low priority if it only affects this unusual setup of yours.  But anyone can write a patch for it anyway, especially if the fix is straightforward and doesn’t break anything.