This can be a little inconvenient at times:

• External files are just more things that have to be distributed and installed with your application. In fact, since virtually every application will want to use at least one icon - to represent the shell window when minimized - it hasn't really been feasible to deploy true one-click executables before. Instead, we find that most Dolphin apps require the use of some form of installer program.
  
• External files can't currently be placing into the built-in Smalltalk Tracking System (STS) version control. This means that bitmap and icon resources must be stored in a separate repository. Whilst not a complete solution for all cases where external files are needed, it would be nice if such image resources could actually be held as Smalltalk methods so they could be successfully versioned.
  
• Icons, with their multi-resolution formats can be tricky to create. At the very least you'll need another application - an icon editor - to manipulate them. Surely, it would be better if we could make use of an alpha-transparency capable image format, such as PNG, for both bitmaps and icons and then we'd only need a single image editing application for both?

To get arround these issues, I've put together a goodies package called "Internal Bitmaps and Icons". You can download this here. What this package does is to introduce two new classes, InternalIcon and InternalBitmap, which can be used to hold the pixels of a PNG image internally within the Dolphin object memory.

These classes make use of GDI+ to load in external picture files and hold them as GdiplusBitmap byte array initializers within the image. Hence the appropriate bitmap can be created at anytime without further reference to the external file. Typically, the external file will be a PNG, which can contain transparency information and is therefore capable of replacing most of the functionality of standard Windows ICO files. Other files, such as BMP and JPG, may also be used if alpha transparency is not required.

Let's see how this might work in practice. There are two things we often want to use icons for: the first is to represent classes or objects pictorially in an application; the second is to represent commands as button images in the application's toolbar.

Using InternalIcons in class #icon methods.

Looking around the standard Dolphin system I can see a number of areas where the included icons are looking a bit tired. So, as an example of how to use InternalIcon, lets try and replace the "Registry Editor" sample application icon with something a bit more swish.

The current icon is actually referenced directly out of the standard Windows RegEdit.exe executable (as are some of the other icons that the sample makes use of). Take a look at RegEdit class>>icon. We are going to modify this method so that all the pixels of our new icon are held within it.

The first thing we need is a suitable icon image. Since the original looks a bit "Rubik's Cubey" I used Google Images to hunt down a suitable PNG file to replace it. Obviously, if this was to be a commercial solution, one would be more wary of copyright, however, for the purpose of this example I took the (rather large) PNG of a Rubik's Cube from this Wikipedia page:

http://upload.wikimedia.org/wikipedia/commons/3/30/Rubik_cube.png

The image you choose can be any size but, to be used as an icon, it should be square. InternalIcon will, by default, resize the picture to 48x48 pixels so an oblong image will become distorted if you decide to use one. The package introduces some helper methods to ClassDescription, so open a workspace and evaluate:

RegEdit createIconMethod.

This will prompt you for the location of your PNG file and will then load it into an InternalIcon instance and from this it will create a RegEdit class>>icon method. If you now cause the System Folder to refresh (by changing folder and going back again) you'll see the new icon has taken the place of the old one:

Taking a look at the RegEdit class>>icon method we see that it has been compiled to answer an instance of InternalIcon built from a literal byte array:

That literal array contains all of the pixel information for the reduced size image in PNG format. If you ever update the extenal PNG file in future, you can bring it into your image again and rebuild #icon method by just evaluating the Smalltalk code in the method comment. Easy-peasey.

Now, whilst the above method source might appear quite long, remember this is not, itself, kept within the image but in the changes (CHG) or source (SML) files. What will be kept in the image is the compiled version of that ByteArray, which will be held in the literal frame of the #icon method. In this case the byte array is 4379 bytes which would compare favourably with the size of a 48x48 PNG image file. Typically, though, this will be a lot smaller than the equivalent Windows ICO file which might have several different resolution renditions of the same uncompressed bitmaps within it. Newer Vista-style icons which hold PNG images anyway are more efficient and might come in at about the same size as our byte array.

So we have added an additional 4379 bytes to our application's runtime footprint but we have got rid of an external file reference, allowed the icon to be versioned with STS and reduced its general download size by being able to omit any external icon files. This seems to me like a reasonable compromise and an overall Good Thing. You would, I suspect, not want to use this technique to load a large number of huge bitmaps into your Dolphin image, however.

Note: If you open the RegEdit application you will notice that the new icon does not show up correctly as the icon for the shell window. This is because the shell view's icon has been explicitly set to be something else in the View Composer. To fix this, edit the RegEdit view, and set the #largeIcon and #smallIcon aspects to nil. Now the shell icon will be taken from that of the RegEdit class.

Using InternalIcons in toolbar buttons

Another great use for InternalIcons is in toolbar buttons. Basically, the method of assigning an icon to a button stays the same but, rather than instantiating a plain old Icon instance, we create an InternalIcon instead. Here are the steps:

1. In the View Composer select the toolbar's #items aspect, click on the New Item button and choose ToolbarIconButton new as normal.
2. Drill down into the #commandDescription of this button and find the #image aspect. You will see that this is predefined to hold an instance of Icon using the standard Object.ico resource identifier.
3. Normally, to choose an external icon file you can double-click the #image aspect and you will be prompted for an ICO filename. However, until the "Internal Bitmaps and Icons" package is integrated into the base Dolphin system this won't work for creating an InternalIcon. Instead you need to go to the Smalltalk workspace pane and type: InternalIcon chooseFile. Accept this (with Ctrl+S) and you will be prompted for the name of your PNG file to use.

After you've done this, here's how the new InternalIcon will appear in the View Composer:

One disadvantage of using this approach (InternalIcon chooseFile) is that a new instance of the InternalIcon will be created each time. Hence, if you do this in several places you will have duplicate copies of the icon and all its pixel bytes being held in each instance, which is rather wasteful of runtime memory. In such cases a better approach might be to create a class side method (Myclass class>>#myIcon, say) on one of your application classes that answers this InternalIcon in just the same way that a standard #icon method might. Then you can just evaluate, MyClass myIcon each time you want to have shared access to the icon data.

I hope this is clear. If you're in any doubt that such an approach really does share the image bytes for each invoation of the method then try the following in a workspace (after having replaced RegEdit class>>icon as explained in the first part of this article).

icon1 := RegEdit icon.
icon2 := RegEdit icon.
icon1 bitmap initializer bytes==icon2 bitmap initializer bytes. "Display It - should get true"

I hope this has been an interesting diversion for at least a few Dolphin developers. Let me know via the newsgroup if you have any problems with these internal icons and bitmaps. If not, then I hope to roll this goodie into the base Dolphin image at some point in the near future.

Oh, and here's the link to the package file again: Internal Bitmaps and Icons.pac

MVP was intended to be quite simple whilst also giving flexibility for better code re-use, and therefore maintainability, in GUIs. I suspect that, in some respects, we failed in the former aim based on the number of people who've had difficulties "clocking" MVP in the past. So, the first thing is; If you don't yet get it - you're not alone. Hopefully,the following discussion will help and not hinder in this respect.

Wasn't VB Great?

Think about Visual Basic (with which I assume you're familiar). What a great system for easily building simple GUIs by drag and drop. I won't hear a word spoken against it! Only when one gets to more complicated apps do cracks start to appear.

I call Visual Basic a visual component system. You have a toolbox of components that you can drag and drop and place on a form. You have text fields, check boxes, push buttons, lists and ActiveX controls. You can compose these in a container (the form) and write code behind each control or behind the form itself. Typically you can change the way a component looks by setting properties in the property inspector. It's all very quick and fun, but what happens if:

1) You want to change the "look" more drastically without affecting the underlying functionality of the control.

2) You want save a container with pre-built functionality and later re-use it inside another container or form. VB does not allow nested/hierarchical containers.

3) You want to associate more structured data with a control. Either with a normal control or a composite that you have created. In VB the data types held by controls are fixed and you can't really associate a specific data type with a form at all.

So these are the problems that MVP aims to solve. Typically, a component in MVP is represented by a Presenter. This is the "visual control" if you like. It has data associated with it (the Model) and an appearance (the View).

In MVP, Presenters are Components

In VB you build up functionality by composing components into a form or by adding code behind them. The equivalents in Dolphin are to build a new composite presenter or to subclass an existing presenter respectively. In Dolphin you don't build a composite by dragging and dropping like you do in Visual Basic; instead you create a subclass (typically of Presenter) and then add a #createComponents method to add the sub-components to it. Ideally, we would have a drag and drop editor to do this but, as yet, we don't and you have to code the assembly yourself.

So by creating new presenter classes you can create new components. For each component that you create you can (and, indeed, must) specify the data on which it operates (the Model) and the visual representation (the View) on the screen. Often a model is just something simple like a text or number value (a ValueModel). Other times it is a collection of things (a ListModel) and sometimes it is more complex still (any Smalltalk object you can think of). A view needs to be drawn for each component with the View Composer.

I think one of the confusing aspects of Dolphin's MVP for many people is the use of the View Composer. Because it looks like the VB form editor they assume it performs the same task - to assemble components. This is NOT what it does. One assembles components in code (by creating subclasses in the presenter hierarchy) but you specify how they look in the drag and drop View Composer. Designing the appearance (certainly the final appearance) will likely be the last step you take when building a GUI component. In VB it's the first.

Views are "Skins"

Because of this separation between presenters and views, the latter can existing in a completely different hierarchy from the former. Hence it is possible to have a fairly simple hierarchical structure on the presenter side that only reflects how the logic of the application works. We like to think of this as being like a schematic diagram. Electronic engineers use schematics to see exactly how a circuit functions without all the extraneous clutter of how the circuit design has to be laid out on a printed circuit board (PCB). It's the same with presenters and views; in the former, you can see the logic of the application without being hindered by the constraints of how the GUI will appear on the screen. Indeed, in many apps, it may also be advantageous to have several different GUI "skins" for the same underlying presenter logic. This is what the ability to associate many views with any given presenter allows you.

Views can have a completely different structure from Presenters

I've suggested that a presenter hierarchy should be as simple as possible; only enough to represent the logic of the application's interactions with the user.  However, the view hierarchy can be more complex. Often this might be the case to allow for automatic layout functionality as the window is resized (via LayoutManagers). Because of the separation between view and presenter all this "visual fluff" can be done without clouding the logic in the "schematic".

Sometimes, you can even use this feature to arrange non-rectangular components, i.e. in MVP, a component isn't forced to live inside a rectangular box on the screen (an example of this is the use of the MethodBrowser inside a ClassBrowserShell - it holds the method list and the source pane in a non-rectangular area).

Should MVP be relabelled MPV?

Another confusion might be in the acronym, MVP. Model-View-Presenter implies a certain creation order but this is rarely how the design actually proceeds. Typically one will have some data, a instance of a Smalltalk class, that needs to be reperesented in a GUI. This is the Model and it usually comes first. Next is the visual component for interacting with the model . This is the Presenter and it is usually considered next. The View (the way of representing the model on the screen) is normally the last piece of the puzzle - if only because each view must have a presenter in existence for it to be attached to.

Often, because of the dynamic, interactive nature of Smalltalk, the design of presenter and view proceed in lock-step but in reality it's probably helpful to think of the presenter coming first, if only slightly. So, think Model-Presenter-View!

I've continued with the "stream of consciousness" approach, which means that the total length of all the programmes is rather long. However, I hope you'll find that, if you can stick through them, they give a good insight into what programming in Dolphin and MVP is all about. Basically, you're going to have to choose between watching "Quantum of Solace" or brushing up on your Smalltalk programming skills. Shurely(sic) no contest?

The final parts can be found in the video library here:

• Part 3
• Part 4

You can also download the completed example package of Dolphin source code from the same pages. However, if you don't want to load them into Dolphin, but would rather just play the game, you can download the final Windows executable file, which should be just click and go. Here's what it looks like when running:

You may also notice that we've upgraded the Object Arts, "Swimming Against the Tide" blog to include the ability to leave comments (powered by a rather nice third part plug-in called Intense Debate). Hopefully, this should help make the blog a more entertaining place to be. In future, we'll probably use it for announcements (such as those for DNG) that we'd otherwise post to the newsgroup, so I'd encourage you to subscribe your RSS reader if you're likely to be interested in such things. 

Eventually, this video library should grow to include plenty of "hands-on" material to supplement the existing help tutorials.d the Dolphin videos here on the Object Arts site or by going to the Smalltalk Programme Channel at Blip.tv.

Lesser Software's current product set includes LSW Vision Smalltalk, whose virtual machine retains full bytecode compatibility with the original Digitalk Visual Smalltalk Enterprise (VSE) platform. Existing VSE developers can migrate their codebase to Vision Smalltalk, usually within minutes, gaining the ability to run their applications on a fast, modern and fully supported virtual machine. 

Similarly, as a result of the new agreement, Dolphin users will have access to the full Dolphin development environment and class library (including MVP) running on top of the Vision Smalltalk substrate. The new system will be completely source code (rather than bytecode) compatible with existing Dolphin Smalltalk X6 projects, so adopters of the new platform will instantly gain a number of key benefits:

• Speed. The Vision VM is Just-In-Time (JIT) compiled and is FAST. The current Dolphin VM is based on a very fast interpreter. In some circumstances this has advantages over JIT compilation but if you want SPEED then JIT is the way to go. Early estimates indicate that the new Dolphin will be between 2x and 5x faster than Dolphin Professional X6.
• Multi-threading. Currently, the Dolphin VM is single threaded (although with an ability to run external calls on separate threads). The Vision Smalltalk VM is true multi-threaded which will allow Dolphin applications to take full advantage of the modern generation of multi-processor and multi-core machines.
• Unicode Support. Internally, the new VM is entirely based on Unicode. For many of our international customers the ability to use Unicode in their applications will be a huge benefit.
• Smalltalk Link Libraries (SLLs). In the same way that Digitalk Smalltalk introduced the concept of SLLs, the Vision Smalltalk platform also allows Smalltalk code to be distributed as collections of small, pre-compiled units that in many ways are simailar to Windows DLLs. Dolphin Smalltalk users will be able to deploy their applications either as SLLs or fully bound into executable files as they are today.
• 64 bit OS Support. Whilst the current Vision Smalltalk VM is 32 bit, development is underway on a full 64 bit version. Once this is ready, new Dolphin users will be able to benefit from this immediately with no additional effort.
• Maintenance and Support. The Vision Smalltalk platform is fully supported and is being actively developed by Lesser Software. With this new way forward both existing and new Dolphin developers can be sure of a supported route into the future.

At present, no pricing structure has been set for the new platform. However, following its release we still intend to continue to keep the current Dolphin products (DPRO and DCE) in existence. Hence, the Next Generation Dolphin environment will likely be positioned at a price point above that of the existing Dolphin Professional product.

If you are excited as we are about the potential behind this announcement you'll probably want to learn more about when development will commence on the Next Generation product. If so please follow this link to Dolphin NG Development.

The setup program can be downloaded from here and the release notes for the current beta can be found here.

As you'll see, this release offers quite a few bug fixes to 6.02 and a number of enhancements. The latter are things like: better cosmetic appearence under Vista, the ability to save out Idea Space templates and an SUnit Plugin for the Class and System browsers.

Actually, although we've called this a beta, in some ways it's more like an alpha. There are a number of features we'd still like to add to the IDE, particularly in the area of the STS integration and these should appear in the next beta release.

Please use the Dolphin Newsgroup (comp.lang.smalltalk.dolphin) for any discussion about the beta.

Hence, I will re-enable the purchase pages on the web site over the next few days but will make it clear that the product is largely unsupported and that no major new versions will be forthcoming. If anyone desperately wants to make an early purchase before the web store is back online then they can e-mail me and I can send them a web link. Please feel free to buy as many licenses as you like :-)

We have come to this point for a number of reasons, the most potent of which is the fact that it is just not commercially viable (and to be truthful it has never really been so) to continue development of the product. There are simply not enough people who are able to recognise that Smalltalk offers something much better than the tools and languages "du jour". The shift of Microsoft away from the Win32 API to the .net platform (and the associated presentation foundation) has not helped and would mean a dedicated development effort of sufficient intensity that we just can't commit to it given the potential returns.

We started Object Arts almost exactly 10 years ago with a view to continuing the development of Dolphin which had been started and then abruptly terminated at our previous company, Intuitive Systems Ltd. Both of us were of a mind that this was something that needed to be done; not only because Smalltalk was quite the best development environment we had come across but because we felt that the work already completed on Dolphin was some of the best we had achieved in our careers to that point. It seemed important that Dolphin Smalltalk should be carried forward and that other developers be given the chance to "see the light". These sentiments remain with us today but the cold reality is that we have to look for other sources of income for our families and the future.

So what of the future? Blair has taken up a job with Microsoft Research in the UK and I am occupied full-time developing stock trading systems under the Alchemetrics banner (still using Dolphin Smalltalk). The latter should mean that Dolphin will not die quickly because we have a wealth of software that relies on it to continuing operating smoothly. The nature of Smalltalk with the fact that most of the source is "open" means that existing users should be able to continue using the Dolphin products and not have to port away to other platforms (and hopefully never to C# or Java). We will try to issue the 6.1 maintenance release that we have been using internally (wrapping all outstanding bug fixes) before the end of this year.

There will no doubt be a number of you who would suggest that we Open Source Dolphin. Of course, you are free harbour such opinions and to discuss the idea on the newsgroup but please do not expect us to be persuaded. It simply will not happen! Both Blair and I dislike the Open Source movement intensely and we would rather see Dolphin gradually disappear into the sands of time than instantly lose all commercial value in one fell swoop. But this is a discussion for another thread. The best, and probably only, way in which the future of Dolphin could be assured would be a sale of the assets to another company. Whilst we are not actively seeking buyers, serious negotiations can be started by writing to me at my e-mail address.

At this point, I cannot sign off without commenting on the enthusiasm and talent in the Dolphin community that has sustained us all these years. There are people on the Dolphin newsgroup who have been with us since the early days back in 1997. There are a number of you who have supported Dolphin far beyond the call of duty and I sincerely thank you for this. I don't want to name names for fear that I forget someone but you know who you are and I thank you again. Doubtless, many of you will be disappointed by this decision but I hope that you understand now why this has to be.

PS: we came to this decision several weeks ago. For those of you who have recently purchased Dolphin Professional and are now unhappy with the decision, we will honour requests for a refund for any purchases made within the last 60 days.

Blair and I both "got into" Smalltalk in 1994 just at a time when it seemed that the language was about to burst onto the software scene in a big way. There had been commercial versions of Smalltalk (DigiTalk, ParcPlace, IBM) around for several years and these had been doing very well in certain market segments, especially the financial sector. However, it was only with the advent of the Pentium processor that the everyday desktop computers really had enough grunt to run Smalltalk applications. From that point on the "performance issue" of dynamic languages became a non-issue.

We started building Dolphin in 1995 and, when Java floated in on the Internet bubble later that year, our disappointment was palpable. It wasn't just that Java was getting very big, very fast and was obviously going to make it harder to sell Dolphin to the masses. It was more that, really, the designers had just missed the point. Or at the very least they had missed an opportunity. Yes, they had a virtual machine and garbage collection, which was more than C++ ever did but what about all that other stuff they could have taken from Smalltalk? What about dynamic typing? What about keyword selectors to aid readability? What about proper Reflection? What about "Everything is an object"? Heck, you couldn't even add two Integers together. It was very sad.

Then to make matters worse, the computer science academia started to be seduced by the money that was available for making Java better. Blair and I attended all of the OOPSLA conferences from 1997 up until 2004. How many papers did we see on Java garbage collection or generics? All this stuff had either been done 10 years before or shouldn't have been necessary anyway. None of it seemed to be advancing the state of computer science. During that period, Smalltalkers were a painful bunch to be around.

With the advent of .NET, I must admit we thought it was all going to change. Here was a virtual machine that was designed to run multiple languages using a common "object" model. Okay, it only ran on Windows but, hey, so does Dolphin so we weren't too unhappy. But where was all that good stuff again? Yes it's all marginally better than it was with Java but, really, writing a performant Smalltalk on top of the current CLR is just impractical.

Are things looking up? It seems that Ruby is getting a good deal of attention these days. It's a dynamic language very much like Smalltalk and has a lot to offer. It is missing a decent IDE and they retain the rather pedestrian non-keyword language syntax but, basically, it's a lot like Smalltalk under the covers. The great thing from our point of view is that, if you like Ruby you are pretty well sure to like Smalltalk so, hopefully, we're about to get a new influx of dynamic, everything is an object, programmers and that can only be a good thing for Dolphin and for computer science. It's taken 25 years but we're nearly back there.

So, maybe we are Swimming against the Tide but this is to be expected. As computer scientist Howard Aiken said, "Don't worry about people stealing your ideas. If the ideas are any good you'll have to ram them down people's throats".