Notification area should be more configurable

[Izidor Matušov]

It would be great to see those options:

  * the count of showed tasks (show 10, 15 or 20 bugs)
  * show only tasks with a certain tag like '@action-today'

[Roquentin (antonio-roquentin-deactivatedaccount)]

This will also partly address bug #591920.

[Izidor Matušov (izidor)]

Antonio, you might be interested to use Tag Completion ( GTG/gtk/tag_completion.py ) used in GTG/gtk/browser/modifytags_dialog.py for limiting tags.

[Roquentin (antonio-roquentin-deactivatedaccount)]

Izidor: thank you for the pointer, it's what I needed.

[Roquentin (antonio-roquentin-deactivatedaccount)]

OK, I think the branch is in decent shape now. I decided to keep "regular" filters ("workview", "active", etc.), separate from tag-based filters (@idea, @project). My reasoning was that one may want to select multiple tags at a time, but there should be always only one global, regular filter at a time. I know multiple filters can be applied, but it seems to me that this way it is also easier to explain the various options in the preferences.

There is one issue. I can get tags completion to work only by "stealing" the instance from the modifytags dialog. I know this is bad... but using a local TagsCompletion object does not work.

I am not too familiar with this feature so if anyone could have a look at it, that would help. The problem is here http://bazaar.launchpad.net/~antonio-roquentin/gtg/bugfix-945553/view/head:/GTG/plugins/notification_area/notification_area.py#L428

Another thing: for the moment all available filters are exposed. I think it would be better to limit the choice to a few ones (for instance workview, workdue, active). Any suggestion?

[Izidor Matušov (izidor)]

Hi Antonio,

the problem you tackle is a typical probelm when you design GUI. There are many possible use cases what to do. To capture them all, you need to create a complex UI. (Un)fortunatelly, 99% people (figurative number) will use very limited subset of those features. GTG developers attempt to think about it and design UI according to that.

Write down typical use cases for notification area plugin. If it is hard, imagine a person or two with realistic details, e.g. Peter is super geek which wants to have every aspect of his life under control and complete every task within short time. He wants to access most relevant tasks for this day without finding GTG main window. He tag all tasks for today with a tag @action-today.

Afterwards look at your questions and answer them for each person/use case. From my point of view, notification area should show a small amount of tasks relevant to the current day and which I can work on. I won't allow any abstract tag as "active" or "workview", but always apply workview filter. I would allow user to choose one tag or one smart tag to filter tasks. If he wants to have a more specific selection, he can create a new tag or create a smart tag.

If you use get_used_tags() from requester, you will have the exact same liblarch tree that TagCompletion uses. You might need to implement get_smart_tags() yourself in requester.

Keep good work!

Izidor

[Roquentin (antonio-roquentin-deactivatedaccount)]

I did the exercice :-) it was useful but I think one can always tweak/ignore use cases to fit a pre-existing design - I swear I did not ;-)

I agree that only workview and one tag should suffice in most cases. I will leave the support for multiple tags just because it was explicitly mentioned in another report. Actually, one of the use cases gave me an idea how to make the notification area more helpful: more on this later.

Let me come back to my problem with TagCompletion because I think I need your advice. If I create an instance of TagCompletion in the plugin, the ViewTree instance inside it (called tagtree) does not emit signals when the tag_completion filter is applied. This is because the filter has been already applied to that viewtree when creating the TagCompletion instance for the modifytags. If I reset the filter every time, signals are emitted, the list store is filled correctly and tag completion works also for the instance in the plugin. The relevant piece of code is around line 83 of http://bazaar.launchpad.net/~antonio-roquentin/gtg/bugfix-945553/revision/1222/GTG/gtk/tag_completion.py. Is this solution ok for you or does it introduce other problems?

Another option would be to have an unnamed ViewTree in TagCompletion, but this will cause a problem for get_used_tags().

[Izidor Matušov (izidor)]

To avoid problems like that, I would suggest to make TagCompletion a singleton. Could you move its initialization from browser.py into gtk/manager.py ? Create a new method something like "get_tag_completion()" which returns the same object every time. It would solve your problems elegantly.

[Izidor Matušov (izidor)]

Also beware that tab completion works only on the first tag, further tags are not completed and I couldn't figured out how to complete them. A patch is welcome.

[Roquentin (antonio-roquentin-deactivatedaccount)]

I am not sure a singleton is the best choice here. As you can see, I
wanted to tweak the way tag completion worked (for instance, show a
popup menu, do not complete @ and !), without altering the behavior in
the tagsmodify dialog. Thus I needed a new instance of tags completion.
Unless you want to enforce completion to work in the same way
everywhere, I would rather not have a singleton here.

[Roquentin (antonio-roquentin-deactivatedaccount)]

Upon reflection it is probably better to use a local instance of GtkEntryCompletion in the plugin, similar to search_completion in browser.py. I can rely on get_used_tags() as you suggested and add available smart tags directly from search.py. I'll come back when I have it working. Thank you for your guidance!

[Izidor Matušov (izidor)]

Antonio> I am still not sure if the entry completion (and advanced filtering) in notification area is a good idea. It might be complicated to write it down, the completition doesn't work for more than a single tag. Maybe we should stick with just one tag.