New releases of KDE and Povray and a proposal

[Andreas Zehender]

On Wednesday, 04. February 2004 13:44, CARVALHO Luis Passos wrote:
> Hello!
>
> > From: Andreas Zehender [mailto:zehender at kde.org]
> >
> > PMPart should contain only the core functionality. All
> > actions will move into
> > the povray plugin.
>
> There still is the issue that the PMPArt, if I'm not mistaken, also creates
> the main widget. I presume that will not move to any plugin. If we want to
> use some part of PMPart (no pun intended) elsewhere, this creation of the
> widget must go. That is also another reason why I want to split both.

Ah, I remember.
The part creates the widget if not created by PMShell. That's used to preview 
a kpm scene embedded in konqueror. The part works correct without a view 
widget.

> > I'd like to split the sources, too. A core library and a
> > plugin directory. I
> > just want to wait for the release of KDE 3.2 to contact the
> > cvs maintainer to
> > move the files. I hope I have enough time this weekend. At the moment
> > everybody is busy to release KDE
>
> Great. Good to hear that. I'll just backup my files so I don't have a lot
> of dificulty merging afterwards.

I will send a warning before moving the files here.

> > Not sure at the moment.
> > Plugins need always a PMPart because of the KDE plugin
> > architecture. And the
> > object library will need plugins to create and handle
> > objects. The only
> > optimization that would be possible is to disable action
> > creation for plugins
> > if no gui is needed.
> >
> > Will have to think about that.
>
> The plugin "scanner" is part of the functionality provided by KParts. What
> if the PMPart is a factory for PMDocumentRules? That way, PMPart scans the
> plugins and registers them in it's own internal PMDocumentRules. Then,
> whenever we need a PMDocumentRules, we just ask the Part to clone one for
> us or give us a reference to it's own manager (depending on whether we
> implement this by inheritance or composition).

Yes, that sounds interesting.
I'm more a fan of composition.

Do you only need object serialization/deserialization and creation for the 
object library? That means the m_pPrototypeManager, m_pInsertRuleSystem and 
m_pIOManager.

One more idea: What about collecting the gui functionality of the part in a 
separate class. The part should work correctly without an instance of this 
class. Then dependent of the created components of the part, gui 
functionality is available or not. Could be extended to other functionality 
groups to make PMPart more scalable and flexible.

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