Early warning: addition of hierarchical user and built-in categories

[chaley]

A number of changes to the tag browser have been committed to trunk. If you manipulate user categories or tag browser items directly, you might be affected.

Change 1: user categories support sub-categories. If you have a category named A, another named A.B, and another named A.C, B and C will appear as subcategories of A. If you are manipulating the db pref 'user_categories', then you probably don't care about this, because the tree view is rebuilt from that dict. You will definitely care if you want to display the item hierarchy.

Change 2: non-user categories can support hierarchies. For example, assume you have a custom col (text mult) named Genre. If you have the following items in that category:
Cooking.French.Classic
Cooking.French.Nouvelle
Mystery.English
Mystery.Thriller
they will display as a tree. The outermost level will contain Cooking and Mystery. Cooking will contain 1 expandable category, French, which contains two leaf nodes.

Hierarchical processing is enabled for individual categories in preferences.look & feel.

You probably will care about this change only if your plugin (or what-have-you) wants to manipulate these items in a similar way. If not, then you can continue to use the full values (as in A.B.C) and the tag browser will deal with displaying the trees.

[chaley]

I forgot to mention: db2.get_metadata returns a new attribute: user_categories. It is a dict of lists, containing {user_category:[items]} for items in the category that the book contains.

[chaley]

I changed the names of some tag_browser APIs to be consistent with the slew of new APIs added to support creation, deletion, and renaming of user categories.

In addition, renaming of category items will now automatically rename the items within the user category, which may simplify some things.