On Jan 30, 11:51 am, "Edward K. Ream" <[email protected]> wrote:
> I'm struggling to understand why g.app.config exists at all The short answer is that the g.app.config class is permanent, and can be used even when commanders do not exist. Because it is always available, it serves as a useful holder for all config-related methods. The c.config methods merely call the g.app.config methods with a non- None 'c' argument. It's a bit clumsy, but it allows the commander config methods to set ivars in the commander. > I can't explain how global settings (g.app.config) ever get set. Now I can. 1. g.app.config **ivars* get set in setIvarsFromSettings as the result of a call at the end of readSettingsFiles. 2. g.app.config **settings** get set as the result of reading leoSettings.leo and myLeoSettings.leo by readSettingsFiles. These settings form the defaults for all per-.leo-file settings. They create various dicts in the g.app.config object. Calls to c.config.getWhatever search per-commander dicts first, and then search the g.app.config dicts. > There may be an opportunity for an important collapse of complexity here. I don't have a lot of hope here. The present situation is actually pretty good. The essence of the problem is that we must have a global config class to handle defaults created *before* individual non- settings .leo files get loaded. This isn't going to go away. I did find one place where the code can be simplified. The calls to setIvarsFromSettings(c) in the "middle" of readSettingsFiles are useless and will eventually go away. The call to setIvarsFromSettings (c) that "works" is in the ctor for the c.configSettings wrapper. But this is an insignificant nit. I added lots of traces to reveal what is happening in the various config init logic. They reveal that the present code, though complex, almost certainly can not be significantly improved. > I'm going to make an intensive study of the situation. I'm reviewing all ivars set by setIvarsFromSettings. This method sets ivars in g.app.config **or** the present commander, depending on how it is called. It seems to me that the g.app.config ivars should almost never be used. That is, the call to setIvarsFromSettings (c=None) at the end of readSettingsFiles doesn't make much sense. I'm going ivar-by-ivar through the code looking for places where the code uses g.app.config ivars when the code could (and therefore should) use c.config ivars instead. I've found a few already. A few global ivars will be retained because they are part of the commander read logic. All other g.app.config ivars should be eliminated. > The question arises what, if any, simplifications would be appropriate > for Leo 4.7 b3. I did create a branch, but it looks like I'll abandon it shortly. It would be foolhardy to attempt anything substantial now. And it's looking like nothing much can be done anyway, apart from a few minor corrections of individual ivars and settings. In short, it's time to focus on the issue at hand, namely the various encoding settings. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
