[wxPython] app framework goals again

There hasn't been any more response to the original app framework messages,
so I thought I would try and get it started again. Any suggested priorities?

I'm looking at the resource issue, but I'm waiting to hear back from Robin
about a sample I sent him.

Components are very important, but not necessary if people simply want to
duplicate the wxWindows doc/view API in Python. The component change is
either going to be a fundamental addition to wxPython or end up being more
like PythonCard, where the wrapped classes sit on top of wxPython, but the
API is no longer wxWindows, just similar.

The items I have the most enthusiasm for are ways of simplifying using
wxPython and adding additional classes to fill the holes in wxPython, which
overlaps many of the original goals of PythonCard, but I don't mind
concentrating on a light doc/view framework instead if we can get a handle
on exactly what it is we want the framework to provide.

The original goals messages is at:
http://aspn.activestate.com/ASPN/Mail/Message/816476
"app framework" is in the subject line of messages and replies relating to
the application framework if you're browsing past messages.

Anyway, we can't proceed without a focus, so we still need some more
discussion.

ka

"Kevin Altis" <altis@semi-retired.com> writes:

There hasn't been any more response to the original app framework messages,
so I thought I would try and get it started again. Any suggested priorities?

My first forays into wxpython were scuppered by not having MVC. Suggestions on
this list and Bernhard Herzog's implementation
(http://sketch.sourceforge.net/Doc/devguide-26.html) greatly helped me do this
in python. Although it doesn't seem to be a wxpython specific problem it'd be
nice to have one to pick up and use.

After VB's 'do it yourself' and fun with Java's layout managers (my knowledge is
pre-swing & to VB6), sizers work pretty well. I still occasionally have to look
up the meaning of 0 or wxEXPAND though - but that's just my sieve like brain!
Sizers and notebooks for some reason always give me headaches aswell.

I've only briefly looked at boa or wxdesigner but still find it easier to
plagerise Robin's demo.

I'm looking at the resource issue, but I'm waiting to hear back from Robin
about a sample I sent him.

This for me is the highest priority, the cleanest way I've found at the moment
is to do the layout as a base class and then inherit to implement the event
handlers. This would all be better handled by some standard resource - and
give builder apps a leg up. Just please don't leave out some sort of resizing
layout.

Components are very important, but not necessary if people simply want to
duplicate the wxWindows doc/view API in Python. The component change is
either going to be a fundamental addition to wxPython or end up being more
like PythonCard, where the wrapped classes sit on top of wxPython, but the
API is no longer wxWindows, just similar.

What do you mean by components?

So why the split from PythonCard? I don't know much about it or hypercard but
the goals look similar??

The items I have the most enthusiasm for are ways of simplifying using
wxPython and adding additional classes to fill the holes in wxPython, which
overlaps many of the original goals of PythonCard, but I don't mind
concentrating on a light doc/view framework instead if we can get a handle
on exactly what it is we want the framework to provide.

I'd like to create gui's with the speed of VB, pick a MVC or doc/view if needed,
write some event handlers and then get on with my real task. Any steps to this
goal would be great - oh and if possible achieve world peace :wink:

···

The original goals messages is at:
ActiveState Community - Boosting coder and team productivity with ready-to-use open source languages and tools.
"app framework" is in the subject line of messages and replies relating to
the application framework if you're browsing past messages.

Anyway, we can't proceed without a focus, so we still need some more
discussion.

ka

_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwindows.org
http://lists.wxwindows.org/mailman/listinfo/wxpython-users

--
wxPython

> I'm looking at the resource issue, but I'm waiting to hear back
from Robin
> about a sample I sent him.

This for me is the highest priority, the cleanest way I've found
at the moment
is to do the layout as a base class and then inherit to implement
the event
handlers. This would all be better handled by some standard resource - and
give builder apps a leg up. Just please don't leave out some sort
of resizing
layout.

I don't have a clue right now how to do an intuitive sizer layout builder.
wxDesigner works, but most of the layouts I've done with it have been a
trial of my patience, it certainly isn't simple. I breathe a sigh of relief
when I finally get a layout to work the way I want it to. I've looked at
HTML table tools and banged my head against several possible "automatic"
layout methods, but haven't hit pay dirt yet. For now, I find it easier to
do a fixed layout, then push it into a sizer afterwards.

>
> Components are very important, but not necessary if people
simply want to
> duplicate the wxWindows doc/view API in Python. The component change is
> either going to be a fundamental addition to wxPython or end up
being more
> like PythonCard, where the wrapped classes sit on top of
wxPython, but the
> API is no longer wxWindows, just similar.

What do you mean by components?

See the past messages on this topic. One way to think about components would
be a simplified COM that is specific to Python. The main thing is that the
class needs to be self-contained, so a layout tool for example would be able
to use introspection and standard methods to be able to use say a custom
class, not just those classes defined in wxPython.

So why the split from PythonCard? I don't know much about it or
hypercard but
the goals look similar??

Long story, you would need to browse the PythonCard archives of the last few
weeks to get a feel for the project. The short answer is that PythonCard
lacks critical mass, especially in the developer area, so I wanted to try my
hand at a wxPython-specific framework and then build PythonCard on top of
that unless the wxPython framework ended up being good enough. PythonCard is
supposed to be simple. Depending on how light the wxPython framework ends up
being, it may not be that simple to use, but it should help wxPython pros.

As a simple example, the PythonCard event handling takes care of event
binding for the user/programmer. Rather than needing an EVT_BUTTON() setup
and a separate method to handle the actual button click like OnMouseClick,
all you have to put in your code is a handler like:

def on_btn1_mouseClick(self, target, event):
    print "hello", target.name

All of the mouse events, selection, key presses, etc. for the base widgets
are setup automatically by PythonCard. At runtime, the event system searches
for methods with the special names and does the binding for you.

Whether we would want something like that in app framework remains to be
seen. Personally, I hate trying to remember all those stupid macros (that's
what they are in C++), so I like having standard event names and not having
to bother with the setup, which is also handy when you want to prototype or
program interactively in the shell.

> The items I have the most enthusiasm for are ways of simplifying using
> wxPython and adding additional classes to fill the holes in
wxPython, which
> overlaps many of the original goals of PythonCard, but I don't mind
> concentrating on a light doc/view framework instead if we can
get a handle
> on exactly what it is we want the framework to provide.
>

I'd like to create gui's with the speed of VB, pick a MVC or
doc/view if needed,
write some event handlers and then get on with my real task. Any
steps to this
goal would be great - oh and if possible achieve world peace :wink:

I don't quite see the VB and MVC connection. VB doesn't do MVC, at least as
far as the user/programmer is concerned. Do you want something more like VB?

ka

"Kevin Altis" <altis@semi-retired.com> writes:

...

>
> What do you mean by components?

See the past messages on this topic. One way to think about components would

apologies, my isp's web service nose dived today.

be a simplified COM that is specific to Python. The main thing is that the
class needs to be self-contained, so a layout tool for example would be able
to use introspection and standard methods to be able to use say a custom
class, not just those classes defined in wxPython.

That would be useful - more of a specifed standard interface than a COM
implementation.

...

As a simple example, the PythonCard event handling takes care of event
binding for the user/programmer. Rather than needing an EVT_BUTTON() setup
and a separate method to handle the actual button click like OnMouseClick,
all you have to put in your code is a handler like:

def on_btn1_mouseClick(self, target, event):
    print "hello", target.name

All of the mouse events, selection, key presses, etc. for the base widgets
are setup automatically by PythonCard. At runtime, the event system searches
for methods with the special names and does the binding for you.

Filling in the blanks for macros & id's - sounds all to the good

...

I don't quite see the VB and MVC connection. VB doesn't do MVC, at least as
far as the user/programmer is concerned. Do you want something more like VB?

Eugh no. I was just talking about the drag & drop gui builder for RAD. Thinking
about it, MVC in python is simple enough to be a recipe rather than a framework.

WxDesigner's xml resource looks interesting, especially in light of pythoncard's
runtime binding. Or does pythoncard take a different light?

···

ka

_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwindows.org
http://lists.wxwindows.org/mailman/listinfo/wxpython-users

--
wxPython

Kevein, you must have been expecting this note from me... didn't you
declare me the official sizer nag a while back?

Kevin Altis wrote:

I don't have a clue right now how to do an intuitive sizer layout builder.
wxDesigner works, but most of the layouts I've done with it have been a
trial of my patience, it certainly isn't simple.

Difficult things aren't simple to do. I'm not just trying to be cute,
auto sizing layout is an inherently difficult thing to wrap your head
around. I've just started using wxDesigner, and after using it a bit, I
find it much less frustrating. It is certainly easier that using sizers
by hand, because you can get almost instant feedback when you do
something, and you don't need to rememeber what all those flags mean. A
little more documentation would help a lot (just how do you use a
splitter window?). Using sizers

For now, I find it easier to do a fixed layout, then push it into a sizer afterwards.

Ahh, this sounds similar to what we have found: Despite its name,
wxDesigner is NOT a good tool for designing GUI layouts. It order to use
it effectively, you have to have your layout designed first, and then
use wxDesigner to put it together. This is partly because you have to
build things from outside in, rather than inside out. I do think it
could be altered a little to make it easier to add a sizer around an
existing object, that would help.

For an easy to use tool, I suppose the ideal might be to allow either
sizers or fixed layout, much like wxWindows itself does. I am wary of
this, however, new users will find it easier to use fixed layout, and
therefor never learn to use sizers, and in the long run, they will
suffer for it. It's a tough call. I have a theory about so called
usability:

Most people define usability in terms of how steep the learning curve is
when the first pick up the tool: A usable tool is one you can do
something useful with soon afer you start using it. I prefer to define
usability in terms of overall productivity: how much can I get done with
how much effort, over the life of my using the tool. As a rule, I've
found that things that have the easiest learning curve at the begining,
stifle my productivity in the long run. I think this very much applies
here.

The problem, of course, is that it is hard to purswade someone that a
tool will make them highly productive when they can't do a damn thing
with it when they first pick it up!

As a simple example, the PythonCard event handling takes care of event
binding for the user/programmer. Rather than needing an EVT_BUTTON() setup
and a separate method to handle the actual button click like OnMouseClick,
all you have to put in your code is a handler like:

def on_btn1_mouseClick(self, target, event):
    print "hello", target.name

All of the mouse events, selection, key presses, etc. for the base widgets
are setup automatically by PythonCard. At runtime, the event system searches
for methods with the special names and does the binding for you.

I think this is great, and just what wxPython needs. I've always thought
that wxPython was not very Pythonesque. In a dynamic language, it should
be much easier to put in a button, and assign something to do when it is
clicked.

Another option would be to assign the methods to call when defining the
button:

mybutton = ButtonConstructor(parent, position_info,
                       mouseclickfunc = self.afunc,
                             mouseoverfunc = self.anotherfunc)

Python's keyword arguments would make this managable, and it would allow
people to use function names that make sense to them, and to allow
different widgets and actions call the same function. This is just an
idea, I havn't thought it through yet...

I do think this is a very valuable project, I hope you can find the time
and support you need to get it to fly.

-Chris

···

--
Christopher Barker,
Ph.D.
ChrisHBarker@home.net --- --- ---
http://members.home.net/barkerlohmann ---@@ -----@@ -----@@
                                   ------@@@ ------@@@ ------@@@
Oil Spill Modeling ------ @ ------ @ ------ @
Water Resources Engineering ------- --------- --------
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------

I do think it
could be altered a little to make it easier to add a sizer around an
existing object, that would help.

It can already. Click the 2nd tool on the bottom toolbar (the one with the
sizer buttons) and then select the object you want to wrap the new sizer
around and then the new sizer.

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!

Robin Dunn wrote:

> I do think it
> could be altered a little to make it easier to add a sizer around an
> existing object, that would help.

It can already. Click the 2nd tool on the bottom toolbar (the one with the
sizer buttons) and then select the object you want to wrap the new sizer
around and then the new sizer.

Got it. Thanks.

By the way, is there any kind of mailing list for wxDesigner users? I
feel like I shouldn't pepper Robert with stupid questions like this, but
I see no other option for help. I'm planning on asking him, but havn't
gotten around to it.

-Chris

···

--
Christopher Barker,
Ph.D.
ChrisHBarker@home.net --- --- ---
http://members.home.net/barkerlohmann ---@@ -----@@ -----@@
                                   ------@@@ ------@@@ ------@@@
Oil Spill Modeling ------ @ ------ @ ------ @
Water Resources Engineering ------- --------- --------
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------

By the way, is there any kind of mailing list for wxDesigner users? I
feel like I shouldn't pepper Robert with stupid questions like this, but
I see no other option for help. I'm planning on asking him, but havn't
gotten around to it.

wx-users is the right place.

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!