Version: 3.4.1 (using KDE 3.4.1, Debian Package 4:3.4.1-1 (3.1)) Compiler: gcc version 3.3.6 (Debian 1:3.3.6-5) OS: Linux (i686) release 2.6.11-1-686 I've been using korganizer quite some time now and I don't find the category selection very intuitive, so I thought of a few ways to improve it: 1) Most of my appointments have only one category, it would be possible to replace the 'select categories' button and read only line edit by a few combo boxes. This would remove the need for an extra dialog. 2) Put the categories in a seperate tab to get rid of the extra dialog. But I think most users would prefer to have category selection the first tab. 3) Add category selection to the side bar in the main window. With this users would be able to simply click on an item and modify the categories. 4) Add the list of categories to the popup menu you get when right-clicking on an item, of course in a submenu to avoid clutter. This would allow easy toggleing of categories without big user interface changes and could for example be implemented in a minor update. 5) Or make it easy to select an calendar to put an item in, like iCal does on MacOS X. And make it is easy to move an item to another calendar. I think I would even prefer this feature above the others.
Reassigning all KOrganizer bug reports and wishes to the newly created korganizer-devel mailing list.
> 1) Most of my appointments have only one category, it > would be possible to replace the 'select categories' > button and read only line edit by a few combo > boxes. This would remove the need for an extra dialog. This my work well for those with only one category, but for users who use multiple categories per event this would be bad. I don't think this is a good idea. > 2) Put the categories in a seperate tab to get rid > of the extra dialog. But I think most users would > prefer to have category selection the first tab. What problem does this solve? I see this only adding complexity to the addition of a new event. > 3) Add category selection to the side bar in the > main window. With this users would be able to simply > click on an item and modify the categories. This would be consistent with Digikam's Tags. In fact, as Categories are many-to-many as Digikam tags are, I think that this is a great suggestion. > 4) Add the list of categories to the popup menu you get > when right-clicking on an item, of course in a submenu > to avoid clutter. This would allow easy toggleing of > categories without big user interface changes and could > for example be implemented in a minor update. I do not think that categories are changed often enough to warrent this. Does anybody change the categories of existing events often enough that this would help them? > 5) Or make it easy to select an calendar to put an item > in, like iCal does on MacOS X. And make it is easy to move > an item to another calendar. I think I would even prefer this > feature above the others. Define "easy". How would you like to see this implemented, from a UI perspective? I am not familiar with OS-X so just describe what you would like, without referrencing software that many people here are likely not familiar with.
There is a point. 90% of my events have only one category. I agree with Dotan that proposed way will add a lot of complexity to dialogs. Maybe it is better to do something similar to KMail compose dialog - simply leave the line for typing categories with auto-completing it and separating different categories by , or ; Eg.: Phone call, Job It can be select button and Select categories button if you forget something, or for users who prefer existing way to select categories.
> simply leave the line for typing categories with > auto-completing it and separating different categories by I cannot check at the moment, but I believe that Digikam does this with Tags. Good idea!
Bug 154539 asks for Digikam's Tags and Kaddressbook's Categories to have application consistency as they both serve a many-to-many purpose.
There is still no solution in 4.4 - I like the idea of typing a comma separated list of categories, but it has to have a auto-completion feature else you get a lot of variants of the same category.
If this bug is now reduced to having categories behave like tags for other kde applications it's a duplicate of bug #155598. Bug #170186 is a bit more specific in how this can be achieved but includes the same basic proposal as this one.