Widgetry is dead, long live Wrapper!

This is great news! Finally, the ban has been broken and the real development and improvements for the UI is starting in earnest - hooray!

 

Quote Jim:
# New and better widgets, incorporating some of the enhancements made in Widgetry
# Improved UI building tools - the painter tools will get updated and improved incrementally
# Improvements to the framework itself - many of the known issues in the underlying UI libraries will be incrementally addressed

 

Now we finally will get drop-down-lists and input fields in toolbars - great!
Yes, finally we get a proper widget for tables - yippie.
The Tab-control will easier and the builder can be used without a deep understanding of the interna of the framework - super.

Now we finally will get look-and-feel changes without programming the relayouting by hand anymore - wonderful.

and much more...

Now, since that the golden times for UI programmers have come and the framework will be improved, the other tools in the system will not need all the overrides anymore (help: 13, wave: 18, (Aragon: 7)).
Otherwise, all the overrides would have to be maintained and changed when the great new improvements are coming. Fortunately, customers never needed to override anything in the UI, so that code will not break - puh, lucky! ey?.

Now we will get for all conceivable UI events the change notifications, the triggered events and the announcements - super! Plenty to choose from. Oh wait, announcements are part of Widgetry, right? So they get dropped too - good, we dont need objects everywhere, really. Oops, just saw that Michael likes announcements and they should be in wrapper - there will be a rewrite them... hmm lets see how announcements are incorporated incrementally (hi hi).

Now that the resources have been freed off Widgetry, the wonderful improvements will start to come in big leaps since now there are 2 people(!) for tools and the UI framework who can really concentrate on the customers interest.

 

Some enlightening posts are on the blogs. For example Travis (http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&entry=3366939116):
"It's got some ugly code in it. Code written by junior Smalltalkers who passed through the halls of ParcPlace and its other names, code that was never cleaned up."

 

Good that this is not among the 2 problems Travis identified (1. widgets dont know their position and 2. no good way to build the UI using code).
But this bit of fix-up cant be that bad, it just needs to be improved incrementally. And we will be surprised to find many problems sufficiently improve over the years - this is just so delightful.

 

Also Michael (http://www.cincomsmalltalk.com/userblogs/mls/blogView?showComments=true&entry=3366953961) has interesting thoughts:
"From a strategic point of view, if you take Widgetry and Wrapper, both have issues and both want money"

 

Thats like saying a mouse is small and an elefant is small (from a very strategig perspective)...
There are/were problems with widgetry and they are/were small. Ususally they are/were fixed in the next publish - often on the same day.
There are problems with wrapper and they are big. Usually they get AR-ed and nobody hears from them anymore. For many wrapper issues the typical response was "we cannot do anything about it, because we do not dare to touch the code since client code will break".
Therefore: from a strategic point of view wrapper and widgetry both have indeed problems. QED

Michael again (now algebraic):
"Wrapper, lots of issues + A money to fix them + B money 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"

 

Where are the wrapper parts of the equation? C money to migrate existing applications + D money to migrate client applications (since all the cool improvements are coming now and for the next couple of years).
I am confident that the management (or at least Michael) has a clear idea about these A, B, C, D, X, Y, Z and Q factors. I'd love to know more about them.

 

"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."

 

Now this is the answer! (and we learned something about propaganda along the way :-).

"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"

 

All these things exist and work in Widgetry. And it will be done again in Wrapper - super idea, because it will be done incrementally, yeah!

 

 

Again Hooray, Hooray, Hooray for such a bold move and to a bright future for UIs in VW!

 

Grateful,

    Christian

 

-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@...
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

After waiting 5+ years for Widgetry, why on earth would we expect that after waiting 15+ (someone will know the real time) on wrapper, the improvements will come soon?  The time is long past to be concerned.

On Sep 11, 2007, at 1:58 PM, Dennis Smith wrote:

I will get concerned if wrapper does not get some siginificant improvements soon -- including
    updated looks

-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              [hidden email]
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.

Folks,

 

IMHO, the decision to drop Widgetry is going to have some serious side-effects.

 

Namely, the Smalltalk evangelists in the world (meaning us) always claim that Smalltalk offers a huge productivity advantage over any other language.  We all say this, all the time.  But dropping Widgetry makes it very easy for detractors to label that as a false claim.  Their question will be:  "Why did Cincom, the owner of the product, with the best Smalltalk engineers on the planet, spend six years attempting to rewrite the User Interface components, and fail at it?"

 

There really is no answer to this, other than corporate spin.

 

I'm interested in everyone's take on this.

 

--Tom

 

 

 

 

 

---

From: Dennis Smith [[hidden email]]
Sent: Tuesday, September 11, 2007 6:10 PM
To: Mike Hales
Cc: [hidden email]
Subject: Re: Widgetry is dead, long live Wrapper!

As long as pollock/widgetry was on the horizon, you would not expect enhancements to wrapper.

A number of years ago, cincom (then parkplace and/or objectshare ??) was in some difficulty -- they changed
direction and did do some significant improvements to wrapper -- so I see no reason why not this time.


Mike Hales wrote:

After waiting 5+ years for Widgetry, why on earth would we expect that after waiting 15+ (someone will know the real time) on wrapper, the improvements will come soon?  The time is long past to be concerned.

On Sep 11, 2007, at 1:58 PM, Dennis Smith wrote:

I will get concerned if wrapper does not get some siginificant improvements soon -- including
    updated looks

-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              [hidden email]
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

---

NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.

Well, some projects can't afford the dedicated gemstone dba that any sizeable repository will require and certainly this is not on any of managed providers lists, whereas there's a lot of relational database expertise out there in comparison. Simplest thing that could possibly work if you like. Then you get into issues like fault tolerance (mirroring is part of 2005 sql, easy to set up), backups (all commercial systems like arcserve support sql server) and other things that smaller shops like us just don't want to figure out all over again. Once running sql server is really almost maintance free when used with caution. That's not to say you couldn't do that with gemstone, but I remember life being a little more involved.

Cheers!

-Boris
(Sent from a BlackBerry)

----- Original Message -----
From: Joseph Bacanskas <[hidden email]>
To: Antony Blakey <[hidden email]>
Cc: VWDEV List <[hidden email]>; vwnc <[hidden email]>
Sent: Tue Sep 11 22:27:15 2007
Subject: Re: Widgetry is dead, long live Wrapper!

Hi Anthony:

On Sep 11, 2007, at 10:08 PM, Antony Blakey wrote:

>
>
> On 12/09/2007, at 2:17 PM, Joseph Bacanskas wrote:
>
>> Instead of understanding the need for synergistic cooperation 
>> (what can we do to make our products work better together), they 
>> lamely go on about Seaside and Glorp.  Seaside and Glorp will 
>> never perform, or will never be easy to maintain.  If you model 
>> objects, you have impedance mismatch.  If you model "data objects" 
>> you have convoluted design and brittle mapping.
>
> But if you must use a RDBMS, surely GLORP is the best thing you can 
> use. Cincom aren't going to make good decisions by presuming that 
> OODBs are about to take over.

Cincom must focus on the profit they must make in order to remain 
viable.  I suggest you ask them to list percentage of income from 
OODBMS projects that have VW clients and percentage of income from 
RDBMS projects that have VW clients.  I think you will find the 
proportions sobering.

>
>> As much as I love VW, I say to Cincom Smalltalk Product management 
>> an old yiddish saying... "Be a mensch!".  And please consider how 
>> you can work with those vendors who help you be successful; and 
>> stop wasting time and money trying to be a "server product"... you 
>> aren't and you have *way* too much catching up to do.  That is a 
>> hard and bitter pill to swallow, but swallowing it might bring you 
>> back to health.
>
> No No No! Not every project can afford to use Gemstone, financially 
> and/or politically. Many projects must use a RDBMS. While I wish 
> Cincom weren't spending resource 'supporting' Seaside that could be 
> spent fixing core issues, I absolutely want a better server 
> product, which to my mind means, in particular, fully supported 
> GLORP with documentation.

I'm baffled, what "server product"?  GLORP is an OR mapping tool. VW 
is not in any way a server, meerly a conduit.

Maybe I'm prejudiced, but I don't really understand how any Smalltalk 
project requiring persistence can afford *not* to use GemStone.

>
> Antony Blakey
> --------------------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
>
> Hi, I'd like to do $THING. I know that $SOLUTION_A and $SOLUTION_B 
> will do it very easily and for a very reasonable price, but I don't 
> want to use $SOLUTION_A or $SOLUTION_B because $VAGUE_REASON and 
> $CONTRADICTORY_REASON. Instead, I'd like your under-informed ideas 
> on how to achieve my $POORLY_CONCEIVED_AMBITIONS using Linux, duct 
> tape, an iPod, and hours and hours of my precious time.
>   -- Slashdot response to an enquiry
>
>

Thanks!!
Joseph Bacanskas [|]
--- I use Smalltalk.  My amp goes to eleven.

On Sep 11, 2007, at 19:08, Maarten Mostert wrote:

Sure this really becomes a situation which scares me.

Today we talk Wrapper and Widgetry but what about Cairo like graphics ?

No plans no vision ?

I can speak to the Cairographics "plan" specifically. I'll leave the Cairo _like_ graphics to others. This is my thoughts only, not even a plan. These don't represent Cincom's, for all I know they're diametrically opposed. :)

The Cairo work is a lot like Glorp. Some Cincom guy who spends his off hours (and some of his do interesting stuff 20% of the time) working on it. Cincom has been kind enough to sponsor my attendance at StS and ESUG so that I could show what I've done with it. There's nothing stopping Cincom from throwing 100% dedicated bodies at it (myself or others), OTOH, I enjoy the freedom to take it slow and correct and not be burdened with marketing expectations. I enjoy the fledgling community that has grown around the effort. I enjoy the larger Cairo community in general. It's much like the GLORP project.

I did not start working on Cairo as a replacement system for VisualWorks graphics. It was fun and entertaining; I was in search of good looking fonts on Linux/X11 since it didn't look like they were coming any time soon (I also like to jokingly blame Randy Coulman because I made this really cool page turning widget but he vetoed it because the lack of AA lines made it look "bad" :) ). Once I began drawing with it, I found I loved drawing with it. It made doing graphics in Smalltalk fun again.

Somewhere along the line, I realized I had accomplished one of Sam Shuster's projects, at least in part. I had built a graphics thing which did modern drawing, and more important, all of the graphics code was out of the VM (this was only part indeed, as Sam's hope was to not only bring drawing out, but things like event and window management as well). And at that point I began to wonder, could this indeed be a real solution for VisualWorks? I still don't know. I've been afraid to commit on that one. The safe course has seemed to keep charging ahead, not _having_ to have it be the solution and force egregious hacks in to reach a ship date. I've tried to remain emotionally removed from the idea as well. I don't want to get attached to the idea, and then start discovering major show stopper bugs and have to reconcile those. My ultimate happy ending is that I keep hearing the happy success stories I usually hear so far. And that eventually, they've amassed to such a pile, supporting it/integrating it is just obvious. Again, similar to the path that Glorp has taken. I was thrilled when someone at ESUG, (whose name is slipping me, Ole?) had some simple GDI+ interface for VW, and switched it to use Cairo and found the speeds and output comparable. I like those stories.

There are some ironies that are not lost on me. Part of me is not interested in backwards portability to the old GC APIs at all. I like the new ones better. They run circles around what the old did. The irony of course, is that this kind of issue is at the core of the Widgetry thread which this has spun off of. So I find another part of me being excited about the work that they EyeSee guys did, and even more completely, the work that Joachim has done recently. I think it might be kind of possible. It's still not preferable to me for a variety of reasons, but from a bootstrap old code, I see it more and more. One of the saving graces as well, is that the two frameworks are happily coexistent. You don't NEED to make the switch completely. You can have a VisualPart which does half of it's drawing with Cairo APIs and half with GC APIs. So incremental adoption and use is not an issue.

My near term effort with Cairo is in a couple of areas. I would love to start writing more code that leveraged Cairo code. But I'm reticent to do that, since we don't have a solution for OSX yet. Hopefully this week? Once that happens, I'm willing to start doing more. Like possibly building a L&F that uses Cairo. And other such things that help ferret out those kind of showstopper issues that we wonder about. My other goal is to become even more involved with the Cairo development process. It's one thing to use it. But good community relationships (and as a side affect, good publicity for Smalltalk) come from giving as well as taking. I've nearly got my windows box set up so I can build cairo libraries there and I intend in my copious free time to do a conical gradient for Cairo. This would be good for us (it's a very handy way to do "shading"). It's good for the Cairo community and all the other languages that bind to it. It's good for applications like Inkscape. Which makes it so I can draw prettier icons for thinks like the inspector.

As a last reminder, this isn't a Cincom promise or plan. It's a guy who works for Cincom, talking about an open source development effort he participates in. So when I change my mind or give up, you can get mad at me, but not Cincom. :)

Back to the RB CodeTool work now. :)

--

Travis Griggs

Objologist

"Dying men never wish they'd spent more time at the office"