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 _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz