On Sun, 12 Mar 2023 23:57:49 +0000 (UTC) Anna Cassar via enlightenment-users
<enlightenment-users@lists.sourceforge.net> said:
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
e doesn't give any ratios... unless you mean ythe xsettings and xrdb xft.dpi
settings and there are noty incorrect settings here. it's a number that affects
scaling - anything renders to a dpi. e sets this to get apps to scale based on
your scale preferences. the goal is to have everyone consistent. that means
font X at size Y (eg Sans 10) draws the same everywhere. e sets dpi
appropriately to have this happen. if that dpi causes some apps to mis-render,
then the problem lies with that app and its toolkit.
if i tell you "you have a very low res TV very close to you so it have things
sized well i want you to use 50dpi" then... you do that. you use the dpi given
if that is how you scale things. this is what e does. it does seem some apps
just have never been tested with various dpi values and fall apart. that
doesn't make it an e bug - it makes it an app or toolkit bug where it just
can't handle some dpi that is given.
efl itself doesn't use dpi at all - it does not care. it does tell freetype
when rendering a font to use 75dpi because that is the old school dpi that was
commonly used when i started writing the font engine for evas, thus "sand 10"
in evas and in x would generally look the same. efl doesn't use dpi for scaling
- it relies on being given a scale factor. this is used to just go multiple
sizes of things, including font size internally as well as size of other items
marked to scale. so scale 0.5 means "draw things 1.2 the size as normal" or
scale = 2.0 == "draw it 2x the size" or scale 1.378 = draw it 37.8% bigger than
the default standard size. qt also supports this kind of scaling - gtk though
does not. or more specifically gtk does but ONLY integers. 1x, 2x, 3x. 4x. gtk
does not handle fractional scaling (it's been something gtk is working to fix i
understand), thus e sets dpi to try force fonts at least to match.
but again - this is an app or toolkit bug if it can't handle a given dpi (of
course assuming the dpi is sane = setting a dpi of 1 or 0 or 1993204 is probably
a bug).
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;
aaah e doesn't set dpi to the correct value. as above. the only way to get gtk
AND qt to both scale in any sensible way is to set the dpi to something to
make it scale. of course SETTING dpi is wrong, but the older toolkits and apps
have it in their head that this is how you scale - you fake the dpi. to me the
dpi is a fixed property of a display device and does not change - never should
change. it's used only when you want to specifically draw something at a
physical size on that display. buty... that's now how these older toolkits
think.
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
i suspect this rounding feature might be like rounding down? and thus a dpi
like 90/96 rounds down to 0 by qt and thus falls apart totally. thus would be a
qt bug though... :)
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.
e sets both xft.dpi xrdb and xsettings dpi. these are set based on your
selected scale factor and "application base dpi" (look in advanced scale
settings in e). e sets these 2 dpi values to base dpi * scale factor. e.g. if
you use scale 1 then it sets it to 75. this achieves the above consistency (for
me at least) and pixel for pixel regular gtk, qt and efl apps draw the same
font at the same size. you can adjust this base dpi if you want. advanced
feature of course :) this will cause gtk and qt apps then to scale differently
- how they do it is up to them but e just sets the 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
a combo of mixx and qt. i suspect removing that rounding factor logic will
suddenly fix it. i think its actually a qt feature and code path that is kind
of broken and some apps like mixx (and freecad) request this feature not
realising it is kind of broken... :)
personally - an app that segfaults on start (probably because it can/'t find
jackd as i use pulse) without a sensible error dialog or some fallback hints to
me that the developer is not polishing things as well as they could which
makes me suspect other things may not be as nicely polished. :)
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
