On Fri, Feb 15, 2008 at 02:18:29PM +0100, Erwann Chenede wrote: > Danek Duvall wrote: > >> 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).
So is there any point in putting compiz-configure in /usr/bin? Seems like it's a Private implementation detail at the moment. >>> 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 ? That seems a bit much. I'd be satisfied for the moment if you could put plugins of any architecture or ABI version into the directory and have compiz sort out which plugins it can load and which it can't. That would imply that the filename of a plugin would have to not matter (i.e., freeblebrotz-x86.so and freeblebrotz-sparc.so could both provide the FreebleBrotz plugin, even though the filenames included the architecture tag). On a related note, are either the plugin API or ABI Public interfaces? >>> /usr/bin/gtk-window-decorator Uncommitted Executable of gtk decorator >> >> What does this executable do? > > It's rendering the frames around the windows. Is it something the user would ever run, or is it an implementation detail of compiz? >> 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. Okay. Thanks, Danek
