[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-edu
Subject:    Re: [kde-edu]: KVocTrain rewrite - feature list and usecases
From:       Dennis Haney <davh () davh ! dk>
Date:       2004-04-11 14:40:10
Message-ID: 407958CA.1060208 () davh ! dk
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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");


[Attachment #5 (text/html)]

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


_______________________________________________
kde-edu mailing list
kde-edu@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-edu


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic