Microsoft's ongoing efforts for WinUI seem to be missing.
https://github.com/microsoft/microsoft-ui-xaml/issues/2488
As mentioned on the thread, the current samples are at https://github.com/microsoft/windows-rs
https://github.com/microsoft/microsoft-ui-xaml/issues/2488
As mentioned on the thread, the current samples are at https://github.com/microsoft/windows-rs
I just spent a few hours evaluating WinUI 3 for a new project. There's currently no way to hook into the app exit event. Want to flush your SQLite store before you exit? Tough.
It is all a matter of using either UWP or Win32, regarding which API to use.
Win32 use WM_CLOSE
https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-clo...
UWP use Application.Suspending
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.app...
I would put my money on WinForms being ported to Linux first...
For my part, I'd argue that, if you care about inclusiveness, you should probably favor either Electron or some other option that builds on the Web stack, or writing a separate native front-end for every platform. The problem with all the cross-platform toolkits is that they have accessibility problems.
more like 76%:
https://www.statista.com/statistics/218089/global-market-sha...
Can't be bothered to verify the tablet claim but that's probably wrong as well.
Is it really worth the argument?
ed: https://gs.statcounter.com/os-market-share/desktop/worldwide...
Plus there are these other toys called HoloLens and XBox.
This was pre WinUI, but a while back I worked at a shop that simultaneously maintained Web-based and WPF versions of an app. The Web version required 3 dedicated developers to maintain. The WPF version needed about half of one person's time, and had more features.
I would say that the main thing favoring tools like Electron is entry costs. There are lots and lots of people who know who to do front-end Web development, and you can do a good job of supporting all platforms using free tools. Even if you grant me for the sake of argument that native GUIs cost less in the long run, there aren't a whole lot of people who have experience doing them these days, even fewer who have experience on more than one platform. Going that route also requires you to shell out for Macs and probably also Visual Studio.
Microsoft is trying to port some of this magic with Blazor, with is quite liked from what I read here and there.
XAML and MVVM is all about two-way data binding. JS frameworks copied it at first. But now it is widely recognized that 2-way data binding is a bad idea.
You can use for Web development too.
As someone who loved Swing and used to hate JavaScript, that's really nonsense if you actually want to be a UI developer (and not just some side afterthought).
State management and the custom capabilities when you need them are amazing. I wasted a lot of my time writing tons of Swing code. Sorry, but the modern front end experience is much more enjoyable and productive. If you want "native widgets" I get the complaint, but most platforms seem to be less interested in consistent experiences these days.
The biggest issue with Swing is just bad defaults. Except for NeWS, Sun wasn't really into the desktop business.
Although I haven't used it for more than a decade, I still have some fondness for Java. I like Workflowy but am not crazy about it being in the browser. I contemplated writing my own outliner and Java + Swing is one combination I'm thinking about.
JS devs just rediscovered MVC with some added immutability and that’s all. Hardly more productive. Also, I don’t see your point on custom capabilities - please add a slight modification to the date picker widget. Oh, you have to reimplement the whole thing with some insane number of divs, while you can trivially override certain parts of it in most desktop libs.
The other reason is that you care about resource usage. Web apps use more battery, bandwidth, and CPU.
https://blogs.gnome.org/christopherdavis/2020/11/19/glade-no...
Thankfully KDE is still around, but many seem to not appreciate the UI design tooling provided by Qt, because $$$$.
So I rather waste my time on Earth on platforms that value good UI/UX tooling.
Nobody is particularly happy about having to edit the XML directly but it's the best option right now until the new tools stabilize.
You are proving GP's point for him:
> So I rather waste my time on Earth on platforms that value good UI/UX tooling.
The fact that that Glade was deprecated without a replacement being ready means exactly that GNOME does not "value good UI/UX tooling".
Edit: Just to be clear here, in my opinion the new tools will likely end up being a large improvement on Glade. Glade is a pretty old application that by design does a number of weird things that don't match current best practices, you can see some of them if you read the blog post that was posted above.
That's a false dichotomy. It could be (and I believe is) that things are a tradeoff. They obviously value good tooling (what developer doesn't? and look at the docs), but they value other things too and had to make a decision. With limited resources you can't do it all.
It's great that GTK4 has decided to commit to API stability, but, at this point, it may be too little, too late as far as the project's reputation among many developers is concerned. Having to lose a venerable tool like Glade to get to the API-stable version doesn't exactly take the edge off.
That is certainly not a solution, you just postpone the problem.
The real solution would be the Gtk4 to be 100% backwards compatible at both the API and ABI level with Gtk3 and similarly with Gtk5, Gtk6, etc.
Otherwise you're just subscribing to wasting your time - it might be now or it might be 5 years from now, it doesn't matter however as it will happen unless the Gtk developers finally decide to stop breaking their library every few years.
(of course don't get me wrong, it is their library and they can do whatever they please with it, they are giving it for free and they are not beholden to anyone - however that doesn't mean others like to have their code broken and waste time that they could use to improve their applications instead)
And yeah, you're right, the GTK team isn't beholden to anyone. But... GUI code is expensive to write and expensive to maintain. So a GUI toolkit can have an outsize impact on the health of projects that use it. There's value in talking about things like this publicly, so that anyone who's shopping for a GUI toolkit can have a better understanding of what they might be getting into.
Of course yes, the next best thing wrt. backwards compatibility is at least not breaking what works - but IMO that is a waste of time for both the Gtk developers (sure, it'd be self inflicted, but still) who would need to support two (or three or four or however many times they decide to break their own APIs) libraries that do essentially the same thing in different ways, and for the developers who at the end of the day will most likely need to move on to the next version at some point to gain access to new features that they may need - so they'll spend that porting time anyway.
> And yeah, you're right, the GTK team isn't beholden to anyone. But... GUI code is expensive to write and expensive to maintain. So a GUI toolkit can have an outsize impact on the health of projects that use it. There's value in talking about things like this publicly, so that anyone who's shopping for a GUI toolkit can have a better understanding of what they might be getting into.
Indeed and this is why i mention my issues with backwards compatibility whenever i see it being relevant.
I do believe the Gtk developers are free to do whatever they want as they are not beholden to my -or anyone else's- wishes for stability, especially when they give out such an otherwise high quality library for free. However that is from their perspective.
From the library users' (that is the developers who use the library) perspective however there are additional issues, like all the time you spent learning the library (breaking the API invalidates your own knowledge which is something that is also important - unless you plan to somehow live forever it makes sense to want to avoid this sort of "knowledge churn" :-P) and writing the code that uses it (important especially for framework-style libraries like Gtk that put their tendrils everywhere in your application). And even if someone believes (wrongly, IMO) that commercial developers can afford all that time, it still is an issue with FLOSS since the vast majority of which is developed during its developers' free time: that time would have better been used to improve the applications instead of keeping up with their dependencies' breakage (e.g. XFCE or... Gimp :-P).
And of course from the end users' perspective it also means that even if the developers decide to drop a program, they can keep using it for a long time without having to worry about the libraries their program depends on getting stale (since they are linked dynamically), not supporting new features (like, e.g. Wayland - AFAIK Gtk2 apps do not support it natively and chances are if a new display server is made Gtk3 apps wont support it either) or having unfixable security issues (for the applications where that makes sense at least).
But yeah, Gtk developers - or any library developers - do not need to care about all of that nor they have to really. As you wrote, it is the developers who decide or not to use a library that care about such things mostly.
Sadly at last on Linux there aren't that many choices: of the "mainstream" toolkits only Gtk and Qt exist. Gtk is, well, Gtk and Qt cannot provide "perfect" ABI compatibility even if they wanted to because of C++ (there are some hacks that could be made but i am not aware of any project doing such a thing - i think only Haiku does something similar with proxy libraries that forward the GCC C++ 2.95 calls to modern GCC C++ calls for BeOS compatibility). But Qt is also a different beast, they are a middleware company with different priorities, the people that pay money on it (and thus affect these priorities) do not care much about providing a stable platform and can affort to waste time on upgrades. From other toolkits there is also Motif but that fell out of favor and got opensourced way too late to make much of a difference - its API/ABI is stable though and has been stable for decades, but that means nothing when barely anyone uses it or develops for it.
Personally i use Lazarus and LCL. LCL uses a variety of backends, kinda like wxWidgets, but unlike wxWidgets it doesn't break its API. This pushes the issue of keeping up to date to the LCL developers (who could have spent their time in fixing LCL's other issues - of which are many - instead) but that is how things are.
I think Java and SWT might be another stable solution for a native UI, AFAIK this never broke backwards compatibility either... or at least it never did back when i looked into it several years ago. Looking at some examples in their site, several of them seem to be somewhat old so it probably is stable (isn't it great how when you do not break your API left and right you get to also get time to build better documentation that you don't have to invalidate it after a while?)
That does not really matter in practice though. I ship a Qt app as AppImage, it works fine from CentOS 7 to the very latest ArchLinux. I just ship libc++ along with it - which is the same that I have to do in Windows anyways.
A trivial example on Windows would be how Win32 applications get to use the Win+; emoji popup even if they were made before Windows even got that feature, or how even classic VB applications can be made to run in HiDPI mode by ticking a shortcut checkbox despite being written decades before HiDPI was even a thing (assuming they use twip instead of pixel coordinates at least).
Or on Linux, how some old games made for it need their bundled SDL removed so that the games can use the system-provided version because the old version tried to use OSS or whatever was common at the time the game as written and the new version can use ALSA or even Pulse that didn't even exist in older times. And i remember reading on twitter about some distros planning to provide the SDL1-to-SDL2 wrapper as an option instead of the real SDL1 because it provides better compatibility with some modern window managers... and Wayland (that SDL1 doesn't support at all but the API doesn't really make a difference and could work perfectly fine with Wayland).
> which is the same that I have to do in Windows anyways.
Windows comes with WAY more functionality out of the box so that applications do not have to rely as much in their own libraries and can rely on the OS to provide and keep functionality up to date. Of course applications can ignore that, but they just do not get those new features and fixes.
The recent Visual C++ runtimes not being part of Windows is a baffling and really stupid decision though. I am certain it has more to do with internal politics and feuds between WinDiv and DevDiv than something practical.
eh, I really really disagree with this. In my experience more often than not this kind of changes breaks the app in various ways. What if the app was using that shortcut for something else ? Now it's broken and can't be used anymore. Likewise for the hidpi thing that windows does, it's terrible - running the app at original resolution and applying a 2x nearest neighbor filter to the whole window would be better than that mess of "crisp" text with upscaled pixmaps that were never made for this resolution.
> Or on Linux, how some old games made for it need their bundled SDL removed so that the games can use the system-provided version because the old version tried to use OSS or whatever was common at the time the game as written and the new version can use ALSA or even Pulse that didn't even exist in older times. And i remember reading on twitter about some distros planning to provide the SDL1-to-SDL2 wrapper as an option instead of the real SDL1 because it provides better compatibility with some modern window managers... and Wayland (that SDL1 doesn't support at all but the API doesn't really make a difference and could work perfectly fine with Wayland).
I strongly believe that for old games / software it's better to use a VM / emulator for hardware of that game's era.
What did break?
> What if the app was using that shortcut for something else ? Now it's broken and can't be used anymore.
Win+; is very unlikely to be used by anything and it is handled by the window proc of the EDIT window class, meaning that other stuff (e.g. accelerators, which are used to implement shortcuts) get to take first dibs. So if an application was using that shortcut it wouldn't reach the EDIT window proc anyway. It isn't any different than an application replacing the right click menu of a text field - the applications that do not do that (ie. most applications) get the new entries introduced in (IIRC) Vista about Unicode characters, etc and the (few) applications that replace it just do not get these options but their menus keep working.
> Likewise for the hidpi thing that windows does, it's terrible - running the app at original resolution and applying a 2x nearest neighbor filter to the whole window would be better than that mess of "crisp" text with upscaled pixmaps that were never made for this resolution.
Note that this is what Windows does by default, what i describe is something you can do manually.
But personally i disagree, i'd rather have crisp text (which is what the majority of a window contains) and a few upscaled bitmaps than lowres everything.
> I strongly believe that for old games / software it's better to use a VM / emulator for hardware of that game's era.
I play a ton of old games and i completely disagree with this. VMs pretty much never work properly and have all tons of issues. Emulators are very slow. And above all, running games on modern hardware allows for higher resolution and maxing out graphics that was often impossible in original hardware (e.g. forcing 32bit color, antialiasing, anisotropic filtering, etc). Not to mention the potential for mods that improve parts of the game which would be impossible on original hardware.
Anyway who cares, maybe GTK4 is good and new GTK threads will not be full of people talking about how bad it was. But why not move the tools together with the rest? I know, it's open source, lack of maintainers, but I wouldn't dare to declare my toolkit stable until basic tools work. Qt is also guilty of doing that in some ways but at least the previous version is still production ready and they move really fast.
I don't know I'll ever get over my irrational anger about how they handle(d) GTK.
However it is like the sibling comments mention, this hasn't been properly managed as message to the UI/UX community.
So when someone used to Forms, WPF/Blend, Qt Designer, Interface Builder, Delphi, C++ Builder, Swift UI, Flutter, JetPack Composer,... sees blogs and tutorials where .ui files are written by hand and direct use of GtkBuilder is praised, eventually all interest is gone.
Anyway, thanks for the link and for jumping in
Also, Glade is not really even used by GNOME designers that much, what they do is make mockups in some other tool (usually Inkscape) and then have the developers implement it. I don't know about other GTK based desktops, though I think some Elementary developers are working on this: https://github.com/akiraux/Akira
I wouldn't mind editing a concise XML dialect (XML really doesn't have to be monstrous, a dialect it can be designed with humans in mind). A visual designer producing XML files as its output doesn't actually solve the problem. VisualStudio's developer experience (where you can change everything on the fly, go to the relevant piece of code in a click or two, refactor something and get it also changed in the designer etc) feels really seamless and fluent while PyQt with PyCharm+QtDesigner seems nice but not nearly like that. It seems to me nothing can be considered a serious and worthy improvement until we have an actual integrated visual RAD IDE. I would immediately buy the paid version of PyCharm (I'm using the community edition if they built a good and well-integrated visual designer in it, for whatever a desktop toolkit they prefer).
When a company rolls out Linux desktops it's a news story because it's unusual. There are killer apps for Windows and Mac. How about Linux? What application is going to have my uncle calling me asking which Linux machine he should buy?
I can only attribute this to marketing as I can see no single humble thing (except lack of MS Office (which is being phased out by MS favouring Office 365), MS VS, Adobe CS and the NumLock bug) in which Linux actually is worse than Windows. And I can see many in which it is better. Even the very user experience is better - Linux feels faster, is more reliable and can be customized to whatever you want (if you do) with relative ease. Lack of some specific apps is not a flaw of Linux. Whoever doesn't need these specific apps can use Linux comfortably.
> What application is going to have my uncle calling me asking which Linux machine he should buy?
What apps does he need? If he doesn't need the apps I've mentioned I would insist he uses Linux if I were you - so I won't have to fix it next time it breaks, gets slow or infected by something nasty.
> When a company rolls out Linux desktops it's a news story because it's unusual.
I have alone rolled out (and never wanted that to be in any news) Linux in a number of companies (~20 desktops/laptops, Browser+Office+Skype+Samba+RDP+OpenVPN workflow, one also needed a Windows GUI CRM client which I configured to run with Wine flawlessly). This worked fast and reliably forever ever since. I wouldn't, however, agree (unless paid extremely well) to become in charge of a Windows system of the same or bigger size as that would mean much more work regularly.
At DebConf 2014
So I really have zero idea of what problems might he mean. Besides lack of native Photoshop and Visual Studio the only thing which always annoyed me in desktop Linux were NumLock quirks. There was also a problem with games but apparently it's not the case any more.
Edit: Fair warning, desktop development code is _interpreted_ by the VM when doing debug builds, so that you can have hot reloading, which is great. But it may seem like your app is slow until you do a release build. Though it seems obvious in retrospect, it took me by surprise at first.
Check out Lazarus: http://lazarus-ide.org
It is WAY easier than WinForms. WinForms' VS "integration" feels as if they started with what Delphi 1 could do back in 1995 or so, implemented most of it and then decided that is enough.
Lazarus' GUI tools are way above and beyond anything WinForms can do and the underlying LCL is crossplatform using native widgets wherever possible with backends for Win32, Gtk1/Gtk2/Gtk3 (though Gtk2 might be the best ATM), Qt4/Qt5, Cocoa and a few others (Carbon, fpGUI and some Amiga toolkit).
Here is a video from 3 years ago where i make a simple sliding image puzzle game under Linux using it:
https://www.youtube.com/watch?v=s_01Xhd2EJM
Also here is another video from 6 years ago where i make a 2D tilemap editor in Windows:
https://www.youtube.com/watch?v=_3JgeIUo1X0
And another video from ~10 years ago making a doodle app:
I adore people who code Lazarus (e.g. Double Commander authors - they have been doing an amazing job with visible progress and persistence all these years) though. Perhaps I'm going to dedicate some time to learn Pascal once, just for this. It would be easier if they had a seamlessly-compatible C++ version at least (like Delphi had).
As for a C++ version, it would be useful (though i find Free Pascal a better language overall, despite its warts - the only thing i wish it had from C++ was 'const' and slightly more powerful generics, but both aren't that big of an issue and generics are improving anyway) but VERY difficult to do as i wrote some time ago here [0] and here [1] where i went into more details about the language side of things (C++ Builder has extended C++ to allow for Object Pascal-isms because VCL itself is written, like LCL/FCL, in Pascal, which for Borland was possible because they made both the Pascal and the C++ compilers).
[0] https://news.ycombinator.com/item?id=15893362
[1] https://news.ycombinator.com/item?id=19882489 (note that the discussion was originally about using LCL from C++ so i also mention the alternatives - and how not having the rest of the IDE would end up with a worse wxWidgets since LCL isn't really designed to be used purely via code)