I have Python 2.7, wxPython 2.8 (64-bit) installed on Win7.
There is no 64-bit version of the Demo? Only a 32-bit? When I run it, my computer pretty much locks up.
I am trying to learn wxPython and thus far, what I have written seems to run OK, so I must have the correct versions of Python and wxPython installed but when I run the Demo to get some clues about new GUI elements it just locks up my computer.
I have Python 2.7, wxPython 2.8 (64-bit) installed on Win7.
There is no 64-bit version of the Demo? Only a 32-bit? When I run it, my
computer pretty much locks up.
The wxPython demo is pure-Python and, as far as I know, it is
completely independent of the machine architecture (and also of the
platform, as it runs on all 3 major platforms wxPython supports).
I am trying to learn wxPython and thus far, what I have written seems to run
OK, so I must have the correct versions of Python and wxPython installed but
when I run the Demo to get some clues about new GUI elements it just locks
up my computer.
Is there any way around this?
Try this:
1) Open a DOS command window;
2) Go to the folder in which you installed the wxPython demo;
3) Type "python Main.py"
4) See if there is any traceback or error in the DOS command window
and maybe report them back here.
I would also suggest you to switch to wxPython 2.9.4 (and its
corresponding demo).
Doing the DOS thing just gives an error message saying it cannot find the options file (probably have HOME set incorrectly?).
Only reason I didn’t try 2.9.4 is that the web-site states it is a development release and not a “stable” release.
But it works! So thanks
Peter
···
On Tuesday, August 28, 2012 4:57:45 PM UTC+10, Peter Milliken wrote:
I have Python 2.7, wxPython 2.8 (64-bit) installed on Win7.
There is no 64-bit version of the Demo? Only a 32-bit? When I run it, my computer pretty much locks up.
I am trying to learn wxPython and thus far, what I have written seems to run OK, so I must have the correct versions of Python and wxPython installed but when I run the Demo to get some clues about new GUI elements it just locks up my computer.
Doing the DOS thing just gives an error message saying it cannot find the
options file (probably have HOME set incorrectly?).
Only reason I didn't try 2.9.4 is that the web-site states it is a
development release and not a "stable" release.
<rant>
Branding the odd-named releases as "unstable" was the biggest mistake
the wxWidgets team of developers could possibly have ever done - for
many reasons. You can call 2.9.0.1 "unstable" as it has maybe just
been released, but 2.9.4? The 2.9 series is now 2.5 *years* old, and I
use it every day exclusively. There is no instability whatsoever.
I wonder what it will take in terms of discussions on wx-dev to
convince the lead developers to finally give up on this nomenclature
and permanently erase from the websites (and from the face of the
earth) the "unstable" branding...
</rant>
But it works! So thanks
You're welcome
···
On 28 August 2012 10:09, Peter Milliken wrote:
On Tuesday, August 28, 2012 4:57:45 PM UTC+10, Peter Milliken wrote:
I have Python 2.7, wxPython 2.8 (64-bit) installed on Win7.
There is no 64-bit version of the Demo? Only a 32-bit? When I run it, my
computer pretty much locks up.
I am trying to learn wxPython and thus far, what I have written seems to
run OK, so I must have the correct versions of Python and wxPython installed
but when I run the Demo to get some clues about new GUI elements it just
locks up my computer.
I have to agree - do you think that we could successfully argue for
re-badging as "Active" as opposed to "Maintenance" there would be sooo
much less opposition to the idea of using an "Active" branch than an
"Unstable" one....
Gadget/Steve
···
On 28/08/2012 9:16 AM, Andrea Gavana wrote:
On 28 August 2012 10:09, Peter Milliken wrote:
2.9.4 seems to work for me - thanks
Doing the DOS thing just gives an error message saying it cannot find the
options file (probably have HOME set incorrectly?).
Only reason I didn't try 2.9.4 is that the web-site states it is a
development release and not a "stable" release.
<rant>
Branding the odd-named releases as "unstable" was the biggest mistake
the wxWidgets team of developers could possibly have ever done - for
many reasons. You can call 2.9.0.1 "unstable" as it has maybe just
been released, but 2.9.4? The 2.9 series is now 2.5 *years* old, and I
use it every day exclusively. There is no instability whatsoever.
I wonder what it will take in terms of discussions on wx-dev to
convince the lead developers to finally give up on this nomenclature
and permanently erase from the websites (and from the face of the
earth) the "unstable" branding...
We probably need to start by figuring out a new way to describe the fact that the API in the even numbered releases is not supposed to change. As long as that is called a "stable" API then the others will automatically and naturally be considered "unstable" even if it is really just that the API that is being allowed to change and not the general level of bugginess.
···
On 8/28/12 1:16 AM, Andrea Gavana wrote:
On 28 August 2012 10:09, Peter Milliken wrote:
Branding the odd-named releases as "unstable" was the biggest mistake
the wxWidgets team of developers could possibly have ever done - for
many reasons. You can call 2.9.0.1 "unstable" as it has maybe just
been released, but 2.9.4? The 2.9 series is now 2.5 *years* old, and I
use it every day exclusively. There is no instability whatsoever.
I wonder what it will take in terms of discussions on wx-dev to
convince the lead developers to finally give up on this nomenclature
and permanently erase from the websites (and from the face of the
earth) the "unstable" branding...
Branding the odd-named releases as "unstable" was the biggest mistake
the wxWidgets team of developers could possibly have ever done - for
many reasons. You can call 2.9.0.1 "unstable" as it has maybe just
been released, but 2.9.4? The 2.9 series is now 2.5 *years* old, and I
use it every day exclusively. There is no instability whatsoever.
I wonder what it will take in terms of discussions on wx-dev to
convince the lead developers to finally give up on this nomenclature
and permanently erase from the websites (and from the face of the
earth) the "unstable" branding...
We probably need to start by figuring out a new way to describe the fact
that the API in the even numbered releases is not supposed to change. As
long as that is called a "stable" API then the others will automatically and
naturally be considered "unstable" even if it is really just that the API
that is being allowed to change and not the general level of bugginess.
Would "frozen" or "frozen API" be a better adjective than "stable" in this case?
I too have previously thought "unstable" in the wx-sense was similar
to the "bleeding-edge-may-be-buggy-not-responsible-if-your-hard-drive-crashes-don't-blame-me"
sense that others commonly use it in software development.
Just a thought. Thanks.
Cheers,
Scott.
···
On Tue, Aug 28, 2012 at 1:29 PM, Robin Dunn <robin@alldunn.com> wrote:
How about Fossilized, (i.e. API set in stone), as opposed to Live?
Gadget/Steve
···
On 28/08/2012 10:56 PM, grunculus wrote:
Hi Robin and All,
On Tue, Aug 28, 2012 at 1:29 PM, Robin Dunn <robin@alldunn.com> wrote:
On 8/28/12 1:16 AM, Andrea Gavana wrote:
On 28 August 2012 10:09, Peter Milliken wrote:
Branding the odd-named releases as "unstable" was the biggest mistake
the wxWidgets team of developers could possibly have ever done - for
many reasons. You can call 2.9.0.1 "unstable" as it has maybe just
been released, but 2.9.4? The 2.9 series is now 2.5 *years* old, and I
use it every day exclusively. There is no instability whatsoever.
I wonder what it will take in terms of discussions on wx-dev to
convince the lead developers to finally give up on this nomenclature
and permanently erase from the websites (and from the face of the
earth) the "unstable" branding...
We probably need to start by figuring out a new way to describe the fact
that the API in the even numbered releases is not supposed to change. As
long as that is called a "stable" API then the others will automatically and
naturally be considered "unstable" even if it is really just that the API
that is being allowed to change and not the general level of bugginess.
Would "frozen" or "frozen API" be a better adjective than "stable" in this case?
I too have previously thought "unstable" in the wx-sense was similar
to the "bleeding-edge-may-be-buggy-not-responsible-if-your-hard-drive-crashes-don't-blame-me"
sense that others commonly use it in software development.
How about Fossilized, (i.e. API set in stone), as opposed to Live?
Gadget/Steve
I think the term “maintenance” or maybe LTS (long-term support) like Ubuntu calls its stable releases makes sense. Frozen works too. Or maybe what Python does where it calls certain releases “security-fix only release” like it does with Python 2.6