kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

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 <jp.charras@xxxxxxxxxx> 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.chris@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> >>>>> 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@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> > 
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp