KDEREVIEW: nowplaying dataengine and applet for plasma

[Aaron J. Seigo]

On Sunday 10 February 2008, Alex Merry wrote:
> aacid was rather... lukewarm... to the idea that we were using translatable
> strings as keys.

it has to, however. why? so that people writing applets can simply list 
key/value pairs and not have the keys show up in English. there's an ongoing 
assumption amongst many DataEngine developers that people will always know 
the keys. they won't.

this will really become an issue when we finally provide a GUI designer.

i'll leave it up to you whether or not you want to translate your keys, i 
guess, but know that it will cause English text to appear in UIs in the 
future for people running non-English desktops.

> > * providing a "help" source is interesting. perhaps we should make that
> > standard, though really ... that's for people designing widgets, isn't
> > it? it's not particularly for the actual usage of the engine.
> > documentation is an unanswered question with engines, and it would be
> > good to provide a better way to do this that doesn't involve having to
> > open up khelpcenter either.
>
> That's on my TODO list for 4.1.  For now, it provides a way of people
> getting the doc without reading the source.  Once we have a better way,
> I'll probably scrap the "help" and "properties" sources.

... well, again .. i wonder if we shouldn't make that a common practice. some 
common way to get help out of the engine as to how to use that specific one. 
what it does, what it offers, etc.

i'm about to do the same with runners so we can expose the syntax they 
understand.

> > * using DataEngine for a command sink is actually rather wrong from the
> > design perspective of DataEngine. i'm sure it works, but it's really not
> > what Engine was designed for. there's no feedback on success, for
> > instance. we discussed this exact issue in the plasma meeting Saturday
> > and we decided to provide a more appropriate interface for commands as
> > it's a common need. but DataEngine is designed to provide access to data,
> > in a one-to-many relationship which makes these things not so fun to do.
>
> Yes, but we only had the meeting yesterday :-P
>
> As soon as we have a DataService class, that will go.

cool.. that's one of my two main tasks this week.

> > on to the applet:
> >
> >     dataEngine("nowplaying")->connectSource("Players", this, 5000);
> >
> > should the players source update itself? polling is Bad(tm). what should
> > probably be happening in the engine is in addPlayer, the Player source
> > should be being updated. that is constant data that is always available
> > and pretty much required, after all. then you can get rid of the 5s poll
> > above and just connect to the source normally.
>
> Point.  Will change, although addPlayer() isn't where it should be (Juk and
> XMMS are added using addPlayer() even if they don't exist, because the
> object needs to be there to check whether the player exists...)

makes sense.

> >     connect(this, SIGNAL(geometryChanged()), this, SLOT(sizeChanged()));
> >
> > what you probably really want to do is respond to the SizeConstraint in
> > constriantsUpdated. you also don't want to call updateGeometry()
> > indiscriminently in constraintsUpdated(). in fact, updateGeometry is
> > called for you when needed before constraintsUpdated() is called; the
> > only time the applet should need to call it is when it changes its own
> > geometry.
>
> OK.  The API docs really need more work.  *notes that this is on his own
> TODO list for 4.1*

yeah. i find it's often only when people use the APIs that i discover what 
really needs to be documented in them ;)

> I got a little confused by what was and wasn't required or possible in
> constraintsUpdated().

ok ... if you don't get around to it, i'll spiff up the docu for 
constraintsUpdated() a bit. this is also really why i *must* write those 
techbase articles to cover all these oddnesses.

honestly, it's one of the biggest pains of not creating a stricly traditional 
system: we lose out on all the learned behavoiurs peopls have built up 
developing more traditional things in the past. for that reason alone i'm 
really grateful to everyone who is sticking with it =)

-- 
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: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080210/5326d96d/attachment-0001.pgp