Libui: GUI library in C

I dunno. My peers don't write UI much at all; I do these things as force multipliers for my own nefarious purposes.

None of it gets "published" in a formally supported way, so I don't have any accountability for 'em. They're intentionally ugly but not dissonantly so. The design is "look, but don't touch." I mainly use them to anticipate integration errors and do something useful to aid in diagnosis of those. The theme here is "it ain't me, babe" or "holy cow, thanks for finding that" - determination on that axis.

But I also put adequate instrumentation in to exploit in the first place. Seems to be a lost art.

To me, the perfect user interface is no user interface at all - maybe a "push to start" button - a physical button. Second best is command line/scripting, third is the sort of thing I write.

In the embedded space, you might get a perception that this is cheating. I just smile.

This is simply not true.

We are closer to hitting 60 fps (or whatever your EDID actually presents) than ever before, and staying locked to that. The more complex of an interface you create, the harder that is, but that is no different today than ever before. Work is underway doing something similar to the webrender concepts which will improve render times even further.

I'm not sure what you mean by visual consistency, other than we create new widgets as designers ask for them. Just because applications choose to use something other than say a GtkComboBox for everything is hardly our fault. I welcome a future where application developers can decide what UI concepts work for them.

That doesn't mean you can't use deprecated widgets. This is no different than any other platform. We experiment with new ideas, keep what works well, and deprecate what doesn't based on feedback and user testing. GTK+ is one of the few libraries that generally stays ABI stable for a decade, so deprecated is more of an indicator than "this will be removed next month" like developers are used to with web APIs.

> GTK 3 and QML (Qt5) would like to target the same space as web applications. It doesn't make sense. Applications which are written with a web UI in mind will translate very poorly on the desktop, and the opposite is also true. My experience with QML was abysmal, and definitely not worth the extra dependency. Maybe you think that you button must be big and fat and have extra space to be tapped on-to, but on a desktop this is all wasted space on the screen that I want to use for data.

Where do you get your information? Because they seem to be fairly miss-informed.

GTK+ is most definitely not trying to be a web application toolkit. The "big buttons" are that size because people have all sorts of accessibility needs different from your own. Or you're on HiDPI and we don't have 1.5x scaling (yet) as it requires more plumbing in the compositor to do 3x scaling in the toolkit and 2x downscaling (and input transformations) in the compositor. I hope to see this before long.

Personally, I'd like to see a "condensed" theme variant of sorts. Finally, thanks to all the CSS node work in 3.20, you can pretty much get that with a couple CSS lines.

> The CSS theming is nice, but they keep breaking the styles at each minor release. It's also incredibly slow. Whereas GTK+ and QML aim for rendering in a GL context, the reality is that if you want predictable performance they're going to be useless anyway.

It's no secret to GTK+ developers that the theming API was always sort of a gray area. As of 3.20 the theming API, for the first time in nearly 18 years, is considered stable.

GTK+ does not render with GL today. (There is integration to embed GL into the scene, though). That might land for 3.22, but it's a lot of work and I would not be surprised if it doesn't make it until 3.24 as it's part of the drain-the-swap redesign of the drawing model. Presumably vulkan will be supported too.

Electron is seen as a great thing because it allows web developers to finally come back to desktop. But what about we guys that learned how to build products directly for the desktop? We do not need Electron. We may need a web view to render something on it, but not Electron specifically.

Finally, as someone trying to build something to sell, I do not want the same GUI on all platforms, I just want something that looks native in each platform (not giant web buttons, for instance) and that allows me to share many components of a codebase.

I have, however, seen compositors that hit buggy mesa llvmpipe paths corrupt the visual output on the way to the GPU. But that would have happened to Qt as well unless you ran the Qt app on a non-composited desktop (which wouldn't really be an apples-to-apples comparison).

What accessibility needs are you targeting when you make the buttons and titlebars bigger? Why did this change drop suddenly? Was there a cry from the majority of your users that the widgets are too small to use with desktop inputs?

Usually when there are accessibility issues you add options to deal with that, you don't change everything for a relatively tiny percentage of your user base. Would you make all your widgets have max contrast and double the font size by default because it improves accessibility for the visually impaired?