[Ann] WxMorphic v.0.01alpha

[Steven Swerling]

Rob Gayvert wrote:
> Steven Swerling wrote:
> 
>> Hi,
>>
>> As the subject says:
>>
>>   http://www.swerlingphoto.com/squeak/wxmorphic/WxMorphic.html
>>
>> Includes screenshot.
>>
>> Pretty stable. Windows only.
>>
>> Take it for a spin and let me know what happens.
> 
> 
> Steve -- this is marvelous. It's amazing to see morphs and widgets 
> working so well together. And it's remarkably stable, especially for a 
> 0.01alpha release ;)
> 
> Just a few comments and questions so far:
> 
> 1. In 0.02, buttons in a WxMorphicWorldTestPresenter outside of the new 
> demo window don't work. This worked fine in 0.01. It might have 
> something to do with the 0.01->0.02 update.

This was a simple bug -- I did a tiny bit of refactoring around the
presenters between .01 and .02 (and will again in the next release).

> 2. The bouncing atoms demo reveals a limitation of the current wx event 
> handling: a modal event loop is run entirely within wxWidgets, so 
> there's no opportunity for any updates on the Smalltalk side. How big of 
> an issue do you think this is?

Can you be more specific here? If you are talking about the atoms
freezing during the openInHand that happens in one of the test frame
buttons, that is an issue with the current deferred events scheme. It
goes away if the button uses on:send: instead of on:sendDeferred.


> 3. The wxSqueak demo needs a couple of directories (rc and data) to 
> function properly. Feel free to add these to your demo if you want.

Will do.

> 4. How much Win32-specific code is there? Any idea how hard this will be 
> to port to OS X or GTK?

The win32 specific code is all contained in the plugin file
"WxFormUtils.cpp". The generated plugin code will be x-platform I would
think, and the header file won't require any signifigant change. So it's
just that file, which contains 4 external functions: WxBitmapFromForm,
formToWxDC, wxInvalidateRect (I was surprised I had to write this, but I
did), and initialize. Most of the support code for those functions was
ripped out of sqWin32Window.c (for color palette handling) and more than
likely an analagous approach would work on other platforms for
supporting those 4 primitives.


> 5. The keyboard focus problem is tricky. I tried a quick modification of 
> WxButtonMorph to see if a wxEvtSetFocus event could deflect focus back 
> to the parent, but it didn't have any effect. We may have to look deeper 
> into the wxWidgets internals here to find an answer.

Yes, this is worrisome, but if worse comes to worse, we can implement a
primitive call that would probably do the trick.

> 6. The notion of halos on wxButtons is intriguing.. If this can be 
> generalized to any wx widget, it may offer an almost trivial solution to 
> some of the more difficult problems in creating a UI builder.

It certainly can, and thats the point of that little demo. The morph
wrapper classes for most objects would be paper thin, too. The one
exeception is Sizers. A WxBoxSizerMorph would have to have some built in
smarts to layout its child widgets the way Wx would after XRC
generation. Also, some careful thought needs to go into the relationship
between wx and morphic. Would a morphic UI builder just spit out XRC, or
can we assume there is a WxMorphicWorld behind the widgets handling
layout. I haven't given much thought to this yet, but I think it's
important to have a clear idea about what direction you want to take it
before adding more WxWidgetWrappers.


> 7. "Toggle Squeak Display on/off".   I think what you're after here is 
> already available with Wx>>showSqueakWindow:. Also, the VM can be 
> started with a -headless option; under Windows, this gives you a tray 
> icon which can open the Squeak window.

Holy cow, that works great. I better make sure that the step/update
cycle doesn't get processed when the display is toggled. Scratch that
one off the list!