GUI framework in kde4

[Hamish Rodda]

On Sunday 02 July 2006 22:46, Thomas Zander wrote:
> On Sunday 2 July 2006 21:08, Hamish Rodda wrote:
> > Hi,
> >
> > Please see the following document created at Trysil about improving
> > XMLGUI (actually, mostly replacing it, but preserving + improving
> > features):
> >
> > http://wiki.kde.org/tiki-index.php?page=KDE+4+GUI+framework
> >
> > Feedback encouraged :)
>
> I find the overview a bit vague; can you give me a workflow for, for
> example, kword?
> I write code in various classes (and thus various KActionCollections) to
> instantiate KAction classes currently, and load an rc file from the
> KWView widget.
> * How will I create KAction instances in kword from now on?

They should be created in designer, and the code for them autogenerated into 
eg. KWordMainWindow.  This of course is only required if you want to use the 
actions with the gui builder, and possibly if they are not in the .ui file, 
they could be searched for at runtime by name.

> * Will using designer mean the actions are datamined from the running app?
> If so, how will that work with kword registering a different set of
> KActions if its in read-only or in read-write mode?

For porting, that is one possibility.  There's no way to port 100% 
automatically, so it will be up to the developer to check that everything is 
ported.

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

> 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.  However for any non-superficial logic that's 
correct.

> 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
3. developer saves as a .ui file and informs build system
3a. developer does same process as 2 + 3 for each kpart, except the actions 
get added at merge points.
4. uic compiles .ui file into a class, which has the actions as class members
5. developer writes rest of the app and connects signals from actions to slots 
by hand (or maybe we can even do an autoconnect thing)
6. developer compiles + runs app
7. app has all information it needs compiled in, doesn't need the .ui file to 
run
7a. app merges kparts, which also have the information compiled in
8. app loads user config to change anything about the layout that the user 
wants


> Requirements that I find important (and are not in kde3):
> - store the (relative) position of a floating toolbar so a restart does
> not open it at the top of my screen, but always directly right of my app
> if I left it there.

Sorry to disappoint but with qt4, QToolBars cannot float, only dock widgets 
can float.  However, I intend to make a KToolPalette class which is like a 
floating toolbar (+ perhaps allow it to dock too), and this would take that 
into account.

> - in the shortcuts dialog (I'm looking at kwords now) there is a distinct
> lack of context for each action.
> I'm thinking we want to have multiple KActionCollections, each with a user
> viewable name for contect, and more than one per widget (since we tend to
> create almost all actions in the View widget).

Sure, and this should be doable from designer too.

> - User should be able to make extra toolbars. KMail only provides one, and
> I'd love to split that into two. (well, I did in my own rc file; but I'm
> talking about the GUI config tools here ;)

Yep.

Cheers,
Hamish.
-------------- 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/0646d41e/attachment.sig>