Fwd: Re: kdereview/plasma/dataengines/nowplaying

[Albert Astals Cid]

A Dimecres 02 Abril 2008, Aaron J. Seigo va escriure:
> 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. 

A function with some if and a call to translatedKey() when showing the key is 
not "a lot more code" imho

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

That could be a problem yes.

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

Right.

> 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")]);

Imho not possible, where are you going to get the context from?

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

So we don't have a solution?

Albert