Kexi Core Design:

Random Information on Handling Dialogs/Views by Kexi Core

 jstaniek, mar 2005

Table of Contents      Q: I'm currently trying to figure out how to handle KActions for Actions      Q: I can't find the point where the action activation takes place

Q: I'm currently trying to figure out how to handle KActions for Actions

 ...specific to the document or view in an KMdi App.
  Currently I disconnect the Actions from one view (or its document)
  and then reconnect them to the slots of the new "current" window
  (or its document) when the current view is changed.
  But I don't think that this is the proper way, there must be a way for
  a view to check wether it's active or not, but I could not find a proper
  function for this. (from Andreas Pakulat < apaku @ gmx . de >)

A: You can notice that portions of the problem were sometimes already implemented many times for different (or similar) needs in KDE. You may also want to look at Kexi way of switching things: -different views of single child window -different windows and then at KexiCORE API where all that is implemented and abstracted.

In short: toolbar items are switched when needed by switching (detaching and attaching) XML GUIClient in KexiMainWindowImpl. You're declaring which "global" action you want reuse and plug into it within your dialog (what means child window here) or even a single view (or QWidget) within a dialog, connect it to your slot.

You are using action proxies, you don't get action unless your receiver is active (focused). One more thing: you can declare supported global actions within plugins (KexiPart: KParts alternative for non-embeddable multi-views interface), so after a plugin is loaded and a child window is opened using it, these actions appear automatically.

Classes:

• KexiActionProxy
• KexiSharedActionClient
• KexiSharedActionHost
• KexiDialogBase
• KexiViewBase

Q: I can't find the point where the action activation takes place

 ..or how you "disable" the inactive slots but activate the slots
 of the focused widget... (from Andreas Pakulat < apaku @ gmx . de >)

A: We're not disabling inactive slots, we're just calling only the one which points to "active" widget/view.

Look at KexiActionProxy code, especially plugSharedAction(): internal QSignal object is allocated there, one per connection, and all "shared" connections are made against it. Then, if you're, say, executing shared action from menu, KexiActionProxy::activateSharedAction() is called (KexiSharedActionHost does that as a top level manager over KMainWindow).

In KexiActionProxy::activateSharedAction(), a QSignal object previously created for currently active view is found, by action name. Then QSignal::activate() is called. The advantage is also that if such a signal is not found, we're looking for parent views' actions, if you want.

There are more subtle features within the framework, like volatile actions (these actions can just disappear when are disabled), and so on. The api is quite Kexi independent, it's in KexiCORE lib, but was not reused outside the app. KexiDialogBase and KexiViewBase currently depend on KMDI views.