I like the button idea, the same thing should be done in the schematic
field editor, that would basically replace cvpcb for most usecases.
On Thu, Jul 19, 2018 at 2:53 PM, Jeff Young wrote:
> I thought there was already a bug for this (reported by Gabriel perhaps?),
> but I can’t seem to find
Ah, you’re totally right. That escaped my mind (hard to track bug w.r.t. std vs
boost). I wasn’t sure how things like that were handled (std vs boost variant
also comes to mind).
From: Seth Hillbrand
Sent: Thursday, July 19, 2018 3:28:43 PM
To: Thomas Figueroa
Awesome, thanks for the update!
Den fre. 20. jul. 2018 kl. 00.48 skrev Rene Pöschl :
>
> The library repos should now all be tagged. (Github had some server
> problems so it all took quite some time. I hope nothing got damaged
> because of that.)
>
> On 19/07/18 10:49, Nick Østergaard wrote:
> >
The library repos should now all be tagged. (Github had some server
problems so it all took quite some time. I hope nothing got damaged
because of that.)
On 19/07/18 10:49, Nick Østergaard wrote:
This sounds good. Thank you.
Den tor. 19. jul. 2018 kl. 10.43 skrev Rene Pöschl :
On 18/07/18
Cool. Thanks, Tom.
> On 19 Jul 2018, at 16:28, Tomasz Wlostowski wrote:
>
> On 18/07/18 13:06, Jeff Young wrote:
>> Hi Tom, et al,
>>
>> I assume we just need to drop wxDC for the canvas, but that UI constructs
>> (such as colour swatches, etc.) would continue to use wxDC?
>
> To clarify:
Thanks for your contribution, Konstantin!
I’ve applied your patch to the 5.1 and 6.0 branches.
Cheers,
Jeff.
> On 15 Jul 2018, at 06:36, Константин Барановский
> wrote:
>
>
> <0001-Fix-untranslatable-label.patch>___
> Mailing list:
I’ve merged code that I think will fix the issue on non-double-buffered
platforms. I you could double-check that would be great.
Cheers,
Jeff.
> On 19 Jul 2018, at 21:07, Jeff Young wrote:
>
> Actually I think it happens on OSX too, you just don’t notice because of
> double-buffering.
Hi Thomas-
Thank you for the contribution! Right now KiCad only uses C++11. But once
we move up to C++17, we will want to minimize code paths so that everyone
sees the same result. Otherwise we risk introducing bugs that _really_
hard to track down. In other words, replacing boost:: with
Actually I think it happens on OSX too, you just don’t notice because of
double-buffering. Appears I failed to put hysteresis into OnUpdateUI.
> On 19 Jul 2018, at 18:19, Wayne Stambaugh wrote:
>
> Jeff,
>
> Please take a look at the attached video of the eeschema plot dialog.
> Notice the
deprecated_functionality.patch
Description: deprecated_functionality.patch
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help
Hello everyone, my name is Thomas. I’ve posted a few times on here to submit
some feedback, but
now I have finally mustered the courage to submit stuff for development.
This first pair of patches is really just to get a feel for things and get
feedback on any issues with
my process or potential
I thought there was already a bug for this (reported by Gabriel perhaps?), but
I can’t seem to find it.
> On 19 Jul 2018, at 20:40, Wayne Stambaugh wrote:
>
> I second this motion. I didn't find the right click trick so I fell
> back to cvpcb which is overkill to change the footprint of a
I second this motion. I didn't find the right click trick so I fell
back to cvpcb which is overkill to change the footprint of a single
symbol. A tooltip might be useful here as well.
On 7/19/2018 3:19 PM, Diego Herranz wrote:
> Hi,
>
> I've started to test these changes and, on the Symbol
Hi,
I've started to test these changes and, on the Symbol properties dialog, I
found it hard to assign a footprint.
Before, there used to be a button to open the Footprint selector window.
Now you seem to need right click on the footprint field and "select
footprint" and that only works if you're
Windows. I can test linux after I get home from work this evening.
On 7/19/2018 2:14 PM, Jeff Young wrote:
> Windows or Linux?
>
> It should highlight to two footnotes, although I’m not sure I’ve tested
> courtyard errors.
>
> Try a track too close to a pad, and it should highlight the track
Windows or Linux?
It should highlight to two footnotes, although I’m not sure I’ve tested
courtyard errors.
Try a track too close to a pad, and it should highlight the track and the pad.
(But probably not on Windows, as it’s based on the same code we use for
selection disambiguation
What exactly is supposed to get highlighted? I have board I'm working
on with some overlapped courtyard errors and I don't see any
highlighting when I select a error in the drc dialog or hover over the
drc markers. I do see the board pan to show the drc marker when it is
underneath the dialog.
Jeff,
Please take a look at the attached video of the eeschema plot dialog.
Notice the page size control be refreshed (flckering). The makes
selecting a page size impossible although the plotting still works. The
same thing happens with the fillet radius static text in the zone
properties
This was pretty much how I saw the development working which is why I
created a separate 5.1 branch. However, if we are not going to allow
new features to be merged into the master branch (6.0-dev) (and it seems
that is the consensus) then I propose that we do all of the 5.1
development in the
Am Do., 19. Juli 2018 um 00:49 Uhr schrieb Tomasz Wlostowski <
tomasz.wlostow...@cern.ch>:
> On 19/07/18 06:15, Seth Hillbrand wrote:
> > Hi All-
> >
> > Our current triangulation caching is based on the poly2tri codebase and
> > has a number of constraints. Most notably, it does not allow
Hi,
for me as a person which doesn't do any active source code development
on KiCad it looks like there is some confusion in the wild what will or
should happen in which branch.
Sorry if I haven't get it until now, what are the goals of the branch
5.1 the project wanted to archive?
And what is
+1
> On 19 Jul 2018, at 16:57, Seth Hillbrand wrote:
>
> I'd be in favor of this but if we're going to focus exclusively on v5.1 GTK3
> migration, can we push the current state, warts and all to the master? We
> have a bunch of bugs tagged to 5.1 but only one is GTK3-related. I suspect
>
Could someone test the DRC highlighting on Linux and Windows. (Since it uses
the same selection highlighting code my guess is that it doesn’t work on
Windows.)
Run a DRC on a board that has some errors.
Right click on an error in the DRC errors list.
Hover back and forth over the two entries
I'd be in favor of this but if we're going to focus exclusively on v5.1
GTK3 migration, can we push the current state, warts and all to the
master? We have a bunch of bugs tagged to 5.1 but only one is
GTK3-related. I suspect we have a number of things to work on here but
without bug assignment,
I’m fine with it either way (my stuff is currently equivalent between the two).
> On 19 Jul 2018, at 16:28, Maciej Sumiński wrote:
>
> It will be a huge motivation for us to fix GTK3 problems as soon as
> possible. I assume you mean to drop the current master branch (or rename
> to 6.0?) and
On 18/07/18 13:06, Jeff Young wrote:
> Hi Tom, et al,
>
> I assume we just need to drop wxDC for the canvas, but that UI constructs
> (such as colour swatches, etc.) would continue to use wxDC?
To clarify: SCH/PCB preview widgets will also use GAL.
Tom
>
> Thanks,
> Jeff.
>
>
>> On 17 Jul
It will be a huge motivation for us to fix GTK3 problems as soon as
possible. I assume you mean to drop the current master branch (or rename
to 6.0?) and make 5.1 the new master branch?
On 07/19/2018 05:19 PM, Wayne Stambaugh wrote:
> You are preaching to the choir. I did most of the maintenance
Hi Jeff,
Yes, for the moment we work to replace wxDC only in places that really
need it. So far it was necessary in pcbnew to boost performance, now
eeschema suffers the same problem with GTK3.
Cheers,
Orson
On 07/18/2018 01:06 PM, Jeff Young wrote:
> Hi Tom, et al,
>
> I assume we just need
You are preaching to the choir. I did most of the maintenance on the
4.0 branch. Initially it was easy but it didn't take long for it to
become a PITA. If no one else objects, I would be more than happy to
make that the policy. If that is indeed what we want to do, I would
delete the 5.1
FWIW, as someone who is also maintaining parallel feature branches, I agree
with Orson and John. Now that we have committed to this 5.1 idea, we
should just make it happen in master. I think if we keep both master and
5.1 branch running in parallel, inevitably one or the other of them will be
Hey Fabrizio,
I thought you were the author I just wasn't sure.
Thanks,
Wayne
On 7/18/2018 6:15 PM, Fabrizio Tappero wrote:
> Hi Wayne,
> How are you? I'm the author of the kicad logo and everything is of
> course fine with me.
>
> Cheers
> Fabrizio
>
>
> On Jul 18, 2018 7:36 PM, "Wayne
On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh wrote:
> Unless we are going to prohibit new features (new file formats, new tool
> framework for eeschema, etc.) from being merged into the dev branch
> until 5.1 is released, I disagree. If we want to only work on 5.1 in
> the dev branch, then
Unless we are going to prohibit new features (new file formats, new tool
framework for eeschema, etc.) from being merged into the dev branch
until 5.1 is released, I disagree. If we want to only work on 5.1 in
the dev branch, then I'm OK with this proposal.
On 7/19/2018 8:39 AM, John Beard
I agree with Orson. It's unfortunate for people to not be able to dump
new features onto master after such a long freeze. However, if 5.1 and
master/6-dev diverge, there will be a lot of pain in porting bugs,
especially if one branch has work that very is invasive and touches a
lot of code, and
Keep in mind that as long as there is a shared user configuration
between versions, there is the potential for issues due to the storage
of environment variables in the user config. The only way to ensure
there will be no version issues is to ensure each new version has a
separate user config.
Alright. Thanks Bernhard. I still suspect that it's very rare compared to
users with custom environment variables on Windows and Linux.
This is yet another reason that this can't get done by Friday.
Adam
On Thu, Jul 19, 2018, 1:06 AM Bernhard Stegmaier
wrote:
> I wouldn’t rely on that.
>
I wonder if there is a point in keeping 5.1 and master branches
separated. In 5.1 there is a lot of new code that will need patches, and
they need to be applied to both branches now. If we keep adding more
features to the master branch, then at one point the branch may diverge
significantly enough
If you need it for something, then I made this build of the 5.0 branch
with only kicad and libs.
http://downloads.kicad-pcb.org/windows/testing/patched/kicad-patched-58-5.0.1-dev-4-g3dcf04fdb-x86_64.exe
It should be suitable to install on top of a rc3 or nightly. Please do
install and test it if
As the installer package everything we can not make a proper 5.0.0
stable before it has been tagged.
Den tor. 19. jul. 2018 kl. 10.21 skrev Maciej Sumiński
:
>
> Hi Simon,
>
> The installer works well, no warnings observed here. Do you think you
> could create one for 5.0.0 stable and upload it to
This sounds good. Thank you.
Den tor. 19. jul. 2018 kl. 10.43 skrev Rene Pöschl :
>
> On 18/07/18 19:59, Carsten Schoenert wrote:
> > Am 18.07.18 um 19:55 schrieb Rene Pöschl:
> >>> I'm traveling the whole Saturday and Sunday to Debian DebCamp and
> >>> DebConf in Taiwan and working on packaging
On 18/07/18 19:59, Carsten Schoenert wrote:
Am 18.07.18 um 19:55 schrieb Rene Pöschl:
I'm traveling the whole Saturday and Sunday to Debian DebCamp and
DebConf in Taiwan and working on packaging kicad-packages3d on a laptop
is PITA. So I'd like to this at home on a more powerful machine at home
Hi Simon,
The installer works well, no warnings observed here. Do you think you
could create one for 5.0.0 stable and upload it to windows/stable directory?
Cheers,
Orson
On 07/19/2018 01:17 AM, Simon Richter wrote:
> Hi,
>
> I've just rebuilt the latest MSYS2 nightly and the rc3 package in
>
On 19/07/18 06:15, Seth Hillbrand wrote:
> Hi All-
>
> Our current triangulation caching is based on the poly2tri codebase and
> has a number of constraints. Most notably, it does not allow touching
> holes, holes on the boundary or duplicate vertices. In these cases, we
> do not cache the
I wouldn’t rely on that.
You can set paths on macOS and at least I needed it to do in my setup before
Wayne made the path configuration dialog.
So, I wouldn’t bet that there are no such macOS installs out there… :)
Regards,
Bernhard
> On 19. Jul 2018, at 06:07, Adam Wolf wrote:
>
> On Mac,
44 matches
Mail list logo
