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

List:       kde-edu-devel
Subject:    Re: [kde-edu-devel] possible design math app
From:       Dominique Devriese <fritmebufstek () pandora ! be>
Date:       2002-08-11 18:37:29
[Download RAW message or body]

Eva Brucherseifer <eva@kde.org> writes:

> > Yes, idd, i was confused, however, i'm sorry to say that i don't think
> > the plugin stuff is usable either, here's why:
> >
> > this comes from the documentation of KParts::Plugin:
> >
> >  * A plugin is the way to add actions to an existing KParts application,
> >  * or to a @ref Part.
> 
> Well, first of all - the documentation of all this is rather bad and 
> incomplete, so better don't trust it :-(

the kde docs are indeed not as good as those of Qt, but they're not
far off, most of the time..  I almost always check the source too, and
for KPart::Plugin the docs are quite correct...

> I wrote a 4 pages article for a german unix magazine about it (iX) and 
> explored the KParts::ReadOnlyPart/ReadWritePart, XML-GUI, KTrader
> and loading KParts in detail, so I know what I talk about... I only
> didn't study the  
> Plugin part and the extensions very well so far. 
> 
> The desktop files are not used by the KParts::* but rather by the KTrader. 
> KTrader has a database (well, rather a cache actually) which you can query 
> for certain service types and mimetypes (if you want so). Once you have 
> determined the plugin lib you want load, you don't need the information 
> anymore, that is provided by the desktop files. You also never look into the 
> desktop files yourself, that is doing the program "kbuildsycoca" for you, 
> which builds the cache for KTrader.

1 what i meant was that the KPlugin loading stuff ( as you can see it
in kdelibs/kparts/plugin.h ) does not use KTrader or desktop files at
all, and it's not supposed to either...
2 There's nothing wrong with looking at the desktop files.  There is a
special class for this (KDesktopFile in
kdelibs/kdecore/kdesktopfile.h) and it is done all over KDE (
e.g. kdelibs/interfaces/kscript/scriptmanager.cpp,
kinit/autostart.cpp, kio/kio/kmimetype.cpp etc.).  For accessing data
in the desktop files specific to your application, you have to use
it... 

<snip>

> I don't know how to interprete your last mail ;-) but I am very sure
> it is the  
> right way to inherit either KPart or KPart::Plugin.

well, i would say to use KParts::Part, and not KParts::ReadOnlyPart or
ReadWritePart, and definitely not KParts::Plugin, since the first one
has only the functionality we need, and the others don't.
KParts::Plugin is especially unuseful since it is designed for
something completely different.  I personally wonder what it's doing
in kdelibs/kparts, since it has nothing to do with kparts at all,
except maybe for the xmlgui stuff...

> This weekend is over and  
> I don't have any time during the week. Next weekend I'll get a
> prototype and  
> then we maybe have a better basis for discussions.

i'm looking forward to it ;)

> 
> > > OK, I'll try to explain it more detailed:
> > > You have communication in 2 directions:
> > > 1) shell ----->  plugin
> > > 2) shell <-----  plugin
> > >
> > > The first part is easy and simply uses the methods/slots of the
> > > interfaces of
> > > the edu-plugin. But the second part is rather difficult because of these
> > > reasons:
> > > the plugin doesn't know which type of shell it was loaded by and what
> > > it's capabilites are. Well, you can transfer some information from the
> > > shell to the plugin, but I'd regard it as rather nasty.
> >
> > You can have shells be subclasses of a KEduShellProgram, which has
> > some functions.  You can pass these as arguments to the KEduPlugin's,
> > so they can use it to pass info, get info etc. in the normal, clean
> > C++ way...
> 
> but then you have a two-way dependency... that works in C++, but I wouldn't 
> call it a "clean C++ way" and definitly not a "clean design"... In Scott 
> Meyer's books or Fowler's "Refactoring" you'll find more info about that.
> 
> I actually prefer a one-way dependency and that is, the shell needs to know 
> the interface of the plugin, but not the other way around, whenever this is 
> possible (see more below).

am i missing something here ?  if you have an object use the dcop
interface of another object, then you depend on it not changing too..
which is not a compile time dependency, but it definitely falls under
what the two authors you mentionned will have meant by it.
Anyway, you could always wrap the data in a struct and give it to the
plugins' constructors...

<snip>
> > > So how do my 2 proposed concepts help?
> > > signals & slots
> > > The signals of a plugin can be used to transport data from the plugin to
> > > the shell, slots for the other direction. The important thing for signals
> > > is: They don't need to be connected, so if a shell isn't interested in
> > > the data, it doesn't setup a connection.
> >
> > a shell can provide an empty implementation for a method of the
> > KEduProgram Base class...
> 
> well, possible... that would then be some type of "NullType"
> implementation. 

sorry, don't know what you are talking about :)

> > > The difficult thing is only. Whenever you change the C++ interface of the
> > > communication, your shells/plugins are not binary compatible anymore
> > > (this also yields for plain function calls) :-(
> >
> > this is more a question of well designing your interface, imho.
> 
> That might become difficult once you expect external contributions
> which are  
> outside of our scope.

difficult, but doable ? just expose all functionality you can, right ?

<snip>
> > > DCOP
> > > With dcop you don't need to predifine the interface for the
> > > communication. (Remember: for signals & slots you need to have all
> > > signals and
> > > slots in your
> > > basic interface description of the edupart - What happens, if you want to
> > > transfer somethings special?).
> >
> > You're wrong here if you think that adding signals/slots isn't binary
> > compatible.  And exactly what do you mean by "something special" ?
> 
> something special = "some special type of information I cannot think
> about at  
> the moment and which wouldn't be in the interfaces"
> 
> You can of course make the communication generic by transfering
> strings, that  
> you parse in order to get a communication protocol, but then again,
> you don't  
> have compile-time checking. 

since this is what both signals/slots and DCOP do, they don't have
that either :)
plus dcop has the additional overhead of copying data out-of-process,
and back again...

> 
> >
> > > With dcop each member of the communication can "explore" the dcop
> > > interface of
> > > the other member.
> >
> > this also holds for signals/slots: "man qmetaobject" might help.
> > there are the functions QMetaObject::signalNames(), and
> > QMetaObject::slotNames(), which are quite similar to their DCOP
> > counterparts, only faster, cleaner and more suitable.
> 
> Mmh... didn't know about that...

we're all learning lots here :)

> > > In order to extend the communication capabilites of one
> > > member, you don't need to change the central KParts::EduPlugin, but
> > > only the
> > > dcop interface of a single shell or a signle plugin. And here comes
> > > the
> > > "compile time dependency": you don't have to recompile all shells
> > > and parts
> > > to use the new feature.
> >
> > Neither do you have to with signals/slots.  There's a good reference
> > somewhere on developer.kde.org on binary compatibility, that you might
> > read...
> 
> Yes, but it is still rather difficult and you still always need to
> change the  
> central parts, which are the edu-plugin's and the edu-shell's base
> class.  

but this is what you  were talking about, right ?

> > > Instead you have a runtime dependency with
> > > check -
> > > that means you can check if a method is available - how would
> > > you do that 
> > > in C++ without crashing the app?
> >
> > there are lots of possibilities:
> > 1 signal/slots stuff
> > 2 virtual functions that can have empty implementations
> 
> then you need to know all possible elements of your communication
> protocol
> 
> > 3 a virtual method call( QCString function, void* args )
> 
> *grml* don't like function pointers, they are C-ish and nasty ;-)

err, i meant a method
virtual void call( QCString function, void* args );
so you would have something like
object->call( "doSomething", (void*) &some-argument );

this is much like how Qt slots work

> > 4 subclasses and dynamic_cast, but due to a gcc bug with dynamic
> > loading that is not usable ATM.
> 
> and it's still nasty after all ;-)

yeah, but using DCOP to do stuff you could do much easier like that is
even nastier, imho...

> > > The third method maybe is XML-RPC, but I don't know anything about
> > >it.
> >
> > i read that it was very basic, very unextensible, and almost
> > completely obsoleted by DCOP..
> 
> that is what I expected. (Doesn't gnome use it? ;-)

i thought they used corba...

> 
> >
> > > Well, to conclude this discussion on communication:
> > > I am much in favour of first using signals&slots, because it's a concept
> > > everyone knows.
> >
> > I agree that it might be useful, but it should be secondary to a good
> > design of the interface classes..
> >
> > > If we experience problems, where it isn't enough (maybe also,
> > > because we get a
> > > lot of plugins from outside of kdeedu and we don't want to brake
> > > compatibility), we can always add DCOP.
> >
> > as said, i disagree...
> 
> Conclusion:
> After all this valuable pro's and con's, I think, we need a
> prototype and need  
> to evaluate what the "real problems" are. 
> For the plugin implementation I'll choose KPart  or KPart::Plugin as
> base 
> class and the KTrader mechanism to load the correct plugin.

please go for KParts::Part, and not KParts::Plugin, cause the latter
is totally inappropriate...

> for the communication, we maybe can have prototypes both for the shell 
> interface and the signal/slot mechanism. Maybe we can also try to get more 
> input by core people (David? Simon? ...)

/me agrees...

> As I said before: next time I can put some work into it will be next weekend 
> and then during the meeting in Hamburg plus the days after that. 

great.. looking forward to see it..
cheers
domi

-- 
 Fry: Whoah. Check out that guy. He makes Speedy Gonzales look like 
 Regular Gonzalez.
_______________________________________________
kde-edu-devel mailing list
kde-edu-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-edu-devel
[prev in list] [next in list] [prev in thread] [next in thread]