GTG

Notification area should be more configurable

Bug #945553 reported by Izidor Matušov
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
GTG
Fix Released
Low
Unassigned

Bug Description

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'

Tags: plugins love
Revision history for this message
Roquentin (antonio-roquentin-deactivatedaccount) wrote :

This will also partly address bug #591920.

Changed in gtg:
assignee: nobody → Antonio Roquentin (antonio-roquentin)
Changed in gtg:
status: Confirmed → In Progress
Revision history for this message
Izidor Matušov (izidor) wrote :

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.

Revision history for this message
Roquentin (antonio-roquentin-deactivatedaccount) wrote :

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

Izidor Matušov (izidor)
Changed in gtg:
milestone: 0.3 → 0.4
Revision history for this message
Roquentin (antonio-roquentin-deactivatedaccount) wrote :

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?

Revision history for this message
Izidor Matušov (izidor) wrote :

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

Revision history for this message
Roquentin (antonio-roquentin-deactivatedaccount) wrote :

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().

Revision history for this message
Izidor Matušov (izidor) wrote :

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.

Revision history for this message
Izidor Matušov (izidor) wrote :

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.

Revision history for this message
Roquentin (antonio-roquentin-deactivatedaccount) wrote : Re: [Bug 945553] Re: Notification area should be more configurable

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.

Revision history for this message
Roquentin (antonio-roquentin-deactivatedaccount) wrote :

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!

Revision history for this message
Izidor Matušov (izidor) wrote :

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.

Changed in gtg:
status: In Progress → Confirmed
status: Confirmed → In Progress
Changed in gtg:
assignee: Roquentin (antonio-roquentin) → nobody
Jeff Fortin Tam (kiddo)
Changed in gtg:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.