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.
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 > > > > > _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
