--nextPart14691362.QJUceEQKEU
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Saturday 07 October 2006 8:58, Boudewijn Rempt wrote:
> On Saturday 07 October 2006 16:42, Aaron J. Seigo wrote:
> > =C2=A0- a LOT of people know it from such applications as the web
>
> I see this assertion a lot, and I really don't know whether it's right.
> There are many web-people who have a little javascript -- but are they the
> people who want to write a script to automate something in KMail? I don't

i would suggest that the examples of firefox's extensions and apple's=20
dashboard proves the point quite nicely. if that isn't enough proof for you=
=20
in addition to the logic behind it then i'd suggest you simply don't want t=
o=20
be convinced =3D) now, i understand that when some of us were making the ca=
se=20
for js in application scripting there weren't such obvious and visible=20
success stories out there, but now there are.

> the majority of Quanta users know more Javascript than any other language=
=20
> except for php, but KWord users? Is javascript at all used outside webpag=
es=20
> and OS X's desktop widgets?

this is a mildly silly question isn't it? i mean, you're essentially asking=
 if=20
there's any use case besides the web, MacOS's desktop, firefox and=20
thunderbird, etc... in other words, besides all those great examples, are=20
there any others? if you honestly sum it up, you'll see that there are few,=
=20
if any, languages that have as wide use and success as javascript for these=
=20
sorts of tasks. and the reasons are pretty obvious for it imho (i listed th=
em=20
in my last email)

you'll also find it in various desktop apps here and there (google can help=
).=20
we have both kjsembed and qsa to draw upon. it starts to seem a bit obvious=
,=20
to be honest.

so ... what is the benefit of having a preferred language for app automatio=
n?=20
and what are the limitations it brings?

well, it allows users to learn one language and apply it in multiple places=
=2E=20
it would really suck if a user would need to learn one language to script=20
koffice, another to script the workspace, another to script kmail, etc. all=
=20
because application developers (that's us) couldn't see past our own person=
al=20
preferences for things instead of doing what is best for those who use all =
of=20
our applications together.

does this mean that one couldn't provide python for application scripting i=
f=20
js was the chosen default? of course one can. but the default js should als=
o=20
be supported. in other words, if one supports scripting js (or whatever is=
=20
the default) must be supported and any other languages you wish to support=
=20
can be provided in addition to that.

for application development, of course, it's a completely different story=20
altogether and i agree that javascript is not the best language to pick fro=
m=20
and that we should, if we can, support a plethora of languages. that said,=
=20
i'd prefer to see us support one or two WELL than five in a half-assed=20
manner. i'd also suggest that java is a pretty important language to suppor=
t.=20
i'd be overwhelmingly proud of this project if we managed to have even bett=
er=20
java, python and ruby app support than we did in kde3. i'd settle for one=20
python app in an official kde module though ;)


p.s. and before someone jumps out with the bleeding obvious: yes, there wil=
l=20
be corner cases where javascript is completely, wholly and absolutely=20
inappropriate due to the problem domain of the application (e.g. for instan=
ce=20
a scientific/math domain where there is already a standard language for=20
working within that domain). but let's not derail on corner cases and rathe=
r=20
concentrate on the core uses.


=2D-=20
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

=46ull time KDE developer sponsored by Trolltech (http://www.trolltech.com)

--nextPart14691362.QJUceEQKEU
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBFJ9Z61rcusafx20MRAkakAJ0SThiFedxuGHMAGiJqaqhYFOeLJgCghIAn
upcuBTGq6rjmhAcL8Oyxqro=
=vUd0
-----END PGP SIGNATURE-----

--nextPart14691362.QJUceEQKEU--