Nautilus: the reborn of the SystemBrowser?

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: '';
package: 'ConfigurationOfNautilus';

(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.


  • 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.


  • 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


  • 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:

16 thoughts on “Nautilus: the reborn of the SystemBrowser?

    1. Thanks German. I sometimes do this kind of post (like the one of KeyMapping) to help their developers to do some marketing about what they are doing. I try to push them 🙂
      Moreover, as you say, there is some people that cannot read the mailing list all the time. And it is a pity that they loose so cool projects hahahah


  1. Excellent, excellent, excellent. Thanks for writing this up and pointing it out! I can’t be the only one that was tired of OB (not to belittle the effort), Nautilus is _very_ nice, and Ben has done some great work.


  2. Went Nautilus yesterday with the advent of the final 1.4. Wow, that’s an impressive browser. Takes a while to get used to but very useful indeed.

    Your article was very useful to avoid spending ages finding the nuggets of gold.

    One thing: out of the box refactorings have a rename class ending with XXX class, which turn an error. Is this fixed somewhere?


    1. Hi Philippe. As you said in your first sentence, this was an *idea*. Several times during the live presentation at Smalltalks 2011 I said that this was an *idea* and what people should copy was the idea itself rather than the code. The code is coupled to my stuff. I tried to code a general solution but it was useless, because there isn’t a general solution. It is just using Metacello + some classes that use Pharo tricks to customize things.

      So what you should do is to take the project, fork it, and change it as much as you want to get your own stuff. Or even start from scratch.

      #repositoryName is just because I am lazy and I want that my packages appear at the end in the Monticello Browser…therefore I do that in #putMyRepositoriesAtTheEnd.

      I know it may be overkilling for a started. However, this whole idea is not aimed for starters. You should have some experience with Metacello and building images to see the real advantage of it. And then the natural flow will tell you that this idea may have sense.



    2. Hi Philippe. Thanks for the comment. Regarding the bug, no, no idea. You should send an email to the Pharo mailing list and Ben will be happy to take a look 😉
      BTW, notice that since this post Nautilus has moved forward and improved and included even more stuff which is not included here…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s