Le 21/10/2015 03:09, Henner Zeller a écrit :
> On 20 October 2015 at 13:49, Henner Zeller wrote:
>> On 20 October 2015 at 13:17, Nick Østergaard wrote:
>>> I think the proposed naming makes sense. I don't think we need to mark
>>> it as deprecated, we could just remove it. I have not heard of a l
I can't see any way of scripting a version check in Kicad, Pcbnew, or
Eeschema,
Most application print version, given -v or -version then exit.
This allows script's to version check, is there some other way for a shell
script to check
what version of Kicad it has ?, if not, would there be any
I just tested on 6264 on linux. When I draw them it starts at the
center and then the next time I click I get the radius and it will
always be a 90 degree arc (no third click). That is not how it has
always been, IIRC. I think this is a regression or some weird option
that I have set.
2015-10-21 7
Hi Bernhard,
Have a look at the video [1]. The first part is the legacy canvas (90
degrees arcs), the second is recorded with the GAL canvas enabled.
Regards,
Orson
1. https://orson.net.pl/pub/out.ogv
On 10/21/2015 04:50 PM, Bernhard Stegmaier wrote:
> Hi Orson,
>
> can you explain how it shou
Hi Orson,
can you explain how it should work in default canvas?
OK, I can get some arc to show up, but this is at least very different from how
to do it in eeschema (and I thought it should be the same in eeschema and
default canvas?):
In eeschema I can create a half-circle with 3 clicks.
I did
Hi Bernhard,
This is how it works in the legacy canvas, nothing wrong with OSX. We
have simply done it in a different way in the GAL canvas.
Regards,
Orson
On 10/21/2015 04:09 PM, Bernhard Stegmaier wrote:
> Hi,
>
> nice discussion, but could anybody please just try if drawing arcs on
> Window
Hi,
nice discussion, but could anybody please just try if drawing arcs on
Windows/Linux is working as expected (if yes, how?)?
Thanks,
Bernhard
> On 20 Oct 2015, at 07:39, Bernhard Stegmaier wrote:
>
> Hi,
>
> I already mentioned it in the OS X graphics performance thread…
> Is drawing arcs
On 20 October 2015 at 13:49, Henner Zeller wrote:
> On 20 October 2015 at 13:17, Nick Østergaard wrote:
>> I think the proposed naming makes sense. I don't think we need to mark
>> it as deprecated, we could just remove it. I have not heard of a lot
>> of users that have discovered the python API
On 20 October 2015 at 13:17, Nick Østergaard wrote:
> I think the proposed naming makes sense. I don't think we need to mark
> it as deprecated, we could just remove it. I have not heard of a lot
> of users that have discovered the python API, so I think the impact of
> removing it when we have no
I agree with Stephano, we should have two tools for arcs, as sometime starting
with the center is preferred, but more often start/end then center is better
suited.
My $0.02,
Jean-Paul
AC9GH
> On Oct 20, 2015, at 4:03 PM, Nick Østergaard wrote:
>
> What do you mean by two different tools?
>
I think the proposed naming makes sense. I don't think we need to mark
it as deprecated, we could just remove it. I have not heard of a lot
of users that have discovered the python API, so I think the impact of
removing it when we have not yet made the stable release yet is very
limited. But if you
What do you mean by two different tools?
2015-10-20 18:50 GMT+02:00 Stefano Rossi :
> Why not have it as two different tools? I think altium has it like that.
>
> On Oct 20, 2015 02:36, "tiger12506" wrote:
>>
>> I shouldn't really be hijacking your thread -- but I hate the
>> center->start->end o
On 20 October 2015 at 11:34, jp charras wrote:
> Le 20/10/2015 06:45, Henner Zeller a écrit :
>> Hi,
>> When setting the SetUseGerberExtensions() in python, the choice was
>> not honored. This is fixing it.
>>
>> Suggested commit message:
>> Fix Plotcontroller to make SetUseGerberExtensions() work
Le 20/10/2015 06:45, Henner Zeller a écrit :
> Hi,
> When setting the SetUseGerberExtensions() in python, the choice was
> not honored. This is fixing it.
>
> Suggested commit message:
> Fix Plotcontroller to make SetUseGerberExtensions() work as expected.
>
> Find patch here:
> https://github.co
This patch has been around in many forms for a while. We use it in our
custom 1.54 version of Boost:
http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/patches/boost_mingw.patch
The msys2 project had a version that worked with both 32 and 64 bit
builds with boost 1.56
Why not have it as two different tools? I think altium has it like that.
On Oct 20, 2015 02:36, "tiger12506" wrote:
> I shouldn't really be hijacking your thread -- but I hate the
> center->start->end ordering for drawing arcs.
> I think it should always be start->end->(center). It's really hard
Horrible news! In June, they decided to add "mingw" support to
boost::context. Wait what
does that even mean if we were compiling with it before hand? Hah who
knows, its boost.
boost::context commit:
https://github.com/boostorg/context/commit/fcb2283c76b93dc4e8cc14f7c358cb9ccfeb82e3
*cough* proba
Thanks for the info. I confirmed JP's testing and it looks like this
may only be a 64-bit mingw build issue.
On 10/19/2015 7:56 PM, Joseph Chen wrote:
> For Linux, Boost 1.59 seems working fine, at least for me for over a
> month now. I've been using Boost 1.59 compiled from the source on my
> U
Le 19/10/2015 21:54, Wayne Stambaugh a écrit :
> On 10/19/2015 11:59 AM, Mark Roszko wrote:
>> It was fixed 2 months ago in the uuid library upstream.
>> https://github.com/boostorg/uuid/pull/6
>>
>>
>> avhttp cannot fix it.
>>
>
> Thanks for the heads up. Unfortunately, this is not the end of th
19 matches
Mail list logo
