Danny Baumann wrote: > Hi, > > >> Wouldn't it be better to add this kind of functionality through >> different interface than the current screen grab interface? We can >> always expose the current screen grabs through a new interface if we >> want that. >> >> I'm not sure exactly how this interface should look like but seems like >> it would makes sense to be able to not just check if some state is >> present but also be able to prevent a state from being entered. >> >> E.g. instead of the rotate plugin checking for some "showdesktop" state, >> the showdesktop plugin could check for a "rotate" state and prevent it >> from being entered while being in "showdesktop" state. >> >> What do you think? Do you think that extending the screen grab interface >> is the best way to do this anyhow? >> > > I'm not sure if we would gain a lot from that. The idea sounds very > nice, but thinking about it I have the impression that such an interface > would be much more complicated than what we have now. > > I can think of two use cases for the whole checking: > > - A plugin wants to check if other plugins are active which could be > disturbing ... otherScreenGrabExist is perfectly suited for that by > whitelisting non-disturbing plugins.
I think this problem is related to my earlier question about action options and the return value. My idea was that every time an action returned true, a signal would be sent which other plugins could listen for in the normal way. My requirements were that each signal would send the following information about what just happened. The plugin name The action option name The method for how it was initiated (mouse/key/edge/other) My initial method involved patching handleActionEvent and changing triggerButtonPressBindings to set the index of the option that was initiated. If triggerButtonPressBidings returned true then I would send an initiateActionOption notification which would modify the options to include the plugin name and the method (ie button). It would then pass through the pointer to the option that was initiated. The same would happen for terminate bindings so other plugins can keep an internal track of all other plugins (even if the author didnt write their plugin specifically for them). I realize that this isn't perfect, but my reasoning is that if a plugin ate a mouse or keypress then there is a good chance it did something. Reading the state doesn't provide enough information and relies on the plugin authors playing by the rules. BTW - I think that in the showdesktop example you could easily check if the screen is in showdesktop mode. There is probably a reason for it, but showdesktop does not use the correct enterShowDesktopMode function so you cannot check. AFAIK showdesktop needs to be fixed in this particular case. It sounds like its a problem with minimized windows again. Regards Mike _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz