applicationDisplayName vs applicationName? applicationDisplayName as QSettings Key?

CJha

Hi, what is the purpose of having two distinct names for an application: QGuiApplication::applicationDisplayName vs QCoreApplication::applicationName?

My application has more than one user and I am planning to set applicationDisplayName for each user and then to save settings belonging to that user using this as a QSettings group key. I have tested it and it seems to work fine, but I want to be sure if applicationDisplayName is used anywhere else (except for in the window title) or not? Because, if it is then I won't use it so that I don't run into problems later down the line.

SGaist

Hi,

As the documentation of the function says, it's for user facing text and it can also be translated. The other one will be used for example with QSettings for their path.

CJha

@SGaist Hi, thanks! So can I change either while the application is running? Will this cause any issues? (I tried it and for now, it seems to cause no problems)

For the QCoreApplication::applicationName the document says:

The value is used by the QSettings class when it is constructed using the empty constructor. This saves having to repeat this information each time a QSettings object is created.

So changing QCoreApplication::applicationName would mean that my settings object would be different and I can use this to store different users settings, i.e. each user will have its own `QCoreApplication::applicationName' and whenever a user is switched while the application is running the settings object is changed automatically and so correct user data is retrieved. Does it make sense?

JonB

@CJha
This way of playing with application name does not sound "nice" to me.

I think you should look at enum QSettings::Scope and

QSettings::UserScope 0 Store settings in a location specific to the current user (e.g., in the user's home directory).

That is how you are intended to store settings if you mean separately for each system user. I don't know if you might mean they are only "your own" users though.

SGaist

As @JonB wrote, that's a very wrong idea.

Each user usually have a different account on their machine, therefor your settings will be in any case stored in a user specific location.

CJha

@JonB @SGaist Thanks! By different users, I mean "my own" users and not different system/OS level users. My application is made in a way that it can have multiple users of its own in a single installation, without changing the user account on the OS level. To achieve this I have a master group key for each user and any settings value that is stored is placed hierarchically under this master group key. This master group key is what I was thinking to replace by either applicationDisplayName or applicationName. Using QSettings::UserScope enum will simply not work here.

JonB

@CJha
Yes, I wondered if you might be non-OS users.

I understand how your approach works, but it still doesn't feel right. From something you said earlier, do you actually alter the application name (repeatedly) while (one instance) is running? I see there is an applicationNameChanged signal, doubtless used by QSettings, so maybe this is supported OK, but it feels "hokey" to me.

See what @SGaist thinks....?

SGaist

You should still not play with the application name.

Build the settings path yourself explicitly. This will be safer.

CJha

@JonB Yeah, I was thinking of doing this because there are signals for both applicationDisplayNameChanged() & applicationNameChanged() this can provide me with an application-wide signal to change users. My application has different modules which are completely independent of each other (I have to develop a lot of custom applications where not each application has to have all modules, and so independent modules are the best idea), the common things among these modules are stored directly inside a namespace (every module is also inside this namespace) and so I need an application-level signal to propagate common settings for my application, i.e. current user master key, current font and current palette. For font and palette, QApplication provides the respective ..changed() signal but there is no way for me to add an application-level signal for the master user key without creating a singleton, which I very much want to avoid, that's why I was thinking of using applicationDisplayName as master user key :)

@JonB @SGaist Thanks for the insight, I will figure out a different way then.

P.S. It would be nice to have a void QCoreApplication::broadcast(const QString& string) signal, the string could be modified in different ways to provide different values to the broadcast :)