ANN: WxInter

[Ed Suominen]

WxInter is a drop-in replacement for TkInter, providing user-transparent
wxPython-based replacements for each and every part of the Tkinter class
library. Because wxPython can do anything that the ancient and stagnant
TkInter can do (but with a themable, modern window appearance), legacy code
will still run, looking better than ever, and Python's last connection to
the Tcl/TK albatross will be forever broken.

OK, I just made all this up. But why couldn't it happen? I'd even be tempted
to code it myself, but I'm sure others with some wxPython experience could
do it much faster and better.

 

[Jeremy Bowers]

WxInter is a drop-in replacement for TkInter, providing user-transparent
wxPython-based replacements for each and every part of the Tkinter class
library. Because wxPython can do anything that the ancient and stagnant
TkInter can do (but with a themable, modern window appearance), legacy code
will still run, looking better than ever, and Python's last connection to
the Tcl/TK albatross will be forever broken.

OK, I just made all this up. But why couldn't it happen? I'd even be tempted
to code it myself, but I'm sure others with some wxPython experience could
do it much faster and better.

Well, it would break my app. The TKInter text widget is better than what
the wxWindows text widget can provide for me; I tried. It still isn't
perfect but at least I can pound it into submission.

TkInter and wxWindows have a lot of overlap, but there are things each can
do the other can't. wxWindows has a *lot* more widgets, and themes more
nicely, but TkInter has a *very* mature widget set; what it has is
sometimes quirky but very solid. You will not be able to provide a 100%
drop in without a lot of work wxWindows itself on several platforms.

 

[David Fraser]

WxInter is a drop-in replacement for TkInter, providing user-transparent
wxPython-based replacements for each and every part of the Tkinter class
library. Because wxPython can do anything that the ancient and stagnant
TkInter can do (but with a themable, modern window appearance), legacy code
will still run, looking better than ever, and Python's last connection to
the Tcl/TK albatross will be forever broken.

OK, I just made all this up. But why couldn't it happen? I'd even be tempted
to code it myself, but I'm sure others with some wxPython experience could
do it much faster and better.

I think its a fantastic idea, and since you thought of it, why not
start? Then others can jump in.
You may want to suggest this on the wxPython-users mailing list

David

 

[Eric Brunel]

Well, it would break my app. The TKInter text widget is better than what
the wxWindows text widget can provide for me

Agreed. And I didn't see any equivalent of the Tkinter Canvas widget in any
other toolset. In fact, I didn't even see any widget coming close to it. For
some kind of applications (namely application doing vector drawing), it is
nearly impossible to consider anything else than Tkinter *because* of the Canvas
widget...

However, I'll be glad if someone can prove me wrong...

 

[Ed Suominen]

Good points. The thing to do, IMHO, would be to improve wxWindows/wxPython
to provide the text and canvas widget functionality, and then move with the
WxInter idea to use it as a path for abandoning TkInter.

I have Tk and OOP experience, and could work on WxInter (all Python) with
the help of others. But the work on wxWindows/wxPython (C++) would have to
be someone else's domain. The wxWidgets project has a bounties page [1]. If
there were enough interest (e.g., by the Python foundation), that might be
a route to get the needed text/canvas functionality.

Would a PEP be welcomed or opposed on this topic?

[1] http://wiki.wxwidgets.org/wiki.pl?WxWidgets_Bounties

Ed Suominen
Registered Patent Agent
Open-Source Software Author (yes, both...)
Web Site: http://www.eepatents.com

 

[Michael Hudson]

Good points. The thing to do, IMHO, would be to improve wxWindows/wxPython
to provide the text and canvas widget functionality, and then move with the
WxInter idea to use it as a path for abandoning TkInter.

I have Tk and OOP experience, and could work on WxInter (all Python) with
the help of others. But the work on wxWindows/wxPython (C++) would have to
be someone else's domain. The wxWidgets project has a bounties page [1]. If
there were enough interest (e.g., by the Python foundation), that might be
a route to get the needed text/canvas functionality.

Would a PEP be welcomed or opposed on this topic?

I'm not sure what you're asking about. A PEP for improving wxWindows
or even wxPython would be irrelavent.

A PEP for removing Tkinter and replacing it with Wxinter would
certainly be necessary, but somewhat premature until Wxinter
exists... I'd also expect it to meet some resistance, but that's only
a guess (I don't use either and don't care .

Cheers,
mwh

 

[Jeremy Bowers]

Good points. The thing to do, IMHO, would be to improve wxWindows/wxPython
to provide the text and canvas widget functionality, and then move with the
WxInter idea to use it as a path for abandoning TkInter.

I really didn't want to do my project in TkInter, because of the scarcity
of widgets. I once tried to go Windows-only, and source-modified the
Windows version to allow me access to even more Windows specific
functionality, and I *still* couldn't match the Tk Text widget.

In particular, the %x,y syntax that identifies a point in the text by
screen coordinates, although some other minor things were missing too. For
my app, that was the critical bit that even made it *possible* without
writing a new text widget somewhere. (While I could do it theoretically,
I'd sooner drop my app; there's no point in an app that needs a custom GTK
to work.)

You might want to instead focus on extended the pre-existing AnyGUI
project.

http://anygui.sourceforge.net/

(Look, a constructive suggestion instead of criticism !) Trying to
implement Tk in wxWindows is probably man-years of work, and probably the
most feasible avenue is to actually source-integrate the Tk widgets into
wxWindows itself; yes, that's a lot of work but I bet it is the least
overall. (Not a horrid idea, but extracting the Tk text widget may
be a real handful due to major impedance mismatch.)

If you're willing to drop the 100% compatibility requirement, then at that
point there's no reason not to extent AnyGUI as much as possible, create a
Tk-a-like front end for AnyGUI, and anybody who uses too much Tk stuff
can't use AnyGUI, which is true no matter what you do so no loss. A little
more work, vastly more reward; a migration path off Tk for simple Tk
users, and if you start from day one with AnyGUI, more flexibility.

 

[Skip Montanaro]

Ed> Good points. The thing to do, IMHO, would be to improve
Ed> wxWindows/wxPython to provide the text and canvas widget
Ed> functionality, and then move with the WxInter idea to use it as a
Ed> path for abandoning TkInter.

FWIW, Gtk has a TextView widget with functionality similar to the Tk text
widget. The Gtk folks have no desire to adopt the model the Tk text widget
uses (I asked once upon a time), but you may be able to paper over most
common differences in Python (I suspect a 100% replacement will be
challenging). I did something along these lines for some contract work a
couple years ago. My former employer is heavily open source oriented and
can probably be convinced to release that code without much problem.

Skip

 

[Cameron Laird]

WxInter is a drop-in replacement for TkInter, providing user-transparent
wxPython-based replacements for each and every part of the Tkinter class
library. Because wxPython can do anything that the ancient and stagnant
TkInter can do (but with a themable, modern window appearance), legacy code
will still run, looking better than ever, and Python's last connection to
the Tcl/TK albatross will be forever broken.

OK, I just made all this up. But why couldn't it happen? I'd even be tempted
to code it myself, but I'm sure others with some wxPython experience could
do it much faster and better.

.
.
.
Also competing as a "faster and better" alternative is to wait for
8.5 of Tk, which will bring "themable, modern window appearance" to
Tkinter <URL: http://wiki.tcl.tk/tile >.

 

[Skip Montanaro]

Ed> Good points. The thing to do, IMHO, would be to improve
Ed> wxWindows/wxPython to provide the text and canvas widget
Ed> functionality, and then move with the WxInter idea to use it as a
Ed> path for abandoning TkInter.

FWIW, Gtk has a TextView widget with functionality similar to the Tk text
widget. The Gtk folks have no desire to adopt the model the Tk text widget
uses (I asked once upon a time), but you may be able to paper over most
common differences in Python (I suspect a 100% replacement will be
challenging). I did something along these lines for some contract work a
couple years ago. My former employer is heavily open source oriented and
can probably be convinced to release that code without much problem.

Skip

 

[Tom B.]

WxInter is a drop-in replacement for TkInter, providing user-transparent
wxPython-based replacements for each and every part of the Tkinter class
library. Because wxPython can do anything that the ancient and stagnant
TkInter can do (but with a themable, modern window appearance), legacy
code
will still run, looking better than ever, and Python's last connection to
the Tcl/TK albatross will be forever broken.

OK, I just made all this up. But why couldn't it happen? I'd even be
tempted
to code it myself, but I'm sure others with some wxPython experience could
do it much faster and better.

A wxInter library would not promote people to learn wxPython. It seems that
the seems that the thing that people like about Tk is the Canvas object has
anyone tried the wxFloatCanvas as a replacement.

Tom

 

[Skip Montanaro]

Tom> It seems that the thing that people like about Tk is the Canvas
Tom> object has anyone tried the wxFloatCanvas as a replacement.

Where is it? Google turns up essentially nothing for "wxFloatCanvas" on
either groups or web. That makes it a pretty well-hidden object. Google
offered "wxPlotCanvas" as an alternative. Are they related?

Skip