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

[Thomas Liebetraut]

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

  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).

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.

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.

Regards,
Thomas

-- 
This email is digitally signed and encoded in PGP/MIME format.
If you prefer encrypted correspondence or if you want to verify my
signature, please ask me for my public key PRIOR to any other response
to this email.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/compiz/attachments/20060419/45dc38a4/signature.pgp