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

List:       kde-core-devel
Subject:    Re: GUI framework in kde4
From:       Hamish Rodda <rodda () kde ! org>
Date:       2006-07-06 15:54:00
Message-ID: 200607061754.04511.rodda () kde ! org
[Download RAW message or body]


On Monday 03 July 2006 08:37, Thomas Zander wrote:
> 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.

action->setParent() or actionCollection->insertAction() / 
actionCollection()->removeAction()

> 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?

You don't, the point was that if you prefer to use designer, the actions will 
be created for you (actually, the ui class will ask kde to create them for 
it).  There is no dependency on KMainWindow, that was an example.

We have a separate api for non-designer use too.  It's taking shape in 
svn.kde.org/home/kde/branches/work/kdelibs-liveui/kdeui/liveui

> > > 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.

Worked for me :)

> > > 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.

This is possible, in fact we're thinking about an auto-connect action signals 
to implementation slots, based on action + slot names, similar to qt's 
connect signals to slots functionality.  So, you might have slot: void 
on_file_open_triggered(); which would get auto-connected if you enabled this 
mode.

We could also detect which actions are unconnected and hide them... but isn't 
this more of an application bug?  To me it doesn't really make too much 
sense.

Cheers,
Hamish.

[Attachment #3 (application/pgp-signature)]

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