gtg-contributors team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

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.


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
> >> >
> >>
> >>
> >>
> >
> >
> >
> 
> 
>