kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 07/19/2012 09:42 AM, Dick Hollenbeck wrote:
> On 07/19/2012 05:38 AM, Edwin van den Oetelaar wrote:
>> http://en.wikipedia.org/wiki/Program_Files
>>
>> Remember that 'Program Files' only is a default location for English installs...
>> Would it make sense for a multi-user machine to have stuff installed in a personal
>> directory instead of a system directory?
>> I have seen systems that would check : ~/.application/ver123/plugins/script1.py and if
>> stuff can not be found there go to other places so users can install specific things
>> without impacting the other users.
> At least one person will have to develop scripts.  That person would prefer "write access"
> to the directory where the scripts live and evolve.
>
>
> A more general observation:
>
> A good [commercial] software application would categorize its various files into a number
> of categorical groups, and then give a mapping table to tell where that category of files
> actually reside.
>
> This would allow some categories of files to be in a read only directory, and some in a
> read/write directory, and each category of files to be relocatable based on the mapping table.
>
> Then you have to find the mapping table without scratching your head too much.
>
>
> Simply saying that we should support installing in /home/<user> falls far short of the
> general solution I mention above.  Our company has implemented the above strategy for our
> commercial software applications, and it is pretty simple since there is already
> infrastructure to read configuration files and lookup name/value pairs from the config files.
>
> Here the "name" is the file category, such as "footprint_libraries" 


Let's give this scheme a name, say we call it a "directory table".


Now, oops, "footprint_libraries" was a bad example of a category within the directory
table, and I explain why below.  Let's carve out footprint libraries and treat them
specially and separately from the directory table discussion.


I believe Wayne is currently implementing a footprint library table, which gives you finer
granularity than "all libraries in one directory or place".  The library table gives more
specificity than the currently implemented library search path scheme we have in place
now.  A library table is similar in concept to the directory table, but the library table
can include the "technology type (plugin type)" used as well.  This lets you
simultaneously use footprint libraries from not only different technologies, but also from
entirely different directories.  Granularity is per footprint library.

The directory table still has merit in other categories where such fine granularity is not
needed.


Dick