From kde-core-devel Wed Nov 14 16:50:49 2001 From: Christoph Cullmann Date: Wed, 14 Nov 2001 16:50:49 +0000 To: kde-core-devel Subject: Re: [RFC] Unified Application Scripting Interface X-MARC-Message: https://marc.info/?l=kde-core-devel&m=100575657100354 Am Wednesday 14 November 2001 17:17 schrieb Simon Hausmann: > On Wed, Nov 14, 2001 at 09:16:13AM -0500, ian reinhart geiser wrote: > > On Wednesday 14 November 2001 05:30 am, Harri Porten wrote about Re: > > [RFC] > > > > Unified Application Scripting Interface: > > > A few comments/questions about the code that I've see in the current > > > CVS. > > > > > > a) Why is ScriptLoader limited to KMainWindow as parent type? > > > (counter example: that API makes it impossible to use it in > > > kword or any other koffice component) > > > > > > b) All the scripts currently seem to leak. Maybe setting the > > > autoDelete property of 'm_scripts' would be a good idea > > > (or much simpler: re-use QObject's > > > parent-deletes-children-mechanism) > > > > > > c) Wouldn't it make sense to put the 'ScriptLoader' class into the > > > KDE namespace by K-prefixing' it? > > > > The scriptloader currently is nothing more than a testbed so that I can > > test the scriptinterface implementation. Ideally it will be re-written > > to provide more features to manage the scripts. This is a first attempt > > and I am in real need of assistance with createing a useful loader here. > > The namespace makes perfect sense, along with the removing the parent > > object of KMainWindow. As the week progresses I hope to have a more > > useful and flexable loader created. > > > > Ideally I want to split the class into two, a script manager and > > convenence class for adding scripts to the UI. I was hopeing that as > > others looked at the code they would be able to provide input and this > > process could speed up. > > Splitting up sounds like an interesting idea. For a plugin interface (here "script plugin") interface with such an architectur, take a look at how kate handles its plugins ;) They are seperated into GUI<->object (and thats the reason I must only load the plugin once and can add it to multiple kate mainwindows) > > > > d) Why does ScriptInterface have a setParent method? Why not re-use > > > what you already have: QObject. Allocate the component > > > implementing the ScriptInterface with the desired parent object > > > as..erhm..parent object, as done through the factory? > > > (another idea, in combination with b) , would be to allocate the > > > components implementing the KScriptInterface with the script > > > loader as parent object and to provide a pair of 'setScriptParent' / > > > 'scriptParent' -- maybe even the naming 'parent' is misleading > > > here) > > > > Yes in retrospect the name is misleading. I got stuck because I could > > not think of a better name. This fucntions/objects purpose that it will > > be the object that is shared between the C++ appliaction and the script > > engine. This will allow the jsembed and the python script engines to > > directly access the main applications objects without using dcop methods. > > The reason this is not done at the construction time is that the > > developer may want to dynamicly set what object is shared to the script > > engine. If you have a suggestion for a better name please share. My > > first names "ObjectTwin" and "ObjectProxy" seemed also very vuage. > > Hmm, I'm really bad in choosing names. Just an idea, how about > 'Target' ? > > > > g) Why does getScripts() (which lacks a const specifier btw :) ) > > > return an action object? How about 'KAction *scriptAction() > > > const' along with an accessor to retrieve a list of QObjects that > > > implement the KScriptInterface? > > > (just an idea :) > > > > The idea behind this method is I wanted a dynamic way to add the script > > actions to the UI. Since I did not want to dork with XML files I decided > > the SelectAction seemed the most correct. It will allow the user to > > overview all of the Scripts in a menu and then select the one they wish > > to use. Reall this is only an convinence method until the class is > > fixed. > > (I guess the user might also want to have a dialog for > configuring/installing scripts and some place where to get real > information what a script is doing (documentation) - a plain menu > entry is indeed not enough) > > > > and isn't simply called scripts() ? > > > > Ah QT/KDE nameing vs Ian Geiser Part XXVX. I am a firm beliver in > > get/set for accessors and mutatior. And blah() type function names for > > static members. Really this makes no difference to me, it is just style > > and I have sometimes forget to adhere. I guess the most clear QT/KDE > > name for this class would be scriptActions(), yes? > > I guess anything that starts with a lowercase character ;-) > > (we really need a kde-choosing-names-for-variables@kde.org list :-) > > > > j) is the errors(QString messages) meant to signal multiple errors ? > > > The docu talks about "[a] current error message". Why not use a list of > > > strings if the signature is right but the docu is wrong ? > > > > Docs are fight the signature is wrong. I will change it to: > > void currentError(QStirng message); > > and > > void currentOutput(QString message); > > > > > k) what is the error code passed by done(int errorCode) ? An arbritrary > > > integer or an enum that could be defined in the header ? > > > > Currently it is return codes from KProcess or Python. These are usually > > and int... I guess I need to look at this more, the script engine may > > have to return a more meaningful string that can be set to a status bar > > or something. > > > > I hope this answers some of your questions here, this is really a work in > > progress so I hope to see this take some real usability within the next > > week. > > I might be the only one, but maybe all this should be delayed a > little bit until after 3.0. You say yourself that it is pretty much > work in progress, and in contrast to that we're feature frozen right now. > If developed during an unfrozen time (after 3.0) it might result in an > overall better technology. > > (this is just a thought, of course. In generally I find this very > exciting stuff with a lot of potential (I like Waldo's idea of > adding external buttons) - and in the end the one who codes decides, > of course :-) > > Simon -- | | / / - get an edge in editing - | | / / »»»» GET KATE «««« | |/ / a fast and capable multiple document, | \ multiple view text editor for KDE | |\ \ cullmann@kde.org | | \ \ http://kate.sf.net