[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: kmainwindow / Qt::WA_DeleteOnClose
From:       Christoph Pfister <christophpfister () gmail ! com>
Date:       2007-01-16 16:37:42
Message-ID: 200701161737.42879.christophpfister () gmail ! com
[Download RAW message or body]

Hi,

Am Montag, 15. Januar 2007 16:17 schrieb David Faure:
> On Thursday 04 January 2007 11:07, Christoph Pfister wrote:
> > Hi,
> >
> > DeleteOnClose is always set during construction of kmainwindow in the
> > current implementation [1]. On the one hand this contradicts to the
> > documentation where it's said that you can disable this by passing 0
> > for the window flags, on the other hand i would like to have a
> > kmainwindow without that flag.
> > (Of course i could clear it but ... :)
>
> Good catch, but I'm not sure what we should do. I still think it makes
> sense to set it by default since people just forget to delete them
> otherwise; and passing parameters to the constructor is not the qt4 way, so
> how about I simply adjust the documentation to say that if you don't want
> deleteonclose you need to clear it in your ctor?

Thanks for your reply ...

About the sense of setting it by default: I think it wouldn't hurt much if it 
isn't deleted due to forgetful people (in _normal_ cases you also exit from 
the application after closing (= here destructing) the mainwindow). Of course 
this should be only the exception (i dunno how many people forget to do 
it ... but normally _you_ should care about lifetime of objects). You could 
also create it on the stack to have automated deletion. Behaviour from qt4 
mainwindow would remain. On the other hand it makes sense to have that flag 
set by default of course so i dunno really ...

About the other proposals: Having such stuff in the flags is kinda evil, 
agreed (it's also difficult to see behaviour changes if they're hidden in 
flags; this way you would override changes to the default flags too). So the 
other solution would indeed consist of adding appropriate documentation about 
it.

Christoph
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]