My recent work on Compiz-scheme has brought to my attention several problems preventing a real compiz extension language. Note that when I refer to an extension language, I am not referring to the ability to add plugins in some other languages, but more of something in the vein of emacs lisp. The major problem right now is extension languages are locked in to one plugin and what core exposes. What I mean by this is it's easy to add support for something like: (window-rule (make-rule (set-opacity-when (window-is tooltipp) 0.5))) However it's impossible to add support for something like: (scale-window-when (window-is negativep)). There are two possible solutions to this: 1. Add basic support for a specific interpreter in core. Core would expose wrapper functions around the interpreter to easily enable plugins to add C functions to the interpreter. On one hand, we probably want to avoid binding core to a specific interpreter, on the other hand this sounds rather pleasant compared to the alternative. 2. Add an interpreter interface, with wrappable functions for plugins embedding a specific interpreter to wrap. I think it is abundantly obvious why such an interface would be unreasonably complex and likely bug ridden, exposing no specifics of an interpreter to individual plugins, but still having conversion from interpreter types->native types (a variable number of arguments per function + return types), plus adding new types and other constructs is exceedingly difficult, and complex to the point where I don't think we would want it. Does anyone else have any thoughts? Regards, Robert
It's worth noting that another alternative is ifdefing code for specific interpreters in various plugins (and insuring the plugins that need to set up the interpreter enviroment load first) and having ./configure --with-scheme --with-python --without-ruby. Or something of the vein. But I don't think we really want this either. On 4/26/07, Robert Carr <racarr@beryl-project.org> wrote:> My recent work on Compiz-scheme has brought to my attention several > problems preventing a real compiz extension language. > > Note that when I refer to an extension language, I am not referring to > the ability to add plugins in some other languages, but more of > something in the vein of emacs lisp. > > The major problem right now is extension languages are locked in to > one plugin and what core exposes. What I mean by this is it's easy to > add support for something like: > (window-rule (make-rule (set-opacity-when (window-is tooltipp) 0.5))) > However it's impossible to add support for something like: > (scale-window-when (window-is negativep)). > > There are two possible solutions to this: > > 1. Add basic support for a specific interpreter in core. Core would > expose wrapper functions around the interpreter to easily enable > plugins to add C functions to the interpreter. On one hand, we > probably want to avoid binding core to a specific interpreter, on the > other hand this sounds rather pleasant compared to the alternative. > > 2. Add an interpreter interface, with wrappable functions for plugins > embedding a specific interpreter to wrap. I think it is abundantly > obvious why such an interface would be unreasonably complex and likely > bug ridden, exposing no specifics of an interpreter to individual > plugins, but still having conversion from interpreter types->native > types (a variable number of arguments per function + return types), > plus adding new types and other constructs is exceedingly difficult, > and complex to the point where I don't think we would want it. > > Does anyone else have any thoughts? > > Regards, > Robert >
Robert Carr wrote:> My recent work on Compiz-scheme has brought to my attention several > problems preventing a real compiz extension language. > > Note that when I refer to an extension language, I am not referring to > the ability to add plugins in some other languages, but more of > something in the vein of emacs lisp. > > The major problem right now is extension languages are locked in to > one plugin and what core exposes. What I mean by this is it's easy to > add support for something like: > (window-rule (make-rule (set-opacity-when (window-is tooltipp) 0.5))) > However it's impossible to add support for something like: > (scale-window-when (window-is negativep)).I am not sure what your ultimate goals are, but this particular example would be easy if you added a custom match handler to the neg plugin. AFAIK scale includes a scale_match action which you could pass 'neg=1' and that would only scale neg'd windows.> > There are two possible solutions to this: > > 1. Add basic support for a specific interpreter in core. Core would > expose wrapper functions around the interpreter to easily enable > plugins to add C functions to the interpreter. On one hand, we > probably want to avoid binding core to a specific interpreter, on the > other hand this sounds rather pleasant compared to the alternative. > > 2. Add an interpreter interface, with wrappable functions for plugins > embedding a specific interpreter to wrap. I think it is abundantly > obvious why such an interface would be unreasonably complex and likely > bug ridden, exposing no specifics of an interpreter to individual > plugins, but still having conversion from interpreter types->native > types (a variable number of arguments per function + return types), > plus adding new types and other constructs is exceedingly difficult, > and complex to the point where I don't think we would want it. > > Does anyone else have any thoughts? > > Regards, > Robert > _______________________________________________ > compiz mailing list > compiz@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/compiz
Robert Carr wrote:> On 4/26/07, Mike Dransfield <mike@blueroot.co.uk> wrote: >> Robert Carr wrote: >> > My recent work on Compiz-scheme has brought to my attention several >> > problems preventing a real compiz extension language. >> > >> > Note that when I refer to an extension language, I am not referring to >> > the ability to add plugins in some other languages, but more of >> > something in the vein of emacs lisp. >> > >> > The major problem right now is extension languages are locked in to >> > one plugin and what core exposes. What I mean by this is it's easy to >> > add support for something like: >> > (window-rule (make-rule (set-opacity-when (window-is tooltipp) 0.5))) >> > However it's impossible to add support for something like: >> > (scale-window-when (window-is negativep)). >> >> I am not sure what your ultimate goals are, but this particular >> example would be easy if you added a custom match handler to >> the neg plugin. >> >> AFAIK scale includes a scale_match action which you could pass >> 'neg=1' and that would only scale neg'd windows. >> > > This isn't quite the problem. Even if that were done, how would scale > expose a function to scale windows to the interpreter?Through the option actions, its fairly easy to do in C so you should be able to replicate that in a function. The initiate and terminate functions take a list of options which can be used to control it. See the dbus plugin for how the scale initiate function can be exposed and be sent parameters, I think the scale example was a specific one that David gave when announcing the match options.