← Back to team overview

kicad-developers team mailing list archive

Re: fp_lib_table


On 12/9/2012 4:00 PM, Dick Hollenbeck wrote:
On 12/09/2012 01:29 PM, Wayne Stambaugh wrote:
On 12/9/2012 10:41 AM, Dick Hollenbeck wrote:
On 12/08/2012 11:37 PM, Dick Hollenbeck wrote:

I got some hours in on the fp-lib-table branch today.  I added the
FP_LIB_TABLE::ROW::description field, and made the parser handle some elements in any
order, with the capability of having optional table columns, i.e. s-expression elements.
The (options) are now optional.

I've got a better idea for presenting platform independent (uri LIBPATH)s, for the case
where LIBPATH is local (local = not on the internet).

I'm thinking we should movefrom the %P path substitution to a full environment variable
capability, in the (uri LIBPATH).


(uri ${KISYSMODS}/passives.mod)

This might be embedded in a row like this:

(lib (name passives)(descr "R/C Lib")(type KiCad)(uri ${KISYSMODS}/passives.pretty))

When loading the library by nickName, i.e. (name), we'd simply do environment variable
substitution on whatever we find in (uri), no limitsas to which environment variables or
how many.   However for the system library table, the one distributed with pcbnewand
reflecting the kicad supplied libs, we'd have a special environment variable, say KISYSMODS.

The purpose of something like KISYSMODS is to achieve a platform independent (cross
platform) system library table that comes with the kicad package, since it can be used to
abstract the "system standard library location"across platforms.  Think of it as a leading
path fragment.

In said bzr branch, see:

pcbnew_config.cpp, line 97.  This code is scaffolding, to be tossed in the future, but
shows that the parser is working on these tables.
Also notice the prj table uses a custom environment variable that would never be mentioned
in kicad documentation, KIUSRMODS, since this was put in there
by someone who runs kicad on both Windows and Linux and wants not to have to futz with his
project specific fp_lib_table.

const wxString FP_LIB_TABLE::ExpandSubtitutions( const wxString aString )
      // We reserve the right to do this another way, by providing our own member
      // function.
      return wxExpandEnvVars( aString );

But what about the guy who did not set his KISYSMODS environment variable?
At program startup, we can do:

--- If KISYSMOD is not in the evironment, then push it into the environment with a value
according to old school platform specific path fragment.  On linux that would be
/usr/local/share/kicad/modules/, and similar for Windows.  This is just a safety net in
the case where KISYSMODS has not been set.

I am still struggling with the number of tables to have, 2 or 3.  And I can even make an
argument for 4in the future.

Here are my arguments, and the order of search precedence:

1) "project specific" table,which is tied to a projectonly.

2) "personal" table, which is cross project.  (This is the one I would use mostly.)

Woke up this morning with a reversal back to my original thinking, which is that 2 tables
are enough for the moment to moment search stack.

The "project specific" and the "personal" (= global) seem to be enough for me.   This
gives a better handle on policy enforcement, namely the ability to exclude libraries by
simply leaving them out of both tables.

There will be a project specific table for each project, with only one in play at any time
(since only one project is in play), and then the personal-global table is always in play.

I will try and make it easy to import another table into the current one in the UI.  This
addresses the need to stay in tune with the distributed standard libraries, if someone so
The tables should also be easy to edit with a text editor, and they should be stored in
obvious places, so this can be done.
To keep it plain text we wont be able to use the current configuration
code otherwise it will end up in the registry on Windows.

LOL registry.  Just the name of it makes it sound like someone else is in charge of my
You must REGISTER with the authority.

If you think it was brain dead before, it's gets even better on 64 bit Windows. Now you have to deal with accessing 64 vs. 32 registry if you are running 64 bit Windows and 64 or 32 bit programs. I just spent a half a day trying to figure out why I couldn't find the Java run time path from Pcbnew when I was looking right at it in the registry editor. It turns out that when accessing the registry from a 32 bit program you need to know which registry (32 or 64 bit) that you want to access. The fact that you could run either the 32 or 64 bit version of Java on 64 bit Windows just compounds the problem. I defy anybody to make a sane argument that Window's is a better (not more popular) development platform the Linux.

s-expression format makes the most sense as the code is already in place
for reading and writing the table in s-expression format.  You might
want to consider using wxStandardPaths::GetUserConfigDir() to get the
platform specific user configuration path for storing the global table file.

Good, that sounds like a user specific directory, and will deal with the case where
multiple users are using Kicad with different personal-global tables.

I got it copying to and from a spreadsheet now also, over the clipboard.  Tested OK with
gnumeric and openoffice on linux.  Block, rows, cols or cell selections all work with cut,
copy and paste.

When I get some time I'll test it out on Windows to make sure all is well there.

With Holidays coming, hard to tell when time will be available.  Taking a break for a
little while.

Enjoy the holidays. It's always a good time to spend with family and friends. I plan on laying low as well. Logan will be home Wednesday for the first time since I dropped him off at school in August. Can't wait.



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