First, I would like to compliment you all for a great work you put in developing compiz. I have it running for more that a month and it did not crash. Stability is very good. Great work! Today I updated compiz from git tree and found that rotate generates this error: compiz (core) - Error: Couldn't activate plugin 'rotate' Rotate does not function. Any ideas ? I run gconf backend. Browsing through compiz site I did not find any guidelines of what is needed to send a bug report. Or I missed it ? I hoped compiz has some verbose option that could shed some light on why rotate initialisation fails. I use --indirect-rendering to avoid nvidia black window bug (somehow it helps). compiz --sm-disable --indirect-rendering --replace ccp&! Backend : gconf Integration : true Profile : default Adding plugin winrules (winrules) Adding plugin snow (snow) Adding plugin decoration (decoration) Adding plugin crashhandler (crashhandler) Adding plugin regex (regex) Adding plugin rotate (rotate) Adding plugin fade (fade) Adding plugin reflex (reflex) Adding plugin move (move) Adding plugin svg (svg) Adding plugin ring (ring) Adding plugin showdesktop (showdesktop) Adding plugin png (png) Adding plugin snap (snap) Adding plugin scale (scale) Adding plugin thumbnail (thumbnail) Adding plugin video (video) Adding plugin zoom (zoom) Adding plugin screenshot (screenshot) Adding plugin switcher (switcher) Adding plugin annotate (annotate) Adding plugin fs (fs) Adding plugin wobbly (wobbly) Adding plugin water (water) Adding plugin neg (neg) Adding plugin resize (resize) Adding plugin fakeargb (fakeargb) Adding plugin trailfocus (trailfocus) Adding plugin tile (tile) Adding plugin splash (splash) Adding plugin dbus (dbus) Adding plugin mblur (mblur) Adding plugin bench (bench) Adding plugin inotify (inotify) Adding plugin cubereflex (cubereflex) Adding plugin wall (wall) Adding plugin put (put) Adding plugin extrawm (extrawm) Adding plugin cube (cube) Adding plugin firepaint (firepaint) Adding plugin blur (blur) Adding plugin addhelper (addhelper) Adding plugin glib (glib) Adding plugin minimize (minimize) Adding plugin plane (plane) Adding plugin text (text) Adding plugin clone (clone) Adding plugin expo (expo) Adding plugin resizeinfo (resizeinfo) Adding plugin opacify (opacify) Adding plugin fadedesktop (fadedesktop) Adding plugin imgjpeg (imgjpeg) Adding plugin place (place) Adding core settings (General Options) Adding plugin group (group) Adding plugin animation (animation) Initializing core options...done Initializing winrules options...done Initializing decoration options...done compiz (core) - Error: Couldn't activate plugin 'rotate' Initializing move options...done Initializing zoom options...done Initializing wobbly options...done Initializing resize options...done Initializing put options...done Initializing resizeinfo options...done Initializing imgjpeg options...done Initializing place options...done Initializing fade options...done Initializing cube options...done Initializing expo options...done Initializing scale options...done Initializing switcher options...done Active Plugin List update -- Kresimir Kukulj madmax at iskon.hr +--------------------------------------------------+ Remember, if you break Debian, you get to keep both parts.
Am Montag 16 Juli 2007 20:49:32 schrieb Kresimir Kukulj:> First, I would like to compliment you all for a great work you put in > developing compiz. I have it running for more that a month and it did > not crash. Stability is very good. Great work! > > Today I updated compiz from git tree and found that rotate generates > this error: > > compiz (core) - Error: Couldn't activate plugin 'rotate' >The problem is that the "load after cube" got removed from the rotate metadata. I reverted it now. The ccs configuration system doesn't handle "require" rules automatically as "load after" rules. There is also a case where we have a "require" and a "load before" rule for the same plugin (3d). Dennis
On Sun, 2007-07-29 at 20:31 +0200, Dennis Kasprzyk wrote:> Am Samstag, 28. Juli 2007 00:24:10 schrieben Sie: > > On Mon, 2007-07-16 at 23:44 +0200, Dennis Kasprzyk wrote: > > > Am Montag 16 Juli 2007 20:49:32 schrieb Kresimir Kukulj: > > > > First, I would like to compliment you all for a great work you put in > > > > developing compiz. I have it running for more that a month and it did > > > > not crash. Stability is very good. Great work! > > > > > > > > Today I updated compiz from git tree and found that rotate generates > > > > this error: > > > > > > > > compiz (core) - Error: Couldn't activate plugin 'rotate' > > > > > > The problem is that the "load after cube" got removed from the rotate > > > metadata. I reverted it now. > > > The ccs configuration system doesn't handle "require" rules automatically > > > as "load after" rules. There is also a case where we have a "require" and > > > a "load before" rule for the same plugin (3d). > > > > I don't think it should be allowed to ask for some plugin to be required > > but loaded after. Plugins that do this should be fixed so they don't > > have to ask for such a relationship and the "load after cube" > > information in the rotate metadata should be removed again. > > > > -David > > We removed the whole plugin order system from core to make it more flexible. > That's the reason why we shouldn't mix now requirements with relations and > limit the functionality. But if you want I can remove the "load after cube" > information in the rotate metadata and add this to the internal configuration > system metadata file.We're not limiting functionality by having requirements also implicitly mean that the plugin must be loaded after. We're just making the existing tags make more sense. If you like some metadata information that indicate that a plugin must be loaded after, then you can always add that through a new tag. The reason I like to have the requirement tag also implicitly mean "load after" is that a plugin that requires another plugin to be loaded after seems to be designed poorly and I think we should do our best not to encourage that. However, you're welcome to prove me wrong and show that requiring that another plugin is loaded after necessarily isn't bad design, in which case I'm happy to allow the requirement tag not to implicitly mean "load after". -David
On Tue, 2007-07-31 at 00:19 +0200, Dennis Kasprzyk wrote:> Am Montag, 30. Juli 2007 16:28:27 schrieben Sie: > > On Sun, 2007-07-29 at 20:31 +0200, Dennis Kasprzyk wrote: > > > Am Samstag, 28. Juli 2007 00:24:10 schrieben Sie: > > > > On Mon, 2007-07-16 at 23:44 +0200, Dennis Kasprzyk wrote: > > > > > Am Montag 16 Juli 2007 20:49:32 schrieb Kresimir Kukulj: > > > > > > First, I would like to compliment you all for a great work you put > > > > > > in developing compiz. I have it running for more that a month and > > > > > > it did not crash. Stability is very good. Great work! > > > > > > > > > > > > Today I updated compiz from git tree and found that rotate > > > > > > generates this error: > > > > > > > > > > > > compiz (core) - Error: Couldn't activate plugin 'rotate' > > > > > > > > > > The problem is that the "load after cube" got removed from the rotate > > > > > metadata. I reverted it now. > > > > > The ccs configuration system doesn't handle "require" rules > > > > > automatically as "load after" rules. There is also a case where we > > > > > have a "require" and a "load before" rule for the same plugin (3d). > > > > > > > > I don't think it should be allowed to ask for some plugin to be > > > > required but loaded after. Plugins that do this should be fixed so they > > > > don't have to ask for such a relationship and the "load after cube" > > > > information in the rotate metadata should be removed again. > > > > > > > > -David > > > > > > We removed the whole plugin order system from core to make it more > > > flexible. That's the reason why we shouldn't mix now requirements with > > > relations and limit the functionality. But if you want I can remove the > > > "load after cube" information in the rotate metadata and add this to the > > > internal configuration system metadata file. > > > > We're not limiting functionality by having requirements also implicitly > > mean that the plugin must be loaded after. We're just making the > > existing tags make more sense. If you like some metadata information > > that indicate that a plugin must be loaded after, then you can always > > add that through a new tag. > > > > The reason I like to have the requirement tag also implicitly mean "load > > after" is that a plugin that requires another plugin to be loaded after > > seems to be designed poorly and I think we should do our best not to > > encourage that. However, you're welcome to prove me wrong and show that > > requiring that another plugin is loaded after necessarily isn't bad > > design, in which case I'm happy to allow the requirement tag not to > > implicitly mean "load after". > > > > -David > > The problem is here that we have a plugin (3d) that has to be loaded before > cube but also requires cube. It needs to be loaded before cube because it's > paintTransformedOutput needs to be called for each cube face, but it also > needs some variables from cube to work correctly. To get into cube it uses > then init/finiPluginForDisplay. > > So we have a plugin that requires another plugin but needs to be loaded before > that plugin. That is the reason why I don't like requirement tag also > implicitly mean "load after".cube plugin should provide hooks that allow 3d to be loaded after cube and hook in where appropriate and not use paintTransformedOutput. -David