Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #45511 > unrolled thread

Future standard GUI library

Back to article view | Back to comp.lang.python

Contents

  Future standard GUI library Beinan Li <li.beinan@gmail.com> - 2013-05-18 10:03 -0400
    Re: Future standard GUI library Kevin Walzer <kw@codebykevin.com> - 2013-05-18 11:32 -0400
    Re: Future standard GUI library Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-18 21:25 +0000
    Re: Future standard GUI library llanitedave <llanitedave@veawb.coop> - 2013-05-18 20:01 -0700
      Re: Future standard GUI library Kevin Walzer <kw@codebykevin.com> - 2013-05-19 08:57 -0400
    Re: Future standard GUI library Wolfgang Keller <feliphil@gmx.net> - 2013-05-22 15:42 +0200
      Re: Future standard GUI library Chris Angelico <rosuav@gmail.com> - 2013-05-23 00:24 +1000
        Re: Future standard GUI library llanitedave <llanitedave@veawb.coop> - 2013-05-22 19:31 -0700
          Re: Future standard GUI library Fábio Santos <fabiosantosart@gmail.com> - 2013-05-23 07:43 +0100
          Re: Future standard GUI library Chris Angelico <rosuav@gmail.com> - 2013-05-23 16:48 +1000
          RE: Future standard GUI library Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-05-23 09:58 +0300
          Re: Future standard GUI library Chris Angelico <rosuav@gmail.com> - 2013-05-23 17:03 +1000
          RE: Future standard GUI library Fábio Santos <fabiosantosart@gmail.com> - 2013-05-23 08:08 +0100
        Re: Future standard GUI library Wolfgang Keller <feliphil@gmx.net> - 2013-05-23 17:41 +0200
          Re: Future standard GUI library Chris Angelico <rosuav@gmail.com> - 2013-05-24 01:51 +1000
            Re: Future standard GUI library Wolfgang Keller <feliphil@gmx.net> - 2013-05-26 19:43 +0200
              Re: Future standard GUI library Roy Smith <roy@panix.com> - 2013-05-26 14:16 -0400
                Re: Future standard GUI library Wolfgang Keller <feliphil@gmx.net> - 2013-05-27 17:31 +0200
                  Re: Future standard GUI library Michael Torrie <torriem@gmail.com> - 2013-05-27 11:13 -0600
                  Re: Future standard GUI library Chris Angelico <rosuav@gmail.com> - 2013-05-28 08:21 +1000
                    Re: Future standard GUI library Roy Smith <roy@panix.com> - 2013-05-27 19:10 -0400
                      Re: Future standard GUI library Chris Angelico <rosuav@gmail.com> - 2013-05-28 17:11 +1000
                        Re: Future standard GUI library 88888 Dihedral <dihedral88888@gmail.com> - 2013-05-28 02:40 -0700
                    Re: Future standard GUI library Denis McMahon <denismfmcmahon@gmail.com> - 2013-05-28 01:01 +0000
              RE: Future standard GUI library Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-05-26 21:32 +0300
                Re: Future standard GUI library Wolfgang Keller <feliphil@gmx.net> - 2013-05-28 19:26 +0200
                  Re: Future standard GUI library Michael Torrie <torriem@gmail.com> - 2013-05-28 12:16 -0600
                  RE: Future standard GUI library Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-05-29 00:17 +0300
                  Re: Future standard GUI library Chris Angelico <rosuav@gmail.com> - 2013-05-29 17:20 +1000
              Re: Future standard GUI library Chris Angelico <rosuav@gmail.com> - 2013-05-27 04:56 +1000
              Re: Future standard GUI library Michael Torrie <torriem@gmail.com> - 2013-05-26 13:41 -0600
                Re: Future standard GUI library Roy Smith <roy@panix.com> - 2013-05-26 15:45 -0400
                  Re: Future standard GUI library Michael Torrie <torriem@gmail.com> - 2013-05-26 15:13 -0600
                  Re: Future standard GUI library Grant Edwards <invalid@invalid.invalid> - 2013-05-28 15:40 +0000
                Re: Future standard GUI library Wolfgang Keller <feliphil@gmx.net> - 2013-05-27 17:22 +0200
                  Re: Future standard GUI library Michael Torrie <torriem@gmail.com> - 2013-05-27 11:16 -0600
                    Re: Future standard GUI library Wolfgang Keller <feliphil@gmx.net> - 2013-05-30 18:40 +0200
                      Re: Future standard GUI library Chris Angelico <rosuav@gmail.com> - 2013-05-31 02:53 +1000
                        Re: Future standard GUI library Chris Angelico <rosuav@gmail.com> - 2013-06-02 06:46 +1000
                        Re: Future standard GUI library Wolfgang Keller <feliphil@gmx.net> - 2013-06-01 20:18 +0200
                          Re: Future standard GUI library Terry Jan Reedy <tjreedy@udel.edu> - 2013-06-01 17:52 -0400
              Re: Future standard GUI library Ian Foote <ian@feete.org> - 2013-05-26 22:02 +0100
              Re: Future standard GUI library Chris Angelico <rosuav@gmail.com> - 2013-05-27 08:09 +1000
          Re: Future standard GUI library Grant Edwards <invalid@invalid.invalid> - 2013-05-23 20:37 +0000
            Re: Future standard GUI library Wolfgang Keller <feliphil@gmx.net> - 2013-05-28 19:28 +0200
              Re: Future standard GUI library Grant Edwards <invalid@invalid.invalid> - 2013-05-28 18:25 +0000
                Re: Future standard GUI library 88888 Dihedral <dihedral88888@gmail.com> - 2013-05-28 16:19 -0700

Page 1 of 3  [1] 2 3  Next page →

#45511 — Future standard GUI library

[Multipart message — attachments visible in raw view] — view raw

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!

[toc] | [next] | [standalone]

#45514

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

[toc] | [prev] | [next] | [standalone]

#45532

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

[toc] | [prev] | [next] | [standalone]

#45545

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.

[toc] | [prev] | [next] | [standalone]

#45560

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

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

[toc] | [prev] | [next] | [standalone]

#45733

> 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

[toc] | [prev] | [next] | [standalone]

#45734

On Wed, May 22, 2013 at 11:42 PM, Wolfgang Keller <feliphil@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

[toc] | [prev] | [next] | [standalone]

#45768

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 <feliphil@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

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?

[toc] | [prev] | [next] | [standalone]

#45775

[Multipart message — attachments visible in raw view] — view raw

On 23 May 2013 03:39, "llanitedave" <llanitedave@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 <feliphil@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.

[toc] | [prev] | [next] | [standalone]

#45776

On Thu, May 23, 2013 at 4:43 PM, Fábio Santos <fabiosantosart@gmail.com> wrote:
> On 23 May 2013 03:39, "llanitedave" <llanitedave@veawb.coop> wrote:
>> On Wednesday, May 22, 2013 7:24:15 AM UTC-7, Chris Angelico 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.

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

[toc] | [prev] | [next] | [standalone]

#45777

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: llanitedave@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 		 	   		  

[toc] | [prev] | [next] | [standalone]

#45778

On Thu, May 23, 2013 at 4:58 PM, Carlos Nepomuceno
<carlosnepomuceno@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

[toc] | [prev] | [next] | [standalone]

#45784

[Multipart message — attachments visible in raw view] — view raw

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" <carlosnepomuceno@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: llanitedave@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
>

[toc] | [prev] | [next] | [standalone]

#45814

> 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

[toc] | [prev] | [next] | [standalone]

#45817

On Fri, May 24, 2013 at 1:41 AM, Wolfgang Keller <feliphil@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.
>
> 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. 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

[toc] | [prev] | [next] | [standalone]

#46087

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

[toc] | [prev] | [next] | [standalone]

#46093

In article <20130526194310.9cdb1be80b42c7fdf0ba502f@gmx.net>,
 Wolfgang Keller <feliphil@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.

[toc] | [prev] | [next] | [standalone]

#46205

> 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

[toc] | [prev] | [next] | [standalone]

#46211

On 05/27/2013 09:31 AM, Wolfgang Keller wrote:
>> 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.

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.

[toc] | [prev] | [next] | [standalone]

#46229

On Tue, May 28, 2013 at 3:13 AM, Michael Torrie <torriem@gmail.com> wrote:
> On 05/27/2013 09:31 AM, Wolfgang Keller wrote:
>>> 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.
>
> 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

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web