From kde-core-devel Fri Sep 25 21:42:56 2009 From: "Thomas Friedrichsmeier" Date: Fri, 25 Sep 2009 21:42:56 +0000 To: kde-core-devel Subject: Re: Review Request: Use in-memory dom document when editing toolbars, Message-Id: <200909252343.00635.thomas.friedrichsmeier () ruhr-uni-bochum ! de> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=125391501511988 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart6468700.fdM2LKYHND" --nextPart6468700.fdM2LKYHND Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable 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(), w= hy > > 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. >=20 > 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"= =20 xmlFile has a higher version number than the localXMLFile. Somehow, while=20 writing this, I thought would happen on each reloadXML, while in reality it= 's=20 an exception. Yet, my idea was to use something similar to this "upgrade merging" all the= =20 time in reloadXML(). I.e. start from the current loaded (and possibly=20 customized) xml, then apply only the relevant portions of the localXMLFile,= as=20 if the localXMLFile had a lower version number. I believe this would work j= ust=20 fine for the ActionProperties, but in fact, as far as I can see, now, it wo= uld=20 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: >=20 > 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= ".=20 Thanks for disentangling my thoughts. > b) your case of setting the xml for a specific part from the outside (whi= ch > 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= =20 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 bot= h=20 files at once). Regards Thomas --nextPart6468700.fdM2LKYHND Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkq9OWEACgkQEKRv+5DVNhjrgACgrqrm/sNgFtgz6tkmHLm1Evm1 gZoAnAm+1JaB1YrW3/xctRVHLxXpN8LR =BJ7R -----END PGP SIGNATURE----- --nextPart6468700.fdM2LKYHND--