I have made some relatively significant changes to gpe-calendar today.
It is still buggy (off by an hour in day-view; off by a day in
year-view), but it sorta, almost, kinda works now....
Check it out! (in CVS or in my "too unstable for unstable" feed at
http://granular.che.pitt.edu/~mccarthy/feed)
later...
Joe
PS. Hey p. I didn't clist-ify the week-view yet, but if you look at what
I did for the day and (probably better yet) the future view, it should
not be hard...
On Sun, 2002-05-12 at 13:09, Philip Blundell wrote:
> On Sun, 2002-05-12 at 17:08, Owen Cliffe wrote:
> > Now that there is code for PIM does anybody have any improvement ideas
> > for the the PIM schema.
>
> One important improvement would be to add support for storing events.
> :-)
>
> The table that gpe-calendar uses currently looks a bit like this:
>
> create table events (
> uid integer NOT NULL, -- unique ID
> start integer NOT NULL, -- Unix time
> duration integer, -- in seconds, zero for alarm-only events
> alarm integer, -- in seconds, time before "start" to
> -- sound alarm. NULL if alarm not required.
> description text -- just what it says
> )
>
> This still lacks support for recurring events. Internally, gpe-calendar
> represents those as:
>
> typedef enum
> {
> RECUR_NONE,
> RECUR_DAILY,
> RECUR_WEEKLY,
> RECUR_MONTHLY,
> RECUR_YEARLY
> } recur_t;
>
> struct
> {
> recur_t type;
> unsigned int count; /* number of days, weeks or whatever */
> unsigned int daymask; /* bit 0 = Mon, bit 1 = Tue, etc */
> time_t end; /* no recurrence after this time;
> 0 = forever */
> } recur;
>
> and it might be reasonable just to translate that directly into SQL.
>
> It's not completely clear to me what the best way to represent calendar
> time is. Unix time is unambiguous and (usually) easy to manipulate, but
> doesn't necessarily do what you want when different timezones and/or
> daylight savings are involved. I haven't done any investigation of how
> other PIM apps handle this.
>
> There probably also wants to be some way to specify what sound to play
> when the alarm goes off.
>
> As for to-do stuff, gpe-todo uses a two-table scheme:
>
> create table gpe_todo_lists (
> id integer NOT NULL, -- unique ID
> description text -- title of this list
> )
>
> create table gpe_todo_items (
> id integer NOT NULL, -- good ol' unique ID
> list integer NOT NULL, -- list of which this is a part
> state integer NOT NULL, -- completion status
> description text, -- pretty self-explanatory
> due_by text, -- date, time in ISO format,
> completed_at text -- ditto
> )
>
> p.
>
> _______________________________________________
> GPE mailing list
> GPE_at_handhelds.org
> http://handhelds.org/mailman/listinfo/gpe
-- Joseph J. McCarthy, Assistant Professor Department of Chemical and Petroleum Engineering University of Pittsburgh 1249 Benedum Hall Pittsburgh, Pennsylvania 15261 Ph. 412-624-7362 Fax 412-624-9639 mccarthy_at_engrng.pitt.edu http://granular.che.pitt.eduReceived on Wed May 22 2002 - 23:37:13 EDT
This archive was generated by hypermail 2.2.0 : Mon Jul 25 2005 - 17:18:59 EDT