GUI framework in kde4

[Thomas Zander]

On Monday 3 July 2006 01:35, Hamish Rodda wrote:
> On Sunday 02 July 2006 22:46, Thomas Zander wrote:
> > On Sunday 2 July 2006 21:08, Hamish Rodda wrote:

> > Hmm reading further some points don't make sense to me, how can you
> > assign kactions to actioncollections.
>
> Every kaction has as its parent a kactioncollection.

Heh. I didn't finish my question, it seems :)

Enabling + disabling of actions is IMO best done via the actionFactory. 
Simply get the action by name and call setEnabled().
The question was suppost to be; how can I set a new KAction to a specific, 
possibly non-mainwindow actionCollection.

If I have 2 views of my data I want two sets of actions instantiated since 
that toggleAction will be able to have different values per view.
So, what I really am asking. Why do you need a KMainWindow to _create_ 
actions?

> > The connection between an action and the
> > resulting code to be called can not be done in a GUI tool, right?
>
> Simon Hausmann told me that you can actually connect actions' signals
> to slots of widgets in designer. 

Hehe, lets check if 4.2 can actually connect to QWidget actions now :) 
Like connecting a QCheckBox to a setEnabled of another widget.

> > A general data-flow, or workflow would be appreciated.
>
> 1. developer creates KMainWindow subclass in designer
> 2. developer adds actions (stdactions, custom actions, and merge
> points) to toolbars, menus etc. with designer

Ok, so a (graphics) designer will create (all) the menus and actions which 
will be useless until the programmer actually does something.

In that case I'd like to suggest some way to 'make active' an action.

With current XMLGui we have a really cool feature that if a action is not 
added or written its item in the Menus will not show up. So a designer 
can provide an xmlgui .rc file which will result in more actions actually 
showing in the menu when they become implemented.
I would really suggest we keep that way of working, so we don't end up 
with whole menus, or inidividual menu items that don't have any effect 
because the program does not know about them.

So; what about only showing an action in the menu when there is someone 
connected to its signal ?

On that level; I'd love the framework to _not_ show a whole (sub)menu, 
including its top-level item, if there are no active actions in there.
-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060703/a7bea831/attachment.sig>