This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Tools and Pollock Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

This is mostly demos from Vassili - there aren't really many slides (and he's used a VisualWorks framework for slides anyway...). So where are we in terms of tools in VisualWorks? What we have now are "legacy" tools from the ParcPlace/ObjectShare days, plus new tools that have been submitted from the community. At present, tools integration is kind of like having a single fire hose to put out multiple house fires - there's a lot of integration that needs to be done. What we'e done over the last few years is to concentrate on the user interaction level - making the tools more user friendly and modern (especially the look/feel). We're going to see a few Pollock demos, but - here's a caveat - Pollock is currently at Feature Set I - meaning, it's partially complete, but not yet "baked". In other words, some of the underlying infrastructure may well change.

First up - Trippy, the inspector introduced in VW 5i.3:

Pragmas in VW.

size
	
	^0

The code in the method does not execute - this calls into the VM. It's not really a pragma. What Vassili is talking about is things like menu pragmas:

browseAllProbedMethods
	

That's Smalltalk code that gets executed, not a call out to the VM (or in the case of DLLCC, to a DLL). The syntax is somewhat limited - you can't just write any old Smalltalk code. If you look at the byte code though, you'll see some attributes - you get a method with a label:

if you define new pragmas, you need a (class side) definition method. Initially, pragmas came in to allow ad-hoc extension of menus (without the issue of multiple applications waxing the same method):

example
	

	"code here"

pragmaDeclaration
	

	^#(example:difficulty)

So - how do we find pragmas if we want to browse for them? Well, clearly you can iterate over a set of methods and look for annotations. However, when a class gets a pragma added you'll get a change message - #instancemethodChanged (for instance side pragmas). There's a class called Pragma that has some protocol making it easier to find them in the system. Immediately, Joseph Pelrine noted that this could be used to make it easier to locate test cases in SUnit.

Moving on - the bottom of the launcher is actually a tool dock, to which you can add your own tools. There's a monitor for Store and for change sets there already:

So to add something to the tool dock, add a method to the launcher:

applicationOpener
	

	^self newTool: BrowserOpener

So what about adding auto-completion? It turns out that there's a tool module for that - in the #postBuildWith: method you add a completionDriver - have a look at the way it's used in method lookup, etc. in the the current system. There's a reusable dialog as well - IncrementalSearchDialog

dialog 

	requestWithSuggestions: #('one' 'two' 'three' 'four')
	filterBlock: : [:entry :suggestion | entry, '*' match: suggestion].	

As a side thing, Vassili is showing us ad-hoc delegation with pragmas - very cool. You can easily define a set of allowable message names to relay onto a defined object.

Finally, we're looking at the Settings framework. That's a cool piece of work - I've mucked with it a fair amount in BottomFeeder. Learning the settings framework will walk you through pragmas as well. One nice thing I discovered is that it's easy enough to change the settings storage mechanism. VW uses an XML file, and allows you to save individual settings pages. I was able to override that in a subclass to save to an ini (key=value pair) style file. It's a very nice piece of work. The nice thing is this - if you mess up when defining a setting, the settings tool itself handles it (showing a "debug" button in development

Now on to the Pollock section of the presentation. I won't have screen shots for any of this stuff, since all the relevant examples aren't available to me at the moment. Looking at tooltips - In VW, the tip pops up as soon as the mouse goes over the relevant screen object. On the Mac (for instance), you need to linger the mouse over the same place for a moment before a tooltip appears. The way this works is a finite state machine, cycling between armed (ready to, but not yet), cool (not active), warm (firing), reaper (get rid of the tip). Most systems (like the mac) don't do "Warm" - VW does. That's why you get a tip for each toolbar button as you move the mouse across the toolbar - the FSM cycles between "warm" and "reaper".

We are having a look at the Pollock version of the completion driver now - same thing as the current implementation, except that the code is cleaner.