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
44  4937 
<bg***@yahoo.comwrote in message
news:11*********************@d55g2000hsg.googlegro ups.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 ;)
On Mon, 30 Jul 2007 16:36:00 +0200, <bg***@yahoo.comwrote:
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+-'])" bg***@yahoo.com wrote:
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
In article <11*********************@d55g2000hsg.googlegroups. com>,
<bg***@yahoo.comwrote:
>
[ ... ]
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()
Gary Duzan
Motorola CHS
On Aug 3, 1:00 am, "wang frank" <f...@hotmail.co.jpwrote:
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
On Aug 2, 7:00 pm, "wang frank" <f...@hotmail.co.jpwrote:
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/msnjpqjl...gbl/direct/01/
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 ky******@gmail.com writes:
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.
On Aug 6, 9:39 am, Paul Rubin <http://phr...@NOSPAM.invalidwrote:
kyoso...@gmail.com writes:
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.
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...x-ulation.html
Desktop apps have security issues too, of course.
Mike
On 06 Aug 2007 07:39:12 -0700, Paul Rubin
<"http://phr.cx"@nospam.invalidwrote:
ky******@gmail.com writes:
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.
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. ky******@gmail.com writes:
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...x-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.
"Chris Mellon" <ar*****@gmail.comwrites:
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.
On Aug 6, 9:58 am, "Chris Mellon" <arka...@gmail.comwrote:
On 06 Aug 2007 07:39:12 -0700, Paul Rubin
<"http://phr.cx"@nospam.invalidwrote:
kyoso...@gmail.com writes:
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.
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.
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
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/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
On 06 Aug 2007 08:20:20 -0700, Paul Rubin
<"http://phr.cx"@nospam.invalidwrote:
"Chris Mellon" <ar*****@gmail.comwrites:
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 <http://ph****@NOSPAM.invalidwrites:
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.
"Chris Mellon" <ar*****@gmail.comwrites:
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.
On Aug 6, 10:27 am, Kevin Walzer <k...@codebykevin.comwrote:
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/T...trl/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
On 06 Aug 2007 09:44:15 -0700, Paul Rubin
<"http://phr.cx"@nospam.invalidwrote:
"Chris Mellon" <ar*****@gmail.comwrites:
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. ky******@gmail.com wrote:
>
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.
--
Kevin Walzer
Code by Kevin http://www.codebykevin.com
Chris Mellon wrote:
On 06 Aug 2007 09:44:15 -0700, Paul Rubin
<"http://phr.cx"@nospam.invalidwrote:
>"Chris Mellon" <ar*****@gmail.comwrites:
[...]
>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.
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 -------------
Chris Mellon wrote:
On 06 Aug 2007 09:44:15 -0700, Paul Rubin
<"http://phr.cx"@nospam.invalidwrote:
>"Chris Mellon" <ar*****@gmail.comwrites:
>>>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.
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
On Aug 6, 12:49 pm, Kevin Walzer <k...@codebykevin.comwrote:
kyoso...@gmail.com wrote:
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.
--
Kevin Walzer
Code by Kevinhttp://www.codebykevin.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
"Chris Mellon" <ar*****@gmail.comwrites:
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. ky******@gmail.com writes:
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: http://infohost.nmt.edu/tcc/help/pubs/tkinter/
On Aug 2, 8:00 pm, "wang frank" <f...@hotmail.co.jpwrote:
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.).
In article <ma***************************************@python. org>,
Chris Mellon <ar*****@gmail.comwrote:
In article <ma***************************************@python. org>,
Bryan Hepworth <br***@redfedora.co.ukwrote:
In article <7x************@ruckus.brouhaha.com>,
Paul Rubin <http://ph****@NOSPAM.invalidwrote:
On Aug 7, 9:00 am, cla...@lairds.us (Cameron Laird) wrote:
In article <7x7io8r6na....@ruckus.brouhaha.com>,
Paul Rubin <http://phr...@NOSPAM.invalidwrote:
.
.
.
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.
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 cl****@lairds.us (Cameron Laird) writes:
application in the web app model (I haven't even touched on the whole
stateless HTTP being mapped to a stateful environment issue, or the
need to manage the local web server) actually buys you anything. I
.
Go ahead: touch on statefulness. I've been pondering the topic
lately, and wonder what's new on the subject. I find it plenty
difficult to cast this as anything but a big liability for the
Web app team.
I'm not sure what you're getting at in this context. You can write a
desktop app where the window system communicates with a gui toolkit
through a socket (at least that's how X windows works), or you can
write a web app where a browser communicates with an http listener
through a socket. What's the difference, as far as application state
is concerned?
I haven't used wxpython but for tkinter you'd typically have a gui
event loop in its own thread, communicating with the application
through queues. Similarly you can use BaseHTTPServer to collect
browser hits and get the data out of them with the cgi module
functions before passing them to the app. If you want to handle
multiple concurrent users you get into the usual issues of web
servers, but if you're just doing a single user web implementation as
an alternative to a desktop gui, some rudimentary locking is probably
enough to stop accidental simultaneous connections.
If the application is simple enough, you can just write it as a cgi
and keep the state in disk files.
"Paul Rubin" <http:/...nvalidwrote: cl****@lairds.us (Cameron Laird) writes:
>application in the web app model (I haven't even touched on the whole
>stateless HTTP being mapped to a stateful environment issue, or the
>need to manage the local web server) actually buys you anything. I
.
Go ahead: touch on statefulness. I've been pondering the topic
lately, and wonder what's new on the subject. I find it plenty
difficult to cast this as anything but a big liability for the
Web app team.
I'm not sure what you're getting at in this context. You can write a
desktop app where the window system communicates with a gui toolkit
through a socket (at least that's how X windows works), or you can
write a web app where a browser communicates with an http listener
through a socket. What's the difference, as far as application state
is concerned?
I haven't used wxpython but for tkinter you'd typically have a gui
event loop in its own thread, communicating with the application
through queues. Similarly you can use BaseHTTPServer to collect
browser hits and get the data out of them with the cgi module
functions before passing them to the app. If you want to handle
multiple concurrent users you get into the usual issues of web
servers, but if you're just doing a single user web implementation as
an alternative to a desktop gui, some rudimentary locking is probably
enough to stop accidental simultaneous connections.
If the application is simple enough, you can just write it as a cgi
and keep the state in disk files.
Something that is often overlooked is keeping some state in the buttons.
It involves changing the text, colour and the command binding, and
possibly setting up a callback using .after for time outs, if necessary.
You can do quite complicated sequences like this, if you have a mind to.
Its a bit of a PITA - but then all state machines are, no matter how you
implement them. Their chief advantage is that they force you to think
of all the possibilities.
- Hendrik
--
Enrol now in Heavy Henry's Wholesome Hackadamy,
for a course in single button GUI design.
The sacred crocodiles are for the moment leashed.
Paul Rubin wrote:
I'm not sure what you're getting at in this context. You can write a
desktop app where the window system communicates with a gui toolkit
through a socket (at least that's how X windows works)
An X server connection is *much* more stateful than
an HTTP one. It persists throughout the entire use
session of the application, for one thing, and there
is heaps of state being kept on both sides of the
connection. There's also a very high communication
bandwidth between them. There's really no comparison.
--
Greg
greg <gr**@cosc.canterbury.ac.nzwrites:
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.
Cameron Laird wrote:
>
While those with an artistic eye
assure me the simplest Tkinter programs look worse
that corresponding ones built with any other toolkit,
they behave the most coherently in regards to resizing
and so on.
"Look worse" can be addressed through extensive means: through theming
(via Tile, which can now be easily used in Tkinter; see http://tkinter.unpy.net/wiki/TileWrapper); and through other aspects of
UI design, such as color, fonts, and even use of icons. A pyGtk or
wxPython application that uses old-school Gnome icons, for instance,
will look ugly. It's quite possible to make an attractive Tkinter
application using modern, stylish icons that even blends in reasonably
well on a specific platform (I've done it).
--
Kevin Walzer
Code by Kevin http://www.codebykevin.com
On 8/8/07, Kevin Walzer <kw@codebykevin.comwrote:
Cameron Laird wrote:
While those with an artistic eye
assure me the simplest Tkinter programs look worse
that corresponding ones built with any other toolkit,
they behave the most coherently in regards to resizing
and so on.
"Look worse" can be addressed through extensive means: through theming
(via Tile, which can now be easily used in Tkinter; see
http://tkinter.unpy.net/wiki/TileWrapper); and through other aspects of
UI design, such as color, fonts, and even use of icons. A pyGtk or
wxPython application that uses old-school Gnome icons, for instance,
will look ugly. It's quite possible to make an attractive Tkinter
application using modern, stylish icons that even blends in reasonably
well on a specific platform (I've done it).
--
Using Tile, of course, loses you the first major benefit of Tk - that
it's already included in the standard library. So in this sense it's
still "ugly old school look and feel" vs "no external dependencies",
which is the swing decision for many people. People who prefer the Tk
API, of course, will be happy to use Tile.
Also, while you can get (mostly) native *look*, the feel is absent.
Unless I'm very uninformed, Tile is a theming engine only, and doesn't
implement platform conventions with regard to behavior (the "feel"
part of look and feel).
Chris Mellon wrote:
On 8/8/07, Kevin Walzer <kw@codebykevin.comwrote:
Using Tile, of course, loses you the first major benefit of Tk - that
it's already included in the standard library. So in this sense it's
still "ugly old school look and feel" vs "no external dependencies",
which is the swing decision for many people. People who prefer the Tk
API, of course, will be happy to use Tile.
Tile has been implemented in the Tk core starting with version 8.5,
still somewhere between alpha and beta stage. Once 8.5 is out, and
Python is configured to build against Tk 8.5 (instead of 8.4), it should
Just Work.
>
Also, while you can get (mostly) native *look*, the feel is absent.
Unless I'm very uninformed, Tile is a theming engine only, and doesn't
implement platform conventions with regard to behavior (the "feel"
part of look and feel).
What do you mean here? Things like keyboard accelerators, menu
placement, and so on? Those things are already natively implemented by
Tk, and the developer just needs to invoke them. Sometimes some
conditional code is required for stuff like keyboard accelerators (the
"tk windowingsytem" command is useful for this), but again, it should
Just Work.
Or am I missing something?
--
Kevin Walzer
Code by Kevin http://www.codebykevin.com
Chris Mellon wrote:
On 8/8/07, Kevin Walzer <kw@codebykevin.comwrote:
Using Tile, of course, loses you the first major benefit of Tk - that
it's already included in the standard library. So in this sense it's
still "ugly old school look and feel" vs "no external dependencies",
which is the swing decision for many people. People who prefer the Tk
API, of course, will be happy to use Tile.
Tile has been implemented in the Tk core starting with version 8.5,
still somewhere between alpha and beta stage. Once 8.5 is out, and
Python is configured to build against Tk 8.5 (instead of 8.4), it should
Just Work.
>
Also, while you can get (mostly) native *look*, the feel is absent.
Unless I'm very uninformed, Tile is a theming engine only, and doesn't
implement platform conventions with regard to behavior (the "feel"
part of look and feel).
What do you mean here? Things like keyboard accelerators, menu
placement, and so on? Those things are already natively implemented by
Tk, and the developer just needs to invoke them. Sometimes some
conditional code is required for stuff like keyboard accelerators (the
"tk windowingsytem" command is useful for this), but again, it should
Just Work.
Or am I missing something?
--
Kevin Walzer
Code by Kevin http://www.codebykevin.com
On 8/8/07, Kevin Walzer <kw@codebykevin.comwrote:
Chris Mellon wrote:
On 8/8/07, Kevin Walzer <kw@codebykevin.comwrote:
Using Tile, of course, loses you the first major benefit of Tk - that
it's already included in the standard library. So in this sense it's
still "ugly old school look and feel" vs "no external dependencies",
which is the swing decision for many people. People who prefer the Tk
API, of course, will be happy to use Tile.
Tile has been implemented in the Tk core starting with version 8.5,
still somewhere between alpha and beta stage. Once 8.5 is out, and
Python is configured to build against Tk 8.5 (instead of 8.4), it should
Just Work.
Also, while you can get (mostly) native *look*, the feel is absent.
Unless I'm very uninformed, Tile is a theming engine only, and doesn't
implement platform conventions with regard to behavior (the "feel"
part of look and feel).
What do you mean here? Things like keyboard accelerators, menu
placement, and so on? Those things are already natively implemented by
Tk, and the developer just needs to invoke them. Sometimes some
conditional code is required for stuff like keyboard accelerators (the
"tk windowingsytem" command is useful for this), but again, it should
Just Work.
Or am I missing something?
There's conventions for shortcuts and they vary by platform. For
example, home/end do different things on a mac vs on windows.
Scrollbars interact differently, and menu pulldowns operate
differently. To my knowledge, while Tile can replicate the *look* of
these things, it does not help with the interaction.
People often say "look and feel" when they actually just mean look.
It's something that I try to bring up when I hear "look and feel"
being applied to purely visual skinning tools.
Don't think I'm singling out Tk, Gtk has exactly the same problem -
you can make the buttons look native, but it doesn't adjust the
behavior.
Chris Mellon wrote:
>What do you mean here? Things like keyboard accelerators, menu
placement, and so on? Those things are already natively implemented by
Tk, and the developer just needs to invoke them. Sometimes some
conditional code is required for stuff like keyboard accelerators (the
"tk windowingsytem" command is useful for this), but again, it should
Just Work.
Or am I missing something?
There's conventions for shortcuts and they vary by platform. For
example, home/end do different things on a mac vs on windows.
Scrollbars interact differently, and menu pulldowns operate
differently. To my knowledge, while Tile can replicate the *look* of
these things, it does not help with the interaction.
On Windows and Mac, Tk gets the menus correct by default (menu is at the
top of the screen on the Mac, attached to a window on Windows). The Tk
scrollbar is native on the Mac; the Tile scrollbar has problems. On
Windows, the Tile scrollbar maps to Vista or XP or Win32, depending on
Windows version. You need to correctly specify the command-accelerator
in your code (on Windows it's the Control key, on the Mac it's Command),
but assuming you do this, it works fine. I don't use "home" and "end"
keys myself (I think these are more common on Windows than Mac) so I
can't speak to that. Under Tk, keyboard navigation with the tab key
generally works as expected on the Mac, and I assume so for Windows as
well.
The biggest drawback with Tk/Tile on the Mac is that even with Tile
theming, it's still a bit outdated--Tile hooks into some older API's on
the Mac that are more compatible with Tk; for instance, the notebook
tabs look like Jaguar-era tabs (c. 2002). The Tile scrollbar is broken,
but the Tk one works natively.
Tile on Windows looks pretty darn good--I've played with the Windows
Inspection Tool Kit, a well-designed Tcl/Tk application on Windows XP
that uses Tile, and it's 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/...-clam-unix.png or http://www.codebykevin.com/pylocate-tile-x11.png). As far as I know,
Tk/Tile offers reasonable defaults for X, unless you are looking for
specfic integration with a particular environment (i.e. Gnome or KDE);
in that case it's not as acceptable.
>
Don't think I'm singling out Tk, Gtk has exactly the same problem -
you can make the buttons look native, but it doesn't adjust the
behavior.
Tk does a better job with platform-specific defaults and behaviors than
Gtk. When I read complaints about Tk on Windows, it's more on how ugly
Tk is, not that its menus/keyboard behaviors don't work correctly.
--
Kevin Walzer
Code by Kevin http://www.codebykevin.com
In article <7x************@ruckus.brouhaha.com>,
Paul Rubin <http://ph****@NOSPAM.invalidwrote:
Paul Rubin wrote:
The high bandwidth and persistence is not needed for an http
connection, which just gets a form submission once in a while.
Bandwidth isn't really the main issue. The point is
that a lot of state is kept on both ends, making it
much easier to implement a rich user interface.
In fact, the more state is kept, the *less* bandwidth
you need, because communication can make use of shared
context to compress the messages.
--
Greg
Jay Loden wrote:
Like most things involving dynamic client side-javascript code and AJAX
technology, it's a lot harder than you'd like it to be to solve the problem, but
in cases where the Back button is really an issue, it's worth the effort.
So if you're willing to put in a huge amount of time,
effort and ingenuity, it's possible to overcome a
problem that only existed in the first place because
you chose an inappropriate technique for implementing
a user interface...
--
Greg
greg wrote:
Jay Loden wrote:
>Like most things involving dynamic client side-javascript code and AJAX
technology, it's a lot harder than you'd like it to be to solve the problem, but
in cases where the Back button is really an issue, it's worth the effort.
So if you're willing to put in a huge amount of time,
effort and ingenuity, it's possible to overcome a
problem that only existed in the first place because
you chose an inappropriate technique for implementing
a user interface...
Exactly my point. Once you start to involve a complex framework to
handle state and interactions you see less and less advantage to
"desktop web" applications, since it's hard to match the directness and
simplicity of a native GUI.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------
Steve Holden wrote:
greg wrote:
>Jay Loden wrote:
>>Like most things involving dynamic client side-javascript code and AJAX
technology, it's a lot harder than you'd like it to be to solve the problem, but
in cases where the Back button is really an issue, it's worth the effort.
So if you're willing to put in a huge amount of time,
effort and ingenuity, it's possible to overcome a
problem that only existed in the first place because
you chose an inappropriate technique for implementing
a user interface...
Exactly my point. Once you start to involve a complex framework to
handle state and interactions you see less and less advantage to
"desktop web" applications, since it's hard to match the directness and
simplicity of a native GUI.
This is true, you certainly won't get an argument from me! I've spent a lot of
time explaining to people why a real-time GUI and the HTTP protocol don't get
along. Event-driven programming using a request/response framework == square
peg, round hole. But, it seems like the benefits of a web-based GUI make for a
big hammer, so people keep pounding away at that square peg ;)
On the negative side, developing any sort of non-trivial web application is
fraught with problems:
* language limitations of javascript/(X)HTML
* highly varied implementations of CSS, HTML, js
* browser-specific bugs (and features)
* no real IDE to speak of
* no way to receive events without some very ugly hacks or polling
However, there are also major benefits, which is why you see so many companies
and individuals jumping on the Web 2.0 train:
* lower barrier of entry to creating a GUI (compare how quickly
most people can turn out a form in HTML versus creating a GUI
with the same entry fields)
* cross-platform (yes, you have to support multiple browsers,
but once you do, it works on the majority of platforms. For
instance, support Firefox means OS X, Linux, Windows, etc all
supported at once
* Convenience for the end user - no need to install anything to
use your software, which entices a lot more people to use it.
This is less of a valid concern in an enterprise environment, but
it still attracts people to feel they don't need to install
something locally
* available from multiple machines without extra effort for the user
* Familiar interface (in most cases at least) to the user; more
comfortable for them, less they need to learn.
* Potentially available on many new platforms such as the iPhone,
with some presentation tweaks. Good luck writing a cross-platform
GUI app that runs on all the major OSes and mobile devices using a
standard GUI toolkit etc. (or shipping the Python interpreter with
an app intended for a Windows Mobile device, for instance)
Your point is absolutely valid, though. I think the web 2.0 craze has people
doing some things that just don't really make sense (like implementing Photoshop
in a browser - what's next, AutoCAD?). The bottom line is that there are many
many things that a native GUI is much better at and more than likely always will
be. If you're developing an application, it's important to stop and ask yourself
why it needs to be a web-based application, and unless you've got compelling
reasons, the native GUI should win out.
-Jay This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Hans-Joachim Widmaier |
last post by:
Hi all.
Handling files is an extremely frequent task in programming, so most
programming languages have an abstraction of the basic files offered by
the underlying operating system. This is...
|
by: John Marshall |
last post by:
Hi,
Does anyone see a problem with doing:
data = file("tata").read()
Each time this is done, I see a new file
descriptor allocated (Linux) but not
released.
1) Will there ever be a point...
|
by: pinkfloydhomer |
last post by:
I want to scan a file byte for byte for occurences of the the four byte
pattern 0x00000100. I've tried with this:
# start
import sys
numChars = 0
startCode = 0
count = 0
|
by: Conrad F |
last post by:
Hello all,
I am waiting for receipt of files in a directory. I use the
FileSystemWatcher to detect when files arrive in said folder. I need
to read the data from these files ASAP but the files...
|
by: Ken Varn |
last post by:
I am working in managed C++. I have a Mutex object in which I need to
replace the Handle property with a new handle. The new handle is being
constructed using Win32 CreateMutex call. I need to...
|
by: Daniel |
last post by:
I have an winform application that uses System.IO.StreamReader and
Serializer.Deserialize to load some data from a file, if any error is
detected in the file a new file should be written to the...
|
by: Daniel |
last post by:
does the windows file handle change?
are file handles unique to the whole operating system or just the current
directoy? if a file is opened then closed then opened again, does the file
handle...
|
by: nicolasg |
last post by:
Hi,
I'm trying to open a file (any file) in binary mode and save it inside
a new text file.
After that I want to read the source from the text file and save it
back to the disk with its...
|
by: Yang |
last post by:
Hi, I'm experiencing a problem when trying to close the file descriptor
for a socket, creating another socket, and then closing the file
descriptor for that second socket. I can't tell if my issue...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
