Please make all your UI's scalable for 4K displays

[Lucretia]

It's impossible to read any of the text on all your apps / plugins. Either, add a scale factor to the ui, or scale with window size and save the size or put in a prefs editor.

[harryhaaren]

Hi, thanks for reporting, yes I'm aware the current UI doesn't scale to HighDPI screens, and indeed the latest AVTK code includes UI scaling. Luppp is not built using AVTK however, so I'm not sure if this will ever be implemented. As far as I know, there is no active effort going into FLTK/NTK supporting HighDPI at the moment... but I'm not very close to those projects right now.

I'll leave this open, tagged with "Feature Request" to track the HighDPI UI improvement potential. Cheers, -Harry

[Lucretia]

The issue is that the UI's in these programs are all hardcoded which is bad in itself. The fonts are set to 10pt, which is small on 1080p.

Is there any docs explaining the differences between ATVK, FLTK and NTK?

[harryhaaren]

Yep I'm aware that coding pixel values doesn't exactly scale (in both effort to change and HighDPI contexts..) however it was a way to get things done quickly at the time. Also yes to hard-coded fonts etc, I'm aware there are many issues regarding HighDPI/hi-res.

Note that simply drawing things bigger isn't the solution - line widths need to increase for HighDPI too, (which AVTKA actually does handle properly).

FLTK is a C++ UI toolkit, its been around a very long time. NTK is an FLTK fork, with Cairo to render/draw things, and some more X-embedding capabilies (create by another Linux Audio dev, for the "non" suite of tools). I used NTK as I had Cairo widgets available (from previous GTK UIs), however GTK is not suitable for LV2 UIs, hence the port to NTK. NTK itself also had (has?) some issues in theory with embedding, hence I created AVTK, then AVTK2, then AVTKA. Depending on a projects needs/requirements, each one of those is a better match. None of them are "proper" UI toolkits like QT, GTK or whatever, but each has features that QT or GTK etc don't have. (Eg, minimalistic deps, easy to cross compile and run on a low-end/embedded context).

If i was doing Luppp again from scratch, I still wouldn't know what UI to use... its a complex field, and there's tradeoffs everywhere. Most commercial apps seem to use QT with GL embedding for fancy stuff (Mixxx also does this). It works but is not suited for embedded usages (which is currently an intrest for me, see the OpenAV Ctlra project).

Thanks again for reporting - as you can see its not a "quick fix" and I'm not sure Luppp's UI will change any time soon - sorry. Regards, -H

[Jee-Bee]

idea (for later) to get screenresolution (https://stackoverflow.com/questions/8690619/how-to-get-screen-resolution-in-c#8690641) and devide the width over 128 (for example)
1280 / 128 = 10
1920 / 128 = 15
3840 / 128 = 30
4096 / 128 = 32

[Lucretia]

It's been a while since I've messed with anything audio related...

Thanks again for reporting - as you can see its not a "quick fix" and I'm not sure Luppp's UI will change any time soon - sorry.

I think it will now.

gentoo-audio/audio-overlay#442 (comment)

[wvengen]

NTK seems to do some DPI computation.
https://github.com/falkTX/ntk/blob/720d8d33200ebd030df700c6c7a5a9cdf4581c03/src/screen_xywh.cxx#L152-L176

FLTK has the environment variable FLTK_SCALING_FACTOR which could be useful. But as NTK is a bit of a dead end, as it seems, there is not that not much hope here.

I did try to compile Luppp with FLTK 1.3.8, and got it compiling (FLTK now has Cairo support), and working with a couple of minor drawing issues. See my feature/fltk branch. But FLTK_SCALING_FACTOR did not change anything here.