6 ms·

> for the entire OS interface to become based on Chromium HTML+CSS+JS I don't care about HTML and CSS and JS in specific, but yes, holy crud I want my native O

> for the entire OS interface to become based on Chromium HTML+CSS+JS 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. It doesn't have to be HTML if everyone hates HTML. But there is a lot of potential beyond just developer convenience to having native apps start representing their interfaces using semantic language. I don't know how to get across how much stuff that would enable on the computer. I need to sit down at some point and try to build proof-of-concepts because the idea is something I genuinely just randomly get excited about sometimes, even though I know it's probably not going to ever actually exist any time soon and nobody is working on it. But just off the top of my head: - I would like to be able to have extremely low-latency remote-desktop access by streaming only the "DOM" tree instead of the entire screen. - I would like to be able to apply user-CSS styles to every single app on my computer. GTK/Gnome styling/etc... sort of works in this direction but... it's not as good. Let me right-click on a running app and inspect element. Let me style stuff in real time. This is something that was always a part of native development and still kind of is, but it feels like the native platforms have all gotten worse in this regard (but maybe that's just anecdotal). - I would like to be able to pipe the interface of an app into another app and scrape its content. - I would like to be able to script my native apps by running DOM queries rather than by learning some plugin language or simulating mouse movements. - I would like to be able to stream a specific sub-tree of an app's interface to another device. I would like to be able to open up my phone and have it show specifically the color picker from Krita and have it pipe my input back into Krita and I don't want to learn a Krita-specific scripting language to do that, I just want to run a query and pull out that sub-tree and stream it. I would like to be able to have an app just pull out the "canvas" element from Krita and occasionally snapshot it or mirror it to another monitor. - I would like to have multiple "views" of a single application by just passing the same application's "DOM" into two different renderers without needing to have two processes for the actual application. - I would like to be able to do all of that on-the-fly without sitting down and writing some specialized program, the same way I can do stuff on a website by just right-clicking and going "inspect element." And again, I don't really care if it's the DOM specifically, I just want all the stuff the DOM provides me as a user.

ezst 3y ago
> 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 mean, that's been the case for most GUI toolkits I know of, for decades before electron was a thing, and part of why I've never been impressed by the value proposition of DOM and web in general as a GUI toolkit/rich application platform by people with no prior exposure to proper GUI frameworks. Qt has GammaRay JavaFX has Scenic View Gtk has a built in inspector (Ctrl+shift+I) Windows has things like UISpy/Inspect
- 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

> 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 mean, that's been the case for most GUI toolkits I know of, for decades before electron was a thing, and part of why I've never been impressed by the value proposition of DOM and web in general as a GUI toolkit/rich application platform by people with no prior exposure to proper GUI frameworks. Qt has GammaRay JavaFX has Scenic View Gtk has a built in inspector (Ctrl+shift+I) Windows has things like UISpy/Inspect

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.