[dev] Kronolith category/color patch, per user

[Kevin Myer]

This message is in MIME format.

--=_mu6zlqpk6nk
Content-Type: text/plain;
	charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Attached, please find my second attempt to provide a solution to what is in my
opinion, a major usability issue with Kronolith as it currently exists - namely
that the display of colors and categories only is shown for the primary user
and does not take into account other users' colors and categories.  In an
environment where you share calendars with multiple individuals, or where you
have organization wide calendars, this quickly becomes very unwieldy.

Initial discussion about this issue is documented at:

http://marc.theaimsgroup.com/?l=horde&m=110329986927737&w=2

My first attempt at a patch, which was rejected, because the current display
behavior change was intentional (I still don't know why) is at:

http://bugs.horde.org/ticket/?id=1414

What these patches do:
1) Modify two CategoryManager function calls (color and fgcolor) to accept an
optional userid, so that colors for other users can be looked up
2) Modify the Kronolith getLink function, to accept optional fgcolor and owner
variables, so the link color is properly created, based on the category color
3) Implement caching of user colors in the Horde Cache system (maybe
unnecessary in some environments but performance was really bad in our setup,
because each color lookup was generating two (very slow) hook calls to our LDAP
server, to retrieve fullname and email address for a user, and our LDAP server
is in bad need of upgrade, for performance reasons..the caching lets me
function for a little while longer with the current LDAP setup)
4) Replace all color lookups in day, week, month, and portal block views, with
logic that:
 a) uses the list of currently displayed calendars to
 b) obtain a list of all the unique calendar owners so that
 c) an associative array of categories and colors can be built for each owner
(dynamically - only categories that are displayed show up in the legend)
5)  Add to the category legend a listing of each user's colors and categories
(dynamically created, again, based on which events are shown)

If this patch is accepted, I would think much of the above logic can actually be
rolled into a single function call, that takes as an argument the calendars and
returns an associative array of owners, colors, and categories.


What these patches do not do:
This is not an attempt to provide management of other users' colors or
categories.  I see little need for that.  I also don't know if/how to handle
display of events on remote calendars that may have categories, or if that even
needs to be considered.

It is an attempt to make shared calendars more usable.  Since a picture is
worth a thousand words, I've put up a couple thousand of them up for
comparison, to give you a feel for the difficulties encountered when using
Kronolith in its current state and Kronolith with my patch.

http://www.iu13.org/~myer/kron-portal.png shows the portal view.
CURRENT:
It is impossible to tell whose events are whose.  Is that my Vacation day in the
first block?  Tomorrow?
PATCHED:
Ah, its not mine (I list my vacation days in my Business category, which is red,
it's Brian's vacation day and he lists his in a Vacation category, which is
purple)

http://www.iu13.org/~myer/kron-month.png

CURRENT:
Same issue as above - whose vacation days are on April 6 and 7?  And how do you
distinguish between the ones on April 14,15, and 18?  Note how the categories
that aren't mine show up in my category list in the legend, but are white...
PATCHED:
Easy to see whose vacation day is whose.  Easy to see that about half the events
aren't even mine :)

A suggestion was made to use side-by-side mode to see the categories, but thats
just impractical in month view, and cumbersome to view if you have more than a
few calendars you subscribe to.  And it does nothing for portal blocks..

These patches (or slightly sloppier formatted ones, without the Caching, which I
added this morning) have been in production use since mid February, with no ill
effects.

This display enhancement (at least the concept) could also be ported to Nag and
Mnemo, although I haven't looked to see how similar the code is there to see
how portable it is.

Kevin

-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org
(717) 560-6140
--=_mu6zlqpk6nk
Content-Disposition: attachment;
	filename="kronolith-category-color.patch"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

A non-text attachment was scrubbed...
Name: kronolith-category-color.patch
Type: text/x-patch
Size: 27369 bytes
Desc: not available
Url : http://lists.horde.org/archives/dev/attachments/20050421/fda28a5b/kronolith-category-color-0001.bin

--=_mu6zlqpk6nk
Content-Disposition: attachment;
	filename="horde-category-color.patch"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

A non-text attachment was scrubbed...
Name: horde-category-color.patch
Type: text/x-patch
Size: 4061 bytes
Desc: not available
Url : http://lists.horde.org/archives/dev/attachments/20050421/fda28a5b/horde-category-color-0001.bin

--=_mu6zlqpk6nk--