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.
For this project, I would:
- Port the Star Browser to the Omni Framework
- Integrate OmniBrowser into the joint Star/Omni browser
- Port 5 non-Omni-based tools to the Omni framework and integrate them into the StarBrowser
- the Changeset browser
- the single-pane Change Sorter
- Monticello Browser
- Monticello Repository browser
- the Monticello Snapshot browser
The result of these efforts would be an integrated tool able to browse every kind of code currently known to squeak;
- Code in the image
- Code in changesets (both internal and external)
- Code in Monticello snapshots
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:
- One month for the StarBrowser
- one week to create an Omni iconified tree morph as capable as the one used in StarBrowser
- one week to port the signaling and layout code in StarBrowser to the Omni framework
- one week to remove the dependence of StarBrowser on its embedded SystemWindow
- one week for testing and debugging problems that arise
- Three weeks for the ChangeSorter and ChangeBrowser
- One week to create an Omni model for change sets
- One week to integrate this Omni change model into StarBrowser's change classifier
- One week to port the two browsers to use this model. I would let the StarBrowser handle the browsing of Changesets, and only port the Changeset Browser. This would give StarBrowser the combined functionality of both tools.
- Three weeks for the Monticello Browsers:
- One week to create an Omni model for PackageInfo, snapshots, and repositories
- One week to integrate this Omni snapshot/package model into StarBrowser's classifier
- One week to move the tools to this framework. This would probably mean letting StarBrowser handle repositories and packages (which it could do is the past, but the functionality is currently broken), and only porting the Snapshot browser. This would make StarBrowser handle the responsibilities of the current Monticello Browser and Repository Browser.
- Two weeks for testing, debugging, and release.
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.