kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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.


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.