Alan Kay's EuroPython Keynote

> Stef....
>
> On Jul 8, 2006, at 12:43 PM, stéphane ducasse wrote:
>
>> I can understand and I'm sorry that we have nothing to offer.
>
> I certainly wouldn't go THAT far! For example, I'm spending some  
> serious time with Seaside this weekend. I need a Web app framework  
> for a series of upcoming projects. For those projects, native  
> widget look-and-feel is absolutely irrelevant. I like the  
> architectural ideas behind Seaside but I'm still at the very early  
> learning stage, so I'm not yet sure it's as usable and powerful as,  
> e.g., Django (Python) or TurboWidgets (also Python strangely  
> enough). I've tried Ruby on Rails and found it too opaque although  
> extremely powerful.

>> But may be you could check vwxWidgets or the GTK binding and start  
>> from there.
>
> I've been in touch with Rob on wxSqueak and have done some  
> experimenting with it on OS X. I plan to get it running on Windows  
> soon and see how it looks and feels there. That may be the ultimate  
> solution for a lot of what i want to do on the desktop, but for the  
> near term, that won't satisfy my clients and colleagues because the  
> wxSqueak stuff isn't yet ready to release.
>
> Dan (Still a Squeakin')
>

> Dan,
>
> My 0.4 release was reasonably solid for Win32, but the Mac version
> wasn't as good (partly my fault, partly the state of wxMac 2.5), and the
> Linux version wasn't really usable. I'm hoping that the 0.5 release
> (coming RSN) will work well on all three platforms.
>
> As for all of the other discussion about wx/gtk/Spoon, I liked Cees'
> response the best: Why one UI? There are pros and cons to any UI
> toolkit, so the more options there are for Squeak, the more
> opportunities there will be to use it. My goal with wxSqueak has been to
>  keep it compatible with the latest release of Squeak, with minimal VM
> changes, and maybe eventually no VM changes at all. And ultimately, it
> should work fine with Spoon. But I think it should always be an add-on
> package to some Squeak/Spoon core.
>
> .. Rob
>
> Dan Shafer wrote:
>> Cees.....
>>
>> I am going by what Rob said about it. He advised me not to rely on it  
>> for a project just yet, but I think he's actively working on it again.
>>
>> Your news is encouraging. Perhaps Rob is being overly cautious.
>>
>> Dan
>>
>> On Jul 8, 2006, at 2:59 PM, Cees De Groot wrote:
>>
>>> On 7/8/06, Dan Shafer <[hidden email]> wrote:
>>>
>>>> That may be the ultimate
>>>> solution for a lot of what i want to do on the desktop, but for the
>>>> near term, that won't satisfy my clients and colleagues because the
>>>> wxSqueak stuff isn't yet ready to release.
>>>>
>>> Why not? Did you test it? Find issues?
>>>
>>> I used it for a project last year, and whatever problems we had, they
>>> weren't wx-related...
>>>
>>
>>
>>
>
>
>

>
> Rob Gayvert a écrit :
>
>>Dan,
>>
>>My 0.4 release was reasonably solid for Win32, but the Mac version
>>wasn't as good (partly my fault, partly the state of wxMac 2.5), and the
>>Linux version wasn't really usable. I'm hoping that the 0.5 release
>
>
> I noted the Linux version is a bit slow (I cannot compare to the other
> version).
> Is it related to Squeak or is related to wxWidget?
>
> At least in the Linux  version, AFAIK, with wxWidget you have two levels
> of indirection:
>  wxWidget <--> GTK+ <-->Xlib
> It may also explain why it seems slow.
>

> Hi Rob
>
> Last time we talked, you told me that you were using wxSqueak as a
> target platform for a legacy VSE application. Are you able to say how
> that port is going?
>
> Cheers
>
> Daniel Poon
>
> Rob Gayvert wrote:
>
>> Dan,
>>
>> My 0.4 release was reasonably solid for Win32, but the Mac version
>> wasn't as good (partly my fault, partly the state of wxMac 2.5), and
>> the Linux version wasn't really usable. I'm hoping that the 0.5
>> release (coming RSN) will work well on all three platforms.
>>
>> As for all of the other discussion about wx/gtk/Spoon, I liked Cees'
>> response the best: Why one UI? There are pros and cons to any UI
>> toolkit, so the more options there are for Squeak, the more
>> opportunities there will be to use it. My goal with wxSqueak has been
>> to  keep it compatible with the latest release of Squeak, with minimal
>> VM changes, and maybe eventually no VM changes at all. And ultimately,
>> it should work fine with Spoon. But I think it should always be an
>> add-on package to some Squeak/Spoon core.
>>
>> .. Rob
>>
>> Dan Shafer wrote:
>>
>>> Cees.....
>>>
>>> I am going by what Rob said about it. He advised me not to rely on
>>> it  for a project just yet, but I think he's actively working on it
>>> again.
>>>
>>> Your news is encouraging. Perhaps Rob is being overly cautious.
>>>
>>> Dan
>>>
>>> On Jul 8, 2006, at 2:59 PM, Cees De Groot wrote:
>>>
>>>> On 7/8/06, Dan Shafer <[hidden email]> wrote:
>>>>
>>>>> That may be the ultimate
>>>>> solution for a lot of what i want to do on the desktop, but for the
>>>>> near term, that won't satisfy my clients and colleagues because the
>>>>> wxSqueak stuff isn't yet ready to release.
>>>>>
>>>> Why not? Did you test it? Find issues?
>>>>
>>>> I used it for a project last year, and whatever problems we had, they
>>>> weren't wx-related...
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

> Unfortunately, rather slowly. Right now I'm just focused on getting to a
> stable wxSqueak base.
>
> .. Rob
>
> Daniel Poon wrote:
>> Hi Rob
>>
>> Last time we talked, you told me that you were using wxSqueak as a
>> target platform for a legacy VSE application. Are you able to say how
>> that port is going?
>>
>> Cheers
>>
>> Daniel Poon
>>
>> Rob Gayvert wrote:
>>
>>> Dan,
>>>
>>> My 0.4 release was reasonably solid for Win32, but the Mac version
>>> wasn't as good (partly my fault, partly the state of wxMac 2.5), and
>>> the Linux version wasn't really usable. I'm hoping that the 0.5
>>> release (coming RSN) will work well on all three platforms.
>>>
>>> As for all of the other discussion about wx/gtk/Spoon, I liked Cees'
>>> response the best: Why one UI? There are pros and cons to any UI
>>> toolkit, so the more options there are for Squeak, the more
>>> opportunities there will be to use it. My goal with wxSqueak has been
>>> to  keep it compatible with the latest release of Squeak, with
>>> minimal VM changes, and maybe eventually no VM changes at all. And
>>> ultimately, it should work fine with Spoon. But I think it should
>>> always be an add-on package to some Squeak/Spoon core.
>>>
>>> .. Rob
>>>
>>> Dan Shafer wrote:
>>>
>>>> Cees.....
>>>>
>>>> I am going by what Rob said about it. He advised me not to rely on
>>>> it  for a project just yet, but I think he's actively working on it
>>>> again.
>>>>
>>>> Your news is encouraging. Perhaps Rob is being overly cautious.
>>>>
>>>> Dan
>>>>
>>>> On Jul 8, 2006, at 2:59 PM, Cees De Groot wrote:
>>>>
>>>>> On 7/8/06, Dan Shafer <[hidden email]> wrote:
>>>>>
>>>>>> That may be the ultimate
>>>>>> solution for a lot of what i want to do on the desktop, but for the
>>>>>> near term, that won't satisfy my clients and colleagues because the
>>>>>> wxSqueak stuff isn't yet ready to release.
>>>>>>
>>>>> Why not? Did you test it? Find issues?
>>>>>
>>>>> I used it for a project last year, and whatever problems we had, they
>>>>> weren't wx-related...
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

> I (and other people on the VSE list) would be interested in some of  
> the technicalities of the port when you have the opportunity to  
> comment.
>
> In particular, I was would like to know if you have automated the  
> translation of the #createViews, or whether you ported the window  
> layouts and events manually. Ive speculated that it would not be  
> that difficult to hack WindowBuilder to output different code to  
> target another platform, like wxSqueak. Thats one project that I  
> would sign up for.
>
> Wouldn't it be a great start for wxSqueak if you could offer an  
> upgrade path for all those VSE applications out there!

> I think the problem here is that the audience I have in mind are  
> developers but who must: (a) feel some comfort level with the tool  
> they use; and (b) who are concerned that the unusual user experience  
> of the Squeak IDE presages such unusualness in their developed  
> applications. SO the line is not so nearly clean as you interpret or  
> as I may have mistakenly led you to believe.
>
> Dan
>
> On Jul 7, 2006, at 2:37 PM, Chris Muller wrote:
>
>> Your original question mentioned IDE's Dan:
>>
>>>>> almost toy-like user experience in the IDE? Is it the case that
>>>>
>>
>> therefore I thought the audience you were referring to were  developers.
>>  For developers I am less-tolerant of their whining about look (but  not
>> feel, because Nicolas Cellier's points are excellent).
>>
>> But since you have clarified you apparently are talking about
>> *end-users*, I'd like to clarify, I think, for end-users look is much
>> more important than for developers.
>>
>> But I doubt native/standard/whatever look alone will be enough  because,
>> as I mentioned, IBM's VisualAge Smalltalk had native widgets PLUS tons
>> of interfaces to major business systems (even CICS!) that no Smalltalk
>> will probably ever have again.
>>
>> I think Cees nailed it, its so hard to overcome the anti-marketing
>> forces.  IBM was selling their VA Java product for half the price of
>> their VA Smalltalk.  Its amazing VAST lasted as long as it did.  I'm
>> sure they were gratified (again) to sell the small interim-step in
>> technlology (VAJ) as a huge wave of revenue.  But I think they made a
>> big mistake, now where are they gonna go?
>>
>> Better looks will never hurt though..
>>
>>
>> --- Dan Shafer <[hidden email]> wrote:
>>
>>>
>>> On Jul 7, 2006, at 12:50 PM, Chris Muller wrote:
>>>
>>>>> Why, after 30 years, does Squeak still appear to be a
>>>>
>>> non-standard,
>>>
>>>>> almost toy-like user experience in the IDE? Is it the case that
>>>>> changing that would be far too complex to undertake? Or is it that
>>>>> the community of Squeak users just isn't largely motivated to
>>>>
>>> worry
>>>
>>>>> about this subject? Or is the absence of an economic incentive the
>>>>> problem? Or IS there a problem?
>>>>
>>>>
>>>> 1.  What does that really mean, looks toy-like?  What's it gonna
>>>
>>> take,
>>>
>>>> please tell us?  A manly "gray metal" look like we've seen before
>>>
>>> or
>>>
>>>> some more rainbow gradients like we've seen before?
>>>
>>>
>>> I can see I touched a sore spot here. First, please remember I'm
>>> passing on reactions from others, not expressing my own views here.
>>> I'm trying to figure out how to make it possible for me to get
>>> projects and contracts using Squeak from people with pre-conceived
>>> ideas about what an application looks like.
>>>
>>> Short of true native platform widgets, I think it's safe to say that
>>> the vast, vast majority of computer users are accustomed to certain
>>> kinds of shapes for certain kinds of objects and that when we vary
>>> from those standards, we'd better have a really good reason for
>>> asking them to pay attention to our interface rather than to the task
>>> they are trying to accomplish. I don't know if that's "manly" gray
>>> metal or rainbow gradients or just round-cornered rectangles with
>>> default buttons flagged somehow. The point is that it is NOT the UI
>>> one finds in Squeak today.
>>>
>>>> 2.  What is THE "standard"?  Microsoft?  What, then, when Microsoft
>>>> changes its look again?  Are they then "non-standard" or their
>>>> followers?
>>>
>>>
>>> Again, I think it's less an issue of choosing a standard than it is
>>> of choosing a UI experience that maps to the user's established
>>> expectations.
>>>
>>>> 2b.  Do you remember this rubbish, "All windows programs look alike
>>>> therefore once you've learned one you've learned them all.."?
>>>
>>>
>>> Yeah, only I heard it said about Mac programs. Same rubbish, though.
>>>
>>>> 3.  Even if it can be "offically" labelled "toy like," what is
>>>
>>> wrong
>>>
>>>> with that?  Too wimpy-looking?  What's wrong with wimpy-looking as
>>>> long
>>>> as its easy and functional?
>>>
>>>
>>> Sorry to keep beating the dead horse here, but the issue is that it
>>> is toy-like *compared to user expectations* set up by other programs.
>>> I find the EToys UI refreshing. My potential clients and colleagues
>>> whom I wish to interest in Squeak just don't.
>>>
>>>> 4.  Speaking of wimpy, someone (not you) once suggested "Squeak"
>>>
>>> was a
>>>
>>>> wimpy-sounding name, what do you think of "KA-POW!"?
>>>>
>>> LOL. I think Squeak is a weird name for a programming language. But
>>> not weirder than C or Java or Ruby.
>>>
>>>>> Thanks for any wisdom you can share. This is one of the two big
>>>>> objections I *always* get when I recommend someone look at Squeak
>>>>
>>> as
>>>
>>>>> a possible solution to a problem for which it appears to me to be
>>>>> ideally suited linguistically and architecturally.
>>>>
>>>>
>>>> So I guess this group sets its priorities to building something, as
>>>> you
>>>> said, "ideally suited linguistically and architecturally".  They
>>>> haven't spent as much time playing endlessly with colors, shadows,
>>>> gradients, only to please the latest group of popularist
>>>> superficialites who'll be gone as soon as the next Wired article
>>>
>>> tells
>>>
>>>> them where they need to go next to be cool.  Whew, sorry to say
>>>
>>> that,
>>>
>>>> at least you have my honesty.
>>>>
>>> I am at least somewhat sympathetic to your thinking here, Chris. All
>>> I'm really trying to do is find answers that will satisfy and/or make
>>> sense to the great majority of people who've had their user
>>> experience expectations shaped by the market.
>>>
>>> Dan
>>>
>>>
>>>
>>
>>
>
>
>

>
> On 7-Jul-06, at 2:45 PM, Daniel Poon wrote:
>
>> +1
>>
>> UI widgets are a solved problem. It is part of the operating  
>> system. Like writing a file system is done, writing UI widgets is  
>> done too.
>
> Now that I have to disagree with. There is no OS/GUI /platform that  
> I have so much as heard rumours of that qualify as having 'solved  
> UI widgets'. They are all sufficiently steeped in effluvium as to  
> smell bad.
>
> I don't think filing systems are 'done ' either; certainly  
> microsoft hasn't managed to finish that damn big file system it's  
> been promising RSN since I first moved to the US in 91. Unix is not  
> exactly a shining example either.
>
> Just because lots (all?) of the current commercial platforms do  
> something  doesn't mean it is a good - or even acceptable - idea.
>
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> 42.7 percent of all statistics are made up on the spot.
>
>
>

> I suppose the simplest way of describing it is that I am attempting  
> to 'harvest'
> code from Sophie and Henrik, so that we can get FreeType/Subpixel-
> Anti-aliasing
> into 3.9, or 3.10, 3.11... :)
>
> I'll see if I get something together for people to look at.
> This will only be for Windows, and similar to the last one, but now  
> using the
> latest FreeType-2.2.1, and based on 3.9.7038)
>
> And I'll take a look at the latest Sophie code when I get a chance.
>
>> Because I hope that andy will not be frustrated :)
>
> Only with my own slow progress :)
>

> Although far from native or standard anything, "Maui" is a
> direct-manipulation "IDE" that has been available for some time on
> SqueakSource.  It's a naked-objects framework, so not only a direct
> manipulation IDE, its direct-manipulation of the actual running UI's.
>
> I think its fun, and a fine example how a generic, open-ended UI
> framework like Morphic permits promotes creative thinking and new
> ideas.  Of course, the main theme lately has been lack of support for
> existing ideas...
>
>
> --- Dan Shafer <[hidden email]> wrote:
>
>> Rob....
>>
>> Good to hear from you again here.
>>
>> I agree; no need to stay with one UI, whatever it is. I'm anxious to
>> get the wx stuff working because I want to turn my attention then to
>> creating a graphical IDE for the construction of windows using the wx
>> widgets. A direct-manipulation IDE is something I sorely miss in
>> Smalltalk.
>
>