On 04/11/2023 17:50, Jon Evans wrote:
Hi Daniel,
> is this something worth putting more time into and work towards
making this a part of KiCad itself rather than a plugin?
It would be better in my opinion to use this only as a prototyping tool
to identify new DRC checks that should be
On 18/07/2023 20:06, Stuart Tyler wrote:
Hi Jon,
Thanks for the feedback. Yes, I agree with all your points. I started
off copying drag track but backed out of this as I got stuck accessing
the multiple selections, but totally agree with your points.
I have not looked through the component
On 03/07/2023 12:49, Stuart Tyler wrote:
Hi, this is my first ever post here. I am really impressed with the
development of KiCad over the past few releases. The python interface is
really good and I am keen to learn. I have been designing PCBs for a few
decades now and keen to help improve
Hi Filip,
Thanks for your interest in contributing to KiCad.
Have a look at this branch, a long time ago I started writing a constraint
solver (arcs + lines + linear dimensions) for pcbnew, but never had the time to
finish it.
On 12/01/2022 14:24, pmx wrote:
Le 12/01/2022 à 13:32, Franck Bourdonnec a écrit :
well, my second laptop is a an old e525 acer that is more than enough
rapid to do 'internet/video/kicad/kicad debuging...' even with 2~3
hours for a full build.
Having it unable to run KiCad , very
On 11/01/2022 22:45, pmx wrote:
From my previous tests (Kicad 5.99), I can say that any speed
bottleneck is likely NOT in the rendering engine, but in the rest of the
code.
I can't count how many Boost:: containers are scanned, and even
temporarily created and deleted, when you play with
On 20/11/2020 10:02, Alex wrote:
> Hi everyone,
>
> I started doing some C++11 modernization and Standard Library insertion
> in the rectangular placement segment of the PCBNew, and in the process I
> went down the rabbit hole of documentation for the algorithm. Out of
> curiosity I adjusted the
On 14/10/2020 20:00, pepijn de vos wrote:
> Hey all,
>
> I'm a sw dev and recent IC design graduate, who made it his mission to
> improve open source tools for IC designers.
> To this end I've been playing with the recently released Sky130 PDK,
> which is an open source PDK that does not require
My 5 quick cents:
> 1) tool to visualize nets lengths (similar to
> https://github.com/MitjaNemec/Kicad_action_plugins#length-stats ). I
> want to make a gui where you can define what nets you want to see
> altogether. And it should show you length on each layer and summary.
>
On 18/07/2020 23:47, Joshua Redstone wrote:
> Thanks, that link's a helpful starting point.
> Josh
Hi Joshua,
If you could figure out the algorithm for robust acute angle detection
(your input is a set of BOARD_ITEMs), I can integrate it with the new
KiCad DRC engine.
Tom
>
> On Fri, Jul 17,
On 10/07/2020 00:58, Reece R. Pollack wrote:
> I'm looking at display origin transformations for DRC reports.
>
> With the 5.1.x branch Pcbnew, the DRC report dialog box message texts
> contained the Cartesian coordinates of each flagged item. It appears
> that the 5.99 branch no longer displays
On 11/06/2020 22:27, Jeff Young wrote:
> I had also originally planned on “compiling” the classic system into
> behind-the-scenes rules, but I don’t think that’s going to work out. It’s
> pretty easy to agree on priority of all the edge case (pad override,
> footprint overrides, netclasses vs.
On 04/04/2020 18:18, Wayne Stambaugh wrote:
> For those of you who haven't heard, the Altium board importer[1] was
> merged into the master branch.
Fantastic work Thomas, looking forward to import our Altium projects
using your plugin!
Tom
___
Mailing
On 28/02/2020 13:00, BERTRAND Joël wrote:
> jp charras a écrit :
>> Le 28/02/2020 à 12:46, BERTRAND Joël a écrit :
>>> BERTRAND Joël a écrit :
Seth Hillbrand a écrit :
> Hi Joël-
>
> Please open an issue report at
> https://gitlab.com/kicad/code/kicad/issues and attach
On 09/02/2020 11:39, Eeli Kaikkonen wrote:
> As early as in the fundraising video
> https://www.youtube.com/watch?v=uhcMGQ32Xw0 for v6 (before the plans for
> 5.1 existed) "improved drawing tools" were introduced and apparently
> some work was already done by then. I don't find this anywhere in
On 03/12/2019 15:28, Wayne Stambaugh wrote:
> I am excited to announce that I have joined the
> KiCad Services Corporation[1]
Congratulations Wayne!
Tom
___
Mailing list: https://launchpad.net/~kicad-developers
Post to :
On 03/12/2019 02:43, Mark Roszko wrote:
> Just throw in a linear regression somewhere and we can say KiCad has
> AI based routing ;)
>
Our GAL does a lot of matrix multiplications. We could perhaps advertise
KiCad as the first EDA tool with a Deep Learning Techniques-based
rendering engine ;-).
On 02/12/2019 21:51, Kliment (Future Bits) wrote:
> The video looks very much like to me like the trace is following a
> voronoi cell boundary with cells coming out from each obstacle outline
> vertex. But what do I know? Maybe I'm just imagining things.
Maybe you're right ;-) I admire your
y topological
concepts (in the case of Kicad P, mainly in the optimizer part of the
code)...
BTW, I'm surprised by the smoothness of the animation in A***m's
promotional videos. Did they use some editing/postprocessing to make
them look this way? :D
Tom
>
> Hope this is helpful.
>
&g
..@gmail.com>> wrote:
>
> On 12/2/19 11:59 AM, Tomasz Wlostowski wrote:
> > On 02/12/2019 17:40, Vesa Solonen wrote:
> >> topological routing will
> >
> > Could you please explain what 'topological routing' does mean (other
> > than
On 02/12/2019 17:40, Vesa Solonen wrote:
> topological routing will
Could you please explain what 'topological routing' does mean (other
than being marketing buzzword used by some companies) and what exactly
it has to do with topology [1]?
Tom
[1] https://en.wikipedia.org/wiki/Topology
On 26/11/2019 20:46, Wayne Stambaugh wrote:
>
>>
>
> It was a joke in the same way that "Never trust the autorouter" is a
> joke. And like most good jokes, there is an uncomfortable truth about
> it.
Indeed ;-) (says the author of the aforementioned joke...)
It's a pun on a quote on the
On 22/11/2019 17:42, Rene Pöschl wrote:
>
> I would assume this is referencing version 6 of eagle. The current
> versions of eagle are actually something that can (in some aspects) be
> used as a good example. I would therefore assume that this sentence is
> simply out of date and could be
On 24/11/2019 18:20, Seth Hillbrand wrote:
>
> I generally like both of these. But part of that is because my IDE (VS
> Code and sometimes Eclipse) shows me the underlying type(...)
I second Seth. Also use VScode, great editor ;-)
T.
___
Mailing
On 07/11/2019 21:14, Wayne Stambaugh wrote:
> I am happy to announce that the KiCad project now has a new member of
> the lead development team. Ian McInerney has accepted an invitation to
> become a member of the lead development team. Ian's contributions have
> earned him this privilege and we
On 30/10/2019 17:37, Seth Hillbrand wrote:
>
> Two things can help there. First, using the gold linker (if you are not
> already) and second, using Ninja. The gold linker is substantially
> faster than the BFD linker.
I can confirm the above, way faster!
> And Ninja is smarter than make
On 30/10/2019 16:20, Simon Richter wrote:
> Hi,
>
> On Tue, Oct 29, 2019 at 07:00:48PM +0100, Tomasz Wlostowski wrote:
>
>> $ make -j12
>
>> real 7m59.758s
>> user 86m44.231s
>> sys 5m9.724s
>
> That is more than 1100% CPU usage, with -j12, so ve
On 29/10/2019 15:40, Simon Richter wrote:
> We could probably shave off another two or three minutes of build time if
> we could make sure that we always make progress on the critical path. The
> dependency generation as a side effect pulls all the sources and headers
> into cache, which reduces
On 10/09/2019 20:55, Michael Kavanagh wrote:
> There is a subtle difference between Ctrl+Click and Shift+Click for
> adding items to a selection. E.g. in Windows Explorer/macOS Finder/MS
> Office:
> - Ctrl + Click: Add only the clicked item to the selection
> - Shift + Click: Add the clicked
On 10/09/2019 20:58, Andy Peters wrote:
> Oh, good god, don’t get me started on the shitty keyboard on the 2017 Touch
> Bar MacBook Pro on which I type this! But the Mac trackpads are still head
> and shoulders above every comer.
>
> (Truth be told, this MBP is a GREAT Kicad machine.)
I do
On 10/09/2019 20:45, Andy Peters wrote:
>
> Ctrl-Click on macOS defaults to right-button click, harkening back to
> the days of the Mac’s one-button mouse (“one button oughta be enough for
> everyone!”).
Not much changed since then ("unusable keyboard oughta be enough for
everyone - all they
ards)
>>> for toggle selection.
>>>
>>> ` is now hooked up to highlight net.
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>> On 10 Sep 2019, at 13:30, Tomasz Wlostowski
>>> wro
Hi,
Am I missing something or did Ctrl-click to highlight a net suddenly
stopped working in pcbnew?
Cheers,
Tom
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe :
On 10/09/2019 08:30, Diego Herranz wrote:
> Hi, all
>
> The CERN Open Days (https://opendays.cern/) will be held this weekend.
> I'll be there on Sunday. Will any developer or librarian be there? Or
> any of the guys working at CERN?
Hi
I'll be there. Orson is away. Drop me an e-mail if you
On 27/08/2019 16:18, Steven A. Falco wrote:
> On 8/26/19 4:16 PM, Seth Hillbrand wrote:
>> On 2019-08-26 16:05, Tomasz Wlostowski wrote:
>>> On 26/08/2019 17:24, Seth Hillbrand wrote:
>>>> Agreed. That looks like it may be have been a rebase issue as the
>>
On 26/08/2019 17:24, Seth Hillbrand wrote:
> Agreed. That looks like it may be have been a rebase issue as the
> commit was for MSVC and shouldn't affect PPC.
>
> @Tom, shout if you see an issue here. I've pushed the patch to master
> in the meantime.
>
I don't see a technical issue, but
Hi Fellow Devs,
I'm fixing some memory management issues in the P by introducing smart
pointers here and there. Do we have any coding policy on typedefing
shared_ptrs/unique_ptrs?
Should I:
- always use std::shared_ptr explicitly?
- or am I allowed to typedef std::shared_ptr TYPE_SP (or
On 07/08/2019 19:45, Jeff Young wrote:
> Hi Orson,
>
> I wanted to keep the selection highlight shadows uncached, but they need to
> go above the device backgrounds and sheet backgrounds.
>
> I can go ahead and put them in cached. (I just need to add some code to
> redraw them when the zoom
On 07/08/2019 19:45, Jeff Young wrote:
> Hi Orson,
>
> I wanted to keep the selection highlight shadows uncached, but they need to
> go above the device backgrounds and sheet backgrounds.
>
> I can go ahead and put them in cached. (I just need to add some code to
> redraw them when the zoom
On 30/07/2019 20:03, Nick Østergaard wrote:
> I get the same error. :(
>
Hi Nick,
We had two problems:
- wrong check macro (I removed it in the last commit from my branch)
- wrong build of wx (must be configured with --enable-backtrace - fixed
PKGBUILD in the attachment).
Latest code here:
On 30/07/2019 15:33, Nick Østergaard wrote:
> It was built like this:
> https://github.com/msys2/MINGW-packages/blob/c6dfad711f4d956a02e93026a0eb9a74ad6bfd65/mingw-w64-wxWidgets3.1/PKGBUILD
>
Try building wx with --enable-backtrace --enable-debugreport
T.
On 30/07/2019 14:54, Nick Østergaard wrote:
> Exacept when I try to build it against wx 3.1 I get errors like:
>
> debug_report.cpp:515:5: error: 'YAML_STACK_WALKER' was not declared in
> this scope
>
> Building against 3.0 is ok, but it crashes when it is trying to upload
> a bug report.
>
> I
On 29/07/2019 18:47, Nick Østergaard wrote:
> I rebased this for todays master and pushed it to:
> https://github.com/nickoe/kicad-source-mirror/tree/tom-crash-reporter-may27_rebased20190729
>
> Diff view of changes:
>
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
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
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
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.com/msys2/M
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
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:
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,
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 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
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 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 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
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 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,
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 *
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 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
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 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
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 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.
-
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 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 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 to cre
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
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 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
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,
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 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 y
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 y
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 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)?
>
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
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
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
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
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.
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 ucon
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 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
++
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 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
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:
>
>
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
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 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
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
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
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 :
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 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
>>
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
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
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 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 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
1 - 100 of 675 matches
Mail list logo
