[compiz] On the way to theming g-w-d

[David Reveman]

On Wed, 2006-04-19 at 20:04 +0200, Thomas Liebetraut wrote:
> Thomas Liebetraut schrieb:
> > I will get in contact with you again when I have designed the interface,
> > so that you can have a look at it and say if you like it.
> As promised, my preliminary interface description:
> ---->8------->8------->8------->8------->8------->8---
> The window decoration is stored in the XWindow property
> "_NET_WINDOW_DECOR" and has the following structure:
> 
> (Indices in dword alignment)
>   data[0] = pixmap
> 
>   data[1] = input left
>   data[2] = input right
>   data[3] = input top
>   data[4] = input bottom
> 
>   data[5] = number of quads that will follow

I don't think we should have the length stored in the property. It's not
needed as the total length is always stored as part of the property and
therefor X properties with dynamic length usually never store the length
in the property. e.g. _NET_CLIENT_LIST.

> 
>   data[5 + n * 9 + 1] = flags
>   data[5 + n * 9 + 2] = p1 x
>   data[5 + n * 9 + 3] = p1 y
>   data[5 + n * 9 + 4] = p2 x
>   data[5 + n * 9 + 5] = p2 y
>   data[5 + n * 9 + 6] = widthMax
>   data[5 + n * 9 + 7] = heightMax
>   data[5 + n * 9 + 8] = x0
>   data[5 + n * 9 + 9] = y0
> 
> "flags" is the following 32bit bitfield:
>   0..1   = p1 gravity
>   2..3   = p2 gravity,
>   4..5   = alignment
>   16..17 = XX (16: length of the vector, 17 sign)
>   18..19 = XY (18: length of the vector, 19 sign)
>   20..21 = YX (20: length of the vector, 21 sign)
>   22..23 = YY (22: length of the vector, 23 sign)
> 
> The quad system works just as the current system, except that it also
> allows negative values for all vector components of the translation
> matrix to allow all sorts of rotations and mirrorings that someone may
> find useful (but still with only one bit accuracy. I don't see any
> reason why one would want rotations of angles other than x*Pi).

Sign on XX, XY... vectors makes sense.

> 
> This interoperability structure should be implemented in the decorator
> itself (to allow downward compatibility with plugins).
> The decorator uses plugins to actually draw the textures. The plugins
> are also responsible for the frame layout, so they have full control
> about where to place which button.
> Event handling for the frame elements is also done by the plugin.
> However, the plugin can (and should!) use reference implementations from
> the decorator (see below), that don't do much more than organizing
> things and cause the decoration to redraw according to the changes.
> 
> The plugin interface is designed similarly to the interface already used
>  for Compiz plugins, except only one plugin can be loaded at a time and
> thus there can't be any dependencies.

The plugin interface doesn't have to be as dynamic as the one in compiz
and you can use gobject and gtk in g-w-d so you might be able to create
something simpler than the interface in compiz. But I'm not sure, you'll
figure out what's best... 

> 
> Screen handling (active window changing, etc) is still done in the
> decorator itself. When creating a window, the decorator delegates all
> non-administration work to the plugin, calling a function to setup the
> WnckWindow. The drawing queue is also managed by the decorator, while
> the actual drawing is again delegated to the plugin.
> 
> To allow plugins to get information from the decorator, a structure that
> contains pointer to functions in the decorator is passed to the plugin.
> This structure can later be extended to also contain commonly used
> helper functions (why invent the wheel more than once?) and maybe (if
> there will ever be a way to achieve it) functions that allow more
> detailed changes to the way the decorations are drawn (shaders, etc).
> This structure is also used to give the plugin the possibility to use
> the decorators implementation of standard functions like
> close_button_event() and other standard function for interaction with
> the user that shouldn't be implemented by each plugin on their own way.
> 
> The plugin can also provide a list of settings it wants to store in some
> settings database. This way, the plugins won't chose whatever places
> they want to store settings, but still can be customized, for instance
> different settings for shadows, colors or other things. The list of
> values will be stored in the gconf database by the decorator in
> /apps/compiz/decorator/[theme name]. This will also prevent different
> plugins from interfering each other by interpreting settings the wrong
> way. Of course, the plugins have the responsibility to provide a unique
> name for the gconf key so that no other plugin choses this name
> (timestamps or similar things are one way, if the theme's name is not
> enough).
> ---->8------->8------->8------->8------->8------->8---
> 
> Additions and objections are welcome.

Sounds good to me. Great Work!

btw, I'll commit some dynamic shadow code to g-w-d in a few days. Most
plugins will likely want to use this code.

-David