[Ann] WxMorphic v.0.01alpha

[Steven Swerling]

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.

Regards,

Steve S.

[Rob Gayvert]

Post by Steven Swerling
Hi,
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.

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?

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.

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

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.

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.

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.

.. Rob

[Steven Swerling]

Post by Rob Gayvert

Post by Steven Swerling
Hi,
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 ;)
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).

Post by Rob Gayvert
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.

Post by Rob Gayvert
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.

Post by Rob Gayvert
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.

Post by Rob Gayvert
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.

Post by Rob Gayvert
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.

Post by Rob Gayvert
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!

[Rob Gayvert]

Post by Steven Swerling

Post by Rob Gayvert
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.

Nice. That sounds very straightforward.

Post by Steven Swerling

Post by Rob Gayvert
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.

That's true. Worst case, we should be able to bypass wx and go straight
to a platform specific routine to set the focus.

Post by Steven Swerling

Post by Rob Gayvert
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.

Re-implementing all the sizer logic is not trivial, but certainly doable.

Post by Steven Swerling
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 think the result of the builder should be independent of morphic, if
that's what you mean.

Post by Steven Swerling
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.

It should be easy to get started with a few simple tests to see how it
might work out. With a couple of wrappers and a box sizer you can go a
long way.

[Steven Swerling]

Post by Rob Gayvert

Post by Steven Swerling

Post by Rob Gayvert
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.

That's true. Worst case, we should be able to bypass wx and go straight
to a platform specific routine to set the focus.

For now I've got a workaround that works well, so we can put this on the
backburner.

Post by Rob Gayvert
Re-implementing all the sizer logic is not trivial, but certainly doable.

Yeah, they don't seem so far removed from Alignment morphs in their
behavior.

I've got multiple panels and scaled panels working, so I'm gonna start
do a thumbnail morph, just to finish it off that idea. Next thing after
that on the priority list is to let the wx windows survive image saves.
Then revisit the debugger and make sure it's debugging the correct world
when it pops up.

I said before I was going to talk to you about deferred events handling,
but I want to work something up first and haven't had time.

[Steven Swerling]

Post by Rob Gayvert
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?

Right, for instance the world stops stepping when the about box is up,
or when the user grabs the scrollbars, or when they access the menubar
at the top of the window. It's very hard for me to judge whether this is
a big deal or not. If it really annoys enough people, we may be able to
muck around inside of Wx to "doOneCycleAllWorlds" during modal
operations.

[Rob Gayvert]

Post by Steven Swerling

Post by Rob Gayvert
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?

Right, for instance the world stops stepping when the about box is up,
or when the user grabs the scrollbars, or when they access the menubar
at the top of the window. It's very hard for me to judge whether this
is a big deal or not. If it really annoys enough people, we may be
able to muck around inside of Wx to "doOneCycleAllWorlds" during
modal operations.

Yes, the about box was what I had in mind. I hadn't even thought of
scrollbars or menus; I'm not sure if there's much we can do there. But
for dialogs opened with #showModal, we could (in theory, at least) keep
running other Squeak processes while the dialog is up, if we were to
replace the modal event loop with a loop driven from Squeak.