From kde-core-devel Tue Nov 13 23:23:17 2001 From: Neil Stevens Date: Tue, 13 Nov 2001 23:23:17 +0000 To: kde-core-devel Subject: Re: [RFC] Unified Application Scripting Interface X-MARC-Message: https://marc.info/?l=kde-core-devel&m=100569357107353 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.