Re: sawfish version numbres of next releases.

[Janek Kozicki <janek_listy wp pl>]

Robert Personen said:     (by the date of Sun, 1 Jul 2007 12:51:35 -0400)

Great! Thanks for your summary. I am unable to answer in detail for
each point, but it's really great that you took the effort to put it
all together. It certainly will go to the wiki site, and will be used
to coordinate our future work :)


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

This is an important point too! Only things that must be changed in
the core, will be. We do not want to lose current stability.




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


-- 
Janek Kozicki                                                         |