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

[Thomas Friedrichsmeier]

On Friday 25 September 2009, David Faure wrote:
> On Friday 25 September 2009, Thomas Friedrichsmeier wrote:
> > 2) Merging only the changes (configured shortcuts / toolbars), without
> >  throwing away customizations. I admit, I'm not quite sure the solution
> > is this simple, but my idea was roughly: "Well, so instead of reloading
> > the original xmlFile() *and* then merging it with the localXMLFile(), why
> > don't we just skip the first step and only merge the new version of the
> > localXMLFile()". So basically in most places where reloadXML() is called
> > right now, reloadLocalXML() or something like that would be called.
> 
> One of us is very confused about this.

I admit, that would be me.

> AFAIK reloadXML only reloads the local XML file.
> There is no merging between xmlFile and localXmlFile.

What I had in mind was the "upgrade merging" that happens when the "global" 
xmlFile has a higher version number than the localXMLFile. Somehow, while 
writing this, I thought would happen on each reloadXML, while in reality it's 
an exception.

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.

> 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". 
Thanks for disentangling my thoughts.

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

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090925/365fd948/attachment.sig>