AW: Re: [compiz] [PATCH] minimize doesn't respect "no core instance" flag

[David Reveman]

On Mon, 2007-03-12 at 18:53 +0100, Danny Baumann wrote: 
> Hi,
> 
> > We've done this before and the problem with this is that there might be
> > conflicts with other plugins. What if some other plugin also wants to
> > transform the core instance? Having plugins animate a separate instance
> > of the window instead of the core instance gives us a well defined
> > behavior in all situations. If plugins are animating the core instance,
> > then you have an infinite number of possible states that the core
> > instance could be in as it's defined by the state of all loaded plugins.
> > 
> > When writing a plugin, it's always a good idea to consider the case
> > where two instances of the plugin is loaded. That's of course not
> > something that has to be supported but if the behavior when having two
> > instances loaded is well defined, you're off to a good start. 
> 
> Well, this approach has obvious problems, too: With the "only one core
> instance" approach, the look of an animation could be pretty weird if
> there were multiple plugins animating at the same time. However, with
> the "one instance per animating plugin" approach, there would be
> multiple instances of the same window with different animations, which
> will look pretty weird as well ;-)
> 
> It may be a matter of personal preference, but I prefer the "only one
> instance only" approach because it gives us the opportunity to hide
> windows completely, which the second approach doesn't provide.
> Additionally, I think the "look and feel" of this approach would look
> less weird to the end user than with the "multiple instances" approach.

We need the multiple instances functionality anyhow for effects like the
switcher. Whether one or multiple instances looks better depends on the
situation. E.g having one instance when two minimize plugins are loaded,
one that transforms the window to the taskbar icon and one that
transforms it so it looks like it's flying towards you is not going to
look good at all.

There's always going to be cases where plugins conflict and things will
never look perfect in those cases. Instead of trying to prevent these
kind of conflicts from happening I prefer a simple and well defined
behavior when it occurs. These conflicts are most appropriately avoided
at the configuration level.

> 
> Also, I'm not completely sure what you mean by "possible states". I
> mean, the transformation of a window isn't a real state machine which
> needs state machine transitions where action 1 could influence if action
> 2 could be executed or not. In my opinion, plugins can act completely
> sepearately on the window transformation and the only question is if the
> result of the transformations look visually appealing or not. Maybe I am
> missing something - if I do, please enlighten me :-)

Scale and minimize plugins both act as state machines but the state is
contained within each plugin so it doesn't matter much. "possible number
of variables that can affect an animation" is more accurate and I'm
mostly concerned about making it harder to track down bugs. E.g. some
user reports a bug which involves animation 'A' performed by plugin 'B'
not being rendered correctly in some cases. If we know that only plugin
'B' can affect animation 'A' then it's a lot easier to debug this.

- David