gtg-contributors team mailing list archive

[Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>]

On Fri, Feb 26, 2010 at 11:46 AM, Lionel Dricot <ploum@xxxxxxxxx> wrote:
> One thing to understand with TreeModel is that nodes should be added
> only if their parent exists.
>
> So if you have:
> @1
> @2
> ->@3
> @4
>
> You cannot add @3 before @2. Same for removing.
>
> Also, the gtk.TreeModel is completely dumb when receiving row-inserted
> or row-deleted signal.
>
> If it receives two row-inserted for the same row, instead of figuring
> "oh, it's the same row", it will happen it twice, thus likely to break
> any other paths that follows.
>
> If it receive a row-removed for a row already removed, it will apply
> that remove to another row or crash.

I know that. It hurt me enough when I wrote the gtk.GenericTreeModel
for tasks and tags ;-)

I think I know why all the tags are displayed anymore: only the tags
saved in tag.xml are added, the others are supposed to be added when
task are loaded. My hypothesis is: previously it was actually done
in... the browser! (update_tags_for_task) Now, we commented out this,
so it's not performed anymore, but it must be replaced by some
convenient mechanisms somewhere.

>
> Le vendredi 26 février 2010 à 11:35 +0100, Bertrand Rousseau a écrit :
>> On Fri, Feb 26, 2010 at 11:22 AM, Lionel Dricot <ploum@xxxxxxxxx> wrote:
>> > Hey, thanks for solving that ! Nice catch.
>> >
>> > Unfortunately, it appears that not all tags are displayed. (I saw it
>> > once with test data but it's more noticeable  with a lot of tasks and
>> > tags.
>>
>> There are troubles with tags parent/child relationships, I'm currently
>> looking into this.
>>
>> > Lionel
>> >
>> >
>> > Le vendredi 26 février 2010 à 11:00 +0100, Bertrand Rousseau a écrit :
>> >> On Fri, Feb 26, 2010 at 10:44 AM, Bertrand Rousseau
>> >> <bertrand.rousseau@xxxxxxxxx> wrote:
>> >> > On Fri, Feb 26, 2010 at 2:06 AM, Lionel Dricot <ploum@xxxxxxxxx> wrote:
>> >> >> Le vendredi 26 février 2010 à 00:47 +0100, Bertrand Rousseau a écrit :
>> >> >>
>> >> >>> I suggest you mark the problematic methods with a special comment,
>> >> >>> like #FIXME or #REFACTOR. I saw you already did this on some, it's a
>> >> >>> good idea to continue.
>> >> >>
>> >> >> Yep, I did that.
>> >> >>
>> >> >>> > Each time I'm solving something, I discover something else, it makes
>> >> >>> > progress really slow :-(
>> >> >>>
>> >> >>> If you want some help, we could provide it, but you need to describe
>> >> >>> what precise problems must be solved, otherwise it's hard to jump in.
>> >> >>
>> >> >> Hm, I understand that this is not easy. Right now, things are starting
>> >> >> to work (well, tasks and tags are displayed) and 0.2.2 will be released.
>> >> >>
>> >> >> It's maybe a good time to jump in to understand a bit more the new code
>> >> >> base. (I plan to document that someday). A good start might be to read
>> >> >> the new requester and the comment at the start of FilteredTree.
>> >> >>
>> >> >> Don't hesitate to ask me any question you might have when you don't
>> >> >> understand something. If you plan to work on a bug or a feature, just
>> >> >> ask me what you want to do and I will explain you if it fits in the
>> >> >> refactorisation and what should be done.
>> >> >>
>> >> >> One issue I have currently (and I don't plan to work on it soon) is that
>> >> >> the "All tags" tag is displayed twice, I've no idea why. I also
>> >> >> discovered that drag-n-drop is broken in the TagTreeView. This is very
>> >> >> surprising as I don't remember touching it.
>> >> >
>> >> > I had a look at this issue. It seems that the iteration mechanism is
>> >> > broken in tagtree. For first-level nodes, on_iter_next should return
>> >> > the next item at the same level. But since first-level nodes are child
>> >> > of the root, but they don't have (anymore, I think) a ref to their
>> >> > parent, it cannot iterate correctly, hence it stops after the first
>> >> > node. Then all rows are added by the row_inserted method, including
>> >> > the already available rows (=pseudo tags) when the treeview builds
>> >> > itself.
>> >> >
>> >> > This is not a problem with the tasks since you defined an iterator in
>> >> > FilteredTree. We need something like this for the tags as well now.
>> >> >
>> >> > I guess that, if possible, we should push some kind of tree iterator
>> >> > upwards, near the Tree itself, so that each tree element would have
>> >> > access to it, not only FilteredTree objects.
>> >>
>> >> After takig a closer look to your next_node() method, I realized it is
>> >> preferable to redefine on_iter_next directly in the tagtree. I just
>> >> did it, and now the tags are correctly displayed in the sidebar (see
>> >> revno 674) (it only changes tagtree.py)
>> >>
>> >> >> There's also 39 FIXME and 28 TODO in the source code. Might be useful to
>> >> >> have a look.
>> >> >>
>> >> >> If any of your work is touching the browser.py file, please get in touch
>> >> >> with me before doing anything, as long as it's not merged.
>> >> >>
>> >> >>
>> >> >> All in all, I'm seeing a lot of bad stuffs that are killing a kitten
>> >> >> but, in the end, I really consider that the roots are really well done.
>> >> >> There are a lot of stuffs that work automatically, and, that are even
>> >> >> sometimes elegant. Considering we are one year old only, that we
>> >> >> accepted many many patches from everywhere, this is a great achievement
>> >> >> and I'm very proud to be part of it.
>> >> >>
>> >> >>
>> >> >> Lionel
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Bertrand Rousseau
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>>
>
>
>



-- 
Bertrand Rousseau