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

Dennis Haney davh at davh.dk
Mon Apr 12 23:42:24 CEST 2004


Peter Hedlund wrote:

>>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...
>>    
>>
>
>Exactly, so I think this code should go in libkdeedu for easier access from 
>different programs.
>  
>
Definetely. I'll draw up a class schema and send it to the list when I'm 
done...
I only have a limited amount of time per week to work on this, so don't 
expect blazingly fast results ;-)

>>>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.
>>    
>>
>
>Yes, I'm aware of this problem. Your solution is more complete. I don't know 
>how to create and work with such files, but I guess there is code in KOffice 
>also?
>  
>
If I can't find anything, I'll contact Trolltech to hear them if they 
are interested in such a feature...

>>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.
>>    
>>
>
>We also need to always keep in mind that the content isn't necessarily a 
>language. I think you called it a toy language. The user should be able to 
>name data columns arbitrarily.
>  
>
Yes, and even in languages there are cases where this is necessary... 
Learning the alphabet comes to mind...
Speaking of that... Sound we implement something special to ease this?

>>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?
>>    
>>
>
>No, the row height when displayed in a table (grid). For long expressions you 
>want word wrapping and the ability to adjust (and remember) the row height. 
>The user should also be allowed to set preferred row heights regardless of 
>font size.
>  
>
Offcourse, noted..

>>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.
>>    
>>
>
>Neither, I think. A word should not be required, but in many cases I think the 
>image or sound would illustrate/support the word/expression.
>  
>
So the question becomes: What is the policy of learning an item based on 
the availability of the different items?

word only - trivial
word and pic
word and sound
word, pic and sound
pic only - trivial
pic and sound
sound only - trivial

For now we could leave the policy up to the displaying program, but I'm 
not fond of that in the long run...

>>>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...
>>    
>>
>
>See http://www.w3schools.com/xml/xml_attributes.asp why attributes are 
>generally a bad idea.
>  
>
Like I said... I hate XML...
I'll draw up version 2 of kvtml as a (mostly) non-attribute XML.

>So how do we coordinate work on this?
>
As I can see there are a few main issues:
1. Implementing parser/class of kvtml
2. Implementing learning method classes
3. Layout of ui - kvoctrain main program
4. Layout of ui - kvoctrain learning (possibly something more general)

The usecases are mostly items of 1 and 3.
Personally I'd like to work on all of them...

>Are you working on the make_it_cool branch of KVocTrain?
>  
>
Yes. The usecases textfile is in the topdir of that branch.


-- 
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/20040412/0faf315d/attachment.html


More information about the kde-edu mailing list