6 ms·

Windows (MS) and OSX (Apple) need to agree on a GUI interoperability API. Either hammer something out, or adopt one/more of the OSS GUI framework specification

Windows (MS) and OSX (Apple) need to agree on a GUI interoperability API. Either hammer something out, or adopt one/more of the OSS GUI framework specifications from QT and GTK. It MUST be open spec. It MUST be free for all/any to implement. It MUST either be included or be in the primary vendor (MS, Apple, distro) software center. A simple Hello World, click OK to exit the program application should be able to be cross-compiled for any platform, and the resulting binary MUST NOT require including / embedding DLL / library hell like everything today does. It SHOULD be a small entirely dynamic program; possibly a few hundred kilobytes at most but even that seems too large. After all, it would mostly be the basic boilerplate of setting up memory, calling the system library loader, and linking in the shared libraries.

nasretdinov 2y ago
I think OpenStep actually had something like this in mind and had a Windows implementation too. It's apparently even used in Apple Windows apps like Safari, but of course it must not be complete enough to be able to fully replace native Windows API, and the incentive isn't there either.
- linguae 2y ago
  There was an implementation of OpenStep for Windows named OpenStep Enterprise: https://forum.winworldpc.com/discussion/11422/openstep-for-windows-nt https://forum.winworldpc.com/discussion/11422/openstep-for-w... It even survived Apple's purchase of NeXT, where the OpenStep API was renamed Yellow Box. There was a port of Yellow Box to Windows: https://www.betaarchive.com/forum/viewtopic.php?t=29049 https://www.betaarchive.com/forum/viewtopic.php?t=29049 In both OpenStep Enterprise and Yellow Box for Windows, while the UI elements still have some NeXT-isms, it's not terribly out of place, either. However, this got scrapped sometime when Apple abandoned Rhapsody (which had PowerPC and x86 versions) in favor of Mac OS X (which was originally only available for PowerPC until the Intel switch in 2006, though Apple maintained an x86 version internally during the PowerPC years). During the transition from Rhapsody to Mac OS X, Yellow Box was renamed Cocoa.
  - WillAdams 2y ago
    The impetus here is that Adobe had initially promised a free, then low-cost license for Display PostScript --- when that was pulled, Apple had to come up with an alternative --- that and the fact that all the major app vendors announced that they weren't willing to do top--to-bottom re-writes using the NeXT frameworks (there was even a rumor that "Yellow Box" was named for the sake of Bill Gates' comment, "Develop for NeXTstep? I'll piss on it.") So, Apple, led by Mike Paquette and many other talented folks from NeXT created Quartz (née Display PDF) and Carbon and instead of a consistent environment with a single API, we got an assemblage of technologies which had a Calculator app written in Java which took _forever_ to load, a Finder written in Carbon instead of Workplace.app, and icons cluttering the desktop and a Sidebar instead of a Shelf, and a bunch of Carbon apps.
deleted 2y ago
[deleted]
criddell 2y ago
> need to agree on a GUI interoperability I hope they don’t. I like that the different platforms I use feel and look different. In fact, I wish there was more variety. I wish there were still Atari, and Amiga, and BeOS, Tandy, and all the other interesting platforms competing for users with different ideas of how computers should work.
- linguae 2y ago
  I wonder how possible it is to design a cross-platform GUI framework that not only uses the native UI widgets of each underlying platform, but also respects each platform's human interface guidelines. I'd imagine this would be very hard work, especially the part about respecting each platform's HIG, but the increased power of AI tools could potentially make this task easier. Such a framework could potentially be an appealing alternative to Electron for making cross-platform applications, with the benefit of conformity to each platform's HIG.
  - swatcoder 2y ago
    There have been many frameworks that offered this and some still do. But it comes at the direct expense of design discipline, branding, and user experience optimization -- all of which have been elevetated to high concern over the 15 years or so. Cross-platform "Native look and feel" currently works for some no-nonsense professional utitlies and hobby tools, but mostly makes software that's hard to sell, document, or support. Most have just opted for common widget libraries instead, and frameworks have stepped up by providing rich libraries of such widgets and prioritizing features for customizing or complementing them even further.
  - criddell 2y ago
    I’ve been thinking more lately about a library which defines an interface for GUI elements, and then leaves implementing that up to you. Something like MVC (or some other design pattern) where the view part is an interface definition.
  - torstenvl 2y ago
    wxWidgets does this pretty well, e.g., wxSingleChoiceDialog has "OK" "Cancel" on Windows but "Cancel" "OK" on Linux/GTK.
torstenvl 2y ago
This exists. It's called wxWidgets. It's an API shim over native components plus some convenience classes for abstracting out OS-specific functionality. It's LGPL with static linking exception, so no DLL hell. I'm not quite sure what you mean by open spec, but it's just an API not a protocol, and uhhhh.... https://caselaw.findlaw.com/court/us-supreme-court/18-956.html https://caselaw.findlaw.com/court/us-supreme-court/18-956.ht...
- mjevans 2y ago
  The library exists, BUT it is NOT shipped natively and NOT (AFAIK) something which trying to run a random downloaded utility app will trigger the system library loader prompting for the 'common wxWidgets runtime, for free, codesigned by Microsoft' download and install from the store to run the app.
  - torstenvl 2y ago
    Your previous post said > the resulting binary MUST NOT require including / embedding DLL / library hell like everything today does If there's no DLL required then why does it matter if the DLL is automatically downloaded from the Microsoft store? DLLs are not useful for statically linked binaries.
userbinator 2y ago
That's called WINE. ;-) Win32 Hello World messagebox is a few hundred bytes.
cxr 2y ago
> Windows (MS) and OSX (Apple) need to agree on a GUI interoperability API. Either hammer something out, or adopt one/more of the OSS GUI framework specifications from QT and GTK. I've been saying for a while now that the open source world would have benefited if more effort than what went into GNUStep had been focused on copying Cocoa to the point that it rather than GTK or Qt had been the toolkit of choice for the Linux Desktop. Especially when there was a major infusion of interest circa 2010 of folks adopting the MacBook Pro as the developer machine of choice. I think it's still doable. And I mean down to looks, too, and not just API feel. Aqua from the same time period (Snow Leopard through Mountain Lion era) is the closest thing I can think of to timeless visual design. It's true that if everyone just made Cocoa apps that looked like they were created with Mac OS in mind it would look out of place on Windows and elsewhere, but (a) it would still look rather good, and (b) it would not look any more out of place than anything else, including Electron and even lots of "native" apps, due to the proliferation of toolkits described in the article not to mention the Gnome identity crisis that has only just recently begun to get reigned in—mostly by following Mac OS cues and being more consistent than before. It's just a shame that it stops at the surface level and doesn't carry over into the actual APIs. Plus those cues are from the post-flattening of UI.
- mjevans 2y ago
  If anything is going to get copied by Linux as is... it'll be Win32 API so mono / C# stuff can bind directly to that, and Mac/OSX will be even more isolated. For something to be portable everywhere it'll have to be an industry standard that the existing industry buys into.
  - deleted 2y ago
    [deleted]
Androth 2y ago
they don't need to do this and likely don't care to. web ui exists. microsoft doesn't even care about native anymore. they are focusing on .net maui cross platform/web (with blazor) stuff and AI. the days of snappy portable applications are over. unless you want to stick with win32. and nothing wrong with that. in win32, you have the tools to create any look and feel you want. the author just doesn't care put in the time to do that and wants something pre-built while conforming to his demands.

nasretdinov 2y ago

I think OpenStep actually had something like this in mind and had a Windows implementation too. It's apparently even used in Apple Windows apps like Safari, but of course it must not be complete enough to be able to fully replace native Windows API, and the incentive isn't there either.

linguae 2y ago
There was an implementation of OpenStep for Windows named OpenStep Enterprise: https://forum.winworldpc.com/discussion/11422/openstep-for-windows-nt https://forum.winworldpc.com/discussion/11422/openstep-for-w... It even survived Apple's purchase of NeXT, where the OpenStep API was renamed Yellow Box. There was a port of Yellow Box to Windows: https://www.betaarchive.com/forum/viewtopic.php?t=29049 https://www.betaarchive.com/forum/viewtopic.php?t=29049 In both OpenStep Enterprise and Yellow Box for Windows, while the UI elements still have some NeXT-isms, it's not terribly out of place, either. However, this got scrapped sometime when Apple abandoned Rhapsody (which had PowerPC and x86 versions) in favor of Mac OS X (which was originally only available for PowerPC until the Intel switch in 2006, though Apple maintained an x86 version internally during the PowerPC years). During the transition from Rhapsody to Mac OS X, Yellow Box was renamed Cocoa.
- WillAdams 2y ago
  The impetus here is that Adobe had initially promised a free, then low-cost license for Display PostScript --- when that was pulled, Apple had to come up with an alternative --- that and the fact that all the major app vendors announced that they weren't willing to do top--to-bottom re-writes using the NeXT frameworks (there was even a rumor that "Yellow Box" was named for the sake of Bill Gates' comment, "Develop for NeXTstep? I'll piss on it.") So, Apple, led by Mike Paquette and many other talented folks from NeXT created Quartz (née Display PDF) and Carbon and instead of a consistent environment with a single API, we got an assemblage of technologies which had a Calculator app written in Java which took _forever_ to load, a Finder written in Carbon instead of Workplace.app, and icons cluttering the desktop and a Sidebar instead of a Shelf, and a bunch of Carbon apps.

deleted 2y ago

[deleted]

criddell 2y ago

> need to agree on a GUI interoperability I hope they don’t. I like that the different platforms I use feel and look different. In fact, I wish there was more variety. I wish there were still Atari, and Amiga, and BeOS, Tandy, and all the other interesting platforms competing for users with different ideas of how computers should work.

linguae 2y ago
I wonder how possible it is to design a cross-platform GUI framework that not only uses the native UI widgets of each underlying platform, but also respects each platform's human interface guidelines. I'd imagine this would be very hard work, especially the part about respecting each platform's HIG, but the increased power of AI tools could potentially make this task easier. Such a framework could potentially be an appealing alternative to Electron for making cross-platform applications, with the benefit of conformity to each platform's HIG.
- swatcoder 2y ago
  There have been many frameworks that offered this and some still do. But it comes at the direct expense of design discipline, branding, and user experience optimization -- all of which have been elevetated to high concern over the 15 years or so. Cross-platform "Native look and feel" currently works for some no-nonsense professional utitlies and hobby tools, but mostly makes software that's hard to sell, document, or support. Most have just opted for common widget libraries instead, and frameworks have stepped up by providing rich libraries of such widgets and prioritizing features for customizing or complementing them even further.
- criddell 2y ago
  I’ve been thinking more lately about a library which defines an interface for GUI elements, and then leaves implementing that up to you. Something like MVC (or some other design pattern) where the view part is an interface definition.
- torstenvl 2y ago
  wxWidgets does this pretty well, e.g., wxSingleChoiceDialog has "OK" "Cancel" on Windows but "Cancel" "OK" on Linux/GTK.

torstenvl 2y ago

This exists. It's called wxWidgets. It's an API shim over native components plus some convenience classes for abstracting out OS-specific functionality. It's LGPL with static linking exception, so no DLL hell. I'm not quite sure what you mean by open spec, but it's just an API not a protocol, and uhhhh.... https://caselaw.findlaw.com/court/us-supreme-court/18-956.html https://caselaw.findlaw.com/court/us-supreme-court/18-956.ht...

mjevans 2y ago
The library exists, BUT it is NOT shipped natively and NOT (AFAIK) something which trying to run a random downloaded utility app will trigger the system library loader prompting for the 'common wxWidgets runtime, for free, codesigned by Microsoft' download and install from the store to run the app.
- torstenvl 2y ago
  Your previous post said > the resulting binary MUST NOT require including / embedding DLL / library hell like everything today does If there's no DLL required then why does it matter if the DLL is automatically downloaded from the Microsoft store? DLLs are not useful for statically linked binaries.

userbinator 2y ago

That's called WINE. ;-) Win32 Hello World messagebox is a few hundred bytes.

cxr 2y ago

> Windows (MS) and OSX (Apple) need to agree on a GUI interoperability API. Either hammer something out, or adopt one/more of the OSS GUI framework specifications from QT and GTK. I've been saying for a while now that the open source world would have benefited if more effort than what went into GNUStep had been focused on copying Cocoa to the point that it rather than GTK or Qt had been the toolkit of choice for the Linux Desktop. Especially when there was a major infusion of interest circa 2010 of folks adopting the MacBook Pro as the developer machine of choice. I think it's still doable. And I mean down to looks, too, and not just API feel. Aqua from the same time period (Snow Leopard through Mountain Lion era) is the closest thing I can think of to timeless visual design. It's true that if everyone just made Cocoa apps that looked like they were created with Mac OS in mind it would look out of place on Windows and elsewhere, but (a) it would still look rather good, and (b) it would not look any more out of place than anything else, including Electron and even lots of "native" apps, due to the proliferation of toolkits described in the article not to mention the Gnome identity crisis that has only just recently begun to get reigned in—mostly by following Mac OS cues and being more consistent than before. It's just a shame that it stops at the surface level and doesn't carry over into the actual APIs. Plus those cues are from the post-flattening of UI.

mjevans 2y ago
If anything is going to get copied by Linux as is... it'll be Win32 API so mono / C# stuff can bind directly to that, and Mac/OSX will be even more isolated. For something to be portable everywhere it'll have to be an industry standard that the existing industry buys into.
- deleted 2y ago
  [deleted]

Androth 2y ago

they don't need to do this and likely don't care to. web ui exists. microsoft doesn't even care about native anymore. they are focusing on .net maui cross platform/web (with blazor) stuff and AI. the days of snappy portable applications are over. unless you want to stick with win32. and nothing wrong with that. in win32, you have the tools to create any look and feel you want. the author just doesn't care put in the time to do that and wants something pre-built while conforming to his demands.