Hydrogen: UI refresh

[elpescado]

While I was working on support for high resolution screens I noticed that current UI - that is based on pixmaps - has some shortcomings:

• It's not translatable, which means that some parts of UI cannot be localised at all. And even if there was a possibility to load different pixmaps for different languages, translating would require creating separate images, thus a lot of pixel pushing. See instrument editor, most of text there is not translated.

• It's not scalable, so it looks pixelated on hide resolution screens. While technically doable, fixing this requires recreating all pixmaps in high resolution, which is a lot of work.

• Developing new features might require creating lots of graphic assets, which is tedious task and it's hard to achieve consistency (look at pixel font throughout Hydrogen UI, there are slight differences everywhere)

• It looks a bit dated, like a holdout from WinAmp era;)

It would be nice to have UI redesigned. I have some ideas how it could be implemented:

• In code, using QPainter API (might be complicated)

• Using SVG (not sure about performance)

• Using QML (not sure if it's possible to use QML from plain Qt app)

• Using Qt CSS implementation (not sure what are limitations)

Of course, that's huge undertaking, but maybe someone is looking for ideas:)

What do you think?

Cheers!

[mauser]

Hi!

Good that you bring this up. I had a discussion with @theGreatWhiteShark recently where we talked also about this topic. With highres display getting more widespread every year, this has been also a big downside of Hydrogen. But we were also talking about the costs and that a major rewrite would be more or less impossible because of the sheer size.

But maybe we could work on the problem issue by issue? I suspect that using SVG for buttons would be sth. that can be done as a first start. Especially if we do not create a complete new design and try to mimic the look of the current buttons.

I'm absolutely unsure about these things, and i don't know how other modern QT applications tackle these problems. I suppose that i also can't offer a lot of help.. my personal playground is LV2 support for Hydrogen at the moment, and even the time for that is quite limited :) .

[trebmuh]

[OT]

my personal playground is LV2 support for Hydrogen at the moment

Nice to read :sunglasses:

[cme]

Replacing existing images with SVG seems a reasonably straightforward change and worth considering even if it's not regarded as a final solution:

• Doesn't require major rework or restructuring of the code

• 1-1 mapping of old pixmap resources to new SVG resources makes it easy to separate the graphical design work into something a non-coder could do.

• If there aren't already tools available to localize text in SVG files, it should be fairly simple to add one to allow translations.

Thinking about it a little more, it should be possible to wrap up almost all the necessary code changes as a pixmap loader to replace the uses of QPixmap::load, which would load and render an available SVG file to a device-resolution pixmap rather than just loading an existing pixmap (and also handle mapping regular DPI pixmaps to device-resolution pixmaps if they're still in use) That would also remove any concerns about runtime performance of SVG rendering.

Hmm.

[theGreatWhiteShark]

How about making a call for "translating" pixel to vector graphics on the mailing list similar to the ones @trebmuh did for the localisation stuff? After all this is a topic completely orthogonal to any of our C++ code.

[elpescado]

Hi!

I am perfectly aware that this is a truly epic task;) Anyway, I'd like to share some remarks.

My original plan while working on #487 was to create code that, when image file was requested and hight DPI screen was detected, tried to load file with the same name as requested and @2x prefix added, and fall back to regular file. The code part was easy, so once it was done I tried to upscale some images to see how does it look. I managed to do borders around player controls, when I realised, however I was pleased with result, that it's simply too much work.

❯ find ./data -name '*.png' | wc -l
     278

I'm afraid that SVG solution requires even more effort. Upscaling pngs is tedious but simple task. Redrawing those pixmaps as vector graphics might prove much harder. Then there's problem with internationalisation. Even if we manage to translate labels in SVGs (that might be tricky but is certainly doable), 1:1 mapping pngs to svgs means that we retain fixed layouts and those do not play well with translations. The same text in different languages might require different amount of space and might not fit provided space. The solution is to use dynamic layouts wherever translatable text is displayed. See #397

That way, I thought that maybe complete overhaul of the UI, while requires the most effort, is the most effective way. I.e. it might be 50% more work but benefits are 300% more (numbers are made up by me;D). I'm aware that probably no one right now has resources to pick up that task (certainly I do not have, however I wish I could), I think it's worth discussing - maybe someday some brave one comes to slay this dragon;)

I'm absolutely unsure about these things, and i don't know how other modern QT applications tackle these problems.

I think that most desktop apps these days use just plain Qt without too much custom UI. Audio apps seem to remain the last stronghold of skinned ("skeuomorphic") interfaces. In embedded world where Qt is also used and custom UIs are much more common, I'm not sure, maybe QML is used?

Cheers!

[cme]

Oh, wow. I must admit I hadn't explored these bits of the UI in enough depth to realise just how monolithic some of these UI pixmaps actually are. Old school in the extreme.

Replacing these with SVG in any coherent and consistent way is not only a much larger task than I'd guessed, but also one that looks incredibly monotonous and unrewarding.

It starts to feel like rebuilding the UI (possibly involving building the widget set that the current interface looks as if it's built from :D ) is a desirable way to go.

[elpescado]

That's what I've been thinking - create a new widget set (there are that many of them) and rebuild UI using those widgets.