wxPython Or Tkinter Advise PLEASEEEEEEEEE

[Learn Python]

hi all,

I know that this is a redundant question.
I started off with Tkinter from
Programming Python book ( explained in detail).
I liked it.

Then i stumbled across wxPython and the kind of qoutes/comments i found on
the web site were so impressive.
for eg :

"Why the hell hasn't wxPython become the standard GUI for Python yet?"

-- Eric S. Raymond

Am so confused???
the docs were OK. There does'nt seem to be a book on it either :-(
Then can anyone answer the above question:
"Why the hell hasn't wxPython become the standard GUI for Python yet?"
:-)

what s'd i be doing? I have to say here that i dont use python @ work but am
learning out of my own interest. But w'd like to master atleast one GUI
package.

thanks in advance,
karthik

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

[Hans Nowak]

>I know that this is a redundant question.
>I started off with Tkinter from
>Programming Python book ( explained in detail).
>I liked it.
>
>Then i stumbled across wxPython and the kind of qoutes/comments i found on
>the web site were so impressive.
>for eg :
>
>"Why the hell hasn't wxPython become the standard GUI for Python yet?"
>
>-- Eric S. Raymond
>
>Am so confused???
>the docs were OK. There does'nt seem to be a book on it either :-(
>Then can anyone answer the above question:
>"Why the hell hasn't wxPython become the standard GUI for Python yet?"
>:-)
>
>what s'd i be doing? I have to say here that i dont use python @ work but am
>learning out of my own interest. But w'd like to master atleast one GUI
>package.

This question has been asked and answered before, but here's my take on it.

Both GUIs have benefits and drawbacks. Tkinter ships with Python, so on most
systems it's almost guaranteed to be there. There's also at least one book
about it (not sure when Fredrik's book is coming out...). On the flip side, I
found that it's often slower than wxPython, and lacks widgets/components that
wxPython has (this is more of a personal issue, but I missed tables/grids like
I am used to in Delphi, to name something).
wxPython has (AFAIK) no books yet, but comes with an impressive demo program,
that gets you started easily; there's also the wxWindows documentation
(although this isn't always 100% applicable to wxPython; some methods are
different, etc.).
An important drawback (I think) is that wxPython will always be out later than
new Python versions. If 2.2 final comes out, some time will pass before a
version of wxPython arrives that will support this. This is inevitable because
development on the new wxPython version cannot really start until the official
Python is out. However, this means that you cannot immediately upgrade to a
new Python version without breaking your GUI code (unless you keep the older
Python version around, I guess).

I am currently using wxPython for my GUI projects, for the reasons mentioned
above. That is not to say I will never do anything in Tkinter in the future,
but currently it has my favor.

HTH,

--Hans Nowak

[Sheila King]

On Mon, 13 Aug 2001 07:29:53 +0000, "Learn Python"
<learn...@hotmail.com> wrote in comp.lang.python in article
<mailman.997687902...@python.org>:

:Am so confused???

:the docs were OK. There does'nt seem to be a book on it either :-(
:Then can anyone answer the above question:
:"Why the hell hasn't wxPython become the standard GUI for Python yet?"

In addition to the comments by Hans Nowak, let me point out that Tkinter
runs on every platform that Python runs on, whereas wxPython does not.

I tried making this decision a few months ago, myself. When I started
reading Programming Python, 2nd ed., the decision was pretty much made
for me. The book has many, many examples with Tkinter and they seem to
work very well. For me, having a book to explain things is really
necessary. Maybe I'll work with wxPython at some point in the future,
but for now there is not enough information on it to get me over the
learning hurdle.

--
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org/

[Kevin Altis]

The comments about tkinter shipping with Python are valid. The question is
often, why doesn't wxPython get included as part of the Python distribution?
One of these days, Python needs to throw off the shackles of tcl/tkinter
(let the flames begin).

Anyway, when we started the PythonCard project:
http://pythoncard.sourceforge.net/

we discussed having a generic framework that works on top of any of the
available GUI libraries for Python. In order to make faster progress, we
decided to leverage the most powerful one that was free and worked with the
OSes that have the largest installed base (Windows, Linux). We ended up
building the framework so that we can probably plug tkinter or anygui
(another project underway) later on, but wxPython works so well, I'm not
sure we'll be inclined to go that way. The big downside to wxPython for me
is that the port to the Macintosh is not complete yet, though wxWindows,
which wxPython is built on top of, is usable today. I get mixed reports on
Solaris, but I think it works there too.

Other people have mentioned the confusing documentation, which is geared
towards C++. What we ended up doing was wrapping the event model and the
major widgets in order to hide what is often the most complex part of using
wxPython, so as a user of the PythonCard framework, you never have to look
at the wxPython docs. Of course, that means we have to do our own docs at
some point, but though we're only doing the prototype right now, we've
already started the process.

You can see some sample screenshots here:
http://pythoncard.sourceforge.net/samples.html

None of the samples, with the exception of the turtle library, took me more
than a day to build and usually the time is more like fifteen minutes
(minimal.py) to a few hours, including layout work. I don't suggest you
commit a big project to PythonCard today since the API is still moving, but
it is more than adequate for building your own small apps and saving
yourself the grief that is tk.

ka

"Learn Python" <learn...@hotmail.com> wrote in message
news:mailman.997687902...@python.org...

[Russell E. Owen]

They both work, so I think you'll do fine either way.

Here are some considerations. I have used Tk much more than Wx, so have
much less to say about Wx. Contributions would be most welcome.

Tk:
+ runs on more different platforms (e.g. Mac) than Wx and is more mature
+ has a nice Canvas widget
+ nice file event support for networking applications
(I don't know about this on Wx)
+ tons of flexibility for button sizes, font sizes, etc.
+ lots of nice layout options
+ lots of books are available on Tk, and at least one on Tkinter
- is fairly slow (you end up running a Tk interpreter as well as the
Python interpreter)
- has brain-dead support for copy and paste
- has somewhat clumsy mapping from Pyton to Tk. For instance a lot of
times you end up with a Tk name that you have to then convert to a
widget before you can do anything with it. I suspect much of this is
because Tk is not object-oriented.
- bizarre inconsistencies in Tk -- different widgets often have
different ways of doing the same things
- lack of a nice multi-line text display widget (that the program can
write to but users cannot alter the text); this is a famouse Tk FAQ, to
which the answer is to (gag) enable updates (which means the user can
manipulate the text), write your text, then disable updates again
- some things are broken on the Mac (menus, file events)

Wx:
+ Wx is reported to be much faster than Tk
+ Python is basically an equal partner to the C++ code, and Wx is
object-oriented, so the mapping appears to be nicer from Python to Wx
- Wx relies on unique ID numbers to describe events (gag)
- no current Mac releases, though if you are willing to check code out
of CVS you can probably get the Mac stuff running (depending on what day
you check it out)
o Wx includes a lot of tools that Python already has; I'm not sure how
this overlap works out

Also, if you care, Wx looks more like Windows, whereas Tk looks more
like unix X.

The Python 2.1 Bible, by Brueck and Tanner, (a very nice book) has a
short chapter on WxPython which should get you going. It also has a
short chapter on Tk, but it sounds as if you may be far enough along to
not need that.

-- Russell

[Robert Amesz]

Russell E. Owen wrote:

> They both work, so I think you'll do fine either way.
>
> Here are some considerations. I have used Tk much more than Wx, so
> have much less to say about Wx. Contributions would be most
> welcome.
>
> Tk:
> + runs on more different platforms (e.g. Mac) than Wx and is more
> mature

I don't know all that much about Tkinter, but from what I've seen
Tkinter programs are somewhat smaller than their wxPython counterparts.
However, it seems that from wxPython you have more control over some
things. Also, wxPython seems to have a richer set of controls and
standard dialogs than Tkinter, presuming Fredrik Lundh's reference in
his tutorial is anywhere near complete.

> + has a nice Canvas widget

From what I've read, a Canvas is just something you can draw on. You
can do that easily on a wxWindow by making a handler for paint-events:
blitting images, writing text, drawing, you can do it all in such a
handler. However, don't expect C++ speed from a Python paint-handler.

> + nice file event support for networking applications
> (I don't know about this on Wx)

Actually, I don't even know what you mean by 'file event'.

> + tons of flexibility for button sizes, font sizes, etc.

"Me 2", states wxPython boldly.

> + lots of nice layout options

"Me 2", snickers wxPython knowingly.

> + lots of books are available on Tk, and at least one on Tkinter

"Ah, there you have me", sighs wxPython forlornly.

Considering the number of times people ask for a book on wxPython, this
could be winner if someone were to write it. If I considered myself
anywhere near an expert on the subject, (and had the time), I might
feel tempted to do so. But I'm just a dabbler...

> - is fairly slow (you end up running a Tk interpreter as well as
> the Python interpreter)
> - has brain-dead support for copy and paste

That's something which wxPython knows how to handle. (Drag'n'Drop too,
BTW.)

> - has somewhat clumsy mapping from Pyton to Tk. For instance a lot
> of times you end up with a Tk name that you have to then convert to
> a widget before you can do anything with it. I suspect much of this
> is because Tk is not object-oriented.
> - bizarre inconsistencies in Tk -- different widgets often have
> different ways of doing the same things
> - lack of a nice multi-line text display widget (that the program
> can write to but users cannot alter the text); this is a famouse Tk
> FAQ, to which the answer is to (gag) enable updates (which means
> the user can manipulate the text), write your text, then disable
> updates again - some things are broken on the Mac (menus, file
> events)
>
> Wx:
> + Wx is reported to be much faster than Tk
> + Python is basically an equal partner to the C++ code, and Wx is
> object-oriented, so the mapping appears to be nicer from Python to
> Wx

> - Wx relies on unique ID numbers to describe events (gag)

Not really. Unique ID number are only needed if you want to call
different event-handlers for the same event-type _from the same
window_. Normally parent windows handle some of the events for/from
their children, which usually controls (e.g. buttons). If those
controls have the same ID number they have to share the same event
handler(s). I think it is possible to determine the target window for
an event without knowing the ID number, but that could be tricky for
several reasons.

Having said that, wxPython will generate unique ID's for its window
objects if you set those to -1 (often, that's the default value
anyway), and it's dead easy to get the ID from a window.

A convenient (well, I use it) idiom would be something like this, as
part of the __init__() function of the parent window:

self.a_button = wxButton(self, -1, "Press Me")
EVT_BUTTON(self, self.a_button.GetId(), self.OnClickEventFunction)

So, doing away with the IDs and associating the event handler directly
with the button-reference would mean we could lose the '-1,' in the
first line and the '.GetId()' in the second. Not a huge saving,
although it would look cleaner. Furthermore, using duplicate ID numbers
can sometimes be helpful: a toolbar-button, for instance, can be
handled by a menu event handler if the IDs are the same.

> - no current Mac releases, though if you are willing to check code
> out of CVS you can probably get the Mac stuff running (depending on
> what day you check it out)
>
> o Wx includes a lot of tools that Python already has; I'm not sure
> how this overlap works out

To be honest, I'm not too sure Robin Dunn bothered to python-wrap all
the wxWindows stuff for which there's already something in the Python
library. I don't think it's a great issue, unless you specifically use
wxPython as a rapid prototyping system for wxWindows.

> Also, if you care, Wx looks more like Windows, whereas Tk looks
> more like unix X.

WxWindows (and consequently wxPython) tries to get the look-and-feel of
the platform it's running on, by using native widgets as much as
possible. On Windows the native look-and-feel is excellent, that's
certainly true.

> The Python 2.1 Bible, by Brueck and Tanner, (a very nice book) has
> a short chapter on WxPython which should get you going. It also has
> a short chapter on Tk, but it sounds as if you may be far enough
> along to not need that.

The best source of examples and a good place to pinch some code from is
the wxPython demo.

Robert Amesz

[Christopher Barker]

Robert Amesz wrote:

> > + has a nice Canvas widget
>
> From what I've read, a Canvas is just something you can draw on. You
> can do that easily on a wxWindow by making a handler for paint-events:
> blitting images, writing text, drawing, you can do it all in such a
> handler. However, don't expect C++ speed from a Python paint-handler.

The tk Canvas is much more than a place to draw things. WX does have
fine facilities for drawing to0 a panel or scrolled window, but it is
kind of slow if you have a lot of objects to draw(100s works OK 1000s is
pretty darn pokey).

Aside from speed, there is no easy way to draw something in wx and link
events to clicking on the object you draw. You would have to do all the
hit-test code yourself. Draggin around bitmaps is a little harder as
well, but it can be done, and Robin has a nice demo of it in the
wxPython demo.

There is work being done on a wxCanvas, but it has not yet been wrapped
for Python, and I'm not sure it's ready to be. If it does make it to
prime time, it looks pretty nice, and is a zoomable and scrollable
vector drawing surface: try that, TK!

All in all, I like wx a lot, although the wrappes around the C++ are a
bit thin. This is good because you can easily ttranslate the C++ docs
into Python, but the code ends up being a bit verbose, and not terribly
Pythonic. this really is a minor quibble, however.

-Chris

--

Christopher Barker,
Ph.D.
cba...@jps.net --- --- ---
http://www.jps.net/cbarker -----@@ -----@@ -----@@
------@@@ ------@@@ ------@@@
Water Resources Engineering ------ @ ------ @ ------ @
Coastal and Fluvial Hydrodynamics ------- --------- --------
------------------------------------------------------------------------
------------------------------------------------------------------------

[Klaus-G. Meyer]

"Russell E. Owen" <ow...@astrono.junkwashington.emu> schrieb im Newsbeitrag
news:9l97d2$2pkg$1...@nntp6.u.washington.edu...

> They both work, so I think you'll do fine either way.
>
> Here are some considerations. I have used Tk much more than Wx, so have
> much less to say about Wx. Contributions would be most welcome.

what about printing with tkinter or wxpython?

text, graph, picture?

[Clive Page]

In article <MmVd7.115$Pm5.1...@news.uswest.net>,

Kevin Altis <al...@semi-retired.com> wrote:
>The comments about tkinter shipping with Python are valid. The question is
>often, why doesn't wxPython get included as part of the Python distribution?
>One of these days, Python needs to throw off the shackles of tcl/tkinter
>(let the flames begin).

That would be very nice. I've used wxPython on Windows where there are
ready-built binaries, and it seems an excellent package, easy to use,
robust, fast, with powerful facilities. But I've been trying to build it
on Solaris or Linux, and have so far failed to get it working on either.
The build process seems more complicated and flakier than anything that
I've ever encountered before, and judging by messages on the wxPython
list, I'm not the only one having trouble. Tk has the advantage of coming
built-in with Python, but I think that's about its only advantage.

>> "Why the hell hasn't wxPython become the standard GUI for Python yet?"
>>
>> -- Eric S. Raymond

I think it's because it's so darned difficult to build and install.

--
Clive Page c...@le.ac.uk

[Paul Boddie]

Sheila King <she...@spamcop.net> wrote in message news:<q2sfnt4052lvehf38...@4ax.com>...

> In addition to the comments by Hans Nowak, let me point out that Tkinter
> runs on every platform that Python runs on, whereas wxPython does not.

I suspect that this statement is absolutely not true, unless Tkinter
makes use of toolkits other than Tk, which I doubt. Of course, Tkinter
works on Windows, Mac and many UNIX-like systems, and it's not that
likely that any given inquirer is asking for advice on user interface
toolkits for platforms other than those. Moreover, it's more Python's
fault for being so portable that the above statement is rendered
untrue. However, "all" versus "the big three, four, or five" is still
a distinction worth making, in my opinion.

wxPython looks very nice and I have seen it running on Solaris and
Linux, but then Tkinter has that lovely canvas widget...

Paul

[Chris Barker]

Clive Page wrote:

> >> "Why the hell hasn't wxPython become the standard GUI for Python yet?"
> >>
> >> -- Eric S. Raymond
>
> I think it's because it's so darned difficult to build and install.

This is really kind of a chicken-egg problem. Many of the advantages
that people have stated about TK essentially boil down to the fact that
it is the "standard" GUI for Python: It comes with the main Python
library, it is introduced in all the books, etc. So, essentially, what
we are saying is:

"TKinter is the standard GUI for Python because it is the standard GUI
for Python."

I think there is a little more to it than that:

TKinter has been around a lot longer that wxPython (which is why it was
established as a semi-standard in the first place)

wxPython is under far more active development: new versions come out
faster that new versions of Python. Personally, I think it is stable
enought to be part of the standard library now, but it wasn't a couple
of years ago.

There are a couple of missing elements still: a good interactive Canvas
being the most obvious, I'm sure there are others. (to be fair, wx has a
number of nice high level widgets that TK doesn't, most notably the
wxGrid)

-Chris

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

[Alexander V. Voinov]

Hi All,

Chris Barker wrote:

> Clive Page wrote:
>
> > >> "Why the hell hasn't wxPython become the standard GUI for Python yet?"
> > >>
> > >> -- Eric S. Raymond
> >
> > I think it's because it's so darned difficult to build and install.
>
> This is really kind of a chicken-egg problem. Many of the advantages
> that people have stated about TK essentially boil down to the fact that
> it is the "standard" GUI for Python: It comes with the main Python
> library, it is introduced in all the books, etc.

Yes, the Windows installer should provide a special "icon" to give the user an
option to install wxPython instead of Tkinter. But for this the user must pay
by having two more icons, say for Tix widget set and togl for PyOpenGL.

Alexander

[Alexander V. Voinov]

Hi All,

Robert Amesz wrote:

> Russell E. Owen wrote:
>
> > They both work, so I think you'll do fine either way.
> >
> > Here are some considerations. I have used Tk much more than Wx, so
> > have much less to say about Wx. Contributions would be most
> > welcome.
> >
> > Tk:
> > + runs on more different platforms (e.g. Mac) than Wx and is more
> > mature
>
> I don't know all that much about Tkinter, but from what I've seen
> Tkinter programs are somewhat smaller than their wxPython counterparts.
> However, it seems that from wxPython you have more control over some
> things.

In general wxPython provides a rather thin if at all layer over the
original C++ functionality, with few exceptions (like Python applets in the
html view widget) which may not be in the everyday use by everybody.
Closely following the lines of the underlying toolkit is good for some
users but is bad for the others. Anyway everybody has a choice.

Alexander

[Kevin Altis]

"Alexander V. Voinov" <a...@quasar.ipa.nw.ru> wrote in message
news:3B7961E3...@quasar.ipa.nw.ru...

PythonCard provides a layer over wxPython specifically so that the user
(programmer) doesn't have to see or deal with C++ or wxPython issues. If you
want really small programs, try PythonCard where the GUI component
descriptions are broken out into resource files to avoid mixing code with
widget creation and even the event binding is handled automatically for you,
which makes for really small and easy to read programs. If you need to, you
can even fall back and mix in plain wxPython code when the PythonCard
framework doesn't provide the functionality you want.

ka

[David Eppstein]

In article <3B79632D...@home.net>,
Chris Barker <chrish...@home.net> wrote:

> There are a couple of missing elements still: a good interactive Canvas
> being the most obvious, I'm sure there are others. (to be fair, wx has a
> number of nice high level widgets that TK doesn't, most notably the
> wxGrid)

I would think a pre-built Mac port is a much more obvious omission.
--
David Eppstein UC Irvine Dept. of Information & Computer Science
epps...@ics.uci.edu http://www.ics.uci.edu/~eppstein/

[Chris Barker]

David Eppstein wrote:

> I would think a pre-built Mac port is a much more obvious omission.

Actually, Any Mac port would be nice!!

I agree: that was almost a deal breaker for me. Of course, Tk doesn't
work all that well on the Mac anyway, and MacPython was only recently
merged with the main source tree, so the lack of Mac support is probably
NOT what has kept wx from becoming more of a standard.

[Timothy Docker]

> The big downside to wxPython for me
> is that the port to the Macintosh is not complete yet, though wxWindows,
> which wxPython is built on top of, is usable today. I get mixed reports on
> Solaris, but I think it works there too.

It works fine on Solaris, with bit of autoconf/makefile tweaking (I
didn't have to change a single line of code though).

Tim

[Clive Page]

In article <3B79632D...@home.net>,
Chris Barker <chrish...@home.net> wrote:

>wxPython is under far more active development: new versions come out
>faster that new versions of Python. Personally, I think it is stable
>enought to be part of the standard library now, but it wasn't a couple
>of years ago.

Yes, on Windows, it seems to work as advertised, and it's very good.

>
>There are a couple of missing elements still: a good interactive Canvas
>being the most obvious, I'm sure there are others.

Some build instructions that an average idiot like me can follow. I've
even tried the RPMs on Linux, but they don't work either. This may be a
result of the active development, but some pointer to a stable version
which works seems essential.

(to be fair, wx has a
>number of nice high level widgets that TK doesn't, most notably the
>wxGrid)

Agree, this is really useful, and works fine.

--
Clive Page c...@le.ac.uk

[Clive Page]

In article <m4ielqe...@macquarie.com.au>,

Timothy Docker <ti...@macquarie.com.au> wrote:
>It works fine on Solaris, with bit of autoconf/makefile tweaking (I
>didn't have to change a single line of code though).

I gave up after a couple of days of tweaking. I've since found out (I
think) that I need to make sure that the wxGTK and wxPython versions are
identical, and use gmake everwhere where it tells you to use make. But I
found it hard to work out which compiler to use, i.e. C or C++, and gnu or
Sun's own. I guess I still haven't exhausted all the possibilities, I
just exhausted my own patience.

Even Python itself doesn't compile out of the box on Solaris using gcc,
only using Sun's cc, which is rather a pity.

--
Clive Page c...@le.ac.uk

[Timothy Docker]

> I gave up after a couple of days of tweaking. I've since found out (I
> think) that I need to make sure that the wxGTK and wxPython versions are
> identical, and use gmake everwhere where it tells you to use make. But I
> found it hard to work out which compiler to use, i.e. C or C++, and gnu or
> Sun's own. I guess I still haven't exhausted all the possibilities, I
> just exhausted my own patience.

Although I use suns C++ compiler for local development, I alway use gcc
for compiling python related stuff. I have a "sandbox" type of
environment that has all the gnu tools (gnu-make,bash etc) on the path
in front of the sun equivalents, in order to get stuff building in
the way the developers would have.

> Even Python itself doesn't compile out of the box on Solaris using gcc,
> only using Sun's cc, which is rather a pity.

Hmmm. It did so perfectly for me, on sol2.7 with gcc2.95.2.

Which gcc version? Which solaris version? What was you problem?

Tim

[Gerhard Häring]

On Tue, 14 Aug 2001 10:37:39 -0700, Alexander V. Voinov wrote:
>In general wxPython provides a rather thin if at all layer over the
>original C++ functionality, with few exceptions (like Python applets in the
>html view widget) which may not be in the everyday use by everybody.
>Closely following the lines of the underlying toolkit is good for some
>users but is bad for the others. Anyway everybody has a choice.

What I hate about wxPython is that it's quite frustrating to just try things
out in the interactive Python interpreter. Every few lines I get Segmentation
Faults when I do this. Then, the Python interpreter is gone and I have start
all over. That's just not the Python way of development, where I get exceptions
when I do something stupid.

Gerhard
--
mail: gerhard <at> bigfoot <dot> de registered Linux user #64239
web: http://www.cs.fhm.edu/~ifw00065/ public key at homepage
public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

[Lutz Schroeer]

I'm in the need of making the decision between TKinter and wxWindows this
week and I think I'll stay to TKinter if I will be able to get SpecTcl 1.2a3
to work on my W2K ('cause of the menu bar option).

Lutz

[Chad Franklin Netzer]

I have an app that uses Tkinter. It plots data and
allows for interactive modification of that data.
However, the Tkinter Canvas is so slow that I've also
had to support PyOpenGL rendering (which is a pain
because Togl has "issues").

One thought I've had is to switch completely to another
GUI toolkit, such as wxPython, or PyGtk. However, I
thought it might be possible to just support the
Canvases (or direct drawing) of another GUI, while
still using Tkinter for the remainder of the interface.

So, can anyone tell me how this might be accomplished.
I made a test program to demonstrate that I could run
both the Tkinter and wxPython mainloops in separate
threads. What are the limits of this approach (I
assume their will be issues with event handling)? Is
it really just this simple?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

import threading
import Tkinter
Tk = Tkinter

from wxPython.wx import *

def tk_button_press():
print "Tkinter button pressed"
return

def wx_button_press(event):
print "wxPython button pressed"
return

class MyWxApp(wxApp):
def OnInit(self):
frame = wxFrame(NULL, -1, "Hello from wxPython")
frame.Show(true)

wx_button = wxButton(frame, 10, "Hello", wxPoint(20, 20))
EVT_BUTTON(frame, 10, wx_button_press)

self.SetTopWindow(frame)
return true

if __name__ == '__main__':

tk_root = Tk.Button(text='Tkinter', command=tk_button_press)
tk_root.pack()

wx_root = MyWxApp(0)

t = threading.Thread( target=wx_root.MainLoop )
t.start()

tk_root.mainloop()
t.join()
--
Chad Netzer
chad....@stanfordalumni.org

[Paul Boddie]

Timothy Docker <ti...@macquarie.com.au> wrote in message news:<m4iae10...@macquarie.com.au>...

>
> Although I use suns C++ compiler for local development, I alway use gcc
> for compiling python related stuff. I have a "sandbox" type of
> environment that has all the gnu tools (gnu-make,bash etc) on the path
> in front of the sun equivalents, in order to get stuff building in
> the way the developers would have.

I can recommend this with certain open source projects, and in my
opinion it's rather nice to be able to use bash instead of the
standard Solaris shells as well.

> > Even Python itself doesn't compile out of the box on Solaris using gcc,
> > only using Sun's cc, which is rather a pity.
>
> Hmmm. It did so perfectly for me, on sol2.7 with gcc2.95.2.

I never had any problems installing Python on Solaris with gcc. Is
this Python 2.1 or 2.2a? If so, then you're doing something I never
got to trying.

> Which gcc version? Which solaris version? What was you problem?

I think the biggest thing to get right in building wxPython is the
combination of compatible packages. wxPython will often require a
particular version of wxGTK, and this may in turn require particular
versions of gtk and glib. On Solaris, there are additional issues
which are conveniently summarised on this Web page I just found:

http://home.t-online.de/home/hburde/s7-tips.html#wxPython

One of them - the --enable-permissive flag for gcc - is to get around
Sun's "broken" X11 headers, and can be quite a common thing to specify
when building things on Solaris.

Paul

[Vadim Zeitlin]

On Tue, 14 Aug 2001 20:04:39 +0200, Gerhard Häring <gerhard...@bigfoot.de> wrote:
>What I hate about wxPython is that it's quite frustrating to just try things
>out in the interactive Python interpreter. Every few lines I get Segmentation
>Faults when I do this.

What kind of things? Maybe you just found a bug? If so, why not report it?

Regards,
VZ
--
GCS/GM d? H+ s++:-- p2 au--- a- w+ v C+++ UBLS+++ P- L++ N++ E--- W++++ M? V--
-po+ R++ G`` !tv b+++ D--- e++++ u++ h--- f+ r++ n- y?