Re: [Kicad-developers] GitLab migration

Hi Andrew, I deliberately skipped the closed bugs, as I thought they do not carry much value, and they would still be available in the Launchpad tracker. If majority prefers to migrate the closed bugs, then there is nothing in the way. Cheers, Orson On 11/11/19 11:54 PM, Andrew Lutsenko wrote:

Re: [Kicad-developers] Tab handling in text rendering and bbox calculation

On 2019-11-11 17:48, Andrew Lutsenko wrote: > Hi Seth, Jeff, > I see you have touched this code recently. I've noticed that tabs are handled > differently for bbox calculation resulting in slightly oversized bbox. > > When rendering tabs we count them as whatever width is needed to align to

[Kicad-developers] Tab handling in text rendering and bbox calculation

Hi Seth, Jeff, I see you have touched this code recently. I've noticed that tabs are handled differently for bbox calculation resulting in slightly oversized bbox. When rendering tabs we count them as whatever width is needed to align to multiple of 4 and +1 additional space but when calculating

Re: [Kicad-developers] Project save as

ti 12. marrask. 2019 klo 0.02 Jon Evans (j...@craftyjon.com) kirjoitti: > I question the value of creating this amount of complex UI around "save > as". > In that case I personally would prefer minimal functionality, copying only the necessary project files. More likely than not the generated

Re: [Kicad-developers] GitLab migration

Is it possible to migrate closed bugs as well? I think gitlab search indexing is much more useful, having history conserved there will likely be handy. On Mon, Nov 11, 2019 at 2:31 AM Maciej Suminski wrote: > Excellent, thanks for the verification! I have also checked a few other > reports that

Re: [Kicad-developers] Project save as

I guess ultimately this is up to Jeff since he's implementing it, but I think this is going way above and beyond what any user should expect of an application. I have never used any software that tried this hard to handle the "save as" feature without any chance of the user needing to take some

Re: [Kicad-developers] Project save as

Here's a rough idea of what a confirmation dialog could do: [image: image.png] I think something like that would be flexible enough to help the user with most workflows and left the responsibility to the user while being simple and easy enough to use (although a bit more work to implement, of

Re: [Kicad-developers] Project save as

Limiting it to a dash is just because that’s all Kicad generates. The user could indeed use anything. So should we rename any file that starts with the old project name? I did have a version that did that, but it seemed too aggressive to me. > On 11 Nov 2019, at 20:56, Eeli Kaikkonen wrote:

Re: [Kicad-developers] Project save as

But even doing that is going to be more work, as they’re going to have to delete a whole pile of old files…. I have several old projects that I haven’t opened since the 4.0.x days. I may want to move them, but regenerating the Gerbers wouldn’t necessarily generate the same files. (It might

Re: [Kicad-developers] Project save as

ma 11. marrask. 2019 klo 22.41 Jeff Young (j...@rokeby.ie) kirjoitti: > Yes, the current algorithm renames files that either match the project > name (with any extension), or start with the project name followed by a > dash. > Limiting the following character to dash seems arbitrary. Underscore

Re: [Kicad-developers] Project save as

I agree, we should only be transferring and renaming the non-generated files rather than trying to account for every possible file under the sun. If the user wants the generated files, they can regenerate them from the new project. -Ian On Mon, 11 Nov 2019, 20:30 Jon Evans, wrote: > In my

Re: [Kicad-developers] Project save as

Yes, the current algorithm renames files that either match the project name (with any extension), or start with the project name followed by a dash. We don’t need to know the extension in either case. This feels right to me, but I’m open to discussion. Cheers, Jeff. > On 11 Nov 2019, at

Re: [Kicad-developers] Project save as

> On Nov 11, 2019, at 1:28 PM, Seth Hillbrand wrote: > > On 2019-11-11 11:42, Jeff Young wrote: > >> A... I didn't notice that. We are indeed failing to look for the Protel >> extensions. > > Are we renaming generated files? If we stick with base project files, it's > easy to explain

Re: [Kicad-developers] Project save as

In my opinion we should not rename any generated files. This matches my experience with other tools. On Mon, Nov 11, 2019 at 3:28 PM Seth Hillbrand wrote: > On 2019-11-11 11:42, Jeff Young wrote: > > > A... I didn't notice that. We are indeed failing to look for the > > Protel extensions.

Re: [Kicad-developers] Project save as

On 2019-11-11 11:42, Jeff Young wrote: A... I didn't notice that. We are indeed failing to look for the Protel extensions. Are we renaming generated files? If we stick with base project files, it's easy to explain where the cut-off is. Once we go down into generated files, this gets

Re: [Kicad-developers] Project save as

A… I didn’t notice that. We are indeed failing to look for the Protel extensions. > On 11 Nov 2019, at 19:35, Eeli Kaikkonen wrote: > > ma 11. marrask. 2019 klo 20.39 Jeff Young (j...@rokeby.ie > ) kirjoitti: > I want to address the Gerber issue first. In this

Re: [Kicad-developers] [PATCH] Eeschema: simulator: more trace colors, smarter color allocation

Thanks! I agree a user setting would be best, preferrably with some nice included palettes. I left the old commented palettes since there was already several other palettes there. Perhaps it would make sense to just backport the bug fix, but keep the old 8-color palette? /Jonatan > 11 nov.

Re: [Kicad-developers] Project save as

Next for the folder or file question. New project does indeed ask for the name of the project file and also asks if you want a directory auto-created. I hate that, but I’ll admit it’s clearer than the Save As… case where you’re not sure which it’s asking for. We have our own dialog for

Re: [Kicad-developers] Project save as

I want to address the Gerber issue first. In this case Eeli was expecting the old name to get updated if it occurred anywhere in the filename. My expectation was that it would only get updated if the file name started with the old name. Either is easy to implement, but I’d rather not have a

Re: [Kicad-developers] [PATCH] Eeschema: simulator: more trace colors, smarter color allocation

Jonatan, Thank you for putting this together. Overall I think it looks good, but the only issue I saw was that the SIM_PLOT_FRAME::generateColor() function seems to be becoming a graveyard for old colors with 4 old attempts at creating color profiles now commented out. I have merged it into

Re: [Kicad-developers] Project save as

ma 11. marrask. 2019 klo 18.07 Wayne Stambaugh (stambau...@gmail.com) kirjoitti: > Isn't this this the same behavior as File->New? We should keep the path > creation behavior consistent. > It should be possible to use the same customized dialog then, right? Now it's different. Eeli Kaikkonen

Re: [Kicad-developers] Project save as

Isn't this this the same behavior as File->New? We should keep the path creation behavior consistent. On 11/11/19 10:56 AM, Jon Evans wrote: > FWIW, we are considering moving to the "create a folder for the project" > to be a requirement rather than an option, in case that impacts this >

[Kicad-developers] [PATCH v5] eeschema: Allow hierarchy navigator to stay open

Hi again ! I now have fixed the commit message to include a tag (ADD). Franck. From 350f5fc0ad7c128c3d152317297468a7b9516e62 Mon Sep 17 00:00:00 2001 From: Franck Jullien Date: Thu, 24 Oct 2019 19:07:01 +0200 Subject: [PATCH v5] eeschema: Allow hierarchy navigator to stay open ADD: User can

Re: [Kicad-developers] [PATCH v3] [NEW] eeschema: Allow hierarchy navigator to stay open

Too late :( I'll do that in a v5. I thought tag should be in subject. I misread the instructions. Franck. Le lun. 11 nov. 2019 à 14:57, Maciej Suminski a écrit : > > Hi Franck, > > Please remember to add changelog tags [1] when sending patch v4. Thanks! > > Cheers, > Orson > > 1.

Re: [Kicad-developers] Project save as

FWIW, we are considering moving to the "create a folder for the project" to be a requirement rather than an option, in case that impacts this feature. Or rather, it would be a requirement that there be one KiCad project per folder, not necessarily that automatically creating a folder would be a

Re: [Kicad-developers] Project save as

I hope you don't mind I give some first impressions here. I can move these to bug database if needed. Before trying it's unclear what the file dialog selects. I created a new directory (with the name of the new project), went inside it and gave the project name in the dialog. "All files *.*"

Re: [Kicad-developers] [PATCH] Eeschema: simulator: more trace colors, smarter color allocation

And here's a screenshot showing how (some of the) new colors looks like. On Fri, Nov 8, 2019 at 5:13 PM Jonatan Liljedahl wrote: > > NEW: The simulator plot now avoids colors already in use, if possible. > The palette is replaced with a larger one with less saturated colors. > > Fixes:

Re: [Kicad-developers] [PATCH] simulation: allow entering signals (spice vectors) by name

Thank you Wayne! I would of course be very happy if you decide to merge it to 5.1 branch as well, since it's currently the only way to do math on simulation plots, and I understand 6.0 is quite far away. Regarding automatically populating the signal list with available spice vectors, I agree

Re: [Kicad-developers] [PATCH] simulation: allow entering signals (spice vectors) by name

Hi Jonaton, I pushed your patch into the master branch. I haven't made up my mind on the 5.1 branch. Technically this is a new feature. We have an unwritten policy to not backport new features from the master branch. Given that this is a fairly trivial change, I may consider applying your

[Kicad-developers] Commit message policy change

I just pushed a minor change to the KiCad commit message policy[1]. It may take a few hours before the KiCad developer docs get updated. The NEW tag has been deprecated. Please use the ADD(ED) tag when adding new features that the user will see. This should simplify things a bit as NEW and

Re: [Kicad-developers] [PATCH v3] [NEW] eeschema: Allow hierarchy navigator to stay open

Hi Franck, Please remember to add changelog tags [1] when sending patch v4. Thanks! Cheers, Orson 1. http://docs.kicad-pcb.org/doxygen/commit_messages.html On 11/10/19 7:36 PM, Franck Jullien wrote: > Le dim. 10 nov. 2019 à 18:29, jp charras a écrit : >> >> Le 10/11/2019 à 17:33, Franck

Re: [Kicad-developers] Interpreting the ARC command

Take a look at the legacy footprint library file format documentation[1] for help. You really should be supporting the new s-expression file format. The legacy file format is deprecated and is read only.

Re: [Kicad-developers] [PATCH] Pcbnew drill sizes statistics & Project manager multiple selection options

Thanks for this. Note though that when passing the functions into the Connect method in wxWidgets, you should specify the fully qualified name (including the class) of the function. When this is not specified, a build error happens on my wxWidgets 3.0.4 Linux build. I have pushed a fix for this to

Re: [Kicad-developers] GitLab migration

Excellent, thanks for the verification! I have also checked a few other reports that had original authors incorrectly assigned, so I believe the bug has been fixed. Cheers, Orson On 11/11/19 10:29 AM, Eeli Kaikkonen wrote: > Now the example bug report ("Implicit 4-way junction" etc.) is

[Kicad-developers] Interpreting the ARC command

I'm writing a program the reads schematic library symbols, and I'm having hard time understanding how arcs are drawn. Taking, for example, the Antenna_Shield symbol from device.lib. This symbol contains two arcs: A -1 -73 32 -882 1242 0 1 0 N 0 -105 -20 -45 A 1 -73 32 -918 558 0 1 0 N 0 -105 20

Re: [Kicad-developers] GitLab migration

Now the example bug report ("Implicit 4-way junction" etc.) is correctly attributed to "eelik". Eeli Kaikkonen su 10. marrask. 2019 klo 19.44 Maciej Suminski (maciej.sumin...@cern.ch) kirjoitti: > On 11/10/19 5:54 PM, Seth Hillbrand wrote: > > On 2019-11-10 08:43, Seth Hillbrand wrote: > > > >>

Re: [Kicad-developers] [PATCH] Pcbnew drill sizes statistics & Project manager multiple selection options

Le 11/11/2019 à 01:12, Ian McInerney a écrit : > JP, > > Are you running this on your 3.0 or 3.1 build of wxwidgets? That looks > like there is an issue with their autosize calculation not factoring in > the width of the sorting bitmap. > > -Ian > I am using wxWidgets 3.1.3 currently. (I

Re: [Kicad-developers] [PATCH] Pcbnew drill sizes statistics & Project manager multiple selection options

Le 11/11/2019 à 01:04, Mikołaj Wielgus a écrit : > - Pcbnew drill sizes statistics: > I've modified the filter and also made the last two columns expand to > fit the remaining space during grid creation and window resizing. > > As for the column sizes: they are assigned with the