[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 13:09:44
[Download RAW message or body]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Eva Brucherseifer <eva@kde.org> writes:
> > Hi,
> >
> > your discussion about a common math app was quite interesting and I
> > would like
> > to come up with a design proposal. I have some holiday soon and I'd
> > also like
> > to put some coding work into it.
>
> Hi, i'm currently working hard on kig, i have a borying summer job,
> and have other stuff to do too, so i prolly won't be able to help
> coding, but i do have some remarks about your design..
Very welcome :-)
> The general idea behind it seems to be very good, but
> implementation-wise, i would do some things differently...
>
> > First of all: I am not for one large math app in one piece, but I am also
> > against masses of small apps. What I favour is a plugin design, where you
> > have shells which embed edu plugins. These plugins would have a common
> > interface and they should be easily reproducable so that a lot of
> > excercises can be implemented (I got my old algebra school book from my
> > parents yesterday, and there are a lot of exercises to implement ;-)
> >
> > So how does my design look like? It is very much inspired by the 'KDE way
> > to do things' which are kparts-plugins (if you are not familiar with
> > kparts, you should definitly have a look at the very good tutorials at
> > developer.kde.org. if you are german, I can also send you a german
> > article from iX magazine).
>
> This is my major problem with your design. KParts are not meant for
> this kind of thing. They are idd a plugin architecture, but for _one_
> specific sort of plugins: kparts are for viewing and editing
> documents. Their design and implementation reflect this goal. Many
> people seem to have misunderstood this, as we also have KonsolePart,
> which is being used in ways that KParts were not designed for. It
> causes many problems, and weird workarounds for problems like what to
> do with KPart methods like openURL etc.
That is not completly true. libkparts contains several classes, where there
are at the moment 3 classes ready for immidiate use:
KParts::ReadOnlyPart, KParts::ReadWritePart, KParts::Plugin.
You are completly right about the first two ones and actually that is what I
tried to say in my email, that they are not appropriate.
But Plugin might be the correct one, and if it is not sufficient (which I am
very sure about), then we need to implement our own KParts::EduPlugin.
Maybe I used sometimes kparts as a general term for the kparts lib, which also
includes the plugin - maybe that caused the confusion....
>
> What we need here aren't KParts, but normal plugins. I would propose
> you look at some stuff in kdelibs/interfaces/kregexpeditor together
> with kdeutils/kregexpeditor. I'll try to explain briefly how it
> works:
> 1 you define an abstract class containing the interface you want all
> plugins to have. This most of the time is rather easy, here's what i
> think it should look like:
>
> class KEduPlugin
> {
> QWidget* widget();
> KActionCollection& actionCollection();
> const QString uiRcFile();
> };
>
> All plugins export ( using KGenericFactory and friends ) their own
> subclass of this class, and install a Desktop file at an appropriate
> place. The shell finds plugins using KTrader, casts it to
> KEduPlugin* and then uses it in some way..
>
> That's about it. If you want to see a real-life implementation of
> this, look at the kregexpeditor sources in
> kdelibs/interfaces/kregexpeditor
I am glad about every example, so I'll have a look at it. But I think,
basically we are trying to say the same ;-)
>
> > Here is the design:
> >
> > You have a shell, which implements educational concepts.
> > This can be:
> > learning something, with imidiate feedback if an answer is correct or
> > not. training: do the excercises as fast as possible
> > feedback at the end of a set of excercises
> > some flashcard approach, where excercises with incorrect answers come up
> > again
> > exercises embedded in games
> > statistics
> > .... (whatever teachers come up with)
>
> this would work the same way...
>
> > This shell embeds widgets which each implement an excercise, like
> > timestables,
> > fractions, calculation of percentage, addition, substruction, etc. Each
> > widget is a plugin. Its capabilites are configured in desktop files,
> > as they
> > exist for kparts:
>
> or other things for that matter ( e.g. kregexpeditor ;)
as above ;-)
>
> > -----------------------------
> > [Desktop Entry]
> > Name=TimestablesEduPlugin
> > Type=Service
> > ServiceTypes=KEduParts/MathLearning,KEduParts/MathTraining
> > X-KDE-Library=libktimestables
> > Icon=ktimestables
> > -----------------------------
>
> this would stay entirely the same (except that i would change
> KEduParts to KEduPlugins :)
yes, that would be more appropriate :-)
>
> > The large difference to kparts is here, that kparts are based on
> > mimetypes and
> > that they always have an attached document. Kparts-plugins also exist,
> > but they don't have widgets. So we need something new here.
>
> like an Interface together with KTrader stuff... ;)
Well, if KParts::Plugin can have widgets, I'd try to do it that way and extend
the interface in an inherited class.
>
> > So how does the shell know which edu-plugins there are to embed? For that
> > kparts has the KTrader. KTrader uses the sycoca-database which scans all
> > desktop files and builds a cache. You can use the KTrader class to ask
> > for plugins which fulfill certain capabilites.
> > But of course you can also have a shell which only embeds a special
> > plugin (that way you still have the setup you have at the moment with a
> > lot of small
> > apps). You basically can use the same plugins in a lot of different
> > ways.
>
> stays the same too..
>
> > But we are not finished yet. What we also need (and we also don't have it
> > in kparts) is a communication between the shell and the plugin. The shell
> > needs to be notified about the result of an exercise and the shell needs
> > to tell the plugin to create a new excercise.
> > I see 2 ways to do this:
> > signals and slots
> > the interface for the plugin contains predefined signals and
> > slots for the
> > communication, so the shell can connect them after loading the plugin
> > and both shell and plugin can use these connections.
> > DCOP (desktop communication protocol)
> > the desktop communication protocol lets you send messages which are not
> > defined in the interface. Each member of the communication can get a
> > list of available dcop commands.
> > The advantage of DCOP is, that you have reduced compile time
> > dependencies. Still signals and slots might be easier in the beginning,
> > so am in favour of that and if we need a more complex communication, we
> > can still use DCOP later.
>
> This is the second thing i would like to react to:
> 1 DCOP is for _interprocess_communication_. Communication between
> different processes. It is _totally_unsuitable_ here.
> 2 even signals/slots are unnecessary here. You can just simply use
> plain old function calls on the Interface object.
> 3 I don't really see what you mean with "reduced compile time
> dependencies". Anyway, the Interface stuff is good here too, since
> plugins only need the Interface header file to compile, and the same
> goes for the shell app.
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 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.
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.
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.
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) :-(
- - 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?).
With dcop each member of the communication can "explore" the dcop interface of
the other member. 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. 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?
The third method maybe is XML-RPC, but I don't know anything about 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.
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.
>
> > In order to have several excercise widgets in one shell we might use a
> > QWidgetStack to hide the inactive excercises.
>
> hm... didn't know that one, but it seems appropriate, indeed. Or
> perhaps we could use a KTabCtl, to show things in different tab
> pages... But i am very bad at ui design... :)
>
> > The great advantage I see in such a design is the following:
> > plugins can be reused
>
> idd
>
> > educational concepts don't need to be implemented over and over
> > again
>
> hm.. could you give an example of that, cause i don't quite understand
> what you mean, here...
Now each program (kbruch, kmathtool, kpercentage, ...) needs an own
implementation for statistics, the test modes etc. See also the list I gave
in the beginning of the first mail.
>
> > common look&feel
>
> err.. no: only the shell is always the same, as your plugins have
> their own QWidget's, they can look any way they want. Btw. the
> KEduPlugin presents a KActionCollection and a rc file, so that
> the shell's ui is adaptable by the plugins in the same way that it
> works for KParts...
Yes sure - the KEduPlugin can look any way. But you also have widgets in your
shell, which are the interface for the educational concepts (like statistics,
like a start/stop button for the tests, like a wizard to setup a test, ....)
>
> > So how would I proceed....
> > first I'd take ktt (or any other little math app) into a kpart.
> > implement a new interface class for kedupart (which would go into a
> > new lib:
> > libeduparts), inspired by the kparts code
> > check with other KDE people if ktrader can be extended or reimplement
> > something similar
>
> KTrader is not solely for KParts as it is now. KTrader does not need
> any additions..
even better :-)
>
> > How does that sound? Any comments/help/critizism is welcome!
>
> well, those were it :)
> i hope you understand what i'm trying to explain, if not, please ask
> me...
Well, thank you. I hope my explanations are a bit clearer now... sometimes a
bit of paper is really helpful ;-)
eva
>
> cheers
> domi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9VmIYTaAgihPikKQRAsOCAJ9vPvkwEWGHJrxjyActNKsQoF1znQCfca9R
DKzUyHv3P1MXMQ34lz6oGGo=
=BeQs
-----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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic