Hi, Excuse me for late reply to this thread. I'll try to comment older notes too.
Citát Alex Perez <[EMAIL PROTECTED]>: > M. Uli Kusterer wrote: > > At 14:05 Uhr +0100 24.04.2005, David Chisnall wrote: > > > >> Perhaps we could provide a lightweight scripting language, with a UI > >> like Automator (or, at least, how I assume Automator works - I haven't > >> actually used it) for combining components, perhaps built on > >> StepTalk? `Applications' would be sets of components, perhaps > >> including some fairly specialised ones that probably won't be used > >> elsewhere, combined using a simple script. > > This is last piece of puzzle for StepTalk 1.0 to be completed. For this one needs kind of semi-persistent stand-alone out-of-application :-) environment. I already did the design, however I have no time to implement it. If there is someone voulenteering i can give him more pointers. Something is already in sources, something is here: http://mediawiki.gnustep.org/index.php/StepTalk_TODO It is not difficult, just a bit time consuming, routine work. Good for someone who would like to learn more about StepTalk internals :-) > > > > This may be a neat feature, but I think it's an entirely separate > > project from the main desktop. AFAIK, Automator currently consists of an > > API specification that lets you create a simple GUI for each task > > component an application wants to expose, which it can then display. > > Most of this is done via AppleScript and AppleEvents. GNUstep could > > probably do similarly using DO and StepTalk. > > Why separate project? Perhaps StepTalk yes, but mechanisms for advertising objects and their actions that can be handled by users through scripts should be included in the core frameworks. Mechanisms should include: class descriptions, definition of public/private methods, where public = scriptable, definition of public objects, ... For the DO & StepTalk see above about scriptable environments. > > Remember, there already are a number of GNUstep applications that use > > the traditional style. The easier we make it for them to add Etoile > > features to their apps without having to rewrite them from the ground > > up, the more likely it is they'll do so. Same goes for future ports of > > Cocoa applications. If we require StepTalk to build a GUI app from > > components, people are locked into GNUstep and StepTalk. But if it's > > just a feature of a GNUstep application, you can choose the language > > that fits your task. Java, ObjC, StepTalk, Python? No problem. > I'll comment on "If we require StepTalk to build a GUI app...". Nor StepTalk, nor any other scripting mechanism should not be required to build any application. Apps should only advertise, as mentioned before, their capabilities. Either as property lists, text files, or any by other means. It is like apps would say: "I know how to do this and that and I provide following objects you can contact to do what you like". > Uli, I think there's a misunderstanding here...StepTalk is not a > language, nor is the StepTalk framework only limited to supporting > Smalltalk. StepTalk can work with many different scripting languages, > such as Ruby and others, it's just that nobody has ever written a > language bundle to support that. StepTalk, itself, however, is designed > in a modular way so as to intentionally facilitate the support of other > languages. > Alex, thanks for explanation. StepTalk is rather an abstraction layer between scripting language and applications. Regards, Stefan Urbanek -- http://stefan.agentfarms.net First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi
