Re: some news / ideas

On Sunday 05 of October 2003 17:37, Carsten Niehaus wrote:
> In KDE-EDU is a class called KPlotWidget. With that class you can simly
> plot 2d-Plots with x/y-Axes, cool tickmarks and everything you ever wanted
> :) I already
> use that class in Kalzium and it works great. I am thinking about adding
> plotting
> of the statisticts. Perhaps something like the changes of a certain value
> in time (eg
> in the last 4 weeks). Are those facts stored in the datafile?

Actually only few data is stored (BTW: "data" is not plural in English, right? 
That's weird for me. :-)
 
	u_short l_ivl;    /* last interval computed by ann */
        u_short rl_l_ivl; /* real last interval */
        u_short ivl;      /* current interval computed by ANN */
        u_short rp;       /* number of repetitions */
        u_short gr;       /* (last) grade */

nothing more, but I think about adding additional, optionally used file 
"statistics.c" in core with some functions to store more data about every 
repetition - that data would be stored in another file and would be used only 
for statistics, not for ANN. (ANN needs just those few data above).


> Well, two ideas: What about a enum categorie { SCIENCE = 1 , LANGUAGE = 2
> ... }
> The problem with that: the user can't define the categories himself.

Yeah.

> Therefore I propose
> this: In a configurationfile is  a list with categiers. Perhaps XML?
>
> <categories>
>     <KMAcat>
>        <name>Science</name>
>        <defaultDifficulity>easy</defaultDifficulty>
>         and so on...
>      <KMAcat>
>      <KMAcat>
>        <name>Languages</name>
>        <defaultDifficulity>medium</defaultDifficulty>
>         and so on...
>      <KMAcat>
> </categories>

And also sub-categories maybe... but I see you think about yet-another-file 
and something KMemAid specific. :)
I would like to avoid it - ideally all important data should be in one file 
only, I think. And support for categories should be in core module: in plain 
ANSI C, ideally without any dependency, on XML parsers, etc.
And all things stored in binary file (elements.txt is just for user, K/MemAid 
normally doesn't read it) to squeeze the maximum from machine - MemAid should 
start and work as fast as possible. :-P

Now, I do have some ideas how to simply and efficiently implement it in core 
and store data - but I don't know how much my interface to it will be usable 
from GUI programmer point of view. (Simply: I don't how how this TreeList 
widgets works, I have never used it, don't know what data it needs, etc. -  
Fox Toolkit documentation is very vague, I can't look at it..).

From GUI programmer point of view:
Let's say every "struct elem" has also additional "int category" field.
And there is one more function in core: 
char *ma_description_of_category (int category); //that returns category name.

I think it would be enough to code this TreeList widget to show all elements 
in categories(?), to do something like this:
http://www.supermemo.com/images/contents.jpg
but without sub-categories.

Now about sub-categories. (if we want to implement them at all (what do you 
think?)).
There could be be yet another function in core, e.g.:
int ma_parent (int category); //that would return parent number
					// (or zero if this category is in root)

Now I can code all described above.
I just need feedback - if this is fine from GUI implementation, or I missed 
something?

(Currently I am implementing simply FXList (plain list, without parents, etc. 
- so no categories here) on a window with buttons in my GUI, FXTreeList 
widget is ahead of me, but I will get to it, anyways.)


-- 
David Calinski
http://neodave.civ.pl
/* FreeBSD: When we say free, we mean it. */



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf