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

List:       kde-core-devel
Subject:    Re: [RFC] Unified Application Scripting Interface
From:       ian reinhart geiser <geiseri () yahoo ! com>
Date:       2001-11-14 17:02:34
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 14 November 2001 11:17 am, Simon Hausmann wrote about Re: [RFC] 
Unified Application Scripting Interface:
[...]
>
> Splitting up sounds like an interesting idea.
>
	I think it makes the most sense for future maintainablity I guess I am "now" 
of the opinon that the manager should only keep track of the plugings, and 
there can be other classes that will make using the scripts easier.

[..]
>
> Hmm, I'm really bad in choosing names. Just an idea, how about
> 'Target' ?
>
	I fail to come up with a meaingful name that is not inanely long:
		ObjectToMirrorInPluginAndApp()
	I think target  is still to ambigus...  I think will call it proxyObject and 
then just include about 50 lines of documentation talking about how it 
"should" be implemented and used.  Really this is where self documenting code 
breaks down :P

> > > 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)
>

	this is where the separation of the script manager could be handy.  
developers can then make dialogs to add and remove scripts from the 
application at runtime then.  really I think if we provide both a simple 
class for adding it quickly this would target a different audence than the 
guys who would like to just use the plugin manager to make something more 
extravagent.

> > > 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 :-)
>

actually i think it just involved me reading the style guides until my brain 
just dropps its old habbits...

[..]
> > 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 :-)

This is a valid concern.  I am very excited about this and have put a great 
deal of work into it.  I really would like to see it in KDE 3.0 but if this 
presents too many issues with implementing properly then I am willing to pull 
it from CVS.

In reality the interface itself only lacks more verbose documentation.  It is 
for all intents and purposes complete.  My big issue is the scriptloader 
class.  This is not needed for implementation of the script engines, but it 
will make using them in applications much easier. 

I think once Rich does a script engine for KJSEmbed we will see if really 
this is ready for KDE 3.0.  I have done a simple shell script engine, but 
again it is not fair for me to asses how easy my interface is for other 
developers.  I guess so far I have gotten positive response overall so I 
think it is worth giving this a try.    

I personally am looking forward to the abilitly to code project management 
scipts for Kate and KDevelop...  

- -ian reinhart geiser
- -- 
:-- Ian Reinhart Geiser --:
GPG Key: D6A6 7E16 13A9 B5A7 9E18 D1A7 3F2E B64D 19BC 76F8
===========================================================
Leveraging always beats prototyping.
===========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE78qOrPy62TRm8dvgRAuaOAKCMy/sDVWCYiM/5DbXhDlIe7idiUgCeO1zJ
kuuoV5uEKKLyaVRXPxoHUTw=
=KZYH
-----END PGP SIGNATURE-----

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