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

List:       kde-devel
Subject:    Re: some beginners questions
From:       David Faure <faure () kde ! org>
Date:       2005-02-25 20:46:09
Message-ID: 200502252146.09377.faure () kde ! org
[Download RAW message or body]

On Friday 25 February 2005 20:34, Andreas Pakulat wrote:
> On 23.Feb 2005 - 23:48:42, Andreas Pakulat wrote:
> > Hi,
> > 
> > I already started my app and today I wanted to dynamically
> > enable/disable KActions depending on wether the Document actually
> > contains data or not. Now looking at one or 2 kde apps there came
> > several things to my mind:
> > 
> > - when using document/view architecture is it better to have the
> > mainwindow create a view (which in turn creates the document) or the
> > other way around - i.e. the mainwindow creates a new document and this
> > creates the view. Including the question if both document and view
> > each get a pointer to the other?

For the KOffice case it's all documented in koffice/lib/kofficecore/DESIGN.

The doc shouldn't have a pointer to the view - there could be more than
one view. At most it can have a list of views, but better use signals to
communicate to the views.

> > - in conjunction with the above should the mainwindow hold a pointer
> > to the view or to the document? 

The mainwindow should rather have a list of views/documents, so that you
can split the window, or have tabs, etc.
 
> > - Last question is how do "correctly" handle KActions that have a
> > meaning only with a document? Currently I have these in the mainwindow
> > class with slots in that class, but I think I should move them into
> > the view-class. 
Yes, most actions make sense in the view class, to act on a document
(but pop up a dialog with the right view as parent, use the view's cursor, etc.)

The mainwindow has very few actions (Quit, Open, Save, etc.)

> > Also I tried to find out how kopete for example does 
> > the enabling/disabling but I didn't came very far. So how does the
> > "normal" kde app enable a KAction (I don't mean call
> > KAction->setEnabled() but how do the apps trigger this, i.e. what
> > signal in what type of class is emmitted and which slot catches it,
> > which class connects these 2)

That all depends on your app's logic - if some actions depend on an object
being selected you can have a objectSelectionChanged() slot etc.

> > I tried to look at kate, but thats a bit too complicated to initially
> > learn from it..

koffice/kword/kwview.cc has KWView::slotFrameSetEditChanged as an example
of a slot like above.

Another solution is defining the various possible states of the application
in XML. Not sure where there are examples of that. See kxmlguiclient's documentation.

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]