kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 09/25/2013 08:04 AM, Wayne Stambaugh wrote:
> On 9/24/2013 9:29 PM, Dick Hollenbeck wrote:
>> On 09/24/2013 07:14 PM, Wayne Stambaugh wrote:
>>> On 9/24/2013 6:40 PM, Dick Hollenbeck wrote:
>>>>
>>>> On Sep 24, 2013 5:29 PM, "Wayne Stambaugh" <stambaughw@xxxxxxxxxxx
>>>> <mailto:stambaughw@xxxxxxxxxxx>> wrote:
>>>>>
>>>>> On 9/24/2013 6:17 PM, Dick Hollenbeck wrote:
>>>>>>
>>>>>> On Sep 24, 2013 5:14 PM, "Wayne Stambaugh" <stambaughw@xxxxxxxxxxx
>>>> <mailto:stambaughw@xxxxxxxxxxx>
>>>>>> <mailto:stambaughw@xxxxxxxxxxx <mailto:stambaughw@xxxxxxxxxxx>>> wrote:
>>>>>>>
>>>>>>> On 9/24/2013 5:15 PM, Dick Hollenbeck wrote:
>>>>>>>> On 09/24/2013 03:14 PM, Wayne Stambaugh wrote:
>>>>>>>>> On 9/24/2013 3:34 PM, Lorenzo Marcantonio wrote:
>>>>>>>>>> Premise: I don't get why this was done, since I find the existing
>>>>>>>>>> library-order search perfectly adequate, however it's an
>>>> interesting
>>>>>>>>>> idea and obviously must have its merits (simply I can't see them,
>>>>>> I need
>>>>>>>>>> better glasses or a different workflow :P). Also I use the
>>>> 'board as
>>>>>>>>>> a library' approach suggested in the manual i.e. I never use the
>>>>>> library
>>>>>>>>>> related operations in the module editor. Create footprint
>>>> archive does
>>>>>>>>>> the library creation step for everything (for now it supports
>>>> only the
>>>>>>>>>> legacy mod files, will that change with the new file-for-module
>>>>>>>>>> libraries?)
>>>>>>>>>>
>>>>>>>>>> First of all: very good the environment variable replacement idea;
>>>>>> a lot
>>>>>>>>>> of symlinks trickery was required to make it work for different
>>>> users.
>>>>>>>>>>
>>>>>>>>>> Tried to play with the library path dialog and it's good. I
>>>>>> presume that
>>>>>>>>>> the 'path' column changes significance depending on the plugin
>>>> (a .mod
>>>>>>>>>> file for legacy, a directory for the new format and so on);
>>>> that plus
>>>>>>>>>> the path substitution makes impossible a 'browse' button for the
>>>>>>>>>> path...however I think that nearly immediately users will ask
>>>> for it!
>>>>>>>>>> In fact I have many libs and I generated the fp file with a
>>>> shell one
>>>>>>>>>> liner:P
>>>>>>>>>
>>>>>>>>> The ability to use any footprint library that is supported by a
>>>> plugin
>>>>>>>>> without having to convert them to one of Pcbnew's formats is
>>>> important
>>>>>>>>> for some users and certainly is more convenient.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Has the description column some significance or it's only a remark?
>>>>>>>>>
>>>>>>>>> It's just a remark that gets saved in the footprint library table
>>>>>> entry.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Possibly useful enhancement: while playing I added an inexistant
>>>>>> pathname... the
>>>>>>>>>> next cvpcb run it said:
>>>>>>>>>>
>>>>>>>>>> Some files are invalid!
>>>>>>>>>> IO_ERROR: Footprint library path does not exist <<< here the
>>>>>> missing file would be useful
>>>>>>>>>> from /home/lomarcan/cvswork/kicad-bzr/pcbnew/kicad_plugin.cpp :
>>>>>> Load() : line 214
>>>>>>>>>
>>>>>>>>> I'll take a look at it.  I did fix a few bugs in r4345 so I may have
>>>>>>>>> already fixed it.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Another thing trapped by my wx debug build:
>>>>>>>>>>
>>>>>>>>>> ASSERT INFO:
>>>>>>>>>> ./src/generic/listctrl.cpp(3063): assert "col >= 0 && col <
>>>>>> GetColumnCount()" failed in SetColumnWidth(): invalid column index
>>>>>>>>>>
>>>>>>>>>> BACKTRACE:
>>>>>>>>>> [1] wxOnAssert(char const*, int, char const*, char const*, wchar_t
>>>>>> const*)
>>>>>>>>>> [2] wxGenericListCtrl::SetColumnWidth(int, int)
>>>>>>>>>> [3] FOOTPRINTS_LISTBOX::SetFootprints(FOOTPRINT_LIST&, wxString
>>>>>> const&, COMPONENT*, int)
>>>>>>>>>> [4] CVPCB_MAINFRAME::BuildFOOTPRINTS_LISTBOX()
>>>>>>>>>> [5] CVPCB_MAINFRAME::ReadNetListAndLinkFiles()
>>>>>>>>>>
>>>>>>>>>> It does so often (every time it repopulates the right column), and
>>>>>> I see
>>>>>>>>>> no sign of column resizing... I have seen the bug comment in
>>>> the code
>>>>>>>>>> and it trips even on wx 2.9 with gtk-2.0. That's just for
>>>> information.
>>>>>>>>>
>>>>>>>>> This one should be fixed in r4345.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Then I tried to 'update' a couple of components: it was C0805 (old
>>>>>>>>>> package), then become smd:C0805. Everything fine till now, saved
>>>>>> the cmp
>>>>>>>>>> file without problems. Maybe one day the cmp file will go away and
>>>>>> only
>>>>>>>>>> the netlist will survive :D (the problem is when a part is
>>>> deleted and
>>>>>>>>>> a new one get its refdes... from the cmp file it takes the *old*
>>>>>>>>>> package, which is bad)
>>>>>>>>>
>>>>>>>>> At some point, I plan on doing away with the cmp file.  I have
>>>> to write
>>>>>>>>> the code so Pcbnew can save the new s-expr netlist file.  Once
>>>> that's
>>>>>>>>> done, cmp files will go away as will the legacy netlist files.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Backannotation in eeschema, it works as expected. However there is
>>>>>>>>>> a catch: the 'qualified' names are usually way too long to be
>>>> shown in
>>>>>>>>>> the drawing. Maybe an option to display only the 'short' name
>>>> would be
>>>>>>>>>> useful (only display, the attribute must remain intact).
>>>>>>>>>
>>>>>>>>> You might want to have a talk with library folks about the length
>>>>>> of the
>>>>>>>>> file and footprint names.  Is it really necessary to have a library
>>>>>>>>> named Allegro_ACS754_ACS755_ACS756_HallCurrentSensor_RevA with a
>>>>>>>>> footprint named Allegro_HallSensor_Package-CB-PFF_24Oct2012?  I
>>>> would
>>>>>>>>> think allegro_hall_current_sense and package_cb_pff would be plenty
>>>>>>>>> readable without wrapping on a 1920X1200 monitor.  You can always
>>>>>> change
>>>>>>>>> the library nicknames to something shorter.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Back to pcbnew... tried to refresh the netlist. As expected it
>>>> noticed
>>>>>>>>>> a mismatch (names from cmp, keep modules), however it says:
>>>>>>>>>>
>>>>>>>>>> Warning: component `C8` has footprint <C0805> and should be
>>>>  <C0805>
>>>>>>>>>>
>>>>>>>>>> I'd expected to read "should be <smd:C0805>", or am I wrong? during
>>>>>>>>>> actual replacement the message is correct, anyway:
>>>>>>>>>
>>>>>>>>> You are correct.  I missed that.  I'll add it to the list.  At
>>>> least it
>>>>>>>>> replaces with the correct footprints.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Replacing component "C8:/4BA0B4A0" footprint "C0805" with
>>>> "smd:C0805".
>>>>>>>>>>
>>>>>>>>>> (is that timestamp really useful? maybe when selecting using
>>>>>> timestamps
>>>>>>>>>> and not references... but then it would be useful in the previous
>>>>>>>>>> message too)
>>>>>>>>>>
>>>>>>>>>> Editing the replaced component shows the qualified name in the
>>>>>>>>>> 'footprint name in library'... I think this need a little caution,
>>>>>>>>>> however; this is because of how libraries are made.
>>>>>>>>>>
>>>>>>>>>> - In a project board that value represents from which library the
>>>>>>>>>>   component came from and the module name.
>>>>>>>>>>
>>>>>>>>>> - In a master board for library creation that is the module name
>>>>>> but, in
>>>>>>>>>>   fact, the library has not significance (since we are going to
>>>>>> write in
>>>>>>>>>>   a specific, maybe new, library). In fact during the archival
>>>> process
>>>>>>>>>>   the library nick is simply stripped (I'd have done the same).
>>>>  Still
>>>>>>>>>>   I don't get *why* it takes so long:P
>>>>>>>>>>
>>>>>>>>>> Maybe would be probably better to split the field in the module
>>>>>>>>>> properties? It needs some more thinking.
>>>>>>>>>
>>>>>>>>> I still have some testing to do with the footprint editor.  I'll
>>>> see if
>>>>>>>>> I can make it more user friendly in this regard.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> All in all it seems to work... I'm using it and if something
>>>> else pops
>>>>>>>>>> up I'll let you know. Having the multiple library backend and
>>>> variable
>>>>>>>>>> substitution is surely an improvement from the previous
>>>>>> implementation.
>>>>>>>>>>
>>>>>>>>>> One last thing: I think we should stop polluting the home
>>>> directory.
>>>>>>>>>> With non-dot files, even! By the way, why are lock files there
>>>> instead
>>>>>>>>>> of aside the original files like before? it is an accepted practice
>>>>>>>>>> (like the .*.swp files for vi) and doesn't pollute the home.
>>>> Frankly
>>>>>>>>>> I find all these _home_lomarcan*lock files quite ugly. Now there
>>>>>> is the
>>>>>>>>>> fp-lib-table which is a permanent file too... why not allocate a
>>>>>> .kicad
>>>>>>>>>> or a .config/kicad directory and put all that cruft there (with the
>>>>>>>>>> individual .eeschema, .pcbnew files and so on, too)?  (Application
>>>>>> Data
>>>>>>>>>> would be the equivalent for Windows systems)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I agree.  This is already on my list as well.  At some point, I
>>>> plan on
>>>>>>>>> moving all the KiCad config files into the .kicad folder in the
>>>> user's
>>>>>>>>> home folder on Linux.  Unfortunately, there is no easy way to do
>>>> this
>>>>>>>>> for Windows users.  Converting the KiCad configuration settings
>>>> in the
>>>>>>>>> registry to config files is not trivial.  I may make Windows user's
>>>>>>>>> reconfigure KiCad rather than try to convert the registry entries
>>>>>> when I
>>>>>>>>> get around to this.
>>>>>>>>
>>>>>>>> Where does the project specific table get saved to when I have to
>>>>>> establish a project, but
>>>>>>>> rather have simply started pcbnew from the command line without a
>>>>>> filename?
>>>>>>>>
>>>>>>>> Otherwise I assume it is saved in the same dir as the *.kicad_pcb?
>>>>>>>>
>>>>>>>>
>>>>>>>> Dick
>>>>>>>>
>>>>>>>>
>>>>>>> That is how it's supposed to work unless there is some issue that I
>>>>>>> missed.  The few projects that I tested it on seemed to work fine.  Let
>>>>>>> me know if it's getting saved somewhere else and I will fix it.
>>>>>>
>>>>>> You did not answer my first question, I don't know where it gets saved
>>>>>> if no project.  But it is.
>>>>>
>>>>> Sorry about that.
>>>>>
>>>>>>
>>>>>> I like what I see, but wanted to examine the project table.  Can not
>>>>>> find it for case when no project.
>>>>>
>>>>> That would be a bug on my part.  It should not save the project
>>>>> fp-lib-table if no board file is loaded.  Is there a way to not show the
>>>>> project specific tab in the footprint table edit dialog.  That seems
>>>>> like a reasonable indicator to the user that no project footprint
>>>>> library table is not available.  I'll take a look at the project
>>>>> footprint library table save code and make the necessary fixes.
>>>>
>>>> Quite mutiny is not desired.   So simply not saving it is worse. 
>>>>
>>>> If this is not something we can agree on, we should keep talking.  Can
>>>> we explore some more ideas. Please?
>>>>
>>>> I think saving it in home directory and loading from home directory WHEN
>>>> NO PROJECT DEFINED is best.  This lets the command line user start a new
>>>> project by inheriting the project table from home.
>>>
>>> Just so I'm clear, are you talking about adding entries from the project
>>> specific table the global footprint table when no board file is loaded?
>>>  The global table is always loaded, board file or no board file and is
>>> the fallback table to either the project specific table or and empty one
>>> if it doesn't exist or no board file is loaded.
>>
>>
>> No.  This is a far less radical idea.  Simpler.  We cannot be changing the global table
>> like your incorrect clarification request.
>>
>> Now, for clarification:  along side the fp-lib-table which is global, have a template or
>> default project table also in the home directory or ~/.kicad/.  This project table only
>> gets loaded when pcbnew is loaded with no project, basically only from the command line.
>>
>> $ pcbnew
>>
>> (This is how I run the software. I never use the project manager.)  When the program is
>> invoked this way, that project table from home gets loaded, and you can edit and save it,
>> and put environment variables in the lib_paths.
>>
>>
>>
>> At the moment a board is "saved as", then you have a project directory.  Since the user
>> did not load the board, but created it anew, there is no existing project table in the
>> project directory.  This is how I work, again, from the command line.  If I then edit fp
>> lib tables, and save, I would expect that template which was initially loaded from home to
>> be saved into the new project directory.  Because between starting pcbnew and editing the
>> fp lib tables, I have mated with a BOARD and CWD (i.e. a project directory).
>>
>> Thats all it is, very simple.  If I don't ever load a board or do a save as, then when I
>> do edit fp lib table (project directory still unset) the Save (OK BUTTON), puts the
>> project table back into home.
> 
> This makes sense to me.
> 
>>
>>
>> Now onto additional justification:
>>
>> Remember just last week we talked about having environment variables in the project table.
>>  You wanted to set a known variable, I said don't bother.  Both of us agreed that the
>> project table can *reference* env-variables even if we put the burden of *setting* them
>> onto the user.
>>
>> Since it has environment variables in it, e.g. ${PROJ_LIB_DIR} I could actually use the
>> same ROW for all projects.
>>
>> (name project)(uri ${PROJ_LIB_DIR}/project.pretty)(type Kicad))
>>
>> I have a project.pretty, I am free to put that where I want by setting env-var PROJ_LIB_DIR.
> 
> I'm assuming that you prefer the environment variable to be set
> internally by Pcbnew per my original suggestion.  I'll go ahead and set
> the path to the project footprint table to the cwd when a board file is
> loaded, set it to ~/ when no board is loaded, and change it to the new
> cwd on a save as.
> 
> I should be able to get these changes done over the weekend.


You da man.

Thanks.

BTW, I am not sure about the future of wxApp, as we move to main-module DLL-ization.
Don't know yet.  Might be prudent to establish an interface for "current project"
identification (or none) as a separate entity.  It could be made responsible for all the
tasks associated with a project change.  Don't know, many correct ways to do things.
Brain cycles exhausted.