Woo! Thanks for being on the pro-Doxygen side, I was going to just go ahead and use Doxygen and hope nobody bothered arguing against it ;) As we should /definitely/ be using Doxygen for this sort of thing.
On Thu, May 12, 2016 at 10:08:13AM -0400, Wayne Stambaugh wrote: > We should be using the Doxygen documentation for this. At some point we > should group things in some sane fashion within the Doxygen docs and > generate a decent main page. Our current main page (index.html) is > empty except for the code links. I've played around with this from time > to time but I cannot get the grouping to play nice with the markdown > documentation so I may need to rethink that. Honestly, I haven't spent > much time on it but it's definitely something we need to improve. > > I want to remove all of the plain text files we currently are using for > documentation at some point. I just need to sort through them and > figure out what we need and what we can get rid of. If it's worth > documenting, then it should be part of the Doxygen documentation. > > On 5/12/2016 9:53 AM, Chris Pavlina wrote: > > I'm going to document the one developer setting for now; we can discuss > > later > > whether we should go back and add all the settings to the developer > > documentation. I think it'd be nice to have them documented, personally. > > > > On Fri, May 13, 2016 at 01:50:29AM +1200, Simon Wells wrote: > >> 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 <[email protected]> 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 > >>>>>>>> <[email protected]> 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 : [email protected] > >>>>> 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 : [email protected] > >>> Unsubscribe : https://launchpad.net/~kicad-developers > >>> More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : [email protected] > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
