I would prefer to see general documentation regarding all the settings possible in the file.... with maybe notes saying "This option is not accessible in the gui but can be set manually in the file"
On Thu, May 12, 2016 at 11:20 PM, jp charras <jp.char...@wanadoo.fr> wrote: > Le 12/05/2016 à 01:22, Chris Pavlina a écrit : >> 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? > > Perhaps a file like <src>/Documentation/developers_notes.txt ? > > >> >> 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 >> > > > -- > 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
