4 ms·

Wait, that was a thing?

michaelt 5y ago
Well, yes and no. In the 1990s, a lot of desktop software was Windows-only, and used the Windows toolkit directly, so they supported the OS theming [1] including high-contrast options. The idea you'd avoid the OS widgets, or that you'd want a touchscreen-but-no-keyboard UI on desktop software for consistency with a mobile version simply hadn't become mainstream. (Java had started testing the waters with cross-platform applets embedded in web pages but that's another story) Of course, this was in the days of 1024x768 so large fonts were for the partially sighted, not like today's "high DPI mode" for people with 13" 4k screens. And most developers didn't test with different OS themes, so large-font settings could mean labels too big for their widgets, vital buttons getting pushed off screen and suchlike. Other applications (well, MP3 players at least) would come with their own 'skinning' system allowing you to style them completely independently of the OS. And many games had their own full-screen menu systems that ignored OS theming, just like they do to this day. [1] https://blog.codinghorror.com/a-tribute-to-the-windows-31-hot-dog-stand-color-scheme/ https://blog.codinghorror.com/a-tribute-to-the-windows-31-ho...
- NeutralForest 5y ago
  Got you, thanks for the link! I've been meaning to write a small native GUI app for fun but all the current options (GTK, Qt) are so large, it's a bit daunting. So I was full of hope when reading the original comment ^^'
  - krapp 5y ago
    I've dipped my toes into GUI development just enough to know you can have "simple," or you can have "native," but not both. There are smaller projects like nanogui[0] and microgui[1] out there, but of course they're only as small as they are because they don't use native widgets. [0]https://github.com/wjakob/nanogui/tree/master/src https://github.com/wjakob/nanogui/tree/master/src [1]https://github.com/ryankurte/micro-gui https://github.com/ryankurte/micro-gui
    - einr 5y ago
      You could go with Lazarus[0]. It is dead simple to use (hope you like Pascal, though) and can use native widgets from your choice of Win32, Cocoa, GTK+ or QT. [0] https://www.lazarus-ide.org/ https://www.lazarus-ide.org/
    - NeutralForest 5y ago
      Alright thanks, it's pretty sad we've handed cross-platform development to the web mostly. I see if I find something great along the way.
      - pjc50 5y ago
        Cross-platform desktop development never really worked properly, partly because the platforms were competitors and had no interest in making it easy. The web is the "neutral zone" where platform-specific stuff has mostly been fought off, at least since we killed IE and Flash. If you want to make a native app, the first question has to be "native to what platform?"
        NeutralForest 5y ago
        True enough, I'll still hold onto a dream of cross-compatible GUI's which work on most platform. Maybe new advances in VM stuff will make that possible?
        krapp 5y ago
        I think one big reason the web works as a GUI platform is that it wasn't designed with programmers in mind, but around a much simpler document and box-model paradigm with separate DSLs for layout, style and execution (HTML, CSS and JS respectively) - only one of which is (arguably) a programming language, and a simple one at that. It would be much different if anyone wanting to write an HTML document or GUI application had to do so in C++ using web APIs directly. Most GUI frameworks just aren't at a high enough level of abstraction to be as easy to work with as the web. Also, obviously, because browsers and the web stack are already ubiquitous. Electron is basically just shipping a web app with a standardized runtime (a Chromium instance) which is exactly what many other apps do (eg, most game frameworks and anything written in Python, Java, etc,) but Electron still needs a platform specific binary to distribute. TANSTAAFL. At the end of the day, nothing is truly cross platform.
  - pjc50 5y ago
    > I've been meaning to write a small native GUI app for fun Windows + Visual Studio Community + C# + WinForms = you can drag a button on to a panel, double-click it and edit the code behind, and start gluing a native app together in minutes. The install is large, and the limitation of WinForms is that it's not dpi-aware and tends not to be resizable either, but the development experience is still pretty great. And if you somehow like the Windows 3.1 experience, all the C code from that era should still compile and run on a 2022 system. You can learn what a window procedure is; I believe people call this "immediate mode" GUI these days. Oh, and as always, you can have native XOR portable.
    - NeutralForest 5y ago
      I'd like to keep my workflow as Windows independent as possible but I'll maybe check that out if all else fails.
- einr 5y ago
  In the 1990s, a lot of desktop software was Windows-only, and used the Windows toolkit directly, so they supported the OS theming [1] including high-contrast options. Windows wasn't alone in providing this. Most desktop operating systems of the day did, including MacOS 8/9, BeOS, OS/2 Warp... Of course, you're right that there never was a utopia of consistency where everything looked and worked the same and always respected user prefs, but the mid to late 90s was about as close as we ever got.

Well, yes and no. In the 1990s, a lot of desktop software was Windows-only, and used the Windows toolkit directly, so they supported the OS theming [1] including high-contrast options. The idea you'd avoid the OS widgets, or that you'd want a touchscreen-but-no-keyboard UI on desktop software for consistency with a mobile version simply hadn't become mainstream. (Java had started testing the waters with cross-platform applets embedded in web pages but that's another story) Of course, this was in the days of 1024x768 so large fonts were for the partially sighted, not like today's "high DPI mode" for people with 13" 4k screens. And most developers didn't test with different OS themes, so large-font settings could mean labels too big for their widgets, vital buttons getting pushed off screen and suchlike. Other applications (well, MP3 players at least) would come with their own 'skinning' system allowing you to style them completely independently of the OS. And many games had their own full-screen menu systems that ignored OS theming, just like they do to this day. [1] https://blog.codinghorror.com/a-tribute-to-the-windows-31-hot-dog-stand-color-scheme/ https://blog.codinghorror.com/a-tribute-to-the-windows-31-ho...

NeutralForest 5y ago
Got you, thanks for the link! I've been meaning to write a small native GUI app for fun but all the current options (GTK, Qt) are so large, it's a bit daunting. So I was full of hope when reading the original comment ^^'
- krapp 5y ago
  I've dipped my toes into GUI development just enough to know you can have "simple," or you can have "native," but not both. There are smaller projects like nanogui[0] and microgui[1] out there, but of course they're only as small as they are because they don't use native widgets. [0]https://github.com/wjakob/nanogui/tree/master/src https://github.com/wjakob/nanogui/tree/master/src [1]https://github.com/ryankurte/micro-gui https://github.com/ryankurte/micro-gui
  - einr 5y ago
    You could go with Lazarus[0]. It is dead simple to use (hope you like Pascal, though) and can use native widgets from your choice of Win32, Cocoa, GTK+ or QT. [0] https://www.lazarus-ide.org/ https://www.lazarus-ide.org/
  - NeutralForest 5y ago
    Alright thanks, it's pretty sad we've handed cross-platform development to the web mostly. I see if I find something great along the way.
    - pjc50 5y ago
      Cross-platform desktop development never really worked properly, partly because the platforms were competitors and had no interest in making it easy. The web is the "neutral zone" where platform-specific stuff has mostly been fought off, at least since we killed IE and Flash. If you want to make a native app, the first question has to be "native to what platform?"
      - NeutralForest 5y ago
        True enough, I'll still hold onto a dream of cross-compatible GUI's which work on most platform. Maybe new advances in VM stuff will make that possible?
        krapp 5y ago
        I think one big reason the web works as a GUI platform is that it wasn't designed with programmers in mind, but around a much simpler document and box-model paradigm with separate DSLs for layout, style and execution (HTML, CSS and JS respectively) - only one of which is (arguably) a programming language, and a simple one at that. It would be much different if anyone wanting to write an HTML document or GUI application had to do so in C++ using web APIs directly. Most GUI frameworks just aren't at a high enough level of abstraction to be as easy to work with as the web. Also, obviously, because browsers and the web stack are already ubiquitous. Electron is basically just shipping a web app with a standardized runtime (a Chromium instance) which is exactly what many other apps do (eg, most game frameworks and anything written in Python, Java, etc,) but Electron still needs a platform specific binary to distribute. TANSTAAFL. At the end of the day, nothing is truly cross platform.
- pjc50 5y ago
  > I've been meaning to write a small native GUI app for fun Windows + Visual Studio Community + C# + WinForms = you can drag a button on to a panel, double-click it and edit the code behind, and start gluing a native app together in minutes. The install is large, and the limitation of WinForms is that it's not dpi-aware and tends not to be resizable either, but the development experience is still pretty great. And if you somehow like the Windows 3.1 experience, all the C code from that era should still compile and run on a 2022 system. You can learn what a window procedure is; I believe people call this "immediate mode" GUI these days. Oh, and as always, you can have native XOR portable.
  - NeutralForest 5y ago
    I'd like to keep my workflow as Windows independent as possible but I'll maybe check that out if all else fails.
einr 5y ago
In the 1990s, a lot of desktop software was Windows-only, and used the Windows toolkit directly, so they supported the OS theming [1] including high-contrast options. Windows wasn't alone in providing this. Most desktop operating systems of the day did, including MacOS 8/9, BeOS, OS/2 Warp... Of course, you're right that there never was a utopia of consistency where everything looked and worked the same and always respected user prefs, but the mid to late 90s was about as close as we ever got.