Fwd: Re: kdereview/plasma/dataengines/nowplaying

[Aaron J. Seigo]

On Tuesday 01 April 2008, Albert Astals Cid wrote:
> QString translatedKey(const QString &key) const;
> function in the dataengine?
>
> That does something like
> if (key == "Artist") return i18nc("The performer of a song", "Artist");
> else if (key == "Track") return i18nc("The track of  song", Track");
> ...
>
> In my opinion fixes the issue of calling i18n over a string that you did
> not generate yourself and places the responsability where it's due.

this results in people having to write a lot more code on both the engine and 
visualization side. that's really against the grain of plasma where the goal 
is make writing add ons simple and quick.

the engine side plausibly fixable by storing a dictionary from key names to 
translated names. more memory consumption, but probalby not all that much. 
perhaps adjust setData(key, data) to be setData(key, translatedKey, data). 
not particularly pretty, but would enforce usage.

it gets tricker on the visualization side: now we can't just show the key text 
in the client side, we have to also always call translatedKey from the engine 
it came from. that information (which engine) is not always going to be 
available to what is showing it, for any number of reasons. this is made even 
trickier by the fact that these messages likely exist in different plugins 
anyways (something we already deal with probably)

shipping the DataEngine* around with dataUpdated would rather suck because it 
creates a tighter coupling between both sides and it will encourage 
visualization writers to Do The Wrong Thing(tm) in other situations. this is 
a real uglification of the API. so let's consider that to be "not an option".

DataEngine::Data could be modified from QString -> QVariant to be .. gah.. i 
don't know what it would be without either breaking lots of existing code or 
just plain fugly. QString -> QPair<QString, QVariant> ? oi vey.... 

we can't just ship the Data with the translated keys rather than the given 
keys otherwise we lose the ability to map across them.

the alternative to all this is to simply require that all acccess into Data is 
wrapped in i18n calls on both sides. so visualizations that care about key 
names would have to do, e.g.:

setText(data[i18n("Annoyance")]);

of course, getting the contexts the same on both sides will still matter. it 
also means that these keys are not reliably storable as identifiers since 
other things may influence them, e.g. the selected language and translation 
packs available.

-- 
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/20080401/49b8ce39/attachment.pgp