Re: Summary of Decisions? (lunar calendar)

[Ali Abdin <aliabdin aucegypt edu>]

> Feel free to disagree, but I think the best way to handle it is as
> follows:
>
> 1. Write the Islamic <--> time_t conversions.  Stick them in a file
> which will ultimately be linked into gnomecal.  (I don't think it
> needs a separate library, but if you think it will be generally
> useful, we could write a libcalendar or the like.)

Agreed. Just get the code done - the integration is a minor technicality.
You said some sort of 'module' system, so I assumed you wanted libraries or
something. But I guess I should just use the concept of 'modular' (e.g. a
set of functions that can be used at run-time). I believe the Islamic <-->
time_t conversions would be the 'easiest' part - but I just need a
'reference' point. i.e. Could someone tell me the islamic date at the
epoch, and the islamic date currently (of course I could just pick up a
news paper and read it - DOH) but anyway, anyone know the islamic date at
the epoch (as a reference point)? if not - I guess i'll just have to do a
little research

> 2. Modify the event editor dialog to convert Islamic dialog input
> into a time_t before it stores it in the internal structures, and to
> Islamic when it edits appointments

Sounds easy enough :) (of course, the concept is much more different than
actually coding the thing - *sigh* if only gnomecal used glade)

> 3. Modify the other widgets as appropriate to let them display
> Islamic info (obtained, as necessary by converting from time_t ->
> Islamic).

This is actually the hardest part. I think Changing the UI is /extremly/
difficult based on the current gnomecal source organization. A lot of it is
Gregorian based (and this was just through a quick look through the code).
In Islamic calendar for example there is no concept of a 'week' so the
organization of 7 days per line really doesn't make a difference - but for
other calendars it "might" - thats just ONE example :) Then there is the
hardcoded day names, I think the month is a bit 'modular' due to it being
an actual GtkObject so there is limited customizability there. My aim is to
be able to just 'click' on gregorian and it adapts - and to 'click' on
Islamic it adapts - 'click' on whatever and it adapts - but This is the
'ultimate' goal :) I'll work on the above first :)

> That should handle everything that you need, since loading and saving
> will work as before (since time_t will be converted to Gregorian at
> save time and vice versa).  You still need some way to handle
> "floating" dates, however.

Yup - i'll treat everything as "fixed" for now - when the core is done, I
guess i can ask more about it when i come to it

> I'm sure I left some elements out, but feel free to ask more specific
> design or implementation issues as they come up.

Sure:)

> > Also - how will development work on this? my suggestion is a branch on
> > CVS cos i think this is not going to be an easy patch to just apply to
> > the main-tree or whatever (and the main tree is in feature-freeze right
now).
>
> Miguel has quite convincingly in the past explained to me why a
> branch is not a particularly good idea, and I agree.  My suggestion
> would be to do what I'm doing on iCalendar- do enough work on your
> local machine to get something which is at least compilable and
> reasonably correct, and then commit to HEAD (after it's thawed).
> Then try, as much as possible, to keep the tree "correct" as you
> gradually integrate your code into gnomecal.  (It shouldn't be too
> hard to maintain the correctness of gnomecal when it's set to
> Gregorian mode while still developing the Islamic mode; you can even
> use conditional compilation or an auto* hack to keep Islamic mode
> from building on other's machines, as long as you provide the
> requisite stubs (or #ifdef's) in the main code to keep it linking.)

Whatever - I'm not too comfortable with #ifdef's and auto* hacks or
whatever. So I might/will probably just code stuff. Sometimes I put #if 0
switches so can test things quickly (on/off) for example in my gLife
program I came up with three different algorithms for a function and i can
switch between anyone (e.g. one stable/slow one, one outdated one, and one
untested/fast one). :) of course, I also comment unworking stuff out.

> However, I would prefer that you *not* commit anything, even to
> another branch, until we release 1.2- that will simply complicate
> matters when we need to merge them.  If you really want to put code
> in CVS, create a subdirectory and don't include it in the standard
> Makefile.am or configure.in, so it doesn't get built.
>
> Hopefully, the freeze for 1.2 won't be too long- in fact, you can
> hasten its end by helping to quash as many outstanding bugs as
> possible. :)

No need to worry - i don't have a CVS account so i can't commit - even if I
wanted to ;) I'm currently not working on any code due to Civ:CTP - I start
playing, hours fly-by, by the time I'm done, I barely have enough time to
do homework (I thought in college they only give u 2 essays and an exam per
semester and then leave you alone) and get a few hours of sleep. Oh well :)
My worst case scenario/estimate is that I start hacking on this during the
last week of febuary/beginning of March. :)