QMap/QSettings - need store key names or additional labels in national alphabets

DenisKormalev

You don't need to tr() name for using it as key. Use latin names as keys and show tr()'ed ones.

Gourmand

bq. You don’t need to tr() name for using it as key. Use latin names as keys and show tr()‘ed ones.

Again - There is no question with Laitn key names. But I need Cyrulllic key names. Or I have to create parallel map with Cyrillic names for each Latin key. Or even turn to my own XML format instead of QSettings. All this requires extra coding and wastes time.

For while I used Cyrillic key names with tr(). But I cannot now test compatability in Linux.

DenisKormalev

Can you say why do you need cyrillic names? If I understood your problem correctly you need to show cyrillic names, but not store them in your settings internally. So you just use latin names and wrap them with tr() when you need to show them to user. After it you add translation to your application and fill it with Linguist. And you are done! You have latin names in your settings and you have cyrillic names in UI.

goetz

If you have a fixed set of settings, hardwire the names in the UI (in english or the standard language you use for your application) and use the means of Qt for translating the visible strings into the target language.

You most certainly will not want the keys of your settings to change between platforms and languages.

Also, stick for easy keys in the Settings, and stick to 7bit ASCII to be on the sure side for platform independence.

IMHO, it's a bad design to show the settings' keys to your users (translated or not does not matter).

See the following links for some details on the translation process in Qt:

"Qt Linguist for programmers":http://developer.qt.nokia.com/doc/qt-4.7/linguist-programmers.html
"Qt Linguist manual":http://developer.qt.nokia.com/doc/qt-4.7/linguist-manual.htmljj
"Qt Linguist examples":http://developer.qt.nokia.com/doc/qt-4.7/examples-linguist.html

Gourmand

bq. If you have a fixed set of settings

No, list of settings is dynamic. Actually this is following:

application consists from extendible number of plugins
each plugin has it's own set of settings, which is stored in QVariantMap
main application (or "core") takes all functionality to store settings, and creates dialogue to let user edit them
each plugin only uses settings which gets from core - this greatly simplifies plugin design, plugin does only what it must to do
if core sends empty set of settings to plugin - that means there was no settings file created yet, then plugin makes set of it's default settings and sends them to core, after that core manages plugin settings completely

All this works fine but settings must have Cyrillic names - to show them in settings dialogue. This is mandatory. This dialogue is created by core. But core doesn't know names after startup. Only plugins know. And of course it is not known for future - which settings with which names will be defined in future plugins.

Similar settings technique used in Mozilla FireFox, Miranda IM and other "constructor set"-like applications. I'm creating application in same class.

QMap can hold only pair of key/value. If only it could hold unlimited number of fields with one key - this would be GREAT. I could create something like this:

@
QMap<key, value, national_name, tooltip, doc_link>
@

Now I see only how to manage this using XML:

@
<setting name="latinname", value="value", readable="cyrillic comment", tooltip="tooltip text", docurl="file://link_to_page"></setting>
@

or something similar. But this will take time to implement. At least XML cannot store QVariant out-of-the-box but QSettings can.

bq. you just use latin names and wrap them with tr() when you need to show them to user. After it you add translation to your application and fill it with Linguist

This will greatly complicate plugins development. But I contrary try simplify it.

[EDIT: list & code formatting, Volker]

goetz

Then I would go with some tiny helper class to store all the stuff:

@
class SettingsEntry {
public:
QString key;
QVariant value;
QString displayName; // national_name
QString tooltip;
QString doclink;

SettingsEntry(const QString &key, const QVariant &defaultValue, const QString &name, const QString & tooltip, const QString &doclink);

};

typedef List<SettingsEntry> SettingsEntryList;

// --- in your plugin:

SettingsEntryList pluginSettings;

pluginSettings << SettingsEntry("username", QVariant(), tr("user name"), tr("enter your username here"), tr("qrc:/path/to/doc"));
pluginSettings << SettingsEntry("password", QVariant(), tr("password"), tr("enter the password here"), tr("qrc:/path/to/doc"));
@

The trick is the tr() for the display name etc. This makes everything translatable. Just make sure your plugin provides the translations or you load them together with the plugin.

You might want to use a QHash instead of a QList and use the key there. The key would be the index into QSettings.

Gourmand

There is no question how to work with that in core. The question is - how better store it in settings file. Stored settings must be multiplatformed. Same settings file must be loaded and all settings must be visible and editable in Windows and Linux versions of app (if same sets of plugins they have).

Another question - how easer implement this. QSettings are very simple to operate. XML is little more complex.

For now only pair key-vaule is enough. And QSettings probably is enough (if only I'll not have in Linux some troubles with Cyrillic keys stored in Windows). But other fields (tooltip etc) could be needed at future.

goetz

QSettings is meant to store the values of your settings. Nothing less, nothing more.

Everything else is up to the application, including the translation of displayable strings

Why do you want to store some stuff that is never changed, like a tool tip, in a QSettings? Your application design appears quite weird to me, sorry.

Gourmand

bq. Why do you want to store some stuff that is never changed, like a tool tip, in a QSettings?

That was a sample. Something can be changed, something not... Some permanent stuff will not be saved. But some must be.

goetz

Sorry, I'm out - I just don't get the point. The design is broken in my opinion. Good luck for your further attempts.

mlong

You're probably going to be better off, then, using an XML file. That way you have complete control of what you store and how you store it. If you're working outside the parameters of the normal behavior of the QSettings class, then the extra work to wrap data around your own storage system would probably be worth the effort.

You can always mimic the appropriate subset of the QSettings API, if you find it convenient to use in your code (as far as loading and saving values.)