Vassili began working at Cincom four years at the end of 5i and the beginning of 7.0 where big changes have taken place.

Building tools is different to other peoples work. There's no flashy algorithms or sexy cool three letter protocols. Building tools is a thankless job in some respects. Vassili is going to show us how to use the tools the way he knows them - intimately.

The difficulty is not putting buttons on the screen, the programming is fairly easy. The hard bit is the design and making sure the tools make sense for all its uses and users. The first example of design he brings up his badge here at the conference and it says he works for "Bykov Cincom" because the font size combines them together by your eye. His name must obviously only be Vassili.

Another example is the lift where the lift lights for 'up' and 'down' look like floor buttons. Unfortunately they're up on the top of the lift where it's hard for short people to reach.

The next example is the alarm clock in the hotel rooms. The Sony Dream Machine. They look like darth vaders helmet. The hotel provides instructions on how to use this machine because it is extremely complex to understand - and the instructions are wrong. (mine is still playing! it didn't wake me up this morning)

There's no doubt that it is a Dream Machine. There are three buttons over the body of it in varying places: Sleep, Snooze and Nap.

The first thing Vassili introduced was Trippy. (Vassili shows us Expose and demonstrates why Mac is much much cooler than Windows). In an array inspector. You can accept some code and it will assign it to everything selected, not just one selected item. There is undo in there too which undoes the assign as well!

You can drag and drop elements from one array inspector in to another array inspector as well as drag and drop re-ordering of items. Not to mention that an array is fixed size. The inspector will happily resize.

The inspectors have an evaluation pane in Squeak - which goes back to the Apple smalltalk, which are also in Trippy now. There are protected instance variables to stop you accidently using drag and drop in places like scheduled controllers where you don't get a chance to hit undo! :)

Once you've gone back and forth along objects you get a back and forth history like a web browser. But there is also a history pane which shows you a graph of all the places you've visited, which breaks out of the linear back/forward path.

Vassili double checked the crowd to see who knew Pragma's. Because there were only a few he's going to roughly run over the pragma's. An example of the Visual Launcher which contains a bit of code and a pragma at the top for defining the menu item.

Using pragmas you can add in your own menu items in to a menu that you didn't define and you didn't have to override the menu definition to add in your own menu items. Tools very often add in new menu items in different contexts, so this pragma technique lets you extend menus all over the environment in any way you wish.

A method that is compiled with a pragma in it instead of being compiled in to a CompiledMethod, you get an AnotatedMethod instead which has attributes on it that are the details of the pragma.

You can also put more than one pragma in to your method. So one method can be the definition for a menu item and a toolbar item and a menu item in another menu too.

To collect up all the methods that have pragma information, you can write code like Pragma allNamed: #some:pragma:name: in: self. With that information you can do whatever you want, for example, use the pragma information to modify menus.

Vassili shows us a Pragma object but it doesn't have a printon. So he does some programming in the inspector by going to the methods tab and adding a printOn: method for Pragma.

Vassili - "Go try this in Eclipse"

To use the pragma in an easy way, you can send pragma withArgumentsDo: [:name :foo :bar | ]. So that you can name the variables in the pragma.

There is a tool area at the bottom of Visual Launcher. Vassili has made a simple class launcher program that is a normal window with a text field and an open button in it. Now he's going to add it as a tool in to the tool area of the Visual Launcher by adding a pragma to the VisualLauncherToolDock.

As soon as he made the pragma, the launcher noticed that there was now a new tool and it immediately redrew itself inside the Visual launcher.

With only a couple of lines of code he added auto-completing of class names to his little tool.

The next tool to look at is an incremental search dialog. The dialog has an input field that auto-completes with a list below and a cancel and accept button. This dialog is used generally for finding classes in the system. Another example is the published items for store.

Having described the incremental search module, which is used in the incremental search dialog, Vassili decides to make a primitive class dialog. which is a mixture of the search and a window are to show the classes definition method.

To drop the search module in to your own window you just use a subcanvas for the class IncrementalSearchModule. In #initialize, set up the search module to have items or a block for geting items, add a couple of signals as well for selection changed, etc. The rest is done for you.

Vassili taunted us with the story of the legend of Sea Snail Soup.

Using pragma's Vassili has also added a new pragma called the relay pragma. It is used to relay messages from object to object to get the information you need through several UI widgets to the destination widget in the nicest possible way.

And finally Vassili moves on to the settings framework. The settings tool is broken up in to two main areas - an iconed tree list down the left hand side, the right side is where the settings for the selected item sits. I've used this before and it is both constraining and flexible. The pragmas certainly make developing with it easy but when I used it it was new and there was little documentation. These days there is plenty of documentation.

For this demo Vassili added a setting to set a Transcript limit and it's one method for creating a setting and a pragma to identify it as an actual setting for the settings window. As soon as he saves the method, the new setting tool appears in the settings window.

As a killer Smalltalk example, he put a mistake in to his setting definition and the settings program showed a red label warning that there was an error and there was a debug button. He hit the debug button and fixed the mistake and the window fixed itself immediately.

I think everyone here learnt a few new tricks in the development environment.

Question: What is the status of the pollock tools?
They are being designed.