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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#46230

In article <mailman.2265.1369693294.3114.python-list@python.org>,
 Chris Angelico <rosuav@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.

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

#46260

On Tue, May 28, 2013 at 9:10 AM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.2265.1369693294.3114.python-list@python.org>,
>  Chris Angelico <rosuav@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.

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

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

#46270

Chris Angelico於 2013年5月28日星期二UTC+8下午3時11分55秒寫道：
> On Tue, May 28, 2013 at 9:10 AM, Roy Smith <roy@panix.com> wrote:
> 
> > In article <mailman.2265.1369693294.3114.python-list@python.org>,
> 
> >  Chris Angelico <rosuav@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.
> 
> 
> 
> 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

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

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

#46242

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, denismfmcmahon@gmail.com

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

#46099

----------------------------------------
> From: feliphil@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,
>
> Wolfgang


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

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

#46313

> 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

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

#46320

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.

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

#46343

----------------------------------------
> From: feliphil@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".
>
> 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 		 	   		  

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

#46357

On Wed, May 29, 2013 at 3:26 AM, Wolfgang Keller <feliphil@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

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

#46101

On Mon, May 27, 2013 at 3:43 AM, Wolfgang Keller <feliphil@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

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

#46106

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.

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

#46107

In article <mailman.2193.1369597318.3114.python-list@python.org>,
 Michael Torrie <torriem@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.

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

#46124

On 05/26/2013 01:45 PM, Roy Smith wrote:
> In article <mailman.2193.1369597318.3114.python-list@python.org>,
>  Michael Torrie <torriem@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.

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.

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

#46298

On 2013-05-26, Roy Smith <roy@panix.com> wrote:
>  Michael Torrie <torriem@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            

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

#46203

> 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

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

#46212

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.

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

#46507

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

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

#46509

On Fri, May 31, 2013 at 2:40 AM, Wolfgang Keller <feliphil@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

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

#46666

On Sun, Jun 2, 2013 at 4:18 AM, Wolfgang Keller <feliphil@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

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

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

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

csiph-web