On Wed, 23 May 2001 18:58:58 CDT, Federico Mena Quintero wrote:
>Okay, let me explain how the whole thing works. Forgive me if this is
>too verbose, but people who are not familiar with the way the
>Evolution Calendar works may find this useful.
No, it's a great, and much-need explanation; had I thought to ask the
list my question three days ago, I could have saved myself much
random jumping around the source by reading it. (Although in the
end, it was worth it, since I read much more of the code than I
otherwise would have.) We should add it to the developer
documentation, either as improvements to the existing descriptions or
even just as a cut-and-paste of your message.
Random note for the future: ideally, there would be documentation
listing all of the signals emitted, CORBA calls handled, etc. and how
the objects interact. Is that what gtk-doc can do automatically?
>Then we added some code so that the PCS could do live search queries.
>This is basically searching functionality for the calendar. Instead
>of simply having a
>
> UID_List cal_client_gimme_objects_that_match (client, search_criteria)
>
>we have a more elegant mechanism through which you create a CalQuery
>object:
>
> CalQuery cal_client_get_query (client, search_criteria)
>
>In effect, a CalQuery is magic stuff that filters the notifications
>from the PCS so that you will only get "obj_updated" and "obj_removed"
>signals from it when an object matches your query or no longer
>matches.
This is really cool, BTW. Filter expressions limited only by our
creativity in creating S-exp functions. :) (Is there a UI yet for
creating arbitrary filter expressions? Probably an expert-only
feature, but I suspect power users would love it.)
[snip description of S-exps]
>When you create the CalQuery, the PCS will go through the objects in
>the calendar looking for those that match your criteria. When it
>finds an object that matches, the CalQuery will emit the "obj_updated"
>signal. It will emit the "query_done" signal when it runs out of
>objects.
It's not immediately related to my problem, but why do you need
"query_done"? Isn't the idea that since they are live queries, you
just hook your add-to-graphical-view function onto the "obj_updated"
signal and process them as they come in? Or is "query_done" more
useful for a search dialog box type of "snapshot"?
>Now, the interesting thing is that the CalQuery remains alive until
>you destroy it. If new objects get added to the calendar and they
>happen to match the sexp from a live CalQuery, that CalQuery will also
>emit the "obj_updated" signal. If an object used to match a
>particular query and it gets changed so that it no longer matches, or
>if the object is deleted, then the CalQuery will emit the
>"obj_removed" signal.
This can happen after "query_done", right?
>The way to make views display more than one calendar is as follows.
>
>All the views store a single CalClient. This should be replaced with
>a list of something like
>
> struct LoadedCalendar {
> CalClient *client;
> CalQuery *query;
> any_information_you_need_to_paint_the_events_for_that_calendar
> }
>
>So for each open calendar you need a CalClient, a CalQuery to filter
>which objects to display, and any extra information you need to
>display the objects for that particular calendar (colors, icons,
>whatever).
Ok, this is close to what I had, although I didn't yet have CalQuery
duplicated. I'm not going to worry for now about the graphical aspects of
how to distinguish calendars; someone like Damon is probably much
better qualified than I to do that, so I will either pass the buck or
ask them for advice later on. Even without that sort of thing, this
can still be a useful feature. (Imagine loading a list of national
holidays as well as the user's calendar; there's no need to
distinguish them in the view, but the user wants to be able to select
which holidays are included.
>Of course you then need methods to add and remove calendars from a
>view.
This is a view specific thing, with no support in the PCS, right?
>The views need a concept of a "current calendar", which is the
>calendar that the user is currently editing. You may have ten
>calendars displayed on a single view, but when the user creates a new
>appointment, to which calendar do you add it? That is the current
>calendar. Of course, changing existing objects presents no problem
>since you already know their parent calendar.
I'm not sure. I imagine a dynamic set of radio buttons (better, check
boxes, although we'll need to do some sort of duplicate handling when
an event is in two or more included calendars) in the Event Editor to
allow the user to select where to save the event. There needs to be
some sort of default calendar, but I don't think it has to be as
exclusive as you make it out to be. (It can just be a check box
("Set as default") in the Include/Exclude Calendar dialog box.)
>Views keep structures like
>
> struct FooViewEvent {
> /* The component */
> CalComponent *comp;
>
> /* Occurrence times */
> time_t occur_start;
> time_t occur_end;
>
> /* View-specific information */
> GnomeCanvasItem *blah;
> ...
> };
>
>You would need to add a field to point to the CalClient to which the
>object belongs, or perhaps the LoadedCalendar structure above.
Ok. My two initial thoughts had been to add a CalClient* to CalComponent
(bad) or add a GHashTable (CalComponent*/uid ---> CalClient*) to the
view structure (awkward). If there already has to be a view-specific
event structure, that's probably the best place to put it. (I assume
the task view has something similar, since there's no reason this
can't be generalized to VTODOs).
>When you need to paint the objects, you color-code them or whatever.
>I guess you would present the user with a color picker in the "add
>calendar to views" dialog. Or something. Display icons, whatever.
Agreed, although as I said above, this is a second-stage issue for me.
>You need to give the user a way of picking the "current calendar" as
>explained above. Instead of showing a list of URIs we should allow
>the user to name the calendars so that you get a list with
>
> My personal calendar
> Company calendar
> Concert calendar from www.yourlocalsymphonyorchestra.org
> Movie schedule from www.cinemex.com.mx
Names should at least be an option; URI's are a second-best fallback.
Naming them, however, requires a centralized database of some sort...
(Unless you use them only to select among already loaded calendars,
rather than allowing the user to Include/Exclude them based on their
name.) Maybe an XML file stored in ~/evolution or a system-wide dir?
>I don't know if you want to specify a different search query for each
>one of the loaded calendars. It may make the interface simpler if you
>only allow the same query to be applied to all calendars; but then it
>doesn't make sense to filter for the "meetings" category, related to
>your business/company calendar, when you also have the Movies calendar
>loaded... take your pick.
Backend wise, there should definitely be separate queries. Whether
the UI should permit separate queries is probably view-specific.
>So, it is not very hard to do. You just keep a list of open calendars
>in the views and associate the calendar components with the CalClient
>to which they belong. All the rest is miscellaneous support code for
>the user interface. The PCS needs exactly zero changes; it is all
>client-side stuff.
I'm glad to see that my initial guesses weren't too far off.... The
naming feature may end up needing some PCS support if we store the
names in the iCalendar file, rather than a separate XML (or other)
file. Eek, we need to i18n the calendar names. :)
>> [1] Ok, it's mostly aspirational. I am determined to have my
>> contribution to Evolution 1.0 *not* be a patch removing my name from
>> the About box. Hence this message... :)
>
>Dude, you did massive amounts of cool work for Gnomecal, and then it
>became the Evolution calendar. If you remove yourself I will slap you
>with a curried trout and add you again :)
I'm not sure if I think the snooze button required a massive amount
of cool work, but it's certainly the most useful feature I added to
the calendar. :)
-Russell
--
Russell Steinthal Columbia Law School, Class of 2002
<[EMAIL PROTECTED]> Columbia College, Class of 1999
<[EMAIL PROTECTED]> UNIX System Administrator, nj.org
_______________________________________________
evolution-hackers maillist - [EMAIL PROTECTED]
http://lists.helixcode.com/mailman/listinfo/evolution-hackers
