Plasma Calendar data engine & widget future plans

[Aaron J. Seigo]

On January 29, 2010, John Layt wrote:
> On Friday 29 January 2010 19:46:38 Aaron J. Seigo wrote:
> > On January 29, 2010, John Layt wrote:
> > > * Support multiple holidays on each day
> > 
> > i think we already do internally, but we don't visually display "this day
> > has more than one holiday"
> 
> The data engine does read and return multiple holidays, but the calendar
> widget only uses a QHash to store them so no duplicates there. It's easily
> fixed by making it a QMultiHash and retrieving all keys.

yes, that would be sensible.
 
> > > * Tool-tip on hover over day showing any holidays
> > 
> > right now that's done with a click. it certainly has its draw backs, and
> > a tooltip sounds like it might work, my only concern is covering the
> > rest of the calendar which could be annoying.
> 
> I'm not a big fan of the current expander, especially how it flickers and
> jumps, not smooth at all, but it does have the advantage of leaving the
> entire month visible while having lots of room for a list of events.  The
> tool-tip could get in the way a lot and be a bit cramped.

cramped isn't a problem, we are experts a making big tooltips in plasma ;) but 
getting in the way could be an issue. 

but yes, it seems we are in agreement that the current solution is ok, but not 
great.

the biggest probems to me are the jumping and flickering which you also 
mention (which means we need to improve extenders more, rather than use that 
as a reason to avoid them by itself :) and it also takes clicking on the day 
which isn't as convenient or as obvious as something that appears as you mouse 
over.

something to chew on while you work further on the backend stuff.

> > i think the kde pim people likely have more experience in these matters
> > than we do, and so it would be good to bring them into the discussion
> > early on as well. best would be if the plasma calendar and what we see in
> > korganizer harmonizes visually.
> > 
> > i think the plasma calendar should remain simple and provide more of an
> > overview than korganizer does, but they should "work together" visually
> > as well as functionally imo.
> 
> Agreed.  I think the pim guys are working on KOrganizer this release cycle,
> so it will be a good time to co-ordinate.  Their current Month Table

ah, perfect :)

> > > * Do we provide users the option of choosing the highlight method for
> > > each holiday type, or not to highlight some types?
> > 
> > if we do, this should be desktop-wide imho.
> 
> Yes, I was thinking that, but I want to try it out at an app level first to
> see if it is practical before moving it to desktop level.

makes sense; as long as we don't accidentally put it in all the apps and end 
up needing to later reunify everything. but i know you're better than that and 
so i shouldn't worry :)

> > we really want to be able to show, simultaneously:
> > 
> > * this day has holidays
> > * this day has appointments
> > * this day is a non-working day
> 
> That's a very clear summary of it, simple really :-)
> 
> Based on most common usage I've seen perhaps:
>   Appointment = Bold day number
>   Non-working = Darker shaded background (includes weekends)
>   Holiday = halo with colour possibly varying based on type
> 
> The bold day number is almost universal (KOrg, Google, Gnome, Evolution,
> Orage, Sunbird), and shading is fairly common for weekends.

i think we have a winner then :) 

i do like the corner being colored to show an appointment booking, as you 
mentioned S60 does. Blackberry does the same. that may be a limitation of the 
low color counts and resolutions they deal with, however. not to mention 
_crappy_ text/font quality.

> > this sounds like a job for visual design: how to communicate three piece
> > of boolean information in a small space using color and shape only.
> 
> What we need is Edward Tufte :-)

lol

> Any increase in the detail in each day cell would probably mean removing
> the graduated fill to keep things looking clean.

very true; busy bars is probably better indeed.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks