Review Request: Use in-memory dom document when editing toolbars, to allow for dynamic changes

[David Faure]

On Friday 25 September 2009, Thomas Friedrichsmeier wrote:
> Yet, my idea was to use something similar to this "upgrade merging" all the
> time in reloadXML(). I.e. start from the current loaded (and possibly
> customized) xml, then apply only the relevant portions of the localXMLFile,
>  as if the localXMLFile had a lower version number. I believe this would
>  work just fine for the ActionProperties, but in fact, as far as I can see,
>  now, it would not work for the toolbar settings. So I guess this is a dead
>  end.

Yes. "toolbar settings" are in fact "a whole different XML for toolbars".
The only thing we preserve from the old xml file during "upgrade merging"
is the shortcuts. Hence my confusion: I don't call that merging (enough 
merging already in xmlgui), but "copying over" :-)

> > However I do see what you mean by "losing application customizations",
> > which are those changes hardcoded in the app, those which are triggering
> > this whole discussion. But now I think the best way to handle those would
> >  be to simply have code like this:
> >
> > given a part with the xml file "part/part.rc", and we want to customize
> > it inside the app "kfoo", kfoo would copy part.rc to
> > kdehome/share/apps/kfoo/kfoo-part.rc (any time these two differ)
> > and do the customizations, then call
> >   replaceXmlFile("kdehome/share/apps/kfoo/kfoo-part.rc",
> > "kdehome/share/apps/part/local-kfoo-part.rc");
> > (the local- isn't necessary but will make reading this mail easier)
> 
> Yes, that's just what I had in mind with "writing out the modified xml
>  file".

Yes, I know. Sorry, didn't mean to sound like the idea was mine; I was just 
deploying the full train of thoughts that led me to agreeing that yes, writing 
the modified XML to disk is the only good solution.

I now implemented it in kontact, and it's working quite nicely.

I now added a note to setDOMDocument, to say that it's generally a bad idea to 
use it, and to describe our solution instead.

> > b) your case of setting the xml for a specific part from the outside
> > (which is the same except that it doesn't have the problem of not
> > affecting the other users of the part)
> 
> Well, that should be safe as well, as long as I make sure not to write over
> the part's vanilla localXMLFile, but to a separate local file (i.e. local-
> kfoo.part.rc. And that's the reason why I made replaceXMLFile() ask for
>  both files at once).

Yep, good move :)

Thanks for the help with the difficult thinking about this issue ;)

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