For those who don't already know, similar patches for libeel and
nautilus are available at:
http://bugzilla.gnome.org/show_bug.cgi?id=444320
and a wallpaper plugin that supports the hint and images/flat
fills/gradients is available at http://gitweb.opencompositing.org. I
plan to add compositing of
On 6/2/07, Sam Spilsbury <[EMAIL PROTECTED]> wrote:
> I was just thinking, with the metadata files allowing us to make up
> settings pages, there is a problem that we could address here.
>
> It seems ever-so-evident that developers are splitting up plugins into
> much smaller plugins to reduce the
The Compiz-scheme can function as a state plugin of sorts. It embeds
the Guile interpreter for the Scheme language in to a Compiz plugin
and provides bindings/hooks in to events.
You can find it at http://gitweb.opencompositing.org
(compcomm/plugins/compiz-scheme) it has an example startup file wi
Beyond the general work on compiz-scheme (new wrappings, hooks, code
improvements, etc), I've added a few large new things:
1. Key bindings with modifiers. This lets you from any of your scheme
files/interactive prompt bind an arbitrary key + modifier to an
arbitrary scheme function. So you can d
don't think we really want this either.
On 4/26/07, Robert Carr <[EMAIL PROTECTED]> 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
th
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.
Th
I've documented the 80+ functions available in compiz-scheme (those
not available in regular scheme) at:
http://people.freedesktop.org/~racarr/DOCUMENTATION
and furthermore in the git repo.
Additionally a 5 minute tutorial to scheme and a 5 minute tutorial to
using compiz-scheme as a state repl
I've put a scheme plugin in users/racarr/compiz-scheme on
gitweb.open-compositing.org.
Essentially it allows the user to define a startup file
(~/.compiz/startup.scm) and fill it with scheme code to do neat things
and extend Beryl.
On one hand it acts like a super powered state plugin, on the ot
We could set up bcop to generate the code for a library for each
plugin that just contains the functions required to get the settings.
Furthermore these settings could be represented through some
hypothetical CompOptionMetadata struct which could contain all the
useful metadata we want.
With some
Compiz and Beryl merge: What's really going on?
Recently Quinns post to the beryl-dev mailing list entitled 'Merge on'
has led to a lot of discussion, some of which has been good and some
of which has led to a lot of misinformation, to clear things up I'd
like to give the story of the merge, and
More on the subject of the internal implementation than the method of
communication, I believe a setup as follows for a drawing interface
makes sense:
Wrappable function:
grabDrawingRequests , this would allow for multiple methods of
communication and protocols to be implemented in plugins (s
I've recently drafted a rough idea of a composite manager agnostic
protocol for leveraging the compositor for retained drawing in a way
suitable for highly interactive and flexible applications.
It seems to be that for anything like this to be a success it would
have to be developed with the supp
On Tue, 2007-02-20 at 12:47 +0100, Anders Storsveen wrote:
Hi
I think this is mostly a question of preference for my part, but I
think it would give an overall better quality feel. What I'm talking
about is mostly the movement it uses. As I've come to understand, it
uses velocity and direction,
13 matches
Mail list logo
