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

List:       kde-devel
Subject:    Re: enable/disable actions
From:       Guillaume Laurent <glaurent () telegraph-road ! org>
Date:       2005-12-07 17:08:44
Message-ID: 4397171C.2020401 () telegraph-road ! org
[Download RAW message or body]

David Faure wrote:
> On Wednesday 07 December 2005 17:28, Bram Biesbrouck wrote:
>   
>> Op woensdag 7 december 2005 15:49, schreef Guillaume Laurent:
>>     
>>> Bram Biesbrouck wrote:
>>>       
>>>> ic, thanks, but still, I'll have to connect every relevant objects's
>>>> signals to the mainWin then?
>>>>         
>>> Yes, but a signal connect() is a much looser coupling that actually
>>> carrying around a pointer to mainWin.
>>>       
>> well, because of the topLevelWidget() function, there's no need to carry 
>> around anything, it's just there, that's what made it interesting to use in 
>> the first place...
>>     
>
> Yes, but later on you decide to use a splitted view or to turn it into an 
> embeddable kparts component or to redesign the GUI in any other way, 
> and then topLevelWidget is no use anymore, another class has the actions 
> and the slots. If you use signals from the start, it's very easy to just
> connect them in the other class when making that redesign.
>   
... and state changes let you easily define in your app's ui.rc files 
which set of actions need to be enabled/disabled for each state, which 
is much more flexible than a series of calls to enable()/disable() 
within your app's code. Also, you don't have to #include a bunch of 
headers for KMainWindow & Co. everywhere.

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