xmlgui (Re: kdelibs (partial) todo list)

[David Faure]

On Tuesday 17 January 2006 11:28, Andras Mantia wrote:
> On Tuesday 17 January 2006 00:28, Alexander Dymo wrote:
> > The question is not whether user can or can not modify the GUI.
> > The question is whether the user needs that (YAGNI approach ;)).
> Right now the only way to tweak context menus is the xml file
> And of course, distributions can tweak the applications through them as well.

I don't think they do that much, and distributions can also patch the code, but anyway :

> Sincerely, I like the idea of XML GUI.

Me too. But I think Simon's idea is to only change the way KParts merging is done
(using the concept I vaguely called "action groups"). 
The current way isn't flexible enough in many cases, for the host. You embed
a part, and it clutters your whole GUI and you can't do anything against that...

But I think we can still keep XML GUI for the application's main rc file, and 
for popup-menus indeed. For those who don't like hand-editing xml files
we can certainly cook up some GUI.

This creates some trouble when converting a class between being a mainwindow
to being a part or vice-versa [or modelling a part after a mainwindow, like in kmail]
but we have that kind of trouble already due to the different merging happening for parts.
[my initial plan for kde4 was to merge the two merging concepts :)]

Hmm. To do things mostly the same way for parts and mainwindows, maybe we 
could keep xmlgui for parts but add the action-group concept on top of it, i.e.
the host could say "only merge the actions belonging to the groups
'viewing', 'editing' and 'printing, but not 'settings' and 'navigation'".

Difficult choices. On one hand being close to Qt, on the other hand keeping the
best ideas from kde3, and on the third hand (yes :)) making things consistent
between parts and mainwindows...

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).