On Wed, Jun 28, 2017 at 12:05 PM, Terry Brown <terrynbr...@gmail.com> wrote:
> On Wed, 28 Jun 2017 06:39:41 -0700 (PDT) > The success of the current > > code in the context of 1. is questionable, seeing new and even > experienced users struggle with settings management. > Imo few (none?) of those problems arise because Leo represents settings in .leo files. > 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. > Yes, I think that's what I meant ;-) 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(). Good. I wasn't sure about this point. > > 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 was referring to ivarsData. I didn't mean to imply that this was directly relevant to the discussion, although Vitalije's suggestion to replace these ivars with python properties is interesting. > > 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. > I object to changing the UI on the grounds that it would simplify code. I don't want people to have to change their settings files! Maybe a prototype will convince me that settings files are dumb idea. Until then, I remain skeptical. > But as long as there's a requirement for Leo settings to be editable as > Leo outlines, the DB implementation is probably not useful. > That's the rub. But maybe I'll get really excited by the prototype. With respect to the settings struggles > [big snip] > I think it's clear that the current settings > management options will always be a barrier for a significant number of > users. I don't have that sense, but if it's true I would welcome proposals to simplify matters. A proposal that says, in effect, I have a great idea for throwing away all of Leo's settings machinery is going to be a hard sell, but possibly not impossible sell. Incremental proposals would likely be easier to understand and evaluate. Edward -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
