> [...] GTK is perfectly fine for Linux. This is great news, so now it is the best time to make thin wrappers around these stable things so that we can all go make useful software..

Hoping not to start any kind of framework quarrel, but my understanding was that quite many applications (such as Wireshark, Subsurface, and OpenShot) are moving from GTK to Qt very much due to Qt being more stable. Or is the main reason cross-platform compatibility?

My personal reason is that GTK 3+ lost his track in what constitutes a desktop widget set. It's also getting slower at each release, it keeps breaking visual consistency and basic features get removed or heavily deprecated in favor of a "dumbed down" approach. So if the non-technical users are actually migrating to dumb web-apps and couldn't care less, the technical crowd which demand power features and efficiency are getting fed up. As a developer, I certainly am. The trend started already with the latest 2.x series in GTK, not with GTK 3.

My standards for quality on the desktop are way higher than what the "web" is supposed to give you today. It must be fast, consistent, and don't have any glitch.

The looks are a secondary point (and GTK 2 engines, or Qt4 for the matter) already give you great customization possibilities, which are way beyond what most other systems can do already.

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.

GTK 3 is trying to innovate a bit on the UI front, but many of the changes come with usability regressions on the desktop which I don't find acceptable anymore. Overlay scrollbars are a good example. In principle, they're a great idea. However the implementation is riddled of bugs which makes using scrollbars with a mouse a pain.

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.

>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.

QML is not targeting the same space as web applications. Its a more flexible and dynamic way of creating user interfaces. Its designed so you can create UIs for kiosks, infotainment systems, mobile applications, games, and desktops all with one toolkit. QML has components specifically for desktop development that have the same look as your traditional forms based widgets.

> It's also getting slower at each release, it keeps breaking visual consistency and basic features get removed or heavily deprecated in favor of a "dumbed down" approach.

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.

> The "big buttons" are that size because people have all sorts of accessibility needs different from your own

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?

> 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?

There are way more types of impairments than visually impaired. We do have high contrast themes to help with a subset of visual impairment. (Even visual impairment is a wide-spectrum).

Many of us may not particularly like touch screens, but an incredible number of computers that run Linux/BSD these days have touch screens. Things should work out of the box for these computers whether or not you want one.

So we can make arbitrary guesses at what the "majority" is but the reality is we have a lot of hardware that we should support. Getting real statistics about users in F/OSS is difficult due to the high overlap of people interested in personal privacy. So we try to make as informed of decisions as we can.

Additionally, more computer users than you might image have various difficulties in using the computer. Even if its not a majority, say one in ten, is still a large number of users.

Count yourself lucky that you don't have an impairment (right now). It is common that people have an impairment at some point in time (RSI, broken arm, etc).

I certainly agree that HiDPI is often way too large today (again due to the need for compositor integration), and I also agree we should have a condensed mode. However, I'd probably argue to implement a condensed mode on top of an effective 1.5x scaling (3/2) rather than yet another option in the toolkit/themes.

Why are you lecturing me on visual impairment and disabilities? At no point did I claim you ignore that user base.

>Many of us may not particularly like touch screens, but an incredible number of computers that run Linux/BSD these days have touch screens. Things should work out of the box for these computers whether or not you want one.

Okay so after all that we get to the root of the issue. Instead of a good traditional desktop experience, you want to provide a mediocre desktop/touch hybrid experience. Instead of doing one thing well, the aim is to do multiple things poorly.

I am trying to not come off as lecturing. My apologies if it was interpreted as such. You were making claims and I'm simply trying to provide examples of how other peoples computing experience might not match your own.

> Okay so after all that we get to the root of the issue. Instead of a good traditional desktop experience, you want to provide a mediocre desktop/touch hybrid experience. Instead of doing one thing well, the aim is to do multiple things poorly.

No need to get disparaging here. Clearly we don't want to provide a "mediocre" experience, nor do I think we do.

I also don't agree that supporting touch is some sort of hybrid experience these days. We aren't trying to be a mobile platform. We aren't trying to be a phone platform. Peoples traditional desktops (including many home workstations) have touch. These are real desktops bought by real people who get real work done.

I work with a lot of people who have desktops. I have two. I haven't seen anyone use a traditional desktop with touch. No one. Not once. My girlfriend is a 2d artist and she uses a wacom tablet for digital painting in photoshop. That's it.

I always disliked the huge buttons that come by default with some desktop environments, and I'm amazed the argument is "people use touch". As far as I and everyone around me is concerned, no they don't.

If it's an accessibility issue, it should be an optional solution for those who need it, not the default.

> Why are you lecturing me on visual impairment and disabilities? At no point did I claim you ignore that user base.

Even though they do.

Don't normally comment online as I find it a lot of work (it's taken me about 5 hours to put together this pretty badly written response), but while there's a GTK dev here on topic I don't want to miss the opportunity.

> There are way more types of impairments than visually impaired.

Thankfully I have perfect eyesight, however I am very dyslexic. I have problems with spelling, but Google's search spell checker and voice recognition have made huge differences to me in that respect over the last year or two.

But relevant to GTK - I have a terrible short term memory. A goldfish like short term memory. I can barely remember a sentence when switching between windows, 5 numbers is a challenge (no distractions please) and remembering how another programmer abbreviated a variable's name is a huge distraction.

I can't organise IRL or digitally. When I'm programming terminal windows just keep piling up, because I can't remember what terminals are doing what (is that sitting at a prompt or is it watching a folder with inotify?). I could click through the open terminals and disrupt my chain of thought and forget what I'm doing or I could just open another terminal, keep working and do a closing session every so often.

So onto how GTK is making my life harder: by making widgets more accessible to people with impaired vision/touch screens they've made them bigger. I can now fit less on screen and I have to remember more. I have to move between windows more and I have to scroll more. This really is making my life much harder, I'm honestly getting lost on my desktop because I can't remember shit and I'm constantly having to switch windows - because there just isn't room any more for two side by side windows on 720p.

And it really never used to be this way. Compare Gnome Terminal with xterm. Yes gnome terminal is better, for instance you can turn off bold fonts (Myself and many other dyslexics have problems with bold and especially italics) and have a nice GUI for changing the settings. But it's visually huge. I'm pretty sure (unfortunately not checked at all, I use XFCE - because it's smaller on screen) with the default font settings you've got just about enough space to tile 120 columns of Gedit and a 80 columns of Gnome Terminal - but not something you'd actually write code with, by the time you've got Sublime's side bar open you're going to have to shrink the fonts. And find a window manager theme with smaller borders. And find a reduced size widget theme (these often don't shrink out much whitespace). And after that somehow you'll still feel cramped, maybe it's because everything has been unnaturally shrunk.

And, really ranting now, the web is the same, I'm starting to quite regularly zoom out on websites to make them more navigable, I'm getting lost scrolling between the massive headings and huge white spaces. I can't find the damn menu buttons and by the time I've found them I've forgotten why I wanted them and have to mentally backtrack (What am I doing? Why? So why was I reading this? What was the bit that sparked something? Oh yeah! Right, back to the menu! Where did that menu go again?...).

Going to the terminal example again if I want to tile my XFCE Terminal and a Digital Ocean tutorial I've to zoom Digital Ocean to 90%. And Digital Ocean are efficient with screen space.

I'm currently using a 720p 13" laptop display and I think my next laptop is going to have to have a 1080p screen, just so I can fit whatever I'm working on. I'll then have to override the DPI settings of course and generally have a broken display setup. I'm looking to buy hardware and run a nonstandard setup to solve the accessibility problems that GTK has introduced for me when solving accessibility problems.

As an analogy to the situation (on bad days) I feel it's like GTK/Gnome is running around shouting "EVERYTHING MUST HAVE WHEEL CHAIR RAMPS! NO STAIRS! ACCESSIBILITY HAS SPOKEN!" ignoring that sloped surfaces can be difficult/painful for those with hypermobility syndrome. And when it's brought up "I'm able bodied but my knees are getting sore" (AKA "your widgets are too big I'm clicking around too much") the response is that it's accessibility and wanting something different is denying wheel chair users. But this response is missing that an able bodied person is having problems (they're being annoyed by it because it's causing them difficulty) and if an able bodied person is having problems then there is almost certainly someone less able who is having even greater problems.

As in able bodied people are complaining your widgets are too big because they're finding they have a higher cognitive load because they're having to switch windows more often. The reduction in general accessibility (higher cognitive load) is traded to enable specific use cases and it's considered ok. In testing you able bodied people say "this is barely harder" and your specific use case say "this is great". But what's missing that there are other people with other disabilities you never tested - we don't speak out because there's not many of us and frankly it's not very easy, both to speak out and to make a meaningful contribution to something as complex as UI ergonomics.

Basically what I'm saying is, yes it is good to have options for disabled users. But forcing the default is not a good idea and you might find you're causing problems. The default route into buildings with access ramps is still normally a set of stairs.

For example I could request that bold and italic fonts not be used anywhere in a UI, for me this would be great, but for able bodied users this would be a step backwards and reduce accessibility (the UI can't highlight important text for instance). Able users would complain, and it would be a mild "oh I liked it when the top command put the total memory in bold, it made it pop out a bit" to which GTK would correctly say "but dyslexics find this approach much easier" but this conversation misses that there is another category of people with poor eyesight who find the bold emphasis really helps them find the important details in the UI. But because GTK has made removing bold and italic default (in the name of accessibility) the user with poor eyesight has no options to turn that back on, and the community is already galvanised against allowing bold, because they did a UI study and it helped dyslexics.

> Count yourself lucky that you don't have an impairment (right now).

Worst of all is if the "but dyslexics find this much easier" statement has accusatory undertones of ableism (Despite my quote I don't feel audidude has done this). That might lead to the poor eyesight user to agonizingly craft a response over 5 hours that tries not to offend anyone in the galvanised community, because they don't have dyslexia and don't understand the difficulties faced, maybe they really are being ableist. Alternatively, and much more likely, they'll just keep quiet and GTK will carry on oblivious, making life worse for them.

Now I have got to thank GTK for being really good with having highlightable text in dialog boxes so I can copy and paste into Google. Also after spending a lot of my childhood in Learning Support classes I have to thank GTK for all the hard work they're putting into accessibility, it isn't sexy, it annoys people but it's damn important (even when I think it's going wrong and sometimes makes me wish I worked in construction).

Thank you so much for writing this post. I know it must have taken quite a bit of time to put together. I don't think all the reasons about the choices we've made were necessarily accurate, but the post is so valuable on it's own it's not worth nitpicking.

I'm sorry that things have been getting harder for you. I'll share this information when we have our summer meet-up face to face to discuss the next years work.

I can't know for sure without studying (maybe you'd be interesting in doing a study with us?) but I'd think if we can get the additional scaling factors into libmutter (the compositor layer for GNOME) that you'd have more precise control over the sizing that would work for you.

That was a pleasure to read, and sheds a different shade of light on the matter of accessibility. Definitely is going to make me think twice when designing a webpage or application. Thanks for the writeup :)

There is some great info in this post. The draining of the swamp is really good work, and seems to be starting to pay off.

I hope for the CSS theme changes there is some sort of migration, or warning - was trying gnome-staging on Ubuntu and lots of things broke with the change.

Fingers crossed that GL will bring GL Enabled cairo at the same time.

Drawing with cairo-gl/glitz/etc was never really faster than drawing on the CPU. I think it's more likely that we'd use the image surface (backed by pixman) and texture uploads.

If we are hitting a path where we expose the immediate mode style drawing (a'la cairo) then we've probably already lost the performance race.

> The "big buttons" are that size because people have all sorts of accessibility needs different from your own.

That's great, but GTK apps still don't work with screen readers, at all[1]. Big buttons don't cut it for making an application truly accessible.

[1]on platforms other than Linux, probably.

I'd like you to substantiate the claim that it "gets slower at each release" before I'll accept it, it conflicts with my experience. I've seen every single GNOME application get consistently faster for the last five releases; today (with GNOME 3.20) they render at ludicrous speed on even my oldest intel boxes.

Personally, I prefer programming in Qt versus GTK. Also, I think GTK is losing developer's mind-share and Qt is moving forward faster, is targeting mobile platforms, is quite active, backed by a company, etc., etc. This kind of things are very important because some of us would like to make a living out of these things!

As someone who would like to create a commercial application for desktop, I really appreciate that at least the UI frameworks for Windows and OSX are quite stable.

Qt is better supported and easier to use compared to GTK. It's also probably the best cross-platform toolkit one can get right now.

Was surprised to hear that even Linus got sick of dealing with GTK and ported Subsurface to Qt, but that's how it is.

Contrary to what people seem to think, just because GTK+ compiles on Windows and OSX, doesn't mean we are trying to be a cross-platform toolkit. Many GTK+ developers consider GTK+ to be a platform in it's own right, not a portability layer.

I understand this, even though the constant breaking of GTK apps after each update annoys me to no end.

But you might want to discuss updating https://www.gtk.org/ and other sites for that matter. Quoting the first lines of the home page: "GTK+, or the GIMP Toolkit, is a multi-platform toolkit for creating graphical user interfaces".

Just a side note in case some representative happens to be around, the https link above delivers an invalid certificate.

And no content. I get a web server directory listing, with no entries.

The content only seems to be served via http.

If your platform is X11, Wayland, or Mir :)

And then you go to the Features page, with a box on the right clearly listing "GNU/Linux and Unix / Windows / Mac OS X" as supported plartforms :) With "Native look and feel" in the box just below.

I disagree with the current GTK direction, but it's not my project and I accept that. If the focus of the project has changed, update the website(s) and documentation.

Also the HTTPS stuff pointed out by distances.

Agreed. It seems wildly out of date. I'll track down who has access to the site and see if we can update it during the hackfest in a couple weeks.

Benjamin Otte recently added uxtheme.dll support to the CSS engine and I've already seen a few screenshots of the win32 theme using it to okay effect. I wrote a patch to add OS X cursor support to GDK last year and it was taken, not to mention work by Christian Hergert and others to improve the relatively new GDK/Quartz backend. So I'm pretty sure Windows and OS X are supported platforms :)

Linus didn't port Subsurface to Qt, other people who were already experienced with Qt did. If you have a look at their talk at linux.conf.au it's pretty obvious that they had no idea what they were doing when they wrote the GTK+ interface. I mean they weren't able to do a proper star rating widget in GTK+ and blame GTK+ for that. But doing that with Qt is just the same amount of work and they didn't even write that themselves, but the one responsible for the Qt port did. So what they are actually complaining about is: There was no one with a basic understanding of GTK+ who wrote the interface for us.

Yes, GTK+ has lots of quirks and I curse it on a regular basis, but so do Qt and all other toolkits I know of. And yes using Qt for Subsurface instead of GTK+ was a good idea, since Windows and OS X ports benefit a lot from that, but if Dirk and Linus were responsible for the Qt interface, it probably would have been just as bad as the GTK+ one.

I'm pretty sure the QT migration occurred after Linus stopped maintaining the project and handed the reins to Dirk Hohndel.

Qt simply works better. I saw GTK showing many artifact and/or working at glacial speed when buggy drivers or SVGA driver (not 2D acceleration) are in. However Qt works flawless on the same situation, even with some nice FX working.

Have a bug number? Link to the driver issues? I've worked on a lot of systems, including popular virtual machines display implementations (the most likely system to hit the SVGA mode) and have not seen this.

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).

GTK has the advantage of being a C library with not that many dependencies (so, simple to wrap.) QT (at least in my very limited experience) has way more dependencies, some weird build steps (MOC anyone?) and writing stubs for it would require much more code.

That said, I haven't programmed a UI in about 5 years, so this might be completely outdated.

It's not a new approach, though. SWT (for the JVM) and wxWidgets (C++, with bindings for more than a dozen languages) have been following it for years.

In my opinion, things such as Qt, WxWidgets, etc., which are implemented in C++ are from the time that C++ was supposed to be the breakthrough language. So these toolkits only targeted C++ in the same way that SWT was mostly thought for Java (although it may have been written in C or C++, I don't know).

This library seems to be implemented in C so that higher level languages can make use of it. C is much simpler to interface than C++. For instance, you mention WxWidgets, but that thing is so god-damn complex that there's still no stable WxPython for pyhton 3..

I really hope that this libui stays as just a simple simple thin wrapper so that we can build complex things no top of it in each language. For instance, python guys may create a declarative framework on top of this while lisp/haskell guys may create a Functional Reactive "thing" on top of it. As long as libui stays simple enough, everyone can extended it in ways that make sense for their own languages..

The library has a C interface, but the underlying implementation varies: Objective-C for Mac OS X, C++ for Windows, and C for Linux.

Actually SWT was one of the most pleasant experiences I've had coding GUI stuff. I always found it such a shame that it's only possible to use within the Java ecosystem. I really wanted an interface to the SWT binary libraries from other languages, I looked into it but it seemed intractable to port. If this library takes a similar approach it's probably doing something right.

SWT itself is written in Java. The native libraries are super-thin JNI wrappers for the underlying OS APIs.

I did a project last year where I wanted to use SWT, but I wanted to write the program in Python, and use CPython rather than Jython so I could have access to C extension modules like lxml. So I hacked up a solution using the Avian lightweight JVM and the pyjnius JNI-based Python/JVM bridge from the Kivy project. I should release that sometime.

The main difference is the License which is much more liberal in this case. Also binding C++ code requires wrapping the code trough a C interface which is really a pain; especially when considering the the underlying OS APIs have a C root.

I guess it's the proverbial "Simpsons did it" in which case, I don't care and I like to see people tinkering with ideas rather than just settling.

I think this is useful when you need simple dialogs. For example if you want to display a license agreement, or similar. It is overkill to bundle Qt libs to display simple dialogs.

But if you want a complex and powerful UI toolkit (let's say you want to create an editor), you need a toolkit like Qt. You can't do that with just wrappers to native toolkits. You will only get the greatest common divisor.

I don't know how far one can go with this approach, but if this project works, I believe one could built on top of it to create more powerful UI toolkits. The advantage would be that, unlike things such as Qt and GTK which draw their own widgets on top of (I think) a OpenGL "canvas", this one uses the platform native UI widgets.. Tl-dr: this approach is lighter and sanner because it leaves the "drawing" burden to the OS itself..

Had some troubles compiling on OSX Mavericks, but now that I've just tested it, it sure looks 100% native to me and perfectly integrates with the platform (file dialogs, osx font dialog, etc.) and much much better and lighter than Qt and other cross-platform tools I've been using so far.

I'm definitely going to try to implement a python wrapper around this as it seems usable enough as it is now.. :)

Started pylibui at https://github.com/joaoventura/pylibui. Pretty barebones for now, but hey, it shows a window!

What trouble?

I have to partially disagree. With stuff like webapps or Electron, we still have the same GUI on all platforms rather than using the native widgets. Also JavaFX is drawing it's widgets themselves, and I wouldn't call JavaFX 'old days'.

I've been professionally developing full stack web products for some years now, and as much as I like the web, it is indeed too cumbersome to implement complex things on it. For instance, my previous company just laid off some 4/5 developers mainly because the web app they were (re)building sucks big time..

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.