From koffice-devel Tue Nov 25 20:18:50 2008 From: Pierre Stirnweiss Date: Tue, 25 Nov 2008 20:18:50 +0000 To: koffice-devel Subject: Re: Change tracker and commit problem Message-Id: <200811252118.50729.pierre.stirnweiss () t-online ! de> X-MARC-Message: https://marc.info/?l=koffice-devel&m=122764429332351 On Tuesday 25 November 2008 05:04:29 Thorsten Zachmann wrote: > > would it not be possible to use KoShapeSavingContext::addSharedData and > KoShapeSavingContext::sharedData to pass the data around. Yes that would indeed be a much cleaner solution. I was sort of carried away copying the style saving mechanism that I didn't study the KoShapeSavingContext interface properly. It should allow to completely isolate the chagetracker in the kotest and textshape realm. > Or do the > KoGenChanges contain any kotext specific code? Actually, the KoGenChanges and KoGenChange are exactly the same as the KoGenStyles and KoGenStyle (minus some methods that I didn't need), I even think I could have used a KoGenStyle but it would have been confusing. The change tracker stores the changes properties (so far OASIS provides dc-creator and dc-date tags, plus optional comment) into a KoGenChange the same way the KoCharacterStyle stores the style properties in a KoGenStyle. There is no Kotext specific code. > If not maybe they could be > added to the KoShapeSavingContext. Yes, if eventually a changetracker can be implemented for other part of Koffice, it would make sense to bring this up in the hierarchy. However, so far it seems OASIS is foreseeing change tracking only for text documents. As long as the changetracker is text only I think encapsulation is better. this is mainly for the sake of clarity and conciseness of the interfaces. > In all I think we should avoid to > subclass KoShapeSavingContext in this way. I will try to use the addSharedData capability, subclassing a KoSharedSavingData to contain the KoGenChanges. On Tuesday 25 November 2008 00:13:57 Thomas Zander wrote: > > Yes, I'm afraid that with the 2.0 release coming up changes this big, even > if commented out, should go to a branch until trunk is open for commits > again. Yes, the initial plan was to commit in a branch for people to have a look and to merge after 2.0 is released. Like most plan, it didn't survive the contact with real life. Actually, I didn't spot the "svn switch" didn't work. > > I suggest using git-svn and use a git branch then while merging the changes > from trunk ever week or so. > This makes it a lot easier to keep the feature up-to-date. > > Naturally its still not free; bugfixes in the code you also changed will > have to manually be merged. There is no way around that, though. Yes, that was the pain I was mainly referring to. Last time I tried to do this, I ended up spending all my time trying to merge the changes back and had little time left to actually code. That became really frustrating. > > I have not read the patch; I do think its *very* interresting for KOffice > and I would love to have this feature in 2.1. I will have little time to > work on reviewing / cooperation before 2.0 is out, though. Getting a > stable 2.0 is very high on my already waaay to long TODO list. > Maybe you can help a little on that part? Getting 2.0 stable since you seem > to already be confident with the code :) Yes I will look into this for the time being then. The sooner the release, the sooner the fun on changetracker really start :) As a side note for the admin. I am using an alias email address that redirect the incoming mail to my real email. The problem comes then when I send a mail to the mailing list as I guess the email I use for sending is not the one I have provided to subscribe to the mailing list. Is there a way around this? Thanks Pierre _______________________________________________ koffice-devel mailing list koffice-devel@kde.org https://mail.kde.org/mailman/listinfo/koffice-devel