LSARC/2008/115 - Compiz: Compositing window manager

Erwann Chenede Erwann.Chenede at sun.com
Fri Feb 15 05:18:29 PST 2008


Danek Duvall wrote:
> On Thu, Feb 14, 2008 at 02:44:05PM -0800, John Fischer wrote:
>
>   
>> 	This tab will allow the user to switch between metacity and 
>> 	compiz. Compiz will only be available as a choice if the user 
>> 	X server is supported and configured properly. If this X server 
>> 	is not configured properly but the underlying driver does support 
>> 	compiz an option is made available to modify the X server 
>> 	configuration file.
>> 	This is provided by compiz-configure. This depends on a private 
>> 	contract with the Xserver to use /etc/X11/.xorg.conf
>>     
>
> What does the end-user have to do to make sure that X is configured
> properly?  Or will this be done automatically at some point?
>   
It's already done automatically, the visual effect tab is disabled if 
compiz cannot run with the
current X server configuration. (in fact it checks for the Composite X 
extension and the GLX_EXT_texture_from_pixmap
OpenGL extension are present).
>>         These plugins are installed on /usr/lib/compiz. Note that 
>> 	each user can install additional plugins into the 
>> 	$(HOME)/compiz/plugins directory.
>>     
>
> How does compiz deal with home directories that are shared between
> machines?  There's both an architecture (sparc vs x86, once sparc support
> is enabled) and a version (compiz ABI v1 vs compiz ABI v2) issue.
The plugins are are ABI versioned.
The architecture specific versioning is not catered for the moment.
Do you think that disabling this $(HOME)/.compiz would be a good solution ?
>   Is it
> smart enough to load all the plugins present and reject them gracefully if
> they're not supported on the running system?  Or do we need to press for a
> directory heirarchy?
>   
In the future version,  I believe checking for the architecture would be 
the nicest way of implementing this.
> What happens if a plugin isn't available on a system, but is loaded by the
> user's configuration? 
It fails gracefully. e.g. It logs a warning.
>  Is there anything that could go seriously wrong, or
> will the desktop operate as normal aside from that functionality being
> missing?  Could that missing functionality be critical in any way?
>   
No, the user is always able to restart another window manager is 
something goes wrong (e.g. compiz itself crash).
>> 	To manage the user settings using gconf as the rest of the GNOME 
>> 	desktop does the plugin/library compiz-config is used. 
>>
>>     4.5. Interfaces:
>> 	
>>         Exported Interfaces 
>>         Interface             Stability        Comments 
>>         --------------------- ---------------- ----------------------
>> 	 SUNWcompiz		Uncommitted	 Package name 
>>          /usr/bin/compiz	Uncommitted      Executable of compiz
>>          /usr/bin/gtk-window-decorator   
>> 			        Uncommitted      Executable of gtk decorator
>>     
>
> What does this executable do?
>   
It's rendering the frames around the windows.
>   
>>          /usr/bin.compiz-configure	
>> 				Volatile         Detect whether the hardware
>> 						 meet the requirement to run
>>                                                  compiz. configure the xorg.conf 
>> 					         file is required.
>> 	 /usr/lib/compiz/*.so   Private		 Compiz Plugins see (5.1 for
>> 			                         details)
>>          /usr/share/compiz	Uncommitted      Contains all image files
>>          ~./compiz/plugins	Uncommitted      Contains all user installed
>>                                                  plugins
>>          ~./compiz/images	Uncommitted      Contains all images using by
>>                                                  user installed plugins
>>
>> 	 SUNWlibcompizconfig    Uncommitted	 Package name for configuration
>> 					         plugin
>> 	 lib/compizconfig/backends/libini.so
>> 				Private		 init file style configuration 
>> 					         plugin
>>     
>
> This path sits under /usr/lib/compiz?  (Thus
> /usr/lib/compiz/lib/compizconfig/backends/libini.so?)
>
> The package naming suggests that compiz and compiz fusion haven't fully
> come together.  Is there any real point in keeping those packages separate?
> Or maintaining the fusion name, now that beryl and compiz have merged?
>   
I believe as the delivery timeline for compiz and compiz-fusion are not 
the same. compiz-fusion releasing more
often than compiz itself.
compiz is the core of the composite window manager and compiz-fusion is 
a set of plugins for this window manager,
So I believe that It's better to keep them in separate package to be 
able to upgrade the plugins more often if need be.

    Erwann

-- 
              Erwann Chénedé,
 Desktop Group, Sun Microsystems, Grenoble




More information about the opensolaris-arc mailing list