I too concur that it would be extremelly useful to see the categories 
from the shared calendar displayed in your calendar view.

This is currently causinfgall manner of grief from for me with users 
complaining about not being able to co-ordinate their calendar views.

perhaps the ultimate solution is to make is a selectale option - 
"display categories shared calendars" wher eyou can choose to either

a) ignore shared categories

b) display shared items with the shared category colours

c) display shared items with your category colours if there is a 
category overlap.

Side-by-side mode is not easy to use in month view, or if you're 
viewing more than a handful of users.  Thanks for the suggestion - we 
will maintain the patch locally, as it is a purely cosmetic patch.   
Our early adopters have commented that display of other users' colors 
is much more useful than assuming all categories are their own and 
displaying only their own colors for all categories.  Apparently, we 
are in a minority here.  I understand the move to global categories 
for all modules but I still don't understand why you would make my 
colors override another user's colors when displaying multiple users' 
shared anything..

You can use the side-by-side view if you want see at one glance which 
events go with which calendar.

You've also intentionally made it impossible to determine whose event 
you're looking at, without clicking on an event to see which calendar 
it's associated with, or without toggling calendars on and off to see 
what makes the event disappear.



Using a simple, but frustrating real-life example for me:



Two users share their calendars with each other.  Each calendar 
contains all the meetings, and vacation days, etc.  for that user.  If 
they both use the same Category name, each user sees all events as 
"theirs" - i.e. they show with their colors.  Let's say we both use a 
Business category.  Mine is red and my staff member's is green.   
There's no way to visually communicate that my vacation day is mine 
and that my staff member's vacation day is theirs.  Because both 
vacation days show up as the same color (red) on my calendar, based on 
my category color choices.  Likewise on my staff member's calendar, 
they're both green.  Throw in a few more staff members and misery 
starts to mount, to the point that Kronolith no longer becomes a 
viable shared calendaring solution.  With my patch, my vacation day is 
red, and my staff member's vacation day is green.



There needs to be a visible way of communicating whose event I'm 
looking at.  Unless I'm missing something, this does not currently 
seem possible and since my idea is apparently not correct, I'm open to 
any additional ways of having event ownership be easily visible.



Maybe a screenshot of the current state of affairs and my patched 
state of affairs would help clarify why this is a problem and how I've 
solved it for myself?

This change was by intention.

Patch to handle original owner's colors and categories for events for 
Kronolith

Patch to Horde Preference Category Manager

One of the features lost in between the Horde/Kronolith ALPHA release 
and the latest officially released versions was the ability to see the 
color of a category, as a user intended it to be, for shared calendar. 
  In the officially released version of Kronolith, only your colors 
and categories are shown.  If another user has shared a calendar with 
you and uses the same categories, your colors show on those 
categories.  If the category names are different, the color goes to 
the default color.  I had posted to the horde mailing list a few 
months back about a way to possibly remedy this, as I think it 
severely limits the useability of any of the shared apps.  After 
muddling along, I think I have a workable patch that provides a proof 
of concept of what I'm after and it doesn't seem to break anything :)



Essentially, what I've done is created a new colors and fgColors 
function in the Pref->CategoryManager class 
(horde-CategoryManager.patch).  These two functions take one argument, 
an owner, and this allows lookup of categories and colors for other 
calendars (and ultimately all shared items).  My thought is that this 
could be further simplified if the existing color and fgColor 
functions were modified such that by default, they looked up the 
current user's categories and colors, but if an argument were 
specified to the function, then they would take that argument to be 
the owner uid to lookup the category and color for.



The second patch takes care of adding the logic to extract the owner 
information about each event, so that colors and categories can then 
be looked up appropriately.  Rather than assume that all colors and 
categories are of the current user, each event has a lookup for the 
category and color.  For each unique owner, and then category, an 
array is built, which is then cycled through when the category legend 
is built.



End result is that at a quick glance of the legend, you can tell which 
events are owned by a user (cued by color).  If an event is owned by 
another user, but has the same category name as one of yours, you can 
still differentiate between them.



Caveats:



I am not a programmer.  This is my best attempt to provide the answer 
to Chuck's proverbial question - "Patch?".  It hasn't broken my system 
that a few of us use as our primary mail and calendar client.  YMMV.



Things I know are flawed:

1)  I made the assumption that the CreatorID for an event == owner of 
the calendar.  However, I later realized that if you give write 
permission to someone else to your calendar, they get set as 
CreatorID.  What I really need to do is get the information back about 
which calendar an event is on and who owns that calendar.  But I'm not 
sure how to do that.

2)  Formatting of the patch is probably not up to the specs provided.   
I can clean it up if the idea is accepted - I want to make sure this 
is a viable option before spending any more time on it though.



If these patches are accepted, I would think that modifying Mnemo and 
Nag to do the same thing would not be too difficult.