FYI: ajuba solutions (formerly scriptics) acquired by interwoven
looks like Tcl's parent company has ceased to be: http://biz.yahoo.com/bw/001020/ca_interwo.html "The Ajuba team will be assimilated into Interwoven's existing technical staff much as the Neonyoyo team was immediately after its acquisition in June. The Ajuba product line will be discontinued." </F>
Fredrik Lundh <effbot@telia.com>:
looks like Tcl's parent company has ceased to be:
This raises anew a question I've been meaning to bring up for the last week: is it finally time to move away from Python's dependence on Tcl/Tk for GUI support? It seems to me that the Tcl world has been in increasing disarray for the last two years. Its growth doesn't seem to have matched Perl's or Python's; no strong community site analogous to python.org or CPAN has emerged; and John Osterhout's attempt to commercialize the language have led to a series of false starts and erratic moves. And Osterhout cheerfully acknowledges that on a technical level that Tcl has been pushed past the natural limits of applicability for its design approach. Tcl's long-term prognosis looks, to me, increasingly poor. Which suggests to me that some move toqwards making Python less dependent on Tk would be a good thing. I understand that we can't simply drop Tkinter. But I think it might be worth another look at alternatives (notably wxPython) to consider bringing one into the core distribution during 2.x, so that later on we can plan to move Tk to "unsupported -- legacy". -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> You need only reflect that one of the best ways to get yourself a reputation as a dangerous citizen these days is to go about repeating the very phrases which our founding fathers used in the great struggle for independence. -- Attributed to Charles Austin Beard (1874-1948)
Fredrik Lundh <effbot@telia.com> wrote:
looks like Tcl's parent company has ceased to be:
I checked out comp.lang.tcl after hearing about this. Ousterhout posted to say that an official statement will be coming out today or tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see what he says the core team is going to do... On Mon, Oct 23, 2000 at 03:40:16PM -0400, Eric S. Raymond wrote:
It seems to me that supporting MacOS is the big problem for cross-platform GUIs. There are several different systems such as Qt that aim for portability across Windows and Unix, but add in the MacOS and the options really decrease. How good is wxWindows support for MacOS? Or will MacOS X fix the problem? I know MacOS X uses a BSD-based underlying kernel, but don't know if it will support X Windows out of the box. If people can only use MacOS-specific GUI APIs, then software such as Tk would still need to be ported specially to MacOS X. --amk
andrew wrote:
from an open-source perspective, Tcl might be more alive than ever: http://sourceforge.net/projects/tcl http://sourceforge.net/projects/tktoolkit and trust me, the Python 2.0/Tk8.4/Tkinter3000 combo will rock ;-) </F>
Fredrik Lundh wrote:
Perhaps this could be an opportunity to split Tcl and Tk more cleanly. People like Fredrick and his Perl/Ruby/... equivalents could get more deeply involved in setting direction. It would be interesting to contrast the number of Tcl versus Tk users right now. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html
On Tue, Oct 24, 2000 at 07:07:12PM +0200, Fredrik Lundh wrote:
In the long run this has probably harmed Tk seriously. If Tk was just a widget set divorced from Tcl, then it might have been chosen as the underlying widget set for GNOME or KDE, and then have benefited from the development work done for those projects, such as the GNOME canvas enhancements, which now can't be absorbed back into Tk without a lot of effort to merge the two sets of code. --amk
andrew wrote:
they just updated their site: http://www.ajubasolutions.com/company/whatsnew.html "Tcl is not a core technology at Interwoven, and Interwoven will not invest in the development of Tcl. However, Ajuba has transferred responsibility for Tcl core development to the newly formed Tcl Core Team /.../ We expect the Tcl Core Team to evolve Tcl at a much faster rate than any single organization could achieve by itself. "Over the next few weeks Ajuba will release in open- source form many of the Tcl packages that we deve- loped for our products. Stay tuned for more info... </F>
Andrew Kuchling <akuchlin@mems-exchange.org>:
It seems to me that supporting MacOS is the big problem for cross-platform GUIs.
It appears that we can't rely on anyone else to provide and support a GUI properly across all three platforms. If we want one, it looks like we'll have to do it ourselves. How about reviving and building upon stdwin? I quite liked stdwin, despite its limitations, because it was small and simple, and it worked on both Mac and Unix. 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 Ewing <greg@cosc.canterbury.ac.nz>:
I fear this is much too big a job to be practical -- not just in the additional code but the downstream maintainance. -- <a href="http:///~esr/">Eric S. Raymond</a> "I hold it, that a little rebellion, now and then, is a good thing, and as necessary in the political world as storms in the physical." -- Thomas Jefferson, Letter to James Madison, January 30, 1787
Eric Raymond:
I fear this is much too big a job to be practical -- not just in the additional code but the downstream maintainance.
Well said. The "roll your own" approach has been attempted before, but simply isn't worth the time and effort. After all, Python is a glue language! (And stdwin would really look pathetic in this time.) --Guido van Rossum (home page: http://www.python.org/~guido/)
Fredrik Lundh <effbot@telia.com>:
looks like Tcl's parent company has ceased to be:
Yes please.
I have been told by two different publishers that they can't even give Tcl books away any longer. It's also interesting that the new Ruby book from Hunt and Thomas clearly positions Ruby as an alternative to Python, rather than Tcl or Perl (I saw three mentions in the first ten minutes of the fact that Ruby is more widely used in Japan than Python). Also interesting that the Ruby GUI toolkit they describe is Tk-based...
I thought about using wxPython in the most recent run of my Python course, but decided to stick to Tkinter because: - There isn't a wxWindows/wxPython book (matters a lot when organizations are trying to decide what to adopt for long-term use). - Tkinter came packaged with the 1.5.2 installer, wxPython didn't. - There aren't as many tools on top of wxPython as there are on top of Tkinter. In particular, I think that a vector drawing package on top of wxPython that did what Sketch does, but on Windows as well as Linux, would make a great subject for a book on Python, non-trivial OO, and HCI (hint, hint...) Thanks, Greg
Some details begin to emerge at http://www.ajubasolutions.com/company/whatsnew.html It looks like some of their proprietary code will be released as open source, possibly including the TclPro development environment. The new company will not be funding Tcl/Tk development, and instead it's up to the 14 members of the recently-formed Tcl core team. I don't know if any of those people are being paid to work on Tcl, but probably at least some of them are. I expect this will cause a good deal disruption, perhaps even a fatal amount, particularly if core developers such as Jeffrey Hobbs no longer work on Tcl full-time. --amk
Andrew Kuchling <akuchlin@mems-exchange.org>:
Not necessarily... Good for Tcl: they *have* a core team now Bad for Tcl: at 14 it's too big, unless there's some inner core of no more than three or four architects. Good for Tcl: Much of the proprietary code will go open. Bad for Tcl: Not clear whether the two Ajuba employees "replaced" are on the new core team. Not clear whether their time available will increase or decrease. Good for Tcl: Osterhout's rather lame attempts to develop under a mixed model have almost certainly come to an end in favor of an Apache-like model funded by big Tcl users. With good leadership, they could manage the transition to something resembling the Apache Software Foundation's organization. If so, Tcl might actually improve. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Rifles, muskets, long-bows and hand-grenades are inherently democratic weapons. A complex weapon makes the strong stronger, while a simple weapon -- so long as there is no answer to it -- gives claws to the weak. -- George Orwell, "You and the Atom Bomb", 1945
I'm not on python-dev so please be sure to copy me on replies. "Greg Wilson" <gvwilson@nevex.com> wrote:
I thought about using wxPython in the most recent run of my Python course,
but
This is something I am hoping to change in the near future. I have a lot of ideas, have been putting an outline together, and have a phone conference with a potential publisher tomorrow. that
Hint received and understood... "Andrew Kuchling" akuchlin@mems-exchange.org wrote:
My understanding is that the version in CVS is nearly up to date with the features in the MSW and GTK versions, though I haven't had a chance to use it myself. It's in use in at least a few commercial applications around the world. The next step I guess is getting it wrapped up in wxPython, which should just be a matter of porting some of the low level startup and helper code, and putting some ifdef's in the SWIG interface files for things that may be different in the Mac version of wxWindows. Unfortunately, given the current state of the amount of my spare time and relative Mac-illiterate-ness, it's either going to require someone else to work on it and be wxPython-Mac's champion, or somebody needs to fund my ramp-up and development time so I can cut back on other things. The good news is that I have been loaned a Mac and CodeWarior and such to play with, I just haven't found the time to play much lately. "Guido van Rossum" guido@python.org wrote:
Just in case anybody didn't know already, wxWindows/wxPython has a wrapper around Scintilla available called wxStyledTextCtrl.
but I know of no widget in a popular widget set that offers anything close to the Canvas widget.
wxWindows has a canvas widget in development right now. I've been trying to nudge the developers working on it towards features found in the tk canvas and the GNOME canvas widget. I have high hopes for it but I'm not sure how long it will be before it gets to the same level as the others. -- Robin Dunn Software Craftsman robin@AllDunn.com http://wxPython.org Java give you jitters? http://wxPROs.com Relax with wxPython!
Robin Dunn <robin@alldunn.com>:
This is exactly what CoSource and SourceXchange are for. Post your Mac port as a project there and see who ponies up money. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> "...quemadmodum gladius neminem occidit, occidentis telum est." [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD),
This is exactly what CoSource and SourceXchange are for. Post your Mac
port
as a project there and see who ponies up money.
Now why didn't I think of that??? Thanks for the idea! -- Robin Dunn Software Craftsman robin@AllDunn.com http://wxPython.org Java give you jitters? http://wxPROs.com Relax with wxPython!
[ESR]
Yes, it may be time to have this discussion again. Of course, Tcl/Tk still has a much larger following than wxWindows, and it is more stable too. (For example, it's easy to cause crashes -- not just exceptions -- by leaving out an initialization call in wxPython.) Plus, Tk has two very high quality widgets: the Canvas and Text widgets are unsurpassed in functionality and robustness by other widget sets. You can draw more lines or characters per second in most toolkits, but few toolkits offer the convenience of marks and tags, not having to deal with refresh events, being able to group objects, move them around, change attributes, etc., etc., etc. The Scintilla text widget comes close (and surpasses Tkinter in some respects, while coming short in others), but I know of no widget in a popular widget set that offers anything close to the Canvas widget. There are other choices too, all of which have Python support already: gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David Ascher can fill me in). --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, Oct 23, 2000 at 04:08:13PM -0500, Guido van Rossum wrote:
I believe the GNOME (not GTk's, but GNOME's) canvas widget began as a fork of the Tk widget that was then substantially enhanced to be a general-purpose display engine, with antialiasing, alpha compositing, more attention to performance, and other fancy features. I don't know if the corresponding text widget (which is Pango, www.pango.org, I think) is equally featureful. --amk
On Mon, Oct 23, 2000 at 04:08:13PM -0500, Guido van Rossum wrote:
XUL. Though slappin' a GUI together in XUL is not all the same as for the other toolkits. Layout with XML, functionality with JavaScript and Python (and/or Perl of C++). Trent -- Trent Mick TrentM@ActiveState.com
Trimmed all CCs [Guido]
and the Mozilla toolkit (whose name I forget -- maybe David Ascher can fill me in).
[Trent "David Ascher" Mick responds]
As a fairly irrelevant (at this point in time) observation: Something about the Mozilla XUL engine seems "right". It is large and complex, but their XML based layout engine, and powerful "code-less" widget creation has a lot of potential IMO. It is very very new and rough. It is very tightly bound with Mozilla itself and javascript, although efforts are underway to separate it from both. It is huge, and constantly changing. It has been designed for tomorrow, and struggles along today. But it may well turn out to be and expressive and compelling model for the future. So, if we can just continue to disagree for the next 2 or 3 years, it may well become something worth considering ;-) Mark.
Guido van Rossum <guido@python.org>:
I'm glad you brought up GTK+. Of all the alternatives you mentioned, it seems to me the most likely to attract long-term cross-platform support by lots of developers (GNOME, Nautilus and Sun Microsystems seem like a tough trio to beat on this score). Thus, GTK+ may be be the safest alternative in terms of being least likely to strand us N years down the road. The GTK+ API seems like a nice clean design, and there is already a Python binding. Any comment from anybody on how stable it is? Are the text and canvas widgets anywhere near competitive with Tk's? There are hints of a wxWindows-based port to Windows on the GTK+ site; is there a Mac port? -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> .. a government and its agents are under no general duty to provide public services, such as police protection, to any particular individual citizen... -- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181)
The mozilla toolkits has more names than I care to remember. =) The most generic name is XPFE, although there are some parts of it with nicer names like XUL (pronounced Zool) and XBL. It also heavily uses XML, DTDs, CSS, etc. Mozilla is definitely a long-term investment in our part. For example, currently it's not possible to have Python code inline in the XUL (XML) code, and JavaScript is the only option there. We'll be working w/ the Netscape and Mozilla crowds to fix that, but it's not there yet. That said, Mozilla does have a fairly strong vision for the future, allows some of the benefits of the web technologies to transfer to the GUI world (designers, not coders, can do the UI work). In terms of the closest equivalent to the Canvas widget, apart from XUL itself, which is very hierarchical, there is the promise of SVG support, which will give you a lot more than the Canvas. That, too, is not quite ready for prime time yet. Hope this is helpful, --david
David Ascher writes:
Sounds great for the future, but I want to inject a few of my unsolicated, opinionated observations - today, in 2000, the Mozilla stuff is *far* from usable. If you want to produce nice, professional looking GUI apps which fit nicely with the desktop (rather that having their own completely different look-and-feel) it's hard to beat Gtk+ or Tkinter. Tkinter is still quite viable, especially if cross-plaform support is important. Some of the examples in Grayson's book are quite beautiful. It will be a long time until XPFE/XUL/whatchamacallit gets to this level of viability. Also consider that Sun (and HP?) now ship Gnome by default, rather than CDE (or so I hear, anyway). I predict that Gnome compatibility will become more and more of a desirable feature. Evidence of the above is the "Galeon" project. It's widely perceived that Mozilla has a nice rendering engine (Gecko) wrapped up in a dreadful GUI (XPFE). So the Galeon project places the Gecko engine inside a Gtk+/Gnome GUI, which provides a much more pleasant user experience. There's also a (preliminary) port of Gtk+ to Win32: http://www.gimp.org/~tml/gimp/win32/ And, finally, IMO, the work being done on PyGtk is of high quality. I'm using it currently in production code.
There's also a (preliminary) port of Gtk+ to Win32: http://www.gimp.org/~tml/gimp/win32/
FWIW, the last time I checked, this was useless. I'd be glad to be wrong, but I'm not holding my breath. Not surprisingly, the GTK crowd, which is rooted in Linux tradition (!), has little interest in Win32 ports, and even less experience in that world. Until that happens, a lot of platform-agnostic projects and vendors will have a hard time w/ GTK. I don't mean to diss GTK, just pointing out that cross-platform solutions are important to a whole lot of communities (Python included). --david
David Ascher writes:
That's what I meant by "preliminary" ;-)
I don't mean to diss GTK, just pointing out that cross-platform solutions are important to a whole lot of communities (Python included).
Right. Cross-platform is very important, but so is native look-and-feel, and this is where (IMO) XPFE falls flat on its face. Something like WxWindows, which uses Gtk+ on *nix and MFC (?) on Win, seems like it could be a real winner. If the x-platform GUI doesn't use native dialog boxes and filechoosers, users REALLY notice this and they will just hate it. (Yes, this is based on observations of actual paying customers). I have a little bit of experience with cross-platform development - having used a lot of these tools - at my last job, after evaluating just about everything, we bought into (against my advice!) a doomed commercial product called Visix Galaxy (for which I immediately created a set of Python bindings). The problem with all of these things, of course, is that the more cross-platform they are, the more "lowest-common-denominator" they are forced to become. Tkinter, with widgets like Canvas, was really pretty amazing - for its day - feature-rich *and x-platform. But even this broke down if you started using fancy features like drawing with dashed lines - works on X, not on Windows (last time I checked, anyway) - the more you start pushing the limits of the toolkit, the more the portability breaks down. Tkinter-is-dead-long-live-Tkinter'ly yrs, -C
Right. Cross-platform is very important, but so is native look-and-feel, and this is where (IMO) XPFE falls flat on its face.
Actually, my experience with XPFE from a look-and-feel POV has been pretty positive. It is true they have re-implemented most widgets rather than use native ones, and also true that you can make these widgets look nothing like native LAF - but generally, my experience with Mozilla and the "classic" skin is that it is close enough that it is very hard to tell. It looks more like "subtle enhancements", in the same way IE provides "subtle enhancements"
seems like it could be a real winner. If the x-platform GUI doesn't use native dialog boxes and filechoosers, users REALLY notice this and
Agreed. However, XPFE works fine here IMO. Again, I do not want to propose XPFE as viable today, and I agree it may never be viable. Most other critisisms posted are valid, but I don't think that LAF is one such problem with XPFE. Mark.
Fredrik Lundh <effbot@telia.com>:
looks like Tcl's parent company has ceased to be:
This raises anew a question I've been meaning to bring up for the last week: is it finally time to move away from Python's dependence on Tcl/Tk for GUI support? It seems to me that the Tcl world has been in increasing disarray for the last two years. Its growth doesn't seem to have matched Perl's or Python's; no strong community site analogous to python.org or CPAN has emerged; and John Osterhout's attempt to commercialize the language have led to a series of false starts and erratic moves. And Osterhout cheerfully acknowledges that on a technical level that Tcl has been pushed past the natural limits of applicability for its design approach. Tcl's long-term prognosis looks, to me, increasingly poor. Which suggests to me that some move toqwards making Python less dependent on Tk would be a good thing. I understand that we can't simply drop Tkinter. But I think it might be worth another look at alternatives (notably wxPython) to consider bringing one into the core distribution during 2.x, so that later on we can plan to move Tk to "unsupported -- legacy". -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> You need only reflect that one of the best ways to get yourself a reputation as a dangerous citizen these days is to go about repeating the very phrases which our founding fathers used in the great struggle for independence. -- Attributed to Charles Austin Beard (1874-1948)
Fredrik Lundh <effbot@telia.com> wrote:
looks like Tcl's parent company has ceased to be:
I checked out comp.lang.tcl after hearing about this. Ousterhout posted to say that an official statement will be coming out today or tomorrow, so I wouldn't conclude that Tcl is dead just yet; we'll see what he says the core team is going to do... On Mon, Oct 23, 2000 at 03:40:16PM -0400, Eric S. Raymond wrote:
It seems to me that supporting MacOS is the big problem for cross-platform GUIs. There are several different systems such as Qt that aim for portability across Windows and Unix, but add in the MacOS and the options really decrease. How good is wxWindows support for MacOS? Or will MacOS X fix the problem? I know MacOS X uses a BSD-based underlying kernel, but don't know if it will support X Windows out of the box. If people can only use MacOS-specific GUI APIs, then software such as Tk would still need to be ported specially to MacOS X. --amk
andrew wrote:
from an open-source perspective, Tcl might be more alive than ever: http://sourceforge.net/projects/tcl http://sourceforge.net/projects/tktoolkit and trust me, the Python 2.0/Tk8.4/Tkinter3000 combo will rock ;-) </F>
Fredrik Lundh wrote:
Perhaps this could be an opportunity to split Tcl and Tk more cleanly. People like Fredrick and his Perl/Ruby/... equivalents could get more deeply involved in setting direction. It would be interesting to contrast the number of Tcl versus Tk users right now. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html
On Tue, Oct 24, 2000 at 07:07:12PM +0200, Fredrik Lundh wrote:
In the long run this has probably harmed Tk seriously. If Tk was just a widget set divorced from Tcl, then it might have been chosen as the underlying widget set for GNOME or KDE, and then have benefited from the development work done for those projects, such as the GNOME canvas enhancements, which now can't be absorbed back into Tk without a lot of effort to merge the two sets of code. --amk
andrew wrote:
they just updated their site: http://www.ajubasolutions.com/company/whatsnew.html "Tcl is not a core technology at Interwoven, and Interwoven will not invest in the development of Tcl. However, Ajuba has transferred responsibility for Tcl core development to the newly formed Tcl Core Team /.../ We expect the Tcl Core Team to evolve Tcl at a much faster rate than any single organization could achieve by itself. "Over the next few weeks Ajuba will release in open- source form many of the Tcl packages that we deve- loped for our products. Stay tuned for more info... </F>
Andrew Kuchling <akuchlin@mems-exchange.org>:
It seems to me that supporting MacOS is the big problem for cross-platform GUIs.
It appears that we can't rely on anyone else to provide and support a GUI properly across all three platforms. If we want one, it looks like we'll have to do it ourselves. How about reviving and building upon stdwin? I quite liked stdwin, despite its limitations, because it was small and simple, and it worked on both Mac and Unix. 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 Ewing <greg@cosc.canterbury.ac.nz>:
I fear this is much too big a job to be practical -- not just in the additional code but the downstream maintainance. -- <a href="http:///~esr/">Eric S. Raymond</a> "I hold it, that a little rebellion, now and then, is a good thing, and as necessary in the political world as storms in the physical." -- Thomas Jefferson, Letter to James Madison, January 30, 1787
Eric Raymond:
I fear this is much too big a job to be practical -- not just in the additional code but the downstream maintainance.
Well said. The "roll your own" approach has been attempted before, but simply isn't worth the time and effort. After all, Python is a glue language! (And stdwin would really look pathetic in this time.) --Guido van Rossum (home page: http://www.python.org/~guido/)
Fredrik Lundh <effbot@telia.com>:
looks like Tcl's parent company has ceased to be:
Yes please.
I have been told by two different publishers that they can't even give Tcl books away any longer. It's also interesting that the new Ruby book from Hunt and Thomas clearly positions Ruby as an alternative to Python, rather than Tcl or Perl (I saw three mentions in the first ten minutes of the fact that Ruby is more widely used in Japan than Python). Also interesting that the Ruby GUI toolkit they describe is Tk-based...
I thought about using wxPython in the most recent run of my Python course, but decided to stick to Tkinter because: - There isn't a wxWindows/wxPython book (matters a lot when organizations are trying to decide what to adopt for long-term use). - Tkinter came packaged with the 1.5.2 installer, wxPython didn't. - There aren't as many tools on top of wxPython as there are on top of Tkinter. In particular, I think that a vector drawing package on top of wxPython that did what Sketch does, but on Windows as well as Linux, would make a great subject for a book on Python, non-trivial OO, and HCI (hint, hint...) Thanks, Greg
Some details begin to emerge at http://www.ajubasolutions.com/company/whatsnew.html It looks like some of their proprietary code will be released as open source, possibly including the TclPro development environment. The new company will not be funding Tcl/Tk development, and instead it's up to the 14 members of the recently-formed Tcl core team. I don't know if any of those people are being paid to work on Tcl, but probably at least some of them are. I expect this will cause a good deal disruption, perhaps even a fatal amount, particularly if core developers such as Jeffrey Hobbs no longer work on Tcl full-time. --amk
Andrew Kuchling <akuchlin@mems-exchange.org>:
Not necessarily... Good for Tcl: they *have* a core team now Bad for Tcl: at 14 it's too big, unless there's some inner core of no more than three or four architects. Good for Tcl: Much of the proprietary code will go open. Bad for Tcl: Not clear whether the two Ajuba employees "replaced" are on the new core team. Not clear whether their time available will increase or decrease. Good for Tcl: Osterhout's rather lame attempts to develop under a mixed model have almost certainly come to an end in favor of an Apache-like model funded by big Tcl users. With good leadership, they could manage the transition to something resembling the Apache Software Foundation's organization. If so, Tcl might actually improve. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Rifles, muskets, long-bows and hand-grenades are inherently democratic weapons. A complex weapon makes the strong stronger, while a simple weapon -- so long as there is no answer to it -- gives claws to the weak. -- George Orwell, "You and the Atom Bomb", 1945
I'm not on python-dev so please be sure to copy me on replies. "Greg Wilson" <gvwilson@nevex.com> wrote:
I thought about using wxPython in the most recent run of my Python course,
but
This is something I am hoping to change in the near future. I have a lot of ideas, have been putting an outline together, and have a phone conference with a potential publisher tomorrow. that
Hint received and understood... "Andrew Kuchling" akuchlin@mems-exchange.org wrote:
My understanding is that the version in CVS is nearly up to date with the features in the MSW and GTK versions, though I haven't had a chance to use it myself. It's in use in at least a few commercial applications around the world. The next step I guess is getting it wrapped up in wxPython, which should just be a matter of porting some of the low level startup and helper code, and putting some ifdef's in the SWIG interface files for things that may be different in the Mac version of wxWindows. Unfortunately, given the current state of the amount of my spare time and relative Mac-illiterate-ness, it's either going to require someone else to work on it and be wxPython-Mac's champion, or somebody needs to fund my ramp-up and development time so I can cut back on other things. The good news is that I have been loaned a Mac and CodeWarior and such to play with, I just haven't found the time to play much lately. "Guido van Rossum" guido@python.org wrote:
Just in case anybody didn't know already, wxWindows/wxPython has a wrapper around Scintilla available called wxStyledTextCtrl.
but I know of no widget in a popular widget set that offers anything close to the Canvas widget.
wxWindows has a canvas widget in development right now. I've been trying to nudge the developers working on it towards features found in the tk canvas and the GNOME canvas widget. I have high hopes for it but I'm not sure how long it will be before it gets to the same level as the others. -- Robin Dunn Software Craftsman robin@AllDunn.com http://wxPython.org Java give you jitters? http://wxPROs.com Relax with wxPython!
Robin Dunn <robin@alldunn.com>:
This is exactly what CoSource and SourceXchange are for. Post your Mac port as a project there and see who ponies up money. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> "...quemadmodum gladius neminem occidit, occidentis telum est." [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD),
This is exactly what CoSource and SourceXchange are for. Post your Mac
port
as a project there and see who ponies up money.
Now why didn't I think of that??? Thanks for the idea! -- Robin Dunn Software Craftsman robin@AllDunn.com http://wxPython.org Java give you jitters? http://wxPROs.com Relax with wxPython!
[ESR]
Yes, it may be time to have this discussion again. Of course, Tcl/Tk still has a much larger following than wxWindows, and it is more stable too. (For example, it's easy to cause crashes -- not just exceptions -- by leaving out an initialization call in wxPython.) Plus, Tk has two very high quality widgets: the Canvas and Text widgets are unsurpassed in functionality and robustness by other widget sets. You can draw more lines or characters per second in most toolkits, but few toolkits offer the convenience of marks and tags, not having to deal with refresh events, being able to group objects, move them around, change attributes, etc., etc., etc. The Scintilla text widget comes close (and surpasses Tkinter in some respects, while coming short in others), but I know of no widget in a popular widget set that offers anything close to the Canvas widget. There are other choices too, all of which have Python support already: gtk, qt, and the Mozilla toolkit (whose name I forget -- maybe David Ascher can fill me in). --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, Oct 23, 2000 at 04:08:13PM -0500, Guido van Rossum wrote:
I believe the GNOME (not GTk's, but GNOME's) canvas widget began as a fork of the Tk widget that was then substantially enhanced to be a general-purpose display engine, with antialiasing, alpha compositing, more attention to performance, and other fancy features. I don't know if the corresponding text widget (which is Pango, www.pango.org, I think) is equally featureful. --amk
On Mon, Oct 23, 2000 at 04:08:13PM -0500, Guido van Rossum wrote:
XUL. Though slappin' a GUI together in XUL is not all the same as for the other toolkits. Layout with XML, functionality with JavaScript and Python (and/or Perl of C++). Trent -- Trent Mick TrentM@ActiveState.com
Trimmed all CCs [Guido]
and the Mozilla toolkit (whose name I forget -- maybe David Ascher can fill me in).
[Trent "David Ascher" Mick responds]
As a fairly irrelevant (at this point in time) observation: Something about the Mozilla XUL engine seems "right". It is large and complex, but their XML based layout engine, and powerful "code-less" widget creation has a lot of potential IMO. It is very very new and rough. It is very tightly bound with Mozilla itself and javascript, although efforts are underway to separate it from both. It is huge, and constantly changing. It has been designed for tomorrow, and struggles along today. But it may well turn out to be and expressive and compelling model for the future. So, if we can just continue to disagree for the next 2 or 3 years, it may well become something worth considering ;-) Mark.
Guido van Rossum <guido@python.org>:
I'm glad you brought up GTK+. Of all the alternatives you mentioned, it seems to me the most likely to attract long-term cross-platform support by lots of developers (GNOME, Nautilus and Sun Microsystems seem like a tough trio to beat on this score). Thus, GTK+ may be be the safest alternative in terms of being least likely to strand us N years down the road. The GTK+ API seems like a nice clean design, and there is already a Python binding. Any comment from anybody on how stable it is? Are the text and canvas widgets anywhere near competitive with Tk's? There are hints of a wxWindows-based port to Windows on the GTK+ site; is there a Mac port? -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> .. a government and its agents are under no general duty to provide public services, such as police protection, to any particular individual citizen... -- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181)
The mozilla toolkits has more names than I care to remember. =) The most generic name is XPFE, although there are some parts of it with nicer names like XUL (pronounced Zool) and XBL. It also heavily uses XML, DTDs, CSS, etc. Mozilla is definitely a long-term investment in our part. For example, currently it's not possible to have Python code inline in the XUL (XML) code, and JavaScript is the only option there. We'll be working w/ the Netscape and Mozilla crowds to fix that, but it's not there yet. That said, Mozilla does have a fairly strong vision for the future, allows some of the benefits of the web technologies to transfer to the GUI world (designers, not coders, can do the UI work). In terms of the closest equivalent to the Canvas widget, apart from XUL itself, which is very hierarchical, there is the promise of SVG support, which will give you a lot more than the Canvas. That, too, is not quite ready for prime time yet. Hope this is helpful, --david
David Ascher writes:
Sounds great for the future, but I want to inject a few of my unsolicated, opinionated observations - today, in 2000, the Mozilla stuff is *far* from usable. If you want to produce nice, professional looking GUI apps which fit nicely with the desktop (rather that having their own completely different look-and-feel) it's hard to beat Gtk+ or Tkinter. Tkinter is still quite viable, especially if cross-plaform support is important. Some of the examples in Grayson's book are quite beautiful. It will be a long time until XPFE/XUL/whatchamacallit gets to this level of viability. Also consider that Sun (and HP?) now ship Gnome by default, rather than CDE (or so I hear, anyway). I predict that Gnome compatibility will become more and more of a desirable feature. Evidence of the above is the "Galeon" project. It's widely perceived that Mozilla has a nice rendering engine (Gecko) wrapped up in a dreadful GUI (XPFE). So the Galeon project places the Gecko engine inside a Gtk+/Gnome GUI, which provides a much more pleasant user experience. There's also a (preliminary) port of Gtk+ to Win32: http://www.gimp.org/~tml/gimp/win32/ And, finally, IMO, the work being done on PyGtk is of high quality. I'm using it currently in production code.
There's also a (preliminary) port of Gtk+ to Win32: http://www.gimp.org/~tml/gimp/win32/
FWIW, the last time I checked, this was useless. I'd be glad to be wrong, but I'm not holding my breath. Not surprisingly, the GTK crowd, which is rooted in Linux tradition (!), has little interest in Win32 ports, and even less experience in that world. Until that happens, a lot of platform-agnostic projects and vendors will have a hard time w/ GTK. I don't mean to diss GTK, just pointing out that cross-platform solutions are important to a whole lot of communities (Python included). --david
David Ascher writes:
That's what I meant by "preliminary" ;-)
I don't mean to diss GTK, just pointing out that cross-platform solutions are important to a whole lot of communities (Python included).
Right. Cross-platform is very important, but so is native look-and-feel, and this is where (IMO) XPFE falls flat on its face. Something like WxWindows, which uses Gtk+ on *nix and MFC (?) on Win, seems like it could be a real winner. If the x-platform GUI doesn't use native dialog boxes and filechoosers, users REALLY notice this and they will just hate it. (Yes, this is based on observations of actual paying customers). I have a little bit of experience with cross-platform development - having used a lot of these tools - at my last job, after evaluating just about everything, we bought into (against my advice!) a doomed commercial product called Visix Galaxy (for which I immediately created a set of Python bindings). The problem with all of these things, of course, is that the more cross-platform they are, the more "lowest-common-denominator" they are forced to become. Tkinter, with widgets like Canvas, was really pretty amazing - for its day - feature-rich *and x-platform. But even this broke down if you started using fancy features like drawing with dashed lines - works on X, not on Windows (last time I checked, anyway) - the more you start pushing the limits of the toolkit, the more the portability breaks down. Tkinter-is-dead-long-live-Tkinter'ly yrs, -C
Right. Cross-platform is very important, but so is native look-and-feel, and this is where (IMO) XPFE falls flat on its face.
Actually, my experience with XPFE from a look-and-feel POV has been pretty positive. It is true they have re-implemented most widgets rather than use native ones, and also true that you can make these widgets look nothing like native LAF - but generally, my experience with Mozilla and the "classic" skin is that it is close enough that it is very hard to tell. It looks more like "subtle enhancements", in the same way IE provides "subtle enhancements"
seems like it could be a real winner. If the x-platform GUI doesn't use native dialog boxes and filechoosers, users REALLY notice this and
Agreed. However, XPFE works fine here IMO. Again, I do not want to propose XPFE as viable today, and I agree it may never be viable. Most other critisisms posted are valid, but I don't think that LAF is one such problem with XPFE. Mark.
participants (13)
-
Andrew Kuchling -
Charles G Waldman -
David Ascher -
Eric S. Raymond -
Fredrik Lundh -
Greg Ewing -
Greg Wilson -
Guido van Rossum -
Mark Hammond -
Paul Prescod -
Robin Dunn -
Tim Peters -
Trent Mick