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

List:       kde-core-devel
Subject:    Re: [RFC] Unified Application Scripting Interface
From:       Neil Stevens <neil () qualityassistant ! com>
Date:       2001-11-13 23:23:17
[Download RAW message or body]

On Tuesday November 13, 2001 04:42, ian reinhart geiser wrote:
> On Tuesday 13 November 2001 04:25 am, Cornelius Schumacher wrote about
> Re:
>
> [RFC] Unified Application Scripting Interface:
> > What applications do you have in mind for your scripting interface? It
> > would probably help to get a better understanding, if you could
> > provide some use cases.
>
> Example for KDE PIM:
> 	A secretary has access to 50 staff KOrganizer calenders and every
> morning she needs to get an idea of who is doing what.  For her to open
> 50 calenders would take all morning.  So a staff developer could write a
> simple shell script that would tell KOrganizer via dcop to iterate
> through a list of calenders and open them up.  Apply a filter to only
> show a certain event and then save the calender to an HTML file in a
> certain directory.  Now this process assumes that KOrganizer has the
> needed dcop interfaces.

This sounds like a completly contrived example, and even so the scripting 
would be a poor hack workaround.  How is the script going to actualy 
display the data?  In a slide show format, 10 seconds per person?  
pPopping a dialog (right in the way of the actual calendar), and going to 
the next one after the user clicks?

Don't you have any real, user-requested examples that you're using as the 
test cases for your design?  Solving a problem when you don't know what 
the problem is seems hard.

I'm as sick of this guy being brought up as anyone, but this user example 
right here reminds me of an article by Joel Spolsky at 
http://joelonsoftware.com/articles/fog0000000075.html that discusses some 
mistakes nearly made in the design of scripting in MS Excel.

> The idea here is that as far as the secretary knows she is using
> KOrganizer. We are allowing end users and developers to expand on the
> features of current applications via automation.
>
> The next stage involves using a shared parent object.  This way the
> script using python/ruby or perl can access the parent objects public
> member functions.  This requires about as much preparation as setting up
> dcop interfaces in an application so it is really up to the developer. 
> The advantage of this shared parent object or "object twin" is that you
> can pass large objects back and forth without the overhead it causes to
> dcop.  You can also allow more flexibility in the nature of the script
> plug in.'

So basically, your whole system is going to count on the dynamic typing of 
the scripting language used?  Runtime discovery of the application's 
interface?

> I hope this clears up some of your questions.  I designed most of my
> examples around Kate, and KDevelop because this was the source I was
> most familiar with.

Makes sense.  Kate and KDevelop users are coders, so are more likely to be 
able to write complicated scripts.  That'd be much more realistic than a 
secretary scripting a morning routine.

Perhaps this is something best implemented as a Kate plugin first, and 
then generalized after users bang on it, and send back feedback on how, 
and how often it will actually be used?

-- 
Neil Stevens
neil@qualityassistant.com

Don't think of a bug as a problem.  Think of it as a call to action.

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