The state of GUI Frameworks in today’s Smalltalk IDEs

Over on the VisualWorks NC mailing List, Marten Moostert started a thread on the current state of GUI frameworks on VisualWorks that has motivated quite a few people to jump into the discussion. The discussion now goes on in at least two more threads on the same list.

To sum up a bit what people are complainig about is that the current hype towards Web Technologies, especially seaside, might lead to the fact that Cincom has throttled their focus on medernizing their GUI frameworks quite a lot. A reason for additional frustration is the fact that Cincom has totally stopped work on their GUI framework for several years, because they were workin on a complete rearchitected GUI Framework named Pollock which was a nice piece of work, but was stopped after a few years, making some customers very unhappy while others were glad not having to rearchitect their applications. The really bad thing, however, was that there was no real visible progress in the old framework, and the new one wouldn’t come (a situation that’s not too unknown to some shops who wanted to rewrite their long-standing Smalltalk systems in Java, but that’ another story…).

To make a long story short, I must say that a standstill in GUI frameworks is not a thing that Cincom has a patent on. It’s a truth in other Smalltalk environments as well. Squeak, Pharo and others have their own chaters in this book. VA Smalltalk is no exception.The last major improvements to the Composition Editor have been made somewhen in the late 90ies, and there haven’t been any new significant widgets for way over a decade. We still have no sorting lists, grid widgets or the like in the base product. There are some add-ons, but even these have their issues when it comes to Vista Theming.

There are some first steps that Instantiations has made: Vista Theming is enabled and the addition of new widgets is on the roadmap for the next few versions.You can make an application look very familiar on Vista (and I guess Windows 7), even with an Aero Look. But still a lot of stuff is a bit OS/2-ish, from the default color scheme to fonts. So I hope we’ll soon be able to build nice-looking and familiar-feeling container details replacements, hopefully API-compatible to the existing Container Details part. The same would be nice for Notebooks. There still are quite a few VA Smalltalk applications around that use emulated OS/2-Notebook parts on Windows XP. Looks strange, but works good for the users. A smooth path for development teams to migrate these to Windows-Tab Strips is overdue, as well as a way to make GUIs platform neutral. By this I mean differences between operating systems or even versions of operating systems in terms of fonts, default spacing etc. Vista uses a completely different font than XP, for example. So layout strategies that can handle font size differences (maybe layout managers) together with a means of setting a window’s font to “system default” are high on my personal wish list.

All of these things are common place in SWT, for example. Not only there, but I take SWT as a special case here because it was architected by the very same people who had worked on CommonWidgets and ExtendedWidgets in VisualAge Smalltalk before. The basic principles in SWT are inherited from VisualAge Smalltalk’s GUI model, and the SWT GUIs are by far the best Java GUIs I’ve seen so far, combined with a lean and clear API which really feels like home for a VisualAge Smalltalker. So the foundation for a modernized GUI model in VA Smalltalk is there, lying in the depths of existing code, these gems “simply” need to be dug out and cut.

Then, there are the long term goals: I would love to see the Composition Editor and WindowBuilder merge into one tool: A GUI builder that produces plain Smalltalk code and supports visual connections. And, of course, supports an up-to-date widget set, like tool bars that can be docked on/off, palette windows, sorting lists, grids and stuff. A useful splitter widget without strange visual effects in the GUI editor and support for wizards would be nice.

The list is long, and the affair is on Instantiations’ agenda.
Let’s see what we’ll get in 9.0 and beyond…

Ah, and I forgot to mention that I’d love to see a Mac version of VA Smalltalk. I mention it here just for completeness πŸ˜‰



5 thoughts on “The state of GUI Frameworks in today’s Smalltalk IDEs

    1. Marten,

      cool. One of the many things that simply fall in the category of things I’d love to look at when I’ve got the time for it πŸ˜‰
      But still: it’s not a Mac application. And, of course, all my mac whining is not so much about not having to use a VM for development, but rather about being able to ship a Mac application written in VAST. There’s not much of a chance that a product which says “first, install WINE, then copy these files there and look at this and that” in the installation guide will be a great commercial success πŸ˜‰

      1. yes, your’re right. But actually with VASmalltal you have only the possiblity to offer desktop based apps for Windows and perhaps Solaris (using the Motif GUI). Both solutions look pretty well. Using the native Linux VASmalltalk would be a pretty bad idea – I mostly now use the wine based VASmalltalk apps. And win under MaxOSX (WineButtler) is pretty well done – but has some NLS problems, which also prevents VASmalltalk starting at the first time.

  1. I agree with you ! They want to give up the Desktop perhaps to concentrate on the WWW, but they will also loose there, because they will not fit into the environments found there …

    VA and VW are bounded in there history and the fear to break compatibility is so big, that they will not move forward …

    I would like to see table widgets – look, what is possible in the .NET area. Powerful widgets with lots of free code ….

    And Mac: did you try to install wine on the Mac and install the Windows based version ???

    1. Marten,

      Wine is not Mac, even if it would run πŸ˜‰

      I don’t see it as pessimistic as you do. They will make progress, but far slower than we wish.

      The “problem” with Seaside and the web is that two or three years back, not supporting web was a sure path to hell for any product. And Seaside was and still is one of the most important attractors for Smalltalk at the moment. So I am in total agreement with Cincom and Instantiations that Seaside has / had to be top priority. Seaside needs to be supported really well in any Smalltalk because it is something that Rubyists and other dynamic language afficionados might stumble upon. And in fact, the number of people who come to Smalltalk and take a look has increased, as far as I can tell, since Seaside is around.

      So I am not saying the vendors should finally stop working on web technologies. But they have to work on the GUIs as well, since rich clients seem to be a trend as well as web.

      And now that Seaside is supported, it is easier to build great UIs for the web in Smalltalk than it is for rich clients (isn’t that ridiculously ironic???). And it is easier to build great web applications in Smalltalk / Seaside that it is in all technologies I’ve seen so far….

      A few years back, Smalltalk was regarded as medieval due to the fact that nobody thought it can do web. How funny…

Comments are closed.