I've been distracted from writing a MirrorImage walkthrough by a discussion on vwnc about Pragmas. One of the final entries was this blog post by Michael. Apart from his surprising advocacy for text as UI - why not extend that argument from a single method to multiple methods, and then to the class - the comment that stood out for me was "Is it easier to pull down a menu to define an attribute on a method, or easy enough just to write some code...". Quite true. VW requires that just about everything is done with the mouse. On OSX at least, the very few keyboard shortcuts only partially work, and in any case you can't use the command key for anything but C/C/P. So all of my muscle memory on my wonderfully uniform (and configurable so) OSX works against me when using VW.

As an aside, text editing in in VW is not just poor, it's appalling. The code editor completely blows. And the implementation of error messages being inserted in the text is IMO not only a crappy idea, it's a complete PITA as implemented. In a recent vwnc thread about this it was asserted that the error message was always selected so you could just hit delete immediately after accepting in order to clear the message. Not so. I started monitoring this after being told about this 'convenience'. Most of my errors leave part of the message selected, and part not, so it's no wonder I hadn't noticed the 'convenience'.

All of this means that whilst on a macro level VW is wonderfully productive, on a micro-level it is anti-productive. The reverse of this situation is something like TextMate. TextMate is optimized for entering and editing text, and is amazingly, beautifully tuned for this task. What I'd like is TextMate micro-convenience and slickness in a Smalltalk environment.

All of that got me thinking about how to achieve some TextMate goodness in VW. And you know what? It's neither difficult nor a lot of work. Unless of course you need to maintain 100% compatibility with customers with a gazillion of mission critical GUI screens dependent on extensions and monkeypatching of the GUI framework.

I decided to start with command invocation, which I've implemented and published in the LinkuisticsUI-Commando bundle.

I've done a screencast showing the system in action. Instructionally its useful to watch both before you read the rest of this post, and afterwards. It's a bit cheap, especially the audio, but I'm not feeling well enough to walk to my studio and do a pro job. Also it's h.264 to lower the file size, so please forgive any minor artifacts.

What is a command?

In abstract, a command is the thing behind menu items, shortcut keys, text snippets, and non-semantic tab completions. The most obvious characteristic of a command is that it does something when it is invoked. Commands are applicable in a particular context e.g. 'Delete Class' might be applicable only if a class is selected. Or maybe that command could also operate without a selection by raising a class selector if there is no current selection. Commands execute in a certain context and may require information from that context (such as the currently selected class) in order to execute. The enablement of e.g. a menu item, is an indication of whether the command is applicable in the current context. Commands can be invoked in a number of ways: from a menu, or via a shortcut key, or by pressing tab at the end of a given text string in an editor, or from a list as in TextMate, which uses a nice filtering mechanism to allow commands to be quickly and concisely selected. Another benefit of list-of-commands UI is that you can easily discover all of the commands available in a given context, and check their shortcut invocations. It also allows you to disambiguate control-key shortcuts with multiple resolutions, and provides an obvious source for task/command-specific linking to help.

The implementation

There is a global registry of all commands known to the system in Commando.Commands. Commands are registered in getLUICommands class methods, which are discovered via reflection. There is currently no mechanism to monitor changes, so you have to manually invoke Commando.findAllCommands to (re-)install them, or you can use the command UI - there are commando commands registered. Each command has a name, which can be constructed from a hierarchical path. The use of a path means that the command is easier to filter and the name doesn't have to jump through linguistic hurdles to include it's context. It's also the basis for replacing the menu system by a filtered view of extant commands, which is my intention. A command can have a shortcut, which is either a control key shortcut or a tab-triggered prefix for text-based snippets. Finally, a command has to implement applicableInContext: aContext and executeInContext: aContext, the meaning of which should be obvious.

I haven't implemented the tab-completion mechanism yet, partly because to be be as good as TextMate it requires more extensive changes to the text editor. For example, when inserting a fragment that has placeholders you should be able to tab between the placeholders to fill them, including tabbing backwards which on my system triggers the emergency evaluator :(. Improving the text editor is on my list of things to look at.

What is a context?

My implementation handles all invocation in the KeyboardProcessor, whose currentConsumer is regarded as the source of the context. The context that is used is a list of objects which are created by visiting the source, it's components and it's parent in a (potentially) recursive manner. It's a trivial mechanism, but it works. You can end with VisualParts, models/applications, windows and controllers in the list.

My original plan was to have objects such as the BrowserNavigator decompose their state so that you would have individual context entries for each of the types of code model objects e.g. Classes/Protocols/Pundles etc. Commands applicable to a given code model object could then trivially operate in any UI which exposes the code model. This is related to the idea of more directly reifying the code model in the interface. It turns out that a lot of the existing UI uses BrowserNavigator, and given that I automatically include the RB commands, which naturally integrate with a BrowserNavigator context, I decided not to do any further decomposition unless I actually build a code-model-reifying UI.

Menu itegration

I have a rough plan for how to build menus from commands, thus replacing the menu system. It's particularly obvious when considering the OSX situation, which for native integration wants a single menu bar, but it's also applicable to menu-per-window model, and trivially replaces existing popup-context-menu systems - it is after all a generaisation of the concept of a context menu.

The published version includes code that processes the RB's menus to create code model commands. The RB already has a command-based system, although that model is somewhat more declarative, which reflects the fact that RBCommands are manipulated by a command definition UI.

But ...

The UI for this works well, but unfortunately the rest of VW isn't really setup to deal well with keyboard navigation, so often you can invoke a command using the keyboard and then you have to switch to the mouse to navigate the result. And as you can see in the screencast, even the mouse behaviour is sometimes annoyingly wrong, particularly in list selection.

I'd like to do something about keyboard view manipulation, and add a similar interface for navigating both to and within code model elements, but that's probably best done in the context of a different type of browser.

I've been involved in a discussion on vwnc about Pragmas. The gist of the discussion flips between whether they are an unneccesary complication of Smalltalk, or whether they don't do enough.

As a response to a 'put up or shut up', I'm going to describe two alternatives to the current VW implementation.

Doing the same with less

As a first, minimal idea, replace all instances like this:

browseLocalImplementorsOf

  <menuItem: #(#LocalImplementorsOfDot #menus 'Local Implementors &Of...')

   nameKey: nil

   menu: #(#listMenu #browse)

   position: 21.015 >

	...

with this:

someMethod

  PRAGMA menuItem: #(#LocalImplementorsOfDot #menus 'Local Implementors &Of...')

         nameKey: nil

         menu: #(#listMenu #browse)

         position: 21.015.

  ...

Add menuItem:nameKey:menu:position: on the class side of PRAGMA, with an empty implementation. Don't use PRAGMA in any other context. To find instances of a pragma selector, find all sends of the selector with PRAGMA as a receiver. The enumeration of all pragmas is simply the class methods of PRAGMA (ignoring superclass methods, obviously).

You can use the class as a further qualifier on the selector e.g. in the previous example, do this:

someMethod

  MENU item: #(#LocalImplementorsOfDot #menus 'Local Implementors &Of...')

       key: nil

       menu: #(#listMenu #browse)

       position: 21.015.

  ...

So far this is just like the existing mechanism. One thing I haven't addressed is change management i.e. how do changes to methods containing 'pramas' get notified. However, there seems to be general consensus that the current mechanism for that isn't very good, so I'm not concerned about not replicating that. Possibly a way to be notified of all method changes containing a given binding (the class reference) would be a cleaner idea.

But this doesn't go far enough for me. I think a better solution would be this:

someMethod

  MenuSystem

       item: #(#LocalImplementorsOfDot #menus 'Local Implementors &Of...')

       key: nil

       menu: #(#listMenu #browse)

       position: 21.015

       do: [ ... ]

But how does this method get called? Well - that to me seems to me to be one of the essential pragma use-cases. Simply use reflection to find references to MenuSystem, qualified maybe by a set of selectors, within a given subtree (which is how Pragma works now) and call those methods. The semantics of the 'pragma' is more obvious because it's just the result of the method call.

This seems to me to be the most Smalltalk-ish solution.

What about pragmas as simple attributes? OK, how about this:

someMethod

  PRAGMA isTest.

  ...

or

someMethod

  IsTest.

  ...

The tools required to do this level of reflection are already there, and it shares with the existing implementation the qualities of requiring no extra tooling, nor any modifications to file out formats, and by extension, VC tools.

A more general model

Having said all of that, I've got reservations about that implementation because it pollutes the method source, and the mechanism for adding such annotations to other entities, such as classes and bindings such as shared variables, isn't very clean, although it can be done.

What I'd like is a way to add general annotations to methods, bindings and classes. And by general annotation, I simply mean an Object. Not just a MessageSend keyed by a selector.

The method source CodeTool could allow the method's annotations to mark the source view in some way (say using a test icon header for test methods). Ignoring the bootstrapping details, imagine that classes intended for use as annotations are themselves annotated as such. Then new annotations to add to a method could be selected from a list of applicable annotations - using a filter on the class side of all available annotation classes. An 'Annotation' CodeTool would not only allow annotations to be maintained, but could do so using a a UI provided by the annotation itself. Imagine a Test annotation adding a checkbox to the header of the source pane for all TestClass subclasses to toggle 'is this a test' or not.

Obviously this UI is applicable not only to methods, but also to classes and shared variable bindings, or in fact any binding. This is a form of dynamic Multiple Inheritance for the code model e.g. a method can be mixed in with 'TestMethod' on the fly, but it does it using a common Smalltalk composition paradigm

And it still leverages the existing exploration facilities - allInstances returns all the instances of a given annotation type. It would be trivial to limit this to annotations in a given subtree. The meaning of the Annotation IS the annotation. Finally, there's no reason that the annotations can't be found and 'triggered' in response to other lifecycle events, such as loading and unloaded.

This would require a bit more work on the file-out system, and by extension, VC tools (e.g. Store), but so far I think it's the best architecture.

I've published versions of LinkuisticsUI/ASBAqua/ASBRB that implement a class hierarchy control as shown below. I'm going to add namespace support. Currently it's only passive, but my intention is to allow:

• click on a superclass will jump to the superclass in the navigator
• control-click on a superclass will switch the method visibility setting to include that class (and hence it's subclasses). Clicking again will return to only showing the leaf methods.
• left-click will bring up the menu that you would normally see.
• control-left-click will bring up a menu of subclasses, which you can select from to jump to that class in the navigator.

You can open an instance of this browser like this:

ASBRefactoringBrowser open

You should be aware however that it uses my GroupLayout mechanism to incorporate the control, hence the window spec has changed flavour. Therefore any extensions you have that depend on overriding the window spec of the RefactoringBrowser will not work.

And BTW, I've discovered a bug that has crept in somewhere (I think) in the scrollbar update that causes the 'Toggle Toolbar' menu option to break. On the existing RB, the problem is that an ASBAquaScrollbar is being created without being properly initialized, which then craps out when doing it's layout. I presume some kind of basicNew to do with cloning the window, but I'm not sure where it is.

A different bug in my new browser, presumably to do with my builder/canvas hacking, is that the builder gets created with a nil window reference. This also stops the 'Toggle Toolbar' menu item from working, and probably some other stuff as well. That's going to be easier to track down because at least I understand what's going on.

New tab style as shown below.

I strongly disagree with the idea of micro-configurable L&F. I think an L&F should reflect a single vision, rather than being a toolkit that delegates the selection of a consistent set of items to the end user. I feel the same way about application configuration, and got myself flamed in vw-dev when I criticized O/S software as often having this characteristic. For testing purposes however, and to see what elements work well together, I've added some configuration for the Scrollbar style and Tab style. The scrollbar style setting replaces the setting I previously provided for disabling the new scrollbars.

And speaking of new scrollbars - the borders look wrong to me because they make the scrollbar too thick. I'll probably leave it for a while though.

MacOSXLookPolicy.ScrollbarStyle := nil. "same as #vwaqua"

MacOSXLookPolicy.ScrollbarStyle := #itunes.

MacOSXLookPolicy.ScrollbarStyle := #vwaqua.



MacOSXLookPolicy.TabStyle := nil. "same as #square"

MacOSXLookPolicy.TabStyle := #recessed.

MacOSXLookPolicy.TabStyle := #round.

MacOSXLookPolicy.TabStyle := #roundgrey.

MacOSXLookPolicy.TabStyle := #square.

I've published versions of ASBAqua and LinkuisticsUI that implement the vertical scrollbars shows below. They are a complete re-implementation using a merged controller/view model, albeit with a decomposed mouse handling architecture that looks feels a bit like a split controller/view model. I'm experimenting with behavioural composition models for event handling, and ASBAquaScrollbar is one example. LUISplitterPart uses a more basic model. The scrollbar model is more complicated because it has multiple overlapping regions which have slightly different behaviours. It's more of an issue because of the way I get around the lack of alpha blending.

This scrollbar more closely adheres to native behaviour in the following ways:

• If you mouse down in the up-button, you can hold the mouse down and move over the down-button and it will trigger. The native behaviour is probably due to the case where the up and down buttons are grouped together, which is an OSX option. I might implement that.
• If you page-up/down and the thumb moves such that the mouse is no longer in the page-up/down region, then it stops repeating. You can drag between page-up/down regions and they respond in the same manner as the up/down-button regions.

These scrollbars implement the initial-delay + repeat behaviour, respond to the mouse wheel, and use optimized drawing (which I largely cadged from the existing implementation).

Note that I've only implemented the vertical scrollbars, and the code reflects that (i.e. a hard coded axis) - I will eventually get around to horizontal scrollbars, but I don't see much of them. There are some issues with the border mechanism, which I haven't got a handle on in VW, and if they don't degenerate very well when the allocation is too little.

Because they are a complete rewrite, in a different hierarchy, things might break. You can turn the scrollbars off and on using the following in a workspace. This is also the only way I could develop them because a scrollbar error is terminal in the UI. The default is true.

MacOSXBorderDecorationPolicy.UseNewScrollbars := false.

MacOSXBorderDecorationPolicy.UseNewScrollbars := true.