kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 03/31/2011 09:22 AM, Wayne Stambaugh wrote:
> On 3/31/2011 9:32 AM, Dick Hollenbeck wrote:
>> User options, preferences, state, and settings:
>>
>> These all mean different things to different people, until you have a set of
>> definitions.  So I will try briefly to distinguish and define.
>>
>>
>>
>> 1*) User options
>>
>> These are the same things  as "user preferences", and come in at least two
>> flavors:
>>
>> a) what to use on a new project, when it is first created.  These could and
>> should be configurable such that any new project gets these settings as
>> initial values.  Obviously these start from a global place, and get copied
>> into a project specific place.
>>
>> b) schematic specific options are also configurable, affect only current
>> schematic, and reside in a schematic specific place.
>>
>>
>>
>> 2*) State variables
>>
>> These are things which change as a result of using the schematic editor,
>> such as mouse pointer position and sheet on screen, currently selected mouse
>> tool, and zoom level.
>>
>>
>>
>>
>> 3*) Settings
>>
>> I guess this means user options, but since it is ambiguous, and not clearly
>> conveying a new concept, we probably should not use this term.
>>
>>
>>
>> My proposal to put the stuff into the schematic, pertains to 1*b) and 2*). 
>> Inherent in my proposal is the desire to address the needs of those using a
>> version control system, which includes me also.
> 1*b absolutely belong in the schematic.  Would it be better to save 2* in a
> state_file or path/state_file so you have the benefit of last editor state
> without changing the schematic file?  When using version control, you just
> ignore the state file or path using your VCS's ignore directive.  The other
> advantage is that when you revert from CVS to a previous version, you don't
> lose your last editor state settings.



I don't know what state settings are.

I know what state variables are, since I defined them in the last email.

State variable are not adjustable, they simply track state, and if they
disappear this is no big deal, you simply start the editor on the first
sheet with mouse pointer at a default location and the zoom at a default
magnitude.


State variables can easily be omitted from a save function:


SHEET::Format( OUTPUTFORMATTER* out, int nestLevel, int ctlFlags )
{

    :

    if( !(ctlFlags & CTL_OMIT_STATE) )
        state->Format( out, nestLevel+1, ctlFlags );

    :
}


The sheet can easily be saved twice:


======================================================
sheet->Format( out1, 0, 0 );

// this one I check into my VCS:
if( wantVCS )
    sheet->Format( out2, 0, CTL_OMIT_STATE );
======================================================



What gets omitted from out2 is an s-expression element that looks something
like this:

# things bad for VCS:
(state_stuff
    ( mouse ....)
    ( zoom_level ....)
    ( sheet_in_view ...)
    ( tool_in_use zone )
    ( date_of_save ... )
    ( mood currently bad )
   
)



If you don't like state_stuff, don't save it.  I identified it as a group of
problematic items for a difference detector in the VCS.  

In any case, taking a look at the C++ within EESCHEMA, the state variables
belong to the SCHEMATIC object in view, and in case you ever want to support
viewing more than one SCHEMATIC, it becomes necessary to go object
oriented.  And I naturally assumed they should be therefore kept *with* the
SCHEMATIC. 

The point about VCS differenced detection is valid, and my proposal deals
nicely with the VCS need.  Yet it remains only a proposal.