4 ms·

> I don't care about HTML and CSS and JS in specific, but yes, holy crud I want my native OS to be based on a user-inspectable XML-like tree. Yes please. I mea

• danShumway 3y ago
  > that's been the case for most GUI toolkits I know of Yes and no? Or at least, yes and to the best of my knowledge, no. Yes, GUI toolkits do have similarities. But none of these tools have ever really been expanded out or utilized to the same degree that the DOM has been utilized. If you look at the documentation for most of the tools you link, they're primarily billed as debugging aids. They're also not something that the OS itself treats as an first-class feature. I do think in particular GTK has been moving more in this direction, but my (possibly incorrect) take on it is that it's basically copying the web (which to be clear, is a good thing). GTK outright uses CSS now. I'll also add onto this that I don't think the DOM is the equivalent of a GUI toolkit in the first place, I think it's a render target. It's at its best when it's targeted as a user-facing feature, not as a developer aid. That's not really ever been my perception of native toolkits (although to be fair, system theming has been a thing forever, but that's really just scratching the surface of what's possible here). There's stuff I can do with a browser console and extensions that I can't do as a user with a compiled GTK app -- and that's even acknowledging that browsers themselves don't leverage the DOM to its full potential. But they're still miles ahead of what I can do with native apps as a user. Not to say that these inspectors couldn't go in that direction. And I hope they do. Like I said, I'm not married to HTML in specific, I don't really care about how we end up heading in this direction, I'm mostly just pointing out that there's really serious advantages to having an XML-based text interface that's inspectable and that is separate from styling and those advantages get lost if everything just gets spit out as a pixel blob. Qt in particular is fun to bring up here because their web targeting makes the exact same mistake, so I don't think GammaRay is proof that they actually understand the strength of this model, because otherwise I don't think they'd be making this mistake when targeting the web. What I will say is in praise of these tools is that the success of platforms like QT and GTK should on some level be evidence that "the web is for documents, not apps" is kind of nonsense. Most apps are documents. QT and GTK do just fine while forcing the developer to build a hierarchical UI of standardized components. They have no problem standardizing things like input handling. A pure-text tree-based UI with universal semantic components is something that works for most apps, even on native. I mean, GTK literally uses XML for interfaces. So I don't buy the whole "document/application" distinction that people sometimes pull out; everyone is already building interactive documents on native and it's completely fine and completely sufficient for a ton of serious applications.
  • ezst 3y ago
    > But none of these tools have ever really been expanded out or utilized to the same degree that the DOM has been utilized. I think you got the history backwards: the DOM was never designed to hold rich applications, controls and containers like a GUI toolkit does. HTML got forms (later, with HTML4), then organically grew more diverse and specialized controls (without ever reaching parity with most GUI toolkits in this area), never quite figuring-out containers nor behaviour inheritance (unlike in object oriented programming and the "Widget" model), while JS got steadily tamed and reshaped into a general-purpose language. I don't disagree with the assertion that "DOM has been utilized in extreme ways", I just don't think that it's a positive thing, simply because what we ended-up with is something extremely ad-hoc, inefficient and counter-productive (but as the saying goes, "when all you have is a hammer…"). What made the Web a successful platform is the "URL as deployment process", not that it's a great tech (neither on the producing nor consuming side). > If you look at the documentation for most of the tools you link, they're primarily billed as debugging aids. They're also not something that the OS itself treats as an first-class feature. Which is totally different than web browser's DOM appearing under "developer tools", or is it? Also, this ability to hook onto the DOM and play with things in the console disappears with packaged electron apps, which turn-out to be often less "introspectable" in practice than their native counterparts. Even on the "normal" web, this ability becomes a rarity as more and more pages get minified and bound to heavy SPA frameworks. > my (possibly incorrect) take on it is that it's basically copying the web (which to be clear, is a good thing). GTK outright uses CSS now. And it's not the only one, JavaFX and QML (Declarative Qt) can be built from XML and styled using CSS-like rules. Microsoft has had many attempts at declarative UI based on XML (XAML, UWP, …). XUL was Netscape solution to building applications with HTML at a time HTML wasn't ready (which lasted well into recent history, with 2018 IIRC being when Mozilla could finally go without it). Though let's not conflate everything: Web implies DOM, but CSS/XML doesn't, and defining documents and UIs in a SGML is much older than HTML itself.
    • danShumway 3y ago
      > Also, this ability to hook onto the DOM and play with things in the console disappears with packaged electron apps, which turn-out to be often less "introspectable" in practice than their native counterparts. To be clear, Electron is NOT what I am asking for. Electron is not fulfilling the spirit of having native DOM. I don't care what it's authored in, I care about what I can do with it as a user. Electron is in some cases a step backwards because I lose even the very limited styling options that the OS does provide. It's not about what the developer writes, it's about what I as the user am presented with. The major strength of the DOM is that you have to describe your interface using text to the user, not to the compiler. > Web implies DOM, but CSS/XML doesn't, and defining documents and UIs in a SGML is much older than HTML itself. But this gets back to your original premise: the DOM was never designed to hold rich applications, and yet, it turns out that XML is perfectly fine for authoring rich applications. The whole document/application distinction hasn't held up (and arguably never held up), which is evidenced by basically every one of these toolkits pushing in that direction. I'm not sure how people can say that the DOM/CSS is insufficient for this when native toolkits are literally pulling CSS in now. But again, I don't really care about HTML/CSS in specific. I care about the architecture. If the problem is just what specific components HTML provides, then use something else. But I want there to be something universal that (almost) everything on my OS uses. I want to get some broad agreement from application devs that they're not going to push pixels to the screen, they're going to give me as an end user a live interface in a shared XML format. And I want to be really clear again, defining documents in UIs and SGML is not what I care about. I care about what gets presented to the user. The authorship is not the important part here. I want to be able to open my calendar app's interface in a text editor. You mention the browser's dev tools yourself, and it's a really good question that I think kind of demonstrates my point: > Which is totally different than web browser's DOM appearing under "developer tools", or is it? To be completely honest, yeah, I do think it's totally different. I can do things as a user in the browser dev tools that I can't do for any of these native toolkits: insert additional markup, add my own rules and event listeners and scripts, etc. And importantly, I can do that stuff on every single website, not using a specialized debugger for a small portion of the apps on my computer. I regularly open my dev tools and write little helper scripts for websites. I regularly alter CSS on the fly for websites I visit. And sure, I don't actually think that browsers are doing a great job of leveraging this, I think they could go way further and could support even more powerful use cases. And some of the integration between the DOM and JS and the tendency towards div soup is actually quite bad on the web. But even so, the experience of working with the dev tools as an end user consuming somebody else's web app interface is miles ahead of the functionality on native platforms. In a lot of web apps that I use seriously I have extra CSS rules getting piped in through uBlock Origin. I don't have that on for any of my native Linux apps. Yes it's still just called "developer tools", yes browsers could support more, but the entire philosophy around CSS as a user-extensible styling tool and HTML as something that can be queried and manipulated on the fly by multiple agents is something that's always been embraced more in browsers than on native platforms (limited OS styling options aside).