Re: [Fresco-devel] scripting

Russell Neches wrote:
> Sean Rae <[email protected]> writes:
> 
>>as retorted by Stefan:
>>
>>>I'm trying to imagine what you have in mind when talking about
>>>scripting. Of course, there are python bindings for Fresco,
>>>allowing you to write Fresco programs in python (and of course,
>>>all other languages that have CORBA bindings).
> 
> In any event, I imagined something like the API exposed by a window
> manager. For instance, the blackbox/bbkeys relationship. blackbox
> exposes some basic functions that allow you to manipulate the state of
> the window manager (manipulating window positions, maximizing,
> minimizing and killing windows, and so forth). bbkeys is a really
> simple key-grabber that knows how to (a) make calls to blackbox and
> (b) parse a configuration file. 

There seems to be a few things that this FrescoScript could be intended 
for, so we'd better work out the design goals before we critique the 
idea into oblivion. I'm suggesting the following as possible goals that 
you can choose from the list.

1. Allow the CommandKit to return a server-side Command that executes in 
a CORBA-aware scripting language (such as JavaScript?) You'd pass in the 
program text and it returns the Command object.

2. Provide a suite of non-interactive programs that are capable of 
manipulating the Display Server from the shell.

3. Integrate a set of queries that would be useful debugging, such as 
"find window named <X> and output a copy of its scene graph" or somesuch.

> The code overhead for the arrangement is miniscule. blackbox already
> has, for instance, a callback function to maximize a window. All that
> is needed to allow bbkeys to work is a mechanism to invoke those
> callbacks manually (if you can forgive my abuse of the term). So,
> blackbox listens for certain mouse events from X (clicking the
> maximize button) to trigger the callback. It's also possible to
> short-circuit X and invoke the callback from blackbox's API. 

I'm not familiar with blackbox, but I know that sawfish has a tool 
called sawfish-client. I'm just worried that a fresco swiss army knife 
thingy will quickly turn into a Fresco binding for shell. That's 
analogous to writing a Fresco/CORBA API wrapper for a new language, in 
this case, shell.

We already do use callbacks for DesktopKit (window manager) functions. 
There's the MoveResizer Command that gets triggered when you grab a 
corner of a window to resize it. Currently, that Command only exists 
inside of the DesktopKit and there's no API you can use to ask the 
DesktopKit to create you one. If it were to expose that, you could then 
wrap a scripting language around it. But should we really expose such 
things? I doubt the Fresco architects will like it much.

>>>However, this may not be exactly what you are looking for,
>>>i.e. write single clients that ask the server for a suitable
>>>UI. You seem to want something to introspect and manipulate the
>>>server's current state.
>>
>>Exactly.  Something to make (y)our lives easier.  It could be a
>>resident program in the server address space that keeps track of
>>current state variables and can be en/dis-abled with a configure
>>flags... possibly?
> 
> I'm pretty certain you'd want this for debugging only. Using it to
> port bbkeys to Fresco would be ridiculous. 

Suppose we were to invent the Fresco Debugging System! What do we want 
it to do? Just like gdb and inspect the registers and stack, and dump a 
backtrace, what should fdb be capable of?

Walking the scene graph, certainly. But if we restrict ourselves to 
CORBA, there isn't but we can get back out of a Graphic, unless we care 
to add a debug_info function to each Graphic. (But why should the 
debugger trust its results? That's a different matter all together.)

How about manipulating the scene graph? Calling into kits to create 
objects and splicing them in where desired? Good at least for adding a 
DebugGraphic somewhere.

Generating events by request? That would take a hook in the Consoles, 
but we already have an old 'autoplay' system in there that we could adapt.

Other wonderful ideas?

Queries like "get the ID of the window named <X>?" Sounds good to me. 
The interface to this thing could be either:
-bash: run various programs to collect information
-javascript: if could parallel our javascript-in-CommandKit effort!
-python: python has corba bindings, works today and even has an 
interpreter mode!
-custom?

>>>May be it would be interesting to think further in that
>>>direction...

While we're busy thinking about manipulating the scene graph in a 
debugger, now would be a good time to point out that the same basic idea 
is good for building a Fresco IDE as well. Except that you'd expect an 
IDE to run inside of Fresco while the debugger should sit outside, but 
that's a minor detail with a proper MVC design.

Nick Lewycky