On Fri, Feb 26, 2010 at 11:46 AM, Lionel Dricot <[email protected]> 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 <[email protected]> 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 >> >> <[email protected]> wrote: >> >> > On Fri, Feb 26, 2010 at 2:06 AM, Lionel Dricot <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
