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

List:       kde-devel
Subject:    Re: enable/disable actions
From:       Bram Biesbrouck <b () beligum ! org>
Date:       2005-12-08 5:02:27
Message-ID: 200512080602.27493.b () beligum ! org
[Download RAW message or body]

Op woensdag 7 december 2005 18:08, schreef Guillaume Laurent:
> 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.
>

you're right guys, thanks for the info
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]