Important: Please read the Qt Code of Conduct -

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

  • I use QSettings to keep settings on hard disk. And I use QVariantMap to keep and access them inside program. Each setting has it's unique key name written by Latin characters. This time all works well. But I need store additional info to each key/value pair. It is - human readable pair name in national alphabet. This pair will be shown in settings dialogue to be read by user. First of all it is Cyrillic alphabet but not only. Here I don't have final solution yet and want ask for advice.

    Is it possible make keys with non-Latin characters? If yes then I could just use Cyrillic names for keys. But how this can be made multiplatformed? If not - how it is better implement this using QSettings?

    For while I see one possible solution - turn from QSettings and make own settings storage in XML. This is not so hard to implement cause I already use XML to save some schemes in this application. In XML I can keep national labels just in attributes. But QSettings is much more easy to use.

  • I will not advise to use non-latin chars in keys. DOn't see any problems here, but you will need always to remember about encoding and so on. Better I think to store these localized names either in translation (and use them with tr() method) or store as additional values in your settings file. But of course translation way is more correct.

  • Ok, looks like it works. But I need keep multiplatform compatability. Settings file created on one platform must be clearly recognized on another. Unfortunately now I can work only on one platform - Windows. Other platform will be Linux. Looks like after tr() key name is kept in unicode and won't provide any problem. Am I right?

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

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

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

  • 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:

  • 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]

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

    class SettingsEntry {
    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.

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

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

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

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

  • Moderators

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

Log in to reply