On Tuesday, 1 June 2021 at 16:20:19 UTC, Ola Fosheim Grøstad wrote:
> I don't really agree with this, most of the interesting things for specifying UIs are happening in in web-frameworks/web-standards nowadays.
I wasn't considering/referring to content in the browser, this is an entirely different arena.
> If I were to make a desktop application in D today then I would have chosen to either embed a browser-view and use that for interface, or electron. Not sure if has been mentioned already, but it is an option.
I don't agree with that at all but I respect your point and encourage you to do so provided you'll end with something useful to you.
The point with that approach is performance, performance, and did I say it ? ... performance.
I don't know about you but, what are the reasons you choose to develop in D ? One of the often cited reasons I came across is performance alongside with better-C style comments and full OOP and the like; which as a side-note it happens to be my case. So for a little while put you on my shoes and try to see the subject we are discussing from my point of view:
Now think for a instant, that you choose D for performance so you expect it to be fast, and you write the hello world app to begin with, and you fire-up a full-framework like Electron or the like just to give you basic GUI controls. Stretch it a bit, instead of using Electron and family you coded a basic HTML page saying hello world and put a button in a form element to close the page/document and then you embed a web browser within your app, a fully-fucking-huge-meaning-millions-of-lines-of-code-with-thousands-of-non-relevant-modules-like-TLS/SSL-Web-Assembly-JavaScript-and-keep-counting just to ... render hello world inside your blazingly-fast-lean D program ?
Will it work ?
Sure.
But, why are we, to begin with, stacking layers upon layers of APIs (meaning millions of lines of code and/or degrading performance to extreme levels and/or increasing the attack surface of our lean app) just to say hello world in a window and expecting the user to close it at any given time and ... nothing more ?
Why did we choose to use huge frameworks, embed browsers, etc to write a simple app ?
Because the basics, the foundations, are broken.
Instead of trying to fix the broken bits to allow us to choose the obvious/correct/lean/straightforward path, we, developers (and now I am talking from the point of view of the whole community), keep using higher and higher levels of abstraction to accomplish simple things.
Given the power of a typical computer nowadays there is no excuse for a GUI to be blazingly-fast, snappy-as-hell, zero-lag. If these symptoms are present we are doing it wrong.
Don't get me wrong: browsers are extremely useful pieces of software. The problem is everybody starts to think the browser is the OS. This approach, to my humble point of view, is short-sighted. We came full-circle: from everything done on the mainframe with stupid terminals on the other side of the line, to personal computers offloading work from servers and starting "thinking" by themselves and all the related client/server stuff of the early 90s, to the Sun's vision the-network-is-the-computer and all the related Java stuff which more-or-less brought us the web browsers, to the google's vision the-web-browser-is-the-OS approach. Endless layers upon layers. Web browsers are fantastic for browsing/reading complex documents with all its hyperlinks, stupid things that now assume for granted, but with its complex rendering engines, they are, and I said it once again, fantastic pieces of software. The problem with the web browser, and now we are backing to the GUI subject we are discussing here, is that sometimes in mid-00s their development started to be orchestrated by the commercial world and specifically by the ad industry, seeing them as software to sell relegating its primary purpose of knowledge/browsing documents, that's why we left HTML 4/XHTML 1.0/1.1 behind and got HTML 5 instead of XHMTL 2 which was the right way to go if the browsers kept sticking to their primary goal. Now the browser mandates font face/style/size, strict-layouts, a magazine, a cool selling magazine on my screen. Evolution. Nothing against it, quite the opposite, a document-centric and app-centric browser split was what was needed then. Dreams. So from then on we started to see the decadence of GUI design: buttons that didn't look like buttons at all, etc. Which is that ? Ah, dunno, try to click over it and let's check if anything happens ... are you following me ? Then came Johnny Ives @ Apple with its concept of the flat user interface. Now everything is flat: is this a button ? is this a ... ? Who knows. This was followed by everyone outside Apple since Apple was cool back then, and we got gnome 3 and KDE Plasma and Unity. Everything learned so far went to the trashcan. So real people doing real work reacted a bit and we got MATE and the like, but it was the timeframe of the desktop being displaced by the smartphones and/or tables for moma/popa/and-the-likes and the power user now became a niche nobody cared for, very reasonable, the real money was not there. Transparent windows ! Why on Earth would you want a transparent window ? Do you think taking notes back then at college on a transparent or semi-transparent notepad would make sense ?
Summarizing a bit: GUIs were oversimplified over time to account for the non-tech-savvy users which happened to be the great majority of them with the advent of mobile devices, and, instead of splitting things apart the GUI was dumbed to extreme levels to accommodate such users, the less-common-denominator ... this is the problem with GUI design guidelines nowadays. The GUI toolkits exploded in complexity to support mobile and every-corner-case possible and became very difficult to maintain and that's why I think many toolkits stalled. I think someone with the knowledge to write a classical toolkit in pure-D following the classical design principles with the standard controls and nothing more should need deep openGL knowledge to begin with (however a better choice should be start from zero with its Vulkan successor) providing he/she has access to proven code for text input and/or font rendering (quite complex) and besides full-UniCode support (which in D is not a problem at all).
This is my two cents.
And of course, feel free to argue on everything you disagree with :)
Permalink
Reply
