Re: [gDesklets] Calendar proposal ant others.

[Bjoern Koch <H Humpel gmx de>]

Hi there,

> I've had an idea about an aesthetic improvement: what about showing events
> and current day changing the colour of the font instead of printing a
> rectangle on the background? 
[...]
> instead. The group is now used only for the ".x", ".y", ".on-enter",
> ".on-leave" (which are in label too cause they are common attributes) and
> for ".bg-color" (which can be replaced with the ".color" of the label).
> 
> Do u agree?? Do u think it looks better?

Hmmm... not sure. Looks nice, but I personnaly like to have the user
make his own choice. So I guess (IMHO) it would be nice to have a chance
to select one of the two methods.
I know, pretty bad programming overhead.
BUT: what about adding a "real bg-color" to the labels ?
Quite not sure about it though...

> And .... what about the management of the events now? Bjoern said it was
> better to eliminate those big arrays. Were you talking about only the arrays
> of mobile events (like EasterApril = ("Easter", [(2007, 21), (2008, 13),
> ....]) or about the "big structure" in general?

Welll, basically: both.

> Because i think that to keep all the structure in memory (ram) is a waste
> (for all the languages too) cause it's rare that the user change the event
> set or even the month showed. What about reading the events data of the
> month from a file only when needed? Cause if in the future we will add more
> and ore events and language the structures we're using now will become
> enormous compared to the single month we have to show, if necessary.

Looks to me that the calculation on Eastern and the other events
depending on it isn't that CPU consuming. So I guess it could be done
this way:

- Calculate Eastern depending on the current year.
- load "language file" and calculate all events for current year and
country (and/or state?) and put them into a much simpler and smaller
arry (?)

So, on every change of a month we only will have to read out the data
from the array.
On every change of the year and/or language file we will have to
re-calculate the array.

And here (again) some of the already collected thoughts about it, just
to have them on the ML as well:

--- snipp ---

The main problem is that there are basically 3 kinds of hollidays:

1. fixed dates (like always the first of may, no matter what)
2. fixed days (like the second Sunday in March)
3. relative dates (like Pentecost -> 50 days after Eastern)

1. is very simple, but 2. and 3. are "making trouble" with the way
hollidays are currently handled in the Calendar desklet.
It would be better (if not best) if these hollidays get calculated
on-the-fly.

Calculating 2. shouldn't be too hard, but 3. looks like impossible as
(as far as I can see) there are different ways to calculate Eastern (and
this seems to be the major - if not the only - event to be considered).
Anyway: we could supply a simple list of Eastern for the next x years
and use these dates for the calculations.

So, what I want to say: we should get rid of these arrays (as far as
possible). But we need a simple, easy and fast way for the calculations,
like: Eastern+60 or March(2ndSun)

--- snapp ---

and:

--- snipp ---

It even gets worse: for example, depending on the state you are living
in Germany (and I guess it will be same for other countries) you are
having different/additional hollidays.

How to deal with that ?
Very good question... maybe something like:

ge_all: list of hollidays for all states in Germany
ge_xyz: additional hollidays for the state xyz in Germany

The lists should have 3 sub-arrays (or what ever you would like to call
them) each:
1. fixed dates
2. fixed days
3. relative days

This might work, but probably there is a better way to do it ?!

No matter what: the current approach with the lists/arrays is working
(more or less) fine, but sooner or later we should switch to a different
approach because now you basically need a Calendar to look up some
hollidays to fill the dates in the desklets lists.

--- snapp ---

> A last question. I wrote an answer in launchpad about the management of the
> preference's callback function but I've not received an answer yet. Do u
> know why? It simply takes a lot or u think it was a stupid question? Don't
> know...

Upps... don't know why I didn't get an eMail about this new question.
Just found out about it now.

Greetings, Bjoern