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

List:       kde-core-devel
Subject:    Re: [RFC] Unified Application Scripting Interface
From:       Christoph Cullmann <crossfire () babylon2k ! de>
Date:       2001-11-14 16:50:49
[Download RAW message or body]

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

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