Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   Re: WxPython versus Tkinter. (http://www.velocityreviews.com/forums/t742674-re-wxpython-versus-tkinter.html)

Octavian Rasnita 01-27-2011 07:28 AM

Re: WxPython versus Tkinter.
 
From: "Brendan Simon (eTRIX)" <brendan.simon@etrix.com.au>
> Since it seems the python motto is "Batteries included", then it would
> seem to me that wxPython is the natural fit as it also has "Batteries
> included" (e.g. accessibility, native look-n-feel, mature and evolving,
> can produce simple or complex gui programs, etc, etc).




Yes Brendan, you are perfectly right, but unfortunately WxPython developers
don't want to have it included in the stdlib.
Finally I understood that this is the main problem, because if they would
want to do it in the conditions imposed by Python, it would have been much
easier and many of other problems could have been solved.

But WxPython is their work and they decision is their.

Octavian


rantingrick 01-27-2011 06:11 PM

Re: WxPython versus Tkinter.
 
On Jan 27, 1:28*am, "Octavian Rasnita" <orasn...@gmail.com> wrote:
> From: "Brendan Simon (eTRIX)" <brendan.si...@etrix.com.au>
>
> > Since it seems the python motto is "Batteries included", then it would
> > seem to me that wxPython is the natural fit as it also has "Batteries
> > included" (e.g. accessibility, native look-n-feel, mature and evolving,
> > can produce simple or complex gui programs, etc, etc).

>
> Yes Brendan, you are perfectly right, but unfortunately WxPython developers
> don't want to have it included in the stdlib.


[...]

> But WxPython is their work and they decision is their.


Actually we don't want "Robins wxPython" in the stdlib "as is" anyway.
What we DO want is an abstraction API for the short term that plugs
into Robin's wx. Then over the long term we will either convince him
to create a better API OR just create our own wxPython directly from
WxWidgets and mold it into the stdlib. So hinging on the argument of
what one *single* man thinks is a non-starter.

We all respect Robin however python is greater then me, then you, and
yes, EVEN Guido van Rossum! Python belongs to the world now. And what
is best for Python's community AS A WHOLE is what we should be
concerned about.




Stephen Hansen 01-27-2011 07:03 PM

Re: WxPython versus Tkinter.
 
On 1/27/11 10:11 AM, rantingrick wrote:
> On Jan 27, 1:28 am, "Octavian Rasnita" <orasn...@gmail.com> wrote:
>> But WxPython is their work and they decision is their.

> Actually we


The word "we" does not mean what you think it means.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJNQcGiAAoJEKcbwptVWx/llq4H/j00UI6eT8nLutDdUqDKRp9c
VutbYF9YvN2uJSNeqevLVJMvx78TPvR+wTOSqAKBSGD3U5TpQn rPr8xcU1VvrO7p
ZIPBxz4R/823Hti+OIwx0VB2z1Nqjj9lPHP8s5w87pbJFqz3o+dRH7nJual r+It8
JarahNaKFy7PQc3s6QR0D1fMw7QCbY52Mv9/94nOspDF4K2XsC+huXjvaqUnkwE7
F3VXmsU/bdsAttG+VTGeAK27SfrIEmYCDy66A3PG/bj4EGrp3LHsJ7Jbgv5QVcoD
jQ3r7miKgnjxDb7cmf7VfDjrmW6RRHvjW3lav+t2m8chWt79WB ZowveVsbbX7kg=
=SRRv
-----END PGP SIGNATURE-----


Kevin Walzer 01-27-2011 11:50 PM

Re: WxPython versus Tkinter.
 
On 1/27/11 1:11 PM, rantingrick wrote:
> Actually we don't want "Robins wxPython" in the stdlib "as is" anyway.
> What we DO want is an abstraction API for the short term that plugs
> into Robin's wx. Then over the long term we will either convince him
> to create a better API OR just create our own wxPython directly from
> WxWidgets and mold it into the stdlib. So hinging on the argument of
> what one*single* man thinks is a non-starter.


I saw this comment elsewhere in the thread, and I'm a bit confused. As I
understand it, you want to layer a Tkinter-style abstraction API over
wxPython? You had mentioned that you want to include something like
Tkinter's grid/pack/place management API's, its event-handling
mechanism, its use of tags, and a few other things?

I'd like to suggest that these things are already in the stdlib, in the
form of Tkinter itself. And at least some thing these things are tightly
bound to Tkinter's inclusion of the Tcl interpreter. For instance, Tcl
has a powerful and flexible event loop mechanism. Does wxWidgets have
something similar? And are Tkinter's grid/pack/place geometry managers
(which are defined at the C level) compatible with wx sizers, which are
also defined at the lower C++ level?

While this thread has taken many twists and turns, it nonetheless seems
to me that the proposal being offered is to layer a Tkinter-style API
over a Tkinter-scale subset of wxPython's widgets (listbox, button,
menu, etc.). After all that work, what would really be gained? We'd have
the same small core of widgets, with an arguably less stable base (since
wxPython seems to have problems with segfaults on Linux).

It is not persuasive to say that Tkinter is "legacy" while wxPython is
"the future." Both Tk and wxWidgets date to the early 1990s. Tk did
stagnate for a number of years, but its development in the past few
years has been reinvigorated by the ttk themed widgets, in addition to
various extension packages that use Tk's C API, and it is now a peer to
wxWidgets in its GUI capabilties. I can't speak to Tkinter's performance
relative to wxPython and the Tcl interpreter, but any performance gains
that are achieved by wxPython's underlying C++ library may be obviated
by lesser stability.

After all the back-and-forth, I am simply not persuaded, especially
since the proposal being offered is not to replace Tkinter with wxPython
in the stdlib, but to instead replace Tkinter with a yet-to-be-designed
wxTkinter amalgamation (a Tkinter body on a wxPython chassis).

--Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

rantingrick 01-28-2011 12:54 AM

Re: WxPython versus Tkinter.
 
On Jan 27, 5:50*pm, Kevin Walzer <k...@codebykevin.com> wrote:
> On 1/27/11 1:11 PM, rantingrick wrote:


[...]

Hello again Kevin and nice to have you back!

Yes the minor details have been evolving over the course of this and
another thread. We have been floating new ideas all along the way in
an effort to get the best result. In the very beginning because we all
know that wxPython IS HUGE i offered a divide and conquer approach...

* Small "Tkinter-like" stdlib module.
* Full featured third party download.

By doing this we can keep the stdlib smaller and leave the bulk of wx
in a 3rd party download. Then we floated around installing the entire
wxPython library because after all hard drives are only getting
bigger. However i think that neither are the best Option.

In any event the ideas (like any ideas in a lively discussion) are
very fluid in nature. Part of generating the best conclusion is by
twisting and turning every idea until it fits neatly into some stated
goals. And yes, we want to get the most bang for our community buck!

I am now convinced that "Robins wxPython" is woefully inadequate due
to the API. We can never consider putting such a blasphemy into the
stdlib. Does that mean we should ignore the great benefits of
wxWidgets? HELL NO, we would be fools if we did!

Now i am thinking along the lines of an abstraction API that plugs
into wxPython. We keep Tkinter until say "Python4000", but in the
meantime we create a "pythonic wxPython" from the ground up (stealing
as much as we can from Robin!). By doing this we can integrate
wxPython at whatever rate the community can bear at the time.

The only thing better would be to convince all GUI library creators to
start thinking globally. To start setting a global standard for all
GUI libraries. Then all we would have to do is create a Python API and
just "plug" it in generically to WX, TK, GTK, QT, Etc, Etc. I know
this sounds like a pipe dream, but this is what must happen at some
point. And we should all be demanding this everyday. Always Remember:

Selfishness = Multiplicity = Entropy = Shock = Stagnation = None


> While this thread has taken many twists and turns, it nonetheless seems
> to me that the proposal being offered is to layer a Tkinter-style API
> over a Tkinter-scale subset of wxPython's widgets (listbox, button,
> menu, etc.). After all that work, what would really be gained? We'd have
> the same small core of widgets, with an arguably less stable base (since
> wxPython seems to have problems with segfaults on Linux).


Yes this discussion has taken many turns. Read my previous statement
for insight.

> It is not persuasive to say that Tkinter is "legacy" while wxPython is
> "the future." Both Tk and wxWidgets date to the early 1990s. Tk did
> stagnate for a number of years, but its development in the past few
> years has been reinvigorated by the ttk themed widgets, in addition to
> various extension packages that use Tk's C API,


Yes Tk has just recently "come out of stagnation". But for how long?
How long must we wait for them to "get it together"? Thats my point.
We will all be dead and rotting by the time Tkinter is including a
ListCtrl and accessibility. And i don't know about you Kevin, but i
really don't want to wait that long!

> and it is now a peer to
> wxWidgets in its GUI capabilties. I can't speak to Tkinter's performance
> relative to wxPython and the Tcl interpreter, but any performance gains
> that are achieved by wxPython's underlying C++ library may be obviated
> by lesser stability.


wxPython IS NOT less stable than Tkinter: That is a FACT. However,
WxPythons API was written in such a horribly unpythonic way (sorry
Robin) that someone could find themselves in trouble IF they are not
experienced enough to use the library. However, we can easily fix an
API. What we can't fix is lack of vision and stagnation in an outside
community. We must help ourselves because no one else is going to do
it for us!

> After all the back-and-forth, I am simply not persuaded, especially
> since the proposal being offered is not to replace Tkinter with wxPython
> in the stdlib, but to instead replace Tkinter with a yet-to-be-designed
> wxTkinter amalgamation (a Tkinter body on a wxPython chassis).


Not exactly Kevin. What i intend to do is take your Yugo (Tkinter) to
my shop and rip out the antiquated engine, rusty transmission, and
remove those "may-pop" tires. Then i plan to replace them with the
best high performance parts that are available (wxWidgets) and
probably even give her a nice paint job too (Tkinter API)! And when i
am done, all your friends are going to be jealous and all the women
are going to want a ride in your new hotrod.

Kevin, i am going to make you the coolest cat in town! But nobody said
it was going to an easy task! ;-)



All times are GMT. The time now is 11:03 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.