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-12 22:28 +0200
                            Re: Future standard GUI library "Frank Millman" <frank@chagford.com> - 2013-06-13 11:32 +0200
                              Re: Future standard GUI library Wolfgang Keller <feliphil@gmx.net> - 2013-06-14 17:18 +0200
                                Re: Future standard GUI library Chris Angelico <rosuav@gmail.com> - 2013-06-15 03:00 +1000
                                  Re: Future standard GUI library Wolfgang Keller <feliphil@gmx.net> - 2013-06-15 14:25 +0200
                                    Re: Future standard GUI library Chris Angelico <rosuav@gmail.com> - 2013-06-15 23:26 +1000
                            Re: Future standard GUI library Chris Angelico <rosuav@gmail.com> - 2013-06-14 00:04 +1000
                            Re: Future standard GUI library "Frank Millman" <frank@chagford.com> - 2013-06-14 07:39 +0200
                            Re: Future standard GUI library Chris Angelico <rosuav@gmail.com> - 2013-06-14 19:10 +1000
                            Re: Future standard GUI library "Frank Millman" <frank@chagford.com> - 2013-06-14 11:36 +0200
                        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 3 of 3 — ← Prev page 1 2 [3]

#47927

"Wolfgang Keller" <feliphil@gmx.net> wrote in message 
news:20130612222819.2a044e86ab4b6defe1939a04@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

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

#48162

> 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

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

#48183

On Sat, Jun 15, 2013 at 1:18 AM, Wolfgang Keller <feliphil@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

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

#48291

> 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

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

#48294

On Sat, Jun 15, 2013 at 10:25 PM, Wolfgang Keller <feliphil@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?

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

#47965

On Thu, Jun 13, 2013 at 7:32 PM, Frank Millman <frank@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

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

#48065

"Chris Angelico" <rosuav@gmail.com> wrote in message 
news:CAPTjJmo+fWsCD3Lb6s+zmWspKzzk_JB=pbcvfLBZjGCFxvM9HA@mail.gmail.com...
> On Thu, Jun 13, 2013 at 7:32 PM, Frank Millman <frank@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

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

#48097

On Fri, Jun 14, 2013 at 3:39 PM, Frank Millman <frank@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

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

#48103

"Chris Angelico" <rosuav@gmail.com> wrote in message 
news:CAPTjJmq_m4y0UXXt3JqYThJj9CKbsvp+Z2PGF5v_31xLrgfr4Q@mail.gmail.com...
> On Fri, Jun 14, 2013 at 3:39 PM, Frank Millman <frank@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

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

#46670

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

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

#46673

On 6/1/2013 4:46 PM, Chris Angelico wrote:
> On Sun, Jun 2, 2013 at 4:18 AM, Wolfgang Keller <feliphil@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

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

#46120

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

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

#46132

On Mon, May 27, 2013 at 5:41 AM, Michael Torrie <torriem@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

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

#45842

On 2013-05-23, 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.

What is "screenwork"?

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

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

#46315

> 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

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

#46322

On 2013-05-28, Wolfgang Keller <feliphil@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            

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

#46349

Grant Edwards於 2013年5月29日星期三UTC+8上午2時25分08秒寫道：
> On 2013-05-28, Wolfgang Keller <feliphil@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

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.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web