Runar Jordahl - Smallwalk - Comments

Indeed

Wed, 16 Apr 2008 06:05:17 EDT

Comment on Indeed
By Claus

The VSE class hierarchy below Listbox is a very good example how not to do it. It has three to four levels, and accessors and variables are mixed wildly. The method inheritance is interesting as well, for it goes like 3->1->2->3->1 for method calls in a single method. But that is actually good design as it reduces method clutter drastically. But doing the same with instance variables, i.e. having accessors for value but not for list which is actually the more important variable makes subclassing there (I created the ComboBoxEx class below ComboBox) a gigantic headache at first.

So, yes, accessors are definitely necessary for reuse. Though them being absent is not as bad as having a mix.

Re: What about on Mac

Sat, 12 Apr 2008 20:18:10 EDT

Comment on Re: What about on Mac
By Antony Blakey

There are OSX apps from Apple (such as Logic) that don't use the standard OSX widget set, and they don't look ugly. Furthermore, Logic even has window-local menubars, which was originally a reflection of it's cross-platform nature, but has been preserved by Apple because of the enormous complexity of the App and it's interface.

Apple can do this because they have the resources to do it properly, and in the case of Logic people will learn the interface because the application dominates their interface experience (IMO that is not uncommon with audio and 3D apps at least).

But I agree with your point about the tolerance of UI variance differing between OSX and Windows. IMO VW should be designed for OSX and Windows will follow, rather than the other way around.

What about on Mac

Sat, 12 Apr 2008 06:34:40 EDT

Comment on What about on Mac
By Sean McGinty

Thanks to the glut of ugly apps showered on the Windows community in the last 20+ year, yes I agree that you probably don't need native widgets for Windows programs--ones that give a close enough approximation are good enough. However, on the Mac platform, users will expect a certain look and feel to your application. The menu bar must be at the top, the tool bar needs to be a certain size an contain minimal icons, etc. An application that doesn't look like a Mac application will be dismissed quickly. Call it elitist or snobbery if you will but that's the way it is. Even I, a fairly new Mac user and a Windows user at work can spot a migrated-from-Windows application and will quickly dismiss it as being inferior because if the developer hasn't taken the time to make it look good, then they probably haven't put in the functionality a Mac user will expect.

If you have the resources ...

Fri, 11 Apr 2008 20:43:21 EDT

Comment on If you have the resources ...
By Antony Blakey

Sure, if you have MS/Apple/Adobe's resources then you can design and build your own. And along the way you need to add accessibility, internationalization/bidi, scripting etc. And do this on each platform separately e.g. input method support.

The desire to have interfaces that people immediately know how to use by virtue of their familiarity is only part of the issue, and obviously the rise of the web shows that users can largely abstract over the visual appearence of interface elements and recognise their underlying function. However, the non-obvious features of controls, such as the IM support are sufficiently complex (e.g. how to use each IM) that 'rolling your own' is IMO a very bad idea. Even worse is to build controls that ignore such requirements. That approach dramatically reduces both the comprehensiveness of the UI, and the ability to leverage other OS features such as scripting support.

VisualWorks and Flex

Tue, 08 Apr 2008 03:47:52 EDT

Comment on VisualWorks and Flex
By Runar Jordahl

Denis: I blogged about VisualWorks and RIAs a while ago. What I would like to see is FLEX as an ultra light client for the Smalltalk image: http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=VisualWorks_and_RIAs&entry=3372591042

The future is not native widgets or SWT

Tue, 08 Apr 2008 01:18:24 EDT

Comment on The future is not native widgets or SWT
By Denis Johnson

I feel that the typical end user has moved well beyond the issues that once seemed like a good justification for native widgets. While common interaction and behaviour has obvious merits, many web UI's and the general future of UI's is for fluid, skinable, composable, extensible & flexible interfaces with transparency, transition effects and animation. While there is also a lot to be said for simple minimalist UI's, IMHO any application that simply uses the native set of widgets will not gain any bonus points from the typical end user who has become accustomed to anything but standard UI's on the web.

For one reason or another we have lagged behind even standard interfaces in Smalltalk. To some extent we have got away with it in the last two decades, but IMO the lack of state of the art UI framework is now a major hindering factor. So much so that in my case unfortunately it was the key tipping points not to use Smalltalk in a recent project. While SWT is certainly responsive and well behaved in terms of native fidelity, even it is a far cry from where I believe we need to be. There are other cross platform frameworks including Qt but they also do not represent enough of a step forward. While Seaside is most welcomed and impressive when compared to other legacy technologies for web development, I feel it in itself is not enough either.

I have been coding VW GUI's including my own Wrapper based widgets for 15+ years, however to date the best UI framework that I have used is Adobe Flex. It has all the above mentioned properties and it runs within the browser or on the desktop. Further, the player has managed to become a standard browser plugin, even in corporate environments, so distributing/upgrading your application across the web is simple. Try getting a corporate IT department to allow users to install other plugins. Even if you manage to get the Smalltalk plugin installed, you end up with an ordinary UI. However, the underlying language in Flex is ActionScript and the associated code development tools can't hold a candle to what we know and love within the Smalltalk image.

Without really contemplating the practicalities and effort involved, IMHO the penultimate would be to somehow allow Smalltalk to leverage the existing Flex UI engine & framework. Server side interaction is important to many people, but I don't always need or want to run a server and instead simply want host an application and its data off Amazon S3 or the like. So this capability would ideally also work as a complete within browser solution, perhaps some small stub Flex application calling out to VW as a DLL or the like. That way all my business and domain logic could be implemented in Smalltalk while leveraging the kick ass UI's that flex can produce. There are many many developers out there producing excellent quality open source flex widgets and extensions. Because of its heritage (flash), it has managed to bring along all the designers and graphic artists from the more traditional realm of the web. All of this and future enhancements can be leveraged without further cost or resources at Cincom or even within our limited Smalltalk community.

Anyone else feel there is any merit and feasibility in such an approach ?

cheers Denis

QT isn't an option IMO

Mon, 07 Apr 2008 20:15:34 EDT

Comment on QT isn't an option IMO
By Antony Blakey

I looked at doing exactly what you suggest. I wasn't considering anything other than widgets, and I decided that linking to another emulated widget set wasn't worth while if all you are wanting is the widgets. There are licensing issues with a GT/VW combination and it's C++, which would require quite some work to bind given the current state of DLLCC. It's just not enough of an improvement.

I think that using SWT would be a better alternative. At least then you have native controls. But ultimately, with a good version of DLLCC (say using LLVM) coupled with the ObjectiveC 2.0 Runtime package, it should be possible to do a completely native, cross-platform UI in VW. I looked at doing this for OSX when I first did WebKit integration, and it's a feasible spare time project (of which I have too many).