[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:       Eva Brucherseifer <eva () kde ! org>
Date:       2002-08-11 16:23:08
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> 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 :-(
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.

>
> I think you are wrong to think that it is useful here, because:
> 1 the main part of it is its loading mechanism: it has a way to search
> a directory for files, which it presents to the program as plugin
> infos it can load.  This is imho not usable for KDEEdu since we want
> desktop files with more information than the file name of the module
> binary...  KParts::Plugin doesn't use desktop files at all..
> 2 The idea behind it is to load all the plugins at once and merge all
> their guis with the main program.  Plugins can be disabled from
> loading with some KConfig stuff, but to turn this into what we want
> would become a hack that would require more work than to write our own
> plugin handling stuff..  The merging of the guis is definitely not
> acceptable, we only want one gui merged at one moment...
> 3 if you look at the source of plugin.cpp, you'll see that almost all
> of it would have to be altered to suit our needs.  I think that like
> that it would be easier to just start over on our own...

Well, you could thing of several types of shells:
- - a shell which only loads 1 plugin at a time. (you can hardcode it to get a 
lot of little apps, or use a commandline option)
- - a shell which loads all plugins, that can fulfill given services (hardcoded)
- - or like the previous, but configurable by the user

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. 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.

> > 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).

>
> > you want to have different interfaces in the shell, depending on the
> > educational concept, so sometimes the plugin needs to transfer more
> > data
> > back, sometimes not. Maybe not in the beginning of the
> > implementation, but we
> > should keep things flexible.
>
> shells can always do whatever they want with the info they receive,
> and plugins can query the info they need...
>
> > 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. 

>
> > Also signals& slots is the common way to do communication in QT/KDE
> > (rather than callbacks...), is well-known, easy-to-use and thus a good
> > solution.
>
> All this holds even more for c++ functions.  I tend to not like how
> people always see uses for signal/slot stuff everywhere, and i think
> it's most of the time unnecessary.  In general, if you don't intend
> multiple objects to connect to a signal, you're imho wrong to want to
> use signal/slot stuff, and should be using an interface class, so that
> you get correct warnings at compile time, and not annoying debug
> output on runtime, and cause it's a cleaner approach used in all
> object-oriented programs..
>
> > 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.

> Perhaps it would be a good idea to have some signal stuff, or a way to
> allow for possible future extensions in the spirit of
> KPart::browserExtension() ?

There I have a lack of knowledge... ok, I'll also study the browserExtension 
mechanisms ;-)

>
> > 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. 

>
> > 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...

>
> > 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. 

>
> > 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 ;-)

> 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 ;-)

> 5 ... ?

>
> > 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? ;-)

>
> > 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.
- - 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? ...)
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. 

> yeah, but nothing beats a good discussion :)

Yes, esp. with a good counterpart :-))

> cheers
> domi

ciao,
eva
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9Vo9tTaAgihPikKQRAqtRAKCUE/77RWB/3k3q6g4hGssB0EB0BQCfb4nO
1HIvwUxwDKNkhG2hq3Bjlkk=
=xBic
-----END PGP SIGNATURE-----

_______________________________________________
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]