Hi, > I wouldn't want it to replace otherScreenGrabExist > because I feel that is for a slightly different purpose. > > My approach was to try to add cooperation, but not > dependencies between plugins. My examples are: > > 1. 3D, Beryl uses IPCS for this which is not recommended. > I would like 3D to be able to listen for rotate -> initiate with > mouse only and then use that signal to raise the windows. > > 2. Zoom on cube rotate. This could easily be added to the > cube plugin and it is a highly requested feature. I thought > it would be nicer if zoom could listen for the same signal and > use that to zoom out. It would mean that the users zoom > settings could be used and everything would be more > consistent.
Ok, understood - having both besides each other sounds sensible. Having the ability to block certain actions makes this approach even more powerful. > I think this is one case where the fix lies in the plugins > rather than something that is needed in core. > > If you are referring to showdesktop mode then you can > read the hint on the root window. If you are referring > to the showdesktop plugin then the plugin needs to be > fixed so that you can do that. Yes, you are right to a certain degree - the root problem here is that moveWindow is used for both window animations and viewport changes, what makes it hard to distinguish both. > Maybe something could be done in core or there is > something we are missing which can make animated > showdesktop plugins easier? Interesting question ;-) I thought of only drawing it at another place (with the xTranslate/yTranslate members), but in this case, no screen interaction would be possible. Regards, Danny _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz