links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Unified Code Browser based on Omni and StarBrowser
Last updated at 1:34 pm UTC on 25 June 2009
This is Matthew Fulmer's second application to Andrew Black's Google Summer of Code 2007 project "Reimplement IDE Tools in a Structured Way". For the latest version, see http://wiki.squeak.org/squeak/5761


The code development tools in Squeak are nearly a decade old, and have not seen many improvements in functionality. Also, there are way too many of them. From the famous System Browser and Debugger, to the more specific "Implementors of" tool and the Monticello merger, to the nearly unknown Method Category Browser and the abandoned StarBrowser, there are over 20 isolated Squeak development tools with heavily duplicated code and minor to annoying inconsistencies. Also, nearly all of them are monolithic "black box" tools, which is part of the cause of the heavy duplication.

Omni is a new framework for Squeak that could relieve this situation. Omni is a network of models and viewers rather than many over-generic viewers on one monolithic model. Additionally, Omni abandons the old MVC symbol-based signaling mechanism and instead adopts the new Announcements Framework framework (The author also re-implemented the Announcements framework in Squeak, since it was originally only for Visual Works). In short, Omni is the recommended basis for creating tools in Squeak. But since it is new, it has not yet been adopted and it is not clear just how extensible it is.

One tool in particular stands out as being especially extensible; the Star Browser was able to handle system code, change sets, Monticello snapshots, and arbitrary files inside of a single, highly customizable tool. This is due to the StarBrowser's Lightweight Classification Model, developed by Roel Wuyts. In addition to pre-defined browsers that can browse a certain class of objects, StarBrowser could also let the user save bookmarks of interesting objects and classify them easily. In short, it is very close to the "one browser to rule them all" that Squeak needs. However, it suffered from a somewhat hackish and slow framework, since it could not depend on the arbitrary tools it attempted to draw together to follow any defined protocol.

StarBrowser, with it's ability to join together tools into a consistent and customizable UI, gives the Omni framework to truly shine. The StarBrowser had to resort to some serious hacks to embed tools that were designed to stand alone into its UI. The Omni framework, however is designed to be able to easily join tools together and be able to easily communicate. Thus, Omni can greatly simplify the implementation of StarBrowser (which would likely also make it faster), as well as allow StarBrowser to better unify the various tools. They are a perfect match for each other.

Specific Goals

For this project, I would:

The result of these efforts would be an integrated tool able to browse every kind of code currently known to squeak;

StarBrowser is able to handle this task, but it is only a loose coupling of the tools and has fallen out of maintenance. This project would update StarBrowser and merge it with the Omni framework to create a much smoother integration of the tools.


I will potentially be working 40 hours per week during the summer; if so, I will have 12 hours per week to dedicate to this project. Otherwise, I will have 50 or so hours per week. Here is my proposed schedule assuming I can dedicate 50 hours per week to this project:

About Me

My name is Matthew Fulmer, and I am a 21-year old college student at Arizona State University in Phoenix, USA. I am double-majoring in Computer Systems Engineering and Electrical Engineering, and will receive those two Bachelor's Degrees next December. I have been somewhat successfully organizing a documentation team to improve the state of Squeak documentation. We have focused almost exclusively on creating and categorizing Squeak tutorials.

Although I have little experience in them, I am very interested in user interfaces and compilers. Due to my research at ASU, I have some experience in pattern recognition and signal processing.

Recently, I have been busy porting ThingLab to recent Squeak images. Most of that has been in tracing and debugging the ThingLab Browser, which, like the current Squeak tools, is monolithic and uses MVC signaling mechanisms. I must say that it is rather difficult to understand these tools, since the very core of their behavior is specified by undocumented symbol-passing conventions.

For this reason, I really like the new Omni framework, especially its adoption (and porting) of Announcements Framework. Announcements Framework are much easier to understand than Symbol signaling, if for no other reason than Announcements must be listed somewhere. PluggableListViews, for instance, have a well-defined signal protocol, but it is neither easy to find nor extensible. The protocol cannot be specialized by subclassing; therefore the models must use the full interface for every PluggableListView, which leads to a lot of duplication. Omni and Announcements fix these issues. I applied to this project to speed the adoption of these systems, and finally lay the MVC legacy to rest.

As a side note, Juraj Kubelka has also applied for this project; he intends to integrate Traits and the Refactory engine into the Omni System Browser, and port the inspector to the new framework. The foci of our two projects do not overlap, and thus we could (potentially) both work on this tools project.

See also