From kde-core-devel Sun Aug 28 20:29:43 2005 From: Sebastian Sauer Date: Sun, 28 Aug 2005 20:29:43 +0000 To: kde-core-devel Subject: Re: Malaga Discussions II Message-Id: <200508282229.47409.mail () dipe ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=112526102816806 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart4637191.1x1vqSghNt" --nextPart4637191.1x1vqSghNt Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi dear devels, > Please note though that this whole discussion was just about scripting > applicatins, neither about application development nor about heavy > plugins. There is still something left to discuss, but we did a start. http://lists.kde.org/?l=3Dkde-bindings&m=3D111854258600143&w=3D2 So, we've at the moment a bunch of different solutions for the same problem= ;=20 how to let Qt and other languages sleep together without paying alimony for= =20 ages. > After the topic of IPC and a little break (with group photo), we had > another discussion on the topic of scripting. We all agreed, that > scripting will be a major component of KDE4 and that we need to make sure > it's as good as possible. Would it be possible to get some more informations what "as good as possibl= e"=20 means? I am specialy interessted in the way kdebindings likes to go in near= =20 future and if my KDE7-joke in the link above is going to be reality (so,=20 rewrite kaliptus/smoke)? > The discussion went a bit back and forth on the topics 'Do we support only > one or several languages?' and 'If one, what language will that be?'. I > was actually the strongest supporter of having a multi-language strategy, > but in the end we left it to the developers there representing the actual > kdebindings authors (Ian, Rich and Richard Dale) and they kind of agreed > that one excellent binding is more than enough work.=20 Will this be a hard limit or is the 'one excellent binding' more something= =20 like 'KDE official supports only kjs-scripting, but if you like to experime= nt=20 we've some xyz bindings up too'? While I agree that one excellent binding is better then 101 partly working= =20 solutions, I hope the provided solution still permits using of other=20 (optional) bindings. So, design it as plugin-architektur with one official= =20 and fully supported plugin and leave that way the door open to the next=20 scripting-hype. I also would like to have, at least some day, some discussion how to merge= =20 kdebindings (wrote whole apps with scripting code) with some Kross-like=20 (embed scripting into a native Qt/KDE app) solution. > During the discussion=20 > on the numbers of languages to support it was already obvious that the > majority of developers wants kjs/qsa (which are said to differ only in > details so far) to be _that_ language. Quit funny cause the feedback I got last year from majority of users and=20 developers is, that they would like to have python or as preferred language instead of ecma like scripts. Anyway, that's personal taste and shows one more time, that we maybe should= =20 provide at least an optional way to leave the decision up to the potential= =20 developer who decides that he likes to write some other binding and got=20 frustrated by rewritting everything cause the existing scripting-solution i= s=20 qsa/kjs only and couldn't be reused and, more worse, applications are bind = to=20 qsa/kjs only. As already sayed above that doesn't mean to maintain a bunch of equivalent= =20 solutions for all existing interpreterlanguages like done today, rather the= n=20 providing a plugin-framework where somebody is able to put his own=20 scripting-binding in and use it as first class citizen even if not official= =20 supported by the KDE-project. =2D-=20 Sebastian Sauer aka dipesh[sebsauer] http://www.dipe.org/public_key.asc =46ingerprint: 8F1E 219B 16E6 4EC7 29CC F408 E193 65E2 9134 2221 Coder in http://www.koffice.org/kexi && http://www.kmldonkey.org --nextPart4637191.1x1vqSghNt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBDEh674ZNl4pE0IiERAthWAJ0TcuxlLZ5W111D16MROkt47OfGqgCeL1Hl 4p+LWYJpw3GX3UFajZ9Lf8k= =mud/ -----END PGP SIGNATURE----- --nextPart4637191.1x1vqSghNt--