A Better Smalltalk IDE

 

(Ideas)

 

Code Browsers

Browsers should only show code for a particular package.

 

Package Manager

The Package Manager is a new introduction in SecureSqueak; it stores all code of interest to the current programmer (as Classes no longer store any code). The Package Manager is responsible for loading, storing and searching code. It can open a Namespace browser (editor) on a package.

 

Code Panes

There are two types of code pane: ones which represent definitions such as class, method, namespace, comment, method categorisation (deprecated?) definitions, and another type which accepts "ad-hoc" code such as in a workspace or debugger.

 

Code in a definition code pane shouldn't be changed unless that definition is changed: print-it should put output elsewhere. A small ad-hoc code pane should always be provided nearby.

 

A code definition pane should have a title or toolbar that shows what it is currently editing: A class definition, namespace definition, method definition, comments, etc. Perhaps this title bar could also be a compact code browser so that other methods in the same class or other classes in the same namespace can also be edited. Perhaps it could also show meta-properties of the method, such as whether that method is private?

 

For example, a definition code pane title bar could look like:

| PackageName:NamespaceName.NamespaceName.ClassName(method category)>>methodName | private: O |

Each element could be clicked on: Namespaces, classes and method categories could be "navigated" to and edited.

 

Perhaps a code pane is much like a browser; you could navigate between methods with a back button.

 

Perhaps each Project (the developer's version, with code) should also have an "ad-hoc" code pane or workspace with it that is stored with the project code? Or maybe the namespace browser should just always show that or have it handy nearby?

 

All text panes (code panes included) should have unlimited undo!

 

Code panes should be separate from text panes. You should not be able to execute code in a text pane. Text panes are for non-programmers to type text in. Code panes should be another subclass.

 

Code panes support (at least) the following operations on selected text:

• Do-it, which does it without any output.
• Print-it. Printed output should not appear in the same pane, but should appear in a separate pane or window. Perhaps a new temporary pane could be fitted under the code pane?
• Inspect-it, which pops up an inspector.
• Expore-it which pops up another inspector.
• Debug-it, which pops up a debugger.
• Tally-it, which profiles for performance.
• Browse-it, which assumes the selection is a class or evaluates to a class name.
• Selectors of it / implementers of it / references to it, which find a particular method.
• "Objects referring to it", which isn't in the menu but could be. This pops up a list of objects referring to the selected object. Perhaps a special browser could be made for this?

 

The "Inspector" and the "Explorer" should be merged. They have a lot of overlapping functionality.

 

Evaluated code should be done in a background process. The panes waiting on output from that process will appear "busy", and have some way of popping up a debugger on that running process.

 

A developer's VM should be able to put profiling information on classes, such as what the most common type of a particular variable is. The code could then be easily navigated by clicking on method invocations to go to the actual method definition that is used most often. Other features, such as code that is rarely executed appearing in grey could also be included.

 

The Debugger

The debugger should show a list of processes (possibly, for SecureSqueak, in a particular dominion). The debugger should be a "observer" rather than a "executor" of code; if "continue" is pressed, the stack in the debugger should rapidly update to show the progress of that code. The debugger can show the state of any particular process at any stage.

 

The Debugger is really just an extended version of the Process viewer.

 

The debugger should never hang or crash. It should only ever "view" another executing process. It should be very defensive about which methods it invokes on objects; the debugger should continue to work if a method never returns or throws an exception.

 

Testing

Each method should have a bunch of unit tests. The IDE could provide for this: every time a method is saved, it is compiled and tests are run against it. The result (pass/fail) of running a method's tests are shown unobtrusively on the GUI.

 

The GUI maker

An IDE can't be considered complete without one.

 

Ideally, the GUI maker would be simple enough such that even somebody with no previous coding experience can get something basic working. I would not try to avoid showing code to users, but provide at least some simple snippets of code to get stuff working.

 

At the same time, it should be usable by experts, possibly by having the GUI maker generate code. The GUI maker should be able to read in that code again (by executing it?) to redraw the GUI for editing, and experts should be able to custimise that code such that the GUI maker does not destroy their changes.

 

For the UGP, the GUI maker could be extended to allow graphic designers to make sites.

 

Perhaps layout of widgets could be done using a TableLayout-style editor (http://tablelayout.dev.java.net/). The GUI could present something akin to a spreadsheet. Widgets are placed in cells, and can do fancy TableLayout stuff like spanning cells (drag a corner) and being FILL, PREFERRED, an absolute size (in mm) or a percentage sizing (e.g. 50% of what is available). The spreadsheet thingie (like a JPanel with TableLayout) would be a widget too, so one can be added as a child of another.

 

Ideally, a "report builder" for printed reports should also be made. When writing the GUI maker, try and have as much code reusable for making a report builder as well for laying stuff out on paper.

 

Tables (like JTable in Java) should be standard widget. Custom widgets should be able to be included as well.

 

*Somehow*, spreadsheet-style code should be allowed. Perhaps widgets have names which become instance variables of a class, and each widget's value is the result of a method call on that class.

 

Examples:

 

1. The user has no idea where to begin. Include a tutorial. 
2. The user makes a inches - centimeters converter. There are two text fields in the window, "inches" and "centimeters" as well as decorations such as labels and icons. The "inches" implementation would be "↑ centimeters / 2.4" and the "centimeters" implementation would be "↑ inches * 2.4". The code might be in a code field on the GUI designer somewhere.
3. The user makes an address book. They add a table and define columns (name, address, phone, email). They add detail fields - text fields that show the table's selected value (e.g. "↑ addressTable selectedItem name"). They add a button to send an email (" | message | message := Message new. message address: (table selectedItem emailAddress). etc."). The functionality of widgets and their values needs to be easily navigated so the user can work out how to use them. The table probably needs a model of some sort, and the model probably needs a dedicated editor.
4. The user makes a "web page" - easy, just put static fields and images on a page. They make a guest book, which is a table and some fields to add new entries. They add a restricted area, meaning they need to be able to access lifecycle methods of the page.
5. The user wants to make a complex web site. Multiple concepts come to play: asset management, page management and security, user management, page hierarchies, styles that can be reused across pages, workflows, etc. The IDE would need some kind of template or wizard to manage all this and make it nice.
6. The user wants to use a package they've never used before. The package should be presented with documentation, help and a browser. The user needs to be able to find this package (perhaps using a package searcher of some sort?). Packages could be free under some OSS license or commercial.
7. Somebody else (or many others) wants to help the user. They also open up an IDE instance and they can collaborate. Methods might be locked for editing by others. Users can see who else is involved and chat with them.
8. The user wants to commit work to a repository.
9. The user wants to browse, compare and merge different versions from a repository.
10. The user wants to deploy and make his work publicly available.
11. The user wants to use advanced features. Examples: annotations, aspects, custom refactorings, integration testing, code coverage, load testing, object modelling, requirements management, bug management, task management, milestone tracking (project management), code completion, other language support, spell checking, documentation, profiling, advanced searching. The IDE should allow for plug-ins.

 

Package Manager

File out all.

Find package, namespace, class, method.

 

Package Source

Upgrade

Show dependencies

Open in browser.

Show versions.

Change description, author, name, description.

 

Dependency

Find reason (which method).

Browse package of dependency.

 

Namespace Source

Add, Remove class.

Add, Remove namespace.

Add, Remove, Inspect global variable.

Open in browser.

Recompile.

Make public/private.

Add, remove imports.

 

Class source

Add instance variable (needs to know dependencies).

Add, remove method.

Inspect compiled class (?)

Change superclass (affects imports)

Add, remove categories.

Change description.

Show hierarchy.

 

Method source

Recompile (may affect import list, class instvars, method instvars).

Inspect CompiledMethod(?)

Translate to another language (?)

 

Package

(User cannot edit directly - only through PackageSource).

File out (as binary), serialize.

Relink, recompile all from IL.

Browse

Find source (?)

Find class/variable/method.

Get description, auther, version, history.

 

Namespace

(User cannot edit directly - only through NamespaceSource).

Browse

Add, remove class

Add, remove global variable

Edit global variable (namespace is read-only, global variables in Associations).

 

Class

Recompile from IL.

Add, remove methods.

Add, remove instance variables.

Change superclass.

Get description (?)

 

CompiledMethod

Get description(?)

 

Should compiled objects contain documentation? Or should the developer need to get their source code? Users don't need documentation.