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

List:       kde-edu-devel
Subject:    [kde-edu-devel] math app - design version 0.1
From:       Eva Brucherseifer <eva () kde ! org>
Date:       2002-08-18 19:33:06
[Download RAW message or body]

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

Hi all,

after spending the weekend in front of my laptop, here are the results. You 
can download the code (early design state!) from 
http://www.rtr.tu-darmstadt.de/~eva/download/kmath-0.1.tar.gz
I used kbruch as an example. 

Right now working is:
- - a lib with the interface of edu parts
- - the part (kbruch, I did change the design of kbruch only where I had to)
- - the communication between the part and the shell
- - the shell has some small functionality (statistics class is taken from 
kbruch)

Missing (or only very quick&dirty implemented) is:
- - configuration of the part (and thus the exercises)
- - configuration of test suites
- - correct loading and management of different parts (at the moment kbruch is 
hard coded)
- - command line option to load a specific part (that can be used to create
  desktop files for each part, so that it can be used as standalone app)

The source has the following directories:
keduparts - interface of the edupart
kmath - shell
plugins - place of the parts (rename to "parts"?)
plugins/kbruch - kbruch edu part

Last weekend we had a diskussion about the class, the edupart interface should 
inherit from. After reading kparts code and the documentation, I think, I can 
say, that we definitly have parts in our application and no plugins. Plugins 
originally don't have widgets, parts do have. Parts also don't need to handle 
files, this only applies to the two specialisations of Kparts::Part which are 
Kparts::KReadOnlyPart and KParts::KReadWritePart.
So far it's not yet clear in my code, but I think, I'll rename all "plugins" 
into "parts".

Still, I got the idea, that we indeed might want to deal with files along with 
the edu parts. Right now, most math apps create random exercises (or is task 
the better word?), which the user has to do. The user has no chance, to save 
a set of exercises and repeat it later. The user also cannot save test 
parameters like, the number of tasks, the level of difficulty, the special 
type. 
Now imagine, we want to enable this... here comes the KParts::ReadWritePart 
in. All edu apps would work on the same mimetype (.edu?) and these files 
describe tests consisting of a number of tasks, which are maybe implemented 
in several edu part libraries. 

So far for today... time to enjoy the rest of the weekend without a computer 
:-)

Greetings,
eva


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

iD8DBQE9X/ZyTaAgihPikKQRAsgqAJ9sCkItHgFI+koo2Om0/X5Y1LbZuACgjLhq
qNeAw6B5qW2za/rbIj/9otM=
=0Jka
-----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]