File handle not being released by close

[Paul Rubin]

Re: Issues of state (was: Tkinter or wxpython?)

claird@lairds.u s (Cameron Laird) writes:

application in the web app model (I haven't even touched on the whole
stateless HTTP being mapped to a stateful environment issue, or the
need to manage the local web server) actually buys you anything. I

.
Go ahead: touch on statefulness. I've been pondering the topic
lately, and wonder what's new on the subject. I find it plenty
difficult to cast this as anything but a big liability for the
Web app team.

I'm not sure what you're getting at in this context. You can write a
desktop app where the window system communicates with a gui toolkit
through a socket (at least that's how X windows works), or you can
write a web app where a browser communicates with an http listener
through a socket. What's the difference, as far as application state
is concerned?

I haven't used wxpython but for tkinter you'd typically have a gui
event loop in its own thread, communicating with the application
through queues. Similarly you can use BaseHTTPServer to collect
browser hits and get the data out of them with the cgi module
functions before passing them to the app. If you want to handle
multiple concurrent users you get into the usual issues of web
servers, but if you're just doing a single user web implementation as
an alternative to a desktop gui, some rudimentary locking is probably
enough to stop accidental simultaneous connections.

If the application is simple enough, you can just write it as a cgi
and keep the state in disk files.

[Hendrik van Rooyen]

Re: Issues of state (was: Tkinter or wxpython?)

"Paul Rubin" <http:/...nvalidwrote:

claird@lairds.u s (Cameron Laird) writes:

>application in the web app model (I haven't even touched on the whole
>stateless HTTP being mapped to a stateful environment issue, or the
>need to manage the local web server) actually buys you anything. I

.
Go ahead: touch on statefulness. I've been pondering the topic
lately, and wonder what's new on the subject. I find it plenty
difficult to cast this as anything but a big liability for the
Web app team.

>
I'm not sure what you're getting at in this context. You can write a
desktop app where the window system communicates with a gui toolkit
through a socket (at least that's how X windows works), or you can
write a web app where a browser communicates with an http listener
through a socket. What's the difference, as far as application state
is concerned?
>
I haven't used wxpython but for tkinter you'd typically have a gui
event loop in its own thread, communicating with the application
through queues. Similarly you can use BaseHTTPServer to collect
browser hits and get the data out of them with the cgi module
functions before passing them to the app. If you want to handle
multiple concurrent users you get into the usual issues of web
servers, but if you're just doing a single user web implementation as
an alternative to a desktop gui, some rudimentary locking is probably
enough to stop accidental simultaneous connections.
>
If the application is simple enough, you can just write it as a cgi
and keep the state in disk files.

Something that is often overlooked is keeping some state in the buttons.
It involves changing the text, colour and the command binding, and
possibly setting up a callback using .after for time outs, if necessary.
You can do quite complicated sequences like this, if you have a mind to.

Its a bit of a PITA - but then all state machines are, no matter how you
implement them. Their chief advantage is that they force you to think
of all the possibilities.

- Hendrik

--
Enrol now in Heavy Henry's Wholesome Hackadamy,
for a course in single button GUI design.
The sacred crocodiles are for the moment leashed.

[greg]

Re: Issues of state

Paul Rubin wrote:

I'm not sure what you're getting at in this context. You can write a
desktop app where the window system communicates with a gui toolkit
through a socket (at least that's how X windows works)

An X server connection is *much* more stateful than
an HTTP one. It persists throughout the entire use
session of the application, for one thing, and there
is heaps of state being kept on both sides of the
connection. There's also a very high communication
bandwidth between them. There's really no comparison.

--
Greg

[Paul Rubin]

Re: Issues of state

greg <greg@cosc.cant erbury.ac.nzwri tes:

An X server connection is *much* more stateful than
an HTTP one. It persists throughout the entire use
session of the application, for one thing, and there
is heaps of state being kept on both sides of the
connection. There's also a very high communication
bandwidth between them. There's really no comparison.

The high bandwidth and persistence is not needed for an http
connection, which just gets a form submission once in a while. The
persistence and bandwidth is instead present in the X connection
between the window system and the browser.

[Kevin Walzer]

Re: Tkinter or wxpython?

Cameron Laird wrote:

>
While those with an artistic eye
assure me the simplest Tkinter programs look worse
that corresponding ones built with any other toolkit,
they behave the most coherently in regards to resizing
and so on.
>

"Look worse" can be addressed through extensive means: through theming
(via Tile, which can now be easily used in Tkinter; see
http://tkinter.unpy.net/wiki/TileWrapper); and through other aspects of
UI design, such as color, fonts, and even use of icons. A pyGtk or
wxPython application that uses old-school Gnome icons, for instance,
will look ugly. It's quite possible to make an attractive Tkinter
application using modern, stylish icons that even blends in reasonably
well on a specific platform (I've done it).

--
Kevin Walzer
Code by Kevin

http://www.codebykevin.com

[Chris Mellon]

Re: Tkinter or wxpython?

On 8/8/07, Kevin Walzer <kw@codebykevin .comwrote:

Cameron Laird wrote:

While those with an artistic eye
assure me the simplest Tkinter programs look worse
that corresponding ones built with any other toolkit,
they behave the most coherently in regards to resizing
and so on.

>
"Look worse" can be addressed through extensive means: through theming
(via Tile, which can now be easily used in Tkinter; see
http://tkinter.unpy.net/wiki/TileWrapper); and through other aspects of
UI design, such as color, fonts, and even use of icons. A pyGtk or
wxPython application that uses old-school Gnome icons, for instance,
will look ugly. It's quite possible to make an attractive Tkinter
application using modern, stylish icons that even blends in reasonably
well on a specific platform (I've done it).
>
--

Using Tile, of course, loses you the first major benefit of Tk - that
it's already included in the standard library. So in this sense it's
still "ugly old school look and feel" vs "no external dependencies",
which is the swing decision for many people. People who prefer the Tk
API, of course, will be happy to use Tile.

Also, while you can get (mostly) native *look*, the feel is absent.
Unless I'm very uninformed, Tile is a theming engine only, and doesn't
implement platform conventions with regard to behavior (the "feel"
part of look and feel).

[Kevin Walzer]

Re: Tkinter or wxpython?

Chris Mellon wrote:

On 8/8/07, Kevin Walzer <kw@codebykevin .comwrote:

Using Tile, of course, loses you the first major benefit of Tk - that
it's already included in the standard library. So in this sense it's
still "ugly old school look and feel" vs "no external dependencies",
which is the swing decision for many people. People who prefer the Tk
API, of course, will be happy to use Tile.

Tile has been implemented in the Tk core starting with version 8.5,
still somewhere between alpha and beta stage. Once 8.5 is out, and
Python is configured to build against Tk 8.5 (instead of 8.4), it should
Just Work.

>
Also, while you can get (mostly) native *look*, the feel is absent.
Unless I'm very uninformed, Tile is a theming engine only, and doesn't
implement platform conventions with regard to behavior (the "feel"
part of look and feel).

What do you mean here? Things like keyboard accelerators, menu
placement, and so on? Those things are already natively implemented by
Tk, and the developer just needs to invoke them. Sometimes some
conditional code is required for stuff like keyboard accelerators (the
"tk windowingsytem" command is useful for this), but again, it should
Just Work.

Or am I missing something?

--
Kevin Walzer
Code by Kevin

http://www.codebykevin.com

[Kevin Walzer]

Re: Tkinter or wxpython?

Chris Mellon wrote:

On 8/8/07, Kevin Walzer <kw@codebykevin .comwrote:

Using Tile, of course, loses you the first major benefit of Tk - that
it's already included in the standard library. So in this sense it's
still "ugly old school look and feel" vs "no external dependencies",
which is the swing decision for many people. People who prefer the Tk
API, of course, will be happy to use Tile.

Tile has been implemented in the Tk core starting with version 8.5,
still somewhere between alpha and beta stage. Once 8.5 is out, and
Python is configured to build against Tk 8.5 (instead of 8.4), it should
Just Work.

>
Also, while you can get (mostly) native *look*, the feel is absent.
Unless I'm very uninformed, Tile is a theming engine only, and doesn't
implement platform conventions with regard to behavior (the "feel"
part of look and feel).

What do you mean here? Things like keyboard accelerators, menu
placement, and so on? Those things are already natively implemented by
Tk, and the developer just needs to invoke them. Sometimes some
conditional code is required for stuff like keyboard accelerators (the
"tk windowingsytem" command is useful for this), but again, it should
Just Work.

Or am I missing something?

--
Kevin Walzer
Code by Kevin

http://www.codebykevin.com

[Chris Mellon]

Re: Tkinter or wxpython?

On 8/8/07, Kevin Walzer <kw@codebykevin .comwrote:

Chris Mellon wrote:

On 8/8/07, Kevin Walzer <kw@codebykevin .comwrote:

>

Using Tile, of course, loses you the first major benefit of Tk - that
it's already included in the standard library. So in this sense it's
still "ugly old school look and feel" vs "no external dependencies",
which is the swing decision for many people. People who prefer the Tk
API, of course, will be happy to use Tile.

>
Tile has been implemented in the Tk core starting with version 8.5,
still somewhere between alpha and beta stage. Once 8.5 is out, and
Python is configured to build against Tk 8.5 (instead of 8.4), it should
Just Work.

Also, while you can get (mostly) native *look*, the feel is absent.
Unless I'm very uninformed, Tile is a theming engine only, and doesn't
implement platform conventions with regard to behavior (the "feel"
part of look and feel).

>
What do you mean here? Things like keyboard accelerators, menu
placement, and so on? Those things are already natively implemented by
Tk, and the developer just needs to invoke them. Sometimes some
conditional code is required for stuff like keyboard accelerators (the
"tk windowingsytem" command is useful for this), but again, it should
Just Work.
>
Or am I missing something?
>

There's conventions for shortcuts and they vary by platform. For
example, home/end do different things on a mac vs on windows.
Scrollbars interact differently, and menu pulldowns operate
differently. To my knowledge, while Tile can replicate the *look* of
these things, it does not help with the interaction.

People often say "look and feel" when they actually just mean look.
It's something that I try to bring up when I hear "look and feel"
being applied to purely visual skinning tools.

Don't think I'm singling out Tk, Gtk has exactly the same problem -
you can make the buttons look native, but it doesn't adjust the
behavior.

[Kevin Walzer]

Re: Tkinter or wxpython?

Chris Mellon wrote:

>What do you mean here? Things like keyboard accelerators, menu
>placement, and so on? Those things are already natively implemented by
>Tk, and the developer just needs to invoke them. Sometimes some
>conditional code is required for stuff like keyboard accelerators (the
>"tk windowingsytem" command is useful for this), but again, it should
>Just Work.
>>
>Or am I missing something?
>>

>
There's conventions for shortcuts and they vary by platform. For
example, home/end do different things on a mac vs on windows.
Scrollbars interact differently, and menu pulldowns operate
differently. To my knowledge, while Tile can replicate the *look* of
these things, it does not help with the interaction.

On Windows and Mac, Tk gets the menus correct by default (menu is at the
top of the screen on the Mac, attached to a window on Windows). The Tk
scrollbar is native on the Mac; the Tile scrollbar has problems. On
Windows, the Tile scrollbar maps to Vista or XP or Win32, depending on
Windows version. You need to correctly specify the command-accelerator
in your code (on Windows it's the Control key, on the Mac it's Command),
but assuming you do this, it works fine. I don't use "home" and "end"
keys myself (I think these are more common on Windows than Mac) so I
can't speak to that. Under Tk, keyboard navigation with the tab key
generally works as expected on the Mac, and I assume so for Windows as
well.

The biggest drawback with Tk/Tile on the Mac is that even with Tile
theming, it's still a bit outdated--Tile hooks into some older API's on
the Mac that are more compatible with Tk; for instance, the notebook
tabs look like Jaguar-era tabs (c. 2002). The Tile scrollbar is broken,
but the Tk one works natively.

Tile on Windows looks pretty darn good--I've played with the Windows
Inspection Tool Kit, a well-designed Tcl/Tk application on Windows XP
that uses Tile, and it's indistinguishab le from something developed in
VB or Delphi. (See http://magicsplat.com/wits/screenshot.html). Tile on
the Mac requires a bit more hackery, but it's quite possible to get
something looking nearly native (see
http://www.codebykevin.com/portauthority.html).

As for X, Tk and Tile are more of a mixed bag, because there is simply
no single standard to target. Standard Tk looks and feels like Motif, as
you know. Some of the Tile themes under X don't look much better. The
most popular Tile theme on X is probably Clam, which looks more like a
modern Gtk Clearlooks-style theme (see
http://tktable.sourceforge.net/tile/...-clam-unix.png or
http://www.codebykevin.com/pylocate-tile-x11.png). As far as I know,
Tk/Tile offers reasonable defaults for X, unless you are looking for
specfic integration with a particular environment (i.e. Gnome or KDE);
in that case it's not as acceptable.

>
Don't think I'm singling out Tk, Gtk has exactly the same problem -
you can make the buttons look native, but it doesn't adjust the
behavior.

Tk does a better job with platform-specific defaults and behaviors than
Gtk. When I read complaints about Tk on Windows, it's more on how ugly
Tk is, not that its menus/keyboard behaviors don't work correctly.

--
Kevin Walzer
Code by Kevin

http://www.codebykevin.com

[Cameron Laird]

Re: Issues of state (was: Tkinter or wxpython?)

In article <7x8x8mpn37.fsf @ruckus.brouhah a.com>,
Paul Rubin <http://phr.cx@NOSPAM.i nvalidwrote:

[greg]

Re: Issues of state

Paul Rubin wrote:

The high bandwidth and persistence is not needed for an http
connection, which just gets a form submission once in a while.

Bandwidth isn't really the main issue. The point is
that a lot of state is kept on both ends, making it
much easier to implement a rich user interface.

In fact, the more state is kept, the *less* bandwidth
you need, because communication can make use of shared
context to compress the messages.

--
Greg

[greg]

Re: Issues of state

Jay Loden wrote:

Like most things involving dynamic client side-javascript code and AJAX
technology, it's a lot harder than you'd like it to be to solve the problem, but
in cases where the Back button is really an issue, it's worth the effort.

So if you're willing to put in a huge amount of time,
effort and ingenuity, it's possible to overcome a
problem that only existed in the first place because
you chose an inappropriate technique for implementing
a user interface...

--
Greg

[Steve Holden]

Re: Issues of state

greg wrote:

Jay Loden wrote:

>Like most things involving dynamic client side-javascript code and AJAX
>technology, it's a lot harder than you'd like it to be to solve the problem, but
>in cases where the Back button is really an issue, it's worth the effort.

>
So if you're willing to put in a huge amount of time,
effort and ingenuity, it's possible to overcome a
problem that only existed in the first place because
you chose an inappropriate technique for implementing
a user interface...
>

Exactly my point. Once you start to involve a complex framework to
handle state and interactions you see less and less advantage to
"desktop web" applications, since it's hard to match the directness and
simplicity of a native GUI.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------

[Jay Loden]

Re: Issues of state

Steve Holden wrote:

greg wrote:

>Jay Loden wrote:

>>Like most things involving dynamic client side-javascript code and AJAX
>>technology, it's a lot harder than you'd like it to be to solve the problem, but
>>in cases where the Back button is really an issue, it's worth the effort.

>So if you're willing to put in a huge amount of time,
>effort and ingenuity, it's possible to overcome a
>problem that only existed in the first place because
>you chose an inappropriate technique for implementing
>a user interface...
>>

Exactly my point. Once you start to involve a complex framework to
handle state and interactions you see less and less advantage to
"desktop web" applications, since it's hard to match the directness and
simplicity of a native GUI.

This is true, you certainly won't get an argument from me! I've spent a lot of
time explaining to people why a real-time GUI and the HTTP protocol don't get
along. Event-driven programming using a request/response framework == square
peg, round hole. But, it seems like the benefits of a web-based GUI make for a
big hammer, so people keep pounding away at that square peg ;)

On the negative side, developing any sort of non-trivial web application is
fraught with problems:

* language limitations of javascript/(X)HTML
* highly varied implementations of CSS, HTML, js
* browser-specific bugs (and features)
* no real IDE to speak of
* no way to receive events without some very ugly hacks or polling

However, there are also major benefits, which is why you see so many companies
and individuals jumping on the Web 2.0 train:

* lower barrier of entry to creating a GUI (compare how quickly
most people can turn out a form in HTML versus creating a GUI
with the same entry fields)
* cross-platform (yes, you have to support multiple browsers,
but once you do, it works on the majority of platforms. For
instance, support Firefox means OS X, Linux, Windows, etc all
supported at once
* Convenience for the end user - no need to install anything to
use your software, which entices a lot more people to use it.
This is less of a valid concern in an enterprise environment, but
it still attracts people to feel they don't need to install
something locally
* available from multiple machines without extra effort for the user
* Familiar interface (in most cases at least) to the user; more
comfortable for them, less they need to learn.
* Potentially available on many new platforms such as the iPhone,
with some presentation tweaks. Good luck writing a cross-platform
GUI app that runs on all the major OSes and mobile devices using a
standard GUI toolkit etc. (or shipping the Python interpreter with
an app intended for a Windows Mobile device, for instance)

Your point is absolutely valid, though. I think the web 2.0 craze has people
doing some things that just don't really make sense (like implementing Photoshop
in a browser - what's next, AutoCAD?). The bottom line is that there are many
many things that a native GUI is much better at and more than likely always will
be. If you're developing an application, it's important to stop and ask yourself
why it needs to be a web-based application, and unless you've got compelling
reasons, the native GUI should win out.

-Jay