Version: 3.2 (using KDE 3.2 BRANCH >= 20040204, (testing/unstable)) Compiler: gcc version 3.3.3 20040214 (prerelease) (Debian) OS: Linux (i686) release 2.4.19-pre7-rmap13 When working with categories, sometimes i was missing more category sets .. to achieve more ways of organizing items. So to generalize the concept, user defined categories would allow for defining own set (name+values) (user for column headline). Another way of achieving the same result would be hierarchic categories (where top hierarchy items are equivalent to hierarchy sets). Multiple categories allow for better logical separation of the sets, but may result in more complicated gui.
Hi Peter, I don't understand your wish. Can you please explain it again? Maybe with some examples of what you have in mind. Thanks, Reinhold
I'm not sure I really understand the bug report. As far as I do, it requests the same (or something similar) as bug 72117. Since I haven't got any response from the reporter, I'm closing this report as a duplicate. Cheers, Reinhold *** This bug has been marked as a duplicate of 72117 ***
Oh. I'm sorry i somehow missed your previous comment. This feature is not about organizing todo items but about categories. If you have todos from multiple areas (personal, work, shopping list etc) .. it happens quite often that for one area you use one set of categories and for another area another set of categories. Now i can create one linear set comprising all partial sets, bu t it is sorted alphabetically and uninteresting categories just gets in the way. Another reason is having ability to have more fine grained categories but keeping information about category hierarchy as well. So the proposed solution was either a) fixed 1 level hierarchy - user could add his own category sets (that is .. for each set the set name and the categories for the set) b) unlimited hierarchy for categories This feature is not essential, one can always browse through long linear list and simulate hierarchy .. but that was the idea how to make it more convenient.
Reassigning all KOrganizer bug reports and wishes to the newly created korganizer-devel mailing list.