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


Reply via email to