Re: categories in core

On Monday 13 October 2003 19:54, David Calinski wrote:
> On Monday 13 of October 2003 08:36, Peter Bienstman wrote:
> > > Active categories are NOT saved to any files: when memaid starts all
> > > categories are activated by default. I guess I should implement
> > > loading/ saving activated categories in core, right?
> >
> > Yeah, but that could simply be writing an extra boolean to the file when
> > saving the category info.

(I seem to have a different opinion than Klemens here ;-) )

> But what about some very simple memaid frontends (e.g. console version),
> that probably won't have implemented using categories... hm, they would
> have to activate all categories, otherwise they would work only with
> categories activated earlier by another frontend.

Well, since all categories are activated by default in the core, the simple 
frontend doesn't even need to know that categories exist. So I don't see a 
problem there.

> Or... what about such user requirement:
> somebody may want to have elements from all categories in the repetition
> mode, but only from some categories in "forced ahead of scheduled time
> repetitions"?
> Similarly: all categories in "repetition mode" and only some in "Final
> drill" mode.

I still think active categories need to be saved by the core, because it makes 
sense that if a user moves his database around different clients (e.g. from 
superkaramba to kmemaid and back), the active categories should not be lost.

If a client wants to do something fancier like having different categories 
active for different learning modes (although I'm not sure how useful that 
would be, also given that's it's more complex to implement) then that's still 
possible even if elements.txt only contains one active bit per category. The 
client can just override that info whenever the learning mode changes, 
according to the client's own configuration files.

In my opinion, the core should offer at least the basic service of basic 
persistence per category (which shouldn't be too hard to implement, I guess), 
and the more fancy stuff can be left to the clients (which will be be a lot 
harder to implement).

Peter

------------------------------------------------
Peter Bienstman
Ghent University, Dep. of Information Technology
Sint-Pietersnieuwstraat 41, B-9000 Gent, Belgium
tel: +32 9 264 34 45, fax: +32 9 264 35 93
WWW: http://photonics.intec.ugent.be
email: [email protected]
------------------------------------------------



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php