Commit 08ebc63b authored by Boudewijn Rempt's avatar Boudewijn Rempt

preserve this discussion for posterity. If anyone has time to make it a proper...

preserve this discussion for posterity. If anyone has time to make it a proper text for the wiki, go ahead.

svn path=/trunk/koffice/; revision=940841
parent 365a0fee
11:58:31 < TZander> the KoVariableRegistry and this one are mutually exclusive (since the variable is also an inline object)
12:08:36 < boud> the svn history of those classes is certainly confusing
12:13:37 * TZander remembers a little bit what happenend. Basically there were only KoVariable based plugins and thus the
usage of a registry for InlineObjects was confusing and subsequently removed.
12:13:49 < TZander> I only noted this quite some time later and an easy revert was impossible at that time.
12:14:40 < TZander> but thats not really important.
12:14:45 < TZander> (the history, I mean)
12:15:12 < TZander> I talked about this on the mailinglist back then and we all agreed it could be put back without much of
a problem
12:15:15 < boud> well, given the relative lack of documentation I was trying to use the history to get a bit informed
12:16:20 < boud> I tried the mailing list to find stuff, but my query must have been rotten, since I could find only one
mail that discussed it
12:19:06 < TZander> the basic situation is a little bit like this; we have a KoVariableRegistry now and the KoVariable
class inherits from KoInlineObject. So its similar to having a KoPathShapeRegistry instead of a
KoShapeRegistry. It disables the creation of plugins that inherit from KoShape directly instead of
from KoPathShape
12:19:48 < boud> ah -- and I guess that that was done because of the code to load variables from odf?
12:19:55 < TZander> so removing the KoVariableRegistry and re-instating the KoInlineObjectRegistry will allow just a more
wide range of plugins.
12:20:36 < TZander> that could be, yes. The bookmark and notes inlineObjects have been moved into KoText.
12:20:46 < TZander> Not entirely sure why they should not keep being plugins.
12:21:31 < boud> would be interesting to find out -- there must have been a reason
12:34:39 < TZander> doing a git log on them I see that they were never plugins but always lived in the kotext package.
12:35:07 < boud> Ah. It seems that the big difference is that KoInlineObject doesn't have a loadOdf method
12:36:14 < TZander> curiously; the KoBookmark class has a saveOdf but not a loadOdf
12:36:24 * TZander has no clue if bookmarks actually work, though
12:36:59 < TZander> why would you not have a loadOdf method on KoInlineObject ?
12:37:08 < boud> that's probably because KoInlineObject doesn't have a loadOdf -- it's an interface KoVariableThingy adds
12:37:32 * TZander shakes head. Not important for 2.0 anyway
12:38:17 < boud> nah, but perhaps we should add this little chat as a memo for when we return to it after 2.0 and have
forgotten all about this :-)
12:38:17 * TZander would really like to move more code into plugins so we can at least be clear about something being
finished and functional.
12:38:24 < boud> yes
12:38:30 < boud> I'm all for plugins, as you know :-)
12:38:46 < boud> I think I actually remember the origin of this...
12:38:46 < CyrilleB> and it makes the library more maintainable ;)
12:39:15 < boud> wasn't it because KoInlineObjects were supposed to be constructed from KoProperties not chunks of odf?
12:39:34 < TZander> hmm, no. KoInlineObject has nothing to do with KoProperties.
12:39:42 < boud> but KoInlineObjectFactory has
12:39:55 < boud> virtual KoInlineObject *createInlineObject(const KoProperties *properties) const = 0;
12:40:18 * TZander reads
12:41:09 < TZander> ah, I see your point.
12:41:25 < TZander> The idea for that was for defaults only;
12:41:40 < TZander> so you can have a set of plugins that show inline objects in your shapeSelector
12:42:04 < boud> so, basically, moving loadOdf to KoInlineObject would be fine
12:42:14 < boud> need to go and get some bread now
12:43:38 < TZander> yes, as the factory method would only get called with a KoProperties if the user chooses a template
that was added earlier.
12:43:51 < TZander> Very much similar to the way we have flake-shape templates.
12:44:07 < TZander> KoShapeTemplate
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment