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

List:       kde-devel
Subject:    Re: KDialogBase problem with KGuiItem
From:       Martijn Klingens <mklingens () yahoo ! com>
Date:       2001-11-29 18:43:40
[Download RAW message or body]

On Thursday 29 November 2001 18:09, David Faure wrote:
> You can't do that, QObjects can't be copied.

:(

> I think QObject is a bit too heavyweight for KGuiItem. We already have
> KAction for the "object that can be activated" concept. KGuiItem was
> supposed to be only a repository of some settings, nothing more.

Hmm... the original idea that I proposed to Simon was more like making 
KGuiItem a base class for KAction. But now that I think of it, the reasons 
why I wanted that (amongst other reasons I wanted the signals if the data 
changed) don't make it a necessity to have KGuiItem as KAction base class.

For the design and clarity of the code it might still make sense, but indeed 
a QObject is quite expensive, so I might better drop that idea.

> I think the first step is to re-evaluate the idea of emitting signals from
> KGuiItem. Then, if you really want to do that, you can use &arg to get the
> address of the argument, with no need for copying it.

I think I'll try it again a bit differently and add the signals to KAction 
instead.

What I still want BTW is to (try to) ditch KStdAction in favour of 
KStdGuiItem. Should be a matter of creating a KAction ctor that takes a 
KGuiItem as parameter. (And KStdAction in itself would become a deprecated 
stub for compatibility reasons - ditching it altogether is not an option yet.)

Martijn
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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