[Interest] 2017

[René J.V. Bertin]

On Tuesday January 03 2017 10:12:50 Shawn Rutledge wrote:

> > aren't that suitable for remote execution anyway. That *was* a bit my motivation to start tinkering with the xcb  QPA, but I've since discovered that it's very nice for local use, too. Esp. being able to run Konsole on all my desktops.
> 
> Why doesn’t it run with just the cocoa plugin?

It does run, but it gets bitten somewhere by Qt's "circus" swapping the Ctrl and Meta ("Command") keys. At least I think that's what makes it missing most of the Control-Key combinations that are relevant for shells, like ^C and ^V. No, disabling the Ctrl/Meta swapping doesn't help here, and I haven't been able to figure out where in Qt things go wrong.
It almost has to be in Qt because the Qt4/KDE4 Konsole application worked fine in this aspect, and there doesn't appear to be anything relevant that was changed in the Konsole code during the transition.

> Does middle-mouse-paste end up interoperating between plain X11 and Qt apps then?

That I cannot tell because I don't have a mouse with a middle button and I avoid using the XQuartz emulation. It also depends on how you set the auto-sync options between the various X11 clip and cut boards. From what I can tell though, copy/paste works fine with the menus and short-cuts between Qt (xcb or cocoa) and GTk apps as well as native applications. That's the most important for me, at the moment.

> Hmm, interesting.  But I guess it makes less sense to composite an overlay desktop, as opposed to having application windows which use the Wayland QPA plugin simply showing up as regular windows, right?  Especially if it eventually ends up providing another way of using applications remotely.

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?

On Tuesday January 03 2017 10:51:19 Kevin Funk wrote:
> Here is a screenshot of KDevelop on OS X using the native style (which 
> probably feels a lot more 'natural' to OS X users):
>   https://www.kdevelop.org/screenshots/kdevelop-5-beta-1-mac-os-x

I'm not so sure about the Breeze icons, they don't feel Mac-native at all to me. And that's with a still rather vivid memory of using System 4 and 5 on monochrome and grayscale displays in the late 80s and early 90s ;) 
I'd hope the main "deviant" look is caused by my choice of fonts (which I left in by choice as it's not something you can get easily with the stock platform theme plugin). The rest of the QtCurve theme is indeed more akin to the UI in pre-10.9 OS X versions, but I think it fits in perfectly and it's of course optional (and a lot more space-efficient than any other widget style).
This is what KDevelop looks like when using the native macintosh application style in Cocoa mode:
https://trac.macports.org/attachment/wiki/KDEProblems/KF5-Mac-Mac.png
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?

R.