Re: [compiz] Read commandline defaults from a file?
On Sat, 2007-07-28 at 10:46 +0200, dragoran wrote: David Reveman wrote: On Thu, 2007-07-12 at 10:42 +0200, dragoran wrote: Right now compiz has hardcoded defaults for command line options like direct vs indirect rendering etc. Because most users use scripts like gnome-wm to start compiz its not that easy for them to change this options. My solution would be to have a file (~/.compizrc) where the default values are saved. So that compiz checks for the file first and pic up this values. If no file is found it fails back to the hardcoded one. Would this cause any problems? If not I can implement it and send patches. We should just make all these command line options real options with metadata attached to them. That way you can easily patch the metadata files to change the default values for them or override them by putting you're own metadata files in ~/.compiz. but can settings like direct/indirect rendering be set this way? Sure, we probably don't want to go through the trouble of making such an option adjustable after initialization but that's not a problem, it can be read-only. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Add opacity limits
On 7/28/07, Kristian Lyngstøl [EMAIL PROTECTED] wrote: On 7/28/07, Erkin Bahceci [EMAIL PROTECTED] wrote: This patch adds appropriate limits (1-100) to opacity_values in core options. Minimum is 1 to be consistent with the opacity changing action and because it doesn't make sense to have an invisible window that is still there. The use cases may not be many, but you could say that for 1% opacity too. I don't think it should be up to us to say that there aren't any use cases when there's no technical reason not to allow it. Maybe change the opacity changing action to 0 too? Temporarily making a window invisible doesn't sound too unreasonable. You can make it 5 percent if 1 is too low. 0 is not a good idea because if a user sets 0 as opacity value (probably unintentionally), there will be invisible windows around that will prevent interaction with windows behind them, which will clearly look like a bug. Why would you want an invisible window that blocks interaction with the windows behind it? Anyway, the point of the patch was to have some limits rather than none. - Erkin ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Add opacity limits
On 7/28/07, Erkin Bahceci [EMAIL PROTECTED] wrote: This patch adds appropriate limits (1-100) to opacity_values in core options. Minimum is 1 to be consistent with the opacity changing action and because it doesn't make sense to have an invisible window that is still there. The use cases may not be many, but you could say that for 1% opacity too. I don't think it should be up to us to say that there aren't any use cases when there's no technical reason not to allow it. Maybe change the opacity changing action to 0 too? Temporarily making a window invisible doesn't sound too unreasonable. -- Regards, Kristian ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
