A few issues of porting Google Gadgets to plasma

[Aaron J. Seigo]

hi Dong...

good to see you on the lists. btw, panel-devel at kde.org is the more useful list 
for plasma related issues. i'm cc'ing the list on this reply and maybe we can 
take the discussion over there?

On Wednesday 02 July 2008, Dong Tiger wrote:
> 1. GGL(Google Gadgets for Linux) has its own GadgetBrowser. I want to use
> it to install gadgets and add gadgets to desktop as an plasma applet. Does
> plasma support this?

no.

while i understand the apparent benefit from the gadget creator's POV (hey 
look, we can make it exactly how *we* want it!) it really doesn't do much at 
all for the user experience. in fact, it rather destroys the user experience 
because now they have to deal with N different control and listing UIs for 
their widgets. that's obviously not great.

what we don't have yet in plasma is a way for gadget systems to provide links 
to their own listing systems. right now we provide support for DXS (the fd.o 
spec for listing app add-ons over the network). while i'd love to see everyone 
adopt DXS, i doubt that's realistic. the easiest thing to do would probably be 
to extend the capabilities of the "Install New Widgets" button to allow 
additional mechanisms to get widgets.

> 2. We have a QWidget subclass, QtViewWidget, that can draw a view of a
> Google gadget and accept input from mouse and keyboard. To reuse the code,
> I tried to use WoC approach. But the result is not so good. Check out the
> screen shot attached. The black part is supposed to be transparent. What I
> can do with it?

you may need to call setAttribute(Qt::WA_NoSystemBackground) on your QWidget. 

it would also probably be even better if it was at some point ported to a 
QGraphicsWidget, and maybe even use Plasma::WebContent directly? i mean, the 
Google widgets are just html/css at the base of it all, right? that might be a 
lot of work, though, depending on how the gadgets library is implemented.

i also see the sizing is wrong: it's not sized to the contentsRect() but to 
the boundingRect(). use contentsRect() always.

> 3. Currently, GGL has one stable javascript runtime which is implemented
> with spidermonkey. I don't feel comfortable that GGL on plasma has to link
> to spidermonkey. So I wrote a runtime with QtScript. But it turned out a
> lot of Google gadgets use syntax from M$ jscript that QtScript doesn't
> support.

well, QtScript isn't really javascript, of course. it's ECMAScript, so you'd 
have to do a lot of work on top of it to turn it into JavaScript (ECMAScript + 
the web dom API)

>  And I don't have much confidence on the quality of QtScript.

anything in particular? (it's easier to fix non-vague problems ;)

>     Thus, I need to choose between kjs and webkit. But QtWebKit doesn't
> support standalone usage of its javascript engine. It looks only kjs is a
> valid choice. What do you think?

this would be a simple if you were using Plasma::WebContent as it already has 
the webkit js runtime there. if you're going to do your own runtime from 
scratch, though, kjs is probably the easier starting point, yes.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080702/f2cb0e78/attachment.sig>