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

[Peter Hedlund]

Hi Dennis,

On Sunday 11 April 2004 07:40 am, Dennis Haney wrote:
> 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...

Exactly, so I think this code should go in libkdeedu for easier access from 
different programs.

> >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?

> 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.

> 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.

> 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.

> >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.

So how do we coordinate work on this? Are you working on the make_it_cool 
branch of KVocTrain?

Thanks,
Peter