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.
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
