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.

 

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/).

 

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.

 

Procedures

All recompilation should go through a managed system recompilation service which verifies security.

 

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.