Hi all, First of all thank you all so much for your helpful replies. My
apologies, my knowledge of how QT apps render is not great yet, but I'm
certainly learning a lot more about it which is really useful! I've done a bit
more testing, and I'm also convinced now that if E has anything at all to do
with the issue then it's probably environment variable related (although I
haven't yet found a guide to help me check whether I have the GTK style plugins
fully installed and set up for E yet). I'm pleased to say that with your help I
was able to get Mixxx to work under Enlightenment! I thought I'd share
details of my tests here in case they are helpful. QT apps appear to be being
given an incorrect device pixel ratio within Enlightenment. I've only been able
to test this against an old KDE install on a different machine so far, with an
older version of QT; Mixxx dialogs display without issue there, but this might
be unrelated. This problem only affects apps which set
HighDpiScaleFactorRoundingPolicy to PassThrough (such as Mixxx and QT's
DprGadget), and those apps display perfectly when
QT_SCALE_FACTOR_ROUNDING_POLICY=Round is set as an environment variable
(setting QT_SCALE_FACTOR=1.0 results in no change). Within Enlightenment,
Xorg.0.log shows my monitor's DPI defined as (90,88) which is correct; xdpyinfo
shows 90x88 DPI in resolution; and xrdb shows Xft.dpi as 90 (set in .Xdefaults)
so I _think_ these are all as they should be. However, DprGadget shows a device
pixel ratio of 0.9375 (which is 90/96), and all other widgets are not displayed
at all! This is the same problem I was seeing in Mixxx.
If I set QT_SCALE_FACTOR=96/90, DprGadget _does_ work well, and displays a
device pixel ratio of 1.0, along with a native logical DPI of 90, but, oddly, a
QWindow DPI of 96! If the pixel ratio within QT under Enlightenment is based on
a DPI of 96, alongside the correct DPI of 90 for my system, I've no idea at all
yet where that's coming from.
Within plain X, xrdb returns _nothing_ under xterm, and xdpyinfo still shows
90x88 DPI. There, DprGadget shows a pixel ratio of 1.0, and all widgets display
perfectly (as they do if I set the "Round" rounding policy for QT under
Enlightenment, again resulting in a device pixel ratio of 1.0).
In any case, Mixxx is now fully usable if I make sure it doesn't pass through
the DPI scale factor! I'm really happy about this, although I would be
interested to find out whether it's Mixxx, QT, GTK or me which is actually at
fault. :-)
Thanks so much for all your help,
Anna
On Sunday, 12 March 2023 at 23:09:54 GMT, Carsten Haitzler
<ras...@rasterman.com> wrote:
On Sat, 11 Mar 2023 19:36:56 +0900 Masaru Nomiya <nom...@lake.dti.ne.jp> said:
> Hello,
>
> In the Message;
>
> Subject : Re: [e-users] Having issues getting mixxx to work
> Message-ID : <20230307054350.c86a5fea5a95729ab0bf6...@rasterman.com>
> Date & Time: Tue, 7 Mar 2023 05:43:50 +0000
>
> [CH] == Carsten Haitzler <ras...@rasterman.com> has written:
>
> CH> On Mon, 6 Mar 2023 21:34:18 +0000 (UTC) Anna Cassar
> CH> <anna_cassa...@yahoo.co.uk> said:
>
> CH> e sets xsettings to tell apps that read these to uses some
> CH> specific fonts, theme, dpi etc. - i've seen qt mess up badly when
> CH> theme is set AND the qt style plugins are not there. it doesn't
> CH> fall back gracefully. not qt5 style. qt5 style plugins. the
> CH> plugins is the important bit - the thing that provides some
> CH> plugin for qt to properly do this.
>
> CH> 5:32AM ~ > pacman -Q | grep styleplugins
> CH> qt5-styleplugins 5.0.0.20170311-35
>
> CH> all i see is mixx segfault. probably because it can't connect to
> CH> jack. not very graceful. it does it even in a wm-less xephyr.
>
> CH> e also sets 2 env vars:
>
> CH> QT_QPA_PLATFORMTHEME=gtk2
> CH> QT_STYLE_OVERRIDE=gtk2
>
> CH> this tells qt to use the gtk2 style to do theme stuff. you could
> CH> unset these in a terminal and run mixxx from there and see.
>
> CH> it might mess up if it doesn't like the dpi set - but then that'd
> CH> be it's problem for not rendering at that dpi to scale correctly
> CH> - regardless of the value. either ignore the dpi or use it as
> CH> given. don't use it then fall over if the value isn't one you like.
>
> I think everything written here is out of line.
>
> I mean, I have no problems with mixxx look and feel on any WM on my
> PC, not just enlightenment, but twm, Plasma5, Gnome, e16, and icewm.
>
> I can only assume that there must be a problem with the build of
> enlightenment.... (_ _?
that's not how x11 works. mixx is in charge of rendering its own content. it
does so directly using x11 protocol to its own window. e just composites the
resulting bitmap. the "it only happens in e - thus i blame e" is a bit of
continuing false logic almost always from people who have no idea how apps,
toolkits, wm's, x11 or compositors work.
your logic is flawed. e is not involved in rendering, it's the client side that
does that. at worse e setys the env vars to tell qt to use a gtk handling style
plugin to make themes match between gtk and qt falls over badly when it can't
find the gtk style plugin and qt or e sets dpi to something qt/mixx does not
like. but both of these would be bugs on the client side.
i've explained that e sets some env vars to encourage qt to use the gtk style
plugin so it will inhrit theme information from gtk. if qt completely falls
over as a result of this, then qt is not very good at handling its own errors.
there is no way for e to know if qt can or cannot handle gtk themes. there is
no mechanism to find out. if it's this then unset the env vars OR install the
style plugins as i mentioned so qt stops failing poorly. it could also be that
e set a dpi value lower than qt5/mixx would expect. there is nothing wrong with
setting a low dpi. if you have a low dpi screen then this is exactly what you
want. if this is the issue the problem is STILL in qt5 or mixx. it's not e's
fault or problem that it sets a lower dpi value. you can find out the above by
unsetting the above env vard then running mixx from that shell. you can find
out if its xsettings dpi by disabling e's x settings feature - logging in again
to clear everything out and running mixx (also try both with env vars gone an d
x settings not there). but just saying "it's e's fault" is not even trying to
narrow down what on qt/mixx's side the problem is as the problem *IS* over
there as e has NOTHING to do with the rendering of an x11 client - only the
final compositing of the resulting image.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - ras...@rasterman.com
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
