GNOME Bugzilla – Bug 346041
Add support for locking down theme
Last modified: 2006-08-15 10:45:25 UTC
Initial patch attached. I was considering including a message in the window with a message along the lines of "Modification of theme settings have been restricted for this user". Or alternatively we could have a dialog box. I haven't added it since i'm not sure about the choice of phrasing. I didn't add any notification/callback for this gconf key. If you think it would be useful then we can also add that but I doubt that is really necessary here. Background one coming shortly.
Created attachment 68080 [details] [review] Initial patch
Can't you just test the gconf key(s) holding the theme names for writability, instead of adding a 'locked down' key?
This would make it difficult since there are at least three different gconf keys to lock down. If not all three are locked down, how should the UI handle this. I think the easiest thing (and also most useful), is that themeing is locked down all together. I suspect the UI should respond to the lockdown with a message box informing the user it has been locked down by the administrator, and then close once the user acknowledges it. I don't see any benifit in a completely disabled UI being open for the user (apart from seeing what theme they have applied currently, which if really critical could be in the message dialog).
As written by Christian we don't need a new gconf key, we just have to look if the "normal" key is writtable or not by the user Thomas, the theme capplet case is tricky because because one of the themes (gtk, icons, wm) can be locked in which case you don't want to close the capplet immediatly but allow going to the details to change the non-locked themes there. I would say: - unsensitive the "Themes Preferences" list as soon as one of the themes is masked - allow people to go to "Theme Details" - unsensitive the list for the locked theme We might want to consider as "theme_locking" key that would prevent to change or install any theme and have the behaviour you described What do you think about it?
Well, there's obviously no point in being able to install a gtk theme if you can't switch to it. The installer already checks what sort of theme is being installed, so it would have to alert the user if they won't be able to choose it after it's installed (or just refuse to install it). What use case is there for being able to lock down individual theme types? I still think it would be both simpler and nicer for people to be able to just lock down the entire capplet.
I didn't argue to make theme installation possible when locked, I think it should be locked too :) I'm not sure there is any usecase to "lock the icons theme but not the GTK one" so you are right, have a "theme_locking" key with a dialog saying the administrator locked themes switching looks good enough to me, let's go for it! Extra point if you do it for 2.15.4 next week ;)
In general, I'm not too keen on the idea of alerts to inform the user that things have been locked down, although as a short-term fix it's better than nothing. Like Thomas, I'd like to see a consistent approach to locked down controls that we can apply to virtually any situation. The HIG already has one suggestion, although it's not very good: http://developer.gnome.org/projects/gup/hig/2.0/controls-sensitivity.html#controls-locked Some options that come to mind are, in no particular order: 1. Just disable locked controls, and leave it at that. Probably not good. 2. Disable each locked control, and have a small indicator of some sort beside each one. Would quickly get cluttered, and disrupt dialog layout. 3. Disable each locked control, and have a single indicator in a fixed location in the window, which would give you an explanation if you clicked or moused over it. (This is a bit like the Mac approach, except clicking the indicator on the Mac allows you to authenticate and then change the settings-- don't think that would make sense for us). 4. Hide locked controls, with an explanation somewhere in the dialog that some controls are not displayed. This would prevent the user from seeing settings that they may need to copy into an email or read out to a helpdesk operator though, for example. I like 3 best; seems to be the least obtrusive and most generally applicable, but I haven't given it a massive amount of thought.
The patch that I originally proposed just did 1. I like the idea of implementing it as shown in Figure 6.2 of the above URL. That is somewhat a cross between 3 and 4. The other main point is whether we should have a lockdown key or instead query the writability of an existing key. At the moment pessulus/sabayon is all geared up for the former with no support for the latter. In reality I think we will need to support both. The former for cases where there is not a single key that is sensible to write protect. e.g. disabling the moving/modification of the panel and the latter for things protected by a single key, e.g /desktop/gnome/typing_break/allow_postpone and e.g. /desktop/gnome/typing_break/enabled :) Since Thomas says there are a multitude of keys that would need to be made read-only (there is also a one entry in pessulus to one gconf key mapping) then I propose my original solution which includes a theme_lockdown key.
Created attachment 68946 [details] [review] New lockdown patch This patch includes a notice at the top of the window to indicate to the user he does not have permission to change the theme settings. I cleaned up various bits of the previous patch too, although I am not sure that /desktop/gnome/interface/lockdown_theme_change is the best key name for this option. I noticed there is a lockdown section under /desktop/gnome. Would it be better for this option to be placed in there as disable_theme_settings?
Yes. Much better. Revised patch attached. I also tidied up the formating for the #defines for the keys.
Created attachment 69384 [details] [review] Version of the patch using newly suggested key.
Patch looks fine to me. I've requested to commit it from the release team, since we are now in feature freeze.
Patch committed to HEAD, thanks
Rodrigo: are you on the release team? I've only had one approval of two needed so far. Also, are you going to notify the i18n team of the string change?
Oops, no, sorry. Let me know if it gets refused and I'll revert it back. And if it gets approved, let me know also so that I mail i18n
It has now got approval from the release team, so please notify i18n about the new string.
This may not be the ideal place to say this but I feel it needs to be said. I am concerned about lockdown in general as a user who has suffered under the pitiful attempts at lockdown on Windows machines. In the case of themes it would be inhumane to force users to use the standard theme when they need a high contrast theme, or large fonts. It bothers me that we would be giving the inept administrator more power to torture their users and make Gnome into something people would despise and hate using. I would strongly encourage developers to consider the wider usability impact of Lockdown. There is an underlying maintaince problem that lockdown aims to solve rather than being an end in itself. If at all possible I would also encourage you to explore the more difficult approach and instead of lockdown (or as well as) try to make it easier for users to revert to a last known good state.
Perhaps this is another argument from moving the accessibility themes and font options out of the theme manager and into the accessibility capplet.
FWIW, I've added that as a possible topic to discuss at the Boston Summit[1] (not that I'll be there myself). See also Bill's reservations about doing this sort of thing though.[2] [1] http://live.gnome.org/Boston2006/AccessibilitySummit [2] http://mail.gnome.org/archives/gnome-accessibility-list/2005-October/msg00023.html