← Back to team overview

gtg-contributors team mailing list archive

Re: Refactorisation progress : an indicible truth?

 

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



Follow ups

References