<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Hedlund wrote:
<blockquote cite="mid200404101959.34187.peter@peterandlinda.com"
 type="cite">
  <pre wrap="">Hi,

  </pre>
  <blockquote type="cite">
    <pre wrap="">Attached is a list of usecases for the new implementation of KVocTrain...
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Very impressive work. Thank you.
  </pre>
</blockquote>
Thank you!<br>
<br>
<blockquote cite="mid200404101959.34187.peter@peterandlinda.com"
 type="cite">
  <pre wrap="">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?
  </pre>
</blockquote>
Yes! It was my plan to implement at complete seperation of the kvtml
handling from the ui.<br>
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...<br>
<br>
<blockquote cite="mid200404101959.34187.peter@peterandlinda.com"
 type="cite">
  <pre wrap="">Second the kvtml file format itself. The minimum changes I would like to do 
are adding an attribute to the &lt;e&gt; element for storing the rowheight used 
when displaying the vocabulary, and adding &lt;sound&gt; and &lt;image&gt; child elements 
to the &lt;o&gt; and &lt;t&gt; 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. 
  </pre>
</blockquote>
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..<br>
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.<br>
<br>
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...<br>
Also we need to maintain more accurate information about the language
used.<br>
I would also like to be able to autotrack wrong guesses, so we can find
some good hard multiple-choice questions :-)<br>
<br>
What do you mean about rowheight? Shouldn't that be as simple as
min(picture, fontsize) + some buffer pixels?<br>
<br>
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.<br>
<blockquote cite="mid200404101959.34187.peter@peterandlinda.com"
 type="cite">
  <pre wrap="">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?
  </pre>
</blockquote>
I hate XML! ;-)<br>
Seriously, I don't care either way.<br>
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.<br>
Or my idea of implementing example sentences...<br>
<br>
<pre class="moz-signature" cols="72">-- 
Dennis
use Inline C =&gt; q{void p(char*g){
printf("Just Another %s Hacker\n",g);}};p("Perl");
</pre>
</body>
</html>