While we're discussing making an option config-file-only, do we have a preferred place in developer documentation to list these sorts of things?
On Wed, May 11, 2016 at 02:50:10PM +0200, jp charras wrote: > Le 11/05/2016 à 14:32, Wayne Stambaugh a écrit : > > At a minimum I would leave the config file entry and the code to access > > the config entries in place so you could manually modify the config file > > for debugging purposes. @JP, would that be acceptable to you? I agree > > that we should not expose debugging settings in the UI but I also > > understand the need for development settings without having to create a > > special build just to debug a specific section of code. > > Yes, this is acceptable. > > > > > On 5/10/2016 3:31 PM, Chris Pavlina wrote: > >> Actually, you might be onto something. Of course you can FRO with the > >> environment vars ;D but perhaps we could leave it an option to be set in > >> the > >> configuration manually for the one time in 2018 JP wants to restrict this > >> for > >> debugging... > >> > >> On Wed, May 11, 2016 at 06:58:58AM +1200, Simon Wells wrote: > >>> or just make it so it always works but is either a command line > >>> option/env variable or manually editing the configuration file > >>> > >>> On Wed, May 11, 2016 at 6:56 AM, Chris Pavlina <pavlina.ch...@gmail.com> > >>> wrote: > >>>> Urgh, do we really need to keep features that a developer may need at > >>>> some > >>>> point in the future in the UI? This is something that one person may > >>>> need once > >>>> sometime next year. Can't we make this a #define or something instead? > >>>> > >>>> We really shouldn't be cluttering everyone's UI with developer-only > >>>> options. > >>>> > >>>> On Tue, May 10, 2016 at 08:54:05PM +0200, jp charras wrote: > >>>>> Le 10/05/2016 à 20:41, Chris Pavlina a écrit : > >>>>>> Back in August (git:aaadb40), I made the undo history infinite in > >>>>>> pcbnew, > >>>>>> eeschema, modedit, and libedit. Wayne wanted this to remain an option, > >>>>>> in case > >>>>>> of issues with the memory consumption of the undo stack. Currently, if > >>>>>> you set > >>>>>> "Maximum undo items" to zero, you get infinite history. I also made it > >>>>>> default > >>>>>> to unlimited. > >>>>>> > >>>>>> In the seven months since I did that, has anybody ever needed to limit > >>>>>> that? > >>>>>> I've found the memory consumption caused by it to be quite minimal > >>>>>> even on very > >>>>>> long layout sessions (I do not often shut my computer down other than > >>>>>> to > >>>>>> install kernel updates and do not generally close things I'm working > >>>>>> on, so > >>>>>> pcbnew can remain open for weeks at a time...). > >>>>>> > >>>>>> And if nobody has needed to change the limit, can I remove it to > >>>>>> reduce options > >>>>>> clutter? > >>>>>> > >>>>> > >>>>> Please, do not remove it. > >>>>> For most of users, this option is not useful. > >>>>> > >>>>> However, developers need to be able to set the value (usually at a low > >>>>> value like 2 or 3) when the > >>>>> undo/redo has an issue (usually related to object deletion), even in > >>>>> release mode. > >>>>> Sometimes a crash can happen when objects in undo/redo list are > >>>>> deleted, if there is a bug in these > >>>>> functions. > >>>>> > >>>>> -- > >>>>> Jean-Pierre CHARRAS > > > > -- > Jean-Pierre CHARRAS > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
