KAction and doc/view
David Faure
david at mandrakesoft.com
Tue Apr 23 20:43:27 BST 2002
On Tuesday 23 April 2002 21:28, Ellis Whitehead wrote:
> Here're some thoughts on what should be done with actions.
>
> Non-XML-based actions are attached directly to the widget that creates them.
>
> XML-based actions don't get connected until KXMLGUIFactory::addClient() is
> called. There are three types:
> actions which the main window creates
> actions which a document object creates
> actions which a view widget creates
Correct - maps exactly the KOffice case at least.
I guess that actions created by plugins are part of the view-widget actions.
> Document actions can only be connected via a view widget. A single document
> action may be connected to multiple view widgets.
>
> There are two scopes:
> program scope -- accessible regardless of focus
> widget scope -- only accessible when the given widget has the focus
Indeed.
Although if all actions are treated as widget scope it would work for the
koffice case. E.g. the document's Undo action doesn't depend on which
view is active, but since it's plugged into both views, if it's treated as
widget scope, it'll work just fine.
Is there really a need for program-scope actions?
> If an action with widget scope is listed in the program menus or toolbar, it
> should only be enabled when its widget has focus.
Hmmm..... I would assume that the enabling/disabling of actions is done
by the app. I'm afraid that this simple rule would create problems when
mixed with the app's more complex enabling/disabling rules. Did you
really intend to automatically enable or disable actions? Sounds like quite
a big behaviour change to me.
> Each widget that has widget-scope actions with shortcuts will require its own
> KAccel object. All other shortcuts go into the appropriate mainwindow's
> KAccel. There may be multiple main windows, and they may share a single
> document.
Indeed.
> -------------
> I have a lot of this done locally already, I think, but I want to make sure
> that I'm not missing some blatant in the concept before I start committing.
We're trying to get KOffice to compile and work with kdelibs-3.0 - until a new
KDE is released. Do you think the above can be done with changes in kdelibs
only, i..e. leaving the koffice code untouched? Otherwise, hmm, some #ifdef KDE_VERSIONs
will be necessary.
--
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KDE, Making The Future of Computing Available Today
More information about the kde-core-devel
mailing list