<!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="mid200404111331.40992.peter@peterandlinda.com"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">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...
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Exactly, so I think this code should go in libkdeedu for easier access from 
different programs.
  </pre>
</blockquote>
Definetely. I'll draw up a class schema and send it to the list when
I'm done...<br>
I only have a limited amount of time per week to work on this, so don't
expect blazingly fast results ;-)<br>
<br>
<blockquote cite="mid200404111331.40992.peter@peterandlinda.com"
 type="cite">
  <blockquote type="cite">
    <blockquote 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>
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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?
  </pre>
</blockquote>
If I can't find anything, I'll contact Trolltech to hear them if they
are interested in such a feature...<br>
<br>
<blockquote cite="mid200404111331.40992.peter@peterandlinda.com"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.
  </pre>
</blockquote>
Yes, and even in languages there are cases where this is necessary...
Learning the alphabet comes to mind...<br>
Speaking of that... Sound we implement something special to ease this?<br>
<br>
<blockquote cite="mid200404111331.40992.peter@peterandlinda.com"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">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?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.
  </pre>
</blockquote>
Offcourse, noted..<br>
<br>
<blockquote cite="mid200404111331.40992.peter@peterandlinda.com"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.
  </pre>
</blockquote>
So the question becomes: What is the policy of learning an item based
on the availability of the different items?<br>
<br>
word only - trivial<br>
word and pic<br>
word and sound<br>
word, pic and sound<br>
pic only - trivial<br>
pic and sound<br>
sound only - trivial<br>
<br>
For now we could leave the policy up to the displaying program, but I'm
not fond of that in the long run...<br>
<br>
<blockquote cite="mid200404111331.40992.peter@peterandlinda.com"
 type="cite">
  <blockquote type="cite">
    <blockquote 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>
    <pre wrap="">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...
    </pre>
  </blockquote>
  <pre wrap=""><!---->
See <a class="moz-txt-link-freetext" href="http://www.w3schools.com/xml/xml_attributes.asp">http://www.w3schools.com/xml/xml_attributes.asp</a> why attributes are 
generally a bad idea.
  </pre>
</blockquote>
Like I said... I hate XML...<br>
I'll draw up version 2 of kvtml as a (mostly) non-attribute XML.<br>
<br>
<blockquote cite="mid200404111331.40992.peter@peterandlinda.com"
 type="cite">
  <pre wrap="">So how do we coordinate work on this?</pre>
</blockquote>
As I can see there are a few main issues:<br>
1. Implementing parser/class of kvtml<br>
2. Implementing learning method classes<br>
3. Layout of ui - kvoctrain main program<br>
4. Layout of ui - kvoctrain learning (possibly something more general)<br>
<br>
The usecases are mostly items of 1 and 3.<br>
Personally I'd like to work on all of them...<br>
<br>
<blockquote cite="mid200404111331.40992.peter@peterandlinda.com"
 type="cite">
  <pre wrap="">Are you working on the make_it_cool branch of KVocTrain?
  </pre>
</blockquote>
Yes. The usecases textfile is in the topdir of that branch.<br>
<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>