[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Change tracker and commit problem
From:       Pierre Stirnweiss <pierre.stirnweiss () t-online ! de>
Date:       2008-11-25 20:18:50
Message-ID: 200811252118.50729.pierre.stirnweiss () t-online ! de
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]