Gtk3 vs HTML5

The last few weeks I’ve been working on an interesting new idea, hacking out a prototype.

The code is not really clean enough for public consumption yet, and a bunch of features are missing. However, its now at the stage where it can be demoed and evaluated.

I think the best way to introduce it is via a video: (original theora file)

Basically, its a backend for Gtk+ 3 that renders in a browser.

A more techincal description for the web geeks among us:

Each toplevel window is mapped to a canvas element, and the content in the windows is updated by streaming commands over a multipart/x-mixed-replace XMLHttpRequest that uses gzip Content-Encoding to compress the data. Window data is pushed as region copies (for scrolling) and image diffs. Images are sent as data: uris of uncompressed png data.

Input is gathered via dom events and sent to the server using websockets.

Right now this is Firefox 4 only, but it could be made to work in any browser with websockets.

Now, I want to know, Is this useful?

There are two basic ways to use this, you can either run your own apps on your own server and access it from anywhere (kinda like screen). Or you can put it on a public server that spawns a new instance of the app for every user (gimp on a webpage!).

If you had this technology, what cool stuff would you do with it? What apps would you run, and how would you use them?

175 thoughts on “Gtk3 vs HTML5”

  1. Dope idea!

    I’d use this to integrate native apps into Chromium OS. Users spend 80% of their time on the internet, and as web standards improve that number is only going to increase. However, native apps are still necessary, and often better than web apps at certain tasks. Yet Chrome OS is forcing users to abandon native apps. I don’t need two machines; I want a single computer capable of doing everything. Right now, that means a traditional desktop interface with a browser installed. But this is a usability problem. While the browser remains a tool of the desktop, users are forced to distinguish between two interaction models: one for native apps, and one for web apps. With this technology we can bridge that divide and unify the browser and the desktop; provide both flexible webapps, and solid, high-performance native apps. All this in a single interface, without forcing users to switch context.

  2. The better question is “What wouldn’t I do with that!” ( Havoc: I like the possibility of Inception. :-) By the time get 5 levels deep of Netscapes, you’ll need a strong sedative indeed. IF the nested instances had to be daisy chained, that is. But it would be possible for the nested instances to directly post its contribution directly to the client. This eliminates the bucket brigade, and would presumably allow any level of nesting without a performance hit. )

    I guess the limitation is interaction with the client workstation. E.g. how does one upload a file to the hypothetical copy of GIMP embedded in my browser?

    Very cool!

  3. If nobody did it before then you’ve just given many the idea of creating a VLC client that renders on HTML5, it’s be just a matter of re-implementing the protocol over XMLHttpRequest and creating all the javascript rendering routines for the canvas. Sick idea. Brilliant demo

  4. That is seriously cool. Lots of potential. I always thought GTK and HTML had enough similarities to do something like this.

    (Tip: Type out your comments ahead of time and just scroll down… avoids filming all the typos. :p)

  5. in a different way, this has been done, for a given value of “done”, in the form of pygtkweb, as a GSoC 2007 project. an absolute basic reimplementation of (in python), combined with an absolute basic reimplementation of (in python) in combination with basic reimplementations of gtk widgets (in python), combined also with a graphics layer that mapped onto HTML5 primitives, was passed through the pyjs compiler.

    the end-result was that, within the GSoC time-limit, luis pamirez was able to demonstrate 17 of the helloworld gtk examples up-and-running inside a web browser, as pure javascript, with the source still being in python.

    the advantage of this approach is that no server-side infrastructure is required to render the application.

  6. IMHO, this has the potential to be revolutionary.

    1) It provides the network transparency!

    2) ZERO install! No X server to configure/install, no *nix dependencies.

    3) Potential for excellent network latency characteristics!

    4) Solves the problems of X without requiring the dump of X applications?

    Let me say that this excites me, as you usher in a new era of network-based computing around a fundamentally different set of assumptions.

    This is incredible!

  7. wow, this is really crazy amazing.

    question: how much does it slow down when you don’t connect to localhost but to a remote website (it’s not so much about bandwidth i guess, but about ping time…)?

  8. Would it be possible to use the javascript bindings for it?

    Then, we could build an application with javascript/GTK and use it on an application server, without compilation.

    To go further:
    This application could let the user define some input forms in javascript/GTK, which would be render within the application.
    I am thinking of an application where some users define the input forms / flows for an other group of user.

    I think it would be fantastic!

  9. Waiting for someone to do this for QT … :-P
    But seriously, yes this is useful. If I wanted to access GUI apps on my own server from behind, say, a workplace firewall this might be the only way.

  10. I remember you talking about something like this on IRC a while ago ..

    Good to see that you actually implemented it and that it works that well, good work!

  11. Very neat stuff, Alex. You are indeed a dangerous man :)

    I don’t know how I would use it though. The obvious use I guess is to expose in-house GTK+ apps to clients that aren’t running X…

    Can you select text? Does the clipboard work? You didn’t show very much keyboard interaction in the video.

    Just musing :) Happy hacking!

  12. @Luke Leighton this has been done with wx too, the problem with that is the reimplementation of everything

    By the way, you just proved neither desktop will defeat web nor web will defeat desktop.

  13. This is insane. Gives a whole new meaning to the term “web application.” Well, it doesn’t really, in the end this is exactly the same thing. But the fact that you can now run normal desktop GTK applications as web applications (possibly without modification) is just crazy.

  14. In some ways this can compete with Adobe Flex, I think — from what I remember of its use, people use it when they want web apps with a more desktop-like feel.

  15. This is superb! I am sure it will go a long way in reducing the amount of bytes downloaded to render an HTML page.

    Keep up the good work!

    Yes.. even I am interested to see how this can be done with QT. QT and KDE4 object layout is very well organized, so I think it should be simple.

  16. With VLC you are literally just getting a big picture of the screen. It captures your click co-ordinates and forwards it over the wire. With this GTK to HTML thing, the GUI front-end is actually running on your computer so there is never any graphical lag et cetera.

  17. This fucking awesome! You know you have created a monster?? Now all people are wanna want this. I can imagine a few use cases. A software project which let you try the program before installing it. Even useful for Linux distribution makers (think of a button on Ubuntu: try this program before installing it).

    I also can think of a pastebin-like service with a compiler and/or python interpreter where you can see the output of your code on the browser. Even for not needing to install a SDK for Maemo or similar projects, where the sdk resides on a remote server, and all you need to do is upload your source code.

    Not much related, but I think this also proves the need of a Client Side Window Decorations on Gtk+ itself :-)

Comments are closed.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>