3 ms·

> Qt can (and is, for instance by default in Debian) be configured with -xcb-native-painting which does what you'd expect it to It seems to me that -xcb-native

by jhgb 5y ago

> Qt can (and is, for instance by default in Debian) be configured with -xcb-native-painting which does what you'd expect it to It seems to me that -xcb-native-painting does the exact opposite of what I "expect Qt to do"? In any case, if it can use server-side X11 painting, that doesn't mean that it doesn't support the opposite, which is what I meant -- unless the Qt devs completely removed the code for client-side rendering, it's basically already ready for that scenario (passing pixmaps), isn't it? > and has the very nice benefit of using my .Xresources (e.g. for my local screen's hi DPI) Not quite sure how that is relevant. Isn't it possible to query that from the client, then produce a pixmap in an appropriate resolution? That should be transparent.

jcelerier 5y ago
> It seems to me that -xcb-native-painting does the exact opposite of what I "expect Qt to do"? I was talking about the flag. Qt by itself can render however you want it to, if someone wanted to make a platform abstraction that would render Qt apps with ncurses that would be possible too. > it's basically already ready for that scenario (passing pixmaps), isn't it? sure, if you use it as a local X11 client (or on other platforms than X11) it's what happens too
- jhgb 5y ago
  I wonder, is this purely a compile-time thing, or is the Qt binary library capable of switching between the two depending on whether you have a remote display or not? It seems like something that should be possible without forcing you to choose whether the performance of local or remote users is prioritized with a compile-time switch.
  - jcelerier 5y ago
    > is the Qt binary library capable of switching yes, that's how a single Qt binary can run on wayland, x11, raw EGLFS, or even expose itself over VNC (https://doc.qt.io/qt-5/qpa.html https://doc.qt.io/qt-5/qpa.html) you can force a platform with QT_QPA_PLATFORM=<...> with <...> being one of the plug-in names in your /usr/lib/qt/plugins/platforms The only limit is that it can only be chosen on startup but not changed "while" the application runs if e.g. for some reason you wanted to switch a Qt app from X11 to wayland without restarting the app.
    - jhgb 5y ago
      Heh, I completely forgot about the ability to switch between Wayland/X11 session which makes this necessary in the first place anyway. Cool, thanks, I learned something new. > or even expose itself over VNC (https://doc.qt.io/qt-5/qpa.html https://doc.qt.io/qt-5/qpa.html) Hmmm, I wonder how difficult it would be to support Ultimate++'s TURTLE protocol (https://www.ultimatepp.org/reference$WebWord$en-us.html https://www.ultimatepp.org/reference$WebWord$en-us.html)...
    - mikepurvis 5y ago
      This clearly makes sense architecturally, but my goodness these envvars are a nuisance in Nix where you have wrapQtAppsHook and a bunch of other hackery to ensure that the proper plugins are findable at runtime.

by jhgb 5y ago

jcelerier 5y ago

> It seems to me that -xcb-native-painting does the exact opposite of what I "expect Qt to do"? I was talking about the flag. Qt by itself can render however you want it to, if someone wanted to make a platform abstraction that would render Qt apps with ncurses that would be possible too. > it's basically already ready for that scenario (passing pixmaps), isn't it? sure, if you use it as a local X11 client (or on other platforms than X11) it's what happens too

jhgb 5y ago
I wonder, is this purely a compile-time thing, or is the Qt binary library capable of switching between the two depending on whether you have a remote display or not? It seems like something that should be possible without forcing you to choose whether the performance of local or remote users is prioritized with a compile-time switch.
- jcelerier 5y ago
  > is the Qt binary library capable of switching yes, that's how a single Qt binary can run on wayland, x11, raw EGLFS, or even expose itself over VNC (https://doc.qt.io/qt-5/qpa.html https://doc.qt.io/qt-5/qpa.html) you can force a platform with QT_QPA_PLATFORM=<...> with <...> being one of the plug-in names in your /usr/lib/qt/plugins/platforms The only limit is that it can only be chosen on startup but not changed "while" the application runs if e.g. for some reason you wanted to switch a Qt app from X11 to wayland without restarting the app.
  - jhgb 5y ago
    Heh, I completely forgot about the ability to switch between Wayland/X11 session which makes this necessary in the first place anyway. Cool, thanks, I learned something new. > or even expose itself over VNC (https://doc.qt.io/qt-5/qpa.html https://doc.qt.io/qt-5/qpa.html) Hmmm, I wonder how difficult it would be to support Ultimate++'s TURTLE protocol (https://www.ultimatepp.org/reference$WebWord$en-us.html https://www.ultimatepp.org/reference$WebWord$en-us.html)...
  - mikepurvis 5y ago
    This clearly makes sense architecturally, but my goodness these envvars are a nuisance in Nix where you have wrapQtAppsHook and a bunch of other hackery to ensure that the proper plugins are findable at runtime.