[kde-edu]: KVocTrain rewrite - feature list and usecases

[Dennis Haney]

Peter Hedlund wrote:

>Hi,
>
>  
>
>>Attached is a list of usecases for the new implementation of KVocTrain...
>>    
>>
>
>Very impressive work. Thank you.
>  
>
Thank you!

>I have a couple of additional items I want to discuss. 
>
>First the libkdeedu library. As it is now there is a very rudimentary class 
>for loading kvtml files. I believe we need a library with shared classes for 
>maintaining kvtml documents. Now if you create an advanced file in KVocTrain, 
>then load it in FlashKard or KWordQuiz, make a little change and save, 
>chances are a lot of information is lost. The library should provide a kvtml 
>document class that can be shared between applications and that will handle 
>loading and saving without data loss. I know this will probably be overkill 
>for a program like KHangman, but will allow a greater number of files to be 
>used by several edu programs. Comments?
>  
>
Yes! It was my plan to implement at complete seperation of the kvtml 
handling from the ui.
First, because it will make it much easiere to maintain in the longer 
run. Second, because it allows for several programs using the same 
interface and thus making them both more maintainable and more robust. 
Third, with the implementation I have in mind the complexity of the file 
will increase to where it is not just a two hour job to implement a 
reader...

>Second the kvtml file format itself. The minimum changes I would like to do 
>are adding an attribute to the <e> element for storing the rowheight used 
>when displaying the vocabulary, and adding <sound> and <image> child elements 
>to the <o> and <t> elements. Sound and image are needed to create a flashcard 
>program that can use this type of data. The elements would contain URLs 
>linking to sound or image files. 
>  
>
My plan was to save these (picutre/sound) files in the kvtml file 
aswell. My plan is then to change the kvtml filetype to be a collection 
filetype, like openoffice packs its files as zip archives holding the 
pictures/sound etc. as seperat entities in the file..
My logic is that the user is unlikely to guess (know?) that there are 
several files to copy, when (s)he makes a backup. And it will be 
difficult to figure out which (sound/picture) files belong to which 
kvtml file.

As for change of the format. We need better support for multiple way of 
maintaining information about the learning method. Not all of them will 
use the same information...
Also we need to maintain more accurate information about the language used.
I would also like to be able to autotrack wrong guesses, so we can find 
some good hard multiple-choice questions :-)

What do you mean about rowheight? Shouldn't that be as simple as 
min(picture, fontsize) + some buffer pixels?

About the picture/sound handling, should I aim for an implementation 
where they are attached to a word or should I aim for where they are 
replacing the word.

>Going further than that I don't particulary like the structure of the kvtml 
>DTD. It relies too heavily on attributes. E.g. comments, false friends, 
>synonyms and antonyms are all attributes. The files would be much easier to 
>handle and read (by human and machine alike) if these things were child 
>elements instead. Comments?
>  
>
I hate XML! ;-)
Seriously, I don't care either way.
The only place it makes a difference is where there can be a unknown 
number of elements of a given type. Like the autotrack feature mentioned 
above.
Or my idea of implementing example sentences...

-- 
Dennis
use Inline C => q{void p(char*g){
printf("Just Another %s Hacker\n",g);}};p("Perl");

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-edu/attachments/20040411/eff4a274/attachment.html