If no one raises objections, I would like to start on refactor / cleanup nautilus code. This includes: renaming / recategorizing solve code critics shown in Critics Browser split classes (AbstractNautilusUI has 427 methods 24 instvars ) stronger separation between the browser model, browser state and browser UI. review event handling and UI updating (sometimes there is a difference between what the UI shows as selected and the selection the model(s) holds maybe: create one package pane widget for package and groups (therefore move all that package vs groups handling from nautilus ui to that widget) merge Nautilus and PackageTreeNautilus (I don't consider all of Nautilus bad code, it has well designed parts, it just has grown meanwhile...) How to update the code? Working with slices makes it easier to find changes that introduces new bugs. Otherwise it takes time to do it in such small steps and I don't know if those changes are reviewed at all. So, I would try to group the changes. 1. code critics 2. renameing/ simple refactoring 3. .... nicolai
Good luck for that. I will have a look because the tool which allows to watch package dependencies embeds the Nautilus Browser, and i'm one of the maintainer at this time. Baptiste ----- Mail original -----
De: "Nicolai Hess" <nicolaihess@web.de> Ã: "Pharo Development List" <pharo-dev@lists.pharo.org> Envoyé: Jeudi 24 Juillet 2014 10:23:15 Objet: [Pharo-dev] Refactor Nautilus
If no one raises objections, I would like to start on refactor / cleanup nautilus code.
This includes:
renaming / recategorizing solve code critics shown in Critics Browser split classes (AbstractNautilusUI has 427 methods 24 instvars ) stronger separation between the browser model, browser state and browser UI.
review event handling and UI updating (sometimes there is a difference between what the UI shows as selected and the selection the model(s) holds
maybe: create one package pane widget for package and groups (therefore move all that package vs groups handling from nautilus ui to that widget) merge Nautilus and PackageTreeNautilus
(I don't consider all of Nautilus bad code, it has well designed parts, it just has grown meanwhile...)
How to update the code?
Working with slices makes it easier to find changes that introduces new bugs. Otherwise it takes time to do it in such small steps and I don't know if those changes are reviewed at all.
So, I would try to group the changes. 1. code critics 2. renameing/ simple refactoring 3. ....
nicolai
2014-07-24 10:28 GMT+02:00 Baptiste Quide <baptiste.quide@inria.fr>:
Good luck for that. I will have a look because the tool which allows to watch package dependencies embeds the Nautilus Browser, and i'm one of the maintainer at this time.
Good to know!
Baptiste
------------------------------
*De: *"Nicolai Hess" <nicolaihess@web.de> *Ã: *"Pharo Development List" <pharo-dev@lists.pharo.org> *Envoyé: *Jeudi 24 Juillet 2014 10:23:15 *Objet: *[Pharo-dev] Refactor Nautilus
If no one raises objections, I would like to start on refactor / cleanup nautilus code.
This includes:
renaming / recategorizing solve code critics shown in Critics Browser split classes (AbstractNautilusUI has 427 methods 24 instvars ) stronger separation between the browser model, browser state and browser UI.
review event handling and UI updating (sometimes there is a difference between what the UI shows as selected and the selection the model(s) holds
maybe: create one package pane widget for package and groups (therefore move all that package vs groups handling from nautilus ui to that widget) merge Nautilus and PackageTreeNautilus
(I don't consider all of Nautilus bad code, it has well designed parts, it just has grown meanwhile...)
How to update the code?
Working with slices makes it easier to find changes that introduces new bugs. Otherwise it takes time to do it in such small steps and I don't know if those changes are reviewed at all.
So, I would try to group the changes. 1. code critics 2. renameing/ simple refactoring 3. ....
nicolai
please On Thu, Jul 24, 2014 at 11:49 AM, Nicolai Hess <nicolaihess@web.de> wrote:
2014-07-24 10:28 GMT+02:00 Baptiste Quide <baptiste.quide@inria.fr>:
Good luck for that. I will have a look because the tool which allows to watch package dependencies embeds the Nautilus Browser, and i'm one of the maintainer at this time.
Good to know!
Baptiste
________________________________
De: "Nicolai Hess" <nicolaihess@web.de> Ã: "Pharo Development List" <pharo-dev@lists.pharo.org> Envoyé: Jeudi 24 Juillet 2014 10:23:15 Objet: [Pharo-dev] Refactor Nautilus
If no one raises objections, I would like to start on refactor / cleanup nautilus code.
This includes:
renaming / recategorizing solve code critics shown in Critics Browser split classes (AbstractNautilusUI has 427 methods 24 instvars ) stronger separation between the browser model, browser state and browser UI.
review event handling and UI updating (sometimes there is a difference between what the UI shows as selected and the selection the model(s) holds
maybe: create one package pane widget for package and groups (therefore move all that package vs groups handling from nautilus ui to that widget) merge Nautilus and PackageTreeNautilus
(I don't consider all of Nautilus bad code, it has well designed parts, it just has grown meanwhile...)
How to update the code?
Working with slices makes it easier to find changes that introduces new bugs. Otherwise it takes time to do it in such small steps and I don't know if those changes are reviewed at all.
So, I would try to group the changes. 1. code critics 2. renameing/ simple refactoring 3. ....
nicolai
-- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
please, go ahead :) On 24 Jul 2014, at 10:23, Nicolai Hess <nicolaihess@web.de> wrote:
If no one raises objections, I would like to start on refactor / cleanup nautilus code.
This includes:
renaming / recategorizing solve code critics shown in Critics Browser split classes (AbstractNautilusUI has 427 methods 24 instvars ) stronger separation between the browser model, browser state and browser UI.
review event handling and UI updating (sometimes there is a difference between what the UI shows as selected and the selection the model(s) holds
maybe: create one package pane widget for package and groups (therefore move all that package vs groups handling from nautilus ui to that widget) merge Nautilus and PackageTreeNautilus
(I don't consider all of Nautilus bad code, it has well designed parts, it just has grown meanwhile...)
How to update the code?
Working with slices makes it easier to find changes that introduces new bugs. Otherwise it takes time to do it in such small steps and I don't know if those changes are reviewed at all.
So, I would try to group the changes. 1. code critics 2. renameing/ simple refactoring 3. ....
nicolai
On 24/7/14 10:23, Nicolai Hess wrote:
If no one raises objections, I would like to start on refactor / cleanup nautilus code.
Wonderful! I can review your changes if this helps you (I really like when other people do it for me).
This includes:
renaming / recategorizing solve code critics shown in Critics Browser split classes (AbstractNautilusUI has 427 methods 24 instvars ) stronger separation between the browser model, browser state and browser UI.
review event handling and UI updating (sometimes there is a difference between what the UI shows as selected and the selection the model(s) holds
maybe: create one package pane widget for package and groups (therefore move all that package vs groups handling from nautilus ui to that widget) merge Nautilus and PackageTreeNautilus
(I don't consider all of Nautilus bad code, it has well designed parts, it just has grown meanwhile...) Sure improving does not mean that previous code is bad. Iterations are the way to learn. How to update the code?
Working with slices makes it easier to find changes that introduces new bugs. Otherwise it takes time to do it in such small steps and I don't know if those changes are reviewed at all.
do the best that can help you and what we can try is to give priority to the integration stream. Like that you avoid to have dependencies between the changes. This is what I try to do when I work on polymorph. I try to work on two unrelated topics (tools and widgets) so that the changes can be pushed to the stream and I can always work with the latest update
So, I would try to group the changes. 1. code critics 2. renameing/ simple refactoring 3. ....
one simple change at a time but steadily. stef
nicolai
participants (5)
-
Baptiste Quide -
Damien Cassou -
Esteban Lorenzano -
Nicolai Hess -
stepharo