confirming.

hmm...., may be we need a menu item to do this.
This will require a UI break.
any ideas of doing this without breaking any freezes.
Marking as enhancement.

devashish, can you explain to me why a missing menu option which makes me unable to have an obvious way to edit categories is now an "enhancement" instead of a bug?
yes, this would be a ui break. but there's a life after ui freeze named "2.7". ;-)

Andre, that is what I meant, i was just saying is there any way we could do this for the current release, otherwise it has to be done in the next one (2.7).
It would have been better if this could have been done this cycle only.

Now that we have it... Target Milestone 2.7.

*** Bug 446774 has been marked as a duplicate of this bug. ***

Bumping version to a stable release.

Created attachment 186660 [details] [review]
Patch

This patch adds Edit->Categories item to addressbook menu. The OK/Cancel buttons are removed and replaced by single "Close" button, which is always sensitive and makes more sense in this context.
The "Currently used categories" entry should probably be hidden too as it is useless in this context, but it requires some changes in the dialog itself in the EDS. If you are OK with this, I'd add something like e_categories_hide_currently_used_entry() method that would make the entry disappear. Another thing is that the checkboxes in the categories list are useless too, but that would probably require a bigger changes in the dialog and I think people can get on well with the checkboxes :)

Having the string "_Categories" already translatable under ../calendar/gui/dialogs/comp-editor.c:1137 , is the mnemonic position "Ca_tegories" in your patch required (e.g. for not colliding with a _Cancel button?)

Review of attachment 186660 [details] [review]:

I like the idea, but I think it should be available globally (in evolution-shell.ui) since it's not specific to the Contacts view.  Change the menu text to say "Available Categories" so it's clear you're not just editing categories on whatever item is being shown in the preview pane.  Also, when running a dialog this way it's better to just call gtk_dialog_run() rather than hooking up a "response" callback.

Also, we should split off the tree view in ECategoriesDialog into a separate widget (ECategoriesSelector?) in libedataserverui, with an option to show or hide the checkboxes next to the category name (we'll want to hide them for this use case).  I don't think the entry box at top of ECategoriesDialog is appropriate for this use case, and it would save you from having to hack the dialog buttons like that.

Created attachment 186770 [details] [review]
EDS patch: break ECategoriesDialog to pieces

This EDS patch breaks ECategoriesDialog to few smaller pieces:

ECategoriesSelector: a GtkTreeView for displaying categories. Visibility of column with checkboxes can be set by _items_checkable.

ECategoriesEditor: widget with ECategoriesSelector, a GtkEntry for displaying displaying checked categories and Add/Edit/Remove buttons. Visibility of the GtkEntry can be changed by _entry_visible (hiding the entry also hides the checkboxes in ECategoriesSelector).

ECategoryEditor: dialog for editing single category which appears when you click Add/Edit button in ECategoriesEditor. The class handles adding/editing categories to ECategories.

ECategoriesDialog: looks like the old ECategoriesEditor, but contains only ECategoriesEditor and OK/Cancel button.

I hope I didn't break it to too many parts, this is more object-oriented design then is probably usual, but I think it's clearer this way.

Created attachment 186771 [details] [review]
Evo patch to insert Available Categories item to main menu

This patch creates Edit -> Available Categories in evolution-shell. The callback creates it's own GtkDialog with ECategoriesEditor and single Close button.

(In reply to comment #11)
> I hope I didn't break it to too many parts, this is more object-oriented design
> then is probably usual, but I think it's clearer this way.

I much prefer building composite widgets from simpler widgets, instead of packing in all into one complex beast.  Cleaner and easier to maintain.  So I like what you did.  Give me a day or so to look it over.

I know I told you to move the item to evolution-shell.ui, but I'm wondering now if it should be hidden from the mail view since it doesn't really apply there.  The action itself definitely belongs in e-shell-window-actions.c, but the <menuitem> tag could be moved to multiple .ui files.

Don't worry about revising the Evo patch yet -- I'm just thinking aloud.  What do you think?

Created attachment 186858 [details] [review]
Evo patch - insert the menu item to all views but mail view.

(In reply to comment #13)
> I know I told you to move the item to evolution-shell.ui, but I'm wondering now
> if it should be hidden from the mail view since it doesn't really apply there. 
> The action itself definitely belongs in e-shell-window-actions.c, but the
> <menuitem> tag could be moved to multiple .ui files.

Yep, you're right. I didn't check if there are any categories in the mail view and blindly put the menu item everywhere. The attached patch inserts the menu item to all views but the mail view. I added a new placeholder to the evolution-shell.ui to ensure that the 'Available categories' item will be always above Plugins and Preferences items. Users are used to these two items being stick together and I don't want to break this by inserting a new item between them.

Anyway, pick whichever patch you like more :))

Nicely done.  I made a few tweaks to the patches -- mostly silly cosmetic stuff -- and updated Gtk-Doc stuff for the new APIs.  Otherwise committed the patches for 3.1.1 as written.

http://git.gnome.org/browse/evolution-data-server/commit/?id=11044cd0ebb4fff492a207750050111d895d3bce

http://git.gnome.org/browse/evolution/commit/?id=8195647e9b92dc3928a66893e8ac1fba88019b66