>  From: Roman Suzi [mailto:rnd-list@[...]..]
> 
>  > > >Well, that makes gtk a non-starter, at least for me.
>  > Native-looking widgets
>  > > >and window types that respond like their native versions is a must.
>  > >
>  > > For me gtk is more native, than Qt or Win ;-)
> 
>  > (1) The desktop UI metaphor has about outlived its usefulness. A
>  > strong argument can be made for just tossing it in the trash can
>  > (which can be found right there on the desktop, just like it is in
>  > your office! :-) )
> 
>  I agree. Even "file" metaphor is not so useful as before.

<Rant on>  ...or why all is not wine and roses in web land...

Despite the myriads of old and new metaphors in use today and what people
may be able to adapt to, I will not build something that requires tossing
out the old or total conversion of data and work habits in order to be used.
That is not my place, nor is it PythonCards'. I like Donald Norman's notion
of the Invisible Computer, but it is out of the scope of what I think I can
do. The best we can hope for is a system that is easy to install on a
variety of platforms, works comfortably with old data and usage paradigms,
but allows for experimentation and migration to new paradigms if desired.
Lack of flexibility is one of the reasons most technology sucks. PythonCard
is not going to suck.

>  > On Thu, 28 Jun 2001 dshafer@[...].. wrote:
>  > (2) Web-based apps and services have, if not eliminated, at least
>  > rendered less important the platform-specific pieces of user interface
>  > that most users neither care about nor are aware of. The fact is,
>  > users are smarter than we think. Faced with a new UI that is similar
>  > but hardly identical to what they are used to seeing, they will adapt
>  > if they are given a good reason to do so.
> 
>  I think that native look&feel is not so important. Today's users are
>  accustomed to the Web and will be happy if interface is just convenient.

And contrary to what we sophisticated users may think we are able to deal
with in terms of different UIs, the fact is that we just get by, it isn't
comfortable nor is it easy to adapt. You only have to listen to *nix geeks
complain about not being able to figure out something simple on Windows or
watch Windows users get lost on the Mac because they can't right-click (hint
guys: you need to press a key while clicking). Anyone that owns a Palm or
PocketPC and a desktop probably has issues. Most people can probably adapt
to what they see on the web because at least the browser UI doesn't change
on them (switch from IE to Opera for a day and have some good fun), plus
most web pages are just reading material with limited actions available, yet
people still have to scan up and down the page to figure out what their
options are and wonder how they can turn off all those annoying pop-up
windows and ads (hint: setting undesirable DNS names to 127.0.0.1 in your
hosts file will solve your DoubleClick... problems ;-)

An application in web terms is generally limited to Back, Forward, Stop, and
Reload. That is about all you can hope for in consistency. You can't count
on cookies for client-side state. You can't count on JavaScript (JScript,
ECMAScript). You don't have a menu bar that you can call your own.
Cut/Copy/Paste/Undo don't do that much since all you can move in the
clipboard is text and the web apps aren't really clipboard aware. There is
no Find/Replace, Find is haphazard at best. The web is mostly a pull medium,
very few people even use protocols/tools like WebDAV. The web app metaphor
for user interaction is basically a 3270 terminal; fill in data, press
enter, server processes screen and spews back another screen. What is in
your browser does not interact with what is on your desktop. There are no
user interface guidelines. Many sites loosely follow the header, footer,
left-side navigation model, but who knows what type, colors, graphics, etc.
will be in use. You can't even count on a single site sticking with the same
look and feel or keeping the same URLs. If you're building an "app" the real
work is done at the server-side and it is neither easy, nor cheap to build
and maintain. While we're moving toward XML for content, XML-RPC and SOAP
for client to server and server to server communication, etc., we're not
there yet. If you require cookies, JavaScript, Flash, Java, "pick your
favorite technology here", what you are really saying is that you don't mind
losing a certain percentage of your potential audience. If that wasn't bad
enough, MS now has a complete monopoly on the browser and they are the ones
who are dictating the client "standards" by de facto. In short, the web is a
mess for building "applications". I'm glad I don't do it for a living
anymore.

Gee, that's pretty depressing. So what's the good news? The good news is
that the web has an architecture and part of that architecture is the
protocol HTTP which has nothing to do with HTML and JavaScript. Better yet,
HTTP is just one of many application-level protocols that run on top of
TCP/IP. As we move away from HTML-based content to XML or other formats that
are easier to parse, manipulate and display, any desktop application can act
as a full citizen on the web and the browser will lose its stranglehold as
the only window on the web. In addition, we'll be exchanging content, not
content mixed with code that can infect or trash your machine. It won't
happen this year, and it probably won't happen next year, but it is already
happening and apps beside the browser will be full citizens again.

I love the web and the communications capabilities it brings to my machine.
It is more important than Visicalc, Lotus 1-2-3, or PageMaker (all killer
apps btw), but it is still primitive, partly due to a reliance on funky
HTML, the browser wars, and the drive to have the browser do everything,
when clearly the browser, despite the bloat, isn't very capable.

Python already has a full complement of high-level (HTTP, XML-RPC, SOAP)
network communication code and it is easy to use. PythonCard will let you
build on top of that communication capability. If I were head of IS in a big
company today, I would be looking at leveraging an open source language like
Python and a framework like PythonCard to build my enterprise apps, thus
saving millions of dollars and countless man years. IS guys, you're making
your lives difficult by trying to squeeze everything in the browser with
convoluted business logic at the back-end.

What can be done on the desktop where you have a high-level of
user-interaction available (not a 3270 terminal), can read/write to local
data stores, use the local hardware to its fullest (sound, video...),
communicate with other desktop apps and services in addition to being able
to communicate with remote devices via TCP/IP is mind-boggling.

Part of what I find really exciting about PythonCard is that when I was a
hardcore HyperCard user and developer, the kind of apps I could build with
HC without resorting to complicated XCMDs and XFCNs was actually pretty
limited, yet it was still fun and useful. Python, the standard library, and
extensions in comparison to HC are a cornucopia that I can't wait to
leverage.

>  It is also my thought that current GUI realised in Windows systems
>  goes in wrong direction: it tries to add features, mostly cosmetical,
>  instead of rethinking GUI.
> 
>  We have freedom to create a tool which could allow for experiments.

BTW, I'm not a dictator here. In some way, I'm probably acting as "fearless
leader" for now, but this is open source, and we build consensus, not
dictate what will be. If I say something will be such and such way, that is
because I hate saying IMHO... and qualifying my point of view all the time.
I expect us to be adults and for everyone on the list to push back when they
feel the need. Besides, if my point of view gets too far out of step with
everyone else's I can always go off and follow my own vision, but because it
is open source I won't be taking the bat and ball with me.

<Rant off> 

ka