Re: File handle not being released by close
Richard Brodie
<bg...@yahoo.com> wrote in message
news:1185806160....@d55g2000hsg.googlegroups.com...
> I'm guessing the garbage collector is causing the file to be written,
> but shouldn't close do this?
Only if you call it ;)
Eric Brunel
> Hi,
>
> I'm in the process of writing some code and noticed a strange problem
> while doing so. I'm working with PythonWin 210 built for Python 2.5. I
> noticed the problem for the last py file processed by this script,
> where the concerned tmp file is only actually written to when
> PythonWin is closed. In other words, after I run this script, one of
> the generated tmp files has a size of 0kB. I then close PythonWin and
> it is then written to.
>
> I'm guessing the garbage collector is causing the file to be written,
> but shouldn't close do this?
>
> /Barry
>
> import os, time, string
>
> dir = 'c:\\temp1'
>
> def listAllFile(fileNames,dir,files):
> def f1(a,dir=dir): return os.path.join(dir,a)
> files2 = map(f1, files)
> fileNames.extend(files2)
>
> fileNames = []
> os.path.walk(dir,listAllFile,fileNames)
>
> for fileName in fileNames:
> fileBeginning = os.path.splitext(fileName)[0]
> fileEnd = os.path.splitext(fileName)[1]
>
> if fileEnd == ".py":
> print fileName
> f=open(fileBeginning+".tmp", 'w')
> f.write("Hello")
> f.close
f.close()
HTH...
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
Peter Otten
> I'm in the process of writing some code and noticed a strange problem
> while doing so. I'm working with PythonWin 210 built for Python 2.5. I
> noticed the problem for the last py file processed by this script,
> where the concerned tmp file is only actually written to when
> PythonWin is closed. In other words, after I run this script, one of
> the generated tmp files has a size of 0kB. I then close PythonWin and
> it is then written to.
>
> I'm guessing the garbage collector is causing the file to be written,
> but shouldn't close do this?
Yes.
> f=open(fileBeginning+".tmp", 'w')
> f.write("Hello")
> f.close
In Python () is nessary to call a parameterless function or method:
>>> def f(): print "Hi Barry"
...
>>> f
<function f at 0xb7cf2374>
>>> f()
Hi Barry
This allows it to treat functions as variables consistently:
>>> def f(write):
... write("Hello")
...
>>> def write_upper(s): print s.upper()
...
>>> import sys
>>> write_to_stdout = sys.stdout.write
>>>
>>> f(write_upper)
HELLO
>>> f(write_to_stdout)
Hello>>>
Peter
Jean-Paul Calderone
>Hi,
>
> [snip]
> f=open(fileBeginning+".tmp", 'w')
> f.write("Hello")
> f.close
>
You forgot to call close. Try this final line, instead:
f.close()
Jean-Paul
Gary Duzan
<bg...@yahoo.com> wrote:
>
> [ ... ]
>
>for fileName in fileNames:
> fileBeginning = os.path.splitext(fileName)[0]
> fileEnd = os.path.splitext(fileName)[1]
>
> if fileEnd == ".py":
> print fileName
> f.write("Hello")
> f.close
Gary Duzan
Motorola CHS
wang frank
Hi,
I want to build a GUI to execut python script. I found TKinter and
wxpython. Which one is easier for a newbie? and which one is better?
Thanks
Frank
_________________________________________________________________
豪華！大リーグ観戦ツアーや高級外車が当たるスペシャルキャンペーンをお見逃しな
く http://clk.atdmt.com/GBL/go/msnjpqjl0060000010gbl/direct/01/
Glenn Hutchings
> I want to build a GUI to execut python script. I found TKinter and
> wxpython. Which one is easier for a newbie? and which one is better?
Well, Tkinter comes with Python, so newbies can get up and running
straight away without having to download and install anything else.
And there are probably lots more examples out there that a newbie can
look at and learn from. As for *better*, wxPython has a lot more
kinds of widgets in it, which will make writing GUIs less tedious in
the long run, and the widgets look a lot nicer too.
Glenn
Jerry McBride
>
> Hi,
>
> I want to build a GUI to execut python script. I found TKinter and
> wxpython. Which one is easier for a newbie? and which one is better?
>
Tkiner is much easier to work with, but doesn't have the fine controls that
wx offers...
--
Jerry McBride
kyos...@gmail.com
> Hi,
>
> I want to build a GUI to execut python script. I found TKinter and
> wxpython. Which one is easier for a newbie? and which one is better?
>
> Thanks
>
> Frank
>
> _________________________________________________________________
>
I've read that Tkinter doesn't scale well if you're writing complex
GUIs. I haven't been able to test this hypothesis though. However,
since I had to rewrite VBA apps into Python, to get the right "look
and feel" I needed the widgets that wxPython provided. Since I started
out with C++, I find wxPython better than Tkinter, but it's all pretty
subjective. Try them both!
Mike
Paul Rubin
> I've read that Tkinter doesn't scale well if you're writing complex
> GUIs. I haven't been able to test this hypothesis though. However,
> since I had to rewrite VBA apps into Python, to get the right "look
> and feel" I needed the widgets that wxPython provided. Since I started
> out with C++, I find wxPython better than Tkinter, but it's all pretty
> subjective. Try them both!
Tkinteger (dang, I always end up typing it that way, I won't even
bother fixing the error) is easy to use for simple gui's, and it's
part of the standard python distro which for me is a big advantage (no
extra crap to download). However, the widget set is rather ugly and
doesn't blend in well with anyone's native widgets; the widget
selection itself is rather narrow, and I think kyosohma may be right
that it doesn't scale well to complex gui's. I've looked at the code
for IDLE's gui and it's terrifying.
At this point I think nobody should write desktop gui apps without a
good reason. There is a fairly flexible and easy to program gui
already running on almost every desktop, namely the web browser.
Before you write a gui using some client side toolkit, ask yourself
whether you can instead embed a web server in your application and
write an HTML gui. That approach is not always the answer, but it has
considerable advantages when you can do it that way.
kyos...@gmail.com
I agree that making web apps is probably the way of the future.
However, there are lots of security risks involved with it that need
to be understood. One of the problems that raging is about AJAX, see
here: http://arstechnica.com/news.ars/post/20070802-security-experts-warn-developers-about-the-risks-of-premature-ajax-ulation.html
Desktop apps have security issues too, of course.
Mike
Chris Mellon
Some disadvantages of the web based platform:
No native look and feel - constrained by the browser.
No control over browser UI idioms. I had to write this post twice
because the text control lost focus and I hit backspace, going back in
the history and losing my work.
No native integration - no "open file", no "browse the filesystem", no
rich drag and drop, no copy/paste.
No or poor dialogs. Poor multiple window support.
More platforms to develop on and test with.
Limited to CSS box model for layout.
You can mitigate some of these constraints if you *require* the local
web browser technique, rather than supporting local or remote access.
You can mitigate more if you write your own browser host (along the
lines of the dashboard in OS X), but then you get to write 3
applications instead of one.
The web is a terrible application platform. There is not a single web
application in existence which has even half the UI functionality of a
rich client application. There are some (even many) applications for
which the benefit of global access and easy deployment makes up for
the lack in functionality, but statements like "At this point I think
nobody should write desktop gui apps without a good reason" are simply
ludicrously misguided.
Paul Rubin
> I agree that making web apps is probably the way of the future.
> However, there are lots of security risks involved with it that need
> to be understood. One of the problems that raging is about AJAX, see
> here: http://arstechnica.com/news.ars/post/20070802-security-experts-warn-developers-about-the-risks-of-premature-ajax-ulation.html
Yes, do be careful of ajax, and of internet programming in general.
However, the usual use of a desktop app is deployment within one
company, so if you write it as a web app you can ease the security
issue by firewalling the server so that it can't be accessed through
the outside internet. That still makes deployment a lot easier, since
there are zero desktop installations required, and you can upgrade the
software whenever you want at the server side.
Paul Rubin
> No native look and feel - constrained by the browser.
Might or might not matter for the application, especially considering
that tkinter is part of the discussion.
> No control over browser UI idioms. I had to write this post twice
> because the text control lost focus and I hit backspace, going back in
> the history and losing my work.
Sounds weird, I'm used to having stuff in text boxes stay in the
browser, and why did backspace have that effect anyway?
> No native integration - no "open file", no "browse the filesystem", no
> rich drag and drop, no copy/paste.
File i/o and file system browsing are available from javascript if the
user grants permission. File system browsing for the limited purpose
of file upload is available in regular html. Copy/paste of ordinary
text is always available. However, this type of requirement is what I
mean by a "good reason" to write a desktop gui. It applies to some
applications, not all.
> No or poor dialogs. Poor multiple window support.
Might or might not matter depending on the application. Most dialogs
can be done with html. Multiple windows are evil most of the time,
and should instead by done with multiple panes or cells in a single
window.
> More platforms to develop on and test with.
Compared to a desktop app? I don't think so.
> Limited to CSS box model for layout.
Might or might not matter depending on the application. If you're
doing a consumer app that has to look slick, you have no choice but to
use something like wxwidgets (tkinter won't cut it either). If you're
doing a special purpose office or industrial app, slickness isn't
important.
> The web is a terrible application platform. There is not a single web
> application in existence which has even half the UI functionality of a
> rich client application.
Some of us consider simple interfaces with consistent, familiar
(i.e. web) elements to be a good thing. Fancy client interfaces are
ok if you feel you need to make a style statement, but are often
unnecessary if you just want to get something done.
> There are some (even many) applications for which the benefit of
> global access and easy deployment makes up for the lack in
> functionality, but statements like "At this point I think nobody
> should write desktop gui apps without a good reason" are simply
> ludicrously misguided.
Well, I don't say that good reasons don't exist, I just see a lot of
desktop apps that could be done just as well as web apps, i.e. for
those, the good reason didn't exist.
kyos...@gmail.com
> On 06 Aug 2007 07:39:12 -0700, Paul Rubin
>
>
>
> <"http://phr.cx"@nospam.invalid> wrote:
If you could use Python's antiquated Grail web browser and write
plugin applications, then that would be awesome! There are trade offs
with anything though.
Mike
Kevin Walzer
>
> Tkinteger (dang, I always end up typing it that way, I won't even
> bother fixing the error) is easy to use for simple gui's, and it's
> part of the standard python distro which for me is a big advantage (no
> extra crap to download). However, the widget set is rather ugly and
> doesn't blend in well with anyone's native widgets; the widget
> selection itself is rather narrow, and I think kyosohma may be right
> that it doesn't scale well to complex gui's. I've looked at the code
> for IDLE's gui and it's terrifying.
It's entirely possible to make sophisticated GUI's in Tkinter, but you
are right, most people don't. Part of the issue is that Tkinter
developers haven't kept up with what's going on in Tk and instead use
outdated, ugly widget sets like Tix, PMW, and so on. Making use of the
available wrappers for current Tk libraries such as BWidgets, Tile,
Tablelist, TkTreeCtrl, and so on allows you to make UI's every bit as
polished as what comes with wxPython: tree views, multi-column lists,
notebook tabs, comboboxes, etc., with platform-specific theming
(XP/Vista, Aqua/OS X, and X11).
For more references, see:
http://tkinter.unpythonic.net/wiki/TileWrapper
http://tkinter.unpythonic.net/wiki/TableListWrapper
http://tkinter.unpythonic.net/wiki/TableListTileWrapper
http://tkinter.unpythonic.net/wiki/PyLocate
http://tkinter.unpythonic.net/wiki/PyLocateTile
http://tkinter.unpy.net/bwidget/
http://tkinter.unpy.net/wiki/NoteBook
http://klappnase.zexxo.net/TkinterTreectrl/index.html
>
> At this point I think nobody should write desktop gui apps without a
> good reason. There is a fairly flexible and easy to program gui
> already running on almost every desktop, namely the web browser.
> Before you write a gui using some client side toolkit, ask yourself
> whether you can instead embed a web server in your application and
> write an HTML gui. That approach is not always the answer, but it has
> considerable advantages when you can do it that way.
Given a choice between a rich desktop client and a web app, I'd choose
the desktop client in most cases. It's just much more pleasant to work
with .
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Chris Mellon
<"http://phr.cx"@nospam.invalid> wrote:
> "Chris Mellon" <ark...@gmail.com> writes:
> > No native look and feel - constrained by the browser.
>
> Might or might not matter for the application, especially considering
> that tkinter is part of the discussion.
>
The point is that you have no option with the browser - even Tkinter
has platform theming support now.
> > No control over browser UI idioms. I had to write this post twice
> > because the text control lost focus and I hit backspace, going back in
> > the history and losing my work.
>
> Sounds weird, I'm used to having stuff in text boxes stay in the
> browser, and why did backspace have that effect anyway?
>
On Windows, backspace is a browser global hotkey that means "go back
once in the history". When the text box lost focus, hitting backspace
navigated back. Gmail uses ajax instead of a page load when you start
typing a reply, and the fragile tricks it uses to try to keep the
browser history and the ajax state in sync don't work in this case.
It's a specific example of the general problems of the browser as
application platform.
> > No native integration - no "open file", no "browse the filesystem", no
> > rich drag and drop, no copy/paste.
>
> File i/o and file system browsing are available from javascript if the
> user grants permission.
Which they won't (I don't even know how, from Firefox), so you can't
rely on it working. You can mitigate with your own browser host, or if
you write all your own file browsing in HTML and move it into your
local browser. Poor solutions all around.
> File system browsing for the limited purpose
> of file upload is available in regular html.
>Copy/paste of ordinary
> text is always available.
But not of anything else. I've often wanted to drag & drop a file onto
the file upload box in gmail, for example.
>However, this type of requirement is what I
> mean by a "good reason" to write a desktop gui. It applies to some
> applications, not all.
>
How about something as simple as context menus? You can't reliably
override the browser context menu from a web page unless, again, you
provide your own browser host. This is a good thing, because a browser
needs to be wary of arbitrary malicious web pages. They aren't good
application hosts.
Keyboard shortcuts that happen to conflict with whatever the browser
or any of its plugins happen to use, too. Although I notice that
Firefox now allows web pages to override that, which is a little sad.
> > No or poor dialogs. Poor multiple window support.
>
> Might or might not matter depending on the application. Most dialogs
> can be done with html. Multiple windows are evil most of the time,
> and should instead by done with multiple panes or cells in a single
> window.
>
Multiple windows are the common case on the mac. They're not rare on
other platforms as well. The fact that your windows are constrained to
the browser and can't be torn off is a large limitation. No toolbars,
no palettes, no modal dialogs (except on IE, or if you constrain them
to the browser). Lots of unnecessary chrome on your extra windows, too
(see below).
> > More platforms to develop on and test with.
>
> Compared to a desktop app? I don't think so.
>
Did you ever try counting? X browsers * Y browser versions * Z
platforms. There are javascript and CSS bugs and differences between
all of these. From my own professional experience, it's not any easier
to account for browser differences than it is for platform
differences. It's getting better as more people jump on the web
bandwagon and CSS and JS abstraction libraries show up, but it's not
even good as the available platform abstraction libraries like
wxWidgets or Qt.
> > Limited to CSS box model for layout.
>
> Might or might not matter depending on the application. If you're
> doing a consumer app that has to look slick, you have no choice but to
> use something like wxwidgets (tkinter won't cut it either). If you're
> doing a special purpose office or industrial app, slickness isn't
> important.
>
I'm not talking about chrome and slickness. I'm talking about basic
usability concerns like "will this work with a higher font size" and
"will it reflow in a sensible way if I change the window size". The
CSS box model works okay for text, it's not so good for widgets. More
than a few web apps end up writing their own layout engines in dynamic
javascript. This is sad. While I'm talking about chrome, add "wasted
screenspace due to browser chrome" to a limitation of web apps, again
unless you write your own browser host. This is another example of a
feature that makes a good browser (don't let arbitrary web pages mess
with my web browser functionality) clashing with the desires of a good
application (don't waste screen space with irrelevant functionality).
> > The web is a terrible application platform. There is not a single web
> > application in existence which has even half the UI functionality of a
> > rich client application.
>
> Some of us consider simple interfaces with consistent, familiar
> (i.e. web) elements to be a good thing. Fancy client interfaces are
> ok if you feel you need to make a style statement, but are often
> unnecessary if you just want to get something done.
>
Man, you should be in PR with the way you spin things. You can't
implement anything except the most trivial of applications using only
the simple, familiar web elements like HTML forms. Anything more
complicated than that needs to be done with DHTML and probably AJAX,
and those UI elements don't look anything like the familiar ones. You
go in one breath from saying that you can implement dialogs in HTML to
saying that the rich client is the *less* familiar of the interfaces?
> > There are some (even many) applications for which the benefit of
> > global access and easy deployment makes up for the lack in
> > functionality, but statements like "At this point I think nobody
> > should write desktop gui apps without a good reason" are simply
> > ludicrously misguided.
>
> Well, I don't say that good reasons don't exist, I just see a lot of
> desktop apps that could be done just as well as web apps, i.e. for
> those, the good reason didn't exist.
> --
If you'd said "if you're making something really simple that has
limited rich UI or data entry needs, consider a web application
instead" I wouldn't have posted. A web application is something you
make because the deployment and access benefits outweigh the UI and
integration limitations, not as your default "go to" whenever you
create an application.
I'd like an example you have of a desktop application that could have
just as easily been a web application. Bonus points if it's not a CRUD
screen, and double bonus if you don't just handwave away things like
file browsing. Although there are benefits even for the crud screen -
I've written screens and applications for data entry professionals and
they almost always prefer the speed optimizations you can make in a
client application.
Paul Rubin
> > No native integration - no "open file", no "browse the filesystem", no
> > rich drag and drop, no copy/paste.
>
> File i/o and file system browsing are available from javascript if the
> user grants permission. File system browsing for the limited purpose
> of file upload is available in regular html. Copy/paste of ordinary
> text is always available. However, this type of requirement is what I
> mean by a "good reason" to write a desktop gui. It applies to some
> applications, not all.
I should also add: there is also the possibility of running a Python
program with an embedded http server on the same desktop as the
browser, using the browser purely as a gui, but with the Python
program having complete access to the file system and so forth. This
could be seen as combining the disadvantages of both the remote web
server approach (i.e. gui elements constrained by the browser) and the
all-desktop approach (deployment issues). However, a lot of the time
it's still just plain easier to do. Whenever I've written a desktop
gui app I've always just been shocked at how much time goes into
making the gui look decent and do the right stuff, even though none of
mine have been even slightly slick (they've all been for industrial
applications). When I do a web gui, it's been just a matter of
tossing some html into a file or into some print statements, viewing
it in a browser, and tweaking it a little as needed. Maybe that's
mostly a matter of the lousy state of gui toolkits, and we actually
need a toolkit that's more like an embedded browser. But we don't
have that at the moment.
Paul Rubin
> > Might or might not matter for the application, especially considering
> > that tkinter is part of the discussion.
> The point is that you have no option with the browser - even Tkinter
> has platform theming support now.
Hmm, I don't know anything about that. I'm taking the view that for a
lot of apps, the requirement is to just put some functionality on the
screen, with slick visual appearance having little value or even
negative value.
> ...Gmail uses ajax instead of a page load when you start
> typing a reply,
I see, the answer to what caused your problem is approximately "ajax
is evil", or alternatively, the gmail app attempts slickness with a
tool that doesn't support slickness that well. OK, I can accept that
using browsers for slick interfaces has its problems, but the answer
(a lot of the time, not always) is to just decide you don't need
slickness.
> > File i/o and file system browsing are available from javascript if the
> > user grants permission.
> Which they won't (I don't even know how, from Firefox), so you can't
> rely on it working.
The application javascript pops a dialog asking for permission and the
user clicks yes or no. If you can get them to install a desktop app
(gah!!) then you can certainly get them to click yes in a browser.
The permission mechanism is admittedly browser dependent.
> But not of anything else. I've often wanted to drag & drop a file onto
> the file upload box in gmail, for example.
Well, ok, that's a slick feature that your app might need. None of
mine have needed it so far.
> How about something as simple as context menus?
Unnecessary slickness for many apps. I've never needed it.
> > Multiple windows are evil most of the time,
> Multiple windows are the common case on the mac. They're not rare on
> other platforms as well. The fact that your windows are constrained to
> the browser and can't be torn off is a large limitation. No toolbars,
> no palettes, no modal dialogs (except on IE, or if you constrain them
> to the browser). Lots of unnecessary chrome on your extra windows, too
> (see below).
You can get rid of the chrome with javascript, but the extra windows
are still usually evil and unnecessary. Just because they get used a
lot doesn't change that. A heck of a lot of deployed interfaces, web
or desktop, simply suck.
> > > More platforms to develop on and test with.
> > Compared to a desktop app? I don't think so.
> Did you ever try counting? X browsers * Y browser versions * Z
> platforms. There are javascript and CSS bugs and differences between
> all of these.
If you can tell them to install a desktop app, you can alternatively
tell them what browser to use. For example we use a complicated
firefox-only browser app where I work, that relies heavily on canvas
objects. But if you write your application with straightforward html
you tend to have very few platform problems.
> From my own professional experience, it's not any easier
> to account for browser differences than it is for platform
> differences. It's getting better as more people jump on the web
> bandwagon and CSS and JS abstraction libraries show up,
I guess I see that stuff as mostly-evil and prefer straightforward
html.
> I'm not talking about chrome and slickness. I'm talking about basic
> usability concerns like "will this work with a higher font size" and
> "will it reflow in a sensible way if I change the window size". The
> CSS box model works okay for text, it's not so good for widgets.
I just haven't had this problem with HTML interfaces. I've never even
used CSS, though that makes me a bit of a lamer. An interface that
needs to fill the whole screen with widgets is probably too
complicated.
> More than a few web apps end up writing their own layout engines in
> dynamic javascript. This is sad. While I'm talking about chrome, add
> "wasted screenspace due to browser chrome" to a limitation of web
> apps, again unless you write your own browser host. This is another
> example of a feature that makes a good browser (don't let arbitrary
> web pages mess with my web browser functionality) clashing with the
> desires of a good application (don't waste screen space with
> irrelevant functionality).
I guess the term I'd use to describe all these effects is "slick" and
a heck of a lot of the time it's just not needed. Anyway you can pop
a chromeless browser window with a simple javascript call.
> Man, you should be in PR with the way you spin things. You can't
> implement anything except the most trivial of applications using only
> the simple, familiar web elements like HTML forms. Anything more
> complicated than that needs to be done with DHTML and probably AJAX,
> and those UI elements don't look anything like the familiar ones. You
> go in one breath from saying that you can implement dialogs in HTML to
> saying that the rich client is the *less* familiar of the interfaces?
I don't see the contradiction--with HTML you have just a few widgets
that everyone understands and you get an interface that's almost
always self-explanatory. Yes you could call those interfaces trivial,
but the little secret that I'm trying to convey is that very often,
trivial is all that's needed.
> If you'd said "if you're making something really simple that has
> limited rich UI or data entry needs, consider a web application
> instead" I wouldn't have posted. A web application is something you
> make because the deployment and access benefits outweigh the UI and
> integration limitations, not as your default "go to" whenever you
> create an application.
Well, I could back off to somewhere between the two. Like, "ask
yourself whether your application really needs a rich gui or complex
data entry features. If you can get by with a simple HTML interface,
and a lot of the time you can, you'll probably have an easier time
doing it that way and that should be the default".
> I'd like an example you have of a desktop application that could have
> just as easily been a web application. Bonus points if it's not a CRUD
> screen, and double bonus if you don't just handwave away things like
> file browsing. Although there are benefits even for the crud screen -
> I've written screens and applications for data entry professionals and
> they almost always prefer the speed optimizations you can make in a
> client application.
I guess I've written 4 or 5 nontrivial desktop gui apps and ZERO of
them had file browsing. One of them did need access to the pc's
serial port, which means there had to be application code on the
desktop, but the gui could have been a browser (talking to an
application-embedded http server) if browsers were available in those
days. Another one of them saved some state to a local file but it did
that without file browsing, and could have instead saved the state on
a remote server if it were written as a remote app.
I'm not saying file browsing is never needed, just that from
experimental observation, it's quite often not needed.
Again, it all depends on what you're trying to do. For data entry
stuff you probably want the data on a remote server anyway, and you
can do basic CRUD validation with fairly simple javascript. Maybe
that departs from pure HTML but it's nothing like the ajax/dhtml
madness that causes the problems you've described.
kyos...@gmail.com
> Paul Rubin wrote:
>
> > Tkinteger (dang, I always end up typing it that way, I won't even
> > bother fixing the error) is easy to use for simple gui's, and it's
> > part of the standard python distro which for me is a big advantage (no
> > extra crap to download). However, the widget set is rather ugly and
> > doesn't blend in well with anyone's native widgets; the widget
> > selection itself is rather narrow, and I think kyosohma may be right
> > that it doesn't scale well to complex gui's. I've looked at the code
> > for IDLE's gui and it's terrifying.
>
> It's entirely possible to make sophisticated GUI's in Tkinter, but you
> are right, most people don't. Part of the issue is that Tkinter
> developers haven't kept up with what's going on in Tk and instead use
> outdated, ugly widget sets like Tix, PMW, and so on. Making use of the
> available wrappers for current Tk libraries such as BWidgets, Tile,
> Tablelist, TkTreeCtrl, and so on allows you to make UI's every bit as
> polished as what comes with wxPython: tree views, multi-column lists,
> notebook tabs, comboboxes, etc., with platform-specific theming
> (XP/Vista, Aqua/OS X, and X11).
>
> For more references, see:
>
> http://tkinter.unpythonic.net/wiki/TileWrapperhttp://tkinter.unpythonic.net/wiki/TableListWrapperhttp://tkinter.unpythonic.net/wiki/TableListTileWrapperhttp://tkinter.unpythonic.net/wiki/PyLocatehttp://tkinter.unpythonic.net/wiki/PyLocateTilehttp://tkinter.unpy.net/bwidget/http://tkinter.unpy.net/wiki/NoteBookhttp://klappnase.zexxo.net/TkinterTreectrl/index.html
>
>
>
>
I tried the PMW widget toolkit. It was ok, but it seemed kind of
buggy. I found out about Tix on a forum of some sort. When I tried to
find out how to get it and use it, all I found was conflicting
information. I finally got it downloaded only to find I had to compile
it and I didn't have the right version of TCL. So I switched to
wxPython then. Months later I found out that Tix is now included with
Python.
I still don't know how to use it though. As with most external Tkinter
widget sets, Tix doesn't have examples. The docs look less inviting
than man pages...but I realize that's probably just me. I just don't
like man pages much.
Thanks for the info though. You never know when you might need another
toolkit for a specialized job.
Mike
Chris Mellon
<"http://phr.cx"@nospam.invalid> wrote:
> "Chris Mellon" <ark...@gmail.com> writes:
> > > Might or might not matter for the application, especially considering
> > > that tkinter is part of the discussion.
> > The point is that you have no option with the browser - even Tkinter
> > has platform theming support now.
>
> Hmm, I don't know anything about that. I'm taking the view that for a
> lot of apps, the requirement is to just put some functionality on the
> screen, with slick visual appearance having little value or even
> negative value.
>
Define "functionality". From the rest of your posts, that seems to be
limited to "press buttons" and "type small amounts of non-formatted
text" on the interaction side and "display small amounts of simply
formatted text" on the output side. I'm not denying that you can get
by with this functionality in a large number of cases, but it's
certainly not optimal in general. If it were, we'd all still be using
VT100 terminals.
> > ...Gmail uses ajax instead of a page load when you start
> > typing a reply,
>
> I see, the answer to what caused your problem is approximately "ajax
> is evil", or alternatively, the gmail app attempts slickness with a
> tool that doesn't support slickness that well. OK, I can accept that
> using browsers for slick interfaces has its problems, but the answer
> (a lot of the time, not always) is to just decide you don't need
> slickness.
>
What you're calling "slickness" is what other people call "usable".
Obviously it could be done without the ajax, but you lose features and
usability. It's slower, because it takes a full page load, and I lose
the context of the discussion.
> > > File i/o and file system browsing are available from javascript if the
> > > user grants permission.
> > Which they won't (I don't even know how, from Firefox), so you can't
> > rely on it working.
>
> The application javascript pops a dialog asking for permission and the
> user clicks yes or no. If you can get them to install a desktop app
> (gah!!) then you can certainly get them to click yes in a browser.
> The permission mechanism is admittedly browser dependent.
>
My out of the box firefox install simply denies the operation and
raises a javascript error.
> > But not of anything else. I've often wanted to drag & drop a file onto
> > the file upload box in gmail, for example.
>
> Well, ok, that's a slick feature that your app might need. None of
> mine have needed it so far.
>
> > How about something as simple as context menus?
>
> Unnecessary slickness for many apps. I've never needed it.
>
How have you decided that you've never needed it? Have you ever worked
with a UI designer or workflow expert? Or have you just never bothered
to implement it and you never heard anything from your users? How
closely have you worked with the users of your applications?
> > > Multiple windows are evil most of the time,
> > Multiple windows are the common case on the mac. They're not rare on
> > other platforms as well. The fact that your windows are constrained to
> > the browser and can't be torn off is a large limitation. No toolbars,
> > no palettes, no modal dialogs (except on IE, or if you constrain them
> > to the browser). Lots of unnecessary chrome on your extra windows, too
> > (see below).
>
> You can get rid of the chrome with javascript, but the extra windows
> are still usually evil and unnecessary. Just because they get used a
> lot doesn't change that. A heck of a lot of deployed interfaces, web
> or desktop, simply suck.
>
As phishing attacks become more common, browsing are restricting the
ability to remove or modify chrome. Again, a good feature for a
browser, not so much for an application platform.
> > > > More platforms to develop on and test with.
> > > Compared to a desktop app? I don't think so.
> > Did you ever try counting? X browsers * Y browser versions * Z
> > platforms. There are javascript and CSS bugs and differences between
> > all of these.
>
> If you can tell them to install a desktop app, you can alternatively
> tell them what browser to use. For example we use a complicated
> firefox-only browser app where I work, that relies heavily on canvas
> objects. But if you write your application with straightforward html
> you tend to have very few platform problems.
>
It depends on your target audience and deployment arena. The context
is cross platform applications, so at least 2 browsers and at least 2
platforms are required. Don't forget browser versioning, too - IE 5 is
different than IE 6 is different than IE 7. Even "straightforward"
HTML has non-trivial cross browser differences.
> > From my own professional experience, it's not any easier
> > to account for browser differences than it is for platform
> > differences. It's getting better as more people jump on the web
> > bandwagon and CSS and JS abstraction libraries show up,
>
> I guess I see that stuff as mostly-evil and prefer straightforward
> html.
>
You simply can't do much of anything beyond display text and basic
crud with straightforward HTML without stying. If that is the sole
limit of your UI needs, then bully for you but that's hardly the
common case and I'd venture that you don't have the experience to
support the rather sweeping claim you made.
> > I'm not talking about chrome and slickness. I'm talking about basic
> > usability concerns like "will this work with a higher font size" and
> > "will it reflow in a sensible way if I change the window size". The
> > CSS box model works okay for text, it's not so good for widgets.
>
> I just haven't had this problem with HTML interfaces. I've never even
> used CSS, though that makes me a bit of a lamer. An interface that
> needs to fill the whole screen with widgets is probably too
> complicated.
>
An application is not a book. Of course you fill the whole "screen"
with widgets - your application is defined by the widgets that it has,
and the amount of space those widgets take up is your screen space.
> > More than a few web apps end up writing their own layout engines in
> > dynamic javascript. This is sad. While I'm talking about chrome, add
> > "wasted screenspace due to browser chrome" to a limitation of web
> > apps, again unless you write your own browser host. This is another
> > example of a feature that makes a good browser (don't let arbitrary
> > web pages mess with my web browser functionality) clashing with the
> > desires of a good application (don't waste screen space with
> > irrelevant functionality).
>
> I guess the term I'd use to describe all these effects is "slick" and
> a heck of a lot of the time it's just not needed. Anyway you can pop
> a chromeless browser window with a simple javascript call.
>
> > Man, you should be in PR with the way you spin things. You can't
> > implement anything except the most trivial of applications using only
> > the simple, familiar web elements like HTML forms. Anything more
> > complicated than that needs to be done with DHTML and probably AJAX,
> > and those UI elements don't look anything like the familiar ones. You
> > go in one breath from saying that you can implement dialogs in HTML to
> > saying that the rich client is the *less* familiar of the interfaces?
>
> I don't see the contradiction--with HTML you have just a few widgets
> that everyone understands and you get an interface that's almost
> always self-explanatory. Yes you could call those interfaces trivial,
> but the little secret that I'm trying to convey is that very often,
> trivial is all that's needed.
>
That's simply not true, and I don't think you can objectively justify
it. Besides, you specifically claimed HTML dialogs as being a
replacement for "real" ones, and that can't be done using trivial
interfaces. It requires DHTML, sometimes ajax, and/or browser support.
> > If you'd said "if you're making something really simple that has
> > limited rich UI or data entry needs, consider a web application
> > instead" I wouldn't have posted. A web application is something you
> > make because the deployment and access benefits outweigh the UI and
> > integration limitations, not as your default "go to" whenever you
> > create an application.
>
> Well, I could back off to somewhere between the two. Like, "ask
> yourself whether your application really needs a rich gui or complex
> data entry features. If you can get by with a simple HTML interface,
> and a lot of the time you can, you'll probably have an easier time
> doing it that way and that should be the default".
>
I would challenge the assumption that, starting from zero, it is less
complicated to write a web application, much less a "pretend" web app
using a local web server, than a desktop application using Tkinter
(ick) or wxPython or pyQt. I would also challenge the assumption that
'a lot of the time' you can get away with a simple HTML interface, at
least by my personal definition of 'get away with'. I've worked a lot
with data entry people, where the actual requirements in terms of
slickness and flash are quite small. But "basic html" simply does not
fit the bill. There is a real cost in terms of how fast and how
accurately they can enter data in this environment.
Moreover, if you *don't* need global access or zero-deployment
(zero-deployment is always nice but most environments where you can
reasonably force a specific browser and version also have IT
infrastructure), then you should ask yourself if forcing your
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
simply do not buy the claim that HTML interfaces are necessarily
simpler in any but the most trivial of cases, and even in those
super-trivial applications there are often hidden concerns that don't
filter up to management.
> > I'd like an example you have of a desktop application that could have
> > just as easily been a web application. Bonus points if it's not a CRUD
> > screen, and double bonus if you don't just handwave away things like
> > file browsing. Although there are benefits even for the crud screen -
> > I've written screens and applications for data entry professionals and
> > they almost always prefer the speed optimizations you can make in a
> > client application.
>
> I guess I've written 4 or 5 nontrivial desktop gui apps and ZERO of
> them had file browsing. One of them did need access to the pc's
> serial port, which means there had to be application code on the
> desktop, but the gui could have been a browser (talking to an
> application-embedded http server) if browsers were available in those
> days. Another one of them saved some state to a local file but it did
> that without file browsing, and could have instead saved the state on
> a remote server if it were written as a remote app.
>
Exactly how much time do you think using an HTML interface with an
embedded server would have saved you, especially considering the
careful care you have to take with access to the serial port? For the
record, I've written over a dozen client applications, many of which I
would consider trivial (but used features that would be expensive or
impossible to implement in the browser) and probably twice that many
web apps.
> I'm not saying file browsing is never needed, just that from
> experimental observation, it's quite often not needed.
>
Plural of anecdote and all that. Make a survey of every application
that you interact with and see how many of them need to interact with
arbitrary files from the filesystem.
> Again, it all depends on what you're trying to do. For data entry
> stuff you probably want the data on a remote server anyway, and you
> can do basic CRUD validation with fairly simple javascript. Maybe
> that departs from pure HTML but it's nothing like the ajax/dhtml
> madness that causes the problems you've described.
> --
CRUD with javascript is something I actually have a lot of experience
with. Deficiencies in the data entry UI have real consequences because
you get invalid data and slow data entry speeds. The auto-completing
combo-box, for example, is simply impossible in a browser without
quite complicated (and slow) DHTML and is a huge boon for data entry.
I'm not trying to claim that there are no benefits to web
applications. But I often see people touting the web as a *superior
application platform*, which is simply false, and as innately simpler
to develop for, which is also false.
Kevin Walzer
>
> I tried the PMW widget toolkit. It was ok, but it seemed kind of
> buggy. I found out about Tix on a forum of some sort. When I tried to
> find out how to get it and use it, all I found was conflicting
> information. I finally got it downloaded only to find I had to compile
> it and I didn't have the right version of TCL. So I switched to
> wxPython then. Months later I found out that Tix is now included with
> Python.
>
> I still don't know how to use it though. As with most external Tkinter
> widget sets, Tix doesn't have examples. The docs look less inviting
> than man pages...but I realize that's probably just me. I just don't
> like man pages much.
Tkinter comes more naturally to me than other toolkits because I'm also
a Tcl developer. I just haven't felt the need to learn wxPython because
I can get what I need from Tkinter, even the more complicated GUI layouts.
Steve Holden
> On 06 Aug 2007 09:44:15 -0700, Paul Rubin[...]
>> Again, it all depends on what you're trying to do. For data entry
>> stuff you probably want the data on a remote server anyway, and you
>> can do basic CRUD validation with fairly simple javascript. Maybe
>> that departs from pure HTML but it's nothing like the ajax/dhtml
>> madness that causes the problems you've described.
>
> CRUD with javascript is something I actually have a lot of experience
> with. Deficiencies in the data entry UI have real consequences because
> you get invalid data and slow data entry speeds. The auto-completing
> combo-box, for example, is simply impossible in a browser without
>
It's not even that easy in wxPython is you choose the wrong widget - I
tried to make a combo box accept text and select the drop-down elements
from a database and it turned out to be way too tricky to manage easily.
Having said that, I quickly discovered superior alternatives once I got
rid of my "it has to be a combo box" mentality. While great GUIs have
been created as web front-ends it is substantially more difficult to
create them than it is with a simple-ish GUI toolkit like wxPython,
particularly with a GUI designer like wxDesigner behind it.
> I'm not trying to claim that there are no benefits to web
> applications. But I often see people touting the web as a *superior
> application platform*, which is simply false, and as innately simpler
> to develop for, which is also false.
I would agree. The inherent state-maintenance and interaction problems
have caused the ASP.NET model to be somewhat counterintuitive, to say
the least, though it *has* made it easier to build complex interfaces
that it is on the "raw web". As with all such things, though, once you
run into the limits of the model, the promise of "point-and-click
programming" rapidly becomes a dim memory.
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 -------------
Bryan Hepworth
> On 06 Aug 2007 09:44:15 -0700, Paul Rubin
> <"http://phr.cx"@nospam.invalid> wrote:
>
>> "Chris Mellon" <ark...@gmail.com> writes:
>>
>>>> Might or might not matter for the application, especially considering
>>>> that tkinter is part of the discussion.
>>>>
>>> The point is that you have no option with the browser - even Tkinter
>>> has platform theming support now.
>>>
>> Hmm, I don't know anything about that. I'm taking the view that for a
>> lot of apps, the requirement is to just put some functionality on the
>> screen, with slick visual appearance having little value or even
>> negative value.
>>
>>
>
> limited to "press buttons" and "type small amounts of non-formatted
> text" on the interaction side and "display small amounts of simply
> formatted text" on the output side. I'm not denying that you can get
> by with this functionality in a large number of cases, but it's
> certainly not optimal in general. If it were, we'd all still be using
> VT100 terminals.
>
>
>>> typing a reply,
>>>
>> I see, the answer to what caused your problem is approximately "ajax
>> is evil", or alternatively, the gmail app attempts slickness with a
>> tool that doesn't support slickness that well. OK, I can accept that
>> using browsers for slick interfaces has its problems, but the answer
>> (a lot of the time, not always) is to just decide you don't need
>> slickness.
>>
>>
>
> Obviously it could be done without the ajax, but you lose features and
> usability. It's slower, because it takes a full page load, and I lose
> the context of the discussion.
>
>
>>>> user grants permission.
>>>>
>>> Which they won't (I don't even know how, from Firefox), so you can't
>>> rely on it working.
>>>
>> The application javascript pops a dialog asking for permission and the
>> user clicks yes or no. If you can get them to install a desktop app
>> (gah!!) then you can certainly get them to click yes in a browser.
>> The permission mechanism is admittedly browser dependent.
>>
>>
>
> raises a javascript error.
>
>
>>> the file upload box in gmail, for example.
>>>
>> Well, ok, that's a slick feature that your app might need. None of
>> mine have needed it so far.
>>
>>
>>> How about something as simple as context menus?
>>>
>> Unnecessary slickness for many apps. I've never needed it.
>>
>>
>
> with a UI designer or workflow expert? Or have you just never bothered
> to implement it and you never heard anything from your users? How
> closely have you worked with the users of your applications?
>
>
>>>>
>>> Multiple windows are the common case on the mac. They're not rare on
>>> other platforms as well. The fact that your windows are constrained to
>>> the browser and can't be torn off is a large limitation. No toolbars,
>>> no palettes, no modal dialogs (except on IE, or if you constrain them
>>> to the browser). Lots of unnecessary chrome on your extra windows, too
>>> (see below).
>>>
>> You can get rid of the chrome with javascript, but the extra windows
>> are still usually evil and unnecessary. Just because they get used a
>> lot doesn't change that. A heck of a lot of deployed interfaces, web
>> or desktop, simply suck.
>>
>>
>
> ability to remove or modify chrome. Again, a good feature for a
> browser, not so much for an application platform.
>
>
>>>>>
>>>> Compared to a desktop app? I don't think so.
>>>>
>>> Did you ever try counting? X browsers * Y browser versions * Z
>>> platforms. There are javascript and CSS bugs and differences between
>>> all of these.
>>>
>> If you can tell them to install a desktop app, you can alternatively
>> tell them what browser to use. For example we use a complicated
>> firefox-only browser app where I work, that relies heavily on canvas
>> objects. But if you write your application with straightforward html
>> you tend to have very few platform problems.
>>
>>
>
> is cross platform applications, so at least 2 browsers and at least 2
> platforms are required. Don't forget browser versioning, too - IE 5 is
> different than IE 6 is different than IE 7. Even "straightforward"
> HTML has non-trivial cross browser differences.
>
>
>>> to account for browser differences than it is for platform
>>> differences. It's getting better as more people jump on the web
>>> bandwagon and CSS and JS abstraction libraries show up,
>>>
>> I guess I see that stuff as mostly-evil and prefer straightforward
>> html.
>>
>>
>
> crud with straightforward HTML without stying. If that is the sole
> limit of your UI needs, then bully for you but that's hardly the
> common case and I'd venture that you don't have the experience to
> support the rather sweeping claim you made.
>
>
>>> usability concerns like "will this work with a higher font size" and
>>> "will it reflow in a sensible way if I change the window size". The
>>> CSS box model works okay for text, it's not so good for widgets.
>>>
>> I just haven't had this problem with HTML interfaces. I've never even
>> used CSS, though that makes me a bit of a lamer. An interface that
>> needs to fill the whole screen with widgets is probably too
>> complicated.
>>
>>
>
> with widgets - your application is defined by the widgets that it has,
> and the amount of space those widgets take up is your screen space.
>
>
>>> dynamic javascript. This is sad. While I'm talking about chrome, add
>>> "wasted screenspace due to browser chrome" to a limitation of web
>>> apps, again unless you write your own browser host. This is another
>>> example of a feature that makes a good browser (don't let arbitrary
>>> web pages mess with my web browser functionality) clashing with the
>>> desires of a good application (don't waste screen space with
>>> irrelevant functionality).
>>>
>> I guess the term I'd use to describe all these effects is "slick" and
>> a heck of a lot of the time it's just not needed. Anyway you can pop
>> a chromeless browser window with a simple javascript call.
>>
>>
>>> Man, you should be in PR with the way you spin things. You can't
>>> implement anything except the most trivial of applications using only
>>> the simple, familiar web elements like HTML forms. Anything more
>>> complicated than that needs to be done with DHTML and probably AJAX,
>>> and those UI elements don't look anything like the familiar ones. You
>>> go in one breath from saying that you can implement dialogs in HTML to
>>> saying that the rich client is the *less* familiar of the interfaces?
>>>
>> I don't see the contradiction--with HTML you have just a few widgets
>> that everyone understands and you get an interface that's almost
>> always self-explanatory. Yes you could call those interfaces trivial,
>> but the little secret that I'm trying to convey is that very often,
>> trivial is all that's needed.
>>
>>
>
> it. Besides, you specifically claimed HTML dialogs as being a
> replacement for "real" ones, and that can't be done using trivial
> interfaces. It requires DHTML, sometimes ajax, and/or browser support.
>
>
>>> limited rich UI or data entry needs, consider a web application
>>> instead" I wouldn't have posted. A web application is something you
>>> make because the deployment and access benefits outweigh the UI and
>>> integration limitations, not as your default "go to" whenever you
>>> create an application.
>>>
>> Well, I could back off to somewhere between the two. Like, "ask
>> yourself whether your application really needs a rich gui or complex
>> data entry features. If you can get by with a simple HTML interface,
>> and a lot of the time you can, you'll probably have an easier time
>> doing it that way and that should be the default".
>>
>>
>
> complicated to write a web application, much less a "pretend" web app
> using a local web server, than a desktop application using Tkinter
> (ick) or wxPython or pyQt. I would also challenge the assumption that
> 'a lot of the time' you can get away with a simple HTML interface, at
> least by my personal definition of 'get away with'. I've worked a lot
> with data entry people, where the actual requirements in terms of
> slickness and flash are quite small. But "basic html" simply does not
> fit the bill. There is a real cost in terms of how fast and how
> accurately they can enter data in this environment.
>
> Moreover, if you *don't* need global access or zero-deployment
> (zero-deployment is always nice but most environments where you can
> reasonably force a specific browser and version also have IT
> infrastructure), then you should ask yourself if forcing your
> 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
> simply do not buy the claim that HTML interfaces are necessarily
> simpler in any but the most trivial of cases, and even in those
> super-trivial applications there are often hidden concerns that don't
> filter up to management.
>
>
>>> just as easily been a web application. Bonus points if it's not a CRUD
>>> screen, and double bonus if you don't just handwave away things like
>>> file browsing. Although there are benefits even for the crud screen -
>>> I've written screens and applications for data entry professionals and
>>> they almost always prefer the speed optimizations you can make in a
>>> client application.
>>>
>> I guess I've written 4 or 5 nontrivial desktop gui apps and ZERO of
>> them had file browsing. One of them did need access to the pc's
>> serial port, which means there had to be application code on the
>> desktop, but the gui could have been a browser (talking to an
>> application-embedded http server) if browsers were available in those
>> days. Another one of them saved some state to a local file but it did
>> that without file browsing, and could have instead saved the state on
>> a remote server if it were written as a remote app.
>>
>>
>
> embedded server would have saved you, especially considering the
> careful care you have to take with access to the serial port? For the
> record, I've written over a dozen client applications, many of which I
> would consider trivial (but used features that would be expensive or
> impossible to implement in the browser) and probably twice that many
> web apps.
>
>
>> experimental observation, it's quite often not needed.
>>
>>
>
> that you interact with and see how many of them need to interact with
> arbitrary files from the filesystem.
>
>
>> stuff you probably want the data on a remote server anyway, and you
>> can do basic CRUD validation with fairly simple javascript. Maybe
>> that departs from pure HTML but it's nothing like the ajax/dhtml
>> madness that causes the problems you've described.
>>
>
> CRUD with javascript is something I actually have a lot of experience
> with. Deficiencies in the data entry UI have real consequences because
> you get invalid data and slow data entry speeds. The auto-completing
> combo-box, for example, is simply impossible in a browser without
>
> I'm not trying to claim that there are no benefits to web
> applications. But I often see people touting the web as a *superior
> application platform*, which is simply false, and as innately simpler
> to develop for, which is also false.
>
first time.
I'd be curious to know peoples take on other GUI's like pygtk and pyqt
for example to get a fuller picture. As a total newbie the list seems
daunting so taking advantage of other peoples experiences seems like a
good idea.
Bryan
kyos...@gmail.com
Yeah...I would assume I would enjoy Tkinter more if I knew more tcl.
Until that day arrives though, it will probably still be fairly
confusing for me to figure out. I do like it's "pythonic" style
though.
Mike
Paul Rubin
> Define "functionality". From the rest of your posts, that seems to be
> limited to "press buttons" and "type small amounts of non-formatted
> text" on the interaction side and "display small amounts of simply
> formatted text" on the output side.
OK, I can live with that, if you include displaying images on the
output side.
> I'm not denying that you can get
> by with this functionality in a large number of cases,
Precisely my point.
> but it's certainly not optimal in general.
> If it were, we'd all still be using VT100 terminals.
Nah, HTML gui's are much easier to use than pure text interfaces,
because of the visual gui elements, pointing with the mouse, simple
control over fonts and color, etc.
> > > ...Gmail uses ajax instead of a page load
> What you're calling "slickness" is what other people call "usable".
I notice google search doesn't use ajax (or didn't til recently) and
has satisfied an awful lot of users with simple html.
> My out of the box firefox install simply denies the operation and
> raises a javascript error.
Hmm, the user might have to change a setting in about:config but
that's certainly easier than installing a desktop application. I
haven't done this with firefox. In Communicator you'd just call
netscape.security.privilegemanager and ask for the permission that you
needed.
> > > How about something as simple as context menus?
> > Unnecessary slickness for many apps. I've never needed it.
> How have you decided that you've never needed it? Have you ever worked
> with a UI designer or workflow expert? Or have you just never bothered
> to implement it and you never heard anything from your users? How
> closely have you worked with the users of your applications?
If the app has enough slickness requirements that the customer is
willing to pay for the attention of UI designers or workflow experts,
maybe it also needs context menus, I don't know. Generally I'd say
there are several levels:
1. In-house app that will have 1 to 10 users who run it now and
then. Every minute of unnecessary development is wasting their money,
so they want the quickest and cheapest possible solution. Web app is
very often an easier way to do this than desktop gui app, even if the
functionality is bare bones. I've done several of these, either as
desktop apps or web apps, generally working closely with the user, and
nobody has said anything about context menus. I think this case is
very common. In some instances the sole user is me, so nobody else
has to be satisfied.
2. Wide-use app that will have 1000's of users, including
non-in-house users who tend to distrust desktop installs. Web app is
superior for deployment reasons even if you have to give up some ui
niceties. This is what I do most of the time as a web developer. I
tend to write simple html to implement functionality, then let a real
designer spiff it up to look slick on multiple browsers while I
concentrate on the backend programming.
3. In-house app somewhere between 1 and 2, i.e. maybe there are
dozens or hundreds of users who will interact with the program all day
long. Usability becomes more important, so this can go either way.
Maybe this is where you want to UI experts involved. It sounds like
your CRUD apps are often in this category. Not everybody's are. Mine
haven't been so far. If I were in this situation I'd consider both
the web and desktop approaches and could go either way depending on
the specific requirements.
4. Shrink-wrap consumer app, zillions of units to ship, pizzazz
sells boxes, slickness is king. You need a whiz-bang desktop gui done
by real artist/designers. I'm just a coder, so my approach would be
write a slapdash tkinter or web gui to figure out the necessary
functionality in conjunction with UI specialists, then write a spec
based on the prototype and turn it over to the artistic gurus, with me
doing the backend stuff in cooperation with them. I haven't so far
done anything like this even though I worked at a game company for a
while. I think most of us can code our way through life without ever
doing it.
> As phishing attacks become more common, browsing are restricting the
> ability to remove or modify chrome.
I'm using firefox 2 and sites pop chromeless windows all the time, so
I'm not sure what browsers you're referring to.
> It depends on your target audience and deployment arena. The context
> is cross platform applications,
I don't see anything about cross platform in the OP's original post.
If cross platform were important I'd start asking whether the app
needed to be usable from mobile phones. If yes, that weighs heavily
for browsers.
> You simply can't do much of anything beyond display text and basic
> crud with straightforward HTML without stying. If that is the sole
> limit of your UI needs, then bully for you but that's hardly the
> common case and I'd venture that you don't have the experience to
> support the rather sweeping claim you made.
I think it's a very common case, which is why so much stuff is being
done on the web instead of the desktop.
> That's simply not true, and I don't think you can objectively justify
> it. Besides, you specifically claimed HTML dialogs as being a
> replacement for "real" ones, and that can't be done using trivial
> interfaces. It requires DHTML, sometimes ajax, and/or browser support.
I guess I'm not sure what you mean about dialogs. I would consider
some html input fields with a submit button to be a dialog. Sometimes
a little client side JS can make things a bit nicer. I guess that
technically counts as DHTML but if you keep it simple, you can avoid
most cross-browser issues.
> I would challenge the assumption that, starting from zero, it is less
> complicated to write a web application, much less a "pretend" web app
> using a local web server, than a desktop application using Tkinter
> (ick) or wxPython or pyQt. I would also challenge the assumption that
> 'a lot of the time' you can get away with a simple HTML interface, at
> least by my personal definition of 'get away with'. I've worked a lot
> with data entry people, where the actual requirements in terms of
> slickness and flash are quite small. But "basic html" simply does not
> fit the bill. There is a real cost in terms of how fast and how
> accurately they can enter data in this environment.
Well, not everybody needs to enter data all day long. If they need to
enter seven numbers into a form once a week and it takes them 15
seconds with a special desktop app and 17 seconds with a web app and
there are only three users, go for the web app if it saves you any
development or support time.
> Exactly how much time do you think using an HTML interface with an
> embedded server would have saved you, especially considering the
> careful care you have to take with access to the serial port?
I am sure it would have saved at least half the development time of
that app. But it's not a fair comparison since that was a 16 bit
MS-DOS app written in C.
> > I'm not saying file browsing is never needed, just that from
> > experimental observation, it's quite often not needed.
>
> Plural of anecdote and all that. Make a survey of every application
> that you interact with and see how many of them need to interact with
> arbitrary files from the filesystem.
OK, looking at what's on my screen during most of my workday:
1) one or more browser windows. No file system interaction.
2) Several terminal windows, no file interaction from the terminal
itself, but I run command line apps (mostly emacs) in the terminals
and those sometimes use the file system.
3) Text chat client, I think it can send and receive files but I never
use that feature. I would not run this particular app if it were
up to me but management chose it. But it is a sort of legitimate
use of a desktop gui.
4) Email client again chosen by management. This one does use the
file system to send and receive attachments, but that's not
fundamentally required since webmail clients are very popular and
effective and can upload and download. At home I read email with
emacs.
The only other desktop gui program I can think of that I use with any
regularity is a PDF viewer occasionally launched by the browser. More
typically this is done with a browser plugin rather than a separate
app, but my desktop is set up to launch xpdf separately. Under
Windows I sometimes used IDLE for Python development but under Linux I
run python inside emacs.
> CRUD with javascript is something I actually have a lot of experience
> with. Deficiencies in the data entry UI have real consequences because
> you get invalid data and slow data entry speeds. The auto-completing
> combo-box, for example, is simply impossible in a browser without
> quite complicated (and slow) DHTML and is a huge boon for data entry.
I'm not sure what that combo box is. I've probably seen one but I'm
just not sure exactly what you're referring to. Maybe it's important
if you write heavily used CRUD apps. Not everybody who needs a gui
writes those apps.
> I'm not trying to claim that there are no benefits to web
> applications. But I often see people touting the web as a *superior
> application platform*, which is simply false, and as innately simpler
> to develop for, which is also false.
I think it is simpler until you're trying to do stuff that's both
slick and multi-platform, but not everyone cares about being both of
those things simultaneously. I generally don't care about slickness
and accomplish multi-platform by writing dirt-simple html.
Paul Rubin
> Yeah...I would assume I would enjoy Tkinter more if I knew more tcl.
> Until that day arrives though, it will probably still be fairly
> confusing for me to figure out. I do like it's "pythonic" style
> though.
I've managed to program tkinter without knowing anything about tcl.
This manual is good:
Chris Mellon
<snip over-long thread>
I had a bunch of replies to each section but I think this is getting
too long so I'll sum up.
You repeatedly have used the word "slickness" as a pejorative. I find
that offensive and it's insulting to users. When I write applications,
I want the interface to be as smooth and trouble free as possible,
with a simple a learning curve and the fewest possible bumps for them.
This isn't a matter of adding chrome or shine or rounded corners and
specular highlights. It's about letting them enjoy working with an
application instead of tolerating it. It's the same reason I use
Python and not C. It's about respect for their time and their
preferences.
As a matter of time spent in development, I do not find that
non-trivial UIs are significantly easier to develop using web
interfaces.
As a matter of respect for the user, I'm not going to tell them to use
a trivial UI if a non-trivial one will save them time, learning
effort, or frustration. In order to make this decision, I like to work
with the people actually using it and watch them at work. To see what
kind of extra steps they have to take and where I can save them time
or inaccuracy or frustration.
sjde...@yahoo.com
> Hi,
>
> I want to build a GUI to execut python script. I found TKinter and
> wxpython. Which one is easier for a newbie? and which one is better?
>
If you want to have a native look and feel, I'd choose wxpython
(probably the Dabo builder for it). If not, I'd usually take a web UI
over tkinter, except in special simple cases. But it's really a
matter of taste. Dabo does make UI construction a lot simpler for me
(and for a lot of other people.).
Paul Rubin
> You repeatedly have used the word "slickness" as a pejorative. I find
> that offensive and it's insulting to users. When I write applications,
> I want the interface to be as smooth and trouble free as possible,
It's a perjorative when it's done for its own sake and doesn't really
help the user. This happens a lot. When it helps the user, as it
sometimes does, then it's not perjorative.
> As a matter of time spent in development, I do not find that
> non-trivial UIs are significantly easier to develop using web
> interfaces.
That's possibly true, but a lot of the time, trivial interfaces are
enough. Look at Google search, one of the most complex apps ever
built (tens or hundreds of MLOC, massive distributed crawler
infrastructure, 100's of PhD's figuring out the algorithms, etc.) but
its interface is simple HTML that you would probably call trivial. It
is quite possibly the most popular application in the world.
> As a matter of respect for the user, I'm not going to tell them to use
> a trivial UI if a non-trivial one will save them time, learning
> effort, or frustration. In order to make this decision, I like to work
> with the people actually using it and watch them at work. To see what
> kind of extra steps they have to take and where I can save them time
> or inaccuracy or frustration.
Right. Obviously this has to be decided according to the specific
needs of the application. A lot of times, trivial interfaces are
easier to learn than nontrivial ones, precisely because they are
trivial so there is less to learn. Again look at Google search for an
example.
Also, at least for in-house applications, while the user's time counts
(since their time costs your customer money), your development time
and deployment effort also costs money that comes from exactly the
same place, so you have to take into consideration the number of
users, amount of time they will spend using the program, just how much
of that time (if any) a fancier interface will save, etc.
Chris Mellon
<"http://phr.cx"@nospam.invalid> wrote:
> "Chris Mellon" <ark...@gmail.com> writes:
> > You repeatedly have used the word "slickness" as a pejorative. I find
> > that offensive and it's insulting to users. When I write applications,
> > I want the interface to be as smooth and trouble free as possible,
>
> It's a perjorative when it's done for its own sake and doesn't really
> help the user. This happens a lot. When it helps the user, as it
> sometimes does, then it's not perjorative.
>
To me, "slick" means well lubricated and smooth. It means that there
are no rough spots in your interaction. I use the term "flash" for
cosmetic features.
> > As a matter of time spent in development, I do not find that
> > non-trivial UIs are significantly easier to develop using web
> > interfaces.
>
> That's possibly true, but a lot of the time, trivial interfaces are
> enough. Look at Google search, one of the most complex apps ever
> built (tens or hundreds of MLOC, massive distributed crawler
> infrastructure, 100's of PhD's figuring out the algorithms, etc.) but
> its interface is simple HTML that you would probably call trivial. It
> is quite possibly the most popular application in the world.
>
When you start talking about trivializing the interface, what you're
actually talking about is trivializing the *process*. The UI is just a
mechanism for interaction. If you have complex interactions, then you
need complex UI (or your users have to do a lot of manual steps).
Search is a good example of trivial interaction. It's not really the
common case, though - in a regular web browser there's a half dozen
minimal points of interaction, and some of them are fairly
complicated. In terms of man-hours spent, raw data entry is one of the
largest cases of human-computer interaction and it's a significantly
more complex interface than search.
As you point out, the complexity of the interaction is only loosely
coupled to the complexity of the application itself, and the art of
designing simple interactions with complex systems is one of the
hallmarks of good design. Apple is generally quite good at this. Note
even so that simple interactions can have or require rather
complicated UI metaphors. Drag and drop is a very visceral, intuitive
interface (it's the second thing my 4 year old figured out how to do,
button clicking was the first) but it's quite complicated to
implement.
I rather suspect that Google has rather more complicated internal
administrative and reporting interfaces for the search engine, too.
> > As a matter of respect for the user, I'm not going to tell them to use
> > a trivial UI if a non-trivial one will save them time, learning
> > effort, or frustration. In order to make this decision, I like to work
> > with the people actually using it and watch them at work. To see what
> > kind of extra steps they have to take and where I can save them time
> > or inaccuracy or frustration.
>
> Right. Obviously this has to be decided according to the specific
> needs of the application. A lot of times, trivial interfaces are
> easier to learn than nontrivial ones, precisely because they are
> trivial so there is less to learn. Again look at Google search for an
> example.
>
> Also, at least for in-house applications, while the user's time counts
> (since their time costs your customer money), your development time
> and deployment effort also costs money that comes from exactly the
> same place, so you have to take into consideration the number of
> users, amount of time they will spend using the program, just how much
> of that time (if any) a fancier interface will save, etc.
Business constraints are always there in software development. You
don't get enough testing, you don't have access to representative test
data, you don't have direct user feedback. And of course the guy
signing the checks, who often isn't the guy using the application, may
decide that an hour of your time isn't worth 100 hours aggravation
from his minimum wage data entry folks. But *I* care about that 100
hours and to the greatest extent possible within my ability and
contract, I will minimize that burden on them.
Cameron Laird
Bryan Hepworth <br...@redfedora.co.uk> wrote:
.
[waaaaaaay too
much quoted text
for my taste]
.
.
>> I'm not trying to claim that there are no benefits to web
>> applications. But I often see people touting the web as a *superior
>> application platform*, which is simply false, and as innately simpler
>> to develop for, which is also false.
>>
>I'm also in a similar predicament starting to look at Python for the
>first time.
>
>I'd be curious to know peoples take on other GUI's like pygtk and pyqt
>for example to get a fuller picture. As a total newbie the list seems
>daunting so taking advantage of other peoples experiences seems like a
>good idea.
>
>Bryan
The traditional answer is, "We've already discussed that far too
often; go search the comp.lang.python archive on your own, because
all the answers are there."
I regard that as unhelpful. <URL:
http://wiki.python.org/moin/ChoosingGuiToolkits > *could* be a good
answer, but it's not, at least not yet. Perhaps the best immediate
help is <URL: http://wiki.python.org/moin/GuiProgramming >.
Even better, maybe: read through these materials, start to integrate
your own findings into what the Wiki already makes available, and
likely others of us will pitch in.
Cameron Laird
Chris Mellon <ark...@gmail.com> wrote:
.
[scores of lines
of vigorous debate]
.
.
>Moreover, if you *don't* need global access or zero-deployment
>(zero-deployment is always nice but most environments where you can
>reasonably force a specific browser and version also have IT
>infrastructure), then you should ask yourself if forcing your
>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.
Cameron Laird
Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
.
.
>I should also add: there is also the possibility of running a Python
>program with an embedded http server on the same desktop as the
>browser, using the browser purely as a gui, but with the Python
>program having complete access to the file system and so forth. This
>could be seen as combining the disadvantages of both the remote web
>server approach (i.e. gui elements constrained by the browser) and the
>all-desktop approach (deployment issues). However, a lot of the time
>it's still just plain easier to do. Whenever I've written a desktop
>gui app I've always just been shocked at how much time goes into
>making the gui look decent and do the right stuff, even though none of
>mine have been even slightly slick (they've all been for industrial
>applications). When I do a web gui, it's been just a matter of
>tossing some html into a file or into some print statements, viewing
>it in a browser, and tweaking it a little as needed. Maybe that's
>mostly a matter of the lousy state of gui toolkits, and we actually
>need a toolkit that's more like an embedded browser. But we don't
>have that at the moment.
One key to Tkinter's longevity lurks there. While
many whine about the antiquity of the appearance of
Tkinter's widgets, they have the virtue of sensible
defaults; more than any other toolkit, Tkinter comes
up with minimal refinements in a sensible and
consistent state. 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.
kyos...@gmail.com
> In article <7x7io8r6na....@ruckus.brouhaha.com>,
I am curious. What are these "sensible defaults" that you mention?
If you set up a wxPython program's sizers appropriately, the program
should resize logically. But I think Tkinter is a little bit easier in
that respect. However, you can get pretty granular in how you want
items to behave in wxPython that you may not be able to do in Tkinter.
I just don't know.
I've used both, so I'm interested in hearing your opinion.
Mike
Paul Rubin
> >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
> .
> 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
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
> 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
> 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
>
> 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).
Chris Mellon
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
> On 8/8/07, Kevin Walzer <k...@codebykevin.com> 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?
Kevin Walzer
> On 8/8/07, Kevin Walzer <k...@codebykevin.com> 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
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
>> 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 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
>
> >> 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).
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 ;)
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.
> >
> > 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.
>
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
Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
.
.
.
>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.
--
Greg
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
Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
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
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...
--
Greg
Steve Holden
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
Jay Loden
> 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