[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-12 21:42:24
Message-ID: 407B0D40.7070903 () davh ! dk
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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");
[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="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 <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.
</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 => 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