[pjmlp]

Nah, Android, macOS and Windows are doing just fine, it is the classical UNIX desktop that cannot get their act together.

The existing issues aren't technical, rather political, like the WinRT crusade that ended up bombing and now we have plenty of GUI toolkits to chose from on Windows.

Swift, Java, Kotlin and the .NET languages are more than high level enough.

[raxxorrax]

MS .NET burned me hard with WPF. After finally looking into it, it more or less was cancelled for greener pastures.

I don't think the newer Windows UI-Frameworks are loved that much and UWP is not really convincing for desktop applications. Just too much hassle for too little gain and the threat of vendor lock-in.

[spaetzleesser]

“I don't think the newer Windows UI-Frameworks are loved that much and UWP is not really convincing for desktop applications. Just too much hassle for too little gain and the threat of vendor lock-in.”

I used to be a desktop dev but after the mess with Winforms, WinRT, WPF, Silverlight, UWP and WinUI I would never bet again on an MS GUI framework. Most likely it will be abandoned soon and put into maintenance mode.

I still don’t understand why they constantly crank out new frameworks that do basically the same instead of evolving an existing one like WPF. The cost of enveloping, testing and documenting these frameworks must be enormous.

[projektfu]

I briefly looked into UWP when it was being promoted with such fanfare, and the only thing I could see were the gross incompatibilities with WPF, basically requiring you to maintain two guis if you wanted to use the app store and support two versions of Windows, let alone Xamarin. Then they basically dumped the app store model they were going to use and started allowing anything on there. It's https://xkcd.com/927/ all over again, except in this case it's all just Microsoft!

[spaetzleesser]

I looked at UWP when it came out. The only thing I found was that it was different but I didn’t see any improvements over WPF. I still don’t understand why they wouldn’t make it compatible with WPF.

[burnte]

Years and years ago I was offered a job as an MS tech evangelist for the purpose of pushing Mozilla to use "new" MS technologies coming in what would eventually be Vista. I had a decent repuation in the Mozilla community, and I've always been a good communicator. The problem was some of the things they wanted me to push I knew would never get out the door.

There were three big issues although I can only remember two, which were WPF and WinFS. I said flat out WinFS isn't going to make the cut, the third feature wouldn't, and even if WPF did make it into the final build, Mozilla doesn't have the resources or desire to move Mozilla to WPF, especially since mozilla is a cross platform app. "Yes, we know, but utilizing WPF will make it easier to develop on Windows!" I pointed out while that's good for MS, it provides no benefit to Mozilla's non-windows users, and Mozilla would never do it. And WinFS isn't working at all, so why would they spend even a moment trying to figure out how the new FS would benefit an application?

I think the third leg was Palladium. "It'll make online banking so secure!" I remember commenting that with all the flack it was getting, it'll have no buy in from anyone else, and flop.

I don't think compulsive "tell it how it is" people are good for evangelist roles. :D

[pjmlp]

It is still actively developed, even if it doesn't get the same WinUI love.

https://github.com/dotnet/wpf

But yeah, having ramped down the team while beting the farm into WinRT wasn't the best idea.

Still, just like VB 6 in Windows 10, WPF will be around for decades to come and it isn't like there are revolutionary UI concepts to implement.

[EllieEffingMae]

Could you expand on this more? I don't know a lot about GUI programming, but I'd be interested in learning what the current failings are within the desktop space.

[AussieWog93]

Specifically for Linux, there is no ubiquitous standard with decent performance and a predictable look such as win32 or Cocoa.

Instead, developers rely on toolkits such as Qt or GTK to ensure compatibility, which are usually either bloated or ugly.

[lavabiopsy]

That's true for "Linux", but "Linux" on its own is not a desktop OS. If you target KDE then Qt is the ubiquitous standard with decent performance and a predictable look, same goes for GNOME with GTK. Both of them I would say are less "bloated" than win32 or cocoa at this point. And I don't have any comment on whether it's "ugly" or not :)

[jcelerier]

If you think that Qt is more bloated than Cocoa I don't know what to say. That objc runtime is so heavy and slow, good luck making it run on microcontrollers

[klodolph]

Not sure what you’re talking about. ObjC runtime is fairly small. The basics of what you need for ObjC is just objc_msgSend, which is basically a fancy hash lookup written in assembly language. If you want ObjC on a microcontroller, you’d want to port this function to your target architecture. There are a few other components you “need” but objc_msgSend is the key one.

You’d probably also want some form of malloc(), but that’s completely optional. There’s nothing in Objective C that says you have to allocate memory dynamically, or that you have to do it with malloc.

ObjC runtime has grown somewhat to include more features, but you don’t need all those runtime features if you want to run your code on a microcontroller. Just like you don’t need glibc if you want to run C. There is more than one runtime for Objective C you can choose, just like there is more than one runtime for C.

[smaudet]

It's probably exactly that runtime...desk devs have forgot that embedded is tiny, megs not gigs of memory, so not one but 2-3 orders of magnitude smaller.

You can have all the 'simple' calls you like but if you need to malloc half a gig of ram just to get started...that is heavy and bloated.

Also you say 'architecture' but unless you are talking a battery hungry cellphone you are probably talking 16 or 32 bit proc not 64, which means potentially massive increase in the size of code to be generated since you lose certain instruction sets. I don't know realistically what Obj C uses in the osx cpu architecture but I'm almost certain it's not going to be as simple as just retargeting your compiler...

Not saying it can't be done but take even the new arm laptops from Apple - that's a significant hardware investment on top of a bunch of software tricks, not just a casual retargetting that can be portably moved to other low power systems.

[klodolph]

> I don't know realistically what Obj C uses in the osx cpu architecture but I'm almost certain it's not going to be as simple as just retargeting your compiler...

Objective C is in mainline GCC. You retarget your compiler and port the runtime. As far as I know, any target with GCC support can run Objective C, given a runtime. The important parts of the runtime require kilobytes, not megabytes, of space.

Remember that Objective C was originally a very thin layer on top of C. You take all the [method calls] and replace them with calls to objc_msgSend(). The overhead is fairly small— your object instances need the “isa” pointer, which is basically just a pointer to a vtable. The objc_msgSend() function reads the vtable and forwards method calls to the correct implementation.

My experience is that Objective C binaries typically have a much smaller footprint than C++ binaries. That’s obviously not some kind of rule, but it reflects idiomatic usage of Objective C. In C++ you'd use a std::vector<T> which is a templated class, which gets instantiated for every different T you use in your program. In Objective C, you’d use NSArray, which is monomorphic.

This all should be completely unsurprising—since Objective C first appeared in the 1980s, it’s no surprise that it doesn’t need much memory.

[AussieWog93]

I don't understand the technical reasons behind it, but for whatever reason doing something like resizing a Window for any non-trivial GUI seems to cause the repaints to drop down to 15-20Hz in Qt and spike the CPU usage massively. The same issue doesn't occur with Win32 or Cocoa.

[smaudet]

You probably don't have graphics drivers installed...

IIRC the fancier toolkits (Qt, GTK) do widget accell with either mandatory blitting and/or 3d (OpenGL/DirectX) (Other frameworks like WPF and Cocoa are notorious for this too).

There are, or used to be, frameworks that were not gpu dependent.

I've never hear nor seen these massive drops you claim to, so either you are running 20 year old hardware or your graphics aren't on, or you have some other hardware issue...

[jcelerier]

That's interesting, I have the exact opposite experience, I used to have a MBP dual booted with ArchLinux, and resizing windows was incredibly much smoother on Linux with either Dolphin, Nautilus or Thunar, than with Finder on the Mac which looked like it only drawed 1/5th of the frames compared to linux.

[PaulDavisThe1st]

I do understand the technical reasons behind it, and it has nothing to do with bloat. It mostly has to do with mapping a cross-platform (i.e. generic) window abstraction onto a specific OS-provided drawing/event/windowing API.

[AussieWog93]

I built my own cross-platform windowing/event API from scratch at my last job, based on top of win32 on Windows, Cocoa on Mac and Qt on Linux. The only platform where there was any noticeable performance drops at all was Linux, because it relied on Qt.

When I said "I don't understand the technical reasons behind it", I didn't mean "I don't understand how to abstract OS-native APIs". I meant "I don't understand how a team of intelligent people managed to fuck things up this badly".

[andrekandre]

for "microcontroller class" whats the perofrmance level your looking at, something akin to a 68030 or so?

[otabdeveloper4]

> the classical UNIX desktop

CDE? That hasn't existed for decades.

[pabs3]

CDE exists, is open source and has had commits only a month ago:

https://sourceforge.net/projects/cdesktopenv/ https://sourceforge.net/p/cdesktopenv/activity/ https://sourceforge.net/p/cdesktopenv/code/ci/master/log/

[lavabiopsy]

If you actually look at the commits, it's mostly fixing the build and tweaking it to work on modern platforms. My personal opinion after trying it, I would not suggest use of Motif or CDE for anything besides nostalgia, it has some serious usability issues. But if you enjoy it, more power to you.

[pjmlp]

Who cares about CDE, the classical UNIX desktop, as in the way that BSDs and GNU/Linux keep pushing for the old days with their fragmented stacks.

macOS, although a UNIX, follows the same ideolagy as NeXTSTEP, where UNIX compatibility was a means to bring software into the platform, and that was about it, GUI software was to be fully taken advantage of Objective-C Frameworks.

[otabdeveloper4]

My point is that "classical UNIX desktop" doesn't exist.

(Hell, even UNIX itself doesn't exist anymore. Linux and FreeBSD is its own thing now.)

[pjmlp]

It sure does exist, a large majority of Linux and FreeBSD users pretend they are still living in the 80's with vt100 and an improved twm.

As proven by https://news.ycombinator.com/item?id=28437173 making to the first page today.

[LargoLasskhyfv]

Imagine the BLING if you combined that with this:

[X] http://jdebp.info/Softwares/nosh/user-vt-screenshots.html

[otabdeveloper4]

> with vt100 and an improved twm

That's in no way a "classic Unix desktop". This is hipster nostalgia, like those indie "retro" pixel art videogames.

[the_only_law]

What is a classic Unix desktop then? Workstation running CDE/Motif?

[5e92cb50239222b]

How do you find time for work? I see your comments shitting on everything that's not Windows pretty much everywhere.

[pjmlp]

https://xkcd.com/303/

You missed my praises for Apple and Google platforms.