gtg-contributors team mailing list archive

[Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>]

Unfortunately I mostly used all my gtg working time quota for today,
maybe I'll have some more time tonight, I don't know. Here are some
notes that I'd like to share:

 - for now, tags can only be _added_ to the treeview, there's only a
"tag-added" signal coming out of the tagstore.
 - tags hierarchical relationships evolve dynamically as tasks are
loaded. A toplevel tag can become a child tags at anytime during load.
 - right now, most tags are first added in a flat manner to the tag
treeview. To improve this, we should be able to tell the treeview that
a tag has been moved under another tag. But here be dragons:
  * Treeviews only support add/remove actions
  * To move a tag, we thus should remove the previous row, and add the new one
  * But, unfortunately, the path of the previous one is lost since the
underlying data store is already updated. As such, we currently have
no way to remove it!

So here's the state of my work: a clean mean to remove a previously
added (but modified) row in the tag treeview is needed. It's not
unsolvable, but I must focus on other things right now. Nevertheless,
if you have any good idea about that, I'm interested.

Bertrand

On Fri, Feb 26, 2010 at 1:31 PM, Lionel Dricot <ploum@xxxxxxxxx> wrote:
> Le vendredi 26 février 2010 à 13:24 +0100, Bertrand Rousseau a écrit :
>> >
>> > 1) either they belong to the tagstore and, as such, should be created
>> > with the tagstore and any view of the tagstore can use/see them.
>> >
>> > 2) they are part of the view and, thus, should not modify the tagstore
>> > at all and be special things completely handled by the tagtreeview.
>> >
>>
>> My take is that those two pseudo tags are actually UI-objects that
>> allow the user to display a certain list of tag, but which have no
>> intrinsic meaning as a data structure. As such, it is for me the
>> conceptually equivalent of a toolbar button, menu item, or whatever.
>> They're just displayed in the sidebar treeview because their purpose
>> is to provide filtering for the task list, and as such, they're
>> (mostly) functionally equivalent.
>>
>> That was the reason they were added from the browser in the first
>> place. I agree they are more specific than the browser, and that they
>> feel out of place there. Actually I think we should have some sidebar
>> object, and sidebar tabs object, to decouple the browser from other
>> task-specific widget and allow to populate the sidebar with other tabs
>> (much like gedit does). As such, it could be interesting to define
>> some kind of tag-list "sidebar tab", and that would be where those
>> pseudo would be handled. Note that it could well be that those pseudo
>> are not added at all in the tagstore. We could just as well create an
>> adhoc TreeModel with just those tags.
>
> That's indeed a good idea. Make it a UI-only object. But it is then
> important to not add them to the tagstore at all. Also, we should remove
> them completely from the requester.
>
> Having them only in the TagTreeModel makes sense for me.
>
>



-- 
Bertrand Rousseau