Re: [Kicad-developers] libkicad_3dsg.so.2.0.0

Yes, that can certainly be an issue depending on the operating system's setup. On MSWin it's a matter of copying the plugin to the correct directory and on Linux and a few other UNIX setups it's also simple, but OSX is more complicated. In reality how many out-of-tree plugins are people likely to

Re: [Kicad-developers] PATCH: 3D resolver

The code takes paths defined in GetLocalEnvVariables(). The only question I think, as Sergey pointed out, is whether environment vars do indeed override the variables defined in KiCad or if the KiCad vars have precedence. I wrote the code so that the shell definition has precedence, but that's

Re: [Kicad-developers] [PATCH] Make EDA_ITEM::Clone() abstract

Hi, On 20.04.2016 22:15, Mark Roszko wrote: > Since we have C++11 now...why not use the override specifier? :D We still have to make it abstract though if we want to be told off when we forget to implement it. Simon signature.asc Description: OpenPGP digital signature

Re: [Kicad-developers] [PATCH] Make EDA_ITEM::Clone() abstract

Since we have C++11 now...why not use the override specifier? :D On Wed, Apr 20, 2016 at 2:28 PM, Simon Richter wrote: > Make this function abstract in the base, and provide private functions > emitting error messages in all types that are actually instantiated. > > ---

Re: [Kicad-developers] Net Ties

On Wed, Apr 20, 2016 at 10:07:33PM +0200, Marco Ciampa wrote: > I understand but this is really the most obvious rapresentation... s/rapresentation/representation/ -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE

Re: [Kicad-developers] Net Ties

IMHO... On Wed, Apr 20, 2016 at 10:00:56PM +0200, Simon Richter wrote: > Hi, [...] > There doesn't appear to be a real standard on how to represent net ties > in the schematic, though. A design note[2] from Linear Technologies uses > 45 degree angles on wires to make it look really intentional

[Kicad-developers] Net Ties

Hi, as wxWidgets is getting on my nerves with editing widgets in the pin table not rendering properly, I've started on support for net ties. In the current iteration, they would be placed the same way as junctions. Rules: - Any wire or pin connected to a net tie is in a separate net (unless

[Kicad-developers] [PATCH] Make EDA_ITEM::Clone() abstract

Make this function abstract in the base, and provide private functions emitting error messages in all types that are actually instantiated. --- 3d-viewer/3d_material.h| 3 +++ 3d-viewer/3d_struct.h | 2 ++ common/base_struct.cpp | 7

Re: [Kicad-developers] [Branch ~kicad-product-committers/kicad/product] Rev 6698: Pcbnew: remove dead macro code.

> On 20 Apr 2016, at 19:11, Wayne Stambaugh wrote: > > On 4/20/2016 3:09 AM, jp charras wrote: >> Le 19/04/2016 22:02, Andrey Fedorushkov a écrit : >>> >>> In attach is one of the files. >>> For example, a macro is very simple to make the ground skip and via between >>>

Re: [Kicad-developers] libkicad_3dsg.so.2.0.0

The problem is not where they are installed (as long as they are where KiCad looks for them), but against which dynamic (KiCad) library (and, what locations) they are linked. The guy providing his plugin might have linked against /usr/lib/… whereas the other guy installing it in his user KiCad

Re: [Kicad-developers] [Branch ~kicad-product-committers/kicad/product] Rev 6698: Pcbnew: remove dead macro code.

> If no one is going to step up to fix and/or maintain the macro code, I would > rather not restore it. There are plenty third party macro recording programs that'll do the same job better than rolling one into KiCad. (like AutoHotkey on windows) ___

Re: [Kicad-developers] [Branch ~kicad-product-committers/kicad/product] Rev 6698: Pcbnew: remove dead macro code.

On 4/20/2016 3:09 AM, jp charras wrote: > Le 19/04/2016 22:02, Andrey Fedorushkov a écrit : >> >> In attach is one of the files. >> For example, a macro is very simple to make the ground skip and via between >> the microwave lines. >> I wrote the "mini-guide" in the newsletter, how to use macros

Re: [Kicad-developers] Build of kicad_new3d-viewer failed

Hi Jakub and Mario, JP pointed out a solution for this prob It is certainly due to the fact pcbnewPYTHON_wrap.cxx is a old file, not updated (frequent issue). When you have an issue with pcbnewPYTHON_wrap.cxx, delete it and rebuild kicad. pcbnewPYTHON_wrap.cxx is not always rebuilt when a .h is

Re: [Kicad-developers] libkicad_3dsg.so.2.0.0

But in the case of binary plugins, theu would be installed to the same search location where kicad is already looking so the ldconfig should not be problem, should it? Den 20/04/2016 16.04 skrev "Bernhard Stegmaier" : > ... these dynamic linked library issues will be

Re: [Kicad-developers] libkicad_3dsg.so.2.0.0

This falls under the category of be careful what you wish for you might get it. :) I'm going to let this play out before I accept any other external plugin architectures. On 4/20/2016 10:04 AM, Bernhard Stegmaier wrote: > ... these dynamic linked library issues will be really fun when/if we >

Re: [Kicad-developers] Build of kicad_new3d-viewer failed

Hi Jakub, Thanks for trying it! It have errors related with python. I dont know about it, so it should be some general issue with build kicad with python. I am not an expert but I am building my branch with: cmake -DCMAKE_BUILD_TYPE=Release \ -DKICAD_SCRIPTING=OFF \

[Kicad-developers] Build of kicad_new3d-viewer failed

Hi Mário, Today I pulled new revision 6017 from your branch and want to build but build has failed as you can see in build log. Sorry for some Czech words in log. Jakub [ 27%] Built target bitmaps [ 27%] Built target netlist_lexer_source_files [ 27%] Generating version string header -- Using

Re: [Kicad-developers] libkicad_3dsg.so.2.0.0

... these dynamic linked library issues will be really fun when/if we start with user-plugins, especially if they are distributed as a binary and maybe not distributed by any official package maintainer of a distribution ... Regards, Bernhard On 2016-04-20 10:11, Mário Luzeiro wrote: I

Re: [Kicad-developers] PATCH: 3D resolver

Cirilo, I didn't notice but does your environment variable code check the environment variable map returned by GetLocalEnvVariables()? If not, it should check if they exist in the map before calling wxEnvVar(). This will ensure that the behavior is consistent for environment variables in the

Re: [Kicad-developers] 3D filename resolution

Cirilo sent us today a (pending) patch that may have some modifications related with this subject. Mario > > So does it show the external env var or the config one? If it shows the > > external one, that is what Mario expects. > > The internally defined environment variable is shown. I suppose

Re: [Kicad-developers] 3D filename resolution

Den 20/04/2016 14.31 skrev "Wayne Stambaugh" : > > On 4/20/2016 8:27 AM, Nick Østergaard wrote: > > > > Den 20/04/2016 14.16 skrev "Wayne Stambaugh" > >: > >> > >> Mario, > >> > >> That's not going to happen. I

Re: [Kicad-developers] 3D filename resolution

On 4/20/2016 8:27 AM, Nick Østergaard wrote: > > Den 20/04/2016 14.16 skrev "Wayne Stambaugh" >: >> >> Mario, >> >> That's not going to happen. I specifically designed the environment >> variable behavior for development purposes. That's why

Re: [Kicad-developers] 3D filename resolution

Den 20/04/2016 14.16 skrev "Wayne Stambaugh" : > > Mario, > > That's not going to happen. I specifically designed the environment > variable behavior for development purposes. That's why the environment > variables defined externally to kicad take precedence. This allows

Re: [Kicad-developers] PATCH: 3D resolver

On 20.04.2016 12:24, Cirilo Bernardo wrote: 2. ENV VARs paths defined by the shell take precedence over what is defined within KiCad; this is consistent with typical UNIX use: ENV_VAR=something pcbnew test.kicad_pcb Are you sure you understand UNIX precedence right? If you call some shell

Re: [Kicad-developers] 3D filename resolution

Mario, That's not going to happen. I specifically designed the environment variable behavior for development purposes. That's why the environment variables defined externally to kicad take precedence. This allows me to keep my test libraries separate from my normal working libraries. This

Re: [Kicad-developers] 3D filename resolution

That sounds good, at least user knows that it is used and cannot be changed (because there is a global external var) From: easyw [ea...@katamail.com] Sent: 20 April 2016 10:45 To: Mário Luzeiro; Cirilo Bernardo; KiCad Developers Subject: Re:

Re: [Kicad-developers] 3D filename resolution

Hi, in windows if the ENV var is defined by the system (i.e. SETX KISYS3DMOD "local_path"), the previous behavior was to respect the system defined var, and the kicad internal var was 'greyed' in Preferences, Path Configuration Maurice On 20/04/2016 10.04, Mário Luzeiro wrote: Hi Cirilo,

Re: [Kicad-developers] 3D filename resolution

May be the good way to mix the two is having the config windows displaying the envar if defined instead of the value in config. In that case it should be greyed out with a little information message explaining why. So user will not get confused changing something without effect, and it remains

Re: [Kicad-developers] libkicad_3dsg.so.2.0.0

On Wed, Apr 20, 2016 at 6:11 PM, Mário Luzeiro wrote: > I experienced that also but, for some reason that I dont understand how it > works, it starts to work again. > So maybe just need a reboot to make that "ldconfig update its cache". > No, a reboot isn't necessary. Others

[Kicad-developers] PATCH: 3D resolver

The attached patch does the following: 1. Ensures ${KISYS3DMOD} is in the resolver's path list even if it is not defined in KiCad's internal path list (Configure Paths). This fixes a bug which was described on the dev list but not reported to the bug tracker. 2. ENV VARs paths defined by the

Re: [Kicad-developers] libkicad_3dsg.so.2.0.0

I experienced that also but, for some reason that I dont understand how it works, it starts to work again. So maybe just need a reboot to make that "ldconfig update its cache". From: Kicad-developers

Re: [Kicad-developers] 3D filename resolution

Hi Cirilo, Thinking as a regular user perspective, I vote for "WYSIWYG", i.e: the one defined in the GUI. Users will get puzzled if something that they don't see is change the variable path. Mario From: Kicad-developers

Re: [Kicad-developers] [Branch ~kicad-product-committers/kicad/product] Rev 6698: Pcbnew: remove dead macro code.

Le 19/04/2016 22:02, Andrey Fedorushkov a écrit : > > In attach is one of the files. > For example, a macro is very simple to make the ground skip and via between > the microwave lines. > I wrote the "mini-guide" in the newsletter, how to use macros when my > colleague Roman Bashkov completed