The Kronolith part of this is already done. I'm really not sure what 
state the mnemo patches are in, but they need to be in a seperate, 
clean ticket for Mnemo.

I agree with Jan. You need to read horde/docs/CODING_STANDARDS, 
though, and get rid of tabs, fix some whitespace issues, etc.

I prefer the first candidate, not only because of the missing optgroup 
feature, but also because of the missing 'option class="selected"' 
feature and the addition Horde_Form overhead which isn't necessary here.

This is the second of two candidate patches moving the select logic to 
the Mnemo class.



This one uses HORDE_FORM and Renderer framework classes to render a 
form element.  This method DOES NOT allow the use of the optgroup 
functionality, but does support the separation of presentation and 
logic recommendations.



This candidate will require additional work as the onchange action 
seems to throw an exception.  I will take the next few steps down this 
path is it seems profitable.  Does anyone have any comments on either 
of the two directions?  Is it permissible to render the select element 
without the form wrapper?

Here are a couple candidate patches moving the select logic to the 
Mnemo class.



This one uses in-line HTML to return a string representation of the 
select element.  This method allows the use of the optgroup 
functionality, but is in conflict with the separation of presentation 
and logic recommendations.



This implementation is full-feature replacement for the earlier patch.

No, there isn't, you need to duplicate code again.

Sounds good.  I was looking at the Horde_Form class.  Do you know if 
it is possible to specify the optgroup from the enum type in any of 
the renderers?

Looks good. Though looking at the mess in menu.inc (which you copied 
from Kronolith, it's not your fault), we should probably move the 
widget generation to Mnemo::/Kronolith:: methods. This should result 
in much cleaner code. At least for the option tags.

I have refactered the last patch to remove redundant creation of the 
my_notepads and shared_notepads arrays.  This patch simplifies the 
previous version.



This also eliminates the need to refactor the Mnemo::listNotepads 
method as discussed on the dev list here (#2):

http://lists.horde.org/archives/dev/Week-of-Mon-20060327/019567.html



I believe this pattern is clear and simple enough to implement on the 
other groupware apps.  As always, I am happy to implement other 
suggestions.

The attached patch is a first pass implementation of the Display 
Notepads functionality for Mnemo.  This implements:

1. Option Group select on the menu.inc drop-down list

2. Display Notepads block w/ checkboxes for the My Notepads page

I think it makes sense to have it be shared between all apps.

That would be great, independently from the owner name topic.

I think a global setting makes sense if there is another way for the 
user to determine the element's owner.



The My Calendars -> Display Calendars section has screen room to 
display the owner name next to the calendar name.  So, even if a 
global default was set to hide the owner on the drop-down list, the 
user could still determine the owner through the My Calendars interface.



The other PIM apps do not currently have a "Display {item}" section 
under the corresponding "My {item}" page.  I personally like the 
display checkboxes and think it would be helpful for other apps.  I 
would be willing to take a first pass at adding the Display section to 
the appropriate apps if this makes sense.

Alright, I think this makes sense if we introduce the same preference 
in the other groupware apps. The question is, should we make this a 
shared preference, so that you turn it on and off globally, or should 
it be one preference per application?

I know, admins can change this easily themselves, but I'm talking 
about the default setting.

Hi Jan,



Would you mind taking another look at this patch? I agree with your 
assessment that we can create a username hook to shorten the calendar 
owner. However, our users have asked us for a way to suppress the 
calendar owner altogether and only display the calendar name. The 
patch implements this feature as a user preference. We believe it also 
brings the calendar UI more in line with the other shared applications 
(tasks, memos, etc.).



Thanks in advance for your time. We are happy to discuss further as needed.



Tom Evans

Tachometry

User names are not email addresses by default, only if your 
authentication backend requires this. Also, there are hooks to convert 
user names in the interface, for example to strip the domain part.

When using IMP as the authentication mechanism, the username by 
default is a fully qualified e-mail address.  We have found that a 
long username combined with the calendar name in the calendar select 
list forces the menu to break to a second line on monitors with a low 
resolution setting.



In an effort to reduce the effect of this occurrence, I would like to 
suggest the following patch to add a preference setting; allowing the 
user an option to "not display" the username before the calendar name 
in the shared calendars option group in the calendar select list.



I appreciate any thoughts or comments you may have on this 
enhancement.  The submitted patch:



1. Adds a preference for "show_shared_owner" to the preferences file 
with a default value of 1 to support backwards compatibility (will by 
default show the usernames).



2. Adds the preference checkbox to the bottom position of the "User 
Interface" options.



3. Modifies the menu.inc file to check the value of the 
"show_shared_owner" preference before printing the owner name in the 
select list.



Thank you for your consideration.  I appreciate any feedback or 
suggested modifications.