This is excellent work, and although I really appreciate the effort for porting more applications from Linux I really do worry this will distract developers from building native applications for Haiku and relying on compatibility layers like this to port or develop applications, this wasn’t such a concern with Qt as that isn’t such a mess as GTK is but I really hope developers will still rely on native Haiku APIs to build their applications that don’t require X11 and not on a bunch of compatibility layers as that’s the best way to achieve obfuscation and fragmentation between developers.
Sorry if this didn’t make any sense to some people btw, im not a developer but things on Linux like Flatpak and Snap with their sandboxing has caused so much fragmentation especially with things like GTK introducing libadwaita, im really worried to see Haiku go down that path with extreme fragmentation between developers.
By the way, Snap and Flatpak are packaging (anti-)tools, not ToolKits. They try to solve distribution problems of precompiled binaries. They basically are just windows “install pre-requisite” installers in a nice shell. Don’t get me wrong, I’m not fond of those tools but they do not “fragment” Linux since they are just that: a fat archive. They work but consume lots of redundant space. They are not what Linux has been designed for (you’ve got source code access) and is not what a true Linuxian would use.
When was the last time you heard a Windows user say that application X and Y suck because they were compiled with an outdated version of Visual Studio, or they use Qt instead of the win32 GUI? The fact that this is even an issue at all in Linux is a testament to how badly most of the Linux ecosystem is designed.
There are so many Linux applications where any real feature work will halt for 3 years because they have to rewrite everything for a new version of GTK. This is pure insanity. Let’s not go there.
Which library and which GUI toolkit an application developer decides to use should not matter at all, as long as the application provides the user with a pleasant experience. And this is really what ports should be about as well: get as many applications as possible to run and make them as pleasant to use as possible for the user.
Applying a principle of absolute library purity only makes sense when writing a new application from scratch. It makes no sense at all when you want to run 20 year old applications or applications that originate on a different platform.
Please don’t generalize a crappy toolkit (GTK) to an entire operating system. Yes, GTK sucks and if you create your app with it you are in for hell. But the same is true for Windows. Pick the wrong toolkit library to build your app upon and you punish yourself and your users.
Other than raw Win32 UI API (you can’t avoid this at the lowest level) I can only imagine you mean MFC. Having had to do a bit of MFC recently, it’s not that bad if you do it right. If you try to bring in all the C++11/14/20 features, yeah - you are fighting against the easy route.
Under .Net, WinForms is a slight pain point, but all of the Xaml based stuff is dead simple. And not having to deal with iOS and Android API directly makes the Xaml approach a win in my book. Roll on Maui.
Windows also changes UI APIs quite frequently… win32, MFC, winforms, WPF, UWP, MAUI… and windows applications can lack features or stagnate because one API was chosen over another. But Windows users have no idea about the internals of any given application, so they will not make statements relating to the what API was used to develop them.
And of course, many commercial windows applications have had to move from one UI framework to another over time. Commercial software vendors just have to suck it up and pay for developers to make the changes in the required time frame because they need to keep their product moving. On the other hand. an open source project cannot simply hire more devs when they have a requirement to move to a new UI API, so it takes them longer to make a similar transition.
I don’t disagree that it’s a problem on Linux, and fragmentation with different toolkits (and sound servers, and init systems and … everything) is a whole other set of annoyances. But what you describe isn’t unique to Linux, it’s just something windows users don’t know is happening.
Yes, UI APIs change quite frequently in Windows and there are tons of foreign libraries being used all the time, and yet for the most part it all works fine. Most Windows users are not aware of the internals of an application, because it doesn’t matter, plain simple. It just works, and on the odd occasion that an application does break on a new Windows release, it only needs a small bugfix, not a complete rewrite.
I use applications from ~2003 on Windows 10 all the time, without even recompiling them. Linux really is a dumpster fire in this regard. I will say however, that the BSDs and macOS are almost as bad.
The base API for most of Windows since Windows 95, and a it was basically the old 16bit APi with 32 bit extensions and some of the co-operative multitasking stuff removed… and Win32s was also available on Windows 3.1… though it was a cut down API.
Win32 has existed since 1992 on paper. I believe it existed in fact since 1993. So 20 odd years.
Is a very thin wrapper around Win32. You actually need to know Win32 also to do anything that is not supported directly out of the box.
MFC went away mainly because visual development became the popular way to enter Windows development and MFC was very not visual in the main. I mean, you can use the resource editor to design basic Windows… but it is not great.
Basically Win32 for .Net. It is a bit like a mash-up of the old VB style API and the MFC style API without all the stuff that makes you want to abandon it. The biggest failing was “all code goes in the code behind.” But, honestly, if you have used anything that is designer based (VB, Delphi, Visual Cafe… etc) it is much the same muchness.
But really, it is just a slightly thicker layer over Win32… and if you want to do anything new, you end up using Win32 to implement it.
So these are very similar and basically jumping between them is fairly painless. If you understand Xaml. If you don’t… good luck!
WPF was the first MS framework that actually did something different. UWP was a bit pointless, but is similar enough.
But you also need to add WinUI to the list, because that is a thing (though it came out of UWP.)
Is basically Xamarin.Forms scaled up. It is just Xaml. It is just like WPF. If you know WPF, and I mean really knwo it and don;t just use it as WinForms with Xaml, it is really not a massive jump.
Why should users care about the UI SDK? This is why BeAPI is the best choice for anything native… the API you ship with the OS is always the best choice. A windows User won’t complain because they don’t care. Nor does a Mac user, and there you now have Cocoa, SwiftUI and Catalyst.
That rarely happens. What actually happens is a new “App X” is completely rewritten and released as “App X+” and it replaces the old app. Some users try to hold on to the old version with all their might, but at the end of the day, progress. If that doesn’t happen, then a company will hit a natural barrier (like 32 - 64bit migration) and will either drop development or lose ground to a competitor if they drag their feet too long.
None of this is any different in the open source world. The main difference is that it is in the control of users as well as developers, and the transition happens in plain view.
I don’t think (and didn’t say) that users should care about what UI was used, just that windows user are less likely to know anything about it, in response to “When was the last time you heard a Windows user say …”. Windows users don’t know much of anything about the development of the applications they use because they are closed source and the developers don’t tell them anything. Whereas for an open source application they may well read somewhere “we are taking a long time with this release because of the transition from X to Y”.
You’ve just described in a bit more detail what I wrote. It sounds like a lot of effort, rewriting an application from scratch, right?!
I think your post is mostly in agreement with what I wrote. I have worked with the various windows UI APIs at one time or another (mostly stopped doing windows work in 2009 though), and I do think that they are more effort to transition between than you suggest. I only wanted to point out that it remains a significant effort to either maintain or transition windows applications across different APIs just as on Linux… and the problem exists on windows whether users know it is there or not. The old binaries may well run: Windows is, in general, very very good at backwards compatibility.
I agree, of course, that native haiku applications are better.
That certain degree of hell can not be avoided if you don’t shut down your system in a way nearly nobody is allowed to do anything creative with it. Nothing against Haiku, just explaining that with creative freedom vs rigid shut down you just can not avoid this kind of friction.
No. Why does such a “crappy” toolkit like GTK have tools like Glade, that make creating a beautiful GUI a breeze, while on on Haiku programming a GUI is like going back to the year 1985. GIMP is based on GTK (or perhaps vice versa). Gnome is GTK. Firefox. Inkscape. Looks like a lot of useful software use that toolkit, even though its supposedly so bad.
Just because it has Glade does not mean the internals are any nicer, and just because Haiku does not have a well-used visual design application does not mean that designing a GUI is like going back to 1985. BLayoutBuilder is actually a pretty nice way to build UIs, though I do agree that visual tools are nicer for this purpose.
(There are some layout editing applications for BeOS/Haiku out there, but they are all kind of limited and none are currently maintained.)
My experience is with Vala, so the internals of GTK were not exposed to me (aside from some peculiarities esp. with glade). Nevertheless I find it hard to believe such a widespread and easy to use toolkit would be as bad as represented in this thread, especially given the strange attitude towards “linux stuff” on these forums.
As far as Haiku GUI developement, yes, layouts are a step in the right direction, but without the support of developement tools they will merely bump the developement experience to year 1990 max.
It isn’t. Vala may well be, but that’s because Vala is covering up all or at least most of the nastiness for you.
There used to be an example of the C code Vala generates on the Wikipedia article. There isn’t anymore, but you can still see it on an old copy of the page. Generated C code is usually uglier than handwritten C, but in this case, handwritten C interfacing with GTK would look pretty much identical to that, and does.
If you can at least read C, I have plenty of examples I can point you to just from the past few days of banging on GTK internals as part of Xlibe work…
A lot of Linux stuff is not great, yes. But GTK is in a very special class all its own. I don’t know anything else (whether that be the Linux kernel itself, systemd, glibc, etc.) that rivals it in this category.
Qt, for instance, is a genuinely more pleasant toolkit to develop for than just about all major native APIs save Haiku’s, and maybe macOS’s (however I haven’t really used macOS’s very much, and I’m given to understand it has a lot of “gotchas.”) Its internals are quite navigable to anyone who has written a bunch of code using Qt in the first place. No such things can be even remotely said of GTK.
I’m not sure why you keep exaggerating here. When did Windows or macOS toolkits get layouts, exactly? At least BeOS never had them, so in Haiku land, we are somewhere past 2001, not 1990.
That is indeed the point of a high level language.
The GTK C API still seems like a natural representation of OOP principle in a non-oop language (much like the win32 API ).
I can certainly read C, and during my sojourn to Vala, the API docs would sometimes point to the C APIs instead, which were perfectly understandable. As for the implementations, I did not give a toss.
I was just joking. It’s been so long that i have manually programmed a GUI.
To me, it isn’t; the Win32 API is significantly better. But the whole idea of OOP in a non-OOP language, or more specifically, OOP in a language that does not even have “objects”, much less “inheritance” or “ownership”, is just a ridiculous idea in the first place…
Well, if you fancy a go, see if you can decipher how GTK’s icon loading procedures work. Hint: gtk_icon_theme_lookup_icon_for_scale is roughly in the middle of them, you might “begin” there…
At a glance it doesn’t look like anything crazy. The code is actually good quality. A good IDE will help you navigate, simulate and debug that right away.
The central question still remains; if GTK/Linux/Windows is so bad, then why is it so good?
If you think 6-8 layers of functions each over a hundred lines just to pick what icon to load and use, are “good quality” code, then I’m not sure what to say here.
I’m on my phone, but i dont think any of those functions are even close to 100 lines. As for “layers of code”, well, thats how you break the code into easily navigable and simulatable chunks of course.