Qt-interest Archive, February 2007
Declaring a global Qsettings ?
Pages: Prev | 1 | 2 | 3 | Next
Message 16 in thread
On Feb 24, 2007, at 4:03 PM, Scott Aron Bloom wrote:
> Well.. jump to your left... a step to right... put your hands on your
> hips.. a pelvic thrust, followed by a hip swivel… Then “Lets do the
> Time warp again...”
If you are going to quote lyrics, please do it properly :)
http://www.stlyrics.com/lyrics/therockyhorrorpictureshow/thetimewarp.htm
It's just a jump to the left
And then a step to the right
With your hands on your hips
You bring your knees in tight
But it's the pelvic thrust that really drives you insane,
Let's do the Time Warp again!
--
[ signature omitted ]
Message 17 in thread
> From: Dan White [mailto:ygor@xxxxxxxxxxx]
> Sent: Saturday, February 24, 2007 2:14 PM
> To: Scott Aron Bloom
> Cc: Qt Interest
> Subject: Re: Declaring a global Qsettings ?
>
>
> On Feb 24, 2007, at 4:03 PM, Scott Aron Bloom wrote:
> > Well.. jump to your left... a step to right... put your hands on
your
> > hips.. a pelvic thrust, followed by a hip swivel... Then "Lets do
the
> > Time warp again..."
>
> If you are going to quote lyrics, please do it properly :)
>
>
http://www.stlyrics.com/lyrics/therockyhorrorpictureshow/thetimewarp.htm
>
> It's just a jump to the left
> And then a step to the right
> With your hands on your hips
> You bring your knees in tight
> But it's the pelvic thrust that really drives you insane,
> Let's do the Time Warp again!
Yeah but I did mine from memory... :)
--
[ signature omitted ]
Message 18 in thread
Hi,
> I'm trying to use a Qsettings at global scope.
>
> I would like to avoid declaring every here and there in my application
> QSetting settings("myProg");
> for having access to settings.value();
I would recommend against using a QSettings object at global scope. The
reason is that it is crucial you make sure the destructor of QSettings
objects is called, or at least that QSettings::sync() is called:
http://doc.trolltech.com/4.2/qsettings.html#dtor.QSettings
QSettings::~QSettings()
Destroys the QSettings object.
Any unsaved changes will eventually be written to
permanent storage.
http://doc.trolltech.com/4.0/qsettings.html#sync
void QSettings::sync()
Writes any unsaved changes to permanent storage, and
reloads any settings that have been changed in the
meantime by another application.
I think the overhead of declaring QSettings objects every here and there
in your application is not worse than the overhead of making sure
QSettings::sync() is called or global QSettings objects are destructed.
My suggestion: Use a global string such as :
const char *organization = "myProg";
and keep declaring QSettings every here and there:
QSettings settings(organization);
> I have tried several syntaxes to be able to declare settings as a QSettings
> in my 'global.h', and then access the values from everywhere, but I did not
> succeed.
>
> Any idea ?
I you insist you could declare in your global.h:
extern QSettings theSettings;
and define in a *.cpp file:
QSettings theSettings("myProg");
However I would recommend against global objects in C++ programs because
you have no control over the construction and destruction of global
objects - what if QSettings needs a QApplication instance for example?
Otherwise use a singleton as suggested elsewhere. But then how do you
control the destruction of this single QSettings instance?
--
[ signature omitted ]
Message 19 in thread
hmm.. very interesting.
what if I provide a second method in the Singleton, called destroyInstance()?
I would then call it in the closeEvent of my QMainWindow (where I would do the settings writing
anyways).
manu.
Dimitri wrote:
> Hi,
>
>> I'm trying to use a Qsettings at global scope.
>>
>> I would like to avoid declaring every here and there in my application
>> QSetting settings("myProg");
>> for having access to settings.value();
>
> I would recommend against using a QSettings object at global scope. The
> reason is that it is crucial you make sure the destructor of QSettings
> objects is called, or at least that QSettings::sync() is called:
> http://doc.trolltech.com/4.2/qsettings.html#dtor.QSettings
> QSettings::~QSettings()
> Destroys the QSettings object.
> Any unsaved changes will eventually be written to
> permanent storage.
> http://doc.trolltech.com/4.0/qsettings.html#sync
> void QSettings::sync()
> Writes any unsaved changes to permanent storage, and
> reloads any settings that have been changed in the
> meantime by another application.
>
> I think the overhead of declaring QSettings objects every here and there
> in your application is not worse than the overhead of making sure
> QSettings::sync() is called or global QSettings objects are destructed.
>
> My suggestion: Use a global string such as :
> const char *organization = "myProg";
> and keep declaring QSettings every here and there:
> QSettings settings(organization);
>
>> I have tried several syntaxes to be able to declare settings as a
>> QSettings
>> in my 'global.h', and then access the values from everywhere, but I
>> did not
>> succeed.
>>
>> Any idea ?
>
> I you insist you could declare in your global.h:
> extern QSettings theSettings;
> and define in a *.cpp file:
> QSettings theSettings("myProg");
> However I would recommend against global objects in C++ programs because
> you have no control over the construction and destruction of global
> objects - what if QSettings needs a QApplication instance for example?
>
> Otherwise use a singleton as suggested elsewhere. But then how do you
> control the destruction of this single QSettings instance?
>
> --
> Dimitri
--
[ signature omitted ]
Message 20 in thread
Hi,
> what if I provide a second method in the Singleton, called
> destroyInstance()?
> I would then call it in the closeEvent of my QMainWindow (where I would
> do the settings writing anyways).
Yes, that would work. But keep in mind that the real burden is not
writing the code but maintaining it.
You'll have to document where to call destroyInstance() from. Even if
you document this, it's quite possible that the code is modified later
on and that destroyInstance() is called before an additional access to
instance() in spite of the documentation.
Of course you may protect QGlobalSettings::instance() the following way
and emit en error message but why risk this?
QSettings *QGlobaSettings::instance() {
static QSettings *ptr = 0;
static bool firstetime = true;
if (!ptr) {
if (!firstetime) {
// EMIT AN ERROR MESSAGE AND ABORT?
}
ptr = new QSettings(...);
firstetime = false;
}
return ptr;
}
QGlobaSettings::destroyInstance() {
if (ptr) {
delete ptr;
ptr = 0;
}
}
--
[ signature omitted ]
Message 21 in thread
hmm.. ok.
what if I do something like this:
QGlobalSettings * QGlobalSettings::getInstance(QObject *parent)
{
if(!_settings) {
_settings = new QGlobalSettings(..);
}
if (_settings->parent() != parent) {
_settings->setParent(parent);
}
return _settings;
}
one class would always be responsible for destruction. well, and only QObject subclasses could
access the settings, but that's fine for me..
is that stupid?
cheers,
manu
Dimitri wrote:
> Hi,
>
>> what if I provide a second method in the Singleton, called
>> destroyInstance()?
>> I would then call it in the closeEvent of my QMainWindow (where I
>> would do the settings writing anyways).
>
> Yes, that would work. But keep in mind that the real burden is not
> writing the code but maintaining it.
>
> You'll have to document where to call destroyInstance() from. Even if
> you document this, it's quite possible that the code is modified later
> on and that destroyInstance() is called before an additional access to
> instance() in spite of the documentation.
>
> Of course you may protect QGlobalSettings::instance() the following way
> and emit en error message but why risk this?
>
> QSettings *QGlobaSettings::instance() {
> static QSettings *ptr = 0;
> static bool firstetime = true;
> if (!ptr) {
> if (!firstetime) {
> // EMIT AN ERROR MESSAGE AND ABORT?
> }
> ptr = new QSettings(...);
> firstetime = false;
> }
> return ptr;
> }
>
> QGlobaSettings::destroyInstance() {
> if (ptr) {
> delete ptr;
> ptr = 0;
> }
> }
>
> --
> Dimitri
--
[ signature omitted ]
Message 22 in thread
oh, one object (not class) would be responsible for destruction, of course..
Manuela Hutter wrote:
> hmm.. ok.
>
> what if I do something like this:
>
> QGlobalSettings * QGlobalSettings::getInstance(QObject *parent)
> {
> if(!_settings) {
> _settings = new QGlobalSettings(..);
> }
> if (_settings->parent() != parent) {
> _settings->setParent(parent);
> }
> return _settings;
> }
>
> one class would always be responsible for destruction. well, and only
> QObject subclasses could access the settings, but that's fine for me..
>
> is that stupid?
>
> cheers,
> manu
>
>
>
> Dimitri wrote:
>> Hi,
>>
>>> what if I provide a second method in the Singleton, called
>>> destroyInstance()?
>>> I would then call it in the closeEvent of my QMainWindow (where I
>>> would do the settings writing anyways).
>>
>> Yes, that would work. But keep in mind that the real burden is not
>> writing the code but maintaining it.
>>
>> You'll have to document where to call destroyInstance() from. Even if
>> you document this, it's quite possible that the code is modified later
>> on and that destroyInstance() is called before an additional access to
>> instance() in spite of the documentation.
>>
>> Of course you may protect QGlobalSettings::instance() the following
>> way and emit en error message but why risk this?
>>
>> QSettings *QGlobaSettings::instance() {
>> static QSettings *ptr = 0;
>> static bool firstetime = true;
>> if (!ptr) {
>> if (!firstetime) {
>> // EMIT AN ERROR MESSAGE AND ABORT?
>> }
>> ptr = new QSettings(...);
>> firstetime = false;
>> }
>> return ptr;
>> }
>>
>> QGlobaSettings::destroyInstance() {
>> if (ptr) {
>> delete ptr;
>> ptr = 0;
>> }
>> }
>>
>> --
>> Dimitri
--
[ signature omitted ]
Message 23 in thread
One of the problems, is QT has disabled copy turned on for QSettings
And there USED (QT 3.X) to be a major problem with collision of QSettings if you had multiple QSettings alive at the same time, so I used to have to have a singleton QSettings for the application.
However, I have confirmed that that bug is gone in qT 4.. However, if you do have non-standard/complex settings for QSettings, ie, you use a custom format, or you use your app version in the location, you have to have that setup at each instantiation. Which can be errorprone and cumbersome.
However, it would be great, if QT could extend QSettings with the following minor changes
Add static setOrginizationName and setAppName, setFormat and setScope methods to QSettings, that if set will override the QApplication settings AND will allow you to uses QSettings() for construction.
I understand why the copy is turned off, however, it prevents us developers from having a global function
QSettings getSettings()
which calls the proper constructor for our needs.
For instance I do use a version in my settings path, and I use a custom format! So for now, I use a smart pointer, that deletes on the scope, and a non-singleton implementation, but my init function calls the correct constrcutor for me.
Scott
________________________________
From: Dimitri [mailto:dimitri@xxxxxxxxxxxxx]
Sent: Sun 2/25/2007 2:08 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: Re: Declaring a global Qsettings ?
Hi,
> I'm trying to use a Qsettings at global scope.
>
> I would like to avoid declaring every here and there in my application
> QSetting settings("myProg");
> for having access to settings.value();
I would recommend against using a QSettings object at global scope. The
reason is that it is crucial you make sure the destructor of QSettings
objects is called, or at least that QSettings::sync() is called:
http://doc.trolltech.com/4.2/qsettings.html#dtor.QSettings
QSettings::~QSettings()
Destroys the QSettings object.
Any unsaved changes will eventually be written to
permanent storage.
http://doc.trolltech.com/4.0/qsettings.html#sync
void QSettings::sync()
Writes any unsaved changes to permanent storage, and
reloads any settings that have been changed in the
meantime by another application.
I think the overhead of declaring QSettings objects every here and there
in your application is not worse than the overhead of making sure
QSettings::sync() is called or global QSettings objects are destructed.
My suggestion: Use a global string such as :
const char *organization = "myProg";
and keep declaring QSettings every here and there:
QSettings settings(organization);
> I have tried several syntaxes to be able to declare settings as a QSettings
> in my 'global.h', and then access the values from everywhere, but I did not
> succeed.
>
> Any idea ?
I you insist you could declare in your global.h:
extern QSettings theSettings;
and define in a *.cpp file:
QSettings theSettings("myProg");
However I would recommend against global objects in C++ programs because
you have no control over the construction and destruction of global
objects - what if QSettings needs a QApplication instance for example?
Otherwise use a singleton as suggested elsewhere. But then how do you
control the destruction of this single QSettings instance?
--
[ signature omitted ]
Message 24 in thread
Hi,
> However, it would be great, if QT could extend QSettings with the following minor changes
>
> Add static setOrginizationName and setAppName, setFormat and setScope methods to QSettings, that if set will override the QApplication settings AND will allow you to uses QSettings() for construction.
But users can easily code that themselves, can't they? Inherit QSettings
and have the constructor set whatever is needed.
--
[ signature omitted ]
Message 25 in thread
On Tuesday 27 February 2007 00:52, Scott Aron Bloom wrote:
> Add static setOrginizationName and setAppName, setFormat and setScope
> methods to QSettings, that if set will override the QApplication settings
My vote for this, I have added this to all my apps.
Frank
--
[ signature omitted ]
Message 26 in thread
Sorry, I missed the start of this thread, but I think QSettings are
quite a bit easier than this. From the docs
(http://doc.trolltech.com/4.2/qsettings.html#basic-usage):
QCoreApplication::setOrganizationName("MySoft");
QCoreApplication::setOrganizationDomain("mysoft.com");
QCoreApplication::setApplicationName("Star Runner");
...
QSettings settings;
You only have to do the first three lines once. (I do mine right after I
make my QApplication in main().) Then, every call to QSettings can use
the default constructor. It sounds exactly like what you're looking for.
ry
> what about using a Singleton?
> http://www.dofactory.com/Patterns/PatternSingleton.aspx
>
>
>
> eb wrote:
> > I'm trying to use a Qsettings at global scope.
> >
> > I would like to avoid declaring every here and there in my application
> > QSetting settings("myProg");
> > for having access to settings.value();
> >
> > I have tried several syntaxes to be able to declare settings as a
QSettings
> > in my 'global.h', and then access the values from everywhere, but I
did not
> > succeed.
> >
> > Any idea ?
> >
> >
> >
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
"unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
>
--
[ signature omitted ]
Message 27 in thread
Ah, that looks interesting.
it raises 2 questions :
- can you then put 'Qsettings settings ; ' in a global .h file, and then
find it properly initialised / instanciated whenever you call it, or
- does your post mean you have to use 'QSettings settings' each time
(instead of QSettings settings("Star Runner") ) ?
Or is there something else ?
Ryan Bobko wrote:
> Sorry, I missed the start of this thread, but I think QSettings are
> quite a bit easier than this. From the docs
> (http://doc.trolltech.com/4.2/qsettings.html#basic-usage):
>
> QCoreApplication::setOrganizationName("MySoft");
> QCoreApplication::setOrganizationDomain("mysoft.com");
> QCoreApplication::setApplicationName("Star Runner");
> ...
> QSettings settings;
>
> You only have to do the first three lines once. (I do mine right after I
> make my QApplication in main().) Then, every call to QSettings can use
> the default constructor. It sounds exactly like what you're looking for.
>
> ry
>
>
>
>> what about using a Singleton?
>> http://www.dofactory.com/Patterns/PatternSingleton.aspx
>>
>>
>>
>> eb wrote:
>> > I'm trying to use a Qsettings at global scope.
>> >
>> > I would like to avoid declaring every here and there in my application
>> > QSetting settings("myProg");
>> > for having access to settings.value();
>> >
>> > I have tried several syntaxes to be able to declare settings as a
> QSettings
>> > in my 'global.h', and then access the values from everywhere, but I
> did not
>> > succeed.
>> >
>> > Any idea ?
>> >
>> >
>> >
>>
>> --
>> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
>> List archive and information: http://lists.trolltech.com/qt-interest/
>>
>>
>>
>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body. List archive and information:
> http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 28 in thread
On Sunday 25 February 2007 17:55, eb wrote:
> Ah, that looks interesting.
> it raises 2 questions :
>
> - can you then put 'Qsettings settings ; ' in a global .h file, and then
> find it properly initialised / instanciated whenever you call it, or
>
> - does your post mean you have to use 'QSettings settings' each time
> (instead of QSettings settings("Star Runner") ) ?
>
> Or is there something else ?
>
> Ryan Bobko wrote:
> > Sorry, I missed the start of this thread, but I think QSettings are
> > quite a bit easier than this. From the docs
> > (http://doc.trolltech.com/4.2/qsettings.html#basic-usage):
> >
> > QCoreApplication::setOrganizationName("MySoft");
> > QCoreApplication::setOrganizationDomain("mysoft.com");
> > QCoreApplication::setApplicationName("Star Runner");
> > ...
> > QSettings settings;
> >
> > You only have to do the first three lines once. (I do mine right after I
> > make my QApplication in main().) Then, every call to QSettings can use
> > the default constructor. It sounds exactly like what you're looking for.
> >
> > ry
> >
> >> what about using a Singleton?
> >> http://www.dofactory.com/Patterns/PatternSingleton.aspx
> >>
> >> eb wrote:
> >> > I'm trying to use a Qsettings at global scope.
> >> >
> >> > I would like to avoid declaring every here and there in my application
> >> > QSetting settings("myProg");
> >> > for having access to settings.value();
> >> >
> >> > I have tried several syntaxes to be able to declare settings as a
> >
> > QSettings
> >
> >> > in my 'global.h', and then access the values from everywhere, but I
> >
> > did not
> >
> >> > succeed.
> >> >
> >> > Any idea ?
> >>
> >> --
> >> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> >
> > "unsubscribe" in the subject or the body.
> >
> >> List archive and information: http://lists.trolltech.com/qt-interest/
> >
> > --
> > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> > "unsubscribe" in the subject or the body. List archive and information:
> > http://lists.trolltech.com/qt-interest/
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body. List archive and information:
> http://lists.trolltech.com/qt-interest/
I'm afraid I don't understand what you're trying to do. It seems like with the
code I recommended above (your second question), your code will just
contain "QSettings settings" and you're done. Which part of this are you
trying to avoid with the global? Do you just want a bunch of "settings" calls
splashed around your code? Wouldn't that be a lot harder to read and maintain
without the reassuring "QSettings" type right there?
Good luck,
ry
--
[ signature omitted ]
Message 29 in thread
true, a global QSettings object doesn't make sense in that case.
one reason could still be that you want to make sure that every QSettings object uses the same
non-default format (ini, xml, ..)
or is there a way to eg. set IniFormat as the default on all platforms?
cheers,
manu
Ryan P Bobko wrote:
> On Sunday 25 February 2007 17:55, eb wrote:
>> Ah, that looks interesting.
>> it raises 2 questions :
>>
>> - can you then put 'Qsettings settings ; ' in a global .h file, and then
>> find it properly initialised / instanciated whenever you call it, or
>>
>> - does your post mean you have to use 'QSettings settings' each time
>> (instead of QSettings settings("Star Runner") ) ?
>>
>> Or is there something else ?
>>
>> Ryan Bobko wrote:
>>> Sorry, I missed the start of this thread, but I think QSettings are
>>> quite a bit easier than this. From the docs
>>> (http://doc.trolltech.com/4.2/qsettings.html#basic-usage):
>>>
>>> QCoreApplication::setOrganizationName("MySoft");
>>> QCoreApplication::setOrganizationDomain("mysoft.com");
>>> QCoreApplication::setApplicationName("Star Runner");
>>> ...
>>> QSettings settings;
>>>
>>> You only have to do the first three lines once. (I do mine right after I
>>> make my QApplication in main().) Then, every call to QSettings can use
>>> the default constructor. It sounds exactly like what you're looking for.
>>>
>>> ry
>>>
>>>> what about using a Singleton?
>>>> http://www.dofactory.com/Patterns/PatternSingleton.aspx
>>>>
>>>> eb wrote:
>>>>> I'm trying to use a Qsettings at global scope.
>>>>>
>>>>> I would like to avoid declaring every here and there in my application
>>>>> QSetting settings("myProg");
>>>>> for having access to settings.value();
>>>>>
>>>>> I have tried several syntaxes to be able to declare settings as a
>>> QSettings
>>>
>>>>> in my 'global.h', and then access the values from everywhere, but I
>>> did not
>>>
>>>>> succeed.
>>>>>
>>>>> Any idea ?
>>>> --
>>>> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
>>> "unsubscribe" in the subject or the body.
>>>
>>>> List archive and information: http://lists.trolltech.com/qt-interest/
>>> --
>>> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
>>> "unsubscribe" in the subject or the body. List archive and information:
>>> http://lists.trolltech.com/qt-interest/
>> --
>> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
>> "unsubscribe" in the subject or the body. List archive and information:
>> http://lists.trolltech.com/qt-interest/
>
> I'm afraid I don't understand what you're trying to do. It seems like with the
> code I recommended above (your second question), your code will just
> contain "QSettings settings" and you're done. Which part of this are you
> trying to avoid with the global? Do you just want a bunch of "settings" calls
> splashed around your code? Wouldn't that be a lot harder to read and maintain
> without the reassuring "QSettings" type right there?
>
> Good luck,
> ry
--
[ signature omitted ]
Message 30 in thread
If you force using INIformat (so the config files may be transferable
between unix and possible windows version), wouldn't multiple
instances overwrite each others files?
As to the "destroying when closing app" - I solved it by using atexit,
see following code sample:
I created Settings class as a thin wrapper around QSettings, providing
forced ini format + few features specific to my app ....
---- settings.h: -----
class Settings : public QObject {
Q_OBJECT
public:
~Settings();
static Settings* getInstance();
...
private:
//Constructor is private, use getInstance
Settings();
...
extern Settings *globalSettings;
---- settings.cc: -----
/** One object for application, holding all global settings.
Should be thread-safe. This instance is used from other files */
Settings *globalSettings=NULL;
/**
Return Instance of Settings.
Ensures only one instance of Settings exists at any time (singleton)
If no instance exists, it is created.
@return existing Settings object
*/
Settings* Settings::getInstance() {
if (!globalSettings) globalSettings=new Settings();
return globalSettings;
}
---- main.cc -----
/** delete settings object (and save settings)
This function is called at application exit
*/
void saveSettings(void) {
delete globalSettings;//this causes settings to be saved to disk
}
int main(int argc, char *argv[]){
...
Settings::getInstance();
...
atexit(saveSettings);
...
---- end of code sample ----
Works fine, I experienced no problems like losing settings when
closing app. I also recommend flushing the settings somewhere in the
code of handling "ok" button in the preferences dialog to make the
system more sudden-app-crash-with-settings-lost resistant.
Martin Petricek
On 2/26/07, Manuela Hutter <manuela.hutter@xxxxxx> wrote:
> true, a global QSettings object doesn't make sense in that case.
> one reason could still be that you want to make sure that every QSettings object uses the same
> non-default format (ini, xml, ..)
>
> or is there a way to eg. set IniFormat as the default on all platforms?
>
> cheers,
> manu
--
[ signature omitted ]
Pages: Prev | 1 | 2 | 3 | Next
