On Sat, Jun 15, 2013 at 10:25 PM, Wolfgang Keller 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.
Y
> 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
On Sat, Jun 15, 2013 at 1:18 AM, Wolfgang Keller 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.
> 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 m
"Chris Angelico" wrote in message
news:captjjmq_m4y0uxxt3jqythjj9ckbsvp+z2pgf5v_31xlrgf...@mail.gmail.com...
> On Fri, Jun 14, 2013 at 3:39 PM, Frank Millman 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 b
On Fri, Jun 14, 2013 at 3:39 PM, Frank Millman 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 t
"Chris Angelico" wrote in message
news:CAPTjJmo+fWsCD3Lb6s+zmWspKzzk_JB=pbcvflbzjgcfxvm...@mail.gmail.com...
> On Thu, Jun 13, 2013 at 7:32 PM, Frank Millman wrote:
>> I am talking about what I call 'field-by-field validation'. Each field
>> could
>> have one or more checks to ensure that the
On Thu, Jun 13, 2013 at 7:32 PM, Frank Millman 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 serv
"Wolfgang Keller" wrote in message
news:2013061819.2a044e86ab4b6defe1939...@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
> > 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
On 6/1/2013 4:46 PM, Chris Angelico wrote:
On Sun, Jun 2, 2013 at 4:18 AM, Wolfgang Keller 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. Ne
On Sun, Jun 2, 2013 at 4:18 AM, Wolfgang Keller 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 m
> > 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 c
On Fri, May 31, 2013 at 2:40 AM, Wolfgang Keller 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
> >> 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.
On Wed, May 29, 2013 at 3:26 AM, Wolfgang Keller 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 TEL
Grant Edwards於 2013年5月29日星期三UTC+8上午2時25分08秒寫道：
> On 2013-05-28, Wolfgang Keller wrote:
>
>
>
> > Actually productive work of significant intensity at a computer screen.
>
>
>
> Oh. You mean emacs.
>
>
>
> --
>
> Grant Edwards grant.b.edwardsYow! Will it improve my
> From: felip...@gmx.net
> Subject: Re: Future standard GUI library
> Date: Tue, 28 May 2013 19:26:55 +0200
> To: python-list@python.org
>
>> Please give me an example of a "suitable transport layer for a RPC
>> protocol&q
On 2013-05-28, Wolfgang Keller wrote:
> Actually productive work of significant intensity at a computer screen.
Oh. You mean emacs.
--
Grant Edwards grant.b.edwardsYow! Will it improve my
at CASH FLOW?
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
> 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
--
http://mail.python.org/mailman/listinfo/python-list
> 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 programmi
On 2013-05-26, Roy Smith wrote:
> Michael Torrie 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
Chris Angelico於 2013年5月28日星期二UTC+8下午3時11分55秒寫道：
> On Tue, May 28, 2013 at 9:10 AM, Roy Smith wrote:
>
> > In article ,
>
> > 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
On Tue, May 28, 2013 at 9:10 AM, Roy Smith wrote:
> In article ,
> 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?
>>
>>
>>
>> or equivalently
>>
>>
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?
>
> or equivalently
>
> How do you represent an empty list named Fo
In article ,
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?
>
>
>
> or equivalently
>
>
>
> How do you represent an empty list named Foo? The same w
On Tue, May 28, 2013 at 3:13 AM, Michael Torrie 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 flatulanc
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.
>
>
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 th
> 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
--
http://mail.python.org/mailman/listinfo/python-list
> 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
On Mon, May 27, 2013 at 5:41 AM, Michael Torrie 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
--
http://mail.python.org/mailman/listinfo/python-list
On 05/26/2013 01:45 PM, Roy Smith wrote:
> In article ,
> Michael Torrie 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.
Tru
On 26/05/13 20:41, Michael Torrie wrote:
On 05/26/2013 11:43 AM, Wolfgang Keller wrote:
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
In article ,
Michael Torrie 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.
--
http://mail.python.org/mailman/listinfo/python-list
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 brillian
On Mon, May 27, 2013 at 3:43 AM, Wolfgang Keller 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
> t
> From: felip...@gmx.net
> Subject: Re: Future standard GUI library
> Date: Sun, 26 May 2013 19:43:10 +0200
> To: python-list@python.org
[...]
> one, HTTP will never be a suitable transport layer for a RPC protocol.
>
> Sincerely,
>
In article <20130526194310.9cdb1be80b42c7fdf0ba5...@gmx.net>,
Wolfgang Keller 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
arg
> > 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,
On 2013-05-23, Wolfgang Keller 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 sup
On Fri, May 24, 2013 at 1:41 AM, Wolfgang Keller 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
> 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'
-------
> > Date: Wed, 22 May 2013 19:31:55 -0700
> > Subject: Re: Future standard GUI library
> > From: llanited...@veawb.coop
> [...]
> >
> > I've been thinking about that myself for some future app ideas. If you
> have a stand-alone app working from your we
On Thu, May 23, 2013 at 4:58 PM, Carlos Nepomuceno
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 t
--
> Date: Wed, 22 May 2013 19:31:55 -0700
> Subject: Re: Future standard GUI library
> From: llanited...@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
On Thu, May 23, 2013 at 4:43 PM, Fábio Santos wrote:
> On 23 May 2013 03:39, "llanitedave" 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.
On 23 May 2013 03:39, "llanitedave" 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
wrote:
...
> > there's another option that is available to every platform and
> > (practially) every high level language: the web
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 wrote:
>
> > What other open-source cross-platform programming language choices do yo
>
> > have.
>
> >
>
> > Java? For GUIs? Excuse me while I vomit.
>
> >
>
> > C++? As a
On Wed, May 22, 2013 at 11:42 PM, Wolfgang Keller 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, s
> 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 usi
> 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
On 2013-05-20, Terry Jan Reedy wrote:
> On 5/20/2013 1:04 AM, Vito De Tullio wrote:
>> 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 rea
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.
--
Kevin Walzer
Code by Kevin/Mobile Code
On 2013-05-20 08:00, Terry Jan Reedy wrote:
On 5/20/2013 1:04 AM, Vito De Tullio wrote:
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
candida
On 5/20/2013 1:04 AM, Vito De Tullio wrote:
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.fl
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
--
http:
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 kn
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.
--
http://mail.python
n Sat, May 18, 2013 at 1:40 PM, wrote:
>
>
> -- Forwarded message --
> From: Kevin Walzer
> To: python-list@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
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 g
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 bu
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 de
64 matches
Mail list logo
