Reference to the part in PMObject

[Andreas Zehender]

Hi!

On Thursday, 08. May 2003 02:13, Luis Carvalho wrote:
> Andreas, as you may recall, I'm changing the library so that we can edit a
> library object through drag'n'drop.

Yes, I remember!

> Currently the library browser has no reference to any part. It doesn't make
> any sense to associate the library browser to any specific part. However,
> in order to provide drag'n'drop for the library, I need to load the objects
> contained in the library object. Since the constructor of PMObject and
> descendants requires a reference to a PMPart I'm a bit stuck, as the
> objects will be created by the Library Browser who doesn't know any part.
>
> Is there a change to have PMObject fallback to a default PMPrototypeManager
> and PMInsertRuleSystem if no part is given? Or, since PMObject only uses
> the part to get the prototype manager and the insert rule system, we could
> change the constructor to receive a pointer to the two managers eliminating
> the reference to PMPart. That way, I can create copies of the managers
> owned by the library browser that will be passed when I load the file.

Hmmm, that's a tricky problem. Almost everything needs an instance of the 
part. You will not be able to parse any object from the xml code without a 
part, as the xml parser needs the symbol table, the prototype manager and the 
insert rule system of the part. Any plugin will be loaded for one part and 
will need a part instance, even the KParts plugins (which will be the base 
class for plugins) are bound to a part or a shell IIRC.

Although it seems to be quite an overhead, I think you should create a PMPart 
instance for the object library. I see no way to remove this dependency. Of 
course we should add a new PMPart constructor that initializes as few members 
as possible, the complete gui stuff can be removed for example.

> Another thing I need to handle is objects created by plugins. I'll add a
> "requires" field to the library object to identify wich plugins have to be
> available to handle the library object. If a library object requires a
> certain plugin that is unavailable, I'll refuse to open the file.

The other way round!

A plugin should define which objects it supports. Each plugin has a xml file 
that describes the supported services, object types, view types, input/output 
formats etc. The plugin manager reads all those xml files at startup, so it 
knows of any supported objects. The object library (and the xml parser) can 
then query the plugin manager: "Is there a plugin that can create an object 
of type Cube?". If we ever change our plugins, move one object to another 
plugin, split one plugin up etc, we will still be able to load scenes and 
objects from the object library.

Greetings, Andreas
-- 
--------------------------------------------------
 Andreas Zehender
 Master of Computer Science, Dipl. Ing. (BA)
 http://www.azweb.de
 az at azweb.de | zehender at kde.org      
--------------------------------------------------