Ok, so here it goes. There was a main method: #package:class:category:method: (https://github.com/pharo-project/pharo-core/blob/8a1f79b44b14f8eafaf6d91a8bab3c28e673114c/Nautilus.package/Nautilus.class/instance/history/package_class_category_method_.st <https://github.com/pharo-project/pharo-core/blob/8a1f79b44b14f8eafaf6d91a8bab3c28e673114c/Nautilus.package/Nautilus.class/instance/history/package_class_category_method_.st>).
This method was setting a state of the model by sending #selectedPackage:, #selectedClass:, ……… to self. Each of this 4 methods were announcing if the parameter was not nil. As you may guess #package:class:category:method: was used through the whole system with occasional nil params. I hate working with nils. So what I did was to break the method into 4: #package: #package:class: #package:class:protocol: #package:class:protocol:method: So now there is no nil passing anymore. E.g. if you select only a class, you send #package:class:. Then I’ve moved announcements from #selectedPackage:, #selectedClass:, ……… to the newly created 4 methods. Also now announcements know the parent scope i.e. NautilusProtocolSelected besides protocol knows also about the class and package that played a role on the selection. This are essentially all the changes. The issue that occurred later (when selecting a package class was not deselected) is because #selectedClass: was doing `self selectedProtocol: nil`, same with protocol. But #selectedPackage: was not “deselecting” a class, probably because it was handled by calling `model package: SomePackage class: nil category: nil method: nil` in a first place. > On 05 Sep 2015, at 21:39, stepharo <[email protected]> wrote: > > > > Le 5/9/15 16:49, Yuriy Tymchuk a écrit : >> I can give you a short explanation for the sake of more people knowing how >> Nautilus works. > Yes please if you have some time. > What I do not like is that we pass nil to indicate that there is no > selection. I was thinking that an hierarchy of null objects could help but > this is difficult to > foresee if it will make sense. > I also that all the logic update without reselecting is complex. > I started to read the code and also move some condition about the model to > the model class :). > I would like to do just a simple pass reading all the code and not changing > much to get now yet another better feel of nautilus. > I will also remove the Nautilus help. > I would like to rename the NautilusRefactoring because it is not about > nautilus but about RB. > >> >> Regarding diffs and knowledge sharing, we should have a normal code review >> support with something like gerrit. > > thomas was working on a code review tool and skip is taking over so I hope > that we will have it. >> >> Uko >> >>> On 05 Sep 2015, at 15:46, stepharo <[email protected]> wrote: >>> >>> As you wish. Thanks for your time. >>> >>> Now I will get really frustrated because I will not know simply what you >>> did and I will have missed a good occasion >>> to learn something. This is what sending the diff in text simply give us. >>> >>> Stef >>> >>> >>> Le 5/9/15 14:09, Yuriy Tymchuk a écrit : >>>> I found the issue. Fix almost ready. Should I reopen the case, or create a >>>> new one? >>>> >>>> Uko >>>> >>>> >>>> >>>>> On 05 Sep 2015, at 13:59, Stephan Eggermont <[email protected]> wrote: >>>>> >>>>> On 05-09-15 08:51, stepharo wrote: >>>>>> Hi >>>>>> >>>>>> I do not know if this is linked to recent changes but we cannot remove >>>>>> classes or move them to another package >>>>> I can move them to another package using drag-and-drop (issue 16488) >>>>> in 50305 >>>>> >>>>> >>>>> Stephan >>>>> >>>>> >>>> >>> >> >> > >
