New wx package

Tried it on five wxPython apps I am updating now.
Worked perfectly on all five.
(You did not ask for success stories, but I hope that is welcome as well)

David

···

-----Original Message-----
From: Robin Dunn [mailto:robin@alldunn.com]
Sent: den 26 mars 2003 20:14
To: wxPython-users
Subject: [wxPython-users] New wx package

After the firestorm of messages a couple weeks ago about the new
namespace idea, it's been pretty quite around here about it. I think
it's a good idea, and so do some other folks, and wx-dev is talking
again about switching to using a C++ namespace relativly soon. So what
I'm wondering is, has there been anybody who has tried Patrick's wx
"renamer" package that has had a bad experience with it?

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

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org

Davide Sparrman:

Robin Dunn:
> After the firestorm of messages a couple weeks ago about the
> new namespace idea, it's been pretty quite around here about
> it. I think it's a good idea, and so do some other folks, and
> wx-dev is talking again about switching to using a C++
> namespace relativly soon. So what I'm wondering is, has there
> been anybody who has tried Patrick's wx "renamer" package that
> has had a bad experience with it?

Tried it on five wxPython apps I am updating now.
Worked perfectly on all five.
(You did not ask for success stories, but I hope that is welcome
as well)

Well, mine is a success story too. I converted Mindwrapper over to
the wx package with no difficulty whatsoever. It did not change
the external API, but the advantage for me is that now the mw.Frame
'presenter' wraps the wx.Frame 'view', mw.Panel wraps wx.Panel, and
so on. I like the symmetry.

···

=====
Donnal Walter
Arkansas Children's Hospital

Donnal Walter <donnalcwalter@yahoo.com> writes:

Well, mine is a success story too. I converted Mindwrapper over to
the wx package with no difficulty whatsoever. It did not change
the external API, but the advantage for me is that now the mw.Frame
'presenter' wraps the wx.Frame 'view', mw.Panel wraps wx.Panel, and
so on. I like the symmetry.

BTW, I did look at Mindwrapper the other day and was quite impressed.
I'm not sure I'll have time to develop an app with it, but the code
looked very clean and you obviously have a keen sense of how to
produce good-looking interfaces. And I like how you simplified the
use of sizers. Good job.

···

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

How limited / generic is Mindwrapper intended to be? It
doesn't seem to be limited to paediatrics. :slight_smile: But maybe it's
only intended for forms? (I.e. not drawing editors, games etc.)

It obviously has the advantage over PythonCard that it uses
sizers...

Somehow, looking at it made me feel "why another?". It seems
to me that its goal is fairly similar to that of PythonCard.
Join forces?

I'd also like a higher level API, and I certainly think that
a high level layout mechanism (i.e. not absolute positioning
as in PythonCard, AnyGUI and V.B.) is a high priority.

/Magnus

P.S. Since I am currently working with an application for handling
nurishment of neonatals, I'm interested in Mindwrapper and Donnal's
work. I'd be really happy if we could steer the project I'm in over
from Excel to Python... The only nice thing with VBA is that it
makes me appreciate Python even more...

···

At 08:02 2003-03-27 -0600, Patrick K. O'Brien wrote:

BTW, I did look at Mindwrapper the other day and was quite impressed.
I'm not sure I'll have time to develop an app with it, but the code
looked very clean and you obviously have a keen sense of how to
produce good-looking interfaces. And I like how you simplified the
use of sizers. Good job.

--
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se

> BTW, I did look at Mindwrapper the other day and was quite
> impressed. I'm not sure I'll have time to develop an app with
> it, but the code looked very clean and you obviously have a
> keen sense of how to produce good-looking interfaces. And I
> like how you simplified the use of sizers. Good job.

How limited / generic is Mindwrapper intended to be? It
doesn't seem to be limited to paediatrics. :slight_smile: But maybe it's
only intended for forms? (I.e. not drawing editors, games etc.)

Well, it is clearly not limited to pediatrics and not necessarily
limited to clinical applications, although that is my focus. Yes,
it is definitely geared toward forms-based applications, especially
data-centric (but not data-intensive) apps. My primary goals are:
(1) to make it easy to create a domain data-model and then (2) to
make it easy create a GUI to interact with the data model.

It obviously has the advantage over PythonCard that it uses
sizers...

Somehow, looking at it made me feel "why another?". It seems
to me that its goal is fairly similar to that of PythonCard.
Join forces?

Yes, I would like to join forces at some point. Unfortunately, the
two architectures are enough different that I don't see a clear way
to do so in the near future, and my immediate priority is to get
some custom applications written for our NICU. The main reason I
decided to create Mindwrapper instead of using PythonCard is the
absolute need for data modeling. The second reason is the relative
desire for relative positioning.

I'd also like a higher level API, and I certainly think that
a high level layout mechanism (i.e. not absolute positioning
as in PythonCard, AnyGUI and V.B.) is a high priority.

/Magnus

P.S. Since I am currently working with an application for
handling nurishment of neonatals, I'm interested in Mindwrapper
and Donnal's work. I'd be really happy if we could steer the
project I'm in over from Excel to Python... The only nice thing
with VBA is that it makes me appreciate Python even more...

We need to talk. My interest in Python/wxPython grew out of an
Excel/VBA program for neonatal hyperalimentation that I wrote a
number of years ago. That application has worked well enough, but
trying extend it (or even make updates) is a nightmare. Mindwrapper
is intended to support, even promote evolutionary/incremental
design and development.

···

--- Magnus Lycka <magnus@thinkware.se> wrote:

At 08:02 2003-03-27 -0600, Patrick K. O'Brien wrote:

=====
Donnal Walter
Arkansas Children's Hospital

Yes, I've also been impressed with Mindwrapper as well as with PythonCard. The pythonic syntax and the ease of use is very sweet. However what concerns me is how many layers are involved. I mean, wxPython is a layer on top of wxWindows which is a layer on top of GTK (or winapi). Adding another layer seems like one too many. However Mindwrapper looks so good that I probably would tolerate another layer.

OTOH, something that Chris Barker said recently made a lot of sense to me "Is it time to write a thicker, more "pythonic" wrapper around wxWindows?" All things equal, this makes better sense to me than adding another layer.

Bob

···

At 08:02 AM 3/27/2003 -0600, you wrote:

Donnal Walter <donnalcwalter@yahoo.com> writes:

> Well, mine is a success story too. I converted Mindwrapper over to
> the wx package with no difficulty whatsoever. It did not change
> the external API, but the advantage for me is that now the mw.Frame
> 'presenter' wraps the wx.Frame 'view', mw.Panel wraps wx.Panel, and
> so on. I like the symmetry.

BTW, I did look at Mindwrapper the other day and was quite impressed.
I'm not sure I'll have time to develop an app with it, but the code
looked very clean and you obviously have a keen sense of how to
produce good-looking interfaces. And I like how you simplified the
use of sizers. Good job.

Bob Klimek <klimek@grc.nasa.gov> writes:

>BTW, I did look at Mindwrapper the other day and was quite impressed.
>I'm not sure I'll have time to develop an app with it, but the code
>looked very clean and you obviously have a keen sense of how to
>produce good-looking interfaces. And I like how you simplified the
>use of sizers. Good job.

Yes, I've also been impressed with Mindwrapper as well as with
PythonCard. The pythonic syntax and the ease of use is very
sweet. However what concerns me is how many layers are involved. I
mean, wxPython is a layer on top of wxWindows which is a layer on top
of GTK (or winapi). Adding another layer seems like one too
many. However Mindwrapper looks so good that I probably would tolerate
another layer.

OTOH, something that Chris Barker said recently made a lot of sense to
me "Is it time to write a thicker, more "pythonic" wrapper around
wxWindows?" All things equal, this makes better sense to me than
adding another layer.

I think there might still be a need for the layers provided by
PythonCard and Mindwrapper. But I doubt either project would mind if
wxPython itself sprouted a more "pythonic" wrapper. That would keep
PythonCard and Mindwrapper and all the other projects from having to
reinvent the wheel in this regard, allowing them to focus on their
true mission.

Here is what I see as a possible approach:

1. Clean up and document the existing API. I've been working on this
   and will talk about this more in another message. This basic API
   needs to be concerned with backwards compatibility and conforming
   to the wxWindows API.

2. Create a more "Pythonic" API that is part of the wxPython standard,
   but isn't concerned with matching the wxWindows API. It will
   likely make use of the existing API, but whether it is coded in
   Python or C++, or makes use of the existing API or not, are
   implementation details.

I think the success of this "Pythonic" API will depend on its adoption
by projects like PythonCard, Mindwrapper, Boa, wxGlade, wxDesigner,
PyFrame, wxpypropdist, etc. So these folks should definitely have a
hand in its design and development.

···

At 08:02 AM 3/27/2003 -0600, you wrote:

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

Well, it is clearly not limited to pediatrics and not necessarily
limited to clinical applications, although that is my focus. Yes,
it is definitely geared toward forms-based applications, especially
data-centric (but not data-intensive) apps.

Which is what most programmers write programs for I guess...

I do imagine that that it's important not to be too narrow
though. Even if most is done with labels and text entry fields,
there will certainly be times when graphs and other ways of
visualizing or entering data will be beneficial.

Yes, I would like to join forces at some point. Unfortunately, the
two architectures are enough different that I don't see a clear way
to do so in the near future, and my immediate priority is to get
some custom applications written for our NICU. The main reason I
decided to create Mindwrapper instead of using PythonCard is the
absolute need for data modeling. The second reason is the relative
desire for relative positioning.

I can understand that. But I imagine there are parts of PythonCard
that you could use. Honestly, I haven't looked very closely at
either PythonCard or Mindwrapper, but I from that little tutorial
I got a feeling of a focus and purpose, while PythonCard seems to
have become something entirely different than it was meant to be...
(Then one can also discuss whether that is good or bad... :slight_smile:

We need to talk. My interest in Python/wxPython grew out of an
Excel/VBA program for neonatal hyperalimentation that I wrote a
number of years ago. That application has worked well enough, but
trying extend it (or even make updates) is a nightmare. Mindwrapper
is intended to support, even promote evolutionary/incremental
design and development.

Funny!

The first thing I said when I was asked to help with this
was that this would be a problem. The paediatrician who
developed the Excel app needed some help with more advanced
stuff, like VBA. I immediately said that the worst problem
was that he was mixing code and data, and that every upgrade
would be difficult. We are now moving all data to an external
SQL database, and that removes the worst problem. There are
a lot of other problems with Excel apps though. I know, I failed
to create that great Excel app already a decade ago! :wink: Except
for what you said, I also read this in a book I just bought.
(Writing Excel Macros with VBA):

"The code in this book has been carefully tested by at least three
individuals ... I have tested the code on more than one machine ...
Unfortunately, all three of us have run into some deviations from expected
behavior (that is, the code doesn't seem to work as advertised, or at all)
as well as some inconsistencies in code behavior (that is, the code works
differently on different systems or at different times)."

Why am I not surprised?

My client used to write BASIC as a kid, and I think he might
be persuaded to try Python in time. We agreed that it was
reasonable to see the Excel version as a prototype. AFAIK,
he has a very limited budget for this though, and no prior
Python experience.

This application lets the nurses enter weight, breat milk analysis
etc and the amounts of all the nutrition sources prescribed and
given to the baby. It will then calculate if the baby got too
much or too little of fluid, energy, fat, protein, minerals etc.

···

At 07:16 2003-03-27 -0800, you wrote:

--
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se

This wasn't intended for the list, sorry. (I'm not so sure
that setting reply-to to the list is such a good idea for
a mailing list, but never mind. I should remember to always
check the headers...)

···

At 02:03 2003-03-28 +0100, I wrote:

Which is what most programmers write programs for I guess...

--
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se

I do imagine that that it's important not to be too narrow
though. Even if most is done with labels and text entry fields,
there will certainly be times when graphs and other ways of
visualizing or entering data will be beneficial.

Yes, graphs would be especially helpful in the kinds of apps I hope
to create. This is definitely on my list. When I get the time, I
will take a closer look at incorporating wxPyPlot, for example,
among other things. Other kinds of visual displays of information
are of interest to me too.

As far as data entry is concerned, I am interested in using
sliders, spin buttons, drop down lists (wx.Choice) and other
techniques for minimizing keyboard input. Some of my users are
interesting in trying out tablet-style notebooks.

[snip]

My client used to write BASIC as a kid, and I think he might
be persuaded to try Python in time. We agreed that it was
reasonable to see the Excel version as a prototype. AFAIK,
he has a very limited budget for this though, and no prior
Python experience.

This application lets the nurses enter weight, breast milk
analysis etc and the amounts of all the nutrition sources
prescribed and given to the baby. It will then calculate if
the baby got too much or too little of fluid, energy, fat,
protein, minerals etc.

I will reply in more detail off-line, but this would appear to be
an excellent opportunity for us to collaborate. BTW, Mindwrapper is
designed for limited budgets. :slight_smile:

    "Custom applications are cost-effective over few copies,
    situation-specific, home-grown, and evolving."

Regards,

···

Magnus Lycka <magnus@thinkware.se> wrote:

=====
Donnal Walter
Arkansas Children's Hospital

Just in case this info is useful -
Hitachi is planning to introduce Linux-based Tablet PCs

http://siliconvalley.internet.com/news/article.php/2168241

···

At 06:32 2003-03-28 -0800, Donnal wrote:

... Some of my users are
interesting in trying out tablet-style notebooks.
...

--
John Hall <wexsessa@telusplanet.net>
Calgary, Alberta, Canada.
"Helping People Prosper in the Information Age".

Either I'm missing something, or I've found a bug in wxGenericDirCtrl.

Platform: Windows 2000
wxPython version: 2.2.2

I am building a file manager, and am in the process of adding a way to
create new folders.

To illustrate the problem, create a folder called "Test1" on one of your
drives. Start the attached ap, and go to that folder.

If you create a folder within Test1 called Test2, the folder is created both
in the file system and in the GenericDirCtrl, and the GenericDirCtrl changes
to that folder without difficulty. Good. This is what I want.

However, if you now go back to Test1 and create Test3, the new folder is
created on the file system, but is not visible in the GenericDirCtrl, and
the GenericDirCtrl does not change to that folder. Furthermore, if you
collapse the Test1 node, the expander button disappears. You can get to all
of the folders in the OTHER GenericDirCtrl, but not in the one that was live
when the Test3 folder was created.

So, is this a bug in the control, or is there some sort of Refresh() method
I'm missing? I've tried various combinations of Refresh() and Update() on
the GenericDirCtrl and on the GenericDirCtrl.GetTreeCtrl() with no success.

TIA for your help.

David Woods
Wisconsin Center for Education Research
University of Wisconsin, Madison

GenericDirCtrlProblem.py (9.9 KB)

Magnus Lycka wrote:

This wasn't intended for the list, sorry.

Personally, I enjoyed readin g it. In fact, I'm plannin gon passing on
the quote about Excel to my co-workers.

(I'm not so sure

that setting reply-to to the list is such a good idea for
a mailing list,

Well, the Python-Mac list is set up the other way around, and I am
constantly accidentally sending personal emial, when I meant to send to
the list. I reply to the list far more often, so I like this method
better.

-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

David Woods wrote:

Either I'm missing something, or I've found a bug in wxGenericDirCtrl.

Platform: Windows 2000
wxPython version: 2.2.2

You should really update, this version is *very* old.

I am building a file manager, and am in the process of adding a way to
create new folders.

To illustrate the problem, create a folder called "Test1" on one of your
drives. Start the attached ap, and go to that folder.

If you create a folder within Test1 called Test2, the folder is created both
in the file system and in the GenericDirCtrl, and the GenericDirCtrl changes
to that folder without difficulty. Good. This is what I want.

However, if you now go back to Test1 and create Test3, the new folder is
created on the file system, but is not visible in the GenericDirCtrl, and
the GenericDirCtrl does not change to that folder. Furthermore, if you
collapse the Test1 node, the expander button disappears. You can get to all
of the folders in the OTHER GenericDirCtrl, but not in the one that was live
when the Test3 folder was created.

You can workaround this problem like this:

       if newFolder.ShowModal() == wxID_OK:
          folder = os.path.join(target.GetPath(), newFolder.GetValue())
          os.mkdir(folder)
          itemId = target.GetTreeCtrl().GetSelection() # ***
          target.GetTreeCtrl().CollapseAndReset(itemId) # ***
          print 'Target Path should be ' + folder
          target.SetPath(folder)
          print 'Target Path is ' + target.GetPath()
       newFolder.Destroy()

···

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

Thanks Robin. Worked like a charm, although I'm sure you knew that it
would.

David Woods
Wisconsin Center for Education Research
University of Wisconsin, Madison

···

-----Original Message-----
From: Robin Dunn [mailto:robin@alldunn.com]
Sent: Monday, March 31, 2003 4:32 PM
To: wxPython-users@lists.wxwindows.org
Subject: Re: [wxPython-users] wxGenericDirCtrl problem

David Woods wrote:

Either I'm missing something, or I've found a bug in wxGenericDirCtrl.

Platform: Windows 2000
wxPython version: 2.2.2

You should really update, this version is *very* old.

I am building a file manager, and am in the process of adding a way to
create new folders.

To illustrate the problem, create a folder called "Test1" on one of your
drives. Start the attached ap, and go to that folder.

If you create a folder within Test1 called Test2, the folder is created

both

in the file system and in the GenericDirCtrl, and the GenericDirCtrl

changes

to that folder without difficulty. Good. This is what I want.

However, if you now go back to Test1 and create Test3, the new folder is
created on the file system, but is not visible in the GenericDirCtrl, and
the GenericDirCtrl does not change to that folder. Furthermore, if you
collapse the Test1 node, the expander button disappears. You can get to

all

of the folders in the OTHER GenericDirCtrl, but not in the one that was

live

when the Test3 folder was created.

You can workaround this problem like this:

       if newFolder.ShowModal() == wxID_OK:
          folder = os.path.join(target.GetPath(), newFolder.GetValue())
          os.mkdir(folder)
          itemId = target.GetTreeCtrl().GetSelection() # ***
          target.GetTreeCtrl().CollapseAndReset(itemId) # ***
          print 'Target Path should be ' + folder
          target.SetPath(folder)
          print 'Target Path is ' + target.GetPath()
       newFolder.Destroy()

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

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org