Ok, so here it goes. There was a main method: #package:class:category:method: (https://github.com/pharo-project/pharo-core/blob/8a1f79b44b14f8eafaf6d91a8ba... <https://github.com/pharo-project/pharo-core/blob/8a1f79b44b14f8eafaf6d91a8ba...>). 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 <stepharo@free.fr> 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 <stepharo@free.fr> 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 <stephan@stack.nl> 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