5 ms·

The main issue with UI on Linux is that toolkits have a higher churn than in Windows - this is because there isn't really "Gtk", "Qt" or whatever, but "Gtk2", "

The main issue with UI on Linux is that toolkits have a higher churn than in Windows - this is because there isn't really "Gtk", "Qt" or whatever, but "Gtk2", "Gtk3", "Gtk4", "Qt4", "Qt5", etc (and i'm sure that if i mentioned "Qt3" i'm sure someone would point out that nobody uses that anymore :-P). Writing something in Win32 will ensure it will run in 10 years from now and chances are it'll also run 20 years from now. As a user you have a very high chance of finding applications that work regardless of when they were made. As a developer you can focus on your tasks without wasting time to "upgrade" to the latest fad (Microsoft does release new toolkits, but the old stuff keep working and Win32 is the stablest of them all). And your knowledge will still be perfectly valid, no need to waste time learning how to do the exact same stuff in a different way. Writing something in Gtk3 (the current stable one) will ensure... well, once Gtk4 is stable, Gtk3 will be deprecated and the one to avoid. Qt can't even remain stable in the long term if they wanted (though they do not seem to want to - after all Qt is middleware targeted to application developers, not a platform component regardless if KDE pretends that it is) because of C++. As a user you are limited in the applications you can find and have to keep around all sorts of different toolkits - which wouldn't be that great of an issue (hard disk space is cheap) if those toolkits were still supported and compiled. Except the only distribution i'm aware that provides -say- Gtk1 is Slackware and Qt4 is already on its way out by most distributions. Gtk2 will soon follow (and perhaps some distributions will already have it dropped). As a developer you have to chase after the brokenness that Gtk and Qt developers introduce (though TBF Qt seems a bit better here, probably because they are getting paid by selling Qt licenses and they cant annoy the developers using Qt too much) and waste time "keeping up" just so that your existing application will keep working. Above X there aren't any stable UI APIs (unless you count Athena but that hasn't received any updates since the 80s - even the updates 3rd parties made during the 90s to improve its look a bit never became part of the "official" distribution). And people want to get rid of X's stability too with Wayland.

jcelerier 7y ago
> Qt can't even remain stable in the long term if they wanted (though they do not seem to want to - after all Qt is middleware targeted to application developers, not a platform component regardless if KDE pretends that it is) because of C++ https://www.qt.io/blog/2018/05/24/porting-from-qt-1-0 https://www.qt.io/blog/2018/05/24/porting-from-qt-1-0 > So, what did we learn? It did not take that much effort to port tutorial 14 from Qt 1.0 to Qt 5.11. It probably took me longer to write this blog post. Qt 1 was released in 1995, Qt 5 has been released in 2012 (and did not break ABI / API since then). I think it's not unreasonable to spend a few days every 7 years to update your app to the new Qt major version... especially when the hardware evolves and you have to update to follow that anyways (touch screens, hidpi, permission requesting).
- badsectoracula 7y ago
  This shows exactly what i mean (and i did note that Qt is at least better than Gtk here). An application written in 1995 against the Qt1 API will not work on Qt5 because both the API and the ABI has been broken. A user who wants to run such an application (not necessarily released in 1995, Qt1 was in use into the very early 2000s, even though Qt2 was already out) is not able to do so. A developer who wants to modify such an application has to become familiar with both Qt1 and Qt5. In contrast an application written in 1995 that uses Win32 will run out of the box in Windows 10 without any changes. A user can run such an application perfectly fine (and personally i have several applications like that that i'm using) and a developer who wants to work with the code will be able to focus on the application itself (since chances are he already learned Win32 at the past if he worked in any other Win32 program). As an example, some time ago Microsoft released the source code of File Manager which dates back to ~1990 - i was able to navigate that code easily and added the ability to filter a window's contents using multiple wildcards. (note that in both cases i am assuming the applications do not do anything stupid that happened to work at the time but doesn't work nowadays) An application may not even be maintained any more. Or it may be maintained but the user(s) might dislike the changes (e.g. i like Paint Shop Pro 7, released in 2000, but i never liked the UI overhaul that PSP8 got and nowadays after Corel bought the software they have severely... well... gimped it :-P - similarly i do not like the changes introduced in Blender 2.8 so i stick with 2.79 and i know a very talented artist who still uses Photoshop 5 - not CS5, plain 5). Those few days are also very optimistic and really depend a lot on the software in question. AFAIK Lazarus, for example, took ages to update form Qt4 to Qt5 (same story, but much worse due to all the breakage Gtk introduced, with Gtk3 which still isn't really usable). And as i wrote above, most of the time, they are a waste of time. Adding support for touch screens and hidpi (not sure what you have in mind with permission requesting, so i ignore that) doesn't require breaking your API nor your ABI. EDIT: BTW, it isn't impossible to have Windows-like backwards compatibility on Linux, here is a screenshot[0] from a toolkit i used to work on at the past showing the same binary working in both 32bit Red Hat from 1997 and 64bit Debian from 2017 - essentially 20 years of backwards binary compatibility (the colors are off because i didn't bother to implement indexed color support). It is just that the toolkit maintainers do not care, but it is perfectly possible to do that if you care. [0] https://i.imgur.com/YxGNB7h.png https://i.imgur.com/YxGNB7h.png
jfkebwjsbx 7y ago
> Writing something in Win32 will ensure it will run in 10 years from now and chances are it'll also run 20 years from now. This, so much. And they will likely work on Linux and macOS through Wine, too!
- badsectoracula 7y ago
  Yeah, it is kinda amusing that one of the stablest ABIs for GUI applications on Linux is the Windows one :-P. Sadly the Wine GUI controls, while they work, always felt off to me and have multiple minor issues. But at least they work. I think a big reason is that despite libwine being usable as a general purpose toolkit for (ELF) Linux application, it never saw much use as that so these issues were never paid much attention.
  - jfkebwjsbx 7y ago
    Indeed, the Wine controls could use some help. It would be great if someone could provide a new renderer based on Vulkan, for instance.
    - badsectoracula 7y ago
      Vulkan would make things more complicated and wont really fix anything (if anything it'll make things worse because that added complication will make it harder to fix things and most likely will break compatibility with anything not supporting Vulkan - e.g. older and/or weaker devices and other OSes like macOS) since it isn't really rendering that is the issue but behavior (there are also some drawing issues but those are at the GDI level and you do not want to break GDI).
      - jfkebwjsbx 7y ago
        Ah! I was referring to the graphical issues. Behavior is more important, of course. By the way, Vulkan is "supported" on macOS thorough MoltenVK which is provided by Khronos under a permissive license (although they don't develop it).
deleted 7y ago
[deleted]
dylan-m 7y ago
To be fair, that churn also means the system you get when you install Fedora Workstation or Ubuntu is almost entirely Gtk3 or something built with Gtk3 in mind. You don't get this weird combobulation of utilities built with different UI toolkits with different kinds of scrollbars (and different levels of support for high dpi, touch screens and scroll events) because the old stuff "works" and we lost the event viewer source code ten years ago. I guess the other chunk of this is the development model seems to prevent that sort of fragmentation within these larger products. The broader app ecosystem is a separate story, and I realize that's most of what you're bothered by, but having that core system be consistently modern is a big thing on its own. And to get there it seems like you kind of have to sacrifice one for the other.
- badsectoracula 7y ago
  But that isn't very helpful nor really that useful. Computers aren't single purpose appliances (even if some people treat them like that but even in that case, they tend to have different opinion about what sort of appliances they are). Ubuntu (and i guess Fedora) out of the box isn't that useful and the moment you install anything that wasn't made with, say, Gtk3 in mind things start to crack. Actually i think in Ubuntu you do not even need to install anything, just open the web browser and things start to not mesh that nicely. And IMO if anything, the reason you get all those different behaviors is exactly because things break. If Gtk3 was backwards compatible with Gtk2 (in a fantasy world where the Gtk developers did learn from the mistakes of Gtk1 to Gtk2 breakage and designed their Gtk2 APIs to avoid it in the future) then all Gtk2 applications would gain, if not all, then at least some of the new functionality in Gtk3. Programs that were abandoned would still get some of the new stuff while programs that are under development would be able to keep using whatever they are using and upgrade in their own pace only the minor differences that were needed for the new functionality.
int_19h 7y ago
Writing something in Gtk3 can break even in minor releases, apparently. I remember there was an update that broke a lot of themes, and apps that did custom theming for their own purposes.

jcelerier 7y ago

> Qt can't even remain stable in the long term if they wanted (though they do not seem to want to - after all Qt is middleware targeted to application developers, not a platform component regardless if KDE pretends that it is) because of C++ https://www.qt.io/blog/2018/05/24/porting-from-qt-1-0 https://www.qt.io/blog/2018/05/24/porting-from-qt-1-0 > So, what did we learn? It did not take that much effort to port tutorial 14 from Qt 1.0 to Qt 5.11. It probably took me longer to write this blog post. Qt 1 was released in 1995, Qt 5 has been released in 2012 (and did not break ABI / API since then). I think it's not unreasonable to spend a few days every 7 years to update your app to the new Qt major version... especially when the hardware evolves and you have to update to follow that anyways (touch screens, hidpi, permission requesting).

badsectoracula 7y ago
This shows exactly what i mean (and i did note that Qt is at least better than Gtk here). An application written in 1995 against the Qt1 API will not work on Qt5 because both the API and the ABI has been broken. A user who wants to run such an application (not necessarily released in 1995, Qt1 was in use into the very early 2000s, even though Qt2 was already out) is not able to do so. A developer who wants to modify such an application has to become familiar with both Qt1 and Qt5. In contrast an application written in 1995 that uses Win32 will run out of the box in Windows 10 without any changes. A user can run such an application perfectly fine (and personally i have several applications like that that i'm using) and a developer who wants to work with the code will be able to focus on the application itself (since chances are he already learned Win32 at the past if he worked in any other Win32 program). As an example, some time ago Microsoft released the source code of File Manager which dates back to ~1990 - i was able to navigate that code easily and added the ability to filter a window's contents using multiple wildcards. (note that in both cases i am assuming the applications do not do anything stupid that happened to work at the time but doesn't work nowadays) An application may not even be maintained any more. Or it may be maintained but the user(s) might dislike the changes (e.g. i like Paint Shop Pro 7, released in 2000, but i never liked the UI overhaul that PSP8 got and nowadays after Corel bought the software they have severely... well... gimped it :-P - similarly i do not like the changes introduced in Blender 2.8 so i stick with 2.79 and i know a very talented artist who still uses Photoshop 5 - not CS5, plain 5). Those few days are also very optimistic and really depend a lot on the software in question. AFAIK Lazarus, for example, took ages to update form Qt4 to Qt5 (same story, but much worse due to all the breakage Gtk introduced, with Gtk3 which still isn't really usable). And as i wrote above, most of the time, they are a waste of time. Adding support for touch screens and hidpi (not sure what you have in mind with permission requesting, so i ignore that) doesn't require breaking your API nor your ABI. EDIT: BTW, it isn't impossible to have Windows-like backwards compatibility on Linux, here is a screenshot[0] from a toolkit i used to work on at the past showing the same binary working in both 32bit Red Hat from 1997 and 64bit Debian from 2017 - essentially 20 years of backwards binary compatibility (the colors are off because i didn't bother to implement indexed color support). It is just that the toolkit maintainers do not care, but it is perfectly possible to do that if you care. [0] https://i.imgur.com/YxGNB7h.png https://i.imgur.com/YxGNB7h.png

jfkebwjsbx 7y ago

> Writing something in Win32 will ensure it will run in 10 years from now and chances are it'll also run 20 years from now. This, so much. And they will likely work on Linux and macOS through Wine, too!

badsectoracula 7y ago
Yeah, it is kinda amusing that one of the stablest ABIs for GUI applications on Linux is the Windows one :-P. Sadly the Wine GUI controls, while they work, always felt off to me and have multiple minor issues. But at least they work. I think a big reason is that despite libwine being usable as a general purpose toolkit for (ELF) Linux application, it never saw much use as that so these issues were never paid much attention.
- jfkebwjsbx 7y ago
  Indeed, the Wine controls could use some help. It would be great if someone could provide a new renderer based on Vulkan, for instance.
  - badsectoracula 7y ago
    Vulkan would make things more complicated and wont really fix anything (if anything it'll make things worse because that added complication will make it harder to fix things and most likely will break compatibility with anything not supporting Vulkan - e.g. older and/or weaker devices and other OSes like macOS) since it isn't really rendering that is the issue but behavior (there are also some drawing issues but those are at the GDI level and you do not want to break GDI).
    - jfkebwjsbx 7y ago
      Ah! I was referring to the graphical issues. Behavior is more important, of course. By the way, Vulkan is "supported" on macOS thorough MoltenVK which is provided by Khronos under a permissive license (although they don't develop it).

deleted 7y ago

[deleted]

dylan-m 7y ago

To be fair, that churn also means the system you get when you install Fedora Workstation or Ubuntu is almost entirely Gtk3 or something built with Gtk3 in mind. You don't get this weird combobulation of utilities built with different UI toolkits with different kinds of scrollbars (and different levels of support for high dpi, touch screens and scroll events) because the old stuff "works" and we lost the event viewer source code ten years ago. I guess the other chunk of this is the development model seems to prevent that sort of fragmentation within these larger products. The broader app ecosystem is a separate story, and I realize that's most of what you're bothered by, but having that core system be consistently modern is a big thing on its own. And to get there it seems like you kind of have to sacrifice one for the other.

badsectoracula 7y ago
But that isn't very helpful nor really that useful. Computers aren't single purpose appliances (even if some people treat them like that but even in that case, they tend to have different opinion about what sort of appliances they are). Ubuntu (and i guess Fedora) out of the box isn't that useful and the moment you install anything that wasn't made with, say, Gtk3 in mind things start to crack. Actually i think in Ubuntu you do not even need to install anything, just open the web browser and things start to not mesh that nicely. And IMO if anything, the reason you get all those different behaviors is exactly because things break. If Gtk3 was backwards compatible with Gtk2 (in a fantasy world where the Gtk developers did learn from the mistakes of Gtk1 to Gtk2 breakage and designed their Gtk2 APIs to avoid it in the future) then all Gtk2 applications would gain, if not all, then at least some of the new functionality in Gtk3. Programs that were abandoned would still get some of the new stuff while programs that are under development would be able to keep using whatever they are using and upgrade in their own pace only the minor differences that were needed for the new functionality.

int_19h 7y ago

Writing something in Gtk3 can break even in minor releases, apparently. I remember there was an update that broke a lot of themes, and apps that did custom theming for their own purposes.