moin, I somehow dislike the idea of having translatable strings in the simulation code. AFAICS this is for now needed for the model parameters implemented for each component. I’d like to move that out of the Component-code. I‘m fine with having the definition in this class, though. Here is my proposal.
We move all translatable strings into the circuit-library I created (for
sharing things between circuit-model, components and simulation) and just keep
references in the simulation code. This means, we should avoid QStrings in
this code, too. Instead QByteArray should be used. This has much less overhead
than QString has and will lead to smaller memory footprint. (QByteArray is
blain 8-bit ASCII, QString is 16-bit unicode and brings a lot of other
features we don’t need at this place) So the Component code will look
something like this:
m_properties.addProperty( QByteArray("resistance"), QVariant( (qreal) 5 ) );
I explicitly mentioned the types in here, you won’t need to write them in real
code. So in real code it would look more like this:
m_properties.addProperty( "resistance", QVariant(5.0) );
The mapping into the translated strings is then done by another class in the
library which reads the translated values from a config file. This config file
will look like this:
[resistance]
name=Resistance
name[gb]=Resistance
name[de]=Widerstand
…
unit=Ω
unit[veryForaignCountry]=some arbitrary unit here
This will be more easy for translators and we could reuse translations for
common properties. Technically this is a KConfig file, which is translatable
with the KDE tools, so translators can use the tools they are used to. Also
KDE ships parsers to easy access the values (it will also pick the right value
according to the locale set by the user, so no extra code on our side is
needed).
What do you think? Should we go this way? Then I’ll start implementing this
config file and you can add new properties on demand. I’ll also provide the
class that does the mapping from the "property-key" to the translated string
from this config file.
btw. in my master branch, there is first code to provide a properties editor
for components. Didn’t took long to write that. Still needs some love, but I
can add more features to it, when the simulator gets ready. For now, I’m
working on better interaction when editing circuit-files.
bye for now
julian
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
