[Kicad-developers] Build failed in Jenkins: linux-kicad-full-gcc-head #3463

See Changes: [hillbrand] Correct message panel sizing [hillbrand] Optionally sort reporter messages [hillbrand] Only search pads when the position hits module [hillbrand] Avoid re-checking items

[Kicad-developers] Build failed in Jenkins: kicad-qa #4163

See Changes: [hillbrand] Correct message panel sizing [hillbrand] Optionally sort reporter messages [hillbrand] Only search pads when the position hits module [hillbrand] Avoid re-checking items already selected

Re: [Kicad-developers] More default fields in schematic

Wouldn't translating them defeat the purpose? I thought the goal was consistency. If you translate them, they will be different for each language and render code like kicost somewhat useless. On 05/22/2018 05:52 PM, Kristoffer Ödmark wrote: > Yes, the only way to make them translateable is to

Re: [Kicad-developers] A quick re-introduction

Hi Alexis, Welcome back. It's good to hear from you. Hopefully you will be able to shake loose some time to work on KiCad in the not too distant future. We could always use the help. Enjoy your trip to Digi-Key. To truly enjoy the full Digi-Key experience, you should visit in January or

Re: [Kicad-developers] A quick re-introduction

Hi Alexis, Welcome back. It's good to hear from you. Hopefully you will be able to shake loose some time to work on KiCad in the not too distant future. We could always use the help. Enjoy your trip to Digi-Key. To truly enjoy the full Digi-Key experience, you should visit in January or

Re: [Kicad-developers] More default fields in schematic

Yes, the only way to make them translateable is to hard-code these and other values into kicad, same as the existing hard-coded fields. That would be a good solution for me, having similar to layers a large set of predefined fields, being able to name them and enable them at will. But storing

Re: [Kicad-developers] rc2 tagged

Hi Wayne, Am 22.05.18 um 23:06 schrieb Wayne Stambaugh: > I forgot to push my tags last night. I just did it so you should be > able to clone from rc2 now. I would rather not move the rc2 tag commit > because I would have to move the KiCadVersion.cmake file changes and > overwrite the repo

Re: [Kicad-developers] rc2 tagged

Hey Carsten, On 05/22/2018 04:40 PM, Carsten Schoenert wrote: Hello Wayne, Am 21.05.18 um 13:55 schrieb Wayne Stambaugh: excellent! But I can't find the related tag 5.0.0-rc2 in both git trees, not on Launchpad nor on GitHub. Forgotten to push the tags also? Ahh! I forgot to push the tags.

Re: [Kicad-developers] rc2 tagged

Hello Wayne, Am 21.05.18 um 13:55 schrieb Wayne Stambaugh: >> excellent! >> But I can't find the related tag 5.0.0-rc2 in both git trees, not on >> Launchpad nor on GitHub. Forgotten to push the tags also? > > Ahh! I forgot to push the tags. I have it tagged on my system at home. > I will

Re: [Kicad-developers] A quick re-introduction

I do plan on sharing the slides if nobody objects. Still making a few last-minute changes (I know, I know) so I'll do that after the talk. No idea if they're planning on recording.On May 22, 2018 12:27 PM, Seth Hillbrand wrote:​Hi Alexis!Congrats and welcome!  Good luck

Re: [Kicad-developers] compiling kicad 4 with python support

Seth, thanks for the reply. > 1) revision ​30455092c is not KiCad 4. But perhaps you are trying to do > something else. If you wanted KiCad 4, you can checkout the tag with `git > checkout 4.0.7` > > ​​I tried installing kicad4 from the ppa but it didn't have the python stuff working. So I

Re: [Kicad-developers] More default fields in schematic

I can confirm that default fields only get added when the symbol is edited AND the default field’s value is non-empty. So it doesn’t seem to me that the proposed patch would pollute existing BOMs. Or am I missing something? Seth’s comment regarding localisation is an issue, though, as we

[Kicad-developers] A quick re-introduction

Hi, Just thought I'd finally get around to getting this out since I'm en route to Digi-Key to give a talk on KiCad, where my place on the dev team is somewhat relevant: I'm a trans person, and as such I'm taking a new name: Alexis Lockwood. I'm sending this from my old email to "authenticate"

Re: [Kicad-developers] A quick re-introduction

​Hi Alexis! Congrats and welcome! Good luck on your KiCad talk. If you're willing, it would be neat to see your slide deck or, better yet, your presentation but beggars and choosers, right? Best- Seth​ Am Di., 22. Mai 2018 um 10:10 Uhr schrieb Chris Pavlina < pavlina.ch...@gmail.com>: > Hi,

Re: [Kicad-developers] A quick re-introduction

Welcome, Alexis. (Re-welcome?) Anyway, l look forward to you getting some more Kicad cycles in. Cheers, Jeff. > On 22 May 2018, at 17:15, Chris Pavlina wrote: > > Hi, > > Just thought I'd finally get around to getting this out since I'm en > route to Digi-Key to

Re: [Kicad-developers] More default fields in schematic

This idea could be a good addition to KiCad eventually. However, at this point, it probably makes sense to discuss it in a bug report. The current strings "Reference", "Value", "Footprint" and "Datasheet" are all translated strings (not in the files but in the interface). The patch adds

Re: [Kicad-developers] compiling kicad 4 with python support

​Hi Matt- There's a couple odd things so I'll try to address them individually: 1) revision ​30455092c is not KiCad 4. But perhaps you are trying to do something else. If you wanted KiCad 4, you can checkout the tag with `git checkout 4.0.7` 2) The variables you show in the build settings

Re: [Kicad-developers] More default fields in schematic

On 5/22/2018 12:43 PM, Jeff Young wrote: >> It should output all fields defined in schematic symbols regardless if >> each optional field is defined in every symbol. If they are outputting >> anything other than that, I would consider this a bug. > > I had trouble parsing this. Are you saying

Re: [Kicad-developers] More default fields in schematic

> It should output all fields defined in schematic symbols regardless if > each optional field is defined in every symbol. If they are outputting > anything other than that, I would consider this a bug. I had trouble parsing this. Are you saying that the list of output fields should be the

Re: [Kicad-developers] More default fields in schematic

On 5/22/2018 6:05 AM, Jeff Young wrote: > I think I like this new patch.  It provides the /opportunity/ for > uniformity, without getting in the way of those who want to go their own > way. The new patch still has the potential to pollute existing project BOMs. Just because a user hasn't defined

[Kicad-developers] compiling kicad 4 with python support

Hi there, and thanks for developing kicad - I use it professionally on a daily basis. I've grown very used to using python in pcbnew, and after recently mistakenly updating kicad to 5 (latest nightly) I'm now in the situation of trying to compile a version of kicad4 that has python support. I

Re: [Kicad-developers] More default fields in schematic

Hello Everyone, I like the patch, and hope it makes it in. Clemens,  I don't think anything that is being discussed is in any way going to constrain b) or c).  But I think there is a third group, not just 1. Big Manufacturers 2. Hobbyist/Student but 3. Small Scale Professional

Re: [Kicad-developers] More default fields in schematic

Hello, I'd like to contribute with my 2c. I completely agree with Kristoffer, there is a need for a "MPN" field hard coded exactly as "Value" field is hard coded in Kicad. As Wayne mentions the current "Preferences - General Options - Default Fields" is not a bad option to add a "MPN" field.

Re: [Kicad-developers] More default fields in schematic

Hello, everybody! Just my five cents: Can we somehow make sure that people understand and consider and Kicad reflects the differences in: a) Unique partname + associated footprint + other arbitrary parameters necessary for the board design. b) One or more qualified components from a

[Kicad-developers] Jenkins build is back to normal : linux-kicad-full-gcc-head #3460

See ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe :

Re: [Kicad-developers] More default fields in schematic

My updated patch forgot to add the files before doing the --amend. So it only updated the commit message. Here is the real file On Tue, 2018-05-22 at 07:52 -0500, Ben Hest wrote: > From a Digi-Key KiCad library standpoint, as we're still in beta, I > would > gladly change the fields to whatever

Re: [Kicad-developers] More default fields in schematic

>From a Digi-Key KiCad library standpoint, as we're still in beta, I would gladly change the fields to whatever would be decided. Uniformity for plugins use would definitely be an advantage. -Ben On Tue, May 22, 2018 at 5:38 AM kristoffer ödmark < kristofferodmar...@gmail.com> wrote: > Thanks!

Re: [Kicad-developers] Call for Translators?

I concur. We should use whatever translations we have available even if it's less than ideal. Cheers, Wayne On 5/22/2018 7:16 AM, Jeff Young wrote: > One of the reasons we left the Language menu in the main menus (instead > of moving it to a dialog along with Icons in Menus, etc.) is for

Re: [Kicad-developers] More default fields in schematic

On 5/22/2018 4:11 AM, Maciej Sumiński wrote: > One more field that could become predefined and receive a special > meaning is 'Mounted' or similar. This will come handy when we decide to > support assembly variants and will let us add a visual distinction > between mounted and not mounted

[Kicad-developers] Build failed in Jenkins: linux-kicad-full-gcc-head #3459

See -- Started by upstream project "any-kicad-mirror-head" build number 2379 originally caused by: Started by remote host 91.189.89.26 with note: Something was pushed to the

Re: [Kicad-developers] Call for Translators?

One of the reasons we left the Language menu in the main menus (instead of moving it to a dialog along with Icons in Menus, etc.) is for people using partly-translated versions where they may have to switch back and forth a lot. So I’d also tend to lean toward the “give them what we have” side

Re: [Kicad-developers] More default fields in schematic

Thanks! This is exactly what i was going for, non-intrusive oppurtunity for uniformity! I tested the bom2csv plugin, It did not include the empty fields. I also tested the bom_csv_sorted_by_ref, it did not include the empty values, but it included some values I had not specified, such as

Re: [Kicad-developers] More default fields in schematic

I think I like this new patch. It provides the /opportunity/ for uniformity, without getting in the way of those who want to go their own way. Do the BOM generators automatically output all default fields or only those with values? > On 22 May 2018, at 09:22, kristoffer ödmark

Re: [Kicad-developers] More default fields in schematic

On Tue, 2018-05-22 at 10:11 +0200, Maciej Sumiński wrote: > One more field that could become predefined and receive a special > meaning is 'Mounted' or similar. This will come handy when we decide > to > support assembly variants and will let us add a visual distinction > between mounted and not

Re: [Kicad-developers] More default fields in schematic

Please disregard my previous mail, it got mangled badly somehow, it did not look like that in my editor at least. On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote: > Eeschema already supports creating default optional fields in the > configuration settings dialog. Used correctly, these

Re: [Kicad-developers] RC2 String Freeze Q

On Mon, May 21, 2018 at 01:01:12PM -0400, Wayne Stambaugh wrote: > Hi Seth, > > On 5/21/2018 12:44 PM, Seth Hillbrand wrote: > > Hi Wayne- > > > > There's a couple minor differences between the strings shown the user in > > modedit and pcbnew.  I'd like to standardize these.  This involves > >

Re: [Kicad-developers] More default fields in schematic

One more field that could become predefined and receive a special meaning is 'Mounted' or similar. This will come handy when we decide to support assembly variants and will let us add a visual distinction between mounted and not mounted components if we want it. The remaining fields is a matter

Re: [Kicad-developers] Call for Translators?

I think 80% is too high. Actually I think we should just ship the translations that has had any contribution within the string freeze period. It could be an incitement for a random contributor to see that some strings are actually translated. And then hopefully most of the work they may do can be

Re: [Kicad-developers] Call for Translators?

On Mon, May 21, 2018 at 04:07:31PM -0700, Seth Hillbrand wrote: > Hi Devs- > > Now that Wayne has declared rc2 and strings are frozen, does anyone have > objections to my posting a call for translators to the user forum? I just > checked the open items and it looks like there are a few languages

Re: [Kicad-developers] More default fields in schematic

The proposed patch would intermingle the default > fields with existing schematic symbol fields which would break > existing BOMs which I don't think users will appreciate. The proposed patch will only change default settings, existing users with a config already in place will not be affected.

Re: [Kicad-developers] Call for Translators?

Hi Seth, I have sometimes sent out an email directly to some of the "usual" and recent translators for languages that were missing updates. I have been playing with the thought of using something like transifex for the translations, but I decided not to use that because I can not see how it can