On Wed, 28 Jun 2017 06:39:41 -0700 (PDT) "Edward K. Ream" <[email protected]> wrote:
> 1. Clarity and simplicity of *purpose*. > 2. Stability and simplicity of *user interface*, including gui and > scripting api. > 3. Simplicity of *code*. [snip] > In this discussion, the first two priorities demand that Leo continue > to use outlines to represent the hierarchy of settings. I don't really think that follows in any particularly clear manner. 1. is a general goal no one can argue with. The success of the current code in the context of 1. is questionable, seeing new and even experienced users struggle with settings management. 2. GUI wise Leo has discarded GUI's in the past, and now has two. I think what you're saying is that setting management *must* remain something that can be done within Leo using the tree and body panes. I guess that's an understandable desire, although to date it doesn't help resolve the settings management challenges. I'm not sure if you meant to apply the scripting api clause to this discussion, but it doesn't seem relevant. There would be no change to the signature of g|c.config(). If you mean that it would no longer be possible to edit settings by editing settings .leo files with Leo's API, that would be true, but I would argue that no one does that anyway. [snip] > For example, yesterday I discovered a settings table that inited > several commander ivars. My first thought was, maybe this table > could go away. But no. These ivars appear all over Leo. It would be > horrible to use c.config.getInt or c.config.getBool in their stead. If you're referring to ivarsData, I don't think that's relevant - the issue of objects "caching" config. vars. as ivars is orthogonal to the proposed alternative g|c.config() implementation. I think a confusing part of this discussion is that it's unclear whether it's about simplifying code or improving the settings ui. I think it's both, i.e. a proposal to use a DB as a key value store that would hugely simplify loading of settings, and also reduce the technical barriers to implementing a less challenging settings UI. But as long as there's a requirement for Leo settings to be editable as Leo outlines, the DB implementation is probably not useful. With respect to the settings struggles I think it's important to remember these numbers, which I'm about to make up: 0% - percent of Leo users whose primary use of Leo is developing Leo, rounded to the nearest percent ;-) 10%?, 20%?, 50%? - percent of Leo users whose primary use of Leo is developing in Python (I have no idea what this number is) 10%?, 20%?, 50%? - percent of Leo users who do not use Leo for coding at all (I have no idea what this number is either) Given those numbers, I think it's clear that the current settings management options will always be a barrier for a significant number of users. Even, hard though it is to believe, with cff :-) Cheers -Terry -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
