RE: [Python-Dev] What to choose to replace Tkinter?
Mark Hammond writes:
Agreed. However, XPFE works fine here IMO.
cgw> "Here" means on MS-Win, right? Maybe that's why our perceptions are cgw> so different.
Correct. Although I have run it under Linux a few times, I wouldnt really know LAF issues if I tripped over them there ;-)
Mark.
It's certainly true that the lack of a consistent look and feel for Linux apps has been somewhat of a problem historically. However, with the emergence of Gnome, it seems that there is finally some convergence. (Althought people in the KDE/Qt camp will certainly not agree!) Gnome is gathering momentum, especially now that Sun has joined the Gnome Foundation. With outfits like Eazel, Helix Code, etc, turning out high-quality products, things are moving fast in the Gnome/Gtk+ world and it seems clear to me that this will be the major desktop platform for Unix machines in the upcoming decade. Back in my former life, when I was still worrying about Windows, the company I worked for bought into a commerical x-platform GUI toolkit called Galaxy (I mentioned this earlier). Galaxy re-implemented all the native widgets, kind of like XPFE does. One issue with this was that MS seemed to change something about the widgets in every release - e.g. the Galaxy filechooser looked like Windows 3.1, then Win95 came out and Galaxy had to play catch-up. Once Galaxy had the Win95 LAF, Win98 came out. Now I hear there's something called Windows ME. Have they changed the look-and-feel again? Seems to me like all the widget-reimplementors are doomed to playing eternal catch-up. OK, enough off-topic rambling (for now), -C
On Tue, Oct 24, 2000 at 10:21:45AM -0500, Charles G Waldman wrote:
It's certainly true that the lack of a consistent look and feel for Linux apps has been somewhat of a problem historically. However, with the emergence of Gnome, it seems that there is finally some convergence. (Althought people in the KDE/Qt camp will certainly not
Careful... while people may try to port GTk+ to Windows, porting GNOME is a different kettle of wax, because GNOME needs GTk+ but also entails gnome-libs and gnome-vfs and Bonobo and esound and lots of other things, which provide services such as object embedding that wouldn't be required -- or would be very different -- on Windows. I don't know if anyone is trying to tease apart GNOME into a Windows-suitable subset; it seems like it would be a difficult task. Qt is at least a toolkit that aims at cross-platform portability, though there again, the KDE environment built on top of it is not going to be portable to anything that isn't Unix. Both the Qt and GTk+ toolkits ignore the Mac, leaving Tk and wxWindows as the only real possibilities. This is why, every time this debate comes up, we end up sticking with Tk; it may suck, but all the other systems don't support everything... Maybe the best approach is to follow /F's lead with Tkinter3000, and reimplement the Tkinter API on top of MFC / GTk+ / Qt. (Er... that *is* what Tkinter3000 is, right?) What's the problem we're trying to solve here? * Is it that the problem that the Tkinter module is a bad API for GUI programming? * Or is it that the Tk implementation is slow or bulky? * Or do we just dislike having to require Tcl as well as Tk? Can someone articulate why Tk should be replaced? --amk
Andrew Kuchling wrote: What's the problem we're trying to solve here?
* Is it that the problem that the Tkinter module is a bad API for GUI programming?
* Or is it that the Tk implementation is slow or bulky?
* Or do we just dislike having to require Tcl as well as Tk?
Can someone articulate why Tk should be replaced?
I can articulate why I'm unhappy with the current set-up: 1. Requiring Tcl is fragile. Un-gumming installation on machines at Los Alamos before my first Python course cost me several hours, and I had to do it again two months' later. I've run into similar problems with multiple Tcl installations on Windows machines (personal use). 2. (Lack of) native look and feel. This is a complete show-stopper for many of the outfits I've dealt with (and not just with Python). Performance doesn't really matter --- I've never had students complain about speed, although I've never asked them to build something large enough that refresh would be an issue. I don't have experience teaching wxPython, so I can't comment on the relative teachability of its API vs. Tk's. Hope this helps, Greg
"GW" == Greg Wilson <gvwilson@nevex.com> writes:
GW> 2. (Lack of) native look and feel. This is a complete GW> show-stopper for many of the outfits I've dealt with (and not GW> just with Python). On the other hand, it's incredibly easy to whip together a GUI in Tk for simple applications. Yes, Tk gets painful as applications grow, but I'd hate to abandon such a simple, well-known toolkit for a complicated, hard-to-learn but powerful native look-and-feel one. You don't /always/ care about strict native LAF. Or to restate: I'd hate to have to make that choice. If we can't satisfy both requirements (mandatory-native-LAF and rapid prototyping friendliness), we may need to continue to support multiple toolkits. the-delicious-aroma-of-the-first-GUI-bakeoff-still-in-the-air-ly y'rs, -Barry
I can articulate why I'm unhappy with the current set-up:
1. Requiring Tcl is fragile. Un-gumming installation on machines at Los Alamos before my first Python course cost me several hours, and I had to do it again two months' later. I've run into similar problems with multiple Tcl installations on Windows machines (personal use).
For Windows, this problem has gone away in 1.6 and 2.0 -- we distribute and install our own Tcl/Tk binaries, in a place that doesn't affect or require existing Tcl/Tk installations. Maybe we can do the same for Unix binary distributions? I believe Jeremy has already had to create a separate RPM for _tkinter because there are too many different versions of Tcl/Tk out there -- it shouldn't be hard to install our own altogether.
2. (Lack of) native look and feel. This is a complete show-stopper for many of the outfits I've dealt with (and not just with Python).
Really? Are you sure that's not just general resistence against new things? To me, and I suspect may others, the app I use most often on Windows is Netscape -- talk about lack of native look-and-feel! It's never bothered me all that much. Or are you saying that IDLE isn't designed as a typical Microsoft app? That's quite a separate issue from the widget look-and-feel! --Guido van Rossum (home page: http://www.python.org/~guido/)
Greg Wilson: I can articulate why I'm unhappy with the current set-up: 1. Requiring Tcl is fragile.
Guido van Rossum: For Windows, this problem has gone away in 1.6 and 2.0 -- we distribute and install our own Tcl/Tk binaries
OK.
Greg Wilson: 2. (Lack of) native look and feel. This is a complete show-stopper for many of the outfits I've dealt with (and not just with Python).
Guido van Rossum: Really? Are you sure that's not just general resistence against new things?
Well, my students' resistance to novelty is low enough that they're willing to take a Python course :-). This comes up every time I teach; no idea whether it has any impact on the usability of completed applications, but I believe it makes people less likely to choose Tkinter when starting development. Thanks, Greg
Well, my students' resistance to novelty is low enough that they're willing to take a Python course :-). This comes up every time I teach; no idea whether it has any impact on the usability of completed applications, but I believe it makes people less likely to choose Tkinter when starting development.
Can you elaborate on the line of argument that you typically hear? What do you say to dispel it? --Guido van Rossum (home page: http://www.python.org/~guido/)
From some feedback forms from old runs of my Python course (with spelling corrections :-)
1. "My users don't care what programs are written in. They just care if they're easy to use. They won't care if Python programs have the same look and feel on different computers, because they won't ever think of [name of program] as a Python program. To them, it will be a Windows program that looks funny."
2. "You said three times in the intro lecture this morning that the most important thing in a GUI was consistency. Then you told us to write GUIs that look different from everything else on the desktop."
3. "I'm confused: I didn't realize that Python was a library on top of TCL."
I spent a minute drawing blob diagrams to answer #3; I think most students understood, but the person who asked the question was clearly still confused.
I didn't try to dispel #1 or #2, because I agree with them: my experience is that consistent look and feel are crucial for making non-programmers less afraid of pressing the wrong button or making the program "do weird things". Other people with more experience creating end-user applications may have different views.
This is helpful. Can you elaborate on what elements of the Windows look-and-feel are missing in Tkinter? As far as I know, the menu bars, file selection dialogs, scroll bars, dialog boxes and so on have a thoroughly native look-and-feel, since Tk implements these as wrappers around the native widgets. IDLE doesn't look very different from Notepad! So what's missing? A toolbar with icons? That would be easy to add using existing Tk controls (Pmw has it too). The multiple document interface? It sucks -- and even Word 2000 has gone away from that! What kind of GUIs did you teach them exactly? If you started with basic Tkinter widgets, sure, it looks different than anything else. But that depends on the widget layout in the program, not on the widget library used! --Guido van Rossum (home page: http://www.python.org/~guido/)
I choose to use wxPython over TK because: 1. wxPython has a reasonable event model 2. wxPython allows me build one object hierarchy 3. TK requires I manage two object hierarchies, TK's and my classes 4. Hooking events to TK seems clumsy from Python As others have said better docs on wxPython would be nice and its to easy to crash the world from wxPython. Barry
If you started with basic Tkinter widgets, sure, it looks different than anything else. But that depends on the widget layout in the program, not on the widget library used!
This is one of my main gripes about the Tk API. The default behaviours of all its layout managers suck. In order to get a layout that looks pleasant and/or conforms to some style guide, you have to set a whole slew of options every time you place a widget. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
Greg Wilson:
2. (Lack of) native look and feel. This is a complete show-stopper for many of the outfits I've dealt with (and not just with Python).
Guido van Rossum: Really? Are you sure that's not just general resistence against new things?
Well, my students' resistance to novelty is low enough that they're willing to take a Python course :-). This comes up every time I teach; no idea whether it has any impact on the usability of completed applications, but I believe it makes people less likely to choose Tkinter when starting development.
As I see it, Tk, like SQL, has the property that it's dead easy to get something crappy running, but it takes a real expert (like /F) to make it good. With wxPython, though, it's easy (if somewhat tedious) to get something good - at least as far as normal "forms" style GUIs. I'm not taking sides - I dabble in both and will never be an expert at either. But for clients using Windows, I use wxPython because it's indistinguishable from native Win32. (BTW, MFC is lagging further and further behind native Win32 - I believe MS considers it "legacy".) - Gordon
On Tue, 24 Oct 2000, Guido van Rossum wrote:
Maybe we can do the same for Unix binary distributions?
I don't know what you mean by "UNIX" binary distributions: each UNIX has its own sets of horrors in the distribution arena. Personally, I don't care what we do about RPMs, since I'm not a Red Hat user. However, this should probably be more Red Hat's job then ours. Debian, on the other hand, would probably do this much better then Python-Dev can, without gratutitous Tcl/Tk installations. For other unices, most people install from sources anyway, which mostly means I should get off my butt and start working on the Sumo interpreter.
Really? Are you sure that's not just general resistence against new things? To me, and I suspect may others, the app I use most often on Windows is Netscape -- talk about lack of native look-and-feel! It's never bothered me all that much.
I don't know how to break this to you, but you're not the average computer user <wink>. -- Moshe Zadka <moshez@math.huji.ac.il> There is no IGLU cabal. http://advogato.org/person/moshez
Guido van Rossum wrote:
2. (Lack of) native look and feel. This is a complete show-stopper for many of the outfits I've dealt with (and not just with Python).
Really? Are you sure that's not just general resistence against new things? To me, and I suspect may others, the app I use most often on Windows is Netscape -- talk about lack of native look-and-feel! It's never bothered me all that much.
In the past I have resolutely demanded native Windows look and feel in my apps. In fact, I have been tiresome on the topic. Now I am changing my mind. Lots of prominent Windows apps now depart from Microsoft LAF, and I have the impression that users are getting used to it. I still think the usual File menu items and file open/save dialogs should be standard, but I am less concerned about other controls. For a look at how to really do controls, check out software for kids. Just my 1.e-2$. JimA
In the past I have resolutely demanded native Windows look and feel in my apps. In fact, I have been tiresome on the topic.
Now I am changing my mind. Lots of prominent Windows apps now depart from Microsoft LAF, and I have the impression that users are getting used to it. I still think the usual File menu items and file open/save dialogs should be standard, but I am less concerned about other controls. For a look at how to really do controls, check out software for kids. Just my 1.e-2$.
Even Microsoft is violating its own (boring) style guide, when they think it appeals to a specific audience. Have you seen their Media Player? --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Even Microsoft is violating its own (boring) style guide, when they think it appeals to a specific audience. Have you seen their Media Player?
Yes, very slick. My daughter has an app where you click on doors to access parts of the program. Nice design. JimA
On 26 October 2000, James C. Ahlstrom said:
Guido van Rossum wrote:
Even Microsoft is violating its own (boring) style guide, when they think it appeals to a specific audience. Have you seen their Media Player?
Yes, very slick. My daughter has an app where you click on doors to access parts of the program. Nice design.
This is generally considered Bad Form by usability types. I think it boils down to this: the computer is not the real world, and trying to emulate the real world on the computer is cutesy but a dead end. Go look for "User Interface Hall of Shame" at your friendly neighbourhood search engine for many enjoyable rants against bad GUI design, including the "emulate the real world" school of thought. Anyways, this is not a usability mailing list... back to our regularly scheduled python-dev... Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367
James C. Ahlstrom said:
Yes, very slick. My daughter has an app where you click on doors to access parts of the program. Nice design.
[Greg Ward]
This is generally considered Bad Form by usability types. I think it boils down to this: the computer is not the real world, and trying to emulate the real world on the computer is cutesy but a dead end.
I once interviewed with a game designer (sports games - popular ones, too). He spent half an hour slamming MS's UI (his games run on Windows). Then he pulled up his latest (opening to a sports stadium) and said "Now here's a real UI". So I said "Show me how it works". The bozo ended up clicking on random things on the screen until something finally happened. no-no-the-beer-means-OK--the-bimbo-means-CANCEL-ly y'rs - Gordon
Greg Ward wrote:
This is generally considered Bad Form by usability types. I think it boils down to this: the computer is not the real world, and trying to emulate the real world on the computer is cutesy but a dead end.
I agree up to a point, and my own app doesn't use doors. But kids like this kind of design, have no trouble understanding it, and people wouldn't write this if they didn't think it would sell. I just meant that people have a larger tolerance for non-Microsoft GUI design ideas than I thought up to now. JimA
Andrew Kuchling writes:
Careful... while people may try to port GTk+ to Windows, porting GNOME is a different kettle of wax, because GNOME needs GTk+ but also entails gnome-libs
But I was never seriously advocating Gtk+ on Windows. This was just a footnote. I shouldn't have even mentioned the Windows Gtk+ port because it just muddied the water. The major point I was trying to make is that toolkits like Tkinter and WxWindows, which try to delegate to the native widget sets whenever possible, will succeed, and toolkits like Galaxy/AWT/Swing/XPFE, which reimpliment all the widgets from scratch, are doomed to fail. (IMO, of course). What I believe we need is a suitable abstraction which uses MFC on MS-Win platforms and Gtk+ on Unix. And which also doesn't, due to the abstraction, take away too many features. I don't know that much about MFC, but for a simple example - Gtk+ offers an option for its canvas widget to do all drawing in antialised mode (by the way, this is slow but produces very nice looking results). It would be a shame if the abstraction layer didn't allow for things like this to be used.
This is why, every time this debate comes up, we end up sticking with Tk; it may suck, but all the other systems don't support everything...
Right. FWIW, in my day-to-day work, if it has to run on MS-Win I use Tkinter, and if MS-Win is not an issue I use PyGtk. Fermilab will be showing some network monitoring software at the Supercomputing 2000 conference next month, and it's mostly all stuff I whipped up a few days using Tkinter.
andrew wrote:
Maybe the best approach is to follow /F's lead with Tkinter3000, and reimplement the Tkinter API on top of MFC / GTk+ / Qt. (Er... that *is* what Tkinter3000 is, right?)
nope -- at least not initially. the first two steps are a new Tk glue layer, and an extension API that allows you to write new widgets in pure Python. also see: http://w1.132.telia.com/~u13208596/tkinter/index.htm ::: I have plans for how to take the Tkinter API *and* the new extension API beyond Tk, but let's save that for another day... :::
Can someone articulate why Tk should be replaced?
beats me ;-) </F>
Fredrik Lundh <effbot@telia.com>:
Can someone articulate why Tk should be replaced?
beats me ;-)
My main reason is that Tcl is in trouble, and I fear Tcl/Tk may become effectively unmaintained in the foreseeable future. -- <a href="http:///~esr/">Eric S. Raymond</a> Rapists just *love* unarmed women. And the politicians who disarm them.
Andrew Kuchling wrote:
Can someone articulate why Tk should be replaced?
I don't know whether Tk should replaced, but I can explain why I don't use it for our commercial Python application. It is just too big and complicated. Windows comes with a built-in GUI, and I hesitate to install another scripting language (Tcl) and its libraries, and then install a big system which has frequently been out of phase with Python releases just to access the Windows GUI. What if a user calls with a problem? Why should I have to debug their Tcl library path problems? No thanks. JimA
Andrew Kuchling wrote:
Can someone articulate why Tk should be replaced?
Jim Ahlstrom replied:
I don't know whether Tk should replaced, but I can explain why I don't use it for our commercial Python application.
It is just too big and complicated. Windows comes with a built-in GUI, and I hesitate to install another scripting language (Tcl) and its libraries, and then install a big system which has frequently been out of phase with Python releases just to access the Windows GUI.
To me this all sounds like FUD. Since Python 1.6 and 2.0, you don't have to install Tcl/Tk or its libraries -- it is installed *transparently* by the Python Windows installer. That's different -- and better -- than what happened in 1.5.2, where a separate Tcl/Tk installer was optionally run. The version issues are also resolved this way: you are guaranteed to get exactly the Tcl/Tk version that was tested by the developers.
What if a user calls with a problem? Why should I have to debug their Tcl library path problems? No thanks.
The Tcl library paths are all taken care of by the new installer strategy. Really, give it a try. It Just Works! (SM) --Guido van Rossum (home page: http://www.python.org/~guido/)
[Guido, on finding Tcl/Tk under Windows]
To me this all sounds like FUD. Since Python 1.6 and 2.0, you don't have to install Tcl/Tk or its libraries -- it is installed *transparently* by the Python Windows installer. That's different -- and better -- than what happened in 1.5.2, where a separate Tcl/Tk installer was optionally run. The version issues are also resolved this way: you are guaranteed to get exactly the Tcl/Tk version that was tested by the developers.
Unless you're Fredrik, alas <wink>. Apparently Tcl still honors library envars first if they exist, and if some other installation or use of Tcl/Tk set those, you can still end up w/ a mix. *Much* better than before, though, and I don't recall ay instance of this happening in real life so far apart from /F (who had no problem figuring it out, of course).
What if a user calls with a problem? Why should I have to debug their Tcl library path problems? No thanks.
The Tcl library paths are all taken care of by the new installer strategy.
Really, give it a try. It Just Works! (SM)
I'll second that! "Mystery startup errors" from the Python+Tcl+Tk+Windows combo were at least weekly questions on c.l.py for 1.5.2, often daily. I've seen none for 1.6 or 2.0. and-all-it-took-was-avoiding-ms's-recommended-practices<wink>-ly y'rs - tim
On Wed, Oct 25, 2000 at 12:23:30PM -0400, Tim Peters wrote:
[Guido, on finding Tcl/Tk under Windows]
To me this all sounds like FUD. Since Python 1.6 and 2.0, you don't have to install Tcl/Tk or its libraries -- it is installed *transparently* by the Python Windows installer. That's different -- and better -- than what happened in 1.5.2, where a separate Tcl/Tk installer was optionally run. The version issues are also resolved this way: you are guaranteed to get exactly the Tcl/Tk version that was tested by the developers.
Unless you're Fredrik, alas <wink>.
...Or anybody installing ActivePython for that matter. We give instructions that the latest version of Tcl/Tk has to be installed separately, but Tk is *not* bundled with it. Trent -- Trent Mick TrentM@ActiveState.com
...Or anybody installing ActivePython for that matter. We give instructions that the latest version of Tcl/Tk has to be installed separately, but Tk is *not* bundled with it.
And that's a shame. Any chance that will be fixed any time soon? --Guido van Rossum (home page: http://www.python.org/~guido/)
"GvR" == Guido van Rossum <guido@python.org> writes:
...Or anybody installing ActivePython for that matter. We give instructions that the latest version of Tcl/Tk has to be installed separately, but Tk is *not* bundled with it.
GvR> And that's a shame. Any chance that will be fixed any time GvR> soon? I think a version of Tkinter packaged with a distutils setup script is the best answer for Unix platforms. As a Linux user, I do *not* want to install a second copy of Tcl/Tk. If we have a distutil-Tkinter, e.g. ftp://ftp.python.org/pub/python/2.0/Tkinter-2.0-8.0.tar.gz then a user can download it and run "python setup.py install" to build a Tkinter against their installed version of Tk. This will be straightforward on many Linux systems, because they ship with Tk installed. Jeremy
I think a version of Tkinter packaged with a distutils setup script is the best answer for Unix platforms. As a Linux user, I do *not* want to install a second copy of Tcl/Tk.
Why not? Because if every app using Tcl/Tk did that there would be hundreds of copies of Tcl/Tk on your disk? I don't think that argument flies; only a few other major languages use Tcl/Tk this was, so maybe you'd end up with 4 copies of Tcl/Tk: one for Tcl/Tk itself, one for Python+Tkinter, one for Perl/Tk (that's a separate code base anyway so you already have this today -- if you install Perl/Tk, that is), and one for Ruby. Given modern disk sizes I don't think it's a problem. We do the same for Windows, for good reasons: so we can be independent of whatever Tcl/Tk version is already installed.
If we have a distutil-Tkinter, e.g. ftp://ftp.python.org/pub/python/2.0/Tkinter-2.0-8.0.tar.gz then a user can download it and run "python setup.py install" to build a Tkinter against their installed version of Tk. This will be straightforward on many Linux systems, because they ship with Tk installed.
Of course that's easier. But less robust. (And why is there an "8.0" in the filename if it works with other Tcl/Tk versions???) --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum writes:
Why not? Because if every app using Tcl/Tk did that there would be hundreds of copies of Tcl/Tk on your disk? I don't think that argument flies; only a few other major languages use Tcl/Tk this was,
So should every application written in Python install it's own copy of Python, since there may be unexpected incompatibilities between versions? -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs Team Member
[Guido]
Why not? Because if every app using Tcl/Tk did that there would be hundreds of copies of Tcl/Tk on your disk? I don't think that argument flies; only a few other major languages use Tcl/Tk this was,
[Fred Drake]
So should every application written in Python install it's own copy of Python, since there may be unexpected incompatibilities between versions?
So long as Python doesn't guarantee binary compatibility across releases, that's the only thing that works. Play PySol lately <wink>?
Why not? Because if every app using Tcl/Tk did that there would be hundreds of copies of Tcl/Tk on your disk? I don't think that argument flies; only a few other major languages use Tcl/Tk this was,
So should every application written in Python install it's own copy of Python, since there may be unexpected incompatibilities between versions?
Of course not, but large and important ones may. Some already do, e.g. Alice, Zope, Ultraseek. I have no problem with this. (The saving grace is that none of these needs to recursively include Tcl. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
[Trent]
...Or anybody installing ActivePython for that matter. We give instructions that the latest version of Tcl/Tk has to be installed separately, but Tk is *not* bundled with it.
[Guido]
And that's a shame. Any chance that will be fixed any time soon?
Not presuming to speak for anyone, least of all the ActivePython product manager :-) I don't think it will be "fixed", as it is not considered "broken". It was an explicit choice to leave out Tcl/Tk. And my recollection is that the "feedback" address sees more requests for wxPython than Tcl/Tk. We make it pretty clear Tcl/Tk is not included - I assume that everyone who cares about that simply uses BeOpen releases or source tarballs. [When I say "wont be fixed", I mean it is unlikely to appear in the core ActivePython release. It almost certainly will be supported as an add-on, whatever that turns out to mean exactly ;-] Mark.
Mark Hammond wrote:
...
I don't think it will be "fixed", as it is not considered "broken". It was an explicit choice to leave out Tcl/Tk. And my recollection is that the "feedback" address sees more requests for wxPython than Tcl/Tk.
That's all true. We also make it very easy to find the right version of Tcl/Tk and will probably go even farther in this direction in the future. Built-in Tcl/Tk support is not out of the question but there are various user confusion issues: "Why are there two GUI frameworks in this development environment? Why are there two development environments in this development environment? Doesn't ActiveState have yet another GUI framework and development environment under development?" "Why do I need Tcl at all? What is its relationship with Python? There are clear benefits to including Tcl/Tk but there are also costs and its possible we'll weigh them differently in the future. BTW: ActivePython does include Tkinter. -- Paul Prescod Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html
[Guido, on finding Tcl/Tk under Windows]
To me this all sounds like FUD. Since Python 1.6 and 2.0, you don't have to install Tcl/Tk or its libraries -- it is installed *transparently* by the Python Windows installer. That's different -- and better -- than what happened in 1.5.2, where a separate Tcl/Tk installer was optionally run. The version issues are also resolved this way: you are guaranteed to get exactly the Tcl/Tk version that was tested by the developers.
[Tim]
Unless you're Fredrik, alas <wink>. Apparently Tcl still honors library envars first if they exist, and if some other installation or use of Tcl/Tk set those, you can still end up w/ a mix. *Much* better than before, though, and I don't recall ay instance of this happening in real life so far apart from /F (who had no problem figuring it out, of course).
Hm... In FixTk, TCL_LIBRARY is set explicitly. Perhaps it should set TK_LIBRARY explicitly too? --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
To me this all sounds like FUD.
True, but FUD is real and I have no apologies.
Since Python 1.6 and 2.0, you don't have to install Tcl/Tk or its libraries -- it is installed *transparently* by the Python Windows installer.
We don't use the Python Windows installer. Our app has to use its own installer, and I would then have to run two installers, one of which I don't understand. Sorry to be such an old fuddy-duddy, but you will get the same reaction from most commercial software vendors. Make that nearly ALL vendors. JimA
jim wrote:
Sorry to be such an old fuddy-duddy, but you will get the same reaction from most commercial software vendors. Make that nearly ALL vendors.
what reaction? are you saying that your own installer can install the Python DLL but not the Tk DLL? </F>
Fredrik Lundh wrote:
jim wrote:
Sorry to be such an old fuddy-duddy, but you will get the same reaction from most commercial software vendors. Make that nearly ALL vendors.
what reaction?
are you saying that your own installer can install the Python DLL but not the Tk DLL?
Not exactly. I am saying I don't want to use the standard Python Windows installer. And I am saying I don't want to install Tk because it is big, complicated, and requires Tcl and its libraries. My installer does install the Python DLL python15.dll, so I guess I could study how to install Tk and duplicate the functionality of the Windows installer, and install Tk too. But why would I want to? JimA
[Guido]
are you saying that your own installer can install the Python DLL but not the Tk DLL?
[James Ahlstrom]
Not exactly. I am saying I don't want to use the standard Python Windows installer. And I am saying I don't want to install Tk because it is big, complicated, and requires Tcl and its libraries.
My installer does install the Python DLL python15.dll, so I guess I could study how to install Tk and duplicate the functionality of the Windows installer, and install Tk too. But why would I want to?
That's up to you and your customers. What Guido has been telling you is that what the Windows installer does now (as of 1.6) to "install" Tcl/Tk is trivial: it merely copies some Tcl/Tk files into the Python installation tree. It no longer runs the Scriptics installer, mucks with the path, changes any envars, copies any files to outside of the Python tree, or even sets anything up in the registry for Tcl/Tk. You may not *want* to install Tcl/Tk, but, if you would like to, there's no longer any basis for fearing it's difficult, obscure, delicate or error-prone. don't-know-about-those-wrt-other-gui-pkgs-ly y'rs - tim
Tim Peters wrote:
That's up to you and your customers. What Guido has been telling you is that what the Windows installer does now (as of 1.6) to "install" Tcl/Tk is trivial: it merely copies some Tcl/Tk files into the Python installation tree. It no longer runs the Scriptics installer, mucks with the path,
Oh, OK. That is much better. JimA
Back in my former life, when I was still worrying about Windows, the company I worked for bought into a commerical x-platform GUI toolkit called Galaxy (I mentioned this earlier). Galaxy re-implemented all the native widgets, kind of like XPFE does. One issue with this was that MS seemed to change something about the widgets in every release - e.g. the Galaxy filechooser looked like Windows 3.1, then Win95 came out and Galaxy had to play catch-up. Once Galaxy had the Win95 LAF, Win98 came out. Now I hear there's something called Windows ME. Have they changed the look-and-feel again? Seems to me like all the widget-reimplementors are doomed to playing eternal catch-up.
Back in a former life of _mine_, I was one of two people who understood the architecture of Neuron Data's Open Interface Toolkit. It used the same strategy. Not sure what that has to do with Python, though it was a very fun project. It was also fun to turn on the Mac 'theme' on a Decwindows box (we're talking 1989 or so =). The funniest story about that job involves Cray and black and white monitors, but that's a story for another time, another place. --da
participants (20)
-
Andrew Kuchling -
Barry Scott -
barry＠wooz.org -
Charles G Waldman -
David Ascher -
Eric S. Raymond -
Fred L. Drake, Jr. -
Fredrik Lundh -
Gordon McMillan -
Greg Ewing -
Greg Ward -
Greg Wilson -
Guido van Rossum -
James C. Ahlstrom -
Jeremy Hylton -
Mark Hammond -
Moshe Zadka -
Paul Prescod -
Tim Peters -
Trent Mick