[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Using scripting languages for KDE4 main modules
From:       Leo Savernik <l.savernik () aon ! at>
Date:       2006-10-02 17:38:09
Message-ID: 200610021938.09864.l.savernik () aon ! at
[Download RAW message or body]

Am Montag, 2. Oktober 2006 11:29 schrieb Boudewijn Rempt:
> This whole discussion is confused from the start. The big thing about
> extending applications with scripting is not creating features for
> distribution: it is making it possible for people to extend the
> functionality of their application locally. Like the molecular biologist
> who scripts kword and krita to load his research data and create
> illustrations automatically. For that use case it _is_ important to offer a
> variety of language choices because such a domain specialist is not going
> to learn a new language just because the kde gurus tell him so. Same with
> kicker: if I want to add a quick script to regularly poll some webservice
> and display the result on the panel, I would like to do that in the
> language I'm most proficient with.

I fully agree.
>
> KOffice is and will be scriptable in any language for which there's a kross
> plugin. And currently we deliver python and ruby plugins, and work is being
> done on a kjs plugin. And that's a good thing.

This usage of scripts isn't problematic either as long as those plugins are 
not necessary for making KOffice work. I. e. using python to implement filter 
"superdither" isn't problematic. OTOH, using python to load koffice documents 
is (not that it's going to happen, but you get the point).
>
> And we're talking about application scripting again, instead of writing
> applications in scripting languages.

Indeed, and I don't oppose custom extensibility by scriptability in any way.
>
> > Therefore I suggest that no core component and core application that *is
> > needed to make KDE being perceived as fully functional* is written in any
> > scripting language except those shipped within KDE (kjsembed), and even
> > that one shouldn't be used too liberally.
>
> Looking back the the 3.x times, I see ksjembed having been available all
> the time and precious little use being made of it. It hasn't enabled easy
> desktop scripting. It hasn't automatically added scripting to every
> application. Applications that are kjsembed enabled (kdevelop, are there
> more?) don't make it easy to add scripts. In my view, kjsembed has failed
> to provide scripting to KDE. There aren't any applications shipped with kde
> that are stand-alone kjsembed scripts -- or at least, none that I am aware
> of. I think the use-kjsembed-like-it-or-leave-it approach is flawed.

Here, it was the lack of a proper VBA-like script editor with syntax 
highlighting and fully working code completion. Take MS-Office as an example 
on how to do it right. By KDE 4, KDevelop should have the necessary 
infrastructure in place.

mfg
	Leo
[prev in list] [next in list] [prev in thread] [next in thread]