I've advocated the creation of a higher level wrapper around wxpython some time ago on the list.
Meanwhile I've did some testing and I think the thing is doable.
I've created a small blog for people to disscuss this.
http://sigmacore.modblog.com/
Anyone interested is welcomed to post an ideea.
Any kind of comments/ideas are welcomed.
--
Peter Damoc
Hacker Wannabe
http://sigmacore.modblog.com/
If you are wanting discussion, then it should take place on a mailing list in conjunction with a wiki. As for the wiki, just use the wxPython wiki and prefix all the pages with something meaningful like WrapperAPI. As for names, I've always liked Wax, but Hans is already using that and I don't know how he would feel about a wrapper that might not go in the same direction as the current version of Wax. Hans?
http://wiki.wxpython.org/index.cgi/Wax
When Robin and I first discussed this idea, a project was setup on SourceForge called Monty, and that can certainly be used as the home for the mailing list as well as a code name for the wrapper, prefix in the wiki, etc.
http://sourceforge.net/projects/montywxpython/
Note that my top coding priority for the next couple of months is to get PythonCard to a 1.0 release, so I'm unlikely to contribute much more than discussion until that is done. Of course, one purpose of getting PythonCard to 1.0 is to be able to evaluate the good and bad points of the approach we took which will certainly be relevant to a more generic wxPython wrapper API discussion.
ka
On May 4, 2004, at 10:54 AM, Peter Damoc wrote:
I've advocated the creation of a higher level wrapper around wxpython some time ago on the list.
Meanwhile I've did some testing and I think the thing is doable.
I've created a small blog for people to disscuss this.
http://sigmacore.modblog.com/
Anyone interested is welcomed to post an ideea.
Any kind of comments/ideas are welcomed.--
Peter Damoc
Hacker Wannabe
http://sigmacore.modblog.com/
On Tuesday 04 May 2004 20:47, Kevin Altis schreef:
On May 4, 2004, at 10:54 AM, Peter Damoc wrote:
> I've advocated the creation of a higher level wrapper around wxpython
> some time ago on the list.
> Meanwhile I've did some testing and I think the thing is doable.
> I've created a small blog for people to disscuss this.
> http://sigmacore.modblog.com/
> Anyone interested is welcomed to post an ideea.
> Any kind of comments/ideas are welcomed.
>
> --
> Peter Damoc
> Hacker Wannabe
> http://sigmacore.modblog.com/
Take a look at GNUe. In fact that is nothing more than a toolkit as you
describe it.. Or at least a framework for building complete applications.
Cheers
D. Kniep
If you are wanting discussion, then it should take place on a mailing list in conjunction with a wiki. As for the wiki, just use the wxPython wiki and prefix all the pages with something meaningful like WrapperAPI. As for names, I've always liked Wax, but Hans is already using that and I don't know how he would feel about a wrapper that might not go in the same direction as the current version of Wax. Hans?
I don't want the wax namespace 
I was thinking more about wxp (gui namespace is also available but is too big a shoe to fit right now )
When Robin and I first discussed this idea, a project was setup on SourceForge called Monty, and that can certainly be used as the home for the mailing list as well as a code name for the wrapper, prefix in the wiki, etc.
http://sourceforge.net/projects/montywxpython/
Note that my top coding priority for the next couple of months is to get PythonCard to a 1.0 release, so I'm unlikely to contribute much more than discussion until that is done. Of course, one purpose of getting PythonCard to 1.0 is to be able to evaluate the good and bad points of the approach we took which will certainly be relevant to a more generic wxPython wrapper API discussion.
ka
I realised that is very difficult to disscuss vaporware so... I should spend a little more time getting the proof of concept cristalized and as soon as it works I'll push a 0.0.0.0.1prealfa version on the net then will have something to argue about. If my luck holds I should have something done by the end of this week.
On Tue, 4 May 2004 11:47:16 -0700, Kevin Altis <altis@semi-retired.com> wrote:
--
Peter Damoc
Hacker Wannabe
Take a look at GNUe. In fact that is nothing more than a toolkit as you
describe it.. Or at least a framework for building complete applications.
I've bookmarked their page, will study (xml forms are a great idea)
On Wed, 5 May 2004 11:25:31 +0200, Dick Kniep <dick@kniep.nl> wrote:
Cheers
D. Kniep
--
Peter Damoc
Hacker Wannabe
Peter Damoc wrote:
I've advocated the creation of a higher level wrapper around wxpython some time ago on the list.
Meanwhile I've did some testing and I think the thing is doable.
I've created a small blog for people to disscuss this.
http://sigmacore.modblog.com/
Anyone interested is welcomed to post an ideea.
Any kind of comments/ideas are welcomed.
Doesn't PythonCard already do what you're interested in? Its higher level and easy to use. Or are you looking for something else?
Bob
well... not really... altho is the most mature high level wrapper around wxpython it does not hit my sweet spot. It does have however some ideas worth "borrowing"
On Wed, 05 May 2004 10:59:12 -0400, Bob Klimek <klimek@grc.nasa.gov> wrote:
Doesn't PythonCard already do what you're interested in? Its higher level and easy to use. Or are you looking for something else?
Bob
--
Peter Damoc
Hacker Wannabe
I thought this discussion was about simplifying the wxPython API without losing *ANY* functionality of the underlying toolkit? PythonCard certainly doesn't attempt to do that, in fact it intentionally hides a whole lot of wxPython that for simple apps is just noise. GNUe doesn't fit the bill either, it is targeted at a very specific application domain and is not a general wrapper around wxPython to hide the C++isms...
So, the first thing that should be done is to define what the target of the effort is. If all you want to do is simplify the parts of wxPython that you use, that is easy, and probably everyone on this list that has a written a sizable app or many apps with wxPython has probably already done that at least once. But it is highly unlikely those helper classes and methods qualify as a general simplification wrapper of the wxPython API.
Anyway, I still suggest that this discussion move to a different list.
ka
On May 5, 2004, at 9:01 AM, Peter Damoc wrote:
On Wed, 05 May 2004 10:59:12 -0400, Bob Klimek <klimek@grc.nasa.gov> > wrote:
Doesn't PythonCard already do what you're interested in? Its higher level and easy to use. Or are you looking for something else?
Bob
well... not really... altho is the most mature high level wrapper around wxpython it does not hit my sweet spot.
Peter Damoc wrote:
Doesn't PythonCard already do what you're interested in? Its higher level and easy to use. Or are you looking for something else?
well... not really... altho is the most mature high level wrapper around wxpython it does not hit my sweet spot.
Be careful here. While the whole concept of open source projects is about "scratching an itch", the truth is that there are far more projects started for similar "itches" that never get to a useful state than ones that make it.
You need critical mass, and you won't get it the community of folks that want an easier to use wxPython wrapper is too divided. This doesn't mean you shouldn't get started with your early prototype, but I'd suggest that if you can't get the folks behind PythonCard, or Wax, or Mindwrapper (http://mindwrapper.org/) or ??? to join you, you'd be better off joining an existing project.
For instance, my big issue with PythonCard is that it doesn't (or didn't anyway) use sizers. However, it's been clear that if I wanted to go that way, I'd be a lot better off contributing a Sizer implementation for PythonCard than starting a whole new project!
What about PythonCard doesn't "hit your sweet spot" can you articulate it? Is a true difference in the aims of the project, or really implementation details?
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
This is the problem with “high level”
toolkits. The higher the level, the more the kit conforms to one
perspective of what is right and proper, attractive vs. unattractive, useable
vs. unuseable – and consequently the more you will find people who don’t
quite like what the toolkit provides or permits. Even at the level
of wxWindows and GTK this kind of tension is evident. In general,
the higher the level, the lower the flexibility – at least at the “high”
level, even if you continue to provide low level access. And particularly
with high quality UI design, flexibility is everything.
So in general, I think, the higher the level
you strive for, the narrower the audience which will find it acceptable
or desireable. I suspect this is more a matter of psychology and
art than it is of technology. But it always gives one pause when
thinking about providing something “better”.
Gary H. Merrill
Director and Principal Scientist, New Applications
Data Exploration Sciences
GlaxoSmithKline Inc.
(919) 483-8456
“Peter Damoc”
pdamoc@gmx.net
05-May-2004 12:01
Please respond to wxPython-users@lists.wxwidgets.org
To
wxPython-users@lists.wxwidgets.org
cc
Subject
Re: [wxPython-users] a higher
level GUI toolkit
`On Wed, 05 May 2004 10:59:12 -0400, Bob Klimek klimek@grc.nasa.gov
wrote:
Doesn’t PythonCard already do what you’re interested in? Its higher
level and easy to use. Or are you looking for something else?
Bob
well… not really… altho is the most mature high level wrapper around
wxpython it does not hit my sweet spot. It does have however some ideas
worth “borrowing”
–
Peter Damoc
Hacker Wannabe
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org
`
I agree, I hope to have something set up by next week (wiki, list, proof of concept)
we'll talk more then.
On Wed, 5 May 2004 09:39:33 -0700, Kevin Altis <altis@semi-retired.com> wrote:
I thought this discussion was about simplifying the wxPython API without losing *ANY* functionality of the underlying toolkit? PythonCard certainly doesn't attempt to do that, in fact it intentionally hides a whole lot of wxPython that for simple apps is just noise. GNUe doesn't fit the bill either, it is targeted at a very specific application domain and is not a general wrapper around wxPython to hide the C++isms...
So, the first thing that should be done is to define what the target of the effort is. If all you want to do is simplify the parts of wxPython that you use, that is easy, and probably everyone on this list that has a written a sizable app or many apps with wxPython has probably already done that at least once. But it is highly unlikely those helper classes and methods qualify as a general simplification wrapper of the wxPython API.
Anyway, I still suggest that this discussion move to a different list.
ka
--
Peter Damoc
Hacker Wannabe
Peter Damoc wrote:
I've advocated the creation of a higher level wrapper around wxpython some time ago on the list.
Meanwhile I've did some testing and I think the thing is doable.
I've created a small blog for people to disscuss this.
http://sigmacore.modblog.com/
Anyone interested is welcomed to post an ideea.
Any kind of comments/ideas are welcomed.
"""
For "parentless" widgets I've created a hidden frame that will be the default parent for all widgets created and used something like a layout manager architecture. All panels have a layout manager provided by default (a thin wrapper around a wx.BoxSizer). This layout manager reparents all the widgets added to the panel.
"""
This won't work on all platforms. Last I checked reparenting was not supported on wxMac.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
A list is ready is go...
http://lists.sourceforge.net/lists/listinfo/montywxpython-devel
For the wiki, as mentioned before, just use the wxPython wiki.
ka
On May 5, 2004, at 10:16 AM, Peter Damoc wrote:
On Wed, 5 May 2004 09:39:33 -0700, Kevin Altis > <altis@semi-retired.com> wrote:
I thought this discussion was about simplifying the wxPython API without losing *ANY* functionality of the underlying toolkit? PythonCard certainly doesn't attempt to do that, in fact it intentionally hides a whole lot of wxPython that for simple apps is just noise. GNUe doesn't fit the bill either, it is targeted at a very specific application domain and is not a general wrapper around wxPython to hide the C++isms...
So, the first thing that should be done is to define what the target of the effort is. If all you want to do is simplify the parts of wxPython that you use, that is easy, and probably everyone on this list that has a written a sizable app or many apps with wxPython has probably already done that at least once. But it is highly unlikely those helper classes and methods qualify as a general simplification wrapper of the wxPython API.
Anyway, I still suggest that this discussion move to a different list.
ka
I agree, I hope to have something set up by next week (wiki, list, proof of concept)
we'll talk more then.
Peter Damoc wrote:
Doesn't PythonCard already do what you're interested in? Its higher level and easy to use. Or are you looking for something else?
well... not really... altho is the most mature high level wrapper around wxpython it does not hit my sweet spot.
Be careful here. While the whole concept of open source projects is about "scratching an itch", the truth is that there are far more projects started for similar "itches" that never get to a useful state than ones that make it.
That's a risk I'm willing to take.
You need critical mass, and you won't get it the community of folks that want an easier to use wxPython wrapper is too divided. This doesn't mean you shouldn't get started with your early prototype, but I'd suggest that if you can't get the folks behind PythonCard, or Wax, or Mindwrapper (http://mindwrapper.org/) or ??? to join you, you'd be better off joining an existing project.
Choices we make are debatable, you cannot have something to please everybody. I think is worth mentioning tho that wax is the closest to my vision.
For instance, my big issue with PythonCard is that it doesn't (or didn't anyway) use sizers. However, it's been clear that if I wanted to go that way, I'd be a lot better off contributing a Sizer implementation for PythonCard than starting a whole new project!
What about PythonCard doesn't "hit your sweet spot" can you articulate it? Is a true difference in the aims of the project, or really implementation details?
Different aim, what I want is something that will require little modification in my programming habits. It should (ideally) allow both the old way and the new way.
KA is right, I have poluted enough the wxpython-users list about this.
If there are anymore comments regarding this subject please direct them at my email address until I manage to start another mailing list.
On Wed, 05 May 2004 09:57:54 -0700, Chris Barker <Chris.Barker@noaa.gov> wrote:
-Chris
--
Peter Damoc
Hacker Wannabe
darn, is there a workaround possible? I'm reparenting allover my code...
On Wed, 05 May 2004 10:18:00 -0700, Robin Dunn <robin@alldunn.com> wrote:
"""
For "parentless" widgets I've created a hidden frame that will be the default parent for all widgets created and used something like a layout manager architecture. All panels have a layout manager provided by default (a thin wrapper around a wx.BoxSizer). This layout manager reparents all the widgets added to the panel.
"""This won't work on all platforms. Last I checked reparenting was not supported on wxMac.
--
Peter Damoc
Hacker Wannabe
This is the problem with "high level" toolkits. The higher the level, the
more the kit conforms to *one* perspective of what is right and proper,
attractive vs. unattractive, useable vs. unuseable -- and consequently the more you will find people who don't *quite* like what the toolkit provides or permits.
Even at the level of wxWindows and GTK this kind of tension
is evident. In general, the higher the level, the lower the flexibility
-- at least at the "high" level, even if you continue to provide low level
access. And particularly with high quality UI design, flexibility is
everything.
well, I don't know about that, I think that in UI design, speed is everything and when I say speed I'm talking about how fast can the UI be created and how fast can be modified uppon client's request.
I agree that flexibility might be lost BUT I see it as an equivalent to memory management: in C you do it by hand in python the language does it for you; some might like this some don't but all agree that this is a speed-up when it comes to how fast a certain thing can be coded.
So in general, I think, the higher the level you strive for, the narrower
the audience which will find it acceptable or desireable. I suspect this
is more a matter of psychology and art than it is of technology. But it
always gives one pause when thinking about providing something "better".
I think that while going higher might loose you some hard-core programmer it will gain us users from those that never touched the thing before due to its complexity.
a recent slashdot feature regarding high level languages
http://www.dadgum.com/james/performance.html
and one of my favorites
http://www.artima.com/intv/simplest.html
Please feel free to join
http://lists.sourceforge.net/lists/listinfo/montywxpython-devel
we will discuss there the aspects related to a higher level wrapper around wxpython, maybe you can provide a view about what will be lost when going higher and help us reduce the "damage" 
On Wed, 5 May 2004 13:00:55 -0400, <gary.h.merrill@gsk.com> wrote:
--------------------------------------
Gary H. Merrill
Director and Principal Scientist, New Applications
Data Exploration Sciences
GlaxoSmithKline Inc.
(919) 483-8456
--
Peter Damoc
Hacker Wannabe
Peter Damoc wrote:
"""
For "parentless" widgets I've created a hidden frame that will be the default parent for all widgets created and used something like a layout manager architecture. All panels have a layout manager provided by default (a thin wrapper around a wx.BoxSizer). This layout manager reparents all the widgets added to the panel.
"""This won't work on all platforms. Last I checked reparenting was not supported on wxMac.
darn, is there a workaround possible? I'm reparenting allover my code...
Perhaps your classes could use the "Pre" form of constructing the wx class, (wx.PreWindow, wx.PreButton, etc.) and then call the widget's Create method later when you have the parent and etc. The Pre form only creates the C++ instance of the class, it does not create the UI widget, so it doesn't need the parent window yet. However there are some methods that probably won't work until there is a UI widget created so you should try to ensure that Create is called soon after the Pre.
On Wed, 05 May 2004 10:18:00 -0700, Robin Dunn <robin@alldunn.com> wrote:
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
A subject near and dear to my heart.
Some time ago I started a project to write my own high-level
toolkit to wrap arround wxPython. Its not *quite* as
high-level as some, but its close.
The basic design philosophy: Given a properly designed
toolkit, a complex application interface need not be time or
code intensive to write. If a default look & feel is
desired, a feature-rich yet simple application interface
should take minutes to create while a complex application
interface should take no more than a few hours. At the same
time, all aspects of the underlying language and any
low-level toolkits must be available to the main application
at _all_ times.
As a friend of mine said, it sounds a bit like having your
cake and eating it too, but I've proven it is possible.
The toolkit I'm writing (not just a wxPython wrapper, an
entire rapid application development package) is still
*very* early in the development process compared to where it
will end, but it already can do some amazing feats in quick
wxPython GUI creation while allowing complete access to
wxPython itself. (yes, I use it myself for all applications
in its current incarnation, though its not in a state I
would let others use it yet).
One of these days I'll stop working so much overtime and be
able to finish writing it.....
--David
On Fri, May 07, 2004 at 08:51:16AM +0300, Peter Damoc wrote:
On Wed, 5 May 2004 13:00:55 -0400, <gary.h.merrill@gsk.com> wrote:
>This is the problem with "high level" toolkits. The higher the level,
>the
>more the kit conforms to *one* perspective of what is right and proper,
>attractive vs. unattractive, useable vs. unuseable -- and consequently
>the more you will find people who don't *quite* like what the toolkit
>provides or permits.
>Even at the level of wxWindows and GTK this kind of tension
>is evident. In general, the higher the level, the lower the flexibility
>-- at least at the "high" level, even if you continue to provide low
>level
>access. And particularly with high quality UI design, flexibility is
>everything.well, I don't know about that, I think that in UI design, speed is
everything and when I say speed I'm talking about how fast can the UI be
created and how fast can be modified uppon client's request.
I agree that flexibility might be lost BUT I see it as an equivalent to
memory management: in C you do it by hand in python the language does it
for you; some might like this some don't but all agree that this is a
speed-up when it comes to how fast a certain thing can be coded.>So in general, I think, the higher the level you strive for, the narrower
>the audience which will find it acceptable or desireable. I suspect this
>is more a matter of psychology and art than it is of technology. But it
>always gives one pause when thinking about providing something "better".I think that while going higher might loose you some hard-core programmer
it will gain us users from those that never touched the thing before due
to its complexity.
join
http://lists.sourceforge.net/lists/listinfo/montywxpython-devel
we discuss high level wrappers over there.
Also I would love to have a sneek preview of your toolkit if possible. I'm curious to see how you solved some of the problems that froze my progress.
On Mon, 10 May 2004 11:23:52 -0600, David Morris <lists@morris-clan.net> wrote:
The toolkit I'm writing (not just a wxPython wrapper, an
entire rapid application development package) is still
*very* early in the development process compared to where it
will end, but it already can do some amazing feats in quick
wxPython GUI creation while allowing complete access to
wxPython itself. (yes, I use it myself for all applications
in its current incarnation, though its not in a state I
would let others use it yet).One of these days I'll stop working so much overtime and be
able to finish writing it.....--David
--
Peter Damoc
Hacker Wannabe