Cambalache is a successor for Glade but it also has issues. It uses its own storage format and you have to export to a .ui file for use in your Gtk4 project, and if you make changes to the UI file it's very difficult or even impossible to use those changes in Cambalache again.
The general consensus on a few of the GNOME-related Matrix channels seems to be writing .ui files by hand.
Cambalache is years away to reach feature parity with Glade. Then there is the whole of using Web to render the designer.
I'm sure all the distros are busy, but it sure would be nice if one of them would fund get a developer they pay to do this.
It suffers from we don't think about UI but only about technology. GUI Builder the old way stink (only XCode stinks like a perfume). There is also a reason why Microsoft does not offer a GUI Builder for their new WinUI 3
There are good reasons why professional developers abandoned GTK+, and this is just one of them.
* First: GNOME was born without an IDE. But, there was an interesting little project (by Naba Kumar) which started in late the mid 90's called Anjuta. IIRC, Anjuta 0.x to 1.x was what was called a "monolithic" IDE; that is: it didn't had any plugins and its features were "hard-coded". The 2.0 rewrite allowed it to have plugins, but they didn't covered (at first) all of the features of Anjuta 1.x. It was only around 2.4 or 2.6 that Anjuta finally got feature-rich and reasonably stable enough to become part of the GNOME project and the "IDE of the GNOME project" although most GNOME devs didn't use it.
* Second: GNOME was born without a GUI Builder. The most successful one was Glade. At first, glade generated C source code for the UI using GTK. Then people thought it was bad and someone created libglade. The 'project libglade' was two things: a XML format specifying an UI description and a library that could dynamically (at runtime) load it and build a GTK interface from that description. It could even connect signals without a single line of C source code.
Since libglade seemed like a good idea it was eventually incorporated into GTK in a format that is now called GtkBuilder.
Parallel to this, many events happened. Glade changed hands a few times and eventually its main developer became Chema Celorio. Celorio was a skydiver and one day he had a problem with his parachute and died. Glade development became dormant until it was picked up again by Tristan Van Berkom. Trista modernized it, 'resurrected' it, improved its UI, rewrote many parts of it and eventually removed its code generation back-end to use only the GtkBuilder format.
* Third: At the same time, Anjuta development also changed hands. I remember Johannes Schimidt and a few others. At some point, there was an integration between Glade and Anjuta, but it was not very different from running the two tools separated except for the fact that they shared the same window.
There was some hope when, during the selection for Google Summer of code an interesting project was chosen: improve the integration by Pavel Kostyuchenko. The project was successful and the integration between Glade and Anjuta improved because of it.
I was happy and hopeful for these facts when one day I saw that (part of) the integration code was chopped off. I was so intrigued by this fact that I decided to ask Anjuta devs personally (on IRC) what had happened. The answer was something like: "it was not as good as we'd like, fixing it would be much more work than rewriting it."
That was when I decided to join the project to fix it myself. I improved the integration between Glade and Anjuta. Rewrote how it created functions inside the C source code, how it discovered automatically which .c and .h files were associated with the .ui file. Implemented automatic creation of members on the C struct that corresponded to the UI elements, fixed some bugs, wrote a documentation which was a good tutorial on how to use these features... I even implemented the preview feature in Glade. I really made the integration work to my liking. It was the workflow I dreamed.
The future seemed bright: there were new developers, frequent commits, new feature were implemented frequently... But GTK evolved faster than Glade. Tristan eventually abandoned it and it was picked up by Juan Pablo Ugarte. By around this time, Glade became something of a monstrosity of technical debt, slow, crash-prone and buggy but it worked. Implementing support for modern GTK features (like bindings and css) seemed to much work and too hard to do.
* Fourth: Around 2013 Christian Hergert started developing a modern IDE for GNOME: GNOME Builder. He left his job, started a campaign to get money to back him up during first versions and quickly showed a lot of progress. It was said at the time that it was going to have Glade integration (it eventually did have, but it was never a decent one). The project thrived and Redhat hired him.
Development of Anjuta slowly became dormant after this. It is now archived.
Hergert started another project, Drafting, to replace Glade but it was de-prioritized. Ugarte basically abandoned Glade and started Cambalache. Cambalache seems like a good idea, works but has no IDE integration and is still mostly a "one man show".
And that is how we arrived at where we are. GNOME still lacks a good UI builder with IDE integration and no current plans to fill this gap.
this deserves to be made into its own blog post.
In general you can get most of old Linux stuff to work if you find and install the relevant libraries, the main issue is that these libraries tend to be spread all over the place and sometimes even conflict with existing libraries.
With Windows you also need to do something similar with older games (e.g. use dgVoodoo2 to play old Direct3D and Glide games) but since Windows comes out with a lot more stuff and that stuff tends to be backwards compatible for the most stuff, there is much less to worry about.
There was an article a couple of years ago about taking binaries from either windows 1 or 2, changing a few bits of the header and it would run fine.
Edit: actually it's covered in the Wikipedia article https://en.m.wikipedia.org/wiki/Windows_1.0x
It's an old citation but here's the snippet:
"Due to Microsoft's extensive support for backward compatibility, it is not only possible to execute Windows 1.0 binary programs on current versions of Windows to a large extent but also to recompile their source code into an equally functional "modern" application with just limited modifications"
I haven't touched windows in probably 15 years though so I can't speak for any of this. Funny, I was a Windows software developer for a decade and now I know nothing about it. I don't even know if the debug tools I used to use made the leap to 64 bit
Windows had one for DOS, Windows 16, "posix" and "os/2" with the last two in air quotes because it was only a subsection and they claimed mission accomplished - I think it was specifically to satisfy some government requirement but don't use me as a reference here. I don't think it could do os/2 "Presentation Manager" for instance.
Regardless, it didn't come free - there's people up in Redmond who had that as part (or maybe all) of their job. I would have done that - maintain an esoteric part of Windows for a Microsoft salary? That's the kind of job where you have almost no boss. Sign me up.
There was a Presentation Manager subsystem for NT that could run 16-bit OS/2 graphical programs, but it was about as hard to come by as buying a single LTSC license is today.
The lesson of DESQ is to design software to run on the computers of tomorrow and don't worry so much about the computers of today. That sounds stupid to me as well but neither of us have yachts or private jets so what do we know. It's about colonizing the future.
I wouldn't be surprised if FreeDOS could spin this up.
https://virtuallyfun.com/2011/03/27/desqviewx/
There's also a long running ticket in dosemu2 around some issues with DesqView/X https://github.com/dosemu2/dosemu2/issues/606
In some more years it will probably be working fine there.
DesqView/X was graphically multi-tasking DOS programs and running X applications the year after Linux was released. This was the Windows 3.1 era ( no cooperative multitasking ) and before OS/2 2.0 was out. Amazing.
Like everything else at the time though, it could not run Windows applications ( Microsoft Office ) and so it was doomed.
Old Microsoft put lots of thought into extensibility of APIs and makes it so that the old interfaces still work when they introduce new functionality.
New Microsoft rewrites components from scratch and deprecates the old one every few years, and doesn't bother to shim over the old interface.
The former group has it such that if your app was well written circa 1997-2001, it works well on the current release.
The latter group has it so that you have several different copies of .NET on your hard drive and the "recommended" UI libraries for new applications has changed a lot, and the new hotness from a few years ago is deprecated.
This seems to be a trend across the industry, not just Microsoft. And it's a real shame. It makes it too risky to use a lot of shiny new things in real projects.
The Microsoft-specific variant of it is something I've seen up close. One of the issues always struck me as confusing interface and implementation. There isn't a good recognition of the fact that when you write against an API, you code against an abstraction, not a particular implementation. If your interface is good enough, you can do the rewrite treadmill thing to justify your current bonus or whatever, but you can point the old interface at a new implementation without most callers knowing the difference.
So, I think a good example of this working relatively well would be Windows audio. The WinMM API still works. They rewrote the audio stack a couple of times, and introduced new APIs such as WASAPI and I forget the newer one. Winmm isn't broken. It may not have access to all the latest features, but it works.
In contrast, all too often they discard an entire API because they want to rewrite the components underneath. But the I in API stands for interface. A good interface can survive rewrites of what's underneath.
Absolutely!
But a good interface is also a really difficult thing to engineer, in part because it seems like a relatively easy thing. The gotchas don't become apparent until long after you ship.
Sometimes I wonder if some of this is just cost-cutting. A difficult task is an expensive task. Other times, I wonder if it's because API design is an actual specialty, and there are too many devs doing it who don't have the chops for it.
Some interfaces that are very simple can allow a broad range of implementations but cannot not expose their capabilities. On the other hand, some interfaces that provide good control over runtime characteristics etc. already give away the implementation.
If "API" were primarily about abstraction, it would be called APA.
One point I'll offer is that ability to shim an old interface onto a new implementation validates the design of the new thing. If you can't shim them, chances are there's some necessary problem you aren't solving, and possibly aren't aware of.
Concrete details of all these things will alter the discussion. I think my example of audio is a good one for the strength of "the old way". The old interface works, even though it does vastly different things than it did in 1995. Like you say, maybe there are some features you can't get with the old interface -- that can be OK. But they didn't break it.
The Win32 subsystem on NT-based Windows began as such a shim too. The NT native APIs sometimes look very very different. Most people don't know this. eg. Most people don't know that renaming things isn't its own syscall that operates on a source filename a la unix rename(2), which is what Win9x did -- that there's transparently an NtCreateFile() call that happens inside MoveFile() ... Philosophically, the NT API "hates" doing things based on filenames, most operations that Unix or Winapi have as filenames operate on handles... But nobody needs to know, the Win9x API is the public API.
Deprecated C++/CX and .NET Native, while neither Native AOT nor C++/WinRT are proper replacements in capabilities, replaced UWP/WinUI 2.0 with WinAppSDK/WinUI 3.0 with lots of missing capabilities.
I highly encourage you to take a look at the work Microsoft did with the XBox backwards compatibility for the XBox One X/S; unlike their naming teams, MS have people who care deeply about this stuff. Not only did they spend a lot of time making sure that most games work on the One X, they spent time doing things like having the newer platform upgrade the games on the fly where possible.
MS absolutely has people tinkering with their old APIs, sometimes to quite good effect.
Really old citation, 1995...
>There was an article a couple of years ago about taking binaries from either windows 1...
The below article seems to go more indepth and was written in 2020, might even be the one you were thinking of:
https://soylentnews.org/article.pl?sid=20/05/10/1753203
>As previously noted, Windows 95 dropped support for 1.x and 2.x binaries. The same however was not true for Windows NT, which modern versions of Windows are based upon. However, running 16-bit applications is complicated by the fact that NTVDM is not available on 64-bit installations.
>After letting NTVDM install, a second attempt shows, yes, it is possible to run Windows 1.x applications on Windows 10 [32-bit].
>FONTTEST also worked without issue, although the TrueType fonts from Windows 3.1 had disappeared.
No way. I'll need major citations on that. Wikipedia for one, firmly disagrees as does every book I've read on that history.
Windows backwards compatibility is also pretty phenomenal if you DON'T know what you're doing and are important enough.
There is the famous case about Windows 95 detecting SimCity and then switching to a more careful memory manager as SimCity had quite some use after free problems, which would crash otherwise.
https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...
This is a point on which I give Microsoft high praise, and they have my great sympathy.
The issue for Windows is existential -- a large percentage (perhaps a majority) of people would ditch Windows in a heartbeat if they had to replace their software because of a new Windows version. Backward compatibility is Microsoft's moat.
It has been worth it to Microsoft to put serious resources toward that end, and they've worked miracles in terms of backward compatibility. It really is amazing.
And I have sympathy for them about it, too, because I guarantee that Microsoft would rather be able to run without carrying that burden too much.
I think this is the main reason why they are extremely forceful about updates. If everyone is using the same version, backward compatibility becomes easier because you don't have to keep it for as long.
And then I opened again a windows laptop...and the words than came to mind were "missing the forest for the trees".
Like, I feel that Microsoft really cares a lot about each and every tree, and went above and beyond to make the most trees happy and cut down as few trees as they could at every iteration. And we lauded then for that, cheering at every tree that could stay alive.
Except now the forest is really badly planned, it grew and expanded a lot but without enough prunning really, each user has to carve a path with a chainsaw to get anywhere livable, we regularly fall into forgotten valleys with runes to unlock lost technology.
I won't argue it needs to be a walled garden breaking new at every release, but there must be a better middle-ground for all of this.
It's hard, really hard, so I don't really blame them for failing. But, Apple mostly managed it. AppKit/UIKit is pretty much a direct path from NeXTStep in the 1980s. 30+ years of evolution, without breaking the whole API until SwiftUI came along. Pretty impressive. Apple should get more credit for that.
Just thinking about the two processor architecture transitions and the whole OS7 -> OSX switch, they really have an expertise no other company seems to even get close to.
Offering emulation where compatibility is broken definitely helps.
[1] https://learn.microsoft.com/en-us/windows/apps/get-started/#...
[2] https://learn.microsoft.com/en-us/windows/win32/
[3] https://learn.microsoft.com/en-us/windows/win32/hidpi/high-d...
"if you're creating a new Windows app from scratch, it is highly recommended that you create a Universal Windows Platform (UWP) application. UWP applications automatically—and dynamically—scale for each display that they're running on."
but no fault on you for being confused, Microsoft announces changes in strategy so fast they can't update their docs to keep up, so their once great MSDN has become a rats nest of contradictory advice and recommendations.
At any rate if you've tried to do Win32 hidpi you will know that it hardly works and this represents defeat by Microsoft. For example hidpi is only even attempted for windows created from dialog resources, but most aren't, so if you run any classical win32 apps they still have tiny 16x16 icons everywhere, tiny fonts, basically unusable on modern screens. Apple went through this pain with the original Retina transition where icons were blurry on old apps for a while, but they updated all their own apps and brought the ecosystem with them on that journey. Microsoft never did.
And it's all like that. Win32 has barely evolved for decades. There are occasional new magic flags and an ever-greater pile of hacks, but there's been no serious attempt to keep it competitive. The assumption was that everyone would migrate to .NET and WinForms but that didn't happen for various reasons. By then, Win32 - never a particularly well designed or well loved API even inside MS - was so aged that they felt it'd be easier to start over from scratch. And once that Rubicon was crossed, they did it again and again.
Motif is pretty good here too.
But Gtk5 port will be total madness. No more modal windows and no more traditional tree view. I can agree that it removes a lot of problems and maintenance from the Gtk Team, but the cost for the application developers is huge.
But just as Win32API we can all still use Gtk2
Hopefully easier? Unsure however.
> But I think having that compatibility is one of the reasons of Linux's success, the rule of "Do not break user space".
Quite. Of course, it's a sometimes repeated joke that the Linux GUI toolkit with the most binary compatibility is the Win32 API (via Wine).