I'm also in a similar predicament starting to look at Python for theChris said: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.
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.
My out of the box firefox install simply denies the operation and
raises a javascript error.
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?
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.
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.
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.
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.
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 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.
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.
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.
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.
It's not even that easy in wxPython is you choose the wrong widget - IChris said: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.
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.
Chris Mellon said: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.
What you're calling "slickness" is what other people call "usable".
My out of the box firefox install simply denies the operation and
raises a javascript error.
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?
As phishing attacks become more common, browsing are restricting the
ability to remove or modify chrome.
It depends on your target audience and deployment arena. The context
is cross platform applications,
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.
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 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.
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?
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.
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.
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.
"Chris Mellon" <[email protected]> writes:
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?
Chris Mellon said:You repeatedly have used the word "slickness" as a pejorative. I find
that offensive and it's insulting to users. When I write applications,
I want the interface to be as smooth and trouble free as possible,
As a matter of time spent in development, I do not find that
non-trivial UIs are significantly easier to develop using web
interfaces.
As a matter of respect for the user, I'm not going to tell them to use
a trivial UI if a non-trivial one will save them time, learning
effort, or frustration. In order to make this decision, I like to work
with the people actually using it and watch them at work. To see what
kind of extra steps they have to take and where I can save them time
or inaccuracy or frustration.
It's a perjorative when it's done for its own sake and doesn't really
help the user. This happens a lot. When it helps the user, as it
sometimes does, then it's not perjorative.
That's possibly true, but a lot of the time, trivial interfaces are
enough. Look at Google search, one of the most complex apps ever
built (tens or hundreds of MLOC, massive distributed crawler
infrastructure, 100's of PhD's figuring out the algorithms, etc.) but
its interface is simple HTML that you would probably call trivial. It
is quite possibly the most popular application in the world.
Right. Obviously this has to be decided according to the specific
needs of the application. A lot of times, trivial interfaces are
easier to learn than nontrivial ones, precisely because they are
trivial so there is less to learn. Again look at Google search for an
example.
Also, at least for in-house applications, while the user's time counts
(since their time costs your customer money), your development time
and deployment effort also costs money that comes from exactly the
same place, so you have to take into consideration the number of
users, amount of time they will spend using the program, just how much
of that time (if any) a fancier interface will save, etc.
.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
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
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.
.
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.
Paul Rubin said: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 said: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)
greg said: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.
Cameron said:While those with an artistic eye
assure me the simplest Tkinter programs look worse
that corresponding ones built with any other toolkit,
they behave the most coherently in regards to resizing
and so on.
"Look worse" can be addressed through extensive means: through theming
(via Tile, which can now be easily used in Tkinter; see
http://tkinter.unpy.net/wiki/TileWrapper); and through other aspects of
UI design, such as color, fonts, and even use of icons. A pyGtk or
wxPython application that uses old-school Gnome icons, for instance,
will look ugly. It's quite possible to make an attractive Tkinter
application using modern, stylish icons that even blends in reasonably
well on a specific platform (I've done it).
--
Chris said:On 8/8/07, Kevin Walzer <[email protected]> wrote:
Using Tile, of course, loses you the first major benefit of Tk - that
it's already included in the standard library. So in this sense it's
still "ugly old school look and feel" vs "no external dependencies",
which is the swing decision for many people. People who prefer the Tk
API, of course, will be happy to use Tile.
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).
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.