drago01 wrote: > On Fri, Nov 28, 2008 at 9:19 AM, Danny Baumann <[EMAIL PROTECTED]> wrote: > >>> Some options I considered: >>> >>> 1: Treat plugins passed on the compiz command line as unremovable at >>> runtime. active_plugins can safely not include gconf, and gconf will >>> remain loaded for the lifetime of compiz. >> At first I thought that this would be no viable way. Imagine somebody >> loading the switcher plugin from the command line and loading fade at >> runtime later on. He would have no chance of getting switcher's >> opacity/brightness/saturation changes faded. >> On the other hand I wonder if there is _anybody_ using that kind of >> scenario anymore. If we consider that an invalid use case, enforcing the >> command line plugins as being loaded all the time might be a pretty good >> idea. > > Nobody really uses the command line for any plugins but configuration > / configuration related ones.
After reading the comments on: http://bugs.opencompositing.org/show_bug.cgi?id=379 The problem stemmed from the inability to unload the gconf plugin via gconf. However, what would the alternative be? It seems like a better solution overall to simply treat conf plugins for what they are, and load (and keep loaded) one plugin for the lifetime of compiz. Does it really make sense to have two configuration plugins loaded? Which configuration value for the same configuration key would apply? Would it depend on load order? Does it make sense for NO configuration plugins to be loaded? The user couldn't make any further updates while compiz is running. Maybe it would be better (at least for distributions) to include a global config file that specifies which conf plugin to load for the distribution, and let both compiz and ccsm read that file to determine the proper backend to use. You wouldn't have to monkey with the command line plugin overrides at all. ... in fact, I think that file already exists as /etc/compizconfig/config ... The user wouldn't have to make a choice any longer as to which conf plugin to configure using a particular backend. ccsm would just work to configure the running compiz. I don't wanna get crazy here, but maybe the conf plugin API can be altered slightly so that the same conf plugin could be used by both compiz and ccsm to read AND write compiz configuration. You wouldn't need libcompizconfig any longer. The code seems largely duplicated anyway between conf plugins and conf backends. >> [...] >> All in all, personally I'm in favour of option 1, perhaps combined with >> the GUI changes from option 3. Any other opinions? > > + 1 > _______________________________________________ > compiz mailing list > compiz@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/compiz _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
