Matthew Fulmer Squeak Tools Application
Last updated at 7:47 pm UTC on 27 March 2007
For the latest version of this application, see http://wiki.squeak.org/squeak/5759
Introduction
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 and VisualWorks 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 signalling 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 VisualWorks). 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.
Specific Goals
For this project, I would port the following 3-5 tools to the Omni framework:
- the Change List
- the Changeset browser (maybe)
- the Monticello Snapshot browser
- the Monticello Merger (maybe)
- the File List
I chose these tools because they are in the grey area of what Omni is designed to support. Omni is currently (I belive) restricted to "live" code; it only works with code living in the image. Making it able to handle code outside the image (in changesets and Monticello snapshots) would at least veryfy that it is extensible enough to deal with just about any code.
There is another reason I want to work on the Change List: it is (in my opinion) a very frustrating tool to use; I always have issues with the way it can hide (but not show) changes, and how it cannot make any changes to the changeset, and that it always seems to file in changes in the wrong order. It is the tool one must use to recover changes that were not saved into the image; thus it serves to increase the frustration that occurs when important changes are lost in an image crash.
The File list is even further away from the current Omni tools (which is just the System Browser at the moment), but it shares many properties with the system browser. Both list a large heirchy of "things" with an editor to edit the leaf objects. Also, FileList only one of two tools in the image (I know of) that make use of PluggableTreeView; it would make a good test case for the Omni tree widget.
UPDATE: OBFileBrowser is a project on SqueakSource that is a re-implementation of FileList on the Omni framework. It would make a very good starting point for this tool.
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. Thus, both of us could potentially work on this project, since our focus will be in different areas of the system.
Schedule
I will allocate one month to each of the three sets of tools:
- One month for the ChangeList and ChangeBrowser
- One week to create OBNodes to represent Changesets and doits
- One week to copy and refactor OmniBrowser to use the change models
- 1-2 weeks to create a ChangeList in Omni framework
- One month for the Monticello Browser and merger
- One week to create an OBNode to represent a package and repository
- one week to create an Omni snapshot browser in much the same way as a change browser
- 1-2 weeks to port the change list. I will not fix it at this point, merely change it to use Omni. I will save making it better for later
- One month for the FileList
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 signalling, 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.
