Hi,
First: my latest StepTalk code can be downloaded here:
http://stefan.agentfarms.net/Download/GNUstep/StepTalk/
StepTalk-200703.zip
It is few months old...
On 18.3.2007, at 11:29, Isaiah Beerbower wrote:
<snip>
The cross-application scripting was not finished in StepTalk -
this was the
last
step needed for the 1.0 release :-) However, StepTalk is designed
with this
cross-application environment in mind. If someone would be
interested in
finishing it I can provide him with pointers to the code and more
information.
I am interested in finishing it. (: Any pointers/information would
be helpful. The cross-application scripting would be for writing
scripts which talk to more than one app at a time, correct? I've
looked through the sources of StepTalk and have seen an unused
class called STEnvironmentServer. Is this part of the cross-
application scripting?
STEnvironmentServer was last step. See stenvironment tool in Tools
directory in GNUstep sources (not in mine/the latest) - that is it.
It is not polished, therefore code was not moved to the class.
Also see my first draft :-)
http://stefan.agentfarms.net/Download/GNUstep/StepTalk/
Conversation.app.JPG
The diagram is first idea of an application controlling the
environments. The intention was a little bit different to your goal,
though. Imagine IM-like (ICQ-like) application, where you see
environments instead of buddies. Then you talk to the environments...
The idea was to have live object environments sitting around your
system and performing various tasks. StepTalk environment is nothing
more than running process waiting for a script to run.
Object transportation was not finished, however the
STConversationClass was changed because of that. From one step:
- (id)runScriptFromString:(NSString *)aString;
to two steps:
- (void)interpretScript:(NSString *)aString;
- (id)result;
... to allow later moving of objects only if necessary.
Basically, the cross-application scripting was meant to be based
on something
like remote-environments, separate processes or threads (in
Workflow.app?) that
would handle remote scripting of applications and passing objects
through
connections.
If you have any questions regarding StepTalk, just ask. Please add
StepTalk to
the subject so I can identify the email more easily :-) thanks.
Another thought concerning Workflow.app: It would probably be
better to have Workflow.app work directly with StepTalk than to
generate code...
@interface Workflow
{
NSArray *steps;
STEnvironment *environment; /* or STContext */
}
@end
@implementation Workflow
- run
{
STConversation *conversation = /*set-up conversation */
for each step in steps do:
{
... set language if needed or other than previous:
[conversation setLanguage:[step language]];
[conversation interpretScript:[step script]];
... do something with the result ...
}
}
@end
I am not sure how apple does it in the Automator, but here I would
suggest to run each workflow in separate stenvironment process...
This would prevent pollution of the Workflow.app process with
unnecessary bundles and frameworks. But you can start writing the app
by executing scripts in its own process and add external execution
later... What do you and others think?
As bonus, you could add STActors later as well... :-)
The code-generation was just an initial idea; on second thought,
however, I think it would most likely end up being somewhat buggy.
I think it is better to leave code generation/execution on particular
language bundle... you save your time.
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
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
