6.0.0-git
2019-04-21

[#7480] Switch to colors by calendar instead of colors by category
Summary Switch to colors by calendar instead of colors by category
Queue Kronolith
Queue Version HEAD
Type Enhancement
State Resolved
Priority 1. Low
Owners jan (at) horde (dot) org
Requester elliot (at) marlboro (dot) edu
Created 2008-10-12 (3843 days ago)
Due
Updated 2010-01-12 (3386 days ago)
Assigned
Resolved 2009-02-03 (3729 days ago)
Milestone
Patch No

History
2010-01-12 23:58:33 CVS Commit Comment #20 Reply to this comment
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
2009-11-19 23:26:44 arnaud (dot) didry (at) univ-avignon (dot) fr Comment #19
New Attachment: Capture.png Download
Reply to this comment
Screenshot of the patched horde
2009-11-19 23:25:39 arnaud (dot) didry (at) univ-avignon (dot) fr Comment #18
New Attachment: uapv_agendaColors.patch Download
Reply to this comment
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
2009-02-03 18:56:24 Jan Schneider Comment #17
Assigned to Jan Schneider
State ⇒ Resolved
Reply to this comment
This has been implemented in Git.
2009-02-03 14:25:14 Michael Rubinsky Comment #16 Reply to this comment
Don't remove colors by category, keep colors by calendar optional as
suggested by Jan in comment #6.
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...
2009-02-03 07:56:23 hordelist (at) quantentunnel (dot) de Comment #15 Reply to this comment
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.
2008-10-13 02:28:52 Chuck Hagenbuch Comment #14 Reply to this comment
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.
2008-10-13 02:28:24 Chuck Hagenbuch Comment #13 Reply to this comment
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.
2008-10-13 01:53:18 Chuck Hagenbuch Comment #12
Summary ⇒ Switch to colors by calendar instead of colors by category
Patch ⇒ No
Reply to this comment
adjusting the ticket summary accordingly
2008-10-12 23:46:57 Jan Schneider Comment #11 Reply to this comment
I'm convinced now that category/tag coloring doesn't make sense anymore.
2008-10-12 18:40:18 elliot (at) marlboro (dot) edu Comment #10 Reply to this comment
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.
2008-10-12 17:47:12 Chuck Hagenbuch Comment #9 Reply to this comment
Elliot - any idea what Sunbird does with multiple categories or tags?
2008-10-12 17:46:11 Chuck Hagenbuch Comment #8 Reply to this comment
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.
2008-10-12 17:44:08 Michael Rubinsky Comment #7 Reply to this comment
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...
2008-10-12 17:32:56 Jan Schneider Comment #6 Reply to this comment
I thought I remembered that, but didn't see it on the task list. Any
specs on how they want it to work specifically?
They just want colors per calendar, so I was thinking of adding that 
configuration switch to either enable colors per calendar, or per 
category.
2008-10-12 17:05:39 elliot (at) marlboro (dot) edu Comment #5
New Attachment: combined-colorization.jpg Download
Reply to this comment
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.
2008-10-12 16:18:05 Chuck Hagenbuch Comment #4 Reply to this comment
I thought I remembered that, but didn't see it on the task list. Any 
specs on how they want it to work specifically?
2008-10-12 16:14:57 Jan Schneider Comment #3 Reply to this comment
That's also part of the ajax rewrite, fwiw.
2008-10-12 15:59:10 Chuck Hagenbuch Summary ⇒ Allow colors by calendar as well as/instead of by category
 
2008-10-12 15:57:31 Chuck Hagenbuch Comment #2
State ⇒ Accepted
Version ⇒ HEAD
Reply to this comment
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.
2008-10-12 13:10:00 elliot (at) marlboro (dot) edu Comment #1
Type ⇒ Enhancement
State ⇒ New
Priority ⇒ 1. Low
Summary ⇒ Add colors to calendars on a per calendar state in addition to per category
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ Yes
New Attachment: Views.patch Download
Reply to this comment
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.






Saved Queries