http://bugs.opencompositing.org/show_bug.cgi?id=976
--- Comment #2 from jug <[EMAIL PROTECTED]> 2008-06-20 15:09:43 --- >It might make sense to enable two switchers (e.g. one for fast switching, one >for good overview - imagine staticswitcher vs. ring). Valid argument. Though with a powerful interface it should be possible to configure different key bindings for different effects. > No. One subplugin per effect would mean as many plugins as we have now. I'm not familiar with the code of compiz, or the possibilities the plugin-system offers. But it should be possible to hide these subplugins. Take the animation plugin as an example. It offers many, many effects and it is easy to select an effect for an event without activating a separate plugin for each effect. This is basically what I meant with a subplugin. It's not a conventional plugin, but it is more like a "theme" so it would require a system for plugins inside another pugin and these would not appear in ccsm. > No. We'd still have one main plugin + n child plugins. Right, although the child plugins would not necessary require a change. If for example the sorting of windows is changed or a bug in the key bindings is fixed. I think I didn't get the point across, so let me clarify. The "application switcher" plugin would just provide these informations: - references to the textures, - current position of the window - maybe a title of the window - ordering of the windows And then there could be four events: initiate, select_next, select_previous, terminate As long as this API does not change there is really no need to change these subplugins. As I said, I don't know if this is possible or how much effort it would take to implement something like this. > What other examples do you have in mind? ;) "Fade to desktop" and "show desktop". It's exactly the same thing... Those Firefly, Snow - "elements" things (finally merged recently). Why duplicate and modify the plugin if you could just add a small theme-package with new animation/textures... And many other plugins where there might be feature requests for "a new animation", that could not yet be easily satisfied because it would require a fork of the plugin. Viewport switching might be another task where this concept could be applied in the long run. The wall, plane and cube plugins. It's basically the same functionality with just a different animation... But I guess this is a much more complex scenario than the other examples. So it's waaay down the list. ;) -- Configure bugmail: http://bugs.opencompositing.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ Dev mailing list [email protected] http://lists.compiz-fusion.org/mailman/listinfo/dev
