Re: [e-users] Having issues getting mixxx to work

I seem to recall when I originally got lost down this rabbit hole there 
were high DPI related issues with some QT apps.  I think an xorg-server 
change/fix affected things as well - think Xorg used to set everything 
to 96dpi;


https://www.mail-archttps://www.mail-archive.com/[email protected]/msg06880.htmlhive.com/[email protected]/msg06880.html 
<https://www.mail-archttps://www.mail-archive.com/[email protected]/msg06880.htmlhive.com/[email protected]/msg06880.html>

> /"DMX DDX has been removed. - X server now correctly reports display 
> DPI in more cases. This may affect //
> //rendering of client applications that have their own workarounds for 
> hi-DPI screens."/


Looks like some things may improve with QT6;


https://doc.qt.io/qt-6/highdpi.html


...or perhaps the fun will start all over again with everything looking 
wrong and we'll all need to find more workarounds :)


On 13/03/2023 14:34, Carsten Haitzler wrote:
> On Sun, 12 Mar 2023 23:57:49 +0000 (UTC) Anna Cassar via enlightenment-users
> <[email protected]>  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
>> <[email protected]>  wrote:
>>   On Sat, 11 Mar 2023 19:36:56 +0900 Masaru Nomiya<[email protected]>
>> said:
>>
>>> Hello,
>>>
>>> In the Message;
>>>
>>>    Subject    : Re: [e-users] Having issues getting mixxx to work
>>>    Message-ID :<[email protected]>
>>>    Date & Time: Tue, 7 Mar 2023 05:43:50 +0000
>>>
>>> [CH] == Carsten Haitzler<[email protected]>  has written:
>>>
>>> CH>  On Mon, 6 Mar 2023 21:34:18 +0000 (UTC) Anna Cassar
>>> CH><[email protected]>  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 [email protected]
>>
>>
>>
>> _______________________________________________
>> enlightenment-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>>    
>> _______________________________________________
>> enlightenment-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>
-- 

Φ SNAKΣ ΣYΣZ Φ

_______________________________________________
enlightenment-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-users