242
edits
CCK:Overview: Difference between revisions
m
no edit summary
No edit summary |
mNo edit summary |
||
| (13 intermediate revisions by 8 users not shown) | |||
| Line 68: | Line 68: | ||
--[[User:MikeKaply|MikeKaply]] 08:38, 28 Apr 2005 (PDT) | --[[User:MikeKaply|MikeKaply]] 08:38, 28 Apr 2005 (PDT) | ||
Was there any effort made in the beginning to move some of the CCK specific changes into preferences, or was it always assumed that DTD/properties files would be modified? | Was there any effort made in the beginning to move some of the CCK specific changes into preferences, or was it always assumed that DTD/properties files would be modified? | ||
--[[User:Robin|Robin Lu]]-4/29 09:38:01 CST 2005 | |||
No. Some changes have to be in DTD/properties files for l10n reason. | |||
Can we divide CCK to two components? One cares about the default settings. Installer package builder is for that. A lot of changes can be made here, including preferences, DTD/properties, bookmarks, icons, RDF and more. The other cares about managing. MCD had both of the components while Netscape CCK only has the first one - installer builder. | |||
Right now, only preferences can be managed. Although we can use extension but it highly depends on the users, which is not a good way for management. What do you think should be managed besides preferences? | |||
--[[User:MikeKaply|MikeKaply]] 06:47, 29 Apr 2005 (PDT) | |||
I definitely thing two components is the way to go, and I like your web management idea a lot. | |||
The only other thing I think someone might want to do is remove/disable menuitems as well as preferences for a corporate lockdown (or about:config for instnace) | |||
So you are correct, one focuses on being very to the CCK, and one focuses on locked preferences and possibly locking other things. | |||
And perhaps we can make the install piece use a mozilla.cfg file if it is available to combine the two (not just putting the jsc file on a server) | |||
--[[User:Robin|Robin Lu]] 4/30 10:21:50 CST 2005 | |||
You are right. The mozilla.cfg should be added into install package by installer builder to enable the autoconfig by default. It is the connection point. | |||
For the menu lockdown, we should find out if admin want to lock the menu by default or they want to manage/change what to lock after deployment. I believe locking the menu by installer builder can meet most of the requirement. "Lock" is not the reason for it in management component. With installer builder, you can also lock some preferences by default. Management is about "change". What do you think? | |||
--[[User:Roc|Robert O'Callahan]] | |||
Just so you know ... Novell is working on code to use the gconf system pref service http://lxr.mozilla.org/mozilla/source/extensions/pref/system-pref/src/gconf/nsSystemPrefService.cpp. to lock prefs. gconf already supports "read only" system preferences that can't be overridden by users. We want to extend this support to the gconf system pref service so that the Mozilla pref is locked when the gconf pref is read-only. (Right now the way we do this is terrible, I need to fix it up.) | |||
[[category:CCK|Overview]] | |||