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

List:       kde-kafka
Subject:    Re: General Design Decisions
From:       Jono Bacon <f9808590 () wlv ! ac ! uk>
Date:       2000-12-06 3:44:12
[Download RAW message or body]

On Tuesday 05 December 2000 20:05, Stephan Heigl wrote:
> On Tuesday 05 December 2000 19:37, Thomas wrote:
> > > Tonight I was having a chat with Stephen Heigl and Wildfox about some
> > > design decisions regarding the next stages of implementation.
> >
> > I have not paid enough attention to kafka for some time. So I'm plesently
> > surprised to see you got this far in so little time ;)
>
> we have to learn all that things you already know, so please dont complain.

Yes Thomas...this is not the first time you have complained...please stop it. 
If you believe you can do it better please code it. If not, please be patient 
as we get to grips with the new content and topics. :-)

> > What confuses me is that I can not load/display a html file in the CVS
> > version. I am sure this has been done allready since you are thinking
> > about ways to edit it.
> >
> > Confused...
> >
> > > The main things we discussed were:
> > >
> > >  - Ways to handle controlling visual objects in WYSIWYG mode(eg -
> > > images) - Hooking the processing to GUI controls
> > >
> > > The general idea is that we should have two services within Kafka:
> >
> > This is an implementation thing. I can not comment on this without
> > knowing the code ;)
> >
> > I was personally thinking a bit more pluggable.
> > In the view you catch the mouseclick like this:
> >
> > KafkaView::contentsMousePressEvent(MousePressEvent *e ) {
> >     // We get called by QT when something is clicked.
> >
> >     // pluginType1 is a QList of plugins that want to get notified
> >     // when another node has been selected.
> >     // for instance QList<PluginBase> pluginType;
> >     for (unsigned int i=0; i < pluginType1->count(); i++) {
> >         pluginType1->at(i)->setCurrentSelectedObject(node);
> >     }
> > }
>
> agree.

This sounds good, but how do we register the plugins at runtime? I assume we 
use polymorphism and a bunch of virtuals, but using loads of virtuals (and 
hence a vtable) can give a performance hit. I have *never* looked at plugins 
before, so please forgive my ignorance. :-P

> > The objectEditor is a plugin and thus inharits from the pluginbase.
> > Therefor it must implement the setCurrentSelectedObject method. This can
> > be done as follows.
> >
> > KafkaObjectEditor::setCurrentSelectedObject(BaseDomObject *object) {
> >     case object->type(); {
> >         "P":   // set up text editing gui
> >           break;
> >         "TABLE": // set up table editing gui
> >          break;
> >     }
> > }
>
> well not using "case"s..... but something like that.
> a EditObject has a tag (e.g. TABLE) and then registers this to the
> EditObjectManager.
> When a Node is passed to the manager the tag is looked up in the registered
> ones and passed to the responsible EditObject implementation.

What is wrong with a case?

	Jono

-- 
Jono Bacon - [vmlinuz] - jono@kde.org
KDE/Qt Developer - Kafka Maintainer
_______________________________________________
Kde-kafka mailing list
Kde-kafka@master.kde.org
http://master.kde.org/mailman/listinfo/kde-kafka

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