kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 9/24/2013 6:17 PM, Dick Hollenbeck wrote:
> 
> On Sep 24, 2013 5:14 PM, "Wayne Stambaugh" <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.

> 
> 
>>
>> Wayne
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>