Applications written using the original Win32 API are binary and source compatible with the current version of the API. Why does GTK keep breaking backward compatibility?
I understand breaking backwards compatibility a first time, maybe out of a failure to plan ahead, but not multiple times.
It would be easy enough to add new subroutines to add more functionality. Is there a reason to change or remove old subroutines of which I’m not aware? Otherwise this is just causing extra work for application developers for no good reason and in many cases killing old stable applications which are no longer developed.
Because the GTK developers do not care about backwards compatibility. There isn't really any other reason, as you wrote the Win32 API is backwards compatible as are the X11 libraries and a few other toolkits - perhaps the most stable is Motif, which goes back to the early 90s.
Of course they do not have to care about backwards compatibility since GTK is just a library that happens to be popular enough to be widely available but not really part of any platform. The OS itself (Linux) is binary compatible going back decades.
It is a bit frustrating though, but really if you want a stable GUI API either write against pure xlib or use something like Motif which even though it barely gets any updates probably wont go away any time soon as it is used in several long standing scientific and enterprise applications (ie. the unsexy stuff you rarely hear about but still work behind the scenes).
It might be interesting to see what it'd take to make Motif a bit more themeable though.
The GTK developers do care about backwards compatibility, as evidenced by their continued maintenance of GTK3.
Jumping to pure Xlib or Motif is a bit beside the point, to that end you might as well use GTK1 or GTK2 if you don't mind using an old stable API that is not really being updated anymore.
> The GTK developers do care about backwards compatibility, as evidenced by their continued maintenance of GTK3.
That sort of "backwards compatibility" is useless in the long run and a big source of waste of time for the developers who rely on their library - see XFCE or even Gimp as examples of projects wasting tons of time just to do the same stuff just with a different API.
In addition it isn't what the thread is about which should have been obvious from the Win32 as an example. When you use Win32 you get the latest fixes and features even in applications that haven't been updated for two decades - for example you get new common dialogs and access to shell extensions (e.g. TortoiseSvn/Git integration) that didn't exist back when those applications were made.
Backwards compatibility isn't just about keeping the old stuff running as they were back when they were released - that is just the absolute minimum. It is also about adding new features and fixing bugs that all applications - both old and new - can benefit whenever possible.
> Jumping to pure Xlib or Motif is a bit beside the point, to that end you might as well use GTK1 or GTK2 if you don't mind using an old stable API that is not really being updated anymore.
Xlib and Motif are not equivalent to GTK1 and GTK2 since they do receive updates and bugfixes, even if they rarely receive new features (though both do receive new features too).
> When you use Win32 you get the latest fixes and features even in applications that haven't been updated for two decades - for example you get new common dialogs and access to shell extensions (e.g. TortoiseSvn/Git integration) that didn't exist back when those applications were made.
What you're describing is not backward compatibility, it's forward compatibility.
The OS is backward compatible with old applications that continue to run. The old applications are forward compatible with newer versions of the operating system including some of the new features that are added.
Achieving backward and forward compatibility (the combination is often called "full compatibility") is actually quite difficult. The resources Microsoft throws at this problem and the related coordination costs are massive (and conversely, the progress any individual developer sees on their particular tasks is often glacial)[0]. In the open source world, I think only web browsers typically see anything resembling a similar level of effort applied to evolving the platform while maintaining compatibility with extant (and often buggy) code, and that's still a much smaller problem (though it might not be after another decade or two), since for all intents and purposes, the web as a whole is a "rolling release" system with bugs and incompatibilities popping up and being fixed constantly.
That's understandable, especially as the effort to make old apps forward compatible isn't being made by the application developer here, but by the platform developer.
Conversely, Microsoft is rather notorious for not making many of its own offerings forward compatible with themselves. For example, old versions of Office cannot open or edit files saved by newer versions. And while new versions of Office will open older format files, they then save the file in the new version of the format by default. This one-way ratchet "strongly encourages" upgrades in lockstep.
I'm not sure what you mean waste of time. If they weighed the cost of doing a port versus the cost of staying on GTK1 or GTK2 and backporting things, and they chose the port, it seems like according to them that would be the least time-wasting option.
I get what you're saying, but asking "why doesn't my old API get new features" is a different thing than asking for backwards compatibility because that entails actually modifying the old applications to support new API features, not just maintaining compatibility with them. If someone really wants to step up and backport features to GTK2, that's always possible, you don't need to wait for the GTK4 developers to figure it out.
The problem is that Gtk has removed features, so old Gtk-using programs no longer even compile. If we could write a program using only old Gtk APIs and it would still work on new Gtk then it would be fine, excepting the obvious point that the programs would not be able to use newer features/widgets, but for many programs that would be a fine trade-off if it was available.
The entire point of a new version is that it has newer features/widgets. Why even bother using a new GTK version if you didn't care about using the new features/widgets? In that case you could still compile against the old version and expect it to work as it always has.
If what you're looking for is a way to roll out some new widgets one by one and transition to a new version slowly, I agree that's something that could be worked on. But it requires a bunch of additional work that's mostly orthogonal to just shipping a new toolkit and it may not make sense for it to happen upstream.
> I'm not sure what you mean waste of time. If they weighed the cost of doing a port versus the cost of staying on GTK1 or GTK2 and backporting things, and they chose the port, it seems like according to them that would be the least time-wasting option.
If GTK3's API was backwards compatible (both in binary and source form) with GTK2's API then the developers of all the applications that relied on GTK2 wouldn't have to spend any time changing their applications to work with GTK3 nor make any "weighting" between doing these changes or staying on a library that wont receive any further updates and features after a while. And in practice this isn't really much of a choice unless the GTK developers also committed to updating, fixing and improving (ie. adding new features) to the previous library - at which point why bother with the new version at all?
This is a waste of time because the developers of those applications could have spend their (often limited, since they're not paid to make those applications and instead make them in their free time) development time on fixing bugs and adding features to these applications that directly benefit the end users instead of trying to catch up with whatever stuff GTK3 broke (and now will be broken again in GTK4).
> I get what you're saying, but asking "why doesn't my old API get new features" is a different thing than asking for backwards compatibility because that entails actually modifying the old applications to support new API features, not just maintaining compatibility with them.
No, this is exactly backwards compatibility in the best way: the old applications get new features without even having to recompile them. This is how it works, e.g. in Win32 where as i wrote above you get new features in applications that were compiled 20+ years ago.
You only need to modify existing applications so that they can use new features when it makes sense for those new features to be requested by the application. But, for example, you do not need to modify existing GTK2 applications to add Wayland support in GTK2, or to improve the a common dialog like the file picker, or to add an emoji picker in text editing areas (which, btw, is also a feature that Windows applications got in Windows 10 which works even in applications compiled many years ago before emoji was a thing outside Japan), or a bunch of other stuff.
What you describe would only be an issue if someone statically linked against GTK but the overwhelmingly vast majority of applications link against GTK dynamically and on Linux they all pretty much use the distribution's libraries instead of bundling their own.
> If someone really wants to step up and backport features to GTK2, that's always possible, you don't need to wait for the GTK4 developers to figure it out.
Yes, of course anyone could improve GTK1, GTK2, etc but what is being discussed here isn't if it is technically possible to improve these libraries without breaking backwards compatibility (it obviously is) but about what the (official) developers of these libraries are actually doing with regards to backwards compatibility.
I'm not going to argue about semantics but I want to be clear here: the basic definition of "backwards compatibility" is keeping the old thing working. Adding new features is often at odds with this because it can break things in subtle ways. You might be able to make some small backend changes, bringing back some of the major breaking changes to widgets or to the rendering model is out of the question.
If someone really wants to backport things like wayland support or emojis to GTK2, or make a shim layer to support all the old GTK2 APIs in GTK3, you could probably get people on board to take those patches somewhere. I know adding wayland support would not be simple and would probably break things as there are a lot of things in GDK2 that were direct mappings onto X11 APIs that have no analog in wayland. As the backports pile up you would have to weigh the cost of doing that versus just porting the application and getting the additional benefits of porting to a newer version. It would only be a total waste of time if there were no benefits to porting, but this is not the case.
I just doubt any of the GTK4 developers are going to want to drop what they're working on now to do these things given the risk it carries combined with the fact that there are workarounds for these missing features.
> I'm not going to argue about semantics but I want to be clear here: the basic definition of "backwards compatibility" is keeping the old thing working.
As i wrote a few messages above, that is the absolute minimum to call "backwards compatibility" so i'm not sure why you need to be clear since we agree on that part
> Adding new features is often at odds with this because it can break things in subtle ways.
You take that into consideration when you decide to add new features, it isn't like features come as demands from the gods in what and how to implement. And if you break things in subtle ways, you can fix them down the road if that is a problem - it isn't like broken code has to remain broken.
> You might be able to make some small backend changes, bringing back some of the major breaking changes to widgets or to the rendering model is out of the question.
The idea is to not make breaking changes to widgets in the first place. And changing the rendering model should also happen in a way that doesn't break the existing code (e.g. add a compatibility layer for custom widgets that use the previous rendering model and either make any customized widgets -e.g. buttons- to detect that they are customized and use the older rendering model in that case so they remain compatible but the new rendering model for newer code or create new widgets that use the new rendering model with an API that is as drop-in as possible so that 99% of the changes can be a search and replace in codebases).
Yes, that makes things harder than simply ignoring backwards compatibility and expecting every single application that uses your library to change their own code and break any applications that cannot update to the new APIs/ABIs, but that is the price for doing backwards compatibility properly.
Of course that is too late now for GTK and as i wrote previously (and later), the developers do not care about backwards compatibility anyway so i do not expect them to do anything about that when GTK5 comes around and instead they'd just expect everyone to waste time changing their working GTK4 code to use GTK5.
> If someone really wants to backport things like wayland support or emojis to GTK2, or [...] this is not the case.
You are missing the point, my message wasn't about what could or not be done by 3rd parties to improve GTK2 or whatever, but about what GTK developers themselves decided to do. What someone else would do is absolutely irrelevant to the topic.
> I just doubt any of the GTK4 developers are going to want to drop what they're working on now to do these things given the risk it carries combined with the fact that there are workarounds for these missing features.
I do not expect that to happen either, after all my first message in this submission even began with "Because the GTK developers do not care about backwards compatibility."
I agree a compatibility layer for the rendering model could be useful but that is a separate and optional thing that someone has to write, probably someone with more of an active financial interest in old GTK versions than the GTK4 developers have. Their priority with the old versions is mostly to keep them working as-is, specifically to reduce the chance that things will break in subtle ways and then will need to be fixed later, because those issues can be hard to track down and can really harm backwards compatibility. If such a compatibility layer existed, it would not be something that needs to be part of GTK4 or hold up a GTK4 release in order for GTK2/3 applications to make use of it. It would really not have been possible to even make this kind of compatibility layer before GTK4 was stabilized.
The GTK developers are just ordinary people like you or I who volunteered to work on it, if you want to change this situation then you or someone else can step up and become a GTK developer and work on this. Then you can say they care about it :) I think it is incorrect to say they don't care about backwards compatibility anyway, you seem to agree that they would meet that minimum required to claim backwards compatibility.
This is entire thread is a criticism of the GTK developers process and their decision to not invest in backwards compatibility time and time again. It’s not about what is or isn’t technically possible. (Btw it’s technically possible to innovate, have clean code, and maintain backwards compatibility without an unreasonable amount of effort.)
The GTk developers aren’t ordinary people. They comprise an organization of trusted individuals and leaders. Not to mention, Many of them are employees are large companies like Red Hat and Canonical. They have resources. The likelihood of a random strangers contributions being upstreamed are low, let alone them setting project direction around backwards compatibility.
Hundreds if not thousands of apps have been left behind in GTK2 and GTK1 before that. Those are all apps that could be part of the current GNOME ecosystem, now they will look like bad foreign apps. Tens of thousands of man hours completely wasted.
This will kill the GNOME desktop. It’s a dead end for anyone but GNOME developers. Everyone sees it. GTK4 is just the latest demonstration of their incompetence and disregard for other developers.
>This will kill the GNOME desktop. It’s a dead end for anyone but GNOME developers. Everyone sees it. GTK4 is just the latest demonstration of their incompetence and disregard for other developers.
Please don't use this type of hyperbole, I've heard this type of thing often in various contexts, and while it may be fun to say, it's inaccurate and it's thoroughly unproductive in getting the actual issues solved. What you view as incompetence and disregard is more accurately described as "lack of time." IIRC there are only really 2-3 people working full time on GTK, and most of their efforts are focused on getting new releases out the door. It's not as many resources as it may seem from the outside and they don't have time to do everything that people want. They depend on volunteer contributors to handle the long tail of issues and edge cases that come up with older applications.
If you'd like to improve GTK2 and GTK1 applications, please find a way to contribute and help out! I can help to point you in a direction if you want. (I don't think it's really much of a big deal if older applications look weird, the main concern with them is usually that they don't break. From this angle, GTK1 and GTK2 apps are not being left behind, they work perfectly fine even on a modern system) I'll warn you though, it's not trivial to get a legacy app to look and act native on a modern platform. If you really want to do a good job at it, you have to manually redesign each of the apps individually and it gets time-consuming.
I personally think it would be great if XFCE/Mate/Budgie/Cinnamon/etc had the resources to pay more full time developers to contribute upstream and collaborate more with the GNOME people, but we are not there yet unfortunately.
That doesn't mean it doesn't work. The package was removed because it wasn't getting security updates, however I see no reason why it wouldn't work if you gather all the dependencies and recompile it.
Sorry but you are completely missing the point, you are talking about how things could be if GTK4 did what they already have and i'm talking about how things could be if GTK took compatibility seriously way before even GTK3 began development.
Again, this isn't about what can be technically possible. As the other poster wrote, it is a criticism towards the decisions of the GTK developers. That someone else could take the code and change it, is completely, absolutely, 100% irrelevant. It has nothing to do with the comments here, they aren't about if it is technically possible to add a compatibility layer on GTK3 or GTK4 or whatever nor who will make it.
It is ALL about the GTK development team's decisions, including the decisions that make a backwards compatibility harder.
Also caring about backwards compatibility isn't something that can be bolted on top by a 3rd party, it is something the library has to keep in mind in the design phase. And it isn't something that can be thought as a separate component, it is something that has to be at the same level as everything else. Expecting that it is something that "shouldn't hold up a GTK release" is a completely wrong way of thinking about backwards compatibility - a project that cares about being backwards compatible considers it as important as any other change (new features, bug fixes, etc) and not something to be an afterthought.
> The GTK developers are just ordinary people like you or I who volunteered to work on it, if you want to change this situation then you or someone else can step up and become a GTK developer and work on this. Then you can say they care about it :)
Sure, they may be (i do not know) and they have all the rights to ignore backwards compatibility - it isn't like i'm paying them to work on their library or be in a position to make any demands out of them. But that doesn't mean i wont say they do not care about backwards compatibility.
> I think it is incorrect to say they don't care about backwards compatibility anyway,
It is absolutely correct because this is what they have repeatedly shown.
> you seem to agree that they would meet that minimum required to claim backwards compatibility.
No, i do agree with that, what i agreed with is the definition that keeping code running is the absolute minimum one would do to provide backwards compatibility, but i never claimed that the GTK developers care about it. These are two different things: one can not care about backwards compatibility, yet still provide that minimum amount for it for practical and strategic reasons to entice people move to the next version.
Sorry I still don't see the point. We could speculate how things could have turned out differently if they made different decisions 20 years ago, but that would just be it: speculation. If you have some better way to design it that you think could preserve perfect backwards compatibility while allowing the same pace of feature development, you should let them know. Because AFAIK both of those are at odds, no developer can realistically spend time on both for an indefinite period of time, and if there are no new features that anyone wants then backwards compatibility is irrelevant anyway.
>Expecting that it is something that "shouldn't hold up a GTK release" is a completely wrong way of thinking about backwards compatibility
Why? Once you decide to refactor an API you have to maintain an extra piece to translate the old to the new, there is no way around that. Developers can spend time before the release working on this translation piece alongside the new features or they can just release it now so people can test the new API before deciding to invest in developing that. For an open source project I can't see how the first option really makes sense, and if your argument is that they should have been developing it the whole time, that is essentially what they were doing for the entirety of the GTK3 development cycle.
That is being generous in assuming that it's even possible to do this, sometimes a design is so flawed that you can't even make it work at all with the new stuff. At some point you have decide to cut deprecated APIs or you are left with an infinitely growing pile of technical debt. I referred to this elsewhere, but old GTK1/2 applications that use raw unscaled pixel buffers are an example: there is no backwards compatibility that is going to work here that makes them function correctly with high dpi. It simply cannot work if the application is hardcoded to use an old API that has no concept of dpi or scale and assumes a pixel is always the same size. (Maybe someone can cheat with AI upscaling algorithms but those are usually pretty slow :)
I guess to put it another way: I don't see any way that GTK4 could have been designed differently to do something like make it easier to compile GTK1 apps against it while reaping all the benefits of GTK4. If somebody wants to make a GTK1 shim for GTK4 that translates GTK1 API calls into GTK4 API calls, they can go do it now, it would probably be a pain and it's probably not going to magically get you all the new benefits that would come from just porting the application to GTK4 and refactoring to use its new techniques along the way.
GTK is not like Win32. Think GTK2 ~= WinForms, GTK3 ~= WPF, GTK4 ~= UWP. The "versions" are parallel installable, you don't have to migrate every app to the newest toolkit ASAP. But unlike with Windows, old versions do get phased out and abandoned, because there's no super-rich corporate force sponsoring their perpetual maintenance.
If GTK is operating in a situation where there is no “rich corporate force” to sponsor the maintenance of old versions then it is a strategic error for them to break backwards compatibility.
At this point I cannot imagine a sane third party application developer choosing to build on top of GTK. The clock starts ticking on the life of your application the moment you choose GTK.
The alternative would be never refactoring anything and allowing technical debt and complexity to balloon out of control, which would also be a strategic error for a small project without many resources.
The ticking clock you're referring to is real, but it applies to any open source library you're depending on that you aren't contributing anything to, not just GTK. It can't be avoided just by switching to another open source toolkit. If it really bothers you, start contributing and help out!
Contributing to each dependency you use is not realistic. What instead happens is that people leave GTK for more stable dependencies. This is what I did. That's what many likely choose to do.
Jumping from dependency to dependency forever hoping that someone else is always going to do the right thing is not a viable option long term, even moreso if you want to build a large application that lasts a while.
Realistically, most people who decide to ditch GTK seem to switch to Qt and either start contributing there or pay for consulting/LTS/commercial licenses eventually, because that is the only comparably modern option for native widgets on Linux/BSD.
Moving from one toolkit to another is an expensive and tedious process. Speaking from experience, those who need to do it tend to do it once and they do their homework to make sure that the toolkit they choose has a sane API development process.
So yes, jumping from dependency to dependency is not a viable option long term. Luckily you only need to jump away from GTK once.
You also only need to jump away from Qt once, if that doesn't work for you for whatever reason. If the toolkit is open source, and your "homework" doesn't include looking into the contribution process and how it goes working with upstream, then I would say you are doing yourself a disservice considering how this is the most critical dependency that a GUI application has. That gets more important the more your project gets invested in the toolkit, doubly so if you aren't paying for support. (Essentially that means you're supporting it yourself or relying on flaky advice from IRC and stack overflow, all the usual caveats apply there. Ignoring upstream and refusing to talk to them or collaborate is really not going to help you in that case)
Of course, but that "homework" would also include considering the incentives and goals of the authors behind the toolkit. If we took the authors of Qt as an example, their incentives and goals are clear. If they needlessly break their API, they will loose their customers and go bankrupt. These incentives have translated in one of the most smoothest major GUI toolkit transitions I've seen (Qt4 to Qt5).
As far as contribution processes go, both upstreams are equally tedious to work with. I doubt GTK would be willing to accept your code contribution if you added systray icons support back to GTK4 for example. So while the contribution process does matter, it doesn't matter as much as you make it out to be.
I don't think Qt4 to Qt5 is a fair comparison. The really substantial changes here are getting closer to what you would have to do to port an application from Qt Widgets to QML/QtQuick, although not quite as drastic. (The whole scene graph design has changed, but you don't need to change all of your widgets to use it effectively, only some of them) The incentive here is the same: Make a modern and flexible toolkit that works for a wide range of applications. If something is deprecated and removed with no replacement or migration plan, it's the same thing there too: customers didn't see enough of a need to pay for it to happen.
AFAIK the systray icon support in GTK was removed because nobody was willing to maintain it. I don't think that's a great example because it doesn't even need to be in GTK anyway, it relies entirely on platform-specific functionality and has little to do with the toolkit. Someone can just make a library for that. (And I think Ubuntu did, but it was not upstreamed for a few reasons, one of them being that it didn't support multiple platforms) Regardless, that is the point I was getting at. The upstream policy is really not that different between these projects, you can't avoid it just by jumping ship.
Maybe it was a mistake to keep using the GTK name. The overhaul between major versions, at least between 2 and 3, was large enough to warrant a new name.
Microsoft has introduced just as many new toolkits during the same time, but nobody expects WinForms to be backwards compatible with MFC.
That would have given application developers a better chance to keep maintaining the toolkit long after GTK developers lost interest.
Okay so if each GTK version exposes a fundamentally different toolkit framework (similar to the differences between win32/mfc/winforms/uwp) why do they expect application developers to “upgrade”? These should be lateral changes as you suggest and upgrading would be meaningless. Just like it’s meaningless to “upgrade” an MFC app to a winforms app.
They don't expect. But usually some Gnome devs are GTK devs, so usually the whole things happens for a reason, and that reason is to have better APIs to be able to write better desktop applications.
GTK3 became "final" in 2016 with 3.22. That was when GTK4 development started. And many applications just started to be ported to 3. Then 3.24 as a maintenance release came out in 2018. And in almost exactly 4 years 4.0 is ready for general availability, but it's likely far from "final" and stable.
So GTK3 continues to be maintained for a good while. (Though GTK2 is now EOL.)
They break backwards compatibility because there's not really much reason for them not to. The new releases have a lot of refactoring and redesigns that would break things anyway. The old ways are considered deprecated and keeping them around forever complicates the code and has about the same cost as backporting things to an old version.
If it's too much work for application developers, the can keep on an old version of the library or maintain a shim. (There are still a lot of GTK2 applications out there, although distros seem to be removing them because nobody is interested in maintaining a shim or backporting things)
It's a big pain in the neck. This is the nonsense we have to go through to keep virt-p2v working on various old Linux systems (required in itself because those old systems support various obsolete/closed source hardware):
I guess I'm confused. The first one looks like backporting of newer functions to get it to work on older GTK versions. The second one looks like shims to work around not wanting to link against deprecated symbols. What could upstream possibly do there? In both cases, the issue seems to be the configuration of the target machine.
We have to make it compile on RHEL 5 and RHEL 6¹ because some obscure SCSI drivers only work on those platforms, and you need those if you're going to virtualize the hardware (P2V). You can't just use modern Gtk on those platforms partly because it doesn't compile and partly because carrying the whole "G stack²" on those distros for a 3 dialog wizard would be a nightmare.
¹ 2007 and 2010 respectively, not sure off the top of my head what versions of Gtk those have, but old.
² It's not just Gtk, but glib and dozens of other libraries.
Right, so how are any upstream changes in GTK3/4 going to help with keeping the application running on GTK 2.10? I don't know what else you could there besides ship a shim.
At that point ... why not drop RHEL5/6 support? Or, if p2v works on them already, why can't you have a rhel-5/6 branch and only touch it if somebody gives you a pot of 24 Karat gold?
One of the main reasons we abandoned Pinta (https://github.com/PintaProject/Pinta) is we had to rewrite a significant portion of the app if we wanted to move to GTK3, as we had many custom UI needs.
See also:
GIMP, still on GTK2.
Inkscape released on GTK3 just within the past year or 2
The lifecycle is at its worst at this very moment and is about 10 years (the last moment you could have made a GTK 2 app before 3 released).
The price of backwards compatibility is keeping backward design. Microsoft stated a few times that they couldn't keep the exact interfaces of Win32 without leaving security problems inherent in the mis-design of original interfaces. I have no idea if they intentionally broke the interfaces, but Wine is sometimes more compatible with old win32 than windows.
In my experience Wine is more compatible when it comes to older games (especially those abusing the APIs), but when it comes to older (and newer) GUI applications it has a lot of issues.
And for older games there are often alternatives in Windows (e.g. dgVoodoo2 which reimplements older DirectX and Glide versions under Direct3D 11 and i think nowadays 12) that provide even better compatibility and features.
You are comparing a runtime API (Win32/Xorg) with a compile-time library (GTK). They are totally different. It's totally fine for a library to have new versions, and for those new versions to be breaking.
You can run two applications with GTK3 and GTK4, and maybe 10 years into the future GTK10 in parallel. They will just look different, but nothing else will change. It's not as if the old application built with GTK3 will crash or not start.
But if you break the Win32 API, a whole lot of desktop applications will crash.
If GTK were simply a so-called compile-time library, they wouldn’t encourage people to port their applications to the newest version. Applications are not expected to vendor private versions of GTK with their source distributions.
Make a thought experiment and imagine that each new major GTK (or Qt) version had a different name. You'd still have old GTK, which wouldn't be maintained anymore as the devs moved on, and new NTK or whatever, which would be what was still developed and used these days. Somewhat similar to old GTK since that was its roots, yet distinct.
And that's exactly what happens, they just reuse the name because well, why wouldn't they. You can still use GTK2 just like you can use Win32 API, but nobody does modern apps in either GTK2 or Win32 API or expects them to smoothly blend into modern desktop these days.
Not even speaking about the fact that The GIMP is a very special case that makes it probably the hardest GTK app to port to newer versions in existence.
Even if GTK2 were to get hidpi support, it would still require making the same types of changes in the applications to support them that would be required to port it to GTK3 and get hidpi there anyway. Only the most trivial applications without any custom drawing/widgets would have hidpi working without any changes. Rule of thumb, if the app's code uses raw pixel units anywhere, that would need to be modified to account for scale. You would probably need to modify all the GTK2 theme engines too.
My 20 year old projects run perfectly on Linux with WINE
Now there is Lazarus to port Delphi code to a native Linux version, but it is using GTK2 and that is running much worse. (or through qt4 but that is even worse) The good thing is, if Lazarus gets a GTK3/4 update, my old code is supposed to run on the new GTK unchanged. The bad thing is, Lazarus is not popular so hardly anyone is working on those updates.
This is why I've pretty well decided that Swing on the JVM is the way to go. I have some confidence that a jar I compile today for a Swing app is going to work in ten years.
That's really weird to hear. If you build an app with GTK3 today, it's still going to work for 10 years. It's compiled into the application, it's not a runtime API. Even if you upgrade GNOME to some futuristic 10 year version, the GTK3 compiled app will just continue to work fine.
The parent thread is comparing a runtime API (Win32) with a compile-time library (GTK).
As a case in point, I just played with an unmodified GTK2 mapping app (FoxtrotGPS) from Openmoko times (2008) on my Librem 5 phone running modern Wayland shell (phosh). Wasn't crisp because GTK2 doesn't support hidpi, and touch support could be better, but worked very well otherwise.
If I build a static binary for each platform I want to release it on and we don't have another a.out to elf transition... Oh, and building it will end up needing a special environment as opposed to the stock JDK.
Actually if you read the links in the 'What's new' section, most of them start with the reason why they needed to break the backward fucntionality for this feature.
> GTK is the core of the GNOME development platform, but it can also be used to write applications for other Linux environments, as well as applications targeting Microsoft Windows and Apple macOS.
I'd love for some hn folks to share feedback on portability and overall value of using GTK for multiple platforms.
What other engines/platforms exist? I know of Kotlin for mobile/web but besides Electron, I'll have a hard time picking something for desktop apps, should portability be a requirement...
PS: I have a love-hate relationship with Electron. I guess I'm not the only one, so I won't elaborate.
The main cross platform open source offerings are GTK and QT.
There are lightweight electron alternatives - HTML/CSS engines with a scripting DSL. Sciter is a paid option but I know there are free options depending on your language of choice
I’ve been working on a cross platform music player and went with GTK over QT because I preferred the Rust bindings, QT seemed to have a lot of non UI code I didn’t need, and I was skeptical of dealing with QT licenses (but a lot of people seem to work with it just fine - I just didn’t put the research in to see if it was right for me).
Compiling linux / mac was very easy for me. Cross compiling linux -> windows via mingw64 was also pretty easy. I had some trouble compiling mingw64 on windows, but that was due to SQLite / MSys issues that I never really figured out.
> The main cross platform open source offerings are GTK and Qt.
Not really. Gtk UX just isn't an acceptable standard outside Gnome and seems to have approximately ~nil cross-platform share apart from GIMP and perhaps one or two more apps. There are really only two cross-platform toolkits that enable an acceptable level of UX: Qt Widgets and wxWidgets. wx has a smaller and generally more limited selection of widgets and some quibbles (awkward APIs, poor rich text support, docs aren't that great), while Qt Widgets is more on the "does it all" side of things, but that means it's less simple. E.g. a model-backed list is pretty darn simple in wx, but wx is also quite limited. Meanwhile Qt requires you to understand a relatively large model API and more code for basic models, but on the flipside it's also much more powerful. For anti-bloaters, Qt has a larger binary size than wx. wx has a bunch of stuff that only works on one platform or the other and there are a number of behavioral differences as well, since it mostly wraps an underlying toolkit. Qt tends to have largely uniform behavior and features across all platforms.
Qt (and not QT) is licensed under LGPL3 and GTK is licensed under 2 and later. So if you are not compiling a proprietary application on embedded device, it doesn't make any difference.
That's about one order of magnitude smaller than Electron. Good to know.
My gtk-rs project is intended to replace a small, self contained win32 application. The application is 132KB. So although 5MB is small it's an oom larger than my benchmark.
However, my gtk-rs hello, world GUI application is 14.6MB in release mode and that does not include the GTK DLLs that are also needed. Yikes. That's crazy.
Perhaps 5MB is a reasonable price to pay for cross platform GUI. Not taking 7+ seconds to build a GUI hello, world would be nice as well.
Indeed, the person you're replying may have experienced a parse error, but this isn't the same person as the one who claimed it's an oxymoron.
Maybe they made that claim because an alternative to Electron probably still uses HTML5 and JavaScript, and HTML5 and JavaScript are huge so it's hard to believe such a thing could be lightweight.
Anyone who says "JavaScript" is "huge" needs to be asked to both qualify and then substantiate the claim (along with the implicit suggestion that they have any idea what they're talking about, instead of just trying to participate in the pile-on with cheap remarks).
There's javascript runtimes for MCUs with <16MB of RAM (no, they are not the same as V8 in Chrome/Node/Electron, but that's the point: large range with many possible solution sizes)
Ardour (0) continues to use GTK2 as a cross-platform GUI toolkit for Linux, Windows, macOS (as well as Solaris/netBSD/FreeBSD). There are a few tricky issues on macOS and Windows, but when I've spoken to people with large cross-platform code bases built on Qt, it seems no better or worse than the case there.
We would like to move away from all desktop toolkits in theory (GTK and Qt as the prime examples) because they really don't offer us a lot. Unfortunately, they do offer:
1. Treeviews
2. File Selector
3. Text Entry
4. Menus
and we have no wish to reimplement these (TreeViews in GTK involve basically the entire toolkit). We slowly move towards a future vision based just on GDK (the lowest levels of GTK) but I doubt we will ever fully be able to drop the higher levels entirely.
I hope eventually I can find the time to contribute some kind of graphics enhancements to ardour. (Maybe this means using GPU acceleration or using a newer GDK version, I don't know) I've noticed scrolling the view can get somewhat laggy on my system when there are a lot of tracks.
The first option seems to be misnamed. When it's disabled it will cache the canvas widgets in cairo surfaces, but it will still use CPU blitting when it actually copies the image back to the window.
I couldn't find the second option, even grepping for it in git master.
How I wish there was a clean Swing implementation of the treetable widget/pattern in swing. JXTreetable makes me sad and wince everytime I have to open up the code. Cell renderers are OK... Until you want to go custom and synchronize events & drawing between renderers and you want them all coherent... And don't get me started on LnF and their interactions with JxTreetable... I know I should just shut up and go build mine own but this seems like such an oversight.
1.) I've written only a little bit using GTK, starting over this past month, and it has been very pleasant. The real issue I have is not knowing what documentation to use, or being a bit confused by the tooling. The existing open source projects using GTK I've been poking at over the last month written using JavaScript, Python, or C are all pretty (relatively) easy to grok and start working on. I'll definitely be back for more... FWIW- I do tend to learn by reading code; so for me, jumping into something totally foreign or unknown is pretty normal.
2.) I'd highly recommend trying Flutter+Dart for cross platform desktop applications. I've been writing my first, for about a month now, on Linux, and it has been fucking great mostly because it works. It uses Skia under the hood so rendering is fast and applications aren't totally bloated. I can speak nothing to building Flutter projects for the mobile or web variants but it seems neat in theory.
I'd definitely prefer to not write Dart, but I also accepted long ago, when you want to write GUI you pretty much have to learn a new language. It's close enough to JavaScript and/or Java learning it is pretty much just figuring out "WTF? Is X called?"
It's also a lot nicer, IMHO, than things like Electron because there's an actually useful SDK [1]. Electron, like the web, will require to you DIY a lot of really boring shit like wiring up list views to only use/reuse the displayed elements. Flutter, like most desktop GUI SDKs, brings a useful set of widgets to the table you can easily customize.
[1] No hate on Electron here; there's zero fault to be had for the web SDKs lacking useful APIs for making web apps... but that's a wholly different conversation I'd rather not have right meow.
> I'd definitely prefer to not write Dart, but I also accepted long ago, when you want to write GUI you pretty much have to learn a new language. It's close enough to JavaScript and/or Java learning it is pretty much just figuring out "WTF? Is X called?"
Are you using another language for your app, or is your entire stack in Dart and not just the UI?
Oh; it's all client-only (GUI) right now. So I've only been using Dart in this app (stack), if I need to add server components (which eventually I likely will) I'll write those in Elixir and/or Rust (i.e. languages I already know).
Nothing against the idea of server-side Dart, I just don't see a reason to bother with it. I've never really been sold on the idea of using the "same language" for both frontend and backend. I (try to) prefer the right tool for the job; which for my requirements, this time, is mostly how I ended up with Dart and Flutter... and I've been pleasantly surprised. It is the first cross-platform desktop language & sdk pairing I've used that I, personally, don't totally hate. Every other time, I've just said "fuck this" and gone and implemented it whatever the native SDKs were.
Oh, I don't mean I hate Dart by any means, I've just written UIs in a lot of languages at this point and would rather use something I'm more familiar with... The one very minor annoyance I've had with Dart that immediately pops to mind, and I think is going to be fixed soon (according to the github issue), is typedefs only working for functions. I personally think it makes things a lot more verbose and unnecessarily difficult to read at times ¯\_(ツ)_/¯
I certainly like it well enough to continue to learn and use both it and Flutter :)
For what it's worth, GTK and Qt (while being cross platform) are also effectively the native toolkits on Linux. So if you're developing for Linux in the first place, you get the cross platform bit for free.
Of course it also means extra effort to make them less alien on MacOS and Windows.
While less than popular, I'm more inclined to just target Electron or Carlo and leave it at that for my UIs. I know that it's much higher overhead, and if I was doing something with a minimal UI, or something that persisted in a tray I'd probably reach for something more minimal. It really depends on the use case.
React Native options may be another target that I might look into if I needed native, thought he UI kits aren't quite as interoperable as I'd necessarily like, it's a pretty decent option.
I mostly do full-stack service layers with react/web ui these days so anything that leans on what I already do is likely the best use of my time. A browser surface, while massive, memory hungry etc, is still often the best option for any app UI work as it solves so many issues and can run everywhere. It's the combination of those two that make it so appealing. Reducing friction. Of course it's also why we have mobile devices with 4gb+ ram on them these days.
I look at my Windows 10 desktop and you know what? Everything is alien. Even Microsoft's own stuff doesn't feel native any longer. Every program I care about is based on some widget tookit/framework that isn't now and probably never will be whatever Microsoft is pushing this year, and Microsoft's own software spans some unknown number of GUI evolution phases as well.
I used to think there was value in being well aligned with the native Desktop UI. Now I don't really know what that is any more and I no longer really care. I care that a given application serves it purpose and the degree of an application's alignment with the latest native UI trend is well down on my list of concerns. Coping with the delta between applications is a small problem I try not to get hung up on.
The same thing is happening to macOS. Big Sur is sealing the deal with a mishmash of iOS styles inconsistently applied across the desktop.
I was always a huge believer in native UI, following the platform HIG, never reinventing controls just to satisfy graphic design caprices; but Apple has essentially given up on these things.
The Mac UI is now just Windows 10 with rounded corners instead of sharp.
Well that's 0 for 3 then. Linux has always exhibited this 'problem.' Windows is effectively at parity with Linux now, and you point out the increasing divergence of even macOS.
What shall we conclude from all of this? I propose that simultaneously expecting a) an operating system to host a limitless diversity of graphical applications with origins that transcend platforms, programming paradigms and decades and b) that they all precisely align with your chosen operating systems ever changing GUI conventions and c) all of this be delivered at at least affordable if not no cost -- is simply unreasonable.
I suppose you could argue having a common style between macOS and iOS is more consistent. I'm still undecided about the new style in Big Sur. On the other hand I spend a lot of time in Windows and find the whole UI grating.
I'm a big fan of using plain SWT[1] without JFace. In fact GTK4 support is already being work on!
I tend to see a lot of developers think of Eclipse Platform UI/JFace[2] when they see SWT. Eclipse Platform UI is Eclipse's abstraction over SWT that allows them to make consistent components across platforms. SWT is lighter weight and it's just platform native components. Also since you are dealing with native components you get easy access to platform accessibility.
Eclipse has some great documentation for the platform as well as loads of snippets[3] and examples[4] to pick apart.
There is also an incredibly useful charting library[5] that is used heavily by OpenChrom(Uses Eclipse platform)[6].
I have only tried it with some small samples, but SWT does work with GraalVM native-image[7]. This should allow you to develop a nice little statically link executable instead of deploying a jar if needed.
I've worked professionally on a fairly large SWT-based project. This project was started when Swing was slow and ugly so SWT probably seemed fresh. Also, having a native L&F was important in those days.
We had tons of problems and they where almost never easy to fix. Layouting in SWT is hard. Custom widgets are hard. SWT did not play nice with Swing/AWT on Linux so it would crash if you needed to use both. I remember I spent a lot of time getting automated testing working reliably (on mac) but eventually just gave up.
Things might have improved since I worked on this 7 years ago but I would not bet on it. SWT is basically a support library for Eclipse and therefore Eclipse is more or less the sole driver for any development.
I would rather just use Swing. Compared to when SWT was started Swing has evolved a lot and IMO the rationale for going with SWT does not exist anymore.
I haven't found the Layout system to be lacking or too difficult to deal with. My only issue with it is how verbose it feels sometimes. The operation of layout and layoutData can be a bit confusing.
You can always roll your own layout system using Control setBounds and moveAbove. I have toyed around with a custom layout system on top of SWT that uses Cassowary Constraints (in fact the imgur link in my other comment shows a sample).
As for custom widgets it really depends on how you want to do it since there are so many options. SWT can embed Swing or JavaFX components, so it allows the developer to make custom widgets in whichever tech they feel most comfortable. In this case I would stick with Swing since JavaFx can be a decently sized dependency, where as Swing is built into the jre.
The eclipse nebula project is also a pretty big repository of community made custom widgets. These can be really helpful for figuring out how to implement custom widgets in pure SWT.
https://github.com/eclipse/nebula
I have never implemented automated testing with it though, bummer it was such a hassle.
Also SWT does grant access to a bit more of the underlying OS than Swing does with its org.eclipse.swt.internal.* package. For example I've had to embed a GLFW window inside a SWT window. This is done with the following api in GLFW: https://www.glfw.org/docs/3.3/group__native.html
Using the internal apis you to map GLFWs native window handle to something SWT understands pretty easily. Then it's just a matter of writing the platform specific code to reparent the GLFW window into App which was 3 or 4 lines of code per platform. Then once the GLFW app was inside the SWT App it was a matter of creating a dummy Composite that when resized would overlay the GLFW app. I don't believe this would have been possible in Swing without addition JNI. I know this is a pretty obscure use case, but the internal package can be extremely handy.
Lastly, SWT has a built in browser component that uses the OSs browser or there are optional embedded V8 and webkit packages. The feature set of SWT just blows other Java toolkits out of the water. Unfortunately, this does lead it to be a bit more complicated than the others. I'm sorry about your experience, but give it another whirl sometime maybe you'll be pleasantly surprised.
A super simple test on Ubuntu I did back in November got me a 14mb executable consuming about 23mb of ram and about 38mb once the app was full screened. I'm pretty happy with the size considering the smallest runtime I can get with jlink around 40mb. I have also found GraalVM devs to be very responsive to issues on Github.
I should note I am using Haxe here instead of pure Java, so a pure Java app might be a few kilobytes smaller.
It used to be that Swing/AWT really sucked. The default theme on every platform (Metal) was really ugly. Everything was purple. The "native" look and feel was emulated (poorly). It was also very slow. That's the reasons why SWT was started in the first place. Swing would just not cut it for any app that wanted a nice UI.
Nowadays the situation is completely different. Swing looks and performs great compared to SWT. IMO it would make much more sense to just use Swing.
JavaFX never happened. People just went web instead. No one uses it and it's officially deprecated.
JavaFX was split out from the JRE and is now its own package[1]. It very much "happened" and there are plenty[2] of people using it.
If you are looking to build a fully themed app similar to a web app Swing or JavaFX are definitely the way to go. Swing still uses an emulated native look and feel and it is pretty decent. If you are planning on building something with real platform UI I would still go with SWT, especially if accessibility is on the table.
JavaFX may be the most feature complete cross platform GUI framework after Qt. I have recently used it for a project and it tuned out much better than if I had used Swing.
I went digging a bit, and there's work being done to making it possible to use react-native for cross-platform desktop apps too: https://github.com/status-im/react-native-desktop-qt Doesn't look production-ready yet, but seems promising.
Uses fucking AWT for windowing (so no Wayland support), uses a hardcoded list of platforms like "linux amd64" (gonna be a huge pain in the ass on BSD/ARM), so rather disappointing from a unix perspective. Of course commercial app developers don't care about any of this, sadly.
If you use GTK on a KDE system you will get the Qt file chooser dialog assuming the developer of the GTK application is using GtkFileChooserNative. People should really stop complaining without noticing their problem is already fixed, but such is open-source.
People complain because the file chooser is broken for most of their GTK-based apps and not for any of their other apps. Expecting them to link the problem to an invisible factor (API call) is ridiculous and silly, but such is open-source.
It will still have the same unusable look and feel as Gnome 3, so it doesn't even matter what name they give. It was 9 years ago, but it still hurts me to think about the release of Gnome 3 and all the different ways they went downhill with this once-beautiful project. Seriously, damn the people who took over the direction of Gnome. Now even Wayland development is mostly focused on Gnome. Where's my time machine?
Thinking seriously about moving to KDE with all these schengens happening around Gnome. All the feature removing between 2 to 3 was already annoying. I wanted HiDPI support and productivity effects from Compiz (like drawing on the screen), not a fake Mac.
My weapon of choice is kubuntu since 18.04 LTS. The only complaint I have is that konsole's cut/paste/selection mechanism eventually ceases to work (copy or select does nothing, old buffer contents remain) after a konsole process has been running for a few weeks.
Unlike your desire for effects, I prefer KDE because you can still completely disable effects and the compositing that make it performant and get excellent, glitch free remote desktop performance over a fast local network using VNC; almost no perceptible lag in normal development actively.
KDE has matured. They took the 4.x fiasco to heart and now KDE development is highly conservative and unobtrusive. I'm frankly amazed; popular Linux desktop environments have such a long history of design failures due to iconoclasts blowing everything up that the current state of KDE seems almost miraculous.
Gnome has its own distinctive feel for me, and it feels entirely different from mac or windows. I don't really understand the hate i keep seeing on here to be honest.
Yes, experimentally since GTK+ 3.2 and Wayland 1.0 protocol since GTK+ 3.8. The backend can be selected with GDK_BACKEND=wayland or GDK_BACKEND=x11 - except in some applications which still force a X11 connection.
[On a personal note, this will be my last release for Cairo. My Cairo
time availability has been non-existent (particularly this crazy past
year). The release process is well documented and hopefully will help
whomever picks up the baton from here.]
Looks like that the situation was mitigated for this release, but the situation will be more dire the next time someone needs a new Cairo release cut.
I understand breaking backwards compatibility a first time, maybe out of a failure to plan ahead, but not multiple times.
It would be easy enough to add new subroutines to add more functionality. Is there a reason to change or remove old subroutines of which I’m not aware? Otherwise this is just causing extra work for application developers for no good reason and in many cases killing old stable applications which are no longer developed.