Future standard GUI library

[Beinan Li]

Not sure if this is the right place to talk about this. Even less sure if I can

move this discussion to tkinter list, so here I am...

I know this may sound a silly question because no one can see the future. But ...

Do you think tkinter is going to be the standard python built-in gui solution as long as python exists?

I couldn't help but wonder if wx or PySide receives better py2 and py3 support, or anything else that prevent

them from getting into the standard python distributions, whether or not this scene could start to shift ...

I believe this "which one of tkinter, wx, qt, is the best gui toolkit for python" flame war has been going on

for ages. I love the fact that python ships a built-in gui solution which makes shipping a pure-python desktop 

application a viable choice. But tkinter does not appear to be the most time-saving way to write a gui app.

The layout designer support, for one, is next to zero. I tried many 3rd-party designers

and loved PAGE (http://page.sourceforge.net) for a few minutes, then came the author's comment:

"For release 4.0, I spent about two months working with the “Theme” part of Ttk and have had only partial success. I now believe that the “Theme” part of Ttk is really a very poor piece of software at all levels - concept, implementation, and especially documentation. My guess is if it had been well documented it would have been recognized by even the author as junk. I find it hard to believe that the people who control Tcl/Tk allowed it in the code base. I continue to support ttk because of the paned window, notebook and treeview widgets."

And ttk seems to be a major attraction that keeps people coming back to tk for the looks. This worries me very much

about whether I should start a gui app using python. Because if ttk is not a "mature" technology, I'd avoid premature adoption.

If ttk is out of the question, tkinter will be too. I'd then be forced to use a 3rd-party solution like wx or qt, which I really don't want to see.

Anyways, this is just some concerns that I hope someone may give his/her opinions about.

Thanks!

[Kevin Walzer]

Hello,

On 5/18/13 10:03 AM, Beinan Li wrote:

> I know this may sound a silly question because no one can see the
> future. But ...
> Do you think tkinter is going to be the standard python built-in gui
> solution as long as python exists?

I don't see any significant clamoring among the Python core developers
to make a change.

>
> I couldn't help but wonder if wx or PySide receives better py2 and py3
> support, or anything else that prevent
> them from getting into the standard python distributions, whether or not
> this scene could start to shift ...

I am not going to engage in the old UI toolkit flame ware; I will limit
myself to factual observations and a few opinions about Tkinter without
placing it against other toolkits.

Python has the PEP process for suggesting changes to the core language
and libraries. Changing the default UI toolkit would require someone to
submit a proposal, get it approved, provide the implementation, and
commit to maintaining the implementation over the long term. You propose
it, you own it.

Thus far no one has done this. I would think the only person who would
be in a position to propose wxPython would be Robin Dunn since he is the
primary copyright holder, and to my knowledge he has never done so. As
for Pyside, it was not part of the transition of Qt from Nokia to Digia,
and so it appears to be orphaned. PyQt might be an alternative, but I
don't think Phil Thompson would ever submit it, as it would likely
affect his livelihood.

Given these facts, it's safe to say that Tkinter will remain the default
GUI toolkit in the stdlib for some years to come.

>
> I believe this "which one of tkinter, wx, qt, is the best gui toolkit
> for python" flame war has been going on
> for ages. I love the fact that python ships a built-in gui solution
> which makes shipping a pure-python desktop
> application a viable choice. But tkinter does not appear to be the most
> time-saving way to write a gui app.
> The layout designer support, for one, is next to zero. I tried many
> 3rd-party designers
> and loved PAGE (http://page.sourceforge.net) for a few minutes, then
> came the author's comment:

PAGE strikes me as an odd choice for a Python developer to develop a Tk
UI. It's a descendent of the old Visual Tcl tool, and is run from Tcl
and not Python. VTcl was always famous for producing a huge pot of
spaghetti UI code that couldn't be easily modified outside the tool. I
have also tried many Tk UI tools including VTcl, SpecTcl, and the
orphaned tool from ActiveState, and have concluded that writing my own
code is both simpler and faster. As always, your mileage may vary.

>
> "For release 4.0, I spent about two months working with the �Theme� part
> of Ttk and have had only partial success. I now believe that the �Theme�

> part of Ttk is really a very poor piece of software at all levels -
> concept, implementation, and especially documentation. My guess is if it
> had been well documented it would have been recognized by even the
> author as junk. I find it hard to believe that the people who control
> Tcl/Tk allowed it in the code base. I continue to support ttk because of
> the paned window, notebook and treeview widgets."

The implementation of the ttk widgets is quite complex--that, in turn,
makes their documentation complex, and the complexity is a drawback.
It's hard to customize the ttk themes, especially compared to
customizing standard Tk widgets. I'm one of the core Tk developers, and
I don't fully understand the themed widgets' internals or how to
customize them. But it's not fair to say that they are "junk." The
author of PAGE may think so, but many would disagree. I think the
widgets work quite well, especially if used in their default mode. It's
difficult to overstate the improvement in the look and feel of my Tk
apps on the Mac when I switched to using the themed widgets.

>
> And ttk seems to be a major attraction that keeps people coming back to
> tk for the looks. This worries me very much
> about whether I should start a gui app using python. Because if ttk is
> not a "mature" technology, I'd avoid premature adoption.
> If ttk is out of the question, tkinter will be too. I'd then be forced
> to use a 3rd-party solution like wx or qt, which I really don't want to see.

ttk is a mature technology. The initial specification, code, and docs
were developed by Joe English nearly a decade ago (see
http://tktable.sourceforge.net/tile/tile-tcl2004.pdf), and they had been
accepted into Tcl/Tk's core in version 8.5 (released in 2007). The
earliest work on integrating these widgets into Python began in 2008,
and they were formally released in 2010. I would say that ttk is
mature, stable, and unlikely to undergo radical change in the future.

Guilherme Polo has done superb work in integrating the themed widgets
into Python--it's the most significant UI advance in Python's stdlib in
years. You are quite safe in developing against this API, unless your
taste simply does not run to using the ttk widgets.

Hope this helps,
Kevin

--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

[Terry Jan Reedy]

On 5/18/2013 10:03 AM, Beinan Li wrote:
> Not sure if this is the right place to talk about this.

It is.

> Even less sure if I can
> move this discussion to tkinter list,

The idea of replacing tkinter is not about improving tkinter ;-).

> Do you think tkinter is going to be the standard python built-in gui
> solution as long as python exists?

AT the moment, there is nothing really comparable that is a realistic
candidate to replace tkinter. Tkinter is a tcl-based c gui library. wx
and qt4 are gui application frameworks that include a gui library -- and
much more that duplicate part of Python's stdlib. They, and consequently
their Python wrappers, are too big. That is quite aside from the fact
that the authors of the wrappers have good reason to not donate their
code, but stay independent.

PyGui was designed as a gui library comparable to tkinter and a possible
replacement. But according to the web page, it is still not completely
ready for py 3 (the last update was July 2011).
http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

I think a tkinter replacement should be written for at least 3.4+, so it
can use the new 3.3 unicode implementation and use or at least integrate
with the new 3.4 event loop that will be part of the planned new async
library.

One test for any new gui library is whether idle can be rewritten in it.
It heavily uses the tag features of the tk text widget.

TJR

[Steven D'Aprano]

On Sat, 18 May 2013 10:03:02 -0400, Beinan Li wrote:

> Do you think tkinter is going to be the standard python built-in gui
> solution as long as python exists?

Probably.

> I couldn't help but wonder if wx or PySide receives better py2 and py3
> support, or anything else that prevent them from getting into the
> standard python distributions, whether or not this scene could start to
> shift ...

One of the major issues preventing projects being added to the standard
library is the maintenance schedule. Python's schedule for new releases
is quite conservative and slow. If, say, wxPython was added to the std
lib, it would have to follow Python's schedule:

* most backwards incompatible changes would be forbidden;

* those that are allowed would require a minimum of two major releases
(three years) before removing functionality;

* about four bug-fix releases (I think?) per year.

If a project is used to (say) weekly releases, dropping down to Python's
schedule can be rather painful.

Once something has been added to the standard library, it more or less
has to have a stable API, become conservative about changes, and care
more about backwards-compatibility than new features. Stability and
consistency become paramount. Many excellent, popular packages cannot
live under those restrictions, and so will never be part of the standard
library.

Tkinter is good in this regard, because it is a wrapper around Tk/Tcl,
which is equally stable and conservative as Python. Possibly even more so.



--
Steven

[Beinan Li]

Thanks for the clarification, Kevin.

It's nice to have a tk dev standing out :-)

This more or less convinced me about the trend.

I also agree that it would be probably a simpler and more maintainable way to write my own tk(inter) code than using any existing 3rd-party designers.

Beinan

On Sat, May 18, 2013 at 1:40 PM, <python-li...@python.org> wrote:

---------- Forwarded message ----------
From: Kevin Walzer <k...@codebykevin.com>
To: pytho...@python.org
Cc: 
Date: Sat, 18 May 2013 11:32:04 -0400
Subject: Re: Future standard GUI library
Hello,

On 5/18/13 10:03 AM, Beinan Li wrote:

I know this may sound a silly question because no one can see the
future. But ...

Do you think tkinter is going to be the standard python built-in gui
solution as long as python exists?

I don't see any significant clamoring among the Python core developers to make a change.

I couldn't help but wonder if wx or PySide receives better py2 and py3
support, or anything else that prevent
them from getting into the standard python distributions, whether or not
this scene could start to shift ...

I am not going to engage in the old UI toolkit flame ware; I will limit myself to factual observations and a few opinions about Tkinter without placing it against other toolkits.

Python has the PEP process for suggesting changes to the core language and libraries. Changing the default UI toolkit would require someone to submit a proposal, get it approved, provide the implementation, and commit to maintaining the implementation over the long term. You propose it, you own it.

Thus far no one has done this. I would think the only person who would be in a position to propose wxPython would be Robin Dunn since he is the primary copyright holder, and to my knowledge he has never done so. As for Pyside, it was not part of the transition of Qt from Nokia to Digia, and so it appears to be orphaned. PyQt might be an alternative, but I don't think Phil Thompson would ever submit it, as it would likely affect his livelihood.

Given these facts, it's safe to say that Tkinter will remain the default GUI toolkit in the stdlib for some years to come.

I believe this "which one of tkinter, wx, qt, is the best gui toolkit
for python" flame war has been going on
for ages. I love the fact that python ships a built-in gui solution
which makes shipping a pure-python desktop
application a viable choice. But tkinter does not appear to be the most
time-saving way to write a gui app.
The layout designer support, for one, is next to zero. I tried many
3rd-party designers
and loved PAGE (http://page.sourceforge.net) for a few minutes, then
came the author's comment:

PAGE strikes me as an odd choice for a Python developer to develop a Tk UI. It's a descendent of the old Visual Tcl tool, and is run from Tcl and not Python. VTcl was always famous for producing a huge pot of spaghetti UI code that couldn't be easily modified outside the tool. I have also tried many Tk UI tools including VTcl, SpecTcl, and the orphaned tool from ActiveState, and have concluded that writing my own code is both simpler and faster. As always, your mileage may vary.

"For release 4.0, I spent about two months working with the “Theme” part
of Ttk and have had only partial success. I now believe that the “Theme”

part of Ttk is really a very poor piece of software at all levels -
concept, implementation, and especially documentation. My guess is if it
had been well documented it would have been recognized by even the
author as junk. I find it hard to believe that the people who control
Tcl/Tk allowed it in the code base. I continue to support ttk because of
the paned window, notebook and treeview widgets."

[llanitedave]

I'm curious about how commonly tkinter is actually used among Python app developers as compared to wx, Pyside, or PyQT. I get the impression that more distributed apps are built with wxPython, at least, than tkinter. My impression is far from actual knowledge, of course.

[Kevin Walzer]

On 5/18/13 11:01 PM, llanitedave wrote:
> I'm curious about how commonly tkinter is actually used among Python app developers as compared to wx, Pyside, or PyQT. I get the impression that more distributed apps are built with wxPython, at least, than tkinter. My impression is far from actual knowledge, of course.
>

I have two commercial apps developed with Tkinter:

http://www.codebykevin.com/phynchronicity.html
http://www.codebykevin.com/quickwho.html

--Kevin

[Vito De Tullio]

Terry Jan Reedy wrote:

>> Do you think tkinter is going to be the standard python built-in gui
>> solution as long as python exists?
>

> AT the moment, there is nothing really comparable that is a realistic
> candidate to replace tkinter.

FLTK? (http://www.fltk.org/index.php)

--
ZeD

[Terry Jan Reedy]

tkinter is the Python wrapper of the tk library, just as wxpython is the
python wrapper of the wx library. I do not see a py-fltk wrapper.

[Robert Kern]

It exists, but it's really old.

http://pyfltk.sourceforge.net/

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Kevin Walzer]

On 5/20/13 1:04 AM, Vito De Tullio wrote:
> FLTK? (http://www.fltk.org/index.php)

FLTK is even uglier than non-themed Tkinter: non-native on every
platform. Tkinter wraps native widgets on MacOS and WIndows, but FLTK
draws its own widgets everywhere.

[Grant Edwards]

http://pyfltk.sourceforge.net/

--
Grant Edwards grant.b.edwards Yow! Is it 1974? What's
at for SUPPER? Can I spend
gmail.com my COLLEGE FUND in one
wild afternoon??

[Wolfgang Keller]

> >>>> Do you think tkinter is going to be the standard python built-in
> >>>> gui solution as long as python exists?
> >>>
> >>> AT the moment, there is nothing really comparable that is a
> >>> realistic candidate to replace tkinter.
> >>
> >> FLTK? (http://www.fltk.org/index.php)
> >
> > tkinter is the Python wrapper of the tk library, just as wxpython
> > is the python wrapper of the wx library. I do not see a py-fltk
> > wrapper.
>
> It exists, but it's really old.
>
> http://pyfltk.sourceforge.net/

And it's imho definitely not "native" (in terms of "look and feel") on
*any* operating system, not even on Linux.

In fact it's SGI's Irix Forms re-implemented, afaik.

Sincerely,

Wolfgang

[Wolfgang Keller]

> I know this may sound a silly question because no one can see the
> future. But ...
> Do you think tkinter is going to be the standard python built-in gui
> solution as long as python exists?

"Standard built-in" maybe, but by far most people who need a GUI for an
actual application will keep using something else.

> I couldn't help but wonder if wx or PySide receives better py2 and py3
> support, or anything else that prevent
> them from getting into the standard python distributions, whether or
> not this scene could start to shift ...

Didn't Pyside have serious trouble recently, requiring a reanimation of
the project?

> I believe this "which one of tkinter, wx, qt, is the best gui toolkit
> for python" flame war has been going on
> for ages.

If (Py)Qt wasn't so freaking fat, it might be the best.
If wxPython had a more pythonic (and stable?) API, it might be the best.
If PyGTK was more native on Windows and native at all on MacOS X, it
might be the best.
If PyGUI was more extensive, it might be the best.

> This worries me very much about whether I should start a gui app
> using python.

What other open-source cross-platform programming language choices do yo
have.

Java? For GUIs? Excuse me while I vomit.

C++? As a language for human beings? Oops, I have to throw up again.

Sincerely,

Wolfgang

[Chris Angelico]

On Wed, May 22, 2013 at 11:42 PM, Wolfgang Keller <feli...@gmx.net> wrote:
> What other open-source cross-platform programming language choices do yo
> have.
>
> Java? For GUIs? Excuse me while I vomit.
>
> C++? As a language for human beings? Oops, I have to throw up again.

I personally like using Pike and GTK, so if I were to try a
cross-platform Python GUI project, I'd probably give PyGTK a shot. But
there's another option that is available to every platform and
(practially) every high level language: the web browser. Make your app
serve HTTP and do up your UI in HTML5/CSS3 - your facilities are
pretty extensive. Plus you get networking support for free! Obviously
this option isn't for everyone, but don't discount it out of hand.

ChrisA

[llanitedave]

I've been thinking about that myself for some future app ideas. If you have a stand-alone app working from your web browser, don't you need an embedded web server to utilize the file system? Is a system like Django for an app overkill? Or is its embedded development server underkill for a single-user browser-based application?

[Fábio Santos]

On 23 May 2013 03:39, "llanitedave" <llani...@veawb.coop> wrote:
>
> On Wednesday, May 22, 2013 7:24:15 AM UTC-7, Chris Angelico wrote:
> > On Wed, May 22, 2013 at 11:42 PM, Wolfgang Keller <feli...@gmx.net> wrote:

...

> > there's another option that is available to every platform and
> > (practially) every high level language: the web browser. Make your app
> > serve HTTP and do up your UI in HTML5/CSS3 - your facilities are
> > pretty extensive. Plus you get networking support for free! Obviously
> > this option isn't for everyone, but don't discount it out of hand.
> >
> > ChrisA
>
> I've been thinking about that myself for some future app ideas.  If you have a stand-alone app working from your web browser, don't you need an embedded web server to utilize the file system?  Is a system like Django for an app overkill?  Or is its embedded development server underkill for a single-user browser-based application?

> --
> http://mail.python.org/mailman/listinfo/python-list

JavaScript has this:

http://appjs.org/

It's a node.js server app serving a folder of plain old HTML files to a chrome embedded browser.

You can code in a node.js server using anything you like, serve requests for your client app (or use the server code directly, you can just put the functions you would like to share with the client in the window object), etc.

I'm using it for a peer to peer configurable application. To do that I serve up the web application for me and my peers (by using a regular server instead of the fake server it comes with), and the browser is just a client which can connect wherever I want it to.

Someone should fork this and make it work in python.

[Chris Angelico]

On Thu, May 23, 2013 at 4:43 PM, Fábio Santos <fabiosa...@gmail.com> wrote:
> On 23 May 2013 03:39, "llanitedave" <llani...@veawb.coop> wrote:

>> --
>> http://mail.python.org/mailman/listinfo/python-list
>
> JavaScript has this:
>
> http://appjs.org/
>
> It's a node.js server app serving a folder of plain old HTML files to a
> chrome embedded browser.
>
> You can code in a node.js server using anything you like, serve requests for
> your client app (or use the server code directly, you can just put the
> functions you would like to share with the client in the window object),
> etc.

Many high level languages today come with simple HTTP server modules.
They may not scale "to infinity and beyond", but they'll work fine for
a single-user system using a browser for its UI. Chances are they'll
do well for everything up to a single CPU core. Depends on the
language and library, of course.

ChrisA

[Carlos Nepomuceno]

You don't! If your app needs local content just use a regular open() (or your browser) to read the files and render them as you see fit.

For remote content you just need the 'urllib2' module or something like 'requests' module to get the data.

----------------------------------------
> Date: Wed, 22 May 2013 19:31:55 -0700

> Subject: Re: Future standard GUI library

> From: llani...@veawb.coop
[...]

>
> I've been thinking about that myself for some future app ideas. If you have a stand-alone app working from your web browser, don't you need an embedded web server to utilize the file system? Is a system like Django for an app overkill? Or is its embedded development server underkill for a single-user browser-based application?

> --
> http://mail.python.org/mailman/listinfo/python-list

[Chris Angelico]

On Thu, May 23, 2013 at 4:58 PM, Carlos Nepomuceno
<carlosne...@outlook.com> wrote:
> You don't! If your app needs local content just use a regular open() (or your browser) to read the files and render them as you see fit.
>
> For remote content you just need the 'urllib2' module or something like 'requests' module to get the data.

BTW, forgot the link. The part you DO need is something like this:

http://docs.python.org/3/library/http.server.html

It takes care of the irrelevant and lets you just write your app. The
same sort of thing is available in quite a few languages. Great for
knocking something together quickly; not designed for thousand-TPS web
servers.

ChrisA

[Fábio Santos]

It would be way more practical to have an embedded browser. Appjs doesn't even occupy a port on the client. We could totally benefit from that. Django applications practically make themselves.

On 23 May 2013 08:02, "Carlos Nepomuceno" <carlosne...@outlook.com> wrote:

You don't! If your app needs local content just use a regular open() (or your browser) to read the files and render them as you see fit.

For remote content you just need the 'urllib2' module or something like 'requests' module to get the data.

----------------------------------------
> Date: Wed, 22 May 2013 19:31:55 -0700
> Subject: Re: Future standard GUI library
> From: llani...@veawb.coop
[...]
>

> I've been thinking about that myself for some future app ideas. If you have a stand-alone app working from your web browser, don't you need an embedded web server to utilize the file system? Is a system like Django for an app overkill? Or is its embedded development server underkill for a single-user browser-based application?

> --
> http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list

[Wolfgang Keller]

> But there's another option that is available to every platform and
> (practially) every high level language: the web browser. Make your app
> serve HTTP and do up your UI in HTML5/CSS3 - your facilities are
> pretty extensive. Plus you get networking support for free! Obviously
> this option isn't for everyone, but don't discount it out of hand.

Both the concept and actually implemented examples of so-called "web
applications" prove that they are just plain garbage and hopelessly
unusable for anything remotely resembling actual screenwork.

HTML forms may be at best useful for "web shops", but for actual
screenwork, HTML is not a valid GUI, no matter how much javascript you
add to it.

Sincerely,

Wolfgang

[Chris Angelico]

All depends on your requirements. For the Yosemite Project, I wanted
the networking aspect, so the web browser UI was a good one. It's been
working beautifully for... what, four or six years now, I think; and
it's just a few pages of Python.

ChrisA

[Grant Edwards]

On 2013-05-23, Wolfgang Keller <feli...@gmx.net> wrote:
>> But there's another option that is available to every platform and
>> (practially) every high level language: the web browser. Make your app
>> serve HTTP and do up your UI in HTML5/CSS3 - your facilities are
>> pretty extensive. Plus you get networking support for free! Obviously
>> this option isn't for everyone, but don't discount it out of hand.
>
> Both the concept and actually implemented examples of so-called "web
> applications" prove that they are just plain garbage and hopelessly
> unusable for anything remotely resembling actual screenwork.

What is "screenwork"?

--
Grant Edwards grant.b.edwards Yow! Am I elected yet?
at
gmail.com

[Wolfgang Keller]

> > Both the concept and actually implemented examples of so-called "web
> > applications" prove that they are just plain garbage and hopelessly
> > unusable for anything remotely resembling actual screenwork.
> >
> > HTML forms may be at best useful for "web shops", but for actual
> > screenwork, HTML is not a valid GUI, no matter how much javascript
> > you add to it.
>
> All depends on your requirements.

Obivously, if your requirements are to be compliant with latest IT
management fads and to not give a darn for end-user productivity or
even legal requirements for screen workplace ergonomics...

> For the Yosemite Project, I wanted the networking aspect, so the web
> browser UI was a good one.

From the description this looks like a simble database CRUD
application. Somethign like that is definitely easier to implement and
to deploy and a *lot* more functional with any of the RAD frameworks
available for Python.

And just like HTML never was a valid GUI framework and never will be
one, HTTP will never be a suitable transport layer for a RPC protocol.

Sincerely,

Wolfgang

[Roy Smith]

In article <20130526194310.9cdb...@gmx.net>,

Wolfgang Keller <feli...@gmx.net> wrote:

> HTTP will never be a suitable transport layer for a RPC protocol.

What, in particular, is wrong with HTTP for doing RPC? RPC is pretty
straight-forward. Take this method, run it over there, with these
arguments, and give me back the result. HTTP handles that just fine,
with your choice of XML, JSON, or whatever turns you on for the content
encoding.

There are protocols that are more efficient (mostly binary ones like
Thrift and Protocol Buffers), but for a lot of things, the simplicity
and convenience of HTTP is worth than the efficiency hit. It's really
nice to be able to slap together HTTP components like load balancers and
caches by just editing a few config files.

[Carlos Nepomuceno]

----------------------------------------
> From: feli...@gmx.net

> Subject: Re: Future standard GUI library

> Date: Sun, 26 May 2013 19:43:10 +0200
> To: pytho...@python.org
[...]

> one, HTTP will never be a suitable transport layer for a RPC protocol.
>
> Sincerely,
>
> Wolfgang

Please give me an example of a "suitable transport layer for a RPC protocol".

[Chris Angelico]

On Mon, May 27, 2013 at 3:43 AM, Wolfgang Keller <feli...@gmx.net> wrote:
>> For the Yosemite Project, I wanted the networking aspect, so the web
>> browser UI was a good one.
>
> From the description this looks like a simble database CRUD
> application. Somethign like that is definitely easier to implement and
> to deploy and a *lot* more functional with any of the RAD frameworks
> available for Python.
>
> And just like HTML never was a valid GUI framework and never will be
> one, HTTP will never be a suitable transport layer for a RPC protocol.

No, it's basically a modified version of a file browser; you get a
directory listing, you can browse subdirectories, and selecting a file
causes an action to happen on the server. You also have some "action
buttons" that provide a measure of control: click a button and
something is done (eg a key is pressed, or a 'killall' command is
fired). The browser works just fine.

ChrisA

[Michael Torrie]

On 05/26/2013 11:43 AM, Wolfgang Keller wrote:
> And just like HTML never was a valid GUI framework and never will be
> one, HTTP will never be a suitable transport layer for a RPC protocol.

On good thing web development has brought us is the knowledge that
modularization and layers are a brilliant idea. Your back end exposes
services and business logic, and your front end can be in HTMLv5 and
Javascript, or QtQuick, PyGTK, or Visual Studio. If you do need a
native interface, it's a heck of a lot easier to rewrite just the
frontend then the entire stack. Who cares how the RPC is done; that's
an implementation detail. HTTP does happen to work well though. Why do
you say it is not suitable?

> From the description this looks like a simble database CRUD
> application. Somethign like that is definitely easier to implement and
> to deploy and a *lot* more functional with any of the RAD frameworks
> available for Python.

Chuckle. Simple CRUD, eh. Almost all apps involve database CRUD
interactions. And often in highly complex ways using business logic.

Maybe it would have been faster to develop, but ultimately less useful
and require more development time in the long run. suppose I now want
the app natively on my phone (because that's all the rage). It's an
iPhone. Oh. Apple doesn't support Python. Okay, rewrite the works,
including business logic, in Objective C. Now I want it on my android
phone. Oops rewrite the stack again in Java.

Since his application by nature is network oriented (client/server I
presume since he mentions multiple users), sticking it on a web server
and having the front end be separate (be it HTML or not) gives him the
flexibility to rapidly build native "screenable" UIs for his app on any
platform he chooses, something your philosophy does not allow for.

[Roy Smith]

In article <mailman.2193.1369597...@python.org>,

Michael Torrie <tor...@gmail.com> wrote:

> On good thing web development has brought us is the knowledge that
> modularization and layers are a brilliant idea.

Modularization and layers were a brilliant idea long before the web came
around.

[Ian Foote]

On 26/05/13 20:41, Michael Torrie wrote:
> On 05/26/2013 11:43 AM, Wolfgang Keller wrote:

<snip>

>
> Maybe it would have been faster to develop, but ultimately less useful
> and require more development time in the long run. suppose I now want
> the app natively on my phone (because that's all the rage). It's an
> iPhone. Oh. Apple doesn't support Python. Okay, rewrite the works,
> including business logic, in Objective C. Now I want it on my android
> phone. Oops rewrite the stack again in Java.
>

Kivy (http://kivy.org) is a python library that can be used to write
python apps for Linux, Windows, MaxOSX, Android and IOS.

Regards,
Ian F

[Michael Torrie]

True. Though it seems like it fell out of fashion for a long time. I
went to school before the advent of web development and though we talked
about modularization and coupling in software engineering, really it was
all rather monolithic. Web development changed our focus back to where
it should have been all along.

[Chris Angelico]

On Mon, May 27, 2013 at 5:41 AM, Michael Torrie <tor...@gmail.com> wrote:
> Chuckle. Simple CRUD, eh. Almost all apps involve database CRUD
> interactions. And often in highly complex ways using business logic.

Right. Sturgeon's Law of Applications.

ChrisA

[Wolfgang Keller]

> Your back end exposes services and business logic, and your front end
> can be in HTMLv5 and Javascript, or QtQuick, PyGTK, or Visual
> Studio. If you do need a native interface, it's a heck of a lot
> easier to rewrite just the frontend then the entire stack.

Any decent database CRUD framework will allow to implement the
application model as "behaviour complete" domain objects, with a
persistence layer totally independent from the GUI layer. In many
Python RAD frameworks, this is done using SQLalchemy.

> Who cares how the RPC is done;

As an end-user I do care for how much an application makes we watch the
cursor animation.

> that's an implementation detail. HTTP does happen to work well
> though. Why do you say it is not suitable?

Because from personal experience I know too well that it does definitely
not "work well though".

> suppose I now want the app natively on my phone (because that's all
> the rage). It's an iPhone. Oh. Apple doesn't support Python.
> Okay, rewrite the works, including business logic, in Objective C.
> Now I want it on my android phone.

Those are gadgets, not work tools.

Sincerely,

Wolfgang

[Wolfgang Keller]

> HTTP handles that just fine, with your choice of XML,

And XML is definitely not suitable as a marshalling format for a RPC
protocol.

XML-over-HTTP is a true cerebral flatulance of some hopelessly clueless
moron.

Sincerely,

Wolfgang

[Michael Torrie]

Hmm. Well I think there are a lot of very smart developers that are
using xml to marshal rpc and it's working fine. So either they know
something you don't, or maybe they are just busy making code that
functions and functions pretty well, instead of making inflammatory
statements on USENET. Sure XML is not very efficient or compact, but it
does handle unicode intrinsically through standard encodings, and a
plethora of parsers makes it a decent choice. It's like what they say
about the book: "for though it has many omissions and contains much that
is apocryphal, or at least wildly inaccurate, it scores over the older,
more pedestrian work in two important respects.
First, it is slightly cheaper; and second, it has the words Don't Panic
inscribed in large friendly letters on its cover."

I've used LBER-encoded wire protocol before, and it was fine, but hard
to debug on the wire, and didn't haven anything in it to handle unicode
except base64-encoding utf8 byte streams.

That said, all this reminds me of a good saying, "XML is like violence;
if it doesn't solve your problem you're not using enough of it."
Fortunately none of this really matters. Who cares what is used to
marshall RPC over the wire? As a developer I certainly don't care. I'll
use whatever is convenient and well supported. One reason I do like
xmlrpc, though, because it's pretty much available to all web-based back
ends for free (or at little cost) and you don't need to set up a special
server process to handle it, or deal with odd port numbers that might be
blocked, doing ssl yourself, etc. Having HTTP do the transport frees me
from having to worry about all that, since in the case of a web app I am
already using a web server.

[Michael Torrie]

On 05/27/2013 09:22 AM, Wolfgang Keller wrote:
>> suppose I now want the app natively on my phone (because that's all
>> the rage). It's an iPhone. Oh. Apple doesn't support Python.
>> Okay, rewrite the works, including business logic, in Objective C.
>> Now I want it on my android phone.
>
> Those are gadgets, not work tools.

As a professional programmer I'm afraid you're going to soon find
yourself out of work if you really see things that way. I honestly used
to feel that way about graphical user interfaces.

[Chris Angelico]

On Tue, May 28, 2013 at 3:13 AM, Michael Torrie <tor...@gmail.com> wrote:
> On 05/27/2013 09:31 AM, Wolfgang Keller wrote:

> Hmm. Well I think there are a lot of very smart developers that are
> using xml to marshal rpc and it's working fine. So either they know
> something you don't, or maybe they are just busy making code that
> functions and functions pretty well, instead of making inflammatory
> statements on USENET. Sure XML is not very efficient or compact, but it
> does handle unicode intrinsically through standard encodings, and a
> plethora of parsers makes it a decent choice.

I'll use XML when I have to, but if I'm inventing my own protocol,
nope. There are just too many quirks with it. How do you represent an
empty string named Foo?

<Foo></Foo>

or equivalently

<Foo/>

How do you represent an empty list named Foo? The same way. How do you
represent an empty dict/mapping named Foo? Lemme look up my
documentation... ah, the same way. Does this seem right to
you?</JubalEarly>

ChrisA

[Roy Smith]

In article <mailman.2265.1369693...@python.org>,

Chris Angelico <ros...@gmail.com> wrote:

> I'll use XML when I have to, but if I'm inventing my own protocol,
> nope. There are just too many quirks with it. How do you represent an
> empty string named Foo?
>
> <Foo></Foo>
>
> or equivalently
>
> <Foo/>
>
> How do you represent an empty list named Foo? The same way. How do you
> represent an empty dict/mapping named Foo? Lemme look up my
> documentation... ah, the same way. Does this seem right to
> you?</JubalEarly>

XML doesn't represent strings, or lists, or dicts. It represents trees
of nodes with labels. If you wish to invent some richer semantic
meaning to impose on those nodes, that's up to you.

JSON isn't better or worse than XML. They solve different problems.

[Denis McMahon]

On Tue, 28 May 2013 08:21:25 +1000, Chris Angelico wrote:

> I'll use XML when I have to, but if I'm inventing my own protocol,
> nope. There are just too many quirks with it. How do you represent an
> empty string named Foo?

> <Foo></Foo>

> or equivalently

> <Foo/>

> How do you represent an empty list named Foo? The same way. How do you
> represent an empty dict/mapping named Foo? Lemme look up my
> documentation... ah, the same way. Does this seem right to
> you?</JubalEarly>

<Foo type="list" />
<Foo type="mapping" />
<Foo type="string" />

--
Denis McMahon, denismf...@gmail.com

[Chris Angelico]

Sure it doesn't, but it's very often used that way. So I guess what
I'm really saying is that XML is wrong for 90% of the places it's
used.

ChrisA

[88888 Dihedral]

Chris Angelico於 2013年5月28日星期二UTC+8下午3時11分55秒寫道：

Please check the annual sales in Ebay or similar sites and the
advertizement fees collected by Google and Yahoo.

[Grant Edwards]

On 2013-05-26, Roy Smith <r...@panix.com> wrote:
> Michael Torrie <tor...@gmail.com> wrote:
>
>> On good thing web development has brought us is the knowledge that
>> modularization and layers are a brilliant idea.
>
> Modularization and layers were a brilliant idea long before the web came
> around.

Once again USENET proves to be an unsuitable RPC protocol for
implementing irony. :)

[OTOH, perhaps Micheal wasn't being ironic...]

--
Grant Edwards grant.b.edwards Yow! Am I having fun yet?
at
gmail.com

[Wolfgang Keller]

> Please give me an example of a "suitable transport layer for a RPC
> protocol".

I won't give you an example, but just some very basic criteria:

- It must be very efficient for very small "datagrams"
- It must provide connections
- For asynchronous programming it must provide for callbacks

No RPC-over-HTTP protocol that I know of does this.

Besides, no one needs RPC just to logically separate GUI and
application layer. And between application logic and database, you use
the native database API for the RDBMS in question, of course.

The whole idea to centralise application logic (and even the GUI with
"web applications") is backwards, it dates from the 70s/early 80s when
desktop computers weren't able to run application logic. Today, to make
an application responsive (minimise latencies and maximise throughput),
it's just obvious to *de*-centralise as much as possible. In fact,
if Postgres-R was available for production, you could even distribute
the persistence and run an entirely "serverless" application.

Sincerely,

Wolfgang

[Wolfgang Keller]

> What is "screenwork"?

Actually productive work of significant intensity at a computer screen.

As opposed to leisurely "clicking around" like managers, administrators
or home users (gaming, "webbing",...) do.

Sincerely,

Wolfgang

[Michael Torrie]

On 05/28/2013 11:26 AM, Wolfgang Keller wrote:
>> Please give me an example of a "suitable transport layer for a RPC
>> protocol".
>
> I won't give you an example, but just some very basic criteria:
>
> - It must be very efficient for very small "datagrams"

I won't argue for XML here, but sometimes space efficiency is simply a
premature optimization.

> - It must provide connections

How would you do this? Connections can and do get dropped regularly.
To rebuild connections you need another layer to track them.

> - For asynchronous programming it must provide for callbacks

What do you mean by this? A transport layer has nothing to do with
callbacks. All a client can do is make the call, and wait for the
answer. The client library can make it look asynchronous of course.
And I suppose one could implement an RPC system using UDP where answer
packets are dispatched as they come in.

[Grant Edwards]

On 2013-05-28, Wolfgang Keller <feli...@gmx.net> wrote:

> Actually productive work of significant intensity at a computer screen.

Oh. You mean emacs.

--
Grant Edwards grant.b.edwards Yow! Will it improve my
at CASH FLOW?
gmail.com

[Carlos Nepomuceno]

----------------------------------------
> From: feli...@gmx.net
> Subject: Re: Future standard GUI library

> Date: Tue, 28 May 2013 19:26:55 +0200
> To: pytho...@python.org

>
>> Please give me an example of a "suitable transport layer for a RPC
>> protocol".
>
> I won't give you an example, but just some very basic criteria:
>
> - It must be very efficient for very small "datagrams"

Interoperability is much more expensive than efficiency. That's why you won't get the most optimized protocol for speed or size.

> - It must provide connections

What do you mean?

> - For asynchronous programming it must provide for callbacks
> No RPC-over-HTTP protocol that I know of does this.

XHR implements asynchronous callbacks over HTTP.

> Besides, no one needs RPC just to logically separate GUI and
> application layer. And between application logic and database, you use
> the native database API for the RDBMS in question, of course.
>
> The whole idea to centralise application logic (and even the GUI with
> "web applications") is backwards, it dates from the 70s/early 80s when
> desktop computers weren't able to run application logic. Today, to make
> an application responsive (minimise latencies and maximise throughput),
> it's just obvious to *de*-centralise as much as possible. In fact,
> if Postgres-R was available for production, you could even distribute
> the persistence and run an entirely "serverless" application.

"web applications" is so nowadays! All of my recent software development projects (last 10 years) focus on business processes integration.
In all of them the BLL (Business Logic Layer), or "application logic", is run on server side (as a controller in MVC) due to security and performance reasons.
None of my clients want their business rules and internal workflows exposed, so the old ways of the 70/80's ain't gonna change.

> Sincerely,
>
> Wolfgang
> --
> http://mail.python.org/mailman/listinfo/python-list

[88888 Dihedral]

Grant Edwards於 2013年5月29日星期三UTC+8上午2時25分08秒寫道：

Check http://www.pyamf.org/index.html for Python +flash
in browser applications. Annyway the virtual server part
can be obtained from the Adobe system in the cloudy services
or whatever.

As long as it is scalable in fees to provide services
to web users in PCs or mobile phones,
then it might be very profitable than 10 to 15 years ago.

[Chris Angelico]

On Wed, May 29, 2013 at 3:26 AM, Wolfgang Keller <feli...@gmx.net> wrote:
> I won't give you an example, but just some very basic criteria:
>
> - It must be very efficient for very small "datagrams"
> - It must provide connections
> - For asynchronous programming it must provide for callbacks

In other words, a TELNET connection. I absolutely concur.

I've made extensive use of that family of protocols; between MUDs
(three active connections right at this moment), mail (SMTP and POP
both), actual command execution (though that's usually encrypted via
SSH), and *seven* separate protocols that I devised for work, I pretty
much *always* am working with a system that parses text into lines and
(usually) lines into commands with arguments. It's a broad concept
that can be applied to *everything*. I'm firmly of the opinion that
Magic: The Gathering could be played over a MUD connection.

ChrisA

[Wolfgang Keller]

> >> suppose I now want the app natively on my phone (because that's all
> >> the rage). It's an iPhone. Oh. Apple doesn't support Python.
> >> Okay, rewrite the works, including business logic, in Objective C.
> >> Now I want it on my android phone.
> >
> > Those are gadgets, not work tools.
>
> As a professional programmer I'm afraid you're going to soon find
> yourself out of work if you really see things that way.

As a "domain expert", I come from the end-user side of "enterprise
applications" and again; those are not tools for screenworkers to get
actual work done, but consumer crap for fad-driven gadget-addicted kids
(regardless of nominal age).

> I honestly used to feel that way about graphical user interfaces.

A GUI that can not be used without taking the ten fingers off the
keyboard is indeed entirely unusable for any half-proficient
screenworker. And anyone doing actual productive screenwork every day
for more than just a few months will inevitably (have to) get proficient
(unless completely braindead).

Sincerely,

Wolfgang

[Chris Angelico]

On Fri, May 31, 2013 at 2:40 AM, Wolfgang Keller <feli...@gmx.net> wrote:
> A GUI that can not be used without taking the ten fingers off the
> keyboard is indeed entirely unusable for any half-proficient
> screenworker. And anyone doing actual productive screenwork every day
> for more than just a few months will inevitably (have to) get proficient
> (unless completely braindead).

My ten fingers stay on my keyboard, which looks somewhat thus:

http://www.xbitlabs.com/images/mobile/lenovo-thinkpad-t61/keyboard.jpg

See the red dot in the middle? Mouse. See the keys all around it? My
hands are all over that. I can casually mouse and keyboard at the same
time. Doesn't bother me.

THIS is a professional programmer's workspace. :)

ChrisA

[Wolfgang Keller]

> > A GUI that can not be used without taking the ten fingers off the
> > keyboard is indeed entirely unusable for any half-proficient
> > screenworker. And anyone doing actual productive screenwork every
> > day for more than just a few months will inevitably (have to) get
> > proficient (unless completely braindead).
>
> My ten fingers stay on my keyboard, which looks somewhat thus:
>
> http://www.xbitlabs.com/images/mobile/lenovo-thinkpad-t61/keyboard.jpg
>
> See the red dot in the middle? Mouse.

I didn't mean "trackpoints" or similar devices, but full keyboard
"navigation" of the entire GUI through shortcuts etc.

A "touch-type" GUI is a "must have" for any application that's supposed
to be used productively. The mouse is nice to "explore" a GUI or for
occasional/leisurely use, but once you use an application daily to earn
your living, it's a hopeless roadblock for productivity.

As is the "response time" behaviour of "web applications".

Besides that pathological non-operating system MS (Not Responding),
btw.

"No cursor animation ever" is an absolute "must have" requirement for
productivity applications.

> THIS is a professional programmer's workspace. :)

And by "screenworkers" I didn't refer to programmers. Those people
rarely have to use the stuff that they implement.

Sincerely,

Wolfgang

[Chris Angelico]

On Sun, Jun 2, 2013 at 4:18 AM, Wolfgang Keller <feli...@gmx.net> wrote:
>> > A GUI that can not be used without taking the ten fingers off the
>> > keyboard is indeed entirely unusable for any half-proficient
>> > screenworker. And anyone doing actual productive screenwork every
>> > day for more than just a few months will inevitably (have to) get
>> > proficient (unless completely braindead).
>>
>> My ten fingers stay on my keyboard, which looks somewhat thus:
>>
>> http://www.xbitlabs.com/images/mobile/lenovo-thinkpad-t61/keyboard.jpg
>>
>> See the red dot in the middle? Mouse.
>
> I didn't mean "trackpoints" or similar devices, but full keyboard
> "navigation" of the entire GUI through shortcuts etc.
>
> A "touch-type" GUI is a "must have" for any application that's supposed
> to be used productively. The mouse is nice to "explore" a GUI or for
> occasional/leisurely use, but once you use an application daily to earn
> your living, it's a hopeless roadblock for productivity.

You have seriously underestimated the power of the combined
keyboard+mouse interface. I absolutely agree that keyboard-only will
(almost) always beat mouse-only, but keyboard AND mouse together can
beat either alone, if the UI is designed correctly.

Case in point: Partial staging of a file in git. I can use 'git add
-p' or 'git gui'. With the former, it's all keyboard; I can step
through the hunks, choose what to stage, move on. With the latter,
it's more visual; I right-click a hunk and choose "Stage this hunk"
(or "Stage this line", which is actually quite fiddly with 'git add
-p').

I am a self-confessed keyboard junkie. I will use the keyboard for
pretty much everything. Yet I use git gui and almost never git add -p,
the one exception being when I can't use git gui (eg it's not
installed on some remote headless system and installing it would
require fetching gobs of GUI libraries). It uses the mouse to good
result.

> As is the "response time" behaviour of "web applications".

On a LAN, with a proper back-end, I can get instant response from a
web app. Obviously over the internet there's latency, but that's
nothing to do with the use of a web browser as a UI; you'll see that
with ssh just as much.

> "No cursor animation ever" is an absolute "must have" requirement for
> productivity applications.

Not really. There are times when the human will be legitimately
waiting for the computer. http://xkcd.com/303/ for one. But this still
has little to do with the use of a web browser UI; I can achieve
exactly that with the Yosemite Project, which can actually be a
three-computer system: the content is stored on one, the HTTP server
is on another, and the web browser is separate again. And this is only
a 100Mbit LAN. If you need moar speeeeeeed, you can always demand
gigabit or better.

>> THIS is a professional programmer's workspace. :)
>
> And by "screenworkers" I didn't refer to programmers. Those people
> rarely have to use the stuff that they implement.

Of course not, programmers never use software they've themselves
written. Never. Not in a million... oh wait, what's this I have? Hmm,
gcc used to compile gcc, RosMud being used by Rosuav, Neil Hodgson
using SciTE... naw, they're all statistical anomalies, carry on!

You really have a very low opinion of programmers for someone on a
programming mailing list :)

ChrisA

[Terry Jan Reedy]

On 6/1/2013 4:46 PM, Chris Angelico wrote:

> On Sun, Jun 2, 2013 at 4:18 AM, Wolfgang Keller <feli...@gmx.net> wrote:

>> And by "screenworkers" I didn't refer to programmers. Those people
>> rarely have to use the stuff that they implement.
>

> Of course not, programmers never use software they've themselves
> written. Never. Not in a million... oh wait, what's this I have? Hmm,
> gcc used to compile gcc, RosMud being used by Rosuav, Neil Hodgson
> using SciTE... naw, they're all statistical anomalies, carry on!

And I use Idle to improve Idle.

I use the HgWorkbench front-end to hg because point and click is often
*faster* for me than remember (or look up command and arg) and type
(without error, or correction after error).

Now back to ignoring the troll.

Terry

[Wolfgang Keller]

> > A "touch-type" GUI is a "must have" for any application that's
> > supposed to be used productively. The mouse is nice to "explore" a
> > GUI or for occasional/leisurely use, but once you use an
> > application daily to earn your living, it's a hopeless roadblock
> > for productivity.
>
> You have seriously underestimated the power of the combined
> keyboard+mouse interface.

As someone who has started to use computers with the Atari ST and later
the Mac, and as someone who has never become proficient himself with
any of the various Unix shells (besides that I had to learn to *hate*
any version of MS DOS or MS (Not Responding)), I certainly don't
underestimate the value of the mouse.

But could it be that you have never seen an actually proficient user of
a typical "enterprise" application (ERP, MRP, whatever) "zipping"
through the GUI of his/her bread-and-butter application so fast that
you can not even read the titles of windows or dialog boxes.

Obviously, this won't work if the client runs on this pathological
non-operating system MS (Not Responding), much less with "web
applications".

Oh, and btw; SAP is a particularly illustrative example for the horrible
response time behaviour of applications with centralised application
logic. They call it "hour-glass display program" over here,
"SanduhrAnzeigeProgramm" in German.

> > As is the "response time" behaviour of "web applications".
>
> On a LAN, with a proper back-end, I can get instant response from a
> web app.

I have been involved as "domain specialist" (and my input has always
been consistently conveniently ignored) with projects for web
applications and the results never turned out to be even remotely usable
for actually productive work.

Sincerely,

Wolfgang

[Frank Millman]

"Wolfgang Keller" <feli...@gmx.net> wrote in message
news:20130612222819.2a04...@gmx.net...

>
> But could it be that you have never seen an actually proficient user of
> a typical "enterprise" application (ERP, MRP, whatever) "zipping"
> through the GUI of his/her bread-and-butter application so fast that
> you can not even read the titles of windows or dialog boxes.
>
> Obviously, this won't work if the client runs on this pathological
> non-operating system MS (Not Responding), much less with "web
> applications".
>

[...]

>
>>
>> On a LAN, with a proper back-end, I can get instant response from a
>> web app.
>
> I have been involved as "domain specialist" (and my input has always
> been consistently conveniently ignored) with projects for web
> applications and the results never turned out to be even remotely usable
> for actually productive work.
>

Hi Wolfgang

I share your passion for empowering a human operator to complete and submit
a form as quickly as possible. I therefore agree that one should be able to
complete a form using the keyboard only.

There is an aspect I am unsure of, and would appreciate any feedback based
on your experience.

I am talking about what I call 'field-by-field validation'. Each field could
have one or more checks to ensure that the input is valid. Some can be done
on the client (e.g. value must be numeric), others require a round-trip to
the server (e.g. account number must exist on file). Some applications defer
the server-side checks until the entire form is submitted, others perform
the checks in-line. My preference is for the latter.

I agree with Chris that on a LAN, it makes little or no difference whether
the client side is running a web browser or a traditional gui interface. On
a WAN, there could be a latency problem. Ideally an application should be
capable of servicing a local client or a remote client, so it is not easy to
find the right balance.

Do you have strong views on which is the preferred approach.

Thanks for any input.

Frank Millman

[Chris Angelico]

On Thu, Jun 13, 2013 at 7:32 PM, Frank Millman <fr...@chagford.com> wrote:
> I am talking about what I call 'field-by-field validation'. Each field could
> have one or more checks to ensure that the input is valid. Some can be done
> on the client (e.g. value must be numeric), others require a round-trip to
> the server (e.g. account number must exist on file). Some applications defer
> the server-side checks until the entire form is submitted, others perform
> the checks in-line. My preference is for the latter.

It's not either-or. The server *MUST* perform the checks at the time
of form submission; the question is whether or not to perform
duplicate checks earlier. This is an absolute rule of anything where
the client is capable of being tampered with, and technically, you
could violate it on a closed system; but it's so easy to migrate from
closed system to diverse system without adding all the appropriate
checks, so just have the checks from the beginning.

In terms of software usability, either is acceptable, but do make sure
the user can continue working with the form even if there's latency
talking to the server - don't force him/her to wait while you check if
the previous field was valid. I know that seems obvious, but
apparently not to everyone, as there are forms out there that violate
this...

ChrisA

[Frank Millman]

"Chris Angelico" <ros...@gmail.com> wrote in message
news:CAPTjJmo+fWsCD3Lb6s+zmWspKzzk_JB=pbcvfLBZj...@mail.gmail.com...

> On Thu, Jun 13, 2013 at 7:32 PM, Frank Millman <fr...@chagford.com> wrote:
>> I am talking about what I call 'field-by-field validation'. Each field
>> could
>> have one or more checks to ensure that the input is valid. Some can be
>> done
>> on the client (e.g. value must be numeric), others require a round-trip
>> to
>> the server (e.g. account number must exist on file). Some applications
>> defer
>> the server-side checks until the entire form is submitted, others perform
>> the checks in-line. My preference is for the latter.
>
> It's not either-or. The server *MUST* perform the checks at the time
> of form submission; the question is whether or not to perform
> duplicate checks earlier. This is an absolute rule of anything where
> the client is capable of being tampered with, and technically, you
> could violate it on a closed system; but it's so easy to migrate from
> closed system to diverse system without adding all the appropriate
> checks, so just have the checks from the beginning.
>

In my case, it is either-or. I do not just do field-by-field validation, I
do field-by-field submission. The server builds up a record of the data
entered while it is being entered. When the user selects 'Save', it does not
resend the entire form, it simply sends a message to the server telling it
to process the data it has already stored.

> In terms of software usability, either is acceptable, but do make sure
> the user can continue working with the form even if there's latency
> talking to the server - don't force him/her to wait while you check if
> the previous field was valid. I know that seems obvious, but
> apparently not to everyone, as there are forms out there that violate
> this...
>

I plead guilty to this, but I am not happy about it, hence my original post.
I will take on board your comments, and see if I can figure out a way to
have the best of both worlds.

Frank

[Chris Angelico]

On Fri, Jun 14, 2013 at 3:39 PM, Frank Millman <fr...@chagford.com> wrote:
>> It's not either-or. The server *MUST* perform the checks at the time
>> of form submission; the question is whether or not to perform
>> duplicate checks earlier. This is an absolute rule of anything where
>> the client is capable of being tampered with, and technically, you
>> could violate it on a closed system; but it's so easy to migrate from
>> closed system to diverse system without adding all the appropriate
>> checks, so just have the checks from the beginning.
>>
>
> In my case, it is either-or. I do not just do field-by-field validation, I
> do field-by-field submission. The server builds up a record of the data
> entered while it is being entered. When the user selects 'Save', it does not
> resend the entire form, it simply sends a message to the server telling it
> to process the data it has already stored.

Ah, I see what you mean. What I was actually saying was that it's
mandatory to check on the server, at time of form submission, and
optional to pre-check (either on the client itself, for simple
syntactic issues, or via AJAX or equivalent) for faster response.

As a general rule, I would be inclined to go with a more classic
approach for reasons of atomicity. What happens if the user never gets
around to selecting Save? Does the server have a whole pile of data
that it can't do anything with? Do you garbage-collect that
eventually? The classic model allows you to hold off inserting
anything into the database until it's fully confirmed, and then do the
whole job in a single transaction.

But if you want to use a "wizard" approach, where the user enters one
thing and then moves on to the next, that can work too. It gets clunky
quickly, but it can be useful if the early responses make the
subsequent questions drastically different.

ChrisA

[Frank Millman]

"Chris Angelico" <ros...@gmail.com> wrote in message

news:CAPTjJmq_m4y0UXXt3JqYThJj...@mail.gmail.com...

> On Fri, Jun 14, 2013 at 3:39 PM, Frank Millman <fr...@chagford.com> wrote:
>>
>> In my case, it is either-or. I do not just do field-by-field validation,
>> I
>> do field-by-field submission. The server builds up a record of the data
>> entered while it is being entered. When the user selects 'Save', it does
>> not
>> resend the entire form, it simply sends a message to the server telling
>> it
>> to process the data it has already stored.
>
> Ah, I see what you mean. What I was actually saying was that it's
> mandatory to check on the server, at time of form submission, and
> optional to pre-check (either on the client itself, for simple
> syntactic issues, or via AJAX or equivalent) for faster response.
>
> As a general rule, I would be inclined to go with a more classic
> approach for reasons of atomicity. What happens if the user never gets
> around to selecting Save? Does the server have a whole pile of data
> that it can't do anything with? Do you garbage-collect that
> eventually? The classic model allows you to hold off inserting
> anything into the database until it's fully confirmed, and then do the
> whole job in a single transaction.
>

The data is just stored in memory in a 'Session' object. I have a
'keep-alive' feature that checks if the client is alive, and removes the
session with all its data if it detects that the client has gone away.
Timeout is configurable, but I have it set to 30 seconds at the moment.

The session is removed immediately if the user logs off. He is warned if
there is unsaved data.

Frank

[Wolfgang Keller]

> I share your passion for empowering a human operator to complete and
> submit a form as quickly as possible. I therefore agree that one
> should be able to complete a form using the keyboard only.

This is not just about "forms", it's about using the entire application
without having to use the mouse, ever.

> Do you have strong views on which is the preferred approach.

Use a decent database RAD desktop (non-web) GUI application framework
which uses client-side application logics. "Validation" of input will
then be essentially instantaneous. Unless you run the client on that
pathological non-operating system MS (Not Responding), obviously. I've
posted a corresponding list of frameworks available for Python multiple
times already on this group:

using PyQt (& Sqlalchemy):
Qtalchemy: www.qtalchemy.org
Camelot: www.python-camelot.com
Pypapi: www.pypapi.org

using PyGTK:
Sqlkit: sqlkit.argolinux.org (also uses Sqlalchemy)
Kiwi: www.async.com.br/projects/kiwi

using wxPython:
Gui2Py: code.google.com/p/gui2py/
Dabo: www.dabodev.com
Defis: sourceforge.net/projects/defis (Russian only)
GNUe: www.gnuenterprise.org

Server-roundtrips required for simple user interaction are an absolute
non-starter for productivity applications. No matter whether in a LAN
or WAN. If you want a responsive application you have to de-centralise
as much as possible. Perfect solution would be if Bettina Kemme's
Postgres-R was available for production use, then even the persistence
could run locally on the client with asynchronous replication of
all clients ("peer to peer").

Sincerely,

Wolfgang

[Chris Angelico]

On Sat, Jun 15, 2013 at 1:18 AM, Wolfgang Keller <feli...@gmx.net> wrote:
> Server-roundtrips required for simple user interaction are an absolute
> non-starter for productivity applications. No matter whether in a LAN
> or WAN. If you want a responsive application you have to de-centralise
> as much as possible.

Okay... how long does a round-trip cost? Considering that usability
guidelines generally permit ~100ms for direct interaction, and
considering that computers on a LAN can easily have sub-millisecond
ping times, it seems to me you're allowing a ridiculous amount of time
for code to execute on the server. Now, granted, there are systems
that suboptimal. (Magento, a PHP-based online shopping cart system,
took the better part of a second - something in the order of 700-800ms
- to add a single item. And that on reasonable hardware, not a
dedicated server but my test box was certainly not trash.)

For a real-world example of a LAN system that uses a web browser as
its UI, I'm using the Yosemite Project here. It consists of a
single-threaded Python script, no scaling assistance from Apache, just
the simplest it can possibly be. It is running on three computers:
yosemite [the one after whom the project was named], huix, and
sikorsky. I used 'time wget http://hostname:3003/airshow' for my
testing, which involves:

* A DNS lookup from the local DNS server (on the LAN)
* An HTTP query to the specified host
* A directory listing, usually remote
* Building a response (in Python)
* Returning that via HTTP
* Save the resulting page to disk

Since I'm using the bash 'time' builtin, all of this is counted (I'm
using the 'real' figure here; the 'user' and 'sys' figures are of
course zero, or as close as makes no odds - takes no CPU to do this).

The files in question are actually stored on Huix. Queries to that
server therefore require a local directory listing; queries to
sikorsky involve an sshfs directory listing, and those to yosemite use
NetBIOS. (Yosemite runs Windows XP, Huix and Sikorsky are running
Linux.)

My figures do have one peculiar outlier. Queries from Sikorsky to
Yosemite were taking 4-5 seconds, consistently; identical queries from
Huix to Yosemite were more consistent with other data. I have no idea
why this is.

So, the figures! Every figure I could get for talking to a Linux
server (either Huix or Sikorsky) was between 7ms and 16ms. (Any
particular combination of client and server is fairly stable, eg
sikorsky -> sikorsky is consistently 8ms.) And talking to the Windows
server, aside from the crazy outlier, varied from 22ms to 29ms.
Considering that the Windows lookups involve NetBIOS, I'm somewhat not
surprised; there's a bit of cost there.

That's the entire round-trip cost. The queries from Sikorsky to
Yosemite involve three computers (the client, the server, and the file
server), and is completed in under 30 milliseconds. That still gives
you 70 milliseconds to render the page to the user, and still be
within the estimated response time for an immediate action. In the
case of localhost, as mentioned above, that figure comes down to just
8ms - just *eight milliseconds* to do a query involving two servers -
so I have to conclude that HTTP is plenty fast enough for a UI. I have
seen a number of desktop applications that can't beat that kind of
response time.

There, thou hast it all, Master Wilfred. Make the most of it. :)

ChrisA

[Wolfgang Keller]

> Okay... how long does a round-trip cost?

With a protocol that wasn't made for the purpose (such as HTTP) and all
that HTML to "render" (not to mention javascript that's required for
even the most trivial issues) - way too long.

> Considering that usability guidelines generally permit ~100ms for
> direct interaction,

That's "generous".

A proficient user with a responsive application can easily outpace that.

100ms is definitely a noticeable lag. Even I feel that and I don't use
touch-typing to use the GUI. 50ms might not be noticeable, but I don't
have the skills myself to test that.

> (Magento, a PHP-based online shopping cart system, took the better
> part of a second - something in the order of 700-800ms
> - to add a single item. And that on reasonable hardware, not a
> dedicated server but my test box was certainly not trash.)

That's not a question of hardware. Just like with MS (Not Responding).

> That's the entire round-trip cost. The queries from Sikorsky to
> Yosemite involve three computers (the client, the server, and the file
> server), and is completed in under 30 milliseconds.

I am talking about applications that actually do something. In my case,
database applications. A PostgreSQL transaction is supposed to take at
most 25ms to complete (anything above is generally considered an issue
that needs to be solved, such as bad SQL), *server-side*. That leaves
you another 25ms for the entire network protocol (the pgsql protocol,
whatever it is, was designed for the purpose, unlike HTTP) *and* the
client-side application logic, including the GUI "rendering".

Qt is already quite sluggish sometimes, don't know why. GTK and
wxPython "feel" swifter, at least on an actual *operating* system. MS
(Not Responding) is definitely incapable to allow applications anything
remotely close to "responsiveness". Minute-long lockups with frozen
cursor are "normal".

> That still gives you 70 milliseconds to render the page to the user,

Forget that.

25ms for client-server (pgsql) network protocol, client-side
application logic *and* GUI.

With a "web" application that would have to include "application
server"-side application logic, *and* generation of HTML (and
javascript), *and* HTTP protocol *and* HTML "rendering" *and*
client-side javascript.

Won't work.

Sincerely,

Wolfgang

[Chris Angelico]

On Sat, Jun 15, 2013 at 10:25 PM, Wolfgang Keller <feli...@gmx.net> wrote:
>> Okay... how long does a round-trip cost?
>
> With a protocol that wasn't made for the purpose (such as HTTP) and all
> that HTML to "render" (not to mention javascript that's required for
> even the most trivial issues) - way too long.

You keep saying this. I have yet to see actual timings from you.

>> Considering that usability guidelines generally permit ~100ms for
>> direct interaction,
>

> 100ms is definitely a noticeable lag. Even I feel that and I don't use
> touch-typing to use the GUI. 50ms might not be noticeable, but I don't
> have the skills myself to test that.

Okay, so let's talk 50ms then. We can handle this.

>> That's the entire round-trip cost. The queries from Sikorsky to
>> Yosemite involve three computers (the client, the server, and the file
>> server), and is completed in under 30 milliseconds.
>
> I am talking about applications that actually do something. In my case,
> database applications. A PostgreSQL transaction is supposed to take at
> most 25ms to complete (anything above is generally considered an issue
> that needs to be solved, such as bad SQL), *server-side*. That leaves
> you another 25ms for the entire network protocol (the pgsql protocol,
> whatever it is, was designed for the purpose, unlike HTTP) *and* the
> client-side application logic, including the GUI "rendering".

No problem. Again taking *actual real figures*, I got roughly 35-40tps
in PostgreSQL across a LAN. That's around about the 25ms figure you're
working with, so let's use that as a baseline. My benchmark was
actually a durability test from work, which was done on two laptops on
a gigabit LAN, with the database server brutally powered down in the
middle of the test. Each transaction updates a minimum of two rows in
a minimum of one table (transaction content is randomized some). So
that's 25ms for the database, leaving us 25ms for the rest.

> 25ms for client-server (pgsql) network protocol, client-side
> application logic *and* GUI.
>
> With a "web" application that would have to include "application
> server"-side application logic, *and* generation of HTML (and
> javascript), *and* HTTP protocol *and* HTML "rendering" *and*
> client-side javascript.
>
> Won't work.

I've demonstrated already that with basic hardware and a simple Python
HTTP server, network, application logic, and generation of HTML, all
take a total of 8ms. That leaves 17ms for rendering HTML. Now, getting
figures for the rendering of HTML is not easy; I've just spent fifteen
minutes researching on Google and playing with the Firebug-like
feature of Chrome, and haven't come up with an answer; so it may well
be that 17ms isn't enough for a full page load. However, I would say
that the matter is sufficiently borderline (bearing in mind that you
can always use a tiny bit of JS and a DOM change) that it cannot be
called as "Won't work"; it's what Mythbusters would dub "Plausible".

Of course, if you're trying to support MS IE, there's no way you'll
guarantee <50ms response time. This is all predicated on having at
least reasonably decent hardware and software. But using either the
100ms figure from common usability guidelines [1] [2] [3] or your more
stringent 50ms requirement [4], it's certainly entirely possible to
achieve immediate response using AJAX.

I've worked with real figures, hard numbers. You keep coming back with
vague FUD that it "won't work". Where are your numbers? And like Sir
Ruthven Murgatroyd, I fail to see how you can call this impossible in
the face of the fact that I have done it.

ChrisA

[1] http://www.nngroup.com/articles/response-times-3-important-limits/
[2] http://usabilitygeek.com/14-guidelines-for-web-site-tabs-usability/#attachment_719
[3] http://calendar.perfplanet.com/2011/how-response-times-impact-business/
[4] Can you provide a link to any study anywhere that recommends 50ms?