On 16.06.2015 14:16, Wayne Stambaugh wrote:
> On 6/15/2015 9:20 PM, Cirilo Bernardo wrote:
>> On Tue, Jun 16, 2015 at 8:33 AM, Tomasz Wlostowski
>> mailto:tomasz.wlostow...@cern.ch>> wrote:
>>
>> On 14.06.2015 13:35, jp charras wrote:
>> > Le 1
On 16.06.2015 17:35, Mário Luzeiro wrote:
>
>
> From: Kicad-developers
> [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of
> Tomasz Wlostowski [tomasz.wlostow...@cern.ch]
> Sent: 16 June 2015 17:13
> To: W
On 16.06.2015 03:20, Cirilo Bernardo wrote:
>
> Tom, have you got a small example of an assembly created by OCC?
> I would like to see how SolidWorks imports the file and if the results
> will be acceptable.
Hi Cirilo.
In the attachment. I don't have solidworks but Inventor and a IDA-STEP
(free
On 31/01/2019 15:40, John Beard wrote:
> Hi,
>
> Two patches for building these libs:
>
> 1) Make bitmaps a "Proper" library. By splitting it off like this, the
> includes for each of the hundreds of XPM cpp files do not need to suck
> in WX headers. This speeds compilation by something like 10x
Hi,
The 3 attached patches add pixel alignment while drawing strokes in GAL
(both Cairo and OpenGL), resulting in sharp and uniform width lines
regardless of the zoom level and antialiasing settings. Current GAL
canvas does not round geometry to integer pixel coordinates, resulting
in sometimes bl
On 11/02/2019 02:12, Jeff Young wrote:
> This hugely improves Fallback on Mac. Still doesn’t look as good as OpenGL
> (or Legacy), but it’s at least usable.
>
> OpenGL 2x Oversampling appears the same, but OpenGL with no antialiasing has
> caught up a lot. It’s now almost as good as 2X OS — in
On 11/02/2019 05:31, Seth Hillbrand wrote:
> 1) The blue stroke/green circle on the bitmaps is a bit unclear of
> purpose (fallback mode). It is drawn behind the bitmap, so you only see
> it with a masked/alpha bitmap but I think we should not draw it. The
> green circle is cleared after placing
On 11/02/2019 02:12, Jeff Young wrote:
> This hugely improves Fallback on Mac. Still doesn’t look as good as OpenGL
> (or Legacy), but it’s at least usable.
Hi Jeff,
I don't see any difference between the look of Fallback mode on your
screenshots vs my machine. Are you referring to the text ren
On 11/02/2019 22:26, Jeff Young wrote:
> Holes seem different (although perhaps it just a different scrolling
> offset), but not fixed:
>
>
Hi Jeff (and others ;-),
I'm working on circle alignment for OpenGL, it also requires some shader
work so it's not that trivial. I'll try to merge all this
On 11/02/2019 18:18, Jeff Young wrote:
> I think text looks best with no anti-aliasing. Is it possible to turn
> it off just for text? (Or is this a Mac-specific result?)
Hi Jeff,
Check my previous e-mail, maybe it's Mac-specific. Unfortunately due to
global (supersampling) nature of GL/Cairo a
y
>>> see that the emitter arrow on the top transistor appears hollow and
>>> the tip isn’t aligned to the wire. Bottom one looks better, but is
>>> still somewhat un-aligned:
>>>
>>>
>>>
>>>
>>>> On 11 Feb 2019, at 17:06, Je
o be 1/2 native resolution).
>
>
>
>> On 11 Feb 2019, at 22:00, Tomasz Wlostowski > <mailto:tomasz.wlostow...@cern.ch>> wrote:
>>
>> On 11/02/2019 18:43, Jeff Young wrote:
>>> I hadn’t played around with PCBNew yet… and sadly it looks uniformly
>
Hi all,
I made some fixes to the GAL pixel alignment code. Now it looks much
better on Retina displays (please set the DPI scaling to 100% in display
settings, otherwise the image will be blurry - OSX applies DPI scale to
GL canvases (!) and I don't know any workaround for this). It also fixes
som
On 16/02/2019 14:21, Wayne Stambaugh wrote:
> I tested this on windows and linux and it looks really good. I think we
> have tested it on all platforms. What is left to get it ready to merge?
Hi Wayne,
I cleaned up & formatted the code, rebased on the last master and pushed
it. Hope people wit
Screenshot would be helpful. I don't have any low power pentodes in my library
:)
17.02.2019 22:04 Vesa Solonen napisał(a):
Tomasz Wlostowski kirjoitti 15.2.2019 klo 20.48:
> Please test and report bugs here,
Polylines and arcs seem problematic. Testing with EM84 symbol is very
r
On 17/02/2019 23:04, Wayne Stambaugh wrote:
> Looks fine on Linux.
>
> On 2/17/19 4:50 PM, Jeff Young wrote:
>> The 3D viewer on my machine is only using the lower-left quadrant.
>> Anyone else seeing this?
I noticed it a retina macbook too. Maybe a Retina-specific issue?
Tom
>>
>>
>> ___
On 16/02/2019 17:08, Seth Hillbrand wrote:
> Did this get lost? Is anyone opposed to merging support for extra
> processors?
Hi,
I'm not opposed to merge this, code is code. However, does this
MIPS/whatever platform at least support OpenGL 2.1?
Tom
_
On 17/02/2019 20:47, Wayne Stambaugh wrote:
> Yes but I haven't heard back from Tom. Since this is primarily his
> code, I would like his input before I merge the PPC64 patch.
As I said in a similar thread about MIPS support, I'm not opposed to
merge this, I'm just wondering if this PPC64 platfor
On 18/02/2019 10:54, Gianluca Renzi wrote:
> With OpenGL it says "Cannot link shaders" or something similar, but I
> suppose it is a limit of my OpenGL video card support.
It looks like OpenGL doesn't really work on your machine. I guess it's
the open source driver "limitations" because ATI/AMD ne
On 18/02/2019 11:14, Gianluca Renzi wrote:
> I am using readon driver. The opensource one.
It supports only a part of OpenGL standard if it fails to compile a
simple shader (and the Cairo canvas works fast only for very small PCB
designs and the 3D viewer doesn't use shaders). IIRC only Intel prov
On 17/02/2019 22:24, Vesa Solonen wrote:
> Please find attached, both with max anti-alias settings. The one is from
> stock library and is a magic eye tube... The Philips pocketbook [1] for
> evening read ;^)
>
> Version: 5.1.0-rc1-unknown-f1a6083~86~ubuntu18.04.1, release build
>
Fixed.
Tom
_
On 21/02/2019 21:21, Wayne Stambaugh wrote:
> Since we are nearing the 5.1.0 release, I want to get an idea of what
> major merges are ready to go once 5.1 is branched. I know Jon's netlist
> code is ready to merge and I'm pretty sure that should be the first big
> merge. Does anyone else have an
On 26/02/2019 21:52, Nick Østergaard wrote:
> From https://www.raptorcs.com/TALOSII/prerelease.php
I tried to open this page:
https://www.raptorcs.com/content/base/software.html
Strangely, it's empty (is it my browser? :D). Does their slogan "For all
your EDA requirements" mean only an unsupport
+ sim->m_reporter->Report( msg );
}
return 0;
--
2.17.1
>From 7471bb0643bdc11cada4942280a75ef22684 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomasz=20W=C5=82ostowski?=
Date: Wed, 6 Mar 2019 17:28:27 +0100
Subject: [PATCH 7/9] LIB_TREE_ITEM: if derived classes
s, etc.
In the case of Windows builds, I would just release a binary archive of
all dependencies (with instructions how to rebuild it from scratch for
the brave/curious). It's a tedious process, especially if Python comes
into play, so I'd rather spare this to "ordinary" p
On 06/03/2019 18:47, Simon Richter wrote:
> Hi Tom,
>
> On 06.03.19 18:17, Tomasz Wlostowski wrote:
>
>> This patchset enables building KiCad in MS Visual Studio (version 2017,
>> not tested on earlier versions).
>
> Awesome!
>
> Patch 5/9 "msvc: enabl
hat integrates with
> CMake standalone and VS2017/VSCode/VS2019.
> The downside is the libraries get built on each user's machine for a
> given arch you specify but not that bad.
>
>
>
> On Wed, Mar 6, 2019 at 12:17 PM Tomasz Wlostowski
> mailto:tomasz
On 06/03/2019 20:30, Simon Richter wrote:
> At the moment, MSVC builds lack Python support, so that's a no go, also
> we'd have to redo the entire packaging as that is msys2 based as well.
>
> Python support on MSVC is non-trivial, because there is no such thing as
> a default system python.
How
On 06/03/2019 20:44, Simon Richter wrote:
> Hi Tom,
>
> On 06.03.19 18:17, Tomasz Wlostowski wrote:
>
>> - prebuilt environment [1], containing the right versions of libraries
>> and tools (CMake & CMake modules). The supplied libraries currently
>> support only
On 06/03/2019 20:28, Wayne Stambaugh wrote:
> Seth,
>
> On 3/6/2019 2:16 PM, Seth Hillbrand wrote:
>> Am 2019-03-06 12:17, schrieb Tomasz Wlostowski:
>>> Hi,
>>>
>>> This patchset enables building KiCad in MS Visual Studio (version 2017,
>>> n
On 08/03/2019 21:41, Wayne Stambaugh wrote:
> Tom,
>
> On 2/22/2019 10:17 AM, Tomasz Wlostowski wrote:
>> On 21/02/2019 21:21, Wayne Stambaugh wrote:
>>> Since we are nearing the 5.1.0 release, I want to get an idea of what
>>> major merges are ready to go on
On 09/03/2019 19:03, Wayne Stambaugh wrote:
> Rather than try to figure out every possible merge combination, I'm
> going to prioritize things serially per editor. The highest priority
> are changes those that will or potentially impact later features.
>
Hi Wayne,
If I may add my 5 cents - let'
On 11/03/2019 13:57, Wayne Stambaugh wrote:
> Hi Tom,
>
> On 3/9/2019 7:59 PM, Tomasz Wlostowski wrote:
>> On 09/03/2019 19:03, Wayne Stambaugh wrote:
>>> Rather than try to figure out every possible merge combination, I'm
>>> going to prioritize things seri
On 11/03/2019 14:41, Wayne Stambaugh wrote:
> On 3/11/2019 9:17 AM, Tomasz Wlostowski wrote:
>> On 11/03/2019 13:57, Wayne Stambaugh wrote:
>>> Hi Tom,
>>>
>>> On 3/9/2019 7:59 PM, Tomasz Wlostowski wrote:
>>>> On 09/03/2019 19:03, Wayne Stambaugh
Hi all,
In the thread [1] on the forum, someone is having hard time trying to
edit a schematic with off-grid wires. Does anyone here remember if older
versions of Kicad used the mouse or cursor position for grabbing
objects? Is there a chance there's a regression in V5/V5.1? If so, I'm
willing to
On 22/03/2019 13:43, Wayne Stambaugh wrote:
> Tom,
>
> AFAIR, the cursor position was always used in order to keep everything
> on grid. Since there has never been connection snapping in Eeschema,
> the grid is the only way to ensure connections.
Hi Wayne,
I want to use mouse position only to g
On 03/04/2019 17:42, Wayne Stambaugh wrote:
> I would be reluctant to get behind this just because of the possibility
> of epic string breakage on lot's of levels. If there was some way to
> piece meal this transition, it might be more palatable but that may
> prove to be very difficult.
>
> The
On 02/04/2019 17:27, Wayne Stambaugh wrote:
> We should always be using wxLogTrace. Using printf and cout are
> meaningless on windows and wxLogDebug means that your debugging output
> is always spewed on debug builds even when it's not needed. I haven't
> made the draconian move of making this p
Hi,
We needed to do some signal/power integrity simulations on one of our
Kicad designs and in order to do that, we needed to convert a Kicad PCB
to Hyperlynx format. Luckily, the format is simple, all text and well
documented in [1], so here comes a patch that adds a Hyperlynx exporter.
Notes:
-
On 05/04/2019 02:16, Tomasz Wlostowski wrote:
> Hi,
>
> We needed to do some signal/power integrity simulations on one of our
> Kicad designs and in order to do that, we needed to convert a Kicad PCB
> to Hyperlynx format. Luckily, the format is simple, all text and well
> doc
On 05/04/2019 16:48, John Beard wrote:
> Hi Tom,
>
> Can the hyperlink export test not exist in the existing qa_pcbnew
> test? The code is all in pcbnew's library, so why not just mirror the
> source layout and put your test as
> "qa/pcbnew/exporters/test_export_hyperlynx.cpp"?
>
> Otherwise we w
On 05/04/2019 18:04, Wayne Stambaugh wrote:
> Tom,
>
> On 4/4/19 8:16 PM, Tomasz Wlostowski wrote:
>> Hi,
>>
>> We needed to do some signal/power integrity simulations on one of our
>> Kicad designs and in order to do that, we needed to convert a Kicad PCB
>
On 05/04/2019 12:09, Jeff Young wrote:
> I’ve got a changelist which cleans up the various SCH_ and LIB_ Draw()
> routines to remove the interactivity features (since they’re now print-only).
>
Hi all,
Since we're discussing merging again, may I push my Crash Reporter patch
(touches mostly kifa
On 08/04/2019 13:58, Nick Østergaard wrote:
> Hi Tomasz
>
> I was wondering about this yesterday. Has it even been merged on master?
>
> I think I would prefer not to merge it on stable
Hi Nick,
I don't plan to merge it to any stable release anytime soon. I meant the
nightlies...
Cheers,
Tom
On 09/04/2019 18:43, Kerusey Karyu wrote:
> Guys
>
>> #: pcbnew/exporters/export_hyperlynx.cpp:190
>>
>> m_reporter->Report(
>> _( "File contains pad shapes that are not supported by the"
>> "Hyperlynx exporter (oval, rectangle, circle). They have been"
>> "exported as oval pads." ),
>
On 12/04/2019 12:17, Jeff Young wrote:
> Hi Tom,
>
> I was going to start laying some of the ground-work for Eeschema’s modern
> toolset. Do you already have some of this in a branch that you can share, or
> should I go ahead and start with master?
Hi Jeff,
I've started working on something t
On 13/04/2019 22:57, Adam Wolf wrote:
> Oh, that's what I get for trying to post from my phone...
>
> I forgot the link, and without it, my post seems super ominous! Sorry
> about that!
>
> https://developer.apple.com/news/?id=04102019a
So does this mean we can't distribute our software anymore
On 16/04/2019 22:52, Seth Hillbrand wrote:
> Am 2019-04-14 18:50, schrieb Tomasz Wlostowski:
>> Dear all,
>>
>> The attached patchset introduces a builtin crash reporter for Kicad -
>> that is a window that pops up in case of a segmentation fault/other
>> seriou
On 16/04/2019 23:25, Mark Roszko wrote:
> Just to throw it out there
>
> Did you consider at all at using something off the shelf such as
> Breakpad which both Mozilla and Chrome use?
> https://wiki.mozilla.org/Breakpad
> https://github.com/google/breakpad
Hi Mark,
I took some inspiration from
On 17/04/2019 22:51, Jeff Young wrote:
> Drawing tools (and zoom-to-selection) moved to modern toolset.
>
Hi Jeff,
How can I try them out?
Tom
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
On 18/04/2019 17:20, Jeff Young wrote:
> Hi Tom,
>
> They’re in master.
OK, but do I need to activate the modern toolset somehow? It seems that
by default eeschema uses the old one?
Tom
___
Mailing list: https://launchpad.net/~kicad-developers
Post to
On 18/04/2019 17:51, Jeff Young wrote:
> Nope. For those that I’ve moved, the old ones are gone.
>
> Note that I haven’t implemented a modern selection model yet, so the user
> model is still “legacy”. I’ve just replaced all the drawing code with new
> code using INTERACTIVE_TOOLs and going th
On 21/04/2019 18:08, Jeff Young wrote:
> In my last few years at Adobe I worked with Day Software in Switzerland which
> we had just acquired. They did a lot of open-source stuff with Apache and
> had this neat decision-making scheme (which may have originated at Apache —
> I’m unaware of its s
On 26/04/2019 13:12, jp charras wrote:
> Le 26/04/2019 à 19:21, Jeff Young a écrit :
>> I’ve been talking to Wayne about the ‘W’ and ‘X’ hotkeys. It appears the
>> design goal is to have these be immediate actions (that is, they start a
>> wire or a track, rather than just selecting the wire or
On 02/05/2019 15:51, Jeff Young wrote:
> The eeschema modern toolset is “finished”.
>
> It can be found at origin/eemodern. A bit of testing before merging might be
> in order….
>
Jeff,
Wow, I'm speechless. You did it lightning fast. I'll try to compile it
in the evening and give you some fee
On 02/05/2019 07:06, Wayne Stambaugh wrote:
> Hey Tom,
>
> I finally got around to testing this. I could not get it to build on
> windows or linux. I'm getting the following compiler error on both 32
> and 64 bit windows and linux builds:
>
> E:/msys64/home/Wayne/src/kicad-lp-clone/common/debug
On 02/05/2019 15:51, Jeff Young wrote:
> The eeschema modern toolset is “finished”.
>
> It can be found at origin/eemodern. A bit of testing before merging might be
> in order….
Hi Jeff,
I noticed eemodern it's missing mouse drag action (i.e. dragging a
selected wire/component/etc. just starts
++
05.05.2019 11:40 Seth Hillbrand napisał(a):
+1
Am 2019-05-05 13:33, schrieb Jon Evans:
> +1
> Merge it and get more testing. It's already worlds better than the
> status quo.
>
> On Sun, May 5, 2019 at 12:12 PM Jeff Young wrote:
>
>> I think this is ready to merge. Any objections?
>>
>> __
On 06/05/2019 09:48, Jeff Young wrote:
> 1) I hate the coroutines. They truncate backtraces in the debugger.
Hi Jeff,
I'm thinking how to improve this. Perhaps we can 'fix' a fake stack
frame that will allow the debugger to unwind the stack past the
coroutine entry point...
Tom
___
On 06/05/2019 09:48, Jeff Young wrote:
> 1) I hate the coroutines. They truncate backtraces in the debugger.
Hi,
How about using ucontext.h on Unices (Linux/OSX) and WinFiber API on
Windows? I have working implementation of the latter already in the MSVC
branch. Are there any reasons to not use
On 07/05/2019 07:47, Wayne Stambaugh wrote:
>
> On 5/6/2019 9:02 PM, Tomasz Wlostowski wrote:
>> On 06/05/2019 09:48, Jeff Young wrote:
>>> 1) I hate the coroutines. They truncate backtraces in the debugger.
>>
>> Hi,
>>
>> How about using ucontex
On 10/05/2019 11:46, John Beard wrote:
> Do the tool actions actually even need to know their hotkey? I think
> perhaps they shouldn't really care *what* the hotkey is or even if one
> is set, it's not their problem. It's the tool framework that should be
> maintaining this mapping.
Hi,
+1 here.
Hi,
I've been recently playing with Victor's huge 32-layer PCB design and
trying to improve the performance of pcbnew for larger designs. This
board causes even pretty decent PCs to crash/render glitches due to
pcbnew's enormous VBO (Vertex Buffer) memory consumption.
It turns out it's caused by
Hi,
I've been away for the weekend, here's the reply for all the
questions/comments:
> As far as I am aware, all commercial tools in the space have more
advanced / modern system requirements than KiCad
> The integrated Intel GPUs that are old enough to not have OpenGL 3.0
are no longer supported
On 13/05/2019 17:46, Wayne Stambaugh wrote:
> I guess I should weigh in on this issue. I would prefer we exhaust all
> other options before bumping opengl to some later version.
Hi Wayne,
I think JP's solution is the way to go, it fixes the original issue
instead of working it around. What's you
On 16/05/2019 20:44, Jon Evans wrote:
> I can think of at least two alternatives:
>
> 1) automatic performance tuning based on self-benchmarking
>
> 2) a "graphics performance" setting (high/medium/low) that changes
> multiple things under the hood.
Hi Jon,
I'm afraid this would be difficult to
On 13/05/2019 12:58, jp charras wrote:
> If we are talking about V6.0 version, we should add zone property field
> in the file format like (outline_thickness 0.0) to avoid serious issues
> (generating broken boards for fabrication).
>
Hi JP,
Are you going to work on this (commit code)?
> Perhap
On 27/05/2019 16:46, Jeff Young wrote:
> Hi Seth,
>
> The Eeschema has one advantage that if you mess it up you get too many undo
> steps rather than too few. But it is somewhat crankier code to get right.
>
> I agree that we should have only one scheme. I don’t believe anyone’s
> working on
On 27/05/2019 17:39, Seth Hillbrand wrote:
> On 2019-05-02 17:41, Tomasz Wlostowski wrote:
>> On 02/05/2019 07:06, Wayne Stambaugh wrote:
>>>
>>> By chance did you build with OCC instead of OCE which is what I am
>>> using? Please fix this when you ge
On 27/05/2019 17:39, Seth Hillbrand wrote:
> On 2019-05-02 17:41, Tomasz Wlostowski wrote:
>> On 02/05/2019 07:06, Wayne Stambaugh wrote:
>>>
>>> By chance did you build with OCC instead of OCE which is what I am
>>> using? Please fix this when you ge
On 29/05/2019 06:07, Seth Hillbrand wrote:
> On 2019-05-28 12:13, Tomasz Wlostowski wrote:
>>
>> Done (tom-crash-reporter-may27 on my Github)!
>>
>> Tom
>
> Hi Tom-
>
> This looks very nice. I like the implementation a lot!
>
> Here are a couple mi
On 29/05/2019 16:33, jp charras wrote:
> Attached a patch that modify the way filled areas (solid polygons) are
> built in copper areas.
>
> Currently, solid polygons are slightly smaller than the exact area, and
> the polygon outlines have a thickness to fill the exact area.
> With this patch, po
On 30/05/2019 00:35, Wayne Stambaugh wrote:
> A `git pull` from https://github.com/twlostow/kicad-dev.git says I'm up
> to date.
>
> A note to the lead dev team, please do not push your personal
> development branches to the main kicad repo. Thanks.
>
It looks I'm the bad boy ;-) Just removed th
On 30/05/2019 16:46, Wayne Stambaugh wrote:
> Hey Tom,
>
> On 5/29/2019 7:59 PM, Tomasz Wlostowski wrote:
>> On 30/05/2019 00:35, Wayne Stambaugh wrote:
>>> A `git pull` from https://github.com/twlostow/kicad-dev.git says I'm up
>>> to date.
>>>
>
On 30/05/2019 21:12, Wayne Stambaugh wrote:
> Nothing was displayed. I was running from the project manager. I even
> crashed the project manager. I'm using msys2 to create mingw32 and
> mingw64 debug builds of KiCad. I'm using wxWidgets 3.0.4 (not a debug
> build). I did not check to see if t
On 03/06/2019 14:42, Wayne Stambaugh wrote:
> On 5/31/19 4:23 PM, Tomasz Wlostowski wrote:
>> On 30/05/2019 21:12, Wayne Stambaugh wrote:
>>> Nothing was displayed. I was running from the project manager. I even
>>> crashed the project manager. I'm using msys2 t
On 04/06/2019 17:11, Tomasz Wlostowski wrote:
> Hi Wayne,
>
> It looks like I screwed up the exception handler under KiCad windows
> shell. Will fix soon.
Fixed in my github branch.
T.
___
Mailing list: https://launchpad.net/~kicad-dev
On 05/06/2019 20:33, jp charras wrote:
> Could you test this version on your very large board, and said me if it
> fixes the very long time calculation to redraw the board on OpenGL.
> Thanks.
Sure, will do. Sorry that I didn't follow the whole discussion, where
can I find the latest code?
Tom
_
On 05/06/2019 21:21, jp charras wrote:
> It is on the master branch (just committed).
Hi JP,
I gave it a try with a bunch of designs. Here are my observations:
- The filled zones look correct on the super-complex board and the
number of unconnected nets is identical to the old algorithm.
- There
On 09/06/2019 20:51, jp charras wrote:
> First, thanks Tom for your test.
>
> But are the drawing issues (calculation time and memory overflow) fixed
> by this change?
> They were the main reason of this change.
Yes, the VBO out-of-memory issue is gone now. I haven't measured yet how
much memory
On 11/06/2019 22:29, Nick Østergaard wrote:
> Too bad the gcc windows
> build crash report doesn't have a stack trace. Maybe MSVC builds would
> have more debug info.
Hi Nick,
My build (wx 3.1.1) under MSYS has stack traces. Which version of
wxWidgets did you use?
Tom
_
Hi Jeff,
While rebasing my branches on the latest master, I noticed you've
refactored the legacy Draw() methods into Print() and moved some legacy
code to pcb_legacy_draw_utils.cpp. Is this code called anywhere within
pcbnew? (IIRC Orson finished Cairo/GAL printing support quite a while
ago...).
On 13/06/2019 15:35, Seth Hillbrand wrote:
>> I like that set of options. It fits in to my plan of absorbing as much
>> as possible from the left toolbar into the layer widget as part of my
>> overhaul of that part of the UI.
>> I also think it would be totally fine to have it *only* in the layer
>
On 22/06/2019 09:09, Greg Smith wrote:
>
> I think the biggest point I am making is that, mathematically, a point
> is identical to a vector from 0,0.
>
Hi Greg & Reece,
This is precisely the reason why we don't have separate point and vector
classes.
Tom
On 22/06/2019 16:32, hauptmech wrote:
> After reading through vector2d.h and matrix3x3.h, I agree with Reece
> more or less. There is ambiguity in the word vector, between math
> vectors, spatial vectors, and c++ vectors. Context implies that VECTOR2
> refers math vectors, but then MATRIX3x3 * VECT
On 22/06/2019 17:41, Reece R. Pollack wrote:
>
> While it is true that you can add two point coordinates and multiply by
> scalar 0.5 to get the midpoint, this is not true in the general case for
> arbitrary scalar multipliers. However, calculating the vector distance
> between two points, multipl
Hi all,
Here's a patch that restores missing junctions in schematic documents
that have been saved with missing libraries/cache (see [1] for an
example). In this case, some connection points on wires can be optimized
away, resulting in
a lot of ERC errors.
@JP/Wayne, is this OK for you or would
On 24/06/2019 11:50, Simon Richter wrote:
> Hi,
>
> On Mon, Jun 24, 2019 at 12:43:47AM -0400, Seth Hillbrand wrote:
>
>> 1) a double-joint in the final connection
>
> Hm, that might be an interesting creation mode: draw the outline as if it
> were a trace.
>
> I'm not entirely convinced that th
On 24/06/2019 15:05, Wayne Stambaugh wrote:
> The geometric constraint solver will be the solution for v6 but this
> still leaves us with the issue of what to do for the 5.1 branch.
Hi Wayne,
I didn't notice it's for v5.1.x branch. In this case, Seth solution is
perfectly OK.
Tom
On 25/06/2019 21:16, Simon Richter wrote:
> Hi Wayne,
>
> On Tue, Jun 25, 2019 at 12:36:36PM -0400, Wayne Stambaugh wrote:
>
>> I guess I should comment on this seeing that I am the project leader. I
>> am fine with refactoring as long as it's an improvement over existing
>> code.
>
> The main
On 27/06/2019 12:02, Simon Richter wrote:
> Hi,
>
> I've rebased[1] Tom's adaptation of my MSVC branch on top of current
> master, seems to compile still[2], except for the usual dependency problems
> with the generated lexers[3].
>
> In this branch, we have an assembler based libcontext (taken o
On 01/07/2019 23:49, Nick Østergaard wrote:
> Hello Tomasz
>
> Do you have any comments on the wxwidgets version?
Hi Nick,
I have 3.1.1 in my MSYS environment, probably manually built.
We have two options:
- ask MSYS folks to update wxWidgets in the package repository,
- factor out stack trace
On 05/07/2019 18:21, Seth Hillbrand wrote:
> I can't test the Windows functionality but this doesn't appear to break
> anything on Linux.
>
I'm ok with Simon's patches. Can give them a try on MSVC, but I'm pretty
confident they will work already.
@Simon: Now that we'll be supporting MSVC, should
On 06/07/2019 09:04, Carsten Schoenert wrote:
> Hi,
>
> Am 05.07.19 um 23:28 schrieb Ian McInerney:
>> 3.1.x is essentially only available on the lesser-known distros and as
>> additional packages for OpenSUSE. Aside from that, most distros run
>> anything between 3.0.2 and 3.0.4. (see
>> here: ht
On 06/07/2019 21:10, Ian McInerney wrote:
> Tom,
>
> Not to pile on the questions, but does the linux stack trace support
> exist in the entire 3.0.x line, or how far back does it go? Currently,
> the minimum version searched by cmake is 3.0.0, and some major linux
> distros only have 3.0.2 (Debia
On 10/07/2019 19:25, Seth Hillbrand wrote:
>
> Proposed solution: I would like to adjust the pcbnew file format and
> internal SHAPE_ARC, DRAWSEGMENT arc and EDGE_MODULE arc to use a single
> format consisting of start point, mid point and end point. Mid point
> here is defined as the point along
ul 2019 at 21:08, Nick Østergaard wrote:
>>
>> @Tomasz Wlostowski I just found that it looks like someone has
>> uploaded a wxwidgets 3.1 pkgbuild for the mingw-packages for msys2, I
>> could try to build and and rebuild your branch for windows.
>>
>> https://github.c
Hi,
I have design with a multi-row connector with pins labeled BGA-style
(a1, a2, etc.). I noticed the footprint for the same symbol in my
library has the pad names in uppercase (A1, A2) and so the netlister
doesn't connect these pins.
Is this the expected behaviour or should we make the pin/pad
Hi Devs,
I built today's master and to my surprise, pressing 'X' in pcbnew starts
immediately drawing a trace under the cursor, something I don't like
very much. Was this change accompanied by the (promised) option to
select between immediate action/activate tool behaviour of hotkeys
somewhere in
On 24/07/2019 19:28, Jeff Young wrote:
> Hi Tom,
>
> I’ll implement the preference if you’ll review my latest via push-n-shove
> stuff. ;)
>
Hi Jeff,
Sure - do you mean the stitching via pushing patch? I can also help with
the hotkey action preference.
Cheers,
Tom
501 - 600 of 727 matches
Mail list logo
