Re: sawfish version numbres of next releases.

["Robert Personen" <psyquark gmail com>]

> 3. version number for a new great sawfish, after adding some of the
>    new things. Should be a bigger jump IMO, even if it's just a
>    consolidated tab support into sawfish themes provided in the trunk,
>    or just a very basic compiz/xgl support.
>
>
> --
> Janek Kozicki                                                         |


There are a number of different extensions that can/should be
implemented.  Off the top of my head: xrandr 1.2, XFixes, XDamage,
XComposite (and arguably Xrender then OpenGL for enhanced display
options).  An additional (and far more ambitious) change would be to
support XCB.

I will try to summarize what I have read so far.

xrandr 1.2:
http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;a=blob_plain;f=randrproto.txt
Out of all the changes in X, this is the only one that would need to
be changed directly in sawfish.  A quick reading of the spec suggests
that the current usage, rereading Xinerama data on the change event,
is sufficient.  What can be done here is to change from using Xinerama
to query to using xrandr which might result in a more finely tuned
event system.  A slightly separate concern would be to create a module
for using xrandr to control the screen placement and activity.

XFixes:
http://gitweb.freedesktop.org/?p=xorg/proto/fixesproto.git;a=blob_plain;f=fixesproto.txt
A collection of fixes and changes to the X protocol.  This includes
the Region type.  XFixes is not strictly needed in the core sawfish
(the current mechanism handles things well enough).  The Region type
that it provides is needed by the next extension.

XDamage:
http://gitweb.freedesktop.org/?p=xorg/proto/damageproto.git;a=blob_plain;f=damageproto.txt
This reports any damage that happens to windows.  It uses the Region
type from XFixes.  I can't think of any use or reason to use or
support this separately from XComposite.

XComposite:
http://gitweb.freedesktop.org/?p=xorg/proto/compositeproto.git;a=blob_plain;f=compositeproto.txt
This is the extension that allows all the fancy stuff to be done.  It
is essentially support for backing stores with an protocol for
accessing and manipulating that store for presentation.  The extension
allows for both manual redirection and automatic redirection but only
one connection and specify manual redirection (making it the composite
manager).  I believe this exclusive manual control per window but for
practical reasons is usually specified on all windows if it is on any.

This extension does not need to be done on the same X connection as
the WM.  The first implementations, xcompmgr and glxcompmgr, were
completely separate programs.  This means that the XComposite support
can and should be developed first as a separate librep program+plugin.

I would suggest a development path of:
separate instance -> loaded module (but separate X connection and
event loop) -> XComposite events handled in the same event loop as the
rest of the X events for sawfish.

Additional drawing libraries (XRender and OpenGL):
http://gitweb.freedesktop.org/?p=xorg/proto/renderproto.git;a=blob_plain;f=renderproto.txt
Direct mapping of the C API to rep functions might not be the best way
of creating these modules, especially in the case of OpenGL.  XRender
might be able to be quickly slipped into the mainline but OpenGL
definitely needs to be developed as a separate module before sawfish
can require it or use it.

XCB:
http://xcb.freedesktop.org/
This is a new C binding to the X protocols.  It claims to fix many of
the oddities and problems of the old Xlib design.  This would be a
major change with little to no difference from the user's perspective.

I would conclude that very little of the development for fancy new
functionality needs or should be started inside the sawfish tree but
rather as separate modules.  Both for stability and because much of
this is still not finalized.