File handle not being released by close

[Kevin Walzer]

On 8/8/07, Kevin Walzer <[email protected]> wrote:

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?

 

[Chris Mellon]

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.

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]

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 indistinguishable 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/screenshots/demo-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.

 

[Chris Mellon]

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).

I was actually referring to click-and-hold vs just click. If Tk wraps
the native menu on OS X (it doesn't on Windows) then that'll be taken
care of though. I don't think you can emulate menus on OS X the way
you can on Windows, though, so if they're where they're supposed to be
they're probably native ones.

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),

That's an interesting gap, since Tk gets other more subtle stuff right.

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.

Just examples. Text navigation has different conventions on a Mac vs
Windows (or Gtk/KDE). I wouldn't expect Tk to get it right unless it
wrapped the native control (which would give all kinds if neat
benefits like spellcheck, too). Of course, if that's what it decides
to do it will eventually end up being wxPython

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 indistinguishable 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/screenshots/demo-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.

The situation under *nix is more complex, where you may or may not
have a DE with its own preferred toolkit. I use Gnome, so I expect
(and require) my apps to either use Gtk or fake it well enough that I
can't tell the difference, but I don't judge the strength of a cross
platform toolkit on that.

There are some cases where you just can't do everything in the
toolkit. One of the things that I really like about wxPython from a
cross platform perspective is how easily it lets you tell it to "do
the right thing for this platform". Stock buttons let you have the
right icons under Gtk, but the descriptive labels that OS X expects.
There's a stock button sizer that gets the layout and order of
ok/cancel correct. If you use the stock IDs for your menus, wxPython
will put the about and preferences menus items in the right spot and
give you the correct preferences accelerator on OS X. Stuff like that.

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.

Gtk is pretty bad, using it's own dialogs and even it's own painting
model. Tk has some definite lacks, though. I find the menus especially
obnoxious. I'm unusually picky about native integration though.

 

[Cameron Laird]

.
.
.

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.

Others have answered this at other levels. In elementary terms,
there truly is a difference, Paul, and one that's widely reified:
a "desktop client-server" application typically listens through
one socket, which therefore constitutes an index of the connection
or client, while a Web application communicates through a sequence
of independent HTTP transactions. The latter can manage state only
to the extent it passes session information around.

As you correctly point out, there certainly are plenty of Web appli-
cations which cheerfully *do* pass session information. As common
as it is, though--and I'm *still* writing CGI on occasion, a decade
after I was convinced it was a dead technique--it's not automatic.
HTTP is a stateless protocol, and therefore state management must
remain an issue.

 

[greg]

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.

 

[Paul Rubin]

Others have answered this at other levels. In elementary terms,
there truly is a difference, Paul, and one that's widely reified:
a "desktop client-server" application typically listens through
one socket, which therefore constitutes an index of the connection
or client, while a Web application communicates through a sequence
of independent HTTP transactions. The latter can manage state only
to the extent it passes session information around.

Is this significant? In the case of a single user http app running on
the same computer as the browser, the server should only listen on
127.0.0.1. Every http hit then almost certainly comes from the same
session. If there's doubt, the app can always set a random cookie at
the initial screen and check that the cookie never changes.

If there's only a small amount of session state (say up to a few
hundred bytes) you can put it entirely into browser cookies and send
it on every single http hit.

 

[Cameron Laird]

Is this significant? In the case of a single user http app running on
the same computer as the browser, the server should only listen on
127.0.0.1. Every http hit then almost certainly comes from the same
session. If there's doubt, the app can always set a random cookie at
the initial screen and check that the cookie never changes.

If there's only a small amount of session state (say up to a few
hundred bytes) you can put it entirely into browser cookies and send
it on every single http hit.

I'm not sure what we're discussing. Yes, I agree those are
mechanisms by which Web applications manage state. Apparently
we agree that, in a general Web application, state management,
or related persistence, requires *some* mechanism or assumption.

 

[Steve Holden]

I'm not sure what we're discussing. Yes, I agree those are
mechanisms by which Web applications manage state. Apparently
we agree that, in a general Web application, state management,
or related persistence, requires *some* mechanism or assumption.

As far as I'm concerned the major issue with trying to have "desktop web
apps" compete with true windowed applications is the difficulty of
maintaining sensible interactions with the interface. AJAX designs have
increased the interaction level at the expense of greater complexity -
there is more state to be transferred, and a much higher interaction
rate with the server. But the browser is a terrible front-end for AJAX
designs because it doesn't record the state changes that take place as a
result of requests for updated InnerHTML content, so if the user is
unwise enough to press the "back" button she loses all traces of the
non-page interactions that have taken place since the page was loaded.

So "desktop web apps" should ensure that they get displayed in browser
windows with minimal user interface decoration. But even then there's
always that chance that sophisticated users will use keyboard shortcuts
like ALT-left-arrow.

That, in summary, is why my 2004 PyCon paper[1] was subtitled "The Back
Button is Not Your Friend".

regards
Steve

[1]: http://www.python.org/pycon/dc2004/papers/18/Setting_A_Context.pdf
--
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]

As far as I'm concerned the major issue with trying to have "desktop web
apps" compete with true windowed applications is the difficulty of
maintaining sensible interactions with the interface. AJAX designs have
increased the interaction level at the expense of greater complexity -
there is more state to be transferred, and a much higher interaction
rate with the server. But the browser is a terrible front-end for AJAX
designs because it doesn't record the state changes that take place as a
result of requests for updated InnerHTML content, so if the user is
unwise enough to press the "back" button she loses all traces of the
non-page interactions that have taken place since the page was loaded.

So "desktop web apps" should ensure that they get displayed in browser
windows with minimal user interface decoration. But even then there's
always that chance that sophisticated users will use keyboard shortcuts
like ALT-left-arrow.

That, in summary, is why my 2004 PyCon paper[1] was subtitled "The Back
Button is Not Your Friend".

regards
Steve

[1]: http://www.python.org/pycon/dc2004/papers/18/Setting_A_Context.pdf

There's been some interesting work done in that area as well:

http://dev2dev.bea.com/pub/a/2006/01/ajax-back-button.html
http://www.isolani.co.uk/blog/javascript/FixingTheBackButtonThatAjaxBroke

In particular, the RSH (Really Simple History) Framework is an open source
solution to the problem:

http://www.onjava.com/pub/a/onjava/2005/10/26/ajax-handling-bookmarks-and-back-button.html

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.

-Jay

 

[greg]

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...

 

[Steve Holden]

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]

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