Replace GUI Toolkit with QT

[lordfolken]

I know this is a long shot, but:

QT is supported on all the relevant platforms:

• https://doc.qt.io/qt-5/android.html
• https://doc.qt.io/qt-5/linux.html
• https://doc.qt.io/qt-5/windows.html

One of the major complexities is the GUI Toolkit that we currently use. (IMO). Moving to a well known[tm] system would lessen this.

QT would be attractive to developers and is well understood at this point.

kflog also seems to use qt: http://www.kflog.org/2016/07/cumulus-5-29-1/

[MaxKellermann]

I agree that it would be advantageous to migrate to a standard GUI toolkit, but I fear that Qt is not a good candidate.

• it requires an obscure preprocessor (moc) which means you're writing moc and not C++
• Qt is a bad citizen in the C++ world, e.g. declaring redundant classes such as QString instead of std::string, which adds overhead for each roundtrip from C++ and Qt; it has its own idea of multi-threading, instead of using what the C++ standard provides; and much more
• Qt works badly on the Kobo (just compare the performance of the original Kobo Qt-based GUI with XCSoar's software renderer)
• Qt has QML which sounds like a good idea, but it has yet to be demonstrated that it is as powerful as XCSoar's dynamic modal dialog code, which easily adapts to all screen formats and screen densities
• Qt adds a lot of bloat and runtime overhead; XCSoar's static Kobo binary weighs 5 MB (which already includes the whole GUI toolkit, the C++ standard library and the C standard library!), and Qt adds a whopping 25 MB to that, WTF!

Of course, XCSoar's GUI toolkit has large weaknesses (next to its great strengths). And Qt has advantages. Unfortunately, Qt is pretty much the only choice for a cross-platform toolkit. I wish we had better choices.

[hor63]

Question is: What do we gain using QT, or what are we lacking with what we have. Is the Staus quo good enough compared the drain on already unsufficient resources to achieve the same with a different toolkit and maybe more contemporary look? I‘d say: Let‘s choose our battles wisely, and stick in this area with what we have. Unless someone dedicates him/herself full-time on the topic. Cheers, Kai

…

Sent from my iPad On Apr 8, 2019, at 22:28, Max Kellermann <notifications@github.com<mailto:notifications@github.com>> wrote: I agree that it would be advantageous to migrate to a standard GUI toolkit, but I fear that Qt is not a good candidate. * it requires an obscure preprocessor (moc) which means you're writing moc and not C++ * Qt is a bad citizen in the C++ world, e.g. declaring redundant classes such as QString instead of std::string, which adds overhead for each roundtrip from C++ and Qt; it has its own idea of multi-threading, instead of using what the C++ standard provides; and much more * Qt works badly on the Kobo (just compare the performance of the original Kobo Qt-based GUI with XCSoar's software renderer) * Qt has QML which sounds like a good idea, but it has yet to be demonstrated that it is as powerful as XCSoar's dynamic modal dialog code, which easily adapts to all screen formats and screen densities * Qt adds a lot of bloat and runtime overhead; XCSoar's static Kobo binary weighs 5 MB (which already includes the whole GUI toolkit, the C++ standard library and the C standard library!), and Qt adds a whopping 25 MB to that, WTF! Of course, XCSoar's GUI toolkit has large weaknesses (next to its great strengths). And Qt has advantages. Unfortunately, Qt is pretty much the only choice for a cross-platform toolkit. I wish we had better choices. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#181 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/APbi3UwVzwhVEw4b4sCT5trrdrhSQldeks5ve6Z5gaJpZM4cjAKk>.

[MaxKellermann]

A nice overview: https://philippegroarke.com/posts/2018/c++_ui_solutions/

[markus2marks]

Is it possible that we use the wxwidget library. Do you have think about it?

[MaxKellermann]

I always thought of wxWidgets that it combines the worst of all, being just a wrapper for some other native toolkit. On Linux, wxWidgets adds 20 MB, plus a dependency on GTK3 (another 10 MB).
I don't know how good wxWidgets's Android support is, and even less if it works on the Kobo at all. Kobo support is probably the most difficult part; I think no toolkit beats XCSoar's highly optimized code here.

[markus2marks]

Ok, thank you for your opinion. But the design of the buttons and so on are very bad. With a library like wxwidget its so easy to make it better.

[MaxKellermann]

But the design of the buttons and so on are very bad. With a library like wxwidget its so easy to make it better.

Here's the code for rendering a button:

XCSoar/src/Renderer/ButtonRenderer.cpp

Lines 36 to 92 in acaa572

	void
	ButtonFrameRenderer::DrawButton(Canvas &canvas, PixelRect rc,
	bool focused, bool pressed) const
	{
	const ButtonLook::StateLook &_look = focused ? look.focused : look.standard;
	canvas.DrawFilledRectangle(rc, _look.background_color);
	const unsigned margin = GetMargin();
	if (margin < 4) {
	/* draw 1-pixel lines */
	canvas.Select(pressed ? _look.dark_border_pen : _look.light_border_pen);
	for (unsigned i = 0; i < margin; ++i)
	canvas.DrawTwoLinesExact(rc.left + i, rc.bottom - 2 - i,
	rc.left + i, rc.top + i,
	rc.right - 2 - i, rc.top + i);
	canvas.Select(pressed ? _look.light_border_pen : _look.dark_border_pen);
	for (unsigned i = 0; i < margin; ++i)
	canvas.DrawTwoLinesExact(rc.left + 1 + i, rc.bottom - 1 - i,
	rc.right - 1 - i, rc.bottom - 1 - i,
	rc.right - 1 - i, rc.top + 1 + i);
	} else {
	/* at 4 pixels or more, it's more efficient to draw a filled
	polygon */
	const BulkPixelPoint p1[] = {
	BulkPixelPoint(rc.left, rc.top),
	BulkPixelPoint(rc.right, rc.top),
	BulkPixelPoint(rc.right - margin, rc.top + margin),
	BulkPixelPoint(rc.left + margin, rc.top + margin),
	BulkPixelPoint(rc.left + margin, rc.bottom - margin),
	BulkPixelPoint(rc.left, rc.bottom),
	};
	canvas.SelectNullPen();
	canvas.Select(pressed
	? _look.dark_border_brush
	: _look.light_border_brush);
	canvas.DrawTriangleFan(p1, ARRAY_SIZE(p1));
	const BulkPixelPoint p2[] = {
	BulkPixelPoint(rc.right, rc.bottom),
	BulkPixelPoint(rc.right, rc.top),
	BulkPixelPoint(rc.right - margin, rc.top + margin),
	BulkPixelPoint(rc.right - margin, rc.bottom - margin),
	BulkPixelPoint(rc.left + margin, rc.bottom - margin),
	BulkPixelPoint(rc.left, rc.bottom),
	};
	canvas.Select(pressed
	? _look.light_border_brush
	: _look.dark_border_brush);
	canvas.DrawTriangleFan(p2, ARRAY_SIZE(p2));
	}

Yes, the button looks ugly and easy to make better. But you don't need wxWidgets for this. Just write some code, and submit it as a pull request.

wxWidgets is incapable of rendering to the frame buffer on Linux; it requires X11 or GTK. I don't think it's a good candidate for XCSoar. It would add shitloads of unnecessary bloat. If anybody disagrees - show me some code and demonstrate that it runs well on all devices that Linux supports (Linux, Windows, Android, Kobo, Raspberry Pi with KMS or Wayland, ...). That's a very tough benchmark, but XCSoar's custom toolkit can do that extremely well (but is also extremely ugly).

[kubark42]

I realize this is an older topic, but I thought it would be worth chiming in. My background is having used Qt extensively, including for a drone Ground Control Station and a sailboat chart application.

I agree that it would be advantageous to migrate to a standard GUI toolkit, but I fear that Qt is not a good candidate. It requires an obscure preprocessor (moc) which means you're writing moc and not C++.

I don't understand this point. Everything in our GCS was written directly in C++ and QML, we never had a reason to work with the moc files. These were automagically generated in the background, much like using CMake or any other build system.

Qt is a bad citizen in the C++ world, e.g. declaring redundant classes such as QString instead of std::string, which adds overhead for each roundtrip from C++ and Qt; it has its own idea of multi-threading, instead of using what the C++ standard provides; and much more

I would argue that this is a feature, as C++ is not intended to be a multi-platform toolkit. There is a sublime beauty to being able to test your app on your desktop and know that it will look identical on every other platform, including iOS and embedded.

There are of course compromises, but in my experience the time and effort we saved was the so substantial that I don't see how we could have succeeded otherwise.

Qt works badly on the Kobo (just compare the performance of the original Kobo Qt-based GUI with XCSoar's software renderer)

That sounds like a blocker. Although Qt works on iOS and embedded, so you'd have to weigh it were worth it to lose a platform in order to gain another.

Qt has QML which sounds like a good idea, but it has yet to be demonstrated that it is as powerful as XCSoar's dynamic modal dialog code, which easily adapts to all screen formats and screen densities

In my experience, Qt excels at adapting to different screen sizes and densities. That's not to say it's as good as what you already have.

Qt adds a lot of bloat and runtime overhead; XCSoar's static Kobo binary weighs 5 MB (which already includes the whole GUI toolkit, the C++ standard library and the C standard library!), and Qt adds a whopping 25 MB to that, WTF!

Speaking from an embedded C background, where debates are about saving 4 bytes by using a float vs double, I never noticed the extra size in the UI. HD space is so much cheaper than developer time, and when 5 pictures on my phone take up 25MB and I get 50MB attachments via email it's hard to make a strong case that 5MB or 25MB is blocking.

FWIW, the binary might grow by even more when using QML, but I have never in my life seen anything as easy to develop as QML. It's almost magical the way the front-end javascript interacts with the backend C++, and it's impossible to overstate the advantage of decoupling front end people-- often time artists and others with limited computer programming background-- from the icky backend.

Of course, XCSoar's GUI toolkit has large weaknesses (next to its great strengths). And Qt has advantages. Unfortunately, Qt is pretty much the only choice for a cross-platform toolkit. I wish we had better choices.

It would be nice to have more choices. IMHO, the biggest reason not to turn to Qt right now is the result of a company decision in January to make it much harder to use Qt for dev: https://www.qt.io/blog/qt-offering-changes-2020. The requirements to have an account mean that automated dev installs will die, with the upshot that it's very hard as project maintainers to make it so that everyone is contributing from the same versions. The loss of LTS is heartrending, as that means for safety critical tasks (which I think XCSoar is) that there is a loss of significant control over QC. That's a huge no-no.

Of course, Qt can change course and undo these changes (and the marvelous KDE org is working hard to get a change of direction), but the fact that it has tried this is enough to make me think hard about using Qt any further. It seems likely that the KDE community will be able to continue development, but nowhere near as much and as fast as with corporate backing.

There's also Flutter, but I don't think you'll get anywhere near the battery performance you get with Qt.

[kubark42]

One more thing to chime in on (as a separate post because it's a separate notion from the above)

Question is: What do we gain using QT, or what are we lacking with what we have.

Quite possibly nothing, but it's important not to think of Qt as a GUI framework. It's a cross-platform interface framework, which interfaces as easily with people as with other machines. It has native support for BLE, serial ports, files, networking, maps of all kinds, javascript libs, online stores, user registration, etc... It's a swiss-army knife platform, and it works exceptionally well.

So if your feature roadmap has you moving in lots of directions, all of which are orthogonal to each other, then Qt is immensely valuable. For instance, if you wanted to run a BLE interface with new-fangled wireless sensors, while providing an app which worked on iOS/Android and macOS/Win/Linux/embedded, and not blowing the battery budget, and supporting a variety of map sources, all while uploading user data (e.g. crowdsourced thermal location) in real-time, Qt would be the only way forward (short of having a hugely talented and diverse staff).

If you're focusing on doing one thing and doing it extremely well, then stick with what you've got.

Is the Staus quo good enough compared the drain on already insufficient resources to achieve the same with a different toolkit and maybe more contemporary look?

Support burden decreases significantly with Qt, both for doing development and bring onboard new devs. We gained significant momentum by lowering the barrier to contributions. People who had the UI/UX skills we needed were able to come up with meaningful code, instead of being stuck at only making feature requests in forums.

I‘d say: Let‘s choose our battles wisely, and stick in this area with what we have. Unless someone dedicates him/herself full-time on the topic.

Amen.

[MaxKellermann]

Current Qt company politics means Qt is unacceptable to switch to. Maybe the KDE project decides to do a full-blown fork, that would be perfect. But Qt has lost a huge amount of my trust this week. It is hard to estimate the permanent damage that the Qt company has done to its own product with this move.

[lordfolken]

So there would be flutter

• Native binaries (linux,windows,osx,ios,android)
• C++ bindings
• Desktop support

Its google owned..

[scls19fr]

Flutter have interessing map widgets https://github.com/fleaflet/flutter_map https://www.syncfusion.com/flutter-widgets/flutter-maps https://www.youtube.com/watch?v=X48VuDVv0do https://pub.dev/packages/mapbox_gl (and probably more) which could be used to draw WMS / WMTS maps as mentionned in #521

[Lenart12]

What about using HTML, every platform supports web rendering. It has ease of development and powerful styling/resizing.

[MaxKellermann]

What about using HTML

gasp ... I hope this is satire and you're not serious. Everything is wrong with this idea.

every platform supports web rendering

The Kobo does not.

ease of development

It's easy for you because it's all you know. It's not easy for me.

powerful styling/resizing

What ... does that even mean? Powerful styling - ok, your dog can edit the CSS and suddenly the buttons are purple or something, if that's important. But your dog can also edit ButtonLook.cpp and have purple buttons, so what's the difference.

XCSoar/src/Look/ButtonLook.cpp

Line 35 in 2286f86

standard.background_color = IsDithered() ? COLOR_WHITE : COLOR_LIGHT_GRAY;

But .. "powerful resizing"? What the hell is that?

If you are serious, then you should first measure the overhead of HTML+JS compared to XCSoar's highly optimized UI toolkit. My estimate is that adding HTML+JS would make XCSoar 100 times slower (and drain 100 times more battery).
Just look at how awfully slow today's HTML-based UIs are; there's this certain Electron-based code editor which eats 90% of a modern multi-gigahertz CPU just to render a blinking cursor while the user does nothing; and it's slower than the IDE I had more than 30 years ago on a 25 MHz 80386.
There's this HTML-based chat app which consumes a gigabyte of my RAM, and switching channels takes several seconds (= billions of CPU cycles). In the 90ies, switching a channel on IRC was faster than the spring under my keyboard's keys could push the button back up.
The 90ies was peak computer speed, and everything has only become slower since, but how is that possible? CPUs are 1000 times faster now. It's (partly) because HTML.

Everything looks like a nail if all you have is a hammer. HTML is your hammer.

[Lenart12]

I said HTML because wxWidgets has a widget that supports it. It's great that the software runs like in the 90s but I was thinking of ways to make it look like its not also in the 90s, out of style and horrible configuration UX (you can debate this all you want, it just is).

I do not get what this performance rant was about. I was looking for options to improve on the look and feel of the app since this is what it is lacking the most. And changing the color of a button to purple will not solve that. How often will users interract with the configuration menu while in flight that the battery will be a problem.

You want more performant options, what about LVGL or ImGUI replacing the menu implementation and keeping the current map rendering. Both can be easily integrated with plug-in drivers and have more configuration with little performace overhead, from experience I used LVGL on an ESP32 with great performance.

For the record I am a c++ developer as was hoping to contribute to this great project but after this warm welcome I will have to think 1000 times slower if I want to help. Maybe my dog will help in the meantime.

[MaxKellermann]

ways to make it look like its not also in the 90s, out of style

That's a question of taste, but even if you don't like the look, changing the look will not solve anybody's problem, it will only make its appearance pleasing to some people. But I repeat what I already wrote in this thread, because you repeated what somebody else already wrote 2 years ago.

and horrible configuration UX (you can debate this all you want, it just is).

If you don't like the configuration dialog, switching to HTML will not improve this. If you have an idea how to improve the UI, the toolkit does not matter.

And changing the color of a button to purple will not solve that.

Of course not. I was only ridiculing your argument about HTML being easy to style. Which solves zero practical problems.

You want more performant options, what about LVGL or ImGUI replacing the menu implementation and keeping the current map rendering. Both can be easily integrated with plug-in drivers and have more configuration with little performace overhead, from experience I used LVGL on an ESP32 with great performance.

How will LVGL and ImGUI improve the configuration dialog? XCSoar already has a fast UI toolkit.

There may be good reasons for switching to a different UI toolkit, but you named none.

For the record I am a c++ developer as was hoping to contribute to this great project but after this warm welcome I will have to think 1000 times slower if I want to help. Maybe my dog will help in the meantime.

I heard this kind of drama so many times. "Oh, I was about to contribute, but now you turned me off, there you have it, in your face!" - If you really feel XCSoar should be improved, just do it, more code and less drama, but if this "warm welcome" and blaming me is more important than your urge to improve XCSoar, there isn't much to be expected from you anyway.

[Lenart12]

Here is my point of view on the problem.

How will LVGL and ImGUI improve the configuration dialog? XCSoar already has a fast UI toolkit.

Yes it is fast, also it is extremly ugly and has minimal features. So why brag about speed? LVGL is fast, can be configured to be as pretty/ugly as you want. It is also way less work than expanding the existing toolkit. What difference does it make if I expand the existing buttons to have the option to be anti-aliased, have shadows and rounded, etc.. or just use a library that already does that, with more optimization that I could manage to fit in in my spare time. Your whole focus being on "practical" problems is why the UX is the way that it is but it could be much better. I have a problem with how the app looks and is complicated and tedious to configure for new users. And I know I am not the only one so saying this wouldn't solve any problems is just ignorant.

The last part was not ment about me, it was about how incredibly rude and unprofessional you are, and how your actions reflect on the community. Ironic that you complain about drama but then you call people as skilled as a dog and go off on rants.

[MaxKellermann]

So why brag about speed?

I "bragged" about the speed of XCSoar's UI toolkit compared to anything HTML-based. Not because XCSoar is particularly fast, but because switching to HTML would make it unbearably slow. So it's not actually "bragging", but pointing out disadvantages of your idea.

I have a problem with how the app looks

You keep repeating that, no matter how often I say I don't care.

and is complicated and tedious to configure for new users. And I know I am not the only one so saying this wouldn't solve any problems is just ignorant.

No, you are being ignorant. You keep ignoring what I say. I do acknowledge that the XCSoar UI should be improved (the usability, not the look). I asked you how switching the UI toolkit would improve that problem, but you keep not answering my question. You still did not. Instead, you keep repeating yourself on other things, going large circles around my question.

The last part was not ment about me, it was about how incredibly rude and unprofessional you are, and how your actions reflect on the community.

You keep up the usual storyline. It bores me, I know that saga already. I've heard it so many times. And if so many people tell the same tale, it must be the truth! /s

What do you expect to happen, now that you have called me out, and revealed my true character to the world? Is that only for your personal satisfaction after you felt goofed on my be, or do you want consequences, do you want the community to chase me away?

Oh yes, please, I'd very much like the project to get along without me (seriously, I've quitted flying 7 years ago and I have no time for hacking XCSoar). Tried that, I had been away for a few years, but it turned out the people who kept complaining about me did not actually manage to write any code in those years. Talking is cheap, complaining is cheap, drama is free, only coding is hard. That's why I choose not to care much about drama people. What counts is code. My prediction is that none will come from you, only more drama, but I'd be very happy to be proven wrong.

Ironic that you complain about drama but then you call people as skilled as a dog and go off on rants.

I did not call "people as skilled as a dog". I wrote "your dog can edit the CSS", but I did not say anybody is as skilled as (any/your) dog. Oh, that's what you call "incredibly rude", because you read things that I didn't actually write.

[lordfolken]

Seeing all the drama, I kind of would like to close this discussion.
I originally started it because i didn't undertand xcsoar's (nor anyother) toolkits for uis when i initially wrote this.

The usability issues are certainly there. There is a project that tracks issues related to that https://github.com/XCSoar/XCSoar/projects/3
Changing the ui toolkit however will not fix these.

XCSoar's ui may be quirky, but i don't know another ui toolkit that handles so many use cases at once. XCSoar has input with gloves, joysticks, keyboards etc. Its designed for high contrast (so its readable on lousy screens), e-paper displays etc.

The irony being that modern uis such as material you is already closer to xcsoar's current look than any of its predecessors