kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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
>