The fact remains that proprietary software seem to be a license to print money, and with the ability to print money is the ability to entrench said software, such as heavy investment in software development.
This is a uphill battle for open source software, but it seems that open source software tend to keep improving in the long run.
It seems like proprietary software has a big advantage when there's still lots of room for improvement, so that investment in further development pays off.
However, in some cases, there's little room for real improvement, and the thing becomes a "solved problem" for the most part. At this point, the proprietary companies then start enshittifying the software (look at Photoshop, now a cloud-based program) to try to extract more money from users, and to keep users on the upgrade treadmill. Part of this is probably from the way corporate politics work: when you're a manager with a team in place, you need something to keep that team busy, to justify your team's continued employment to upper management, so when you run out of useful improvements to make, you invent less-than-useful "improvements" (e.g., ugly new UIs).
This is where FOSS seems to be able to do well: it doesn't need to waste resources on useless improvements (we'll ignore GNOME for a moment as an exception), and can just focus on delivering the necessary functionality. Once that's done, it can just go into maintenance mode and people can move on to other projects. Until then, it can continue to improve and attract users to switch from the enshittifying proprietary stuff.
GNOME I'll heartily agree on. But I've never liked GNOME myself (v1 seemed OK though) and have always criticized that project. I've always been a KDE fan, though admittedly they've had some similar problems and have handled some major changes rather poorly (esp. 4.0). Really, the desktop environments are one place where FOSS hasn't really done that well, frequently re-inventing the wheel for questionable reasons, or adopting questionable new design philosophies. At least there's a fair amount of competition in the space, so if one project rubs you the wrong way, you can try another; this proliferation of competitors also shows just how much disagreement there is in the community on this particular matter.
I really don't know enough about the audio stack changes; I can only guess that they found big problems with older solutions there which required major architectural changes, esp. for certain high-performance applications.
It is to be expected that there is a proliferation of different UIs if there is the possibility of making different UIs run on the same OS. The reason is that everybody has a different workflow, different aesthetic preferences, different ways of doing things (e.g.: leaning more toward keyboard, mouse, touchpad, touchscreen). The best thing I remember in this space were the dozen or so X11 windows managers of the 90s. The worst one is the single UIs for Windows and Macs. There are some ways to customize them but not as heavily as it is possible with Linux.
Wayland seems to restrict what's possible to customize but I might be wrong because I have no direct experience. I'm still of X11 because of an old NVIDIA card and frankly I could stay on X11 forever. I know that I'll have to switch sooner or later because of software compatibility. I'd hate to have to buy a new laptop only to be able to run Wayland. It's still good enough to work with me for my customers.
Which is why Windows and Mac still get native UIs for many desktop products, while Linux if a product actually targets it, gets Electron.
Don't know much about the architecture about wayland but I think grahic driver handling changed in wayland too.
Native widget libraries is whatever the OS vendor puts on the SDK, and ships on the installers for their compilers.
The large majority of Electron apps that happen to land on Mac and Windows land, usually come from GNU/Linux shops, that also feel like targeting other operating systems, and since that is the solution for GNU/Linux, they dump it into everyone else.
In the process they help Google take over the browser ecosystem, and then talk about how M$ used to be all over the place with IE.
But meanwhile, the OS vendors got creative and pumped out a bunch of new, _more modern_ libraries, which have abilities that the old, "system" ones do not have. You want Acrylic design on Windows? Better be satisfied with WinUI -- which, in v3 is the recommended way to write native applications by the platform owner, and which is decoupled from system releases and from Windows SDK.
Electron apps are coming from any shop, that want to throw together some installable, locally running app and figured out, that paying HTML+CSS devs is cheaper, than paying C++ (or ObjC) ones. Having shorter development time is also something positive. It has nothing to do with Linux shops; there are Electron apps, that could be running on Linux if there was a will, but aren't (Whatsapp), or almost-electron-but-edge_webview-instead (Teams).
Doubled down at .NET Conf 2024 during the last week.
Regardless of the GUI framework from Apple, and Microsoft, those are managed bindings to the underlying native APIS (Win32 and Cocoa), which is why they also expose handles to do lowlevel stuff if one so desires, coding like 2000.
Webviews are a different matter, as they don't require shipping Chrome with the application.
It definelty has a lot to do with Linux shops, as they can't be bothered to support GNOME, KDE, Sway, XFCE, or whatever everyone else uses, so Electron it is.
And then they want Mac OS and Windows customers as well.
So maybe Microsoft should update their own guides then: https://learn.microsoft.com/en-us/windows/apps/get-started/?...
| Many apps for Windows are written using Win32, Windows Forms, or UWP. Each of these frameworks is supported and will continue to receive bug, reliability, and security fixes, but varying levels of investment for new features and styles. For more information about these app types see the following tabs.
Yes, in Build 2024, there was backpedaling back to WPF, since WinUI is in terrible shape.
> Webviews are a different matter, as they don't require shipping Chrome with the application.
Electron also doesn't ship Chrome with application; it ships the rendering engine (blink) and javascript engine (v8). Which is exactly the same, as edge webview. Unlike edge webview, they are not dragged in by Microsoft Edge, the browser (so you get it whether you have an use for it or not).
> It definelty has a lot to do with Linux shops, as they can't be bothered to support GNOME, KDE, Sway, XFCE, or whatever everyone else uses, so Electron it is.
So how do you imagine such support would look like? I know a thing or two about development on linux, but I have no idea what would supporting XFCE or Sway explicitly in an app would involve. Unless you hyperbolize, right?
The only real decision would be choosing Gtk or Qt; the desktop environments have no real impact on your app and with Qt, you are getting the multiplatform support, that is supposedly behind the electron usage of those linux shops.
Also, what exactly are those linux shops, that target multiplatform by using electron? Is it like Cisco? Or Meta? Maybe Bitwarden? Discord? Figma? Microsoft (skype, vscode)?
>The worst one is the single UIs for Windows and Macs. There are some ways to customize them but not as heavily as it is possible with Linux.
You're right, and I forgot to touch on this before. Just look at Windows for instance: it's not a monolithic thing, because it's changed over time. Lots of Windows users criticize the new(er) versions, and say that Win7 was the peak of the Windows UI. Lots of people absolutely hated the new "Metro* UI in Win8. So clearly there's no agreement there either, so how could there possibly be broad agreement in Linux?
Why when I have my file manager view of a directory open do I need to open it again inside the application to save a file there?
This works fine on macOS in anything that supports it. For example I can drag assets in and layers out of Pixelmator without any issue, drag emails to the desktop or a Finder to save them, etc.
> mostly you can't use overlapping windows because of raise on click
Which can be disabled if it makes sense for that app. What use case are you thinking of here?
> Why when I have my file manager view of a directory open do I need to open it again inside the application to save a file there?
You can drag a directory into the save dialog to jump to it (Windows gets this wrong), and the title heading of an open Finder window is itself draggable, you don't have to exit the directory if you already have it open.
Alternatively Opt-Cmd-C to copy current directory and then paste it into the save location dialog, or Cmd-Shift-G and paste in the location.
My use case is I have 2 applications that I want to drag something between, and the windows overlap
Can you create a new document and then drag a proxy icon to the Finder on MacOS?
This should work for most use cases. If you can see the window for the target app even if you can’t see the drop destination, holding on that window briefly while dragging should raise it to the front (my testing says about 2 seconds). Alternatively (or if you can’t see the target window), the various expose gestures and buttons work during a drag operation. For example on a MacBook you can start dragging from one window, swipe up with your other fingers to reveal all applications or swipe down to reveal just the windows from the current app, and you can drag to the window for your target. From there you can hover on the target and expose will switch to the chosen window after a moment, or you can perform the opposite swipe action while hovering over your target window to raise it to the front.
As for the new document thing if you mean to save a document for the first time by dragging it to a finder window, as far as I can tell you can’t do that. You can drag the finder window to the save dialog but not the other way around.