Re: [Evolution-hackers] functional specification for list view

[Ettore Perazzoli <ettore ximian com>]

On Wed, 2003-09-10 at 18:41, Tim Lee wrote:
> On Wed, 2003-09-10 at 16:33, Ettore Perazzoli wrote:
> > Hmm, that's an interesting idea...  However we are already showing the
> > tasks in the same view, on the right of the calendar, so it sounds like
> > it might be a bit too much.
> > 
> Would we be keeping the side calendar and task list in this view? I'm
> not sure that the side calendar would serve much purpose. The three main
> functions of the side calendar that I'm aware of don't seem very
> applicable to a list view:

I am not sure how the layout would change then...  We don't want the
screen to look radically different when you do a search, do we?  Because
of the way things are laid out, hiding the side calendars will also mean
hiding the to-do list, which would probably be annoying.

> 1. Navigate to a date in the day view. 
> - I'm not sure what would this mean in a list view, especially if you
> had the list sorted by something other than date. Highlight events
> occurring on that date?

Yeah that's why I was thinking that changing date in the day view would
just switch to the calendar view?..

> 2. Select dates to display in multi-day view. 
> - To implement this for the list view it seems to me that the result
> would be similar to my suggestion to filter events by the dates they
> occur on.

Same, you click on multiple dates, and it switches to week or month
view.

> With a six column, and potentially 10+ column, view I'm not sure the
> side calendars are worth the loss of screen real estate. Though I
> suppose you could always resize the list panel to obscure the side
> calendars. An other consideration, would leaving off the side calendars
> simplify the implementation?

I don't think it would make much of a difference.  The state of the
selection in the calendars is already bound to the view type (e.g. if
you select a week, it switches to week view), so I guess we can just
bring that association forward and have the list view in place only if
when no date(s) are selected on the calendars and vice versa.

> > > I agree that grouping would make this view much more useful. I think a
> > > list does not lend itself to showing time relationships well. Being able
> > > to group events by the day, week or month they occur in would help.
> >
> > That sounds a bit complicated to implement...  I think we can leave this
> > to after 2.0, although it does sound like a good idea.
> > 
> Too bad, why would it be so hard? We already have the "By Company" view
> in the address book. 

Grouping in ETable happens automatically as long as its string-based,
but doing grouping by day/date/month would require writing new models
for it.  Possibly a sizable chunk of work...

> > This I don't know, what does Outlook do?
> I don't know, does Outlook have a list view for calendars? Outlook 2002
> treats them just the same as Evolution, displays them in a header above
> the times in the day view.

I don't know if it does, we should check.  :)

> > Yes, the "new" button would still work normally.  Although, I don't
> > think we can have a "click here to add" interface since this is supposed
> > to be a read-only list...
> Have we decided how we are going to handle new events when the view has
> multiple calendars displayed? Will the event just always go into the
> default calendar?

There is not going to be a "default" calendar anymore.

The list on the left will have two kinds of selection: a "primary" one,
which means the calendar that has the standard background highlight, and
a "multiple" selection, i.e. the checkboxes.

The "multiple" selection specifies which calendars are displayed; the
primary selection will specify where a newly created event goes.

We also need to add an option menu to the calendar editing window, so
you can change the default value, and you can move an event from one
calendar to another.

> > I don't know, this might need further UI work...  I think we should keep
> > it simple for now though.
> > 
> That's too bad I think the real strength of a calendar list view would
> the ability to manipulate the view of one's events in ways that the
> day/week/etc. paradigm doesn't really allow.

Yeah, I am aware of that.  :)  But we can't do everything at the same
time...  Let's get the basics done first.

> see my notes above. I'm not sure that changing the view is the behavior
> that I would expect when selecting a date in the side calendars. Also we
> already have buttons in the tool bar to change views.

It already does that though.  If you select a range of dates in the
mini-calendars, it changes the view type.

> Speaking of which I think if an event is selected in the list view when
> one of the view button in the tool bar is pressed, then I think the view
> should open to the day/week/etc. that contains that appointment. 

Yeah, that's actually what I meant when I said that we need to specify
the transitions between the different states.

> Not sure how Evolution should behave if multiple events are selected in
> this case. Which brings up an other point, will we allow multiple events
> to be selected in the list view? The current calendar views do not allow
> multiple events to be selected as far as I can tell. 

Good question; I think we should be able to select multiple events for
the purpose of deletion and cut / copy / paste.  In the list view this
basically comes for free (since ETable does all the work).

-- Ettore