I have always had a problem regarding Pharo: how to help/collaborate with its developement while still be as much productive as possible? The thing is that to help you usually need to work with the bleeding edge. To help, an easy way is to just use it and report/fix the problems you find while doing so. But I cannot use an image where I am not productive. So…how do I manage this? Since Pharo 1.0 to 1.3 (or so) I tried to always keep updated the Metacello configurations of the development tools I needed and sometimes even try to update myself the code of such tools. Second step was to at least, automate all my image building so that I could spend less time on in.
The tools I always need are: a nice browser with refactoring integration, OCompletion and Shout. So far, I have always been used OmniBrowser (a.k.a OB), and sometimes O2. The main problem with them is that their main developers are usually one version behind the Pharo bleeding edge. Say we are now in the development of Pharo 1.4, OB developers will likely update OB to work with Pharo 1.4 only when it is released, but not before. Therefore, it doesn’t solve my problem of trying to help Pharo yet have an environment where I am productive.
Luckily, Benjamin Van Ryseghem is solving my problem 🙂 He has been working a lot in a new browser called Nautilus. I really recommend you to give it a try. Just spend 5 minutes on it. There is a Pharo By Example chapter about Nautilus on the way which you can download from here.
Installing Nautilus
You can get a working image with it from Jenkins. Otherwise you can take the latest Pharo 1.4 image and try to execute the following:
Gofer it url: 'http://ss3.gemstone.com/ss/Nautilus'; package: 'ConfigurationOfNautilus'; load. (Smalltalk at: #ConfigurationOfNautilus) perform: #loadRelease
That will load Nautilus together with the refactoring engine and OCompletion (the default code completion in Pharo images). If you just want Nautilus and RB, then you can use #loadRefactorings and if you just want Nautilus alone, just use #loadDefault.
My point of view about Nautilus
I have been using it since a couple of days already and I would like to share the nice things I found.
Infrastructure
- The first thing is that it works in bleeding edge of Pharo 1.4. I hope that in the future Nautilus continue to be update at the same time than Pharo, so that I can always use Nautilus in the bleeding edge of Pharo.
- Not only it works in Pharo 1.4, but also it is based on the new tools of it, such as Ring (a model infrastructure for Pharo), RPackage (a replacement for PackageInfo and friends) and KeyMappings.
- It has integration with Refactoring Engine, KeyMappings, OCompletion, Shout and SUnit.
Usability
- Nice “Hierarchy” view. Maybe the first time it looks strange because it swaps the panes of the packages and the classes. But there are several reasons for that.
- Since I use Metacello to load/update projects, the 90% of my usage of Monticello Browser is to commit or view changes. Once you have modified a class, the icon of the package turns red in Nautilus. From within the icon, you can click and it directly opens a Monticello Browser so that you can commit 🙂 But…if you are lazy like me, there is even an option in the menu “Commit in ” -> select the repo.. and that’s all! You don’t even need to go to Monticello Browser to commit 🙂 And of course, there is also an option for “Changes With”.
- Environments aware browsing: you can select a class or a package, right click -> “browse restricted”. That will open a new Nautilus browser where the scope is limited to the class/package you have selected. So now for example if you search for senders or do a refactor, I will only do it in that scope. This is similar to OB’s refactoring scopes.
- The refactorings are grouped and adapted for each pane (package, classes, protocols and methods).
- Integration with SUnit: you can run tests from the browser. You can select one test method in particular, a class or a whole package. It also has rounded icons to see whether they have failed or not (the icon can be black when the test was not run, green or red).
- When you browse a package, you also see (in gray) the classes that have extension methods of that package!
- There is no confusion about with refactor and without refactor. For example, previously with OB, you have the default “rename” which was not a refactor…just rename it. Then to real rename it (and update references) you needed to go to the refactoring. I found this confusing, mostly for newcomers. Nautilus clarifies that.
- Finally, resizable panes (columns)!
- Clear button names. For example, instead of “?” now comments are in the button “Comments”.
Educating people
- Long methods have a yellow background and very long ones red 🙂 That tells you something!
- There is a special icons for not commented classes and you are even able to click in the icon to edit the class comment
Extensivility
- It is easy to add your own menu entries and shortcuts.
- Plugins architecture: like Firefox, Eclipse, etc., you can write your own plugins for Nautilus! For example, I like Igor plugin 🙂 it shows for each method the timestamp of the current version of the method.
“New” stuff
- Nice concept of Groups. You can create groups, where you give them a name and then you can add classes, methods or protocols to them. Then you can browse those groups and see only those items you have added. There are also some automatic/smart groups such as “Most Viewed Classes” and “Last Modified Classes”.
- Multiselection list!!! Yes, finally 🙂 The browser has the infrastructure for a multiplelist, so you can multiselect classes, protocols, methods, etc. Not all “actions” of the normal menu applies to multiselection. Some others would require some changes in the core of Pharo. Nonetheless, what matters is that at least the browser now supports that. As an example, you can select several methods, and remove all of them altogether.
My conclusion
I have to admit that so far I am loving Nautilus. One of the things I really like is that Ben is not only developing Nautilus but also he is improving Pharo in the way. You can check, for example, the Spec project. I also like the fact of using the latest infrastructure of Pharo such as Ring, RPackage, KeyMappings, etc. Finally, I have to remark the incredible good actitutude of Ben, its author. If you have feedback, wishes, ideas, bugs or whatever, do not hesitate to let him know. In my case I have reported him like 15 ideas and they were all implemented in the same or next day 😉 You can just drop an email in the Pharo mailing lists or directly create an issue in the Pharo bug tracker (there is a specific type for Nautilis). Thanks also for ESUG, Stef or all other who have pushed this project.
To sum up, I have migrated all my images to work with Pharo 1.4 and Nautilus.
Here you have a screenshot:
