[compiz] Question about extending screengrabs

[Mike Dransfield]

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