Ten Essential Development Practices

[Ed Leafe]

FWIW, some people may find this page interesting, which gives you an
idea what "standard" Tk looks like on OS X, and then with adopting the
"tile" extension to Tk and a few other tweaks, which is on its way to
becoming a standard part of Tk:
      http://wiki.tcl.tk/14522

That's certainly an improvement. But when we reviewed the various toolkits a
year and a half ago, we just looked at the standard Tk stuff.

 

[Peter Decker]

Most people? What percentage of actual Python users do you think have
wxPython installed? If you're really claiming it's over 50%, you're
out of your mind.

Oh, sorry, I forgot that I have to type slower so that you can follow along..

We were discussing your 'enormous pain' installing wxPython. I find it
interesting that you selectively quoted part of one line of my post,
leaving out the remainder of the sentence that establishes context. It
confirms the earlier observation that you're just trolling.

 

[Paul Rubin]

We were discussing your 'enormous pain' installing wxPython. I find it
interesting that you selectively quoted part of one line of my post,

Yes, the one line I quoted was the one that said most people have
wxPython installed, which is a preposterous claim. The reason they
don't have it installed is they don't have reason to go through the
hassle of installing it, given (among other things) that tkinter is
already there. If they don't want to go through that hassle, I don't
see why I should want to go through it.

As for installing from source, well, that's what I see the whole FOSS
movement as being about. If I can't compile the source, why should I
care about having it? And if I don't care about having it, what's the
point of FOSS? Source that I can't compile is not much better than no
source.

 

[Cliff Wells]

Try this as one example:
http://wiki.tcl.tk/4094

Okay, I figured if any, Win32 would be the one that worked, and I even
recall seeing this example at one time. However, last time I checked,
this bit of code wasn't actually working (although it may have been a
temporary situation).

Still, that leaves Linux and Mac out in the cold. But I'll admit you
met my challenge. Most likely you can actually do most of the things
with Tk you can with Wx, it's simply a matter of how much effort is
going to be (for instance, it's certainly quite possible to embed Gecko
in Tk, but I for one am not likely to be up to the task).

I'd respectfully disagree (having done large, real-world Tk apps).
You're right that Tk has a slow learning curve, which makes it easy to
knock out simple interfaces really quickly - and generally ones that are
not too impressive looking. You can do more sophisticated ones, and
ones that blend properly into the platforms you're working on - however,
the amount of effort and learning curve increase substantially. This is
because you end up needing to do a lot more fiddling, looking at or
using any of a large number of add-on packages, etc.).

Yes, this was my finding with Tk. I ended up using Pmw.MegaWidgets and
a few other things to make up for deficiencies in the core library, but
mostly I found a need to write highly sophisticated controls myself,
many of which were simply provided by wxPython. I was spending more
time writing controls than writing applications. It was kind of fun and
interesting, but not very productive. This is what prompted my move to
wxPython several years ago. I still believe wxPython to be a much more
rapidly evolving toolkit (although my tracking of Tk has fallen to
almost nil since the switch so I'm willing to stand corrected or at
least leave the point open to debate). The native look-and-feel across
all platforms was another big motivation, but no the primary one.
Mostly I found that the steeper learning curve paid off quite well in
the long run.

Regards,
Cliff

 

[Peter Decker]

Yes, the one line I quoted was the one that said most people have
wxPython installed, which is a preposterous claim.

OK, troll, the above is an actual quote. Now how about if I
selectively quote part of one of your sentences instead?

most people have wxPython installed

Wow, how could you make such a claim!? Gee, isn't it interesting how
you can distort someone's intent by leaving out certain parts of what
they wrote?

Well, I think you've adequately displayed your integrity here in your
desperate attempt to convert everyone to your One True Purist Faith.
I'm done feeding the troll.

 

[Cliff Wells]

Yes, the one line I quoted was the one that said most people have
wxPython installed, which is a preposterous claim. The reason they
don't have it installed is they don't have reason to go through the
hassle of installing it, given (among other things) that tkinter is
already there. If they don't want to go through that hassle, I don't
see why I should want to go through it.

I seriously hope you are being intentionally obtuse, otherwise your
difficulties with wxPython have acquired a sharply illuminated source.
It was quite clear that by saying "most people" he was not referring to
the set of "most Python users", but rather the set of "most people who
have tried wxPython".

Cliff

 

[Reinhold Birkenfeld]

Hi Reinhold,

did You have a look at 'venster'?

http://venster.sourceforge.net/htdocs/index.html

They even dropped win32gui and worked with ctypes and the Win32API
reducing the C-footprint. For frameworks like Dabo, AnyGUI, PyGUI etc.
this would be the right level to create an abstraction layer IMO. By
the way the demo applications of venster run stable and fast on WinXP.

Ah! No, I didn't know this. I don't need it, either but good to know
it exists.

Of course, doing such a thing for Xlib is more complicated because it
doesn't know native widgets (okay, you can use Athena et al., but who
wants them today...).

Reinhold

 

[Paul Rubin]

Still, that leaves Linux and Mac out in the cold. But I'll admit you
met my challenge. Most likely you can actually do most of the things
with Tk you can with Wx, it's simply a matter of how much effort is
going to be (for instance, it's certainly quite possible to embed Gecko
in Tk, but I for one am not likely to be up to the task).

I actually misunderstood your question about embedding a browser and
thought for a while about what it would take to write or port a
serious browser to use tkinter as its graphics layer. The resulting
picture wasn't pretty. I wonder whether it's feasible in wxpython.

I like the idea of a browser-like portable gui toolkit. Instead of
merely wrapping some other widget set, you'd write your interface as
an XML file using HTML-like interface elements. You'd have callbacks
on the form submit buttons and optionally on the other input elements,
and you could get at the elements through the XML DOM if you were so
inclined (sort of like the HTML DOM that browsers expose through
Javascript). Implementations could run on top of Tk, GTK, native
Windows widgets, or whatever.

The language probably shouldn't be exactly HTML (e.g. it should have
some additional widgets), but maybe it could be close enough that
people wanting to do so could use the various wysiwyg web-layout
programs that are out there, to put interfaces together.

 

[Paul Rubin]

It was quite clear that by saying "most people" he was not referring to
the set of "most Python users", but rather the set of "most people who
have tried wxPython".

That wasn't clear to me. If that's what he meant, he should have said so.

 

[Cliff Wells]

I actually misunderstood your question about embedding a browser and
thought for a while about what it would take to write or port a
serious browser to use tkinter as its graphics layer. The resulting
picture wasn't pretty. I wonder whether it's feasible in wxpython.

wxPython has a toy HTML renderer that allows embedding wxPython widgets
directly into it. If you only need simple HTML it works great. It is
also possible to embed IE, Safari and Mozilla (via wxMozilla) but you
lose the ability to embed the wxPython widgets).

I like the idea of a browser-like portable gui toolkit. Instead of
merely wrapping some other widget set, you'd write your interface as
an XML file using HTML-like interface elements. You'd have callbacks
on the form submit buttons and optionally on the other input elements,
and you could get at the elements through the XML DOM if you were so
inclined (sort of like the HTML DOM that browsers expose through
Javascript). Implementations could run on top of Tk, GTK, native
Windows widgets, or whatever.

Actually wxPython has this today (and has had for some time): you can
build your interface code in XML and wxPython will build the interface
on the fly. I played with it once as a method of building a dialog
editor along the lines of VB, but the project I needed it for died and I
didn't have time to finish. My discovery was that it was entirely
doable though, had I had time to finish.

In fact, with the XRC stuff in wxPython, you can even create custom
controls with pure XML. I'm not sure how great this is for hand-built
interfaces (but I haven't tried), but it seems ideal for automated
generation of GUI's.


Regards,
Cliff

 

[Cliff Wells]

That wasn't clear to me. If that's what he meant, he should have said so.

Paul,

Honestly what appears to me to be happening here is that you have found
yourself assailed on all sides and are perhaps getting a bit too quick
with both your reading of posts and with your replies. The end result
is you end up trying to defend your earlier statements, which, due to
haste, were either worded incorrectly or based on incorrect
interpretations of what others have said. Then because you feel under
attack you are compelled to defend those statements further, quite
probably against your own better judgement.

I know I've contributed plenty to this situation (and I'll also admit to
having been in similar situations before, and it's a lot easier to get
into this situation than to get out of it), therefore I'll make you a
deal: you slow down and put a bit more thought into your replies and
I'll lay off the sideways comments and cut you some slack. In fact,
enough having been said, I think I'll just try to let this thread die a
natural death.

Deal?

Regards,
Cliff

P.S. I would have preferred to have made this off-list, but I can't
figure out how I should decipher your email address.

 

[Mark Roseman]

I actually misunderstood your question about embedding a browser and
thought for a while about what it would take to write or port a
serious browser to use tkinter as its graphics layer. The resulting
picture wasn't pretty. I wonder whether it's feasible in wxpython.

I'll point out that this has been done (in fact, many times). For
example:
http://tkhtml.hwaci.com

(Integrating Gecko in has also been done, as a side note).

I'll highlight a meta-point regarding this thread: there's a lot of
stuff in Tk that is available but not built into the standard library,
nor necessarily well documented or even easy to find. While this is a
sad state of affairs, and to my mind no excuse (even though this is a
common situation with open source software), it emphasizes that a
cursory look does not tell the whole story.

While I certainly don't begrudge anyone their choice of tools, it's no
surprise that someone who's become more familiar with wxPython would
have an unduly low opinion of Tk. They've obviously spent more time
overcoming the warts in wxPython, and wouldn't have spent comparable
effort learning what it would take to overcome the warts in Tk - it just
looks hopelessly flawed in comparison.

Switch "wxPython" and "Tk" around in the above argument and I think the
statements equally hold of course.

Mark

 

[Cliff Wells]

I'll point out that this has been done (in fact, many times). For
example:
http://tkhtml.hwaci.com

(Integrating Gecko in has also been done, as a side note).

Interesting. Your later point about hard to find is certainly correct
as my searches (albeit not as in-depth as they could have been) turned
up little in this regard.

While I certainly don't begrudge anyone their choice of tools, it's no
surprise that someone who's become more familiar with wxPython would
have an unduly low opinion of Tk. They've obviously spent more time
overcoming the warts in wxPython, and wouldn't have spent comparable
effort learning what it would take to overcome the warts in Tk - it just
looks hopelessly flawed in comparison.

Well, as was mentioned earlier (by Paul I believe), "life is too short",
in this case, to become expert in more than one GUI toolkit (which as a
whole, are a wart on the face of programming in general, IMHO). They
are highly complex and require a large investment of time regardless of
which you choose. People often cite one kit as being "more pythonic"
than another, but frankly I've yet to see one that even remotely meets
that (admittedly vague) criteria. I've made my choices based on my own
criteria, and certainly I would not hesitate to recommend my choices to
others.

Frankly most of my ire in this thread has been over things tertiary to
the toolkits themselves: 1) the idea of demanding that one toolkit be
"the preferred" way 2) dismissing without due consideration the hard
work of others who have volunteered their code without demand for
recompense, and 3) what I've taken (rightly or wrongly) to be deliberate
obtuseness on the part of some of the participants.

Aside from that, I consider the choice of GUI toolkits to be a pretty
benign issue and hardly one qualifying for the level of heat we've had
for the last day or so.

Switch "wxPython" and "Tk" around in the above argument and I think the
statements equally hold of course.

Agreed.

Regards,
Cliff

 

[Mike Meyer]

You install GUI apps on Unix *servers*?

Yup. Thanks to the wonders of X, I can run GUI apps on servers and
have them display on my desktop. Or my OS X laptop. I normally leave a
gkrellm running on most of my servers.

Of course, the problem under discussion isn't restricted to GUI
apps. Anytime I use a third party library, I have to deal with how end
users are going to get it.

Regardless, when you say "Unix", what do you mean? You may as well say
"OS" as this term has little meaning. Linux (which flavor)? BSD? SCO?
HPUX? OS/X? Minix? Whichever way, I suspect that a bit of distutils
hacking would solve your problem.

I think the post I replied to covered the OS X case - there's an
application bundler available for it already.

I want distributions that will work on all three major BSD variants
and most Linux distrubtions - in particular, anything that uses deb's,
rpm's or emerge. If you want to choose one in particular, try ubuntu
Linux.

<mike

 

[Mike Meyer]

So we don't solve the problem with a "standard" distribution and that was
the point I was trying to show.

Exactly what problem are you trying to solve? If it's the one about
not having a standard GUI, I don't think it's a problem.

In fact this sounds more like a joke I've heard a while ago: standards, if
you don't like the ones out there, create your own.

Works for me.

And solve a completely different problem while sharing the very same problem
you, on the post prior to mine, was trying to solve: what is the standard
GUI on a Linux distribution? QVWM? WindowMaker? Gnome? KDE? FVWM?

I think you have me confused with someone else. I was responding to
someone who was claiming that the lack of a standard enterprise
strength GUI toolkit was a serious problem for Python - I disagree. I
won't recap the thread, but other languages have been *very*
successful without having a GUI as part of the language, all they had
was one development environment distributed with a GUI.

BTW, in answer to your rhetorical question about GUI's for Linux, the
answer is plwm.

<mike

 

[Mike Meyer]

Hallöchen!

[...]

None of us has talked about changing syntax. However, the
standard library is part of the language unless you're really
very petty.

Or you use different Python implementations. There are four
different Python implementations in the world. Not everything in
the CPYthon standard library runs in all of them. Or are you going
to claim that someone usin Jython isn't using Python because they
can't use the full standard library?

Well, in a way, they aren't using Python indeed. For example, most
Python books tell only partly the truth in this case.

Well, in a way, you're right. On the other hand, Guido has always
insisted that CPython is just an implementation, and not a definition.

You have to take into account not only the number of application
areas, but also their respective importance.

True. To you, GUI applications are very important. To me, they pretty
much don't matter at all.

I'm interested in a language with a big community. This is my
definition of success. It has to do with the functionality I can
expect (more contributors can create more modules and documentation)
and with future-proofness.

GUI applications seem to be the most attractive application type.
This is not only true for commercial programming. When I look at
the most agile projects on Sourceforge, almost all of them have a
GUI.

Why restrict yourself to agile projects? For that matter, how do you
decide if a project is agile or not?

I won't argue that most of the projects on Sourceforge have GUIs -
that's certainly true. I will argue that most of the projects are done
in languages that aren't what you call GUI-aware.

Therefore, GUI-aware languages attract much larger user bases, and
so they cater my definition of being successful.

Since you haven't stated what that definition is, I can't really say
anything about this. If you're counting applications on sourceforge,
the evidence doesn't support your conclusion. C and C++ are the most
used languages by an order of magnitude, and neither of those has
integral GUI support.

[...] By which measure C is still immensely popular, because of
the large number of older applications that are written in it that
are available - Python being one such.

Legacy code is not a sign of success IMO because it implies a
difficult future.

So you're saying that Python, Perl, Linux, the various BSD
et. al. will have a difficult future? If you believe that about
Python, then why are you here at all?

[...] I'd say Python has succeeded as a web development language,
and as a systems scripting language - and I've certainly missed
some.

I don't think that Python should rely on these old strongholds. In
the biggest bookstore of our region, there is one book about Zope
but a whole bookself about PHP. And I've never used consciously a
Python system script in contrast to dozens of Perl scripts.

Um - you should compare apples to apples. Zope is an application
development framework, and doesn't really compete in the same space as
PHP and Python. For that matter, as you note, PHP is a special-purpose
language (for a very popular application area) whereas Python is
general purpose language.

As for system scripts, Python is the primary system scripting tool for
a number of Linux distributions (gentoo and redhat come to mind), and
if I understand correctly, it's also used pretty heavily in OS X.

In contrast to PHP or Perl, I consider Python a general-purpose
language. There is its future in my opinion. However, this area is
much tougher, and you need a good GUI approach there.

I know a large number of people who'd argue with you implying that
Perl isn't a general-purpose language. It's more successful than
Python pretty much across teh board.

[...] Could it be that that's what you really want - someone to
distribute Python bundled with an enterprise-class GUI library
and IDE?

Well, a nice thing to have, but besides my point.

Then you seem to have missed some of your own points. C++
succeeded without having a standard GUI library. You claimed that
that success was because of a single distribution that included
the things you are looking for. Why can't the same thing work for
Python?

I just didn't say that it couldn't work. But I don't think it'll
happen, that's all.

Well, if you dismiss it out of hand, it certainly won't happen. Try
asking ActiveState (they seem to be the major alternative distribution
of CPython) to consider it, rather than trying to get it into the
www.python.org distribution of CPython.

Or maybe you could switch to Jython, and just use swing?

<mike

 

[Cliff Wells]

Yup. Thanks to the wonders of X, I can run GUI apps on servers and
have them display on my desktop. Or my OS X laptop. I normally leave a
gkrellm running on most of my servers.

Yes, yes. The "wonders of X" have been known to me since around 1992.
Personally I avoid running GUI apps on my servers since they are usually
unnecessary, waste memory, and if not used properly, open the door for
security issues (for that matter, any extra piece of software installed
opens the door for potential security issues so I tend to run
stripped-down servers that only provide needed services - no fluff.
Then again "server" is a pretty broad term. The bulk of my servers are
shared and dedicated hosting environments where paranoia is rewarded.
Your situation may be different).

Of course, the problem under discussion isn't restricted to GUI
apps. Anytime I use a third party library, I have to deal with how end
users are going to get it.

Absolutely. However GUI libraries tend to stick out a bit more since
they tend to have a larger number of dependencies plus sheer code size
and complexity makes platform-specific bugs more likely.

I think the post I replied to covered the OS X case - there's an
application bundler available for it already.

Yes, I've used it to bundle wxPython apps on 10.3.

I want distributions that will work on all three major BSD variants
and most Linux distrubtions - in particular, anything that uses deb's,
rpm's or emerge. If you want to choose one in particular, try ubuntu
Linux.

OpenBSD: in portage
FreeBSD: in portage
386BSD: don't know... does anyone still use this?
NetBSD: included AFAICT
Fedora: rpms available
Debian: debs available
Ubuntu: included
Gentoo: in portage
OS/X: available on wxpython.org

FWIW, much of this info I found in less than 5 minutes using Google. I
suppose with a little persistence you could have discovered it for
yourself.

Here's your Ubuntu instructions:
http://wiki.wxpython.org/index.cgi/wxPython_20with_20Ubuntu

Of course, if you are distributing end-user software by requiring users
to install 3rd party packages themselves, then I hope you are
distributing open source software. If it's a commercial/closed-source
app you'll do far better by simply packaging all the requirements into
the installer and installing it within the application's directory tree
(this solves a lot of problems with version conflicts and user
confusion).

In my experience, binary packages work best for Windows and OS/X, and
source distributions work best for Linux (mostly because building
packages for Linux is a varied and sometimes painful process. Further
Linux truly works best as a source-based system: you cannot always
depend on ABI compatibility across versions of libraries - *usually* you
can but... caveat emptor).

Regards,
Cliff

 

[Cliff Wells]

I think you have me confused with someone else. I was responding to
someone who was claiming that the lack of a standard enterprise
strength GUI toolkit was a serious problem for Python - I disagree. I
won't recap the thread, but other languages have been *very*
successful without having a GUI as part of the language, all they had
was one development environment distributed with a GUI.

I think there's a lot of confusion in this thread.

BTW, in answer to your rhetorical question about GUI's for Linux, the
answer is plwm.

Technically, a toolkit for building a window manager, not a GUI. But
funny anyway

Cliff

 

[Cliff Wells]

Or maybe you could switch to Jython, and just use swing?

Man, c.l.py is getting *mean*

 

[Jorge Godoy]

Exactly what problem are you trying to solve? If it's the one about
not having a standard GUI, I don't think it's a problem.

Me neither. You pointed out that having a standard distribution made by
some company would solve the non-standard GUI problem. I believe we share
the same opinion, judging from this last post of yours. Maybe I missed
something on your message and read it as if you had a different opinion.

Works for me.

What works for you? You believe that chaos is better than having standards?
I believe that flexibility is good, but not chaos.

I think you have me confused with someone else. I was responding to
someone who was claiming that the lack of a standard enterprise
strength GUI toolkit was a serious problem for Python - I disagree. I

I dunno. Maybe I confused your words. I agree on disagreeing ;-)

won't recap the thread, but other languages have been *very*
successful without having a GUI as part of the language, all they had
was one development environment distributed with a GUI.

One IDE, you mean? I believe the freedom to choose from multiple IDEs is
also good. Some code on VI, others on Emacs, others on Eclipse, others
on ...

I agree that having multiple toolkits is good.

BTW, in answer to your rhetorical question about GUI's for Linux, the
answer is plwm.

And does it integrate well with common business apps, such as a mail client,
note taking apps, addressbooks (with personal and shared entries), calendar
with ability to share appointments, etc.?


Be seeing you,