29

http://blogs.gnome.org/alexl/2011/03/15/gtk-html-backend-update/

This new backend allows Gnome applications to run as a service over the internet, in a much more streamlined/simplified approach when compared to VNC/FreeNX/what have you. Essentially, this instantly makes GTK and Gnome run on more platforms than KDE currently does, and any platform with an HTML5 capable browser (in the near future).

As far as I've researched, Qt has no equivalent option. Also, so far as I know, KDE might have much less control over Qt development than I'm aware. However, if there is some way we can promote this feature in Qt or KDE itself, I think it would be well worth it to instantly port our applications to new platforms. Provided it's practical enough, this could change the way people use software, and bring us far past the commercial competition.

Feel free to mark this invalid if it's an issue that should be taken up directly with Qt.

Though I am not a fan of web frontends and web applications I think this idea does make sense.
There is some russian developer who implemented something that came close though he used another approach: the GLAN project (http://ostatic.com/glan) uses a native application (or a browser plugin) as a seed to connect to a server to load the application. In basic he has added a network transparence layer in Qt. It is fast, but nearly undocumented and never gained much supporters as far as I can see.
This html5 approach solves the same idea without a native application or plugin.

But there is one catch (please correct me, I hope I am wrong): sure it should be possible to implement html5 based widgets equivalent to those offered in GTK/Qt. But this can only work for basic widgets, those we find in the basic libraries. For application developers this means that they have to double their effort because they have to port every new widget they implement additionally to html5.
Maybe this can be reduced to only those widgets that are _not_ based on standard widgets (that are not recombinations), but somehow I doubt that. Generic projection sounds to complex to me to actually work in all cases.
Nevertheless it does make sense to explore this option. Web browsers will become more and more spread, used and capable as frontend canvases for everyday stuff. So why not use them in a really generic way.

Have fun !

This is what I love about the open source community- the same people who are into a stylish DE are into fringe software for crazy uses. Great job picking that up to show us.

I don't know the exact mechanics of Alexander's work on broadway, but from what I read it seems that he approached it from a perspective where, if you can generalize on it and make the widget work with the toolkit's elements alone, it should be able to be compressed and rendered in that format, rather than sending the data across as an image to be refreshed. However, everything that can't simply be handled by GTK is transmitted as compressed png data in Broadway. So I'm guessing that if a developer has a customized widget that can't be parsed in such a generic way, it will simply be sent as a graphical diff with everything else.

Again, I'm not completely up on toolkit terminology and graphical rendering at the moment, but I'll discuss it with some KDE programmers I know to see how feasible it is with Qt. From what I can tell, Qt is much easier to work with than GTK, so while it's got more features as a toolkit, it might be easier to code this backend for Qt than GTK. I'd like to get some relevant developers in on the discussion, at least.

Certainly, one could leverage work on Wt, see http://www.webtoolkit.eu/wt. Also for Java fans, there's JWt, see http://www.webtoolkit.eu/jwt

Approved until somebody tells me that it should be taken up with the Qt folks.

It would be a Qt thing, but that doesn't mean it can't be done by someone from KDE, so I agree on keeping it open.

> Essentially, this instantly makes GTK and Gnome run on
> more platforms than KDE currently does

This statement is false. It doesn't allow gtk apps to run on a lot of platforms, but to display on a lot of platforms while running somewhere else.

As you said, this is just like (behaviour-wise) having an X server on your machine that displays an application.

I'm surprised that nobody wrote a html5 x server yet - we have/had java x server applets, native browser applets etc. but now when browsers are powerful enough to do the same w/o a plugin, nobody tries to do it.

--

Now back on the topic: since Qt already supports various different graphics backends, the framework for this is in place. You just need to find somebody with html5 knowledge and a lot of free time to implement it

Another thing is that somebody (can't find the blog post) wrote a .ui to .svg converter - essentially painting a window to an svg file

arkascha wrote:Though I am not a fan of web frontends and web applications I think this idea does make sense.
There is some russian developer who implemented something that came close though he used another approach: the GLAN project (http://ostatic.com/glan) uses a native application (or a browser plugin) as a seed to connect to a server to load the application. In basic he has added a network transparence layer in Qt. It is fast, but nearly undocumented and never gained much supporters as far as I can see.
This html5 approach solves the same idea without a native application or plugin.

But there is one catch (please correct me, I hope I am wrong): sure it should be possible to implement html5 based widgets equivalent to those offered in GTK/Qt. But this can only work for basic widgets, those we find in the basic libraries. For application developers this means that they have to double their effort because they have to port every new widget they implement additionally to html5.
Maybe this can be reduced to only those widgets that are _not_ based on standard widgets (that are not recombinations), but somehow I doubt that. Generic projection sounds to complex to me to actually work in all cases.
Nevertheless it does make sense to explore this option. Web browsers will become more and more spread, used and capable as frontend canvases for everyday stuff. So why not use them in a really generic way.

Have fun !

GTK+ broadway uses Canvas element and EcmaScript! So we can uses this to any widget.

My understanding of this technology is that it allows Gtk applications to be efficiently run through networks. As all that is required is an HTML5 based browser on the client, could a low power ARM chipset tablet type gadget be used?

The advantages of this could be longer power life and I would imagine keep costs down as a lower spec of processor would be required. This would be ideal for educational establishments that could provide the infrastructure to allow these 'dumb terminals' tablets to connect to a network to allow these applications to run or even round the house where the tablet could be connected to the main PC and other gadgets like a printer via wifi. Again, this would allow a really cheap tablet type device to be produced.

Apologies for any lack of in-depth knowledge of what I am commenting on and the rather rambling nature of it as I am just putting down some thoughts on an idea I have which I don't know is technically possible or feasible.

EDIT:

I found a link to this which describes a tablet type device which could be useful for the type of technology described in original post.

http://www.pcworld.com/businesscenter/a ... tk=mod_rel