← Back to team overview

gtg-contributors team mailing list archive

Re: Refactorisation progress : an indicible truth?

 

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.

> 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



Follow ups

References