Using scripting languages for KDE4 main modules
boud at valdyas.org
Tue Oct 3 22:30:21 BST 2006
On Tuesday 03 October 2006 23:10, Alexander Neundorf wrote:
> On Tuesday 03 October 2006 22:53, Michael Pyne wrote:
> > On Tuesday 03 October 2006 16:46, Guillaume Laurent wrote:
> > > On Tuesday 03 October 2006 18:34, Gary L. Greene Jr. wrote:
> > > > Personally, I think this idea of selecting an "official" application
> > > > scripting language is a bad idea, as that again raises the bar for
> > > > new developers.
> > >
> > > See Coolo's message on the matter. Maintaining multiple bindings is not
> > > an option.
> > Sure it is, but I don't think it's an option for an applications that are
> > to be distributed ('blessed') by KDE.
> So let the beatings begin !
> Today: Python vs. Ruby
> P.S. seriously, I don't think we can choose one over the other
No... And I think that given the enormous breadth and depth of applications,
utilities and libraries found in the various kde modules and subprojects,
it's impossible to impose any arbitrary limitation. Plus, there's a good deal
of independence. If the majority of koffice developers decides to create
something we don't have (hard to think of anything...) in Lisp, we'll jolly
well put it in the koffice distribution. The contingency is extremely remote,
but it's rather more likely that python, ruby and other languages will appear
in kde games or education. And it's extremely unlikely that we'll have a
perl-based replacement for kdm in kdebase.
Maybe it would be enough for apps written in rad languages to get
an "official" status to create kde-games-ruby, kde-games-python etc (as needs
arises), modules that will be packaged together with the respective bindings
(and we have volunteers for pyhon and ruby, right?) and put in the same
release as the rest of kde.
That way it'll be available for distribution, but the core won't depend on any
binding being present, so no harm done for those who don't want scripting
language slowing their desktop down. It's different from the current
kde-bindings module because apps that use those bindings don't get included
in a full kde release and so seldom get distributed, and it makes it really
easy for application developers to get started using something that's just a
little more productive than C++.
This should work, I think, for apps written in "scripting languages". The
extension scripting language is another issue, and here I think kross should
unannounced scripting bof. Not that we should, necessarily, code features in
scripts included in the kde (not koffice) release, I'm fine with mandatory
know. Programmers don't mind changing languages more often than their
underwear, but to demand from users that they learn another language just to
script KMail is, well, too WordPerfect 4.2 for words.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
More information about the kde-core-devel