GUIs - A Modest Proposal

[lkcl]

 there are _lots_ other options that i know of.  here are three of the
best:
[list of browser engines cut for brevity]

Although I didn't state it or even hint at it, I thought it was implied
and obvious-- though obviously I was wrong ;-) Oops!

i just wanted to do a "completeness" thing. apologies, there.

 

[lkcl]

[ye gods, i think this is the largest thread i've ever seen,

For python-list, it is possibly the longest this year, but definitely
not of all time ;-)

oh dearie me...

Can you expand on this? In brief, What were the 'failings' and were they
failings of the wrappers or the underlying toolkits?

the toolkits themselves. it's related to layout, to presentation, but
most of all to the implementation of the most basic widget - Label!
i actually got quite a long way with the qt4 port, after deciding to
deal with Label some other time, but then... ok, best to read on

* in neither gtk nor qt does there exist an "auto-layout" widget
that's equivalent to putting some <span /> DOM objects into a <div />,
to "flow" widgets that wrap around. yes, you can put words into a
Label and get them to flow, but not _widgets_.

* in neither gtk nor qt is HTML properly supported. qt has a
"RichText" widget but it's drastically limited.

* if in gtk you use PyGTKHTML2 you cannot expect it to take care of
its own width and height: you *have* to set width and height,
whereupon it immediately defeats the container's layout rules. (and i
just was not prepared to do "onresize" notification throughout the
entiiire UI wrapper toolkit, explicitly implementing W3C DOM rules in
terms of gtk or qt widgets, examining the size of the HTML text after
it had been drawn once, then... gaah. _no_.)

* GTKHTML3 does have "flow" capability, and even allows you to attach
widgets to the layout based on the "id" associated with bits of
HTML... but PyGTKHTML3 was dropped because webkit came along, and
everyone loved that so much they abandoned work on making python
wrappers to GTKHTML3.

* qt4 "RichText" _also_ fails to set width and height correctly and
requires explicit width and height setting, in pixels, which _again_
defeats container layout rules.

* in implementing a Pyjamas Grid widget using qt4, qt4's Grid widget
turned out to have a bug where the Layout Container classes could only
be added once. you're _supposed_ to be able to remove the widgets and
the Layout Containers and be able to re-add and re-lay-out the Grid,
but this failed miserably: the widgets _remained_ in-place and were
drawn _twice_. whoops.

* developing containers for both gtk and qt4 (one idea suggested to
solve some of the above problems) requires writing c code, and
adoption of the resultant containers by the respective communities. i
scratched that idea as unworkable.

* both gtk and qt4 can use webkit to display HTML. all i ****ing
wanted was a Label widget to display a word or a sentence, not an
entire whopping 12mb library with a runtime overhead of 6mb per
widget! so the use of pywebkitqt or pywebkitgtk _just_ to implement
pyjamas.ui.Label was absolutely out of the question.

* there's no way you can apply CSS stylesheets to gtk or qt4 (and
Qt4's RichText certainly doesn't support CSS). one developer i spoke
to at the time was working on exactly this, for gtk, but it was an
"afterthought" - and more of a GTK "theme". you certainly weren't
going to be able to add a CSS style on a per-id basis: only to
"classes" of widgets (Buttons etc.)

the second thing i had to consider was: how the hell am i going to
implement the embedded object tag, using gtk or qt4? although it _is_
possible to put ... ohh... what is it... you can embed ... something,
i can't remember what it is, but there's a way to put SWF into gtk
apps... well, i realised i was looking at this entirely the wrong way.

and that was the point at which i went, well wtf am i doing
considering shoe-horning a square peg into a round hole for, when i
can just use webkit with glib/gobject bindings and then python
bindings on top of that, or xulrunner with python-xpcom for that
matter, and dropped both gtk and qt4 like scalding hot coals and made
a beeline for webkit's source code. hulahop, the missing piece of the
"xulrunner" puzzle, turned up a few months later; once the dust had
settled from those, MSHTML actually turned out to be a breeze.

so i apologise if you were expecting a short answer, but gtk2 and qt4
_just_ don't cut the mustard. to be fair: whilst the pyjamas panels
are _supposed_ to be "stable" and "look the same on all engines", it
has to be said that, like GWT, we're relying on the "underlying
browser engines", and they're not entiiirely the same. you can't work
round _all_ browser bugs without _some_ significant effort.
fortunately, GWT with the staggering amount of money from google
behind them are focussing on doing exactly that, for GWT 2.0: writing
some layout panels which they will _guarantee_ will put the child
widgets in the right damn places, regardless of the browser engine
used.

.... we'll just wait until they've completed that work, and run a java-
to-python language translator on them, to turn them into python

Your point that browser widget sets have gotten a lot of competitive
commercial development is well taken. HTML5 will be even more
competitive with desktop. It certainly will be a nicee cross-platform
platform for. for instance, casual no-install open-source games.

yes. six so far. sudoku, lightout and asteroids. oh, and i did
three multi-player games: backgammon, rummikub and a generic "card-
playing" game. basically those three were merely moving tokens
around, no actual "rules" as such. the multiplayer games i haven't
released: they rely on a server.

although, there _is_ the possibility of porting that port of Quake
entirely to python - the one that was ported from java to GWT using
GWT-G3D, the wrapper around WebGL, and still ran at 30fps as
_javascript_ for goodness sake. that would sufficiently rock that i'm
giving it serious consideration.

i'm also looking forward to doing sound-effects, using the new HTML5

The latter has a link tohttp://pyjd.sourceforge.net/controls/

mmmm... maybe http://pyjs.org hmmm must sort that all out.

3 Suggestions:

1. 'type' is a built-in function. Reading a line like the above is
jarring to me. Use 'etype' for the event type.

2. I belive the above is equivalent to

     if etype in ("mousedown", "mouseup", "mousemove" "mouseover",
"mouseout"):

free bugreporting for pyjamas, yaaaay!
http://code.google.com/p/pyjamas/issues/detail?id=419

thank you terry.

which would fit github's (soft) limit and be clearer and faster.

3. Until you can persuade github to change, with a better explanation of
the needed change than I can give, keep to their line limit for code you
expect others to look at.

i consider that a bug in pyjamas: the lines shouldn't have gone over
79 chars. thanks for noticing.

I enjoyed the rest of the post. When I need to do gui stuff, I will
definitely look at pyjamas as an alternative to desktop-only kits.

it's not all roses: the free software pyjd dependencies are not
within our control (pywebkitgtk and xpcom+hulahop), but i can still
definitely recommend it. seems to be taking off, too, which is nice.

l.

 

[Stephen Hansen]

ok... analogy: when using g++ to compile c++ code, would you place
use of "asm" statements into the same sort of foot-shooting category?

Sure, dangerous tools exist for expert users who really, really know
what they're doing, to achieve things that would be either burdensome,
slow, or impossible in the higher level abstraction.

Its one thing for Python to make available foot-shooting tools(this is
good! I love ctypes, with care) for the developer, its another thing
entirely for it to shoot at the ground in the normal course of its
operation and hope it doesn't blow off any big toes.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJME/P3AAoJEKcbwptVWx/ltaQH/R57Y1ZyCyLg1TbC4eYiska9
gHLOF/gCmMCrxRoU3ZJR84LwKrGiSocaLCNsWdPFqCXWMHJqgDv9KI/4UHGBc1ZK
TZWcrlvsiL6oTdq6kUvA96RXj9KdURcbmWy8cWwJZBzsR9F66B9lG4dBHeKEM2oc
lYa/ve+M7AA91fGc6Wq/MYIl3PXxB/ShFyx5FJv3URiYRVQeTeQGPmtXQaUUS6EN
NttHlIRAw0tRfCaZuE5R7W0fWZd/NIlEOFAWZDQpJxvzDO8zIQIN29IQtxJkWofj
7YQ/wUkcCR09/yHDbopmrKiyU0fm/it8LWdWoO/bBAr9zw3y0uvSswFh8yH4dTY=
=DLdg
-----END PGP SIGNATURE-----

 

[geremy condra]

Having the absence of ctypes causing IDLE and turtle to stop working would
not be any worse, in a sense, though probably less expected.


I suppose one could develop in ctypes and then rewrite when 'stable', though
'stable' seldom is.

Would it be possible to write a program that converts a module that uses
ctypes to interface to a dll to a corresponding C extension program that
would compile to a drop in replacement extension module?

I did a similar thing using Java and the JNI, so this seems pretty plausible
to me. Having said that, it turned into a time sink very quickly, and there
were cases that I never got ironed out- I suspect the same would be true
here.

Geremy Condra

 

[Terry Reedy]

Which is to say, anyone who wants to remove it from *their* individual
custom installation should be able to do so, without disabling other
stdlib modules. I can imagine someone providing Python hosting on shared
machines might want to do so.

[snip]

removal of ctypes would be a big, big mistake. i trust that i have
misinterpreted the implication of what you're saying, martin.

I believe so. It was an independent 3rd party module of Thomas Heller
(who is still maintaining it) until recently and I have seen no
suggestion that it be removed in general from the PSF distribution.
Indeed, other distributions are implementing it also. Interface modules
written with ctypes are more portable to such than the same modules
written in C with, for instance, SWIG. For some people, is it also much
easier than SWIG. So it is an important addition to the stdlib.

Terry Jan Reedy

 

[Martin v. Loewis]

Notice that it's not (only) the functions itself, but also the

what's so bad about that? (this is a genuine, non-hostile, non-
rhetorical, non-sarcastic question).

(if the answer is "because you can't catch a segfault as a python
exception", then the question is repeated)

It's not only that a segfault may occur, but also that you may overwrite
arbitrary memory.

What's so bad about that? Nothing per se, but some people actually like
the property that you can't crash Python with pure Python code. Those
people would want to remove ctypes. It would be unfair to them if then
large parts of the standard library stopped working, in particular as
there is no real technical reason for them to stop working.

In particular, in some applications, untrusted code is executed. In
order to execute it, all "dangerous" API functions must be removed from
the interpreter, or appropriately wrapped. In these applications,
wrapping ctypes is not feasible, so only removal would work.

Regards,
Martin

 

[Martin v. Loewis]

ok... analogy: when using g++ to compile c++ code, would you place

use of "asm" statements into the same sort of foot-shooting category?

In a slightly different way, yes. There is no way of disabling inline
assembly in g++, so the analogy is not fully appropriate.

However, IIUC, using inline assembly in glibc (in particular, in header
files) requires a pure-C replacement version to be written for the case
inline assembly is not available.

Regards,
Martin

 

[Martin v. Loewis]

Am 12.06.2010 17:33, schrieb Stephen Hansen:

Come now, of course it is. It may not be problematic for *you*, but it
*is* problematic for a lot of people.

Sure, but a lot of people don't contribute to the standard library. They
can happily continue to use ctypes.

Please trust me that, *for the standard library*, the requirement to
write explicit wrappers never was a problem.

Maybe Cython'll be mature enough eventually that the stdlib could accept
Cython-based "C" extensions for such cases.

For Cython, the issue is rather the bootstrapping issue (would we need
to incorporate it if we have Cython code in CPython?). Perhaps the
answer is "no", assuming that the generated C file also gets checked
into Python (after all, autoconf is also not distributed along with Python).

Regards,
Martin

 

[Martin v. Loewis]

Would it be possible to write a program that converts a module that uses

ctypes to interface to a dll to a corresponding C extension program that
would compile to a drop in replacement extension module?

If implemented at all, I think the ctypes implementation itself could do
that. I.e. create all the function objects, let the Python script
declare the APIs, and then generate C code from those signatures.

The C code would then best be adjusted: you'd rather use the struct
declarations from the header files instead of the one you learned from
ctypes (which may be wrong, or processor-dependent, or
version-dependent). So a manual adjustment of header files would be
necessary afterwards.

Regards,
Martin

 

[Martin v. Loewis]

Am 12.06.2010 19:59, schrieb Stephen Hansen:

I believe the point is that it must be possible for users/admins to
remove it, and that this removal will not cause any other part of the
standard library to fail to function.

Exactly so. End users/packagers/admins may want to remove it.

Regards,
Martin

 

[Gregory Ewing]

Would it be possible to write a program that converts a module that uses
ctypes to interface to a dll to a corresponding C extension program that
would compile to a drop in replacement extension module?

Probably, but I don't see how that could be done automatically
in a way that ensured the result would be any safer than the
original ctypes-using version. If you preserve the semantics of
the Python code, you also preserve any bugs it might have.

 

[Gregory Ewing]

The important thing here isn't so much the exception as
the *traceback*.

When you've been programming in Python for a while, it's
easy to forget how much help the traceback is in tracking
down bugs. Suddenly being faced with having to do without
one comes as a rude shock.

 

[Gregory Ewing]

* in neither gtk nor qt does there exist an "auto-layout" widget
that's equivalent to putting some <span /> DOM objects into a <div />,
to "flow" widgets that wrap around.

You essentially seem to be complaining here that pqyqt and
pygtk are not HTML. They have their own auto-layout mechanisms
that do what they're designed to do well enough -- they just
happen to be based on a different model from HTML.

I'm far from convinced that HTML and CSS are the One True Way
to design GUIs these days, that web apps are about to take over
the world, etc. There is still a place for GUI toolkits that
are not based on the DOM, or whatever the W3C technology of
the month is.

 

[Gregory Ewing]

Its one thing for Python to make available foot-shooting tools(this is
good! I love ctypes, with care) for the developer, its another thing
entirely for it to shoot at the ground in the normal course of its
operation and hope it doesn't blow off any big toes.

I would hope that a module included in the stdlib was written
by a sufficiently skilled marksman that it can successfully
carry out ground-targeting without loss of appendages. And I'd
better stop before this metaphor undergoes a sudden catastrophic
stress fracture.

Seriously, though, if you can't trust someone to write safe
ctypes-using code, can you trust them to write safe C code any
better? Especially considering that the equivalent C code is
much longer and more tedious to write, with attendant risk of
the author losing concentration and making a mistake.

 

[Stephen Hansen]

The important thing here isn't so much the exception as
the *traceback*.

When you've been programming in Python for a while, it's
easy to forget how much help the traceback is in tracking
down bugs. Suddenly being faced with having to do without
one comes as a rude shock.

Oh, agreed absolutely.

The exception just gets things started. If its something you're prepared
for, you can recover just fine.

Worst case scenario, you get a traceback.

And you pity those people who have to have gdb running before hand and
get a stack trace ;-)


--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJMFHkSAAoJEKcbwptVWx/lwk8H/3ala1cdO9Jhohrmth4jLx+4
0gVSdb3QfUSPI9JZh9neHrYkfe1BiP3tVqHQsaMgGAsuKF39n7bYjQdahZJRwub2
itsTe+HvWiUYtqkUcxOJvQJHxeLM4tfsy3caYlIfCtWHbY0rVzTK9vMt1M6tU1ps
BZQrbEznJq4s1+20yP/r5mVhdUF3+ZgLEMZ6GqOuBrcJ688IcnVw5XMXGcrOOAgB
pXXcL3EIAYdE/T8j7fG0r0pRQ0h05A4NY745gLEleLcso+gfBSOekB2Vm31z+huH
jdNHVAmHzWsxojHxNSCgX+rCIMJ1k02zx/ZVtN2ADslstVwrSGGsdCtyZG8WupU=
=qLSV
-----END PGP SIGNATURE-----

 

[Stephen Hansen]

I would hope that a module included in the stdlib was written
by a sufficiently skilled marksman that it can successfully
carry out ground-targeting without loss of appendages. And I'd
better stop before this metaphor undergoes a sudden catastrophic
stress fracture.

Wow, I had difficulty taking the metaphor as far as I did. I bow to you,
sir!

Seriously, though, if you can't trust someone to write safe
ctypes-using code, can you trust them to write safe C code any
better? Especially considering that the equivalent C code is
much longer and more tedious to write, with attendant risk of
the author losing concentration and making a mistake.

I don't disagree at all; in fact I consider the use of ctypes entirely
fine, if the devs doing it take sufficient care.

But I do get the point of the policy, even though in certain cases --
namely, win32 api access -- it pains me and I wish there could be a
middle-way which gave me the best of both worlds.

If ctypes is in place, then anything can use ctypes. Clearly, that stuff
which may make it into the stdlib will be best of breed from a safety
stand point, and they're using ctypes just as a maintenance relief and
not due to lack of ability or knowledge.

But now -everything- has access to ctypes. And that's sort of dangerous.
I've been in environments where corporate / security interests were such
that they'd like to /not/ have ctypes, as the safety of Python was a key
selling point. Removing ctypes preserves that safety. But you can't have
the stdlib breaking then, with only certain parts working.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJMFHrdAAoJEKcbwptVWx/liGcH/i5MfK9DNVz9Rd2ZIxjmFTfk
pa52qrJUnDQaz0azlfbZXqVymAhquf7GL3YnVFtdKx6jSeQ0Ta+iVz46dOiIABew
hUFffWK4LRwbVkaJuBVTU4GVEaXo1vDaDhaC/WBdl2Jjzigb5lclw2n/1KxiHvyj
zu/sZJgm/0/9fibVrxZVNVGKKUbpAb32/Aa5m/oVI+SAmED0Uny8kNg1t/X2Nsek
fMz7fMpDkzQP/DS304pvl1/zobzl3SDiMqG6ZgYcG7kmNoI4W2WXJ5578qom7bTp
9RuUCGg+lV7S/1dEaOIzAQks8t8jdq/7Pz/Bj/iIbdc1Uf77JHuuHLNUFnE2+eU=
=+0Bi
-----END PGP SIGNATURE-----

 

[Stephen Hansen]

You essentially seem to be complaining here that pqyqt and
pygtk are not HTML. They have their own auto-layout mechanisms
that do what they're designed to do well enough -- they just
happen to be based on a different model from HTML.

I'm far from convinced that HTML and CSS are the One True Way
to design GUIs these days, that web apps are about to take over
the world, etc. There is still a place for GUI toolkits that
are not based on the DOM, or whatever the W3C technology of
the month is.

Agreed. While "web interfaces" have a certain appeal, and definite
strengths, they have difficulties as well.

Although I have never used gtk directly, I do use wxWidgets/wxPython
extensively, and its Linux-port is GTK based. Its a serious learning
curve, I do freely admit. But once I began to think in wx, it works well.

And all of my wxPython apps use dynamic / "auto-layout" sort of
orientation and sizing without any sort of explicit management. So its
clearly -possible-. Maybe its entirely done in wx, and wx does all the
pain that lkcl went through trying to get gtk to do it. But that seems
unlikely.

But I don't actually know, one way or the other.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJMFHucAAoJEKcbwptVWx/lISIH+wYpxoB9Fs1/LAAtJA6iuXUk
ubOhklM7vDfReF48OyqLPw35l6J+CtYJmDXE0nJbn/R051rZnPnqTpI27HGPO36R
zoZ5E6E68qOvO0z8g2LykUPsiFWZ43gBoh0wbP63NCyNr3/BmBPwF5okXRz/LJVh
7e6ZaFwWA1ItYjZm1hiLikm6bdTjqzm1C3PUmUPP49NMGffkWQczA7GInjIYRjFX
z53HW+L1xMst4TNYovdDeA8uz8q6x9H9fSJCf4BEciujnZjh7LpblK+Hupfp4n96
+zGTuchiU56KqwgPzvU94O/+xbyGV107CP1SaSn/hEDivT3XwOna4mzNh6VA83M=
=EGnc
-----END PGP SIGNATURE-----

 

[Stephen Hansen]

Probably, but I don't see how that could be done automatically
in a way that ensured the result would be any safer than the
original ctypes-using version. If you preserve the semantics of
the Python code, you also preserve any bugs it might have.

I dunno. This is exactly what Cython does. I have exactly one extension
module in Cython that uses it, and so very limited experience-- but it
seems very solid and very safe, from my admittedly limited attempts at
breaking it.

True, Cython != Python. But its close enough that Python programmers can
do it without knowing the pain of C, just following a certain limited
Python subset. Its very doable, very accessible, and *seems* to address
this very issue.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJMFHwaAAoJEKcbwptVWx/lIi8H/Ao3AlzM3/6kaqbCNZ8JFCin
AXsG3LBqX6fqj3q53U4V2oU2qh3XHjqpe8n/2co9NbThUZHYM0QhNea2XcGP7F0h
cAGZnOstF9k//DGztvGvdM+vd5ojYAaw15iYp/gwuzz1Ojc+09q6AT1WS7srU2MM
TMmo3Ix7g2NQBL1MruTo7AXBjehEkq66+bhvMapNrYRqmO24HsuJFWA7Rc3uwWg6
e3X92srfL5ua6xp7Yyi/XQmLki3PtCySMzMDMMKG311+JMAnYxjjh22S3h1KISlj
DG+Y92baKiJOF1XzOCrEfp6Ab/uYIHdRkuPreZYhnSN4hg6nG+aFBMKATDDlG+k=
=+LmF
-----END PGP SIGNATURE-----

 

[Jeremy Sanders]

* in neither gtk nor qt does there exist an "auto-layout" widget
that's equivalent to putting some <span /> DOM objects into a <div />,
to "flow" widgets that wrap around. yes, you can put words into a
Label and get them to flow, but not _widgets_.

I'm pretty sure in PyQt4 that you can derive your own layout class from
QLayout to get what you want. No C++ is required. You can easily extend PyQt
without using C++.

There is even an example in the PyQt examples which does something similar
to what you want: see examples/layouts/flowlayout.py

Personally I find the Qt layout to be much better than anything provided by
CSS and HTML. Personally I'd rather be writing complex C++ templates that
those, though it does give you a feeling of achievement when you get what
you want with CSS.

Jeremy

 

[lkcl]

You essentially seem to be complaining here that pqyqt and
pygtk are not HTML.

no, i'm not complaining - i'm pointing out that in my meandering
experiences to pick suitable technology, i found, very simply, that
both pyqt and pygtk didn't cut it. that's not a "complaint". so i'm
stating/implying that from the experience that i had with both
toolkits, pyqt and pygtk were not as easy to create layouts or widgets
with (but caveat: jeremy kindly points out that in pyqt there is
examples/layouts/flowlayout.py)

another way to put that: i'm stating that, in my search for suitable
technology to implement W3C-standards-like behaviour, such that i
could map an existing widget set API on top of it, i found both pygtk
and pyqt4's "bang per buck" as far as both extensibility and existing
functionality was concerned to be below an acceptable threshold *for
me*.

statement of "personal experience". not "complaint".

They have their own auto-layout mechanisms
that do what they're designed to do well enough -- they just
happen to be based on a different model from HTML.

one which turns out to be sufficiently different from HTML as to make
it beyond my time and patience to implement one in terms of the
other. again - that's not a "complaint", just a statement that i
prefer to leverage technologies where the "bang per buck" or better
"bang per line-of-code" is way above average.

I'm far from convinced that HTML and CSS are the One True Way
to design GUIs these days,

if you have "HTML the fileformat" and "CSS the fileformat" in mind
when saying that, i can tell you right now that they're not.
fortunately, with the W3C DOM functions exposing properties and style
attributes, it's possible to manipulate the exact same attributes that
CSS and HTML "files" provide access to, using a declarative
programming style.

so with pyjamas you get the best of both worlds. (and i've found
that the combination of the advanced features of python, and
declarative DOM manipulation, is _definitely_ worthwhile exploring,
and i definitely find it to be far more powerful than pyqt4 or pygtk
programming).

it's the exact same thing for SVG image file-format. i'm
_definitely_ not convinced that "SVG the image fileformat" is The One
True Way to design images - but i'm equally definitely convinced of
the power of SVG manipulation libraries which allow for the creation
SVG images using declarative programming.

but, all that having been said, and returning to "HTML and CSS (the
fileformats)", there's a lot to be said for convincing people who are
stuck in those worlds of the benefits and freedom of declarative
programming... _without_ having to get involved directly in
javascript.

that web apps are about to take over
the world, etc. There is still a place for GUI toolkits that
are not based on the DOM,

that there definitely are.

or whatever the W3C technology of the month is.

don't underestimate how much time and money is going into the W3C
standards! and remember, someone's got to implement them, so the
actual proof of the pudding is not what the W3C thinks but whether the
technology ends up actually in the hands of users and is successful
_for users_.

l.