A few issues of porting Google Gadgets to plasma

Dong Tiger idlecat511 at gmail.com
Thu Jul 3 05:02:48 CEST 2008


2008/7/3 Aaron J. Seigo <aseigo at kde.org>:

> 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?
>
Nice to see you too:)

>
> 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.


Agree that "Install New Widgets" should be able to handle this. But I still
feel it will be convenient to be able to ask plasma to load a gadget. It can
be used in the following cases:
1. User clicks a dowloaded widget to run it.
2. Some programs can be turned into a widget on the fly. For example, Amarok
can minimize itself to a widget on panel.
3. Before "Install New Widgets" is powerful enough, I still need this to let
user browse google gadgets in GoogleGadgetsBrowser and install them into
plasma.

>
> > 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.
>

There are two kinds of Google gadgets. One is the iGoogle Gadgts which just
use html/javascript. The other is Desktop Gadgets which uses self-brewed xml
and javascript. Plasma::WebContent will only works with the iGoogle gadgets.

>
> 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)


The javacript runtime in GGL is used to support Desktop Gadgets. So web dom
api is not needed. The problem is that many gadgets use non-ECMAScript
syntax like "someobj('APropertyNmae') = something;". It's truely not the
fault of QtScript. We are working on eliminating the usage of such syntax.
But it takes time.


> >  And I don't have much confidence on the quality of QtScript.
>
> anything in particular? (it's easier to fix non-vague problems ;)

 I don't mean QtScript is not good. I just mean it's not widely used as
spidermoney and webkit, especially in the way I use. As of bugs, I just
filed one that QtScript crashed on this:
  var a = new Array(); a.splice(0, 0, 'a');


> >     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 --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20080703/0f6624bc/attachment.html 


More information about the Panel-devel mailing list