From: Nick H. <nic...@ho...> - 2009-10-05 12:31:23
|
Doug Blank wrote: > On Mon, Oct 5, 2009 at 5:07 AM, Nick Hall <nic...@ho...> wrote: > >> Benny Malengier wrote: >> >>> This can indeed be done more easy. The present way is compatible with >>> the gnome config way, and was done to have kde, windows, ..., have the >>> same 'methods' as those using gnome. >>> >>> Gconf is deprecated now, so we can change things. Constraint is >>> perhaps some 'upgrade' way so that old settings move to the new system >>> on first use. >>> >>> One thing that would be nice to have stored: size of the columns in >>> the tab pages, and the views. We now only save size of windows. That >>> would mean a large amount of extra keys though, and I didn't want to >>> do that last time I hacked in that code. >>> >>> >> This would be good. >> >>> There are some existing libraries for config files in python I >>> believe, no need to reinvent the wheel. >>> >>> >> The existing code already uses ConfigParser but only to read the file. This >> module gives the functionality Doug describes in (a) and (b). The options >> are stored as text but there are convenience functions to convert to float >> and boolean. >> >> It would be easy to sub-class the parser to emit a signal when a setting is >> updated. It would also be good to provide convenience functions for load() >> and save() which would call read() and write() with the appropriate >> filename. >> >> The default values are handled in a separate [default] section which is not >> what we need so a method would be needed to read these from a data >> structure. >> >> No upgrade would be needed because the ini file format would be the same. >> > > Actually, the ini file will have to change slightly, so that the type > of the setting's value is indicated by the value (quotes -> string, > etc). Currently, the value 0 could be a string, an int, or a boolean > the way we have it implemented. > > Would this really give much advantage? For example, if you wanted to get the clipboard height, with ConfigParser you could type: cliph = config.getint("interface", "clipboard-height") You know you are expecting an integer, you could trap for a ValueError exception in case a user manually edited the ini file and put something stupid in there. With ConfigParser the ini file format would stay the same, we would be re-using existing code and python developers may already be familiar with the interface. > So, the upgrade path is the only thing I didn't mention, and would > need a plan. Perhaps the easiest solution would be to migrate from > keys.ini to gramps.ini and make it a new file. (If we do consider > that, then the file could be XML which would allow us to have much > more flexibility, but might make it harder for users to change a > setting. But going from ini to xml is a change independent of the > current proposal, and can be done at any point easily.) But I think we > an leave it as keys.ini if there was a reason to do so. > > -Doug > > >> There would be many changes in the code where settings are accessed though. >> >> Nick. >> >>> Benny >>> >>> 2009/10/4 Doug Blank <dou...@gm...>: >>> >>> >>>> Devs, >>>> >>>> I've been wrestling with the manner in which we have evolved our >>>> gramps Config code, and I'd like to propose a re-organization. Most of >>>> the cruft has accumulated as we evolved away from gconf, towards a >>>> file-based .ini solution. It is overly complicated, and unnecessarily >>>> limited. >>>> >>>> First, here are some of the problems that I see with the current config >>>> code: >>>> >>>> 1) In order to add a new configure setting, you have to give it two >>>> names. For example, in: >>>> >>>> src/Config/_GrampsConfigKeys.py >>>> >>>> you need to give it a Python constant name (such as EXPORT_NO_PRIVATE) >>>> and you also have to give it a section/setting/typecode like >>>> ('export', 'no-private', 0). Also, you give it a default, in a >>>> different location in this file. You have to know the type of the >>>> setting to find the default as it is keyed off of the (section, >>>> setting, typecode) tuple: >>>> >>>> default_value = { >>>> ... >>>> EXPORT_NO_PRIVATE : True, >>>> ...} >>>> >>>> 2) In order to look up or change a setting, you have to use the awkward >>>> syntax: >>>> >>>> Config.get(Config.EXPORT_NO_PRIVATE) >>>> Config.set(Config.FILTER, obj.get_active()) >>>> >>>> 3) Currently there is no manner for a third-party plugin to have >>>> easily accessible settings, short of writing their own config code and >>>> creating a separate file. For example, plugins have typically added >>>> their settings in the file above, or have created their own config >>>> file that the user has to find to edit. >>>> >>>> 4) If you change a config setting, sometimes you have to wait until >>>> you restart gramps for that change to take effect. Some of these >>>> changes could perhaps take effect immediately with a better designed >>>> config handler. >>>> >>>> 5) Currently, there are only 3 types of values that you can currently >>>> put in the ~/.gramps/keys.ini file: strings, ints, and booleans. >>>> >>>> The solution that I'd like to propose should fix many of these, and >>>> help lead to a solution for the others. In addition, it is less code, >>>> and is a more intuitive API: >>>> >>>> a) Create a standard way to add sections, settings, and default >>>> values. Something like: >>>> >>>> Config.init("export.no-private", True) >>>> >>>> The given name would be THE name for the setting, and would exactly >>>> match the keys.ini file. >>>> >>>> b) Create a standard way to retrieve and set the settings: >>>> >>>> Config.get("export.no-private") >>>> Config.set("export.no-private", False) >>>> >>>> and to remove them: >>>> >>>> Config.delete("test-plugin.linecount") >>>> Config.delete("test-plugin") >>>> >>>> c) Currently, all keys are stored internally as strings, and converted >>>> to a type on lookup. I'd like to create a format in the keys.ini that >>>> stores the setting type, so that you can get return the appropriate >>>> value and type (0, "0", or False). The easiest manner would be to use >>>> a very simple syntax for the parser (For example, if it starts with a >>>> quote, it is a string, else if it is True or False is is a bool, else >>>> if it has a dot in it it is a float, else an int). >>>> >>>> To give some protection from overwriting system level settings, one >>>> can require plugins to write only to specially named sections (such as >>>> [geoview-plugin]). I think we can still ensure that any settings must >>>> have the same type as the default to give some sanity checks. I would >>>> also require that you can only Config.set a name that has been >>>> Config.initialized. >>>> >>>> In addition, I think that we *could* be backwards compatible (if we >>>> wanted) but I'd advocate for a wholesale update. >>>> >>>> The only other concern I can think of is that keys.ini might grow too >>>> big, or that a third-party plugin could corrupt the file. But I think >>>> we can make sure that we have it properly formatted when you write it, >>>> and check for proper values when setting. I'd rather have a little bit >>>> larger keys.ini file with all of the settings there than having config >>>> files spread around. In fact, gramplets could use this config system >>>> too, and remove the gramplets.ini file. >>>> >>>> It could be possible in the future to have the Preferences just be a >>>> handy way to change all of the values in this file. >>>> >>>> Other comments, concerns, ideas? >>>> >>>> -Doug >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Come build with us! The BlackBerry® Developer Conference in SF, CA >>>> is the only developer event you need to attend this year. Jumpstart your >>>> developing skills, take BlackBerry mobile applications to market and stay >>>> ahead of the curve. Join us from November 9-12, 2009. Register >>>> now! >>>> http://p.sf.net/sfu/devconf >>>> _______________________________________________ >>>> Gramps-devel mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>> >>>> >>>> >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry® Developer Conference in SF, CA >>> is the only developer event you need to attend this year. Jumpstart your >>> developing skills, take BlackBerry mobile applications to market and stay >>> ahead of the curve. Join us from November 9-12, 2009. Register now! >>> http://p.sf.net/sfu/devconf >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >>> > > > |