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

List:       koffice-devel
Subject:    Re: ODF text (was Release schedule after the alpha's)
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2007-12-31 12:42:04
Message-ID: 200712311342.04578.mail () dipe ! org
[Download RAW message or body]

Thorsten Zachmann wrote:
> I have put answers of different mails in this one so that all is in one
> place.

great, that makes it much easier to follow the discussion :)
 
> How about extending the KoShapeLoadingContext to have a QMap<QString,
> QVariant> to store data that should be passed between the different shapes
> on loading. This way kotext could use the KoShapeLoadingContext and would
> not need to have a own context. When a text shape is loaded it checks if
> it's cache is available and if not it initializes it once. When the next
> text shape is loaded it sees that the cache is there and uses it.

yeah, that sounds like a good (aka working) solution too.

[snip] 
 
>> Right, same problem like before; KoStyleManager need to be passed around
>> somehow and if we like to have loading across different text-shapes
>> working as well, then we also need to pass the textloader around.
> 
> That is why I wrote the mail on how to initializing values in shapes. With
> that we can make sure applications have a the style manager set on text
> shapes if they want to use it. In the other thread we agreed that only
> applications wanting to have a KoStyleManager should provide one. The
> loading should work also when there is no KoStyleManager used for
> applications that prefer to don't have one.

With "passing around" I was mainly refering to "pass internal somehow around 
e.g. to the textloader". For sure I understand and still agree there re that 
not each app should be forced to handle all this if not needed.
 
>> > 2) sounds fine as in the most logical way to go imho, but if you remove
>> > the KoTextLoadingContext class, please check that files still load
>> > since I doubt that 2) makes KoTextLoadingContext unnecessary (and it
>> > would be so horrible demotivating to see it such deep broken at this
>> > state). Anyway, any idea/hint/code how to remove it while preserving
>> > the functionality would be very welcome :)
>> > Also if there are any questions please just ask since I know that the
>> > code is rather confusing (but unfortunately I've the feeling it's not
>> > easy to change that - p.s. the flake-code is imho even more confusing
>> > to me :-)
> 
> I sure don't want to break anything on the change I propose. I hope to fix
> some things that don't work at the moment by the change. We sure need to
> keep the functionality of the KoTextLoadingContext.

great. That was my biggest/only fear on the whole discussion I somehow had 
after reading again and again the "remove the textloadercontext" proposal 
rather then a "replace the context with..."
 
>> a small extension;
>> and we would still have the alternate to let KoOasisLoadingContext
>> inherit QObject and allow that way to attach own stuff... or at least
>> properties...
> 
> If is the KoShapeLoadingContext that has to be extended and not the
> KoOasisLoadingContext. Do you think the solution I described above with
> the map of variants would work. It looks the same QObject properties is
> the same stuff.
> 
> So what do you think?

Sounds like a good solution that will be even be more flexible then what we 
have right now.

So, till next year :)
_______________________________________________
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]