For some people James's announcement to discontinue Widgetry came as a shock - to many others, not so much. I've got a long history with Widgetry/Pollock. When it first started to appear, it was 'obvious' to me that this old "wrapper" thing was dead and I should start the effort to port WithStyle to the Pollock framework away from Wrapper.
I'm going to have to be a bit mind-blah about this post, I'll jump around the place. The whole naming of the existing UI toolkit in VisualWorks as "Wrapper" is a wonderful piece of propaganda. At some point in the past, it was decreed that Wrapper was busted and couldn't be fixed, thus a new effort was born - Widgetry. A complete rewrite.. complete. There are obvious problems with this. For one, it could take a while to do; two: it deserves a significant set of resources; for three: all of VisualWorks' IDE will have to be rewritten, even if there is a reasonable porting path forward; four: all our clients would have to rewrite their UIs too.
As we can see from James's post, the major cost in continuing with Widgetry was points hree and four. And to a large extent, point one as well. It has been a long time coming and even now Widgetry suffers from some of the most obvious bugs, this is due mostly to point two - essentially only Sam worked on Widgetry for these last six years. That's quite an effort for just one guy.
So now we're in a situation where we have a large framework that has issues just like the old framework, has some advantages and some disadvantages - the two frameworks become sort of even when you look at them holistically - and yet the new framework is still begging for more money. I can see how the decision was made.
Recently, I had a very positive "Wrapper" experience - by god I hate that name, it's a wonderful piece of propaganda - you can hear the clumsy music playing in the background every time you say it, "Uh duh, wrapper, let's, uh, wrap things." At Travis's suggestion, I stopped using the UI Builder and specs and actually made a subclass of VisualPart and just -wrote- a widget.
The result of this venture? SmallSpotlight. I can save without a doubt that I've never gotten as much positive feedback for a tool in my whole life as I have for SmallSpotlight! There are still many things I want to do with it before I'll ask it to be integrated in to VisualWorks, but the programming experience was positive.. I just made my subclass and 'went at it' and the results were a very snappy, visually appealing, fast, non-flashy widget. This seems contrary to the opinion about Wrapper that it looks old, clunky, flashes a lot and is slow.
As Travis points out, the issues with Wrapper are not so much in its design, but its use. There are several widgets that write directly to the graphics context without a care for graphical inheritence - which doesn't work on any platform except win32. Because of the way they do this, they get around any double buffering efforts that may be taking place at the Window level. This is one of the major causes for 'flicker' and, to be honest, would be pretty easy to fix.
The other major issue I have with Wrapper is that its emulation of widget -behaviour- is very 'off'. Lists, for example, treat selection and drag and drop differently to any other UI environment on the planet. Selection is always a toggle-list, which is very counter intuitive. Dragging requires you to start with no selection, otherwise the click to drag will do a deselect. Crazy stuff and also quite fixable.
I'll start heading this post back toward WithStyle now and see if I can get there. The major stumbling block for Software WithStyle using VisualWorks to make WithStyle was multimedia. VisualWorks still, to this day, has dreadful graphics support. There are only a select few kinds of graphics formats it will successfully load up - and if you want >1 bit transparency, tough. Well, sort of - Epigent made a way to draw PNGs properly, but it's a hack, doing all the work in image to blend.. neat, but slow.
That and fonts. Fonts on Linux really are dreadful. But let's face it, Widgetry was never going to fix these two issues. There were plans to fix these issues after Widgetry was 'done'. Widgetry still has a ways to go before it'll get there, so these issues are 'on hold' until we can get there. In many respects, ending Widgetry gives us hope that may be these issues will be resolved sooner rather than later.
What about Native Widgets? Well, those are pretty hard and nasty. Even Microsoft Office avoids them :) .. but let's be fair, that's another giant project the size of Widgetry and no one has even begun to work on it. It's pretty clear that from a customer-relations point of view, giant all encompassing projects are a bad idea. You have no idea how they're going to turn out unless you can get production ready code in to the hands of your users in under a year. Get them a beta in six months and you're well on track - that's the agile way.
So, when we decided to add widget support to WithStyle, embedded widgets for forms and for reuse of existing other VW components, we naturally tried to hook up to things using specs. The underlying layer was as mysterious to us as cross-platform register optimization. We failed, to put it bluntly. Widgetry, on the other hand, had a simpler composure and event model, so it was again 'obvious' that we should port to Widgetry. As some of you may have noticed, we never got there.
Time to take a step back, try something else with Widgetry that wasn't as hard. So James Robertson and I made a Twitter client called Swallow. It was at this point that I noticed, using Widgetry at the highest level - as a regular programmer aught too - was very hard. I may as well be writing reams of xml and css for all the APIs gave me in Widgetry. The bugs showered down too.. but hey, in the end we got Swallow to work and that's all that matters. Never mind the awkward layout framework I had to make to make it happen.
Okay, I don't want to sound bitter or anything, but for all the Widgetry hype, I'm trying to point out that both Wrapper and Widgetry have their own kinds of suck. From a strategic point of view, if you take Widgetry and Wrapper, both have issues and both want money. Here's "now" onwards:
Wrapper, lots of issues + A money to fix them + Bmoney to migrate as changes are made
Widgetry, lots of issues + X money to fix them + Y money to migrate as changes are made + Z money to migrate existing applications + Q money to migrate client applications
So the equation is simple, is A + B > X + Y + Z + Q. It's hard to argue that the Widgetry approach would be cheaper in the long term. I think I'm getting off track again. Why am I trying to justify the message from product management? I don't know. I've been a long time user of both frameworks now.. so I'll just get back to the engineering message I'm trying to convey and stop trying to play another propaganda game.
So we had WithStyle, we couldn't integrate Wrapper widgets in to it well. I gave a presentation in 2005 that demonstrated the first attempt I had made to integrate Wrapper widgets in to WithStyles rendering engine. I could successfully drop a Wrapper widget in to the screen, have it flow with the layout. Cool! - I couldn't, however, push events down to it successfully. The event model in Wrapper just plain sucks. Queue huge benefit of Widgetry - Announcements.
Announcements is so good, in fact, that I've noticed two engineers here in Cincom pushing them in to Wrapper already.
So what, that's it? I swapped UI frameworks just because I couldn't grok the event model in Wrapper? Sadly, yes. And in the end, the Widgetry version of WithStyle never made it out the door. It was too complex, too bulky and too much of a rewrite. Yes, I was an early adoptor of Pollock/Widgetry and yes WithStyle really got 'under the hood' of Widgetry, but for me that's where Widgetry failed WithStyle. Low level work is what I was doing and Wrapper made that a pleasure.. Widgetry is very focused on the high level APIs - giving you lots of switches to changes colours, frames, etc.
Yet, I criticized this high level API above in my Swallow example too. So let's be fair and have another go at Wrapper. The high level APIs in wrapper are -incredibly crap-. This underlying *fact* should not be forgotten. You may as well not have them in Wrapper, because writing code like:
(builder componentAt: #thing) widget controller continuouslyAccept: true
or some of my less favourite code:
(builder componentAt: thing) container container container container value
Pretty bad. How do you toggle whether a widget is on or not - let's just not go there right now. There have been efforts to fix up some of these bad APIs in Wrapper. Notably Arden Thomas has a whole framework to simplify all this stuff. Why isn't it integrated? Well, to be brutally honest, the propaganda against Wrapper was pretty damn good back when it was introduced. Work on Wrapper ceased - but really, it had stopped a long time before then as no one understood it and no one wanted to touch it.
But something much MUCH worse happened waiting for Widgetry. Work on the tools basically stopped. Why invest more time and effort in to tools that have to be rewritten? .. as a customer I looked on in agony as all the little bugs quirks and annoyances I had with the environment, continued to persist release after release after release.
I've seen some angry responses to James's post about ending Widgetry. To my amazement, I'm seeing the anger directed along the lines of "You spend 6 years making Widgetry, didn't fix any of the stuff I cared about in that time, and now you're dropping Widgetry, how could you!?"
This seems like an irrational argument to me. Management somewhere really screwed the pooch when Widgetry started. One guy? Hold all other UI projects while one guy does all this work rewriting the lot from scratch without fixing the low level graphics capabilities of the product first? Yep, it was a recipe for disaster - an unintentional one though. As a result, the product IDE and graphics capabilities -have- stagnated.
My hope is that with the requirement on waiting for Widgetry and porting to Widgetry gone, we'll see some real improvements on the existing UI framework and widgets and tools. Incremental is better than big bang.
So finally, what cool things can we take from Widgetry:
- Announcements without a doubt
- Built in coordinate system in each widget as Travis explained
- Emulating widget behaviour is what makes a UI feel 'native', not just the look, fix up widget behaviour
- Don't draw directly to the graphics context - ever, this is what Sam called FlickerFree(tm)
- You can make a lot of UI tests, it's hard, it's even harder doing it cross platform (We learnt this writing WithStyle too), and in the end you'll still have lots of bugs
- Big rewrites are a bad product strategy, incremental improvements are better
I'm interested to see where we go from here. May be I should dust off WithStyle3 and give it another guy.. if I had time that is.
Now, back to Seaside! To the web and beyond!