5 ms·

Lomg time ago, I think 2010ish, there was an experimental HTML renderer that would open up a GTK app in a browser that has its UI using plain HTML+CSS. For the

by wg0 3y ago

Lomg time ago, I think 2010ish, there was an experimental HTML renderer that would open up a GTK app in a browser that has its UI using plain HTML+CSS. For the time, it was just jaw dropping. For context, I think it was before Atom, VS Code or Electron (or possibly even NodeJS?) was a thing. Don't know if that HTML renderer is still around or not.

ho_schi 3y ago
You mean Broadway? https://docs.gtk.org/gtk4/broadway.html https://docs.gtk.org/gtk4/broadway.html https://www.phoronix.com/news/GTK4-Broadway-Being-Used https://www.phoronix.com/news/GTK4-Broadway-Being-Used I did not considered it as main/official backend but it is still there and was ported to Gtk4.
- wg0 3y ago
  Oh yes, that's it. Thanks for posting. I think its so beautiful. It is one of those things that have pure artisan value. Of craftsmanship. Whether it is used widely or not, I wish this backend to be there. Back then, I did run Open Office in Firefox and it amazed me.
  - mananaysiempre 3y ago
    If nothing’s changed, the Gtk 4 design tool Cambalache[1] by the former maintainer of the now-defunct Glade project uses[2] Broadway to render its design view, because it was there and an embedded Wayland compositor widget wasn’t. Broadway is awesome, but this just makes me sad. [1] https://gitlab.gnome.org/jpu/cambalache https://gitlab.gnome.org/jpu/cambalache [2] https://blogs.gnome.org/xjuan/2021/05/18/merengue-cambalaches-workspace/ https://blogs.gnome.org/xjuan/2021/05/18/merengue-cambalache...
    - aktuel 3y ago
      I dont't understand. What exactly makes you sad?
      - mananaysiempre 3y ago
        That the easiest way for a UI design tool using a native toolkit and targeting that same toolkit to display a preview of the UI being edited turned out to be embedding the 800-pound gorilla called a webview.
        tadfisher 3y ago
        The only reason the tool does that is to support multiple versions of GTK. But the alternative you suggest, embedding a Wayland compositor in a widget, doesn't exactly seem to be the lightest-weight of options.
        mananaysiempre 3y ago
        Not my suggestion, for what it’s worth, but the author’s own (in ref. 2 above). And yes, it’s not precisely fantastic, but on the other hand “embedded Wayland compositor” is for the most part a fancy way to say “dumb RPC passthrough and a single blit”. (That doesn’t mean that it wouldn’t take a whole lot of work to make, just that the eventual result would not be huge.)
arghwhat 3y ago
It's called Broadway: https://docs.gtk.org/gtk4/broadway.html https://docs.gtk.org/gtk4/broadway.html
- wg0 3y ago
  Impressive. Web was very primitive back then compared to how it is today. I think there was no flex, no grids, no ESM modules even. It might not sound impressive in 2024 but back then, it was a huge deal. Very daring to even attempt something like that IMHO. It was a time of YUI, jQuery, ExtJS, script.aculo.us and such.
  - toyg 3y ago
    QML pre-dates it by a year or so, it's basically in the same vein. Everyone wanted to co-opt web-devs for desktop development at that point.
    - actionfromafar 3y ago
      Haha, they got quite a bit more than they bargained for. Hello Electron.
      - toyg 3y ago
        Lol yeah. In a way, most people kinda got where the industry was moving to, but desktop toolkits moved too slowly and effectively got left in the dust.
  - deaddodo 3y ago
    It literally just rendered to a Canvas framebuffer. It's really not that crazy. I mean cool, yes....but it wasn't generating DOM elements/complex HTML or anything like you're trying to sell it as.
troupo 3y ago
I think qbittorrent still uses that for its web ui
- steve_rambo 3y ago
  Not really. qBittorent is built on Qt (thus the prefix), and has a hand-rolled webui in pure html + css + js (with a couple of helper libraries, but no heavy frameworks): https://github.com/qbittorrent/qBittorrent/tree/master/src/webui/www https://github.com/qbittorrent/qBittorrent/tree/master/src/w...
  - troupo 3y ago
    Kudos to them then. It's really well done
  - EasyMark 3y ago
    and it's actually quite responsive
    - BlueTemplar 3y ago
      As Qt usually is.
      - seba_dos1 3y ago
        ...which is true, but completely irrelevant to the above-mentioned Web UI.
      - EasyMark 3y ago
        I was talking about the web interface, not the GUI; the web interface uses only web technologies of course. I mean I guess they could do a wasm version too but ehhhhhh
no_time 3y ago
Calling it a "HTML renderer" is a bit of a strech. Atleast in GTK3 it just streams pixel data into a canvas element, effectively being the same as VNC with a web viewer. https://imgur.com/a/2EDZ2Ti https://imgur.com/a/2EDZ2Ti
- wg0 3y ago
  Ok I'm not so sure if canvas was around back then so I might have misremembered it. But I did see div upon div with inline styles. Maybe later they moved to canvas. Or like I said, I might be mistaken. Recently however, Flutter had two backends for web. One HTML based and other canvas based. Some WebGL etc might be in the works.
moondev 3y ago
broadway - A while back I created a little POC for running it inside docker which worked really well. https://github.com/moondev/gtk3-docker https://github.com/moondev/gtk3-docker My use case was running a browser inside a browser to easily interact with Kubernetes clusterip services without needing to port forward or proxy. Another awesome example: running virt-manager to run a vm via the gtk virt-viewer (and interacting with it through the browser) https://github.com/m-bers/docker-virt-manager https://github.com/m-bers/docker-virt-manager
chrismorgan 3y ago
Although it uses more HTML and CSS than some similar things, I don’t think it’s fair to call it “plain HTML + CSS”, because it displays more functional characteristics of the pure canvas approach (where you throw away just about everything the browser gives you and start from scratch). My three primary heuristics for proper behaviour are: (a) using browser scrolling (the web doesn’t expose the right primitives to make a scroll-event-based reimplementation anything but bad, barely noticeable in some configurations but painfully broken in some of the most common configurations); (b) using browser text rendering (strongly preferably by DOM nodes, but even canvas plus fillText can be acceptable); and (c) handling links with real <a> elements (no alternative can provide the same functionality). Broadway fails all three of these (reimplementing scrolling, rendering text on the server and sending images, and I think actually locking up when you try to click on a link). It also fails my fourth and fifth tests, which are (d) handling text input properly (it looks like it just uses key events, not even a backing <input> or <textarea> or contenteditable, so IME composition fails completely and keyboard navigation will presumably be GTK rather than native); and (d) having a meaningful accessibility tree (preferably backed by normal DOM stuff, but not necessarily; I place this one last despite its importance because it’s likely to be more retrofittable than the others, though it’ll still generally be hard). I’d count Broadway as suitable for tech demos and for personal use where you know you don’t mind its limitations, but not for any sort of public deployment. It’s basically just an RDP/VNC sort of thing, with a smattering of DOM use. (Also remember that’s how it works—the code is all running on the server.)
- KTibow 3y ago
  > no alternative can provide the same functionality I agree that real links should always be used to represent links, but if you were to emulate links surely it wouldn't be that hard? Just allow middle-clicking and ctrl-clicking and you should have the basic functionality. Is stuff like the ability to drag a problem?
  - chrismorgan 3y ago
    You can’t even emulate middle-click or Ctrl+click correctly! The best you can do in-page is open(), which will will typically open a new foreground tab; but in typical desktop configurations, middle-click and Ctrl+click will open a new background tab. Users will notice you disrupting their normal workflow of opening a bunch of thing at once and then going through them one by one and get extremely frustrated. And then beyond that, well. Right click or long press, browser context menu with things like copy, bookmark, open in new tab, open in private window, share… you can’t emulate most of this at all. And hover to see href in the browser’s status bar. And so it goes on. No, the only acceptable technique is to have the user interact with a real HTML <a>, HTML <area> or SVG <a> element.
gtirloni 3y ago
Reminds me of $something that allowed Delphi desktop applications to run in the browser. I think it was CGI-based and really fragile.
jauntywundrkind 3y ago
There's Greenfield, an HTML5 Wayland compositor. https://github.com/udevbe/greenfield https://github.com/udevbe/greenfield There's some fancy bridging modes to run apps in a browser, but the author has also been working on a way to make wasm Wayland apps run directly in the browser tol.

by wg0 3y ago

ho_schi 3y ago

You mean Broadway? https://docs.gtk.org/gtk4/broadway.html https://docs.gtk.org/gtk4/broadway.html https://www.phoronix.com/news/GTK4-Broadway-Being-Used https://www.phoronix.com/news/GTK4-Broadway-Being-Used I did not considered it as main/official backend but it is still there and was ported to Gtk4.

wg0 3y ago
Oh yes, that's it. Thanks for posting. I think its so beautiful. It is one of those things that have pure artisan value. Of craftsmanship. Whether it is used widely or not, I wish this backend to be there. Back then, I did run Open Office in Firefox and it amazed me.
- mananaysiempre 3y ago
  If nothing’s changed, the Gtk 4 design tool Cambalache[1] by the former maintainer of the now-defunct Glade project uses[2] Broadway to render its design view, because it was there and an embedded Wayland compositor widget wasn’t. Broadway is awesome, but this just makes me sad. [1] https://gitlab.gnome.org/jpu/cambalache https://gitlab.gnome.org/jpu/cambalache [2] https://blogs.gnome.org/xjuan/2021/05/18/merengue-cambalaches-workspace/ https://blogs.gnome.org/xjuan/2021/05/18/merengue-cambalache...
  - aktuel 3y ago
    I dont't understand. What exactly makes you sad?
    - mananaysiempre 3y ago
      That the easiest way for a UI design tool using a native toolkit and targeting that same toolkit to display a preview of the UI being edited turned out to be embedding the 800-pound gorilla called a webview.
      - tadfisher 3y ago
        The only reason the tool does that is to support multiple versions of GTK. But the alternative you suggest, embedding a Wayland compositor in a widget, doesn't exactly seem to be the lightest-weight of options.
        mananaysiempre 3y ago
        Not my suggestion, for what it’s worth, but the author’s own (in ref. 2 above). And yes, it’s not precisely fantastic, but on the other hand “embedded Wayland compositor” is for the most part a fancy way to say “dumb RPC passthrough and a single blit”. (That doesn’t mean that it wouldn’t take a whole lot of work to make, just that the eventual result would not be huge.)

arghwhat 3y ago

It's called Broadway: https://docs.gtk.org/gtk4/broadway.html https://docs.gtk.org/gtk4/broadway.html

wg0 3y ago
Impressive. Web was very primitive back then compared to how it is today. I think there was no flex, no grids, no ESM modules even. It might not sound impressive in 2024 but back then, it was a huge deal. Very daring to even attempt something like that IMHO. It was a time of YUI, jQuery, ExtJS, script.aculo.us and such.
- toyg 3y ago
  QML pre-dates it by a year or so, it's basically in the same vein. Everyone wanted to co-opt web-devs for desktop development at that point.
  - actionfromafar 3y ago
    Haha, they got quite a bit more than they bargained for. Hello Electron.
    - toyg 3y ago
      Lol yeah. In a way, most people kinda got where the industry was moving to, but desktop toolkits moved too slowly and effectively got left in the dust.
- deaddodo 3y ago
  It literally just rendered to a Canvas framebuffer. It's really not that crazy. I mean cool, yes....but it wasn't generating DOM elements/complex HTML or anything like you're trying to sell it as.

troupo 3y ago

I think qbittorrent still uses that for its web ui

steve_rambo 3y ago
Not really. qBittorent is built on Qt (thus the prefix), and has a hand-rolled webui in pure html + css + js (with a couple of helper libraries, but no heavy frameworks): https://github.com/qbittorrent/qBittorrent/tree/master/src/webui/www https://github.com/qbittorrent/qBittorrent/tree/master/src/w...
- troupo 3y ago
  Kudos to them then. It's really well done
- EasyMark 3y ago
  and it's actually quite responsive
  - BlueTemplar 3y ago
    As Qt usually is.
    - seba_dos1 3y ago
      ...which is true, but completely irrelevant to the above-mentioned Web UI.
    - EasyMark 3y ago
      I was talking about the web interface, not the GUI; the web interface uses only web technologies of course. I mean I guess they could do a wasm version too but ehhhhhh

no_time 3y ago

Calling it a "HTML renderer" is a bit of a strech. Atleast in GTK3 it just streams pixel data into a canvas element, effectively being the same as VNC with a web viewer. https://imgur.com/a/2EDZ2Ti https://imgur.com/a/2EDZ2Ti

wg0 3y ago
Ok I'm not so sure if canvas was around back then so I might have misremembered it. But I did see div upon div with inline styles. Maybe later they moved to canvas. Or like I said, I might be mistaken. Recently however, Flutter had two backends for web. One HTML based and other canvas based. Some WebGL etc might be in the works.

moondev 3y ago

broadway - A while back I created a little POC for running it inside docker which worked really well. https://github.com/moondev/gtk3-docker https://github.com/moondev/gtk3-docker My use case was running a browser inside a browser to easily interact with Kubernetes clusterip services without needing to port forward or proxy. Another awesome example: running virt-manager to run a vm via the gtk virt-viewer (and interacting with it through the browser) https://github.com/m-bers/docker-virt-manager https://github.com/m-bers/docker-virt-manager

chrismorgan 3y ago

Although it uses more HTML and CSS than some similar things, I don’t think it’s fair to call it “plain HTML + CSS”, because it displays more functional characteristics of the pure canvas approach (where you throw away just about everything the browser gives you and start from scratch). My three primary heuristics for proper behaviour are: (a) using browser scrolling (the web doesn’t expose the right primitives to make a scroll-event-based reimplementation anything but bad, barely noticeable in some configurations but painfully broken in some of the most common configurations); (b) using browser text rendering (strongly preferably by DOM nodes, but even canvas plus fillText can be acceptable); and (c) handling links with real <a> elements (no alternative can provide the same functionality). Broadway fails all three of these (reimplementing scrolling, rendering text on the server and sending images, and I think actually locking up when you try to click on a link). It also fails my fourth and fifth tests, which are (d) handling text input properly (it looks like it just uses key events, not even a backing <input> or <textarea> or contenteditable, so IME composition fails completely and keyboard navigation will presumably be GTK rather than native); and (d) having a meaningful accessibility tree (preferably backed by normal DOM stuff, but not necessarily; I place this one last despite its importance because it’s likely to be more retrofittable than the others, though it’ll still generally be hard). I’d count Broadway as suitable for tech demos and for personal use where you know you don’t mind its limitations, but not for any sort of public deployment. It’s basically just an RDP/VNC sort of thing, with a smattering of DOM use. (Also remember that’s how it works—the code is all running on the server.)

KTibow 3y ago
> no alternative can provide the same functionality I agree that real links should always be used to represent links, but if you were to emulate links surely it wouldn't be that hard? Just allow middle-clicking and ctrl-clicking and you should have the basic functionality. Is stuff like the ability to drag a problem?
- chrismorgan 3y ago
  You can’t even emulate middle-click or Ctrl+click correctly! The best you can do in-page is open(), which will will typically open a new foreground tab; but in typical desktop configurations, middle-click and Ctrl+click will open a new background tab. Users will notice you disrupting their normal workflow of opening a bunch of thing at once and then going through them one by one and get extremely frustrated. And then beyond that, well. Right click or long press, browser context menu with things like copy, bookmark, open in new tab, open in private window, share… you can’t emulate most of this at all. And hover to see href in the browser’s status bar. And so it goes on. No, the only acceptable technique is to have the user interact with a real HTML <a>, HTML <area> or SVG <a> element.

gtirloni 3y ago

Reminds me of $something that allowed Delphi desktop applications to run in the browser. I think it was CGI-based and really fragile.

jauntywundrkind 3y ago

There's Greenfield, an HTML5 Wayland compositor. https://github.com/udevbe/greenfield https://github.com/udevbe/greenfield There's some fancy bridging modes to run apps in a browser, but the author has also been working on a way to make wasm Wayland apps run directly in the browser tol.