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

List:       kde-edu-devel
Subject:    [kde-edu-devel] possible design math app
From:       Eva Brucherseifer <eva () kde ! org>
Date:       2002-08-11 10:00:03
[Download RAW message or body]

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

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.

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).
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 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:
- -----------------------------
[Desktop Entry]
Name=TimestablesEduPlugin
Type=Service
ServiceTypes=KEduParts/MathLearning,KEduParts/MathTraining
X-KDE-Library=libktimestables
Icon=ktimestables
- -----------------------------
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.

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.

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.

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

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

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

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

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

iD8DBQE9VjWjTaAgihPikKQRAsnwAJ4xyHPvI6n8T1V6I2yoWk9WQ58o1gCghBu/
A9pAf/DudepS51lKXV46GRM=
=kLdO
-----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]