=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

your discussion about a common math app was quite interesting and I would l=
ike=20
to come up with a design proposal. I have some holiday soon and I'd also li=
ke=20
to put some coding work into it.

=46irst of all: I am not for one large math app in one piece, but I am also=
=20
against masses of small apps. What I favour is a plugin design, where you=20
have shells which embed edu plugins. These plugins would have a common=20
interface and they should be easily reproducable so that a lot of excercise=
s=20
can be implemented (I got my old algebra school book from my parents=20
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 t=
o=20
do things' which are kparts-plugins  (if you are not familiar with kparts,=
=20
you should definitly have a look at the very good tutorials at=20
developer.kde.org. if you are german, I can also send you a german article=
=20
from iX magazine).
Here is the design:

You have a shell, which implements educational concepts.=20
This can be:
=2D - learning something, with imidiate feedback if an answer is correct or=
 not.
=2D - training: do the excercises as fast as possible
=2D - feedback at the end of a set of excercises
=2D - some flashcard approach, where excercises with incorrect answers come=
 up=20
again
=2D - exercises embedded in games
=2D - statistics
=2D - .... (whatever teachers come up with)

This shell embeds widgets which each implement an excercise, like timestabl=
es,=20
fractions, calculation of percentage, addition, substruction, etc. Each=20
widget is a plugin. Its capabilites are configured in desktop files, as the=
y=20
exist for kparts:
=2D -----------------------------
[Desktop Entry]
Name=3DTimestablesEduPlugin
Type=3DService
ServiceTypes=3DKEduParts/MathLearning,KEduParts/MathTraining
X-KDE-Library=3Dlibktimestables
Icon=3Dktimestables
=2D -----------------------------
The large difference to kparts is here, that kparts are based on mimetypes =
and=20
that they always have an attached document. Kparts-plugins also exist, but=
=20
they don't have widgets. So we need something new here.

So how does the shell know which edu-plugins there are to embed? For that=20
kparts has the KTrader. KTrader uses the sycoca-database which scans all=20
desktop files and builds a cache. You can use the KTrader class to ask for=
=20
plugins which fulfill certain capabilites.=20
But of course you can also have a shell which only embeds a special plugin=
=20
(that way you still have the setup you have at the moment with a lot of sma=
ll=20
apps). You basically can use the same plugins in a lot of different ways.

But we are not finished yet. What we also need (and we also don't have it i=
n=20
kparts) is a communication between the shell and the plugin. The shell need=
s=20
to be notified about the result of an exercise and the shell needs to tell=
=20
the plugin to create a new excercise.
I see 2 ways to do this:
=2D - 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.
=2D - 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.=20
The advantage of DCOP is, that you have reduced compile time dependencies.=
=20
Still signals and slots might be easier in the beginning, so am in favour o=
f=20
that and if we need a more complex communication, we can still use DCOP=20
later.

In order to have several excercise widgets in one shell we might use a=20
QWidgetStack to hide the inactive excercises.

The great advantage I see in such a design is the following:
=2D - plugins can be reused
=2D - educational concepts don't need to be implemented over and over again
=2D - common look&feel
=2D - we can reuse the KDE knowledge of the kparts/ktrader implementation, =
maybe=20
we even don't need to reimplement it but extend existing code

So how would I proceed....=20
=2D - first I'd take ktt (or any other little math app) into a kpart.=20
=2D - implement a new interface class for kedupart (which would go into a n=
ew lib:=20
libeduparts), inspired by the kparts code
=2D - check with other KDE people if ktrader can be extended or reimplement=
=20
something similar

How does that sound? Any comments/help/critizism is welcome!

Greetings,
eva
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9VjWjTaAgihPikKQRAsnwAJ4xyHPvI6n8T1V6I2yoWk9WQ58o1gCghBu/
A9pAf/DudepS51lKXV46GRM=3D
=3DkLdO
=2D----END PGP SIGNATURE-----

_______________________________________________
kde-edu-devel mailing list
kde-edu-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-edu-devel