Changes have been made in Git for this ticket:

Set colors per calendar (Request #7480).

http://git.horde.org/diff.php/kronolith/calendars/edit.php?rt=horde-git&r1=2a9fa482e924aafca455684f8650ac5ced81f561&r2=76dd70cd9a6308e670b8ce183a25b0fcadfd1621
http://git.horde.org/diff.php/kronolith/docs/CHANGES?rt=horde-git&r1=c20cf5a369f077635620af3b574efa76182db051&r2=76dd70cd9a6308e670b8ce183a25b0fcadfd1621
http://git.horde.org/diff.php/kronolith/lib/Driver.php?rt=horde-git&r1=b282b337c5c6958989b5fc9d8641162ce797782d&r2=76dd70cd9a6308e670b8ce183a25b0fcadfd1621
http://git.horde.org/diff.php/kronolith/lib/Forms/CreateCalendar.php?rt=horde-git&r1=16c24dd261e086bbdcd5df204d5f4210988b56c8&r2=76dd70cd9a6308e670b8ce183a25b0fcadfd1621
http://git.horde.org/diff.php/kronolith/lib/Forms/EditCalendar.php?rt=horde-git&r1=16c24dd261e086bbdcd5df204d5f4210988b56c8&r2=76dd70cd9a6308e670b8ce183a25b0fcadfd1621
http://git.horde.org/diff.php/kronolith/lib/Kronolith.php?rt=horde-git&r1=93c3b6b8d43a050fa41490b269b76523a83e10fe&r2=76dd70cd9a6308e670b8ce183a25b0fcadfd1621
http://git.horde.org/diff.php/kronolith/lib/Views/Day.php?rt=horde-git&r1=9910e685f9ac27e8205ecd78230c60ea0c58c4e8&r2=76dd70cd9a6308e670b8ce183a25b0fcadfd1621
http://git.horde.org/diff.php/kronolith/lib/Views/Month.php?rt=horde-git&r1=4d8569d6454f4f4995bcb84e2efb448ca58e4b3b&r2=76dd70cd9a6308e670b8ce183a25b0fcadfd1621
http://git.horde.org/diff.php/kronolith/lib/Views/Week.php?rt=horde-git&r1=4d8569d6454f4f4995bcb84e2efb448ca58e4b3b&r2=76dd70cd9a6308e670b8ce183a25b0fcadfd1621
http://git.horde.org/diff.php/kronolith/templates/panel.inc?rt=horde-git&r1=b0938c87208341f48fab9bb233003f735483a113&r2=76dd70cd9a6308e670b8ce183a25b0fcadfd1621

Screenshot of the patched horde

Because my organisation quickly needs colors per calendar, I used the 
ideas mentionned here to create a patch for horde webmail edition 
1.2.4 to display colors in the Sunbird way. It will maybe interest 
some people so I share it here. For now, the colors are generated from 
the name of calendars owners but we plan to make them customizable. 
Here is a patch wich also include fix for the bug 
http://bugs.horde.org/ticket/8716
Screenshot in the next comment

This has been implemented in Git.

The main issue here is that categories are turning into tags - which 
are essentially the same. The difference will be that calendars will 
be able to be tagged with multiple tags, and so can the events the 
calendar contains. The problem with keeping a per-tag-color 
implementation is how to handle the coloring when an event is tagged 
multiple times....and how to handle when a calendar and the event are 
both tagged, which color should take precedence etc...  To sum it up, 
events can have multiple tags, but only ever one calendar - so it 
makes sense IMO, to color per calendar.



If you have any ideas as to how to represent multiple tags with colors 
without the calendar looking like my 5 year old's crayon box, feel 
free to share :)





I *do* think the point you bring up with having your categories 
pre-configured is a good one - I'm sure there are many people using it 
in this way, not sure yet how to go about satisfying that use-case 
with tags...

Don't remove colors by category, keep colors by calendar optional as 
suggested by Jan in comment #6.



Our use case for Kronolith is a small office with multiple calendars 
for ppl. taking appointments. We have 5 - 6 categories for the 
different appointments so it's easy to see if we can take more than 
one appointment for a person at the same time (depending on category) 
or if e.g. the person is out of the office.



Guess this is a many categories vs. many shared calendars thing.



Maybe it's better to create an option to display the calendar name 
below an event like it's done for a location. Or for the category - 
which would be a good enhancement of the print version. Color printers 
are rare, most ppl. use black & white for printing and you can't 
distinguish the categories on the print out.



Our categories are centralized in the config file and locked. If a 
there's still an easy way to provide the same categories for all 
calendars in the config, then i guess i'm ok with this.

Also, whatever model we settle on here should, in my opinion, also be 
applied to Nag and Mnemo. Turba is as usual its own kettle of bats.

We might be able to head off some of the bad reaction to this if we 
could create a reasonable implementation of "sub calendars". I'm not 
suggesting any nesting other than a single parent/child relationship. 
But by allowing a user to group a few different calendars (which would 
be available as separate ics/webdav items) under a single Share - 
i.e., all getting the same permissions; allowing users to subscribe to 
calendar "bundles" all in one instead of dealing with however many 
calendars I have; and by letting users choose colors for each 
sub-calendar, we might retain some of the best of both worlds here.



If you look at a program like iCal, you are basically encouraged to 
create multiple calendars to do any colorization or category-like 
differentiation. We could do the same thing, but simplify the calendar 
creation process a bit and the share overhead by nesting the 
sub-calendars.

adjusting the ticket summary accordingly

I'm convinced now that category/tag coloring doesn't make sense anymore.

It appears that Sunbird only displays a color for the first category.   
All categories are maintained in the ics file, but oddly only the last 
category shows up in the edit event dialog, which only supports one 
category per event.

Elliot - any idea what Sunbird does with multiple categories or tags?

My instinct is the same as Michael's. We're going to be allowing 
multiple tags, or multiple categories, soon; events will never have 
more than one calendar. So calendar seems like a better thing to 
visually differentiate on.

FWIW, I think that since we are moving to a tag paradigm here instead 
of categories - which means we can have multiple tags per event, as 
well as mulitple tags on the calendar the event belongs to, it will be 
a better idea to just move to per-calendar coloring instead of having 
to deal with how to color an event based on tags. Would avoid issues 
such as what color gets applied when multiple tags are present on an 
event - does the calendar tag get applied if the event has no tag etc...

They just want colors per calendar, so I was thinking of adding that 
configuration switch to either enable colors per calendar, or per 
category.

Here's Sunbird's solution.  The blue is the calendar and red 
represents the category.  This could be easily duplicated with a 
border-right: 5px solid red; If the events weren't rounded.  It looks 
a bit funny when they are.

I thought I remembered that, but didn't see it on the task list. Any 
specs on how they want it to work specifically?

That's also part of the ajax rewrite, fwiw.

We do need this option eventually. I am opposed to having colors for 
_both_ categories and calendars, since right now I don't see a good 
way to visually present that. If someone can come up with a clear way 
to do it, then I'm open to it.



Assuming that we also allow for multiple categories for calendar 
events (or tags - same concept really), then it may make sense to 
switch entirely from color by categories to color by calendar, since 
multiple categories would present the same visual problems - how to 
represent multiple colors for a single event without the calendar 
turning into a tie-dye shirt.



At the least, I think we should have an administrative option so the 
sysadmin can set an install to be colored by either categories or 
calendars.

The current implementation of calendar coloring only takes into 
account the category of an event.  All Business events, for example, 
might be red while all Pleasure events might be blue.  This is a great 
feature, but is lacking in a shared calendar environment where one 
might be displaying a dozen calendars on the same page all containing 
events on the same day, some of which might even be of the same 
category.  Currently, the only way to determine if something is on one 
calendar as opposed to another is to disable and re-enable calendars 
until the event disappears and re-appears.

One can mouse over the event to find the owner, which is helpful, but 
even clicking on the event doesn't tell you what calendar it belongs to.



I'd like to request that we start working toward a system similar to 
how categories are colorized but that enables colorization by calendar 
if requested.  Perhaps the calendar can be denoted by the border color 
rather than the background (though it seems the opposite might be more 
appropriate in my opinion.)  Either way here's an initial patch that 
simply adds a hash of the calendar name to the class on a given event 
so that administrators if they wish could add colorization to a css 
file as a stop-gap fix until something more robust can be developed.