← Back to branch summary

~ubuntu-branches/ubuntu/precise/koffice/precise

« back to all changes in this revision

Viewing changes to libs/kotext/variable-registry-inline-object-registry.txt

  • Committer: Bazaar Package Importer
  • Author(s): Alessandro Ghersi
  • Date: 2010-10-27 17:52:57 UTC
  • mfrom: (0.12.1 upstream)
  • Revision ID: james.westby@ubuntu.com-20101027175257-s04zqqk5bs8ckm9o
Tags: 1:2.2.83-0ubuntu1
* Merge with Debian git remaining changes:
 - Add build-deps on librcps-dev, opengtl-dev, libqtgtl-dev, freetds-dev,
   create-resources, libspnav-dev
 - Remove needless build-dep on libwv2-dev
 - koffice-libs recommends create-resources
 - krita recommends pstoedit
 - Keep our patches
* New upstream release 2.3 beta 3
  - Remove debian/patches fixed by upstream
  - Update install files

Show diffs side-by-side

added added

removed removed

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