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
