On 02 Jan 2001 23:04:55 -0500, Hassan Aurag wrote:
Great, this is cool. I have a set of functions from ITimer (don't know if you know it), but if you've got ones that are glib-friendly then even better. As for the GUI part, I am ready to hack that part. I really am only talking about the visual part of the calendar and not the underlying stuff. All dates would be stored as standard international dates (gregorian based), and only the visual part would be hacked in a separate module or maybe as an ifdef or something. Now, I think this is important for internationalization. It should also be available for other calendars I might not be aware of. Are there others? However I won't hack anything until someone from Helix gives us his/her 2 cents worth on this issue.
It would be nice to first see Federico's response on the issues that he brought up (see his mail which provides a link to his response to me). Also - you can not store the "appointments" in Gregorian time unfortunately, simply because it is not "accurate". For example, what if I wish to mark the first day of 'Eid' (the day right after Ramadan is over). I think you know that Ramadan can be 29 or 30 days. So you might get an off-by-one problem. If you store the date in Islamic time then that would be okay. You should be able to specify appointments in my opinion in either Gregorian or Islamic. So I may set-up my flight next week in Gregorian terms, but I set things like Eid, or Hajj appointments in Islamic. You could have an 'option' to show Islamic appointments on the Gregorian calendar, or vice-versa, but these appointments should somehow show up as 'Unreliable'. My date conversion functions are not 100% accurate. They are just good approximations (hey, it predicted Ramadan at the correct day this year!) They are just basically C implementations of the Lisp functions in the Emacs calendar (oh, and /AFTER/ I went through learning lisp and trying to convert the code into C, somebody emails me C++ versions of these functions (grrr!!)) Since I may be away from email sometime soon (for a while), I'll attach the conversion functions that I have. Its only 10K (with an empty header file and a Makefile). On my TODO list was: use a IslamicDate structure to hold the day/month/year, convert it into a library (inclues autoconf support), if glib is installed then compile in GDate conversion functions (not done). This project is on the back burner though cos I'm too busy working on various other GNOME projects. Regards, Ali
On 03 Jan 2001 03:51:30 -0200, Ali Abdin wrote:On 01 Jan 2001 21:14:53 -0500, Hassan Aurag wrote:First happy new year everyone. Speaking of which, I'd have a request with which I might help. While most people use the standard grogorian calendar, I think many (muslims and hebrews among others) might want to use other calendars. My request here applies equally well to the stock gtkcalendar widget, but that's another issue. For the islamic calendar I can help with the functions to convert, but I am sure you will find many people who'd help with other calendars (the other I know of is the hebrew one). The implementation would essentially go like this: - modular so that people not interested in other calendars won't have to download all modules related to those. - Each module would implement either a combo standard/other calendar or only other calendar depending on user's wish. - Translation when it becomes applicable is handled by that module. - All internal scheduling is handled by standar time: so when one appointement is entered in eg muslim dates it'd be converted to standard time before processing. - In a few words, the module should implement the visual part of calendaring. Thanks for reading thus far.Actually, I already have the Islamic calendar conversion functions done :) You can basically convert from time_t -> Islamic and vice versa. It was discussed briefly on gtk-devel recently wether Islamic calendar functions would be desired to go into glib (apparently not). But it would be trivial to make the existing code translate an Islamic Date <-> GDate and Islamic Date <-> struct tm. So while the work for the conversion function is done. It still remains to see how this would 'fit in' with the existing calendar (which uses the iCalendar specification). The problem is: does evolution implement its own way, or should someone propose a set of "extensions" to the IETF folks? Also, is somebody actually willing to hack on the GUI portion? (I unfortunately am too occupied for that, but I can work on cleaning up the low-level Islamic/Gregorian calendar functions that I coded). Regards, Ali _______________________________________________ evolution maillist - evolution helixcode com http://lists.helixcode.com/mailman/listinfo/evolution________________________________________________________________________ Hassan Aurag CAE Electronics Ltd. Aircraft Systems Specialist - Update Group Email: auragNOSPAM cae ca ________________________________________________________________________ Those who do things in a noble spirit of self-sacrifice are to be avoided at all costs. -- N. Alexander. ________________________________________________________________________
Attachment:
cal-islamic.c
Description: Text Data
Attachment:
cal-islamic.h
Description: Text Data
Attachment:
Makefile
Description: Text Data