On Thursday 03 November 2005 04:45 pm, Boudewijn Rempt wrote: > On Thursday 03 November 2005 22:19, Adam Treat wrote: > > Hi All, > > > > I would just like to point out that from discussions with the Ian, Aaron, > > Matt, and Ryan at OSDW, I think the future of scripting in KDE4 might > > follow a different path... > > > > There is talk of integrating the interpreter loading in the KParts > > framework. This would allow us to have, among other things, genuine > > KParts that could be written in several different languages as well as > > embedded within regular C++ applications. Regardless, I know Ian is > > hoping to have kjsembed available to all KDE applications for KDE4. I'll > > let Ian and Aaron expand here, but I don't want to see KOffice apps > > detour from the greater KDE scripting/binding community if it can be > > avoided. > > Me neither, but with one big proviso: previous attempts at adding scripting > to KOffice apps have always been halted because something great and KDE > wide was going to come along in a moment. It never came along, and KOffice > still doesn't have scripting. Five years or so after the Python community > got all excited because KOffice was going to have Python scripting > throughout... Yes, this was kind of a downer. Back in KDE 3.0 when I introduced our common bindings layer with dcop the python and perl camps basicly said "No". They didn't want to use DCOP because . At any rate no-one used it but Kate and KDevelop. To this day all we have is KJS, Python and Bash. Now that dbus wont work in process I am not sure how feasable it will be to continue this. Therefor, I have decided to go the ECMAScript route. > So if this KDE4 magic doesn't materialize, fully-formed, including a > usable, pluggable IDE for scripting and a sensible way for people to manage > their scripts, in a very short time period, say before March, I guess we'll > have to make do with what we can come up ourselves. Talk doesn't buy us > anything but even more delays. At Akademy it was decided that ECMAScript support was to be added at the core of KDE. KJSEmbed is moving into kde's core libraries and will provide a scripting and automation interface for all KDE applications. This will be done in a similar manner that dcop is done now. Now you may ask "Why ECMAScript? Why not Python? Why not " Well the answer is pretty much "No-one cares". If they cared about using all of the languages they would have jumped on the KScriptInterface back in 3.0. The point is ECMAScript is the most popular scripting language out there. TT has done a few studies, as well as the fact that pretty much every web page out there uses ECMAScript. Now beyond automation support there are KParts. KDevelop and KOffice are all currently extended with KParts. You can even write Python and Java KParts. This is Today, been that way for almost 2 years. Again, we don't push it, but that is another issue. The big technical issue is these abilities are not part of KParts itself. They use bootstrap KParts and for each interface you must provide a binding and a special KPart. This pretty much limits us to the basics. To get around this KParts needs to have more knowledge than just C++ shared libraries. The second technical hurdle (there are a few ideas to solve this currently) is to dynamicly provide the interface to the target language. This way you can just grab the interface description and run with it. This also needs to be solved to help get around BC issues in KPart interfaces. The last issue is the workbench and debugger. Now that Richard Moore and I have worked out many of the sticky bindings issues, we have started on the debugger and workbench. With the new Qt Designer and text editor interfaces we already have nice things like syntax highlighting and breakpoints. The next step is to hook up Designer actions to KJS methods. Maybe not by march, but we will be ready for KDE 4 with basic functionality. > Personally, I think the Sebastian Sauer's kross thing is pretty cool -- and > given that it works already, maybe something for the dreamers to take a > look at? And build upon kross, instead of reinventing the wheel again? I am not sure what kross gains us. It seems pretty unclear what use it really would be. Its way to heavy for automation scripting, and way to light for adding full plugins. > I miss Richard Dale in your cc-list, by the way... And maybe it would be a > good idea to also add Phil Thompson, Simon Edwards and Jim Bublitz to the > list of people who may have something interesting to say? They weren't at > OSDW, but they all have worked on scripting bindings for Qt and KDE, and > there isn't any larger KDE scripting/binding community than PyQt/KDE. Well there are two parts to this. The big one is that pretty much everyone has made a pretty obvious effort to not work together. Its either their way or their way. Really I am tired of it, and pretty much joined them in that optinion. The only difference is that I want to solve this in a manner so we don't have to care. By making KParts the interface, there only has to be one plugin layer, then the higher level language people just have to bind to the kparts interfaces, and build the proxy to forward the interface methods. Again PyQt, Java and KJSEmbed have already solved this. I think Ruby may have too, but I have not seen the bugger in action. The point is that once KParts is extended the fruits of Richard Dale will be sampled by every KDE application that uses KParts. (read pretty much every KDE application) One thing I would like to make clear. I am not against Kross, and I don't care if Kexi or Krita etc use it. They are the developers, and I have absolutely no control over them. I just wanted to let you guys know what is brewing down in the kdelibs guts. Cheers -ian reinhart geiser _______________________________________________ koffice-devel mailing list koffice-devel@kde.org https://mail.kde.org/mailman/listinfo/koffice-devel