+1 for the GUI! ;)
Miguel Ángel Ajo
On Friday, 9 de January de 2015 at 18:21, Andy Peters wrote:
>
> > On Jan 9, 2015, at 4:34 AM, Brian Sidebotham > (mailto:brian.sidebot...@gmail.com)> wrote:
> >
> > On 8 January 2015 at 13:44, Wayne Stambaugh > (mailto:stambau...@gmail.com)> wrote:
> >
> On Jan 9, 2015, at 4:34 AM, Brian Sidebotham
> wrote:
>
> On 8 January 2015 at 13:44, Wayne Stambaugh wrote:
>> Fully defined paths can be used in the fp-lib-table if that is your
>> preference. Environment variable substitution is optional. You are
>> free to use any environment variable
On 1/9/2015 6:34 AM, Brian Sidebotham wrote:
> On 8 January 2015 at 13:44, Wayne Stambaugh wrote:
>> Fully defined paths can be used in the fp-lib-table if that is your
>> preference. Environment variable substitution is optional. You are
>> free to use any environment variable you want. KISYSM
On 8 January 2015 at 13:44, Wayne Stambaugh wrote:
> Fully defined paths can be used in the fp-lib-table if that is your
> preference. Environment variable substitution is optional. You are
> free to use any environment variable you want. KISYSMOD is merely the
> variable name used for the defa
In response to a message written on 08.01.2015, 18:02, from Adam Wolf:
Hi Wayne,
I think I have been sending from the wrong email address or not replying all,
but I did not intend for any of my messages to be off list. Just clearing up
for the rest of everyone.
To this mailing list maintainers
On 1/8/2015 11:21 AM, Bernhard Stegmaier wrote:
> Hi all,
>
> you are right... if its not mandatory to use KISYSMOD, but someone can
> use any other variable (like Wayne does), then I wouldn't care about a
> "hard" set value (just take my own one if pre-defined doesn't fit). And
> one reasonable f
Hi Wayne,
I think I have been sending from the wrong email address or not replying
all, but I did not intend for any of my messages to be off list. Just
clearing up for the rest of everyone.
If you aim on having this done before the next stable release, I am
comfortable with where we are. Night
On 1/8/2015 11:23 AM, Adam Wolf wrote:
> Wonderful!
>
> Any sort of ETA on this work? Is it something I can help out on, or is
> it really nitty gritty and needs someone who is really familiar with the
> internals?
Your going to have to be pretty comfortable with the internals to write
this code
Hi all,
you are right... if its not mandatory to use KISYSMOD, but someone can
use any other variable (like Wayne does), then I wouldn't care about a
"hard" set value (just take my own one if pre-defined doesn't fit). And
one reasonable fixed path probably would fit 95% percent of users...
I
On 1/8/2015 10:40 AM, Adam Wolf wrote:
> Hi Wayne,
>
> Thank you for wearing all those hats! It makes you a pleasure to work with.
Your welcome. That's what makes working on KiCad challenging. I am a
user, developer, and packager trying to satisfy all of those
requirements on three separate pl
On 1/8/2015 9:43 AM, Adam Wolf wrote:
> Hi Wayne,
>
> When dealing with Kicad's internals, I often have the perspective of a
> packager, and sometimes that makes me have weird ideas.
As a developer, packager, and user I have the same issues. What is good
for development purposes is not always th
Den 08/01/2015 15.45 skrev "Adam Wolf" :
>
> Hi Wayne,
>
> When dealing with Kicad's internals, I often have the perspective of a
packager, and sometimes that makes me have weird ideas.
>
> I remember the search path discussions and the issues where it was
impossible to tell which footprint got pic
Hi Wayne,
When dealing with Kicad's internals, I often have the perspective of a
packager, and sometimes that makes me have weird ideas.
I remember the search path discussions and the issues where it was
impossible to tell which footprint got picked. I don't want to bring that
back.
Right now,
Fully defined paths can be used in the fp-lib-table if that is your
preference. Environment variable substitution is optional. You are
free to use any environment variable you want. KISYSMOD is merely the
variable name used for the default footprint library path. I use
KILCLMOD to point to the
On 1/8/2015 7:53 AM, Adam Wolf wrote:
> I hear what you're saying.
>
> I don't really like the idea of using environment variables to drive the
> behavior of GUI programs, especially in OS X. They're tricky in OS X,
> and they're hard to explain to a lot of users.
Environment variables are not i
Maybe. For KISYSMOD, I am not sure if it is used anywhere in the source.
I do not think your work around would work for KISYS3DMOD, though.
On Jan 8, 2015 7:29 AM, "Miguel Ángel Ajo" wrote:
> Can’t users just change that reference to their own path on their own
> fp-lib-table
> instead of the E
Can’t users just change that reference to their own path on their own
fp-lib-table
instead of the ENV var reference if they don’t want the system modules?
That would be reasonable enough to me.
Miguel Ángel Ajo
On Thursday, 8 de January de 2015 at 13:53, Adam Wolf wrote:
> I hear what you
I hear what you're saying.
I don't really like the idea of using environment variables to drive the
behavior of GUI programs, especially in OS X. They're tricky in OS X, and
they're hard to explain to a lot of users.
Fixing this through changing the behavior of how KISYSMOD and probably the
othe
Hi Adam, hi all,
that IMHO could be problematic (depends on what you intend to have).
For a single-user environment this might be OK, but it then forces
modules to be in a machine specific folder common to all users. In a
multi-user environment you probably might not want to have that. And,
Hi folks,
As you may know, it's harder than it seems to set an environment variable
on a bundle in OS X as a user.
I have a patch here for the OS X bundle that sets KISYSMOD to
/Library/Application Support/kicad/modules
Please let me know if there are any questions or comments.
Thanks!
Adam Wo
20 matches
Mail list logo
