http://bugs.opencompositing.org/show_bug.cgi?id=976
--- Comment #3 from Danny Baumann <[EMAIL PROTECTED]> 2008-06-20 16:08:54 --- (In reply to comment #2) > >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. Problem here is that this doesn't really fit in the whole concept as it stands now. The current concept is designed to be as general as possible, not for special cases like that one. > > 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. That's because animation is one plugin only ;) It's almost 13000 LOC, which is why its maintainer wants to split it into ... guess what ... multiple plugins ;) > 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. Texture references, window position is provided by Compiz itself. The problem is that the switchers work very differently internally: switcher and staticswitcher open a window, decorated specially by the decorator, and draw the thumbnails on that one. Ring, stackswitch, shift draw the thumbnails without a window and work pretty much like scale internally. As I said, I don't like the variety of keybindings for the switchers myself, and thought about that for quite some, but haven't come to a good solution idea so far. As soon as someone has a good idea to actually _code_ that, we'll go ahead and do it. > > What other examples do you have in mind? ;) > "Fade to desktop" and "show desktop". It's exactly the same thing... No. Both provide different effects to _one_ action (show desktop), which is in Compiz and has only _one_ keybinding. So those two are actually a good example ;) > 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... The only somewhat official of those is snow. We obviously can't hinder other people from duplicating it. > 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. With git, you don't necessarily need to fork it. See the animations-plus user repo. But as I said, the animation maintainer wants to add sub-plugin capability to animation. > 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. ;) The similarities between plane and wall were the reason why plane was killed off in 0.7.6. The only similarities of wall and cube+rotate are the key bindings, so it's next to impossible to merge something there. -- 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
