Re: categories in core

On Monday 13 of October 2003 21:35, Peter Bienstman wrote:
> > 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.

All categories are activated by default - now.
But if I will implement saving/loading active categories in core, and later 
(as an user) I will de-active some categories in a GUI version,
then yet later I will use console version (from a different location - I 
sometimes work remotely on my computer, but in console) I won't be able to 
use some categories.
Well, ok, I consider this argument not so important as the one below.

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

I think we think about a bit different use of "active" categories. ;)
I think that active categories (the one I want to learn at the moment) are 
more "volatile".
E.g. tomorrow I have an exam from algebra, then today I make active only 
"algebra" category and learn only it.
Tomorrow I may turn active all categories.
I don't see "active" categories as something more persistent - I don't see any 
point of having deactivated categories for longer.. But it's just me. I 
wonder about your views and your possible use of "categories".

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

Hmm. I consider "scheduled repetitions" to be very important - I want to have 
always all categories activated in this mode as I want to have reviews 
exactly on the scheduled day.
At the same time I may want to worry about specific category/topic that I need 
to learn for next few days (e.g. exam) - so in "Force ahead of repetition" 
mode I may turn only one category.
I think it is useful. :)
And it's not that hard to implement, but something (core or frontend) should 
remember simple table for all modes. In C++:
bool category_active[number_of_total_categories];

But frontend may have implement many modes. E.g. I initially wanted to 
implement such modes/options:

"finall drill" (all categories)
"final drill from specific categories"
"force ahead of scheduled time repetitions" (default: all categories)
"force ahead of scheduled time repetitions from specific categories"
(... etc ...)

Now if the core (not a frontend) will save activated categories (and only one 
such table, not for multiple modes) then the implementanion of the idea above 
would be more complicated, I think... hm, or maybe not.

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

Yes, you are right here... but that would be double implementation (of saving 
data about activated categories): in core and in frontend.
And now:
feature-rich frontend would probably not use internal core "active 
categories",
while simple frontend maybe won't use categories at all... well, depends.

> 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).

It's not hard to implement, you are right.
Ok, I am lost here. :)
Probably you are right, but it's against my personal accustoms (e.g. I would 
never de-activate categories for "scheduled repetition" mode, so I find 
"active categories for all modes" idea useless for me.).
I wonder what others think.

Dave



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