Re: [Kicad-developers] [RFC][PATCH] import pins from CSV

Replying again because I've updated this patch. It now supports pin types, as well as fixing a crash that I noticed after I sent the last one. Cheers, Alex On Tue, Feb 07, 2017 at 12:31:39PM -0800, Alex Bell wrote: > Importing a CSV file into component editor > > 1. Start kicad, launch

[Kicad-developers] menu bitmaps

Currently the CMakeLists.txt says that menu icons are 16x16, but many of the icons which i believe are in the menu and in the menu only are in the 26x26 list, this includes the lang_* icons (for example) which i have yet to see outside of the language menu. which one should it be and can the

Re: [Kicad-developers] [PATCH] Dragging with tracks in GAL

This needs with some other patches on the list. To use this patch, you need the "CCW rotate" patch and the "delete tracks" patch to be applied first. There is a branch with just this patch (which will conflict with the above mentioned patches) at

[Kicad-developers] [PATCH] Dragging with tracks in GAL

Hi, Here is a really basic concept patch for component dragging with tracks ('G') in pcbnew GAL. It uses the same dragging mechanism as legacy for modules and pads. If it's not desired to continue to use that code for the time being, at least this provides the TOOL_ACTION hook and outlines where

Re: [Kicad-developers] for comment: legacy canvas in V5 release

I really like this idea. Removing terms only really known to developers (Cairo, GAL) and naming them based on their *function* would be a huge improvement especially for newer users who have yet to get used to KiCAD-particular names. On Wed, Feb 8, 2017 at 9:57 AM, Chris Pavlina

Re: [Kicad-developers] for comment: legacy canvas in V5 release

On 07.02.2017 23:57, Chris Pavlina wrote: > I suggested something related earlier. Here is what I would do: > > - Merge OpenGL and Cairo!!! The average user doesn't know what a Cairo > is, or what a GAL is. We're lucky if they know what an OpenGL is. > OpenGL and Cairo should just be

Re: [Kicad-developers] for comment: legacy canvas in V5 release

I suggested something related earlier. Here is what I would do: - Merge OpenGL and Cairo!!! The average user doesn't know what a Cairo is, or what a GAL is. We're lucky if they know what an OpenGL is. OpenGL and Cairo should just be "Pcbnew", with a fallback from GL to Cairo if GL can't

[Kicad-developers] for comment: legacy canvas in V5 release

Given the recent thread on making Legacy a build option and after a number of conversations with people familiar with the source code, it seems that a number of developers believe that the Legacy canvas code is really holding back a lot of improvements to the code structure. I would suggest that

Re: [Kicad-developers] [PATCH] Delete whole tracks in GAL

Mm, it seems this also reverses it such that you have to use backspace to delete a footprint whereas in that case the delete key should be used. 2017-02-07 10:36 GMT+01:00 John Beard : > The first of these patches has a mistake in the selection code, which > used to clear

Re: [Kicad-developers] [PATCH] Fix arc selection over-enthusiastic bounding boxes

Now I wonder why I kept it this way. The only problem I have noticed is that the center edit point (the white squares used for dragging) of capacitor arcs disappear in the footprint editor when the arc itself out of view. Still, I consider it less erroneous behaviour than what we previously had. I

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

> > As I understand it, CvPCB is slated for removal anyway, and the > filter-by-pin-count functionality only exists there. I have been informed that I may not be correct on this point. Disregard this if this is the case - the other points still stand. On Wed, Feb 8, 2017 at 9:35 AM, Oliver

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

> > As for our standard libraries, we would have to get the buy in of our > library developers As one of the librarians, there are three current uses of invisible pins in the standard libs: a) Invisible power pins - especially the 74 series libs. This is not a behaviour that I like necessarily,

Re: [Kicad-developers] More wxformbuilder

I am curious too. - Kristoffer On 2017-02-07 22:06, Cirilo Bernardo wrote: Could you please elaborate on the specific problem with handling events? I prefer to learn what the problem was rather than to use another tool because it gives the desired results and without understanding why. -

Re: [Kicad-developers] [PATCH] Fix warp-to-nearest pad bug with T hotkey

We actually discussed this on IRC, it had a bug - I pushed a fixed version. Sorry, I should have replied here to say so. On Tue, Feb 07, 2017 at 11:18:42PM +0100, Maciej Suminski wrote: > Hi John, > > For the record, Chris has already committed your patch. Thank you both, > I am slowling

Re: [Kicad-developers] Pad import/export/push and modedit mirror

Thank you. 2017-02-07 23:24 GMT+01:00 Maciej Suminski : > Hi Nick, > > Thank you for the patches, I have just pushed them. I squeezed the two > patches that rename and regenerate bitmap data, I think they should go > together. > > Regards, > Orson > > On 02/04/2017 01:10

Re: [Kicad-developers] Pad import/export/push and modedit mirror

Hi Nick, Thank you for the patches, I have just pushed them. I squeezed the two patches that rename and regenerate bitmap data, I think they should go together. Regards, Orson On 02/04/2017 01:10 PM, Nick Østergaard wrote: > I have attached a patch that renames this. It contains three commits >

Re: [Kicad-developers] [PATCH] Fix warp-to-nearest pad bug with T hotkey

Hi John, For the record, Chris has already committed your patch. Thank you both, I am slowling crawling out of a stack of patches and e-mails, so I should check the remaining ones soon. I am sorry it takes so long. Cheers, Orosn On 02/06/2017 11:23 AM, John Beard wrote: > Hi, > > This patch

Re: [Kicad-developers] [PATCH] libedit: part deletion

Hi, On 02/07/2017 03:21 PM, Wayne Stambaugh wrote: > I committed this patch. Thanks Oliver. Please keep in mind when > submitting patches that fix bugs to include the bug report information > in the commit message. At a minimum, "Fixes: lp:##" is required. > It's also not a bad idea to

Re: [Kicad-developers] RFC: Arbitrary color support

Hi Jon, On 02/07/2017 04:03 AM, Jon Evans wrote: > Hi all, > > I started working on the idea of a color theme system for KiCad, starting > with the schematic editor. > > This change relies on a complete removal of EDA_COLOR_T from the code, and > replacement with a color structure that can

Re: [Kicad-developers] More wxformbuilder

Could you please elaborate on the specific problem with handling events? I prefer to learn what the problem was rather than to use another tool because it gives the desired results and without understanding why. - Cirilo On Wed, Feb 8, 2017 at 3:02 AM, jp charras wrote:

Re: [Kicad-developers] [RFC][PATCH] import pins from CSV

Importing a CSV file into component editor 1. Start kicad, launch component editor, create a new component 2. Click CSV button in top toolbar (far right) 3. When prompted for file, navigate to a csv file containing pins for import 4. Pins will be created in a vertical column with 100 mm spacing.

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

propably a bit offtopic: My experience with the hidden power pins was painful as I did not know about this "implicit global label" mechanics in the beginning. So I wondered why the ERC complained about interconnections betweens rails which I did not make/draw. This happend with parts I

Re: [Kicad-developers] [RFC][PATCH] import pins from CSV

This sounds like something I could use now. Do you have any documentation on 'how to use' ? I would also have to reinstate my toolchain to be able to use it - not insignificant amount of labor. By reading your doc, I could determine the cost/benefit at the moment. Thanks much - Bob G On

Re: [Kicad-developers] [PATCH] Display more information in component selector

No effect, the component selector just builds on top of this. Will push. Thank you On Tue, Feb 07, 2017 at 02:53:23PM -0500, Wayne Stambaugh wrote: > Chris, > > This looks good to me. Go ahead and commit it if there are not any > objections. Will this effect you new component selector dialog

Re: [Kicad-developers] [PATCH] Display more information in component selector

Chris, This looks good to me. Go ahead and commit it if there are not any objections. Will this effect you new component selector dialog patch? If so hold off committing it until I get a chance to review it. Thanks, Wayne On 2/5/2017 2:21 PM, Chris Pavlina wrote: > Hi, > > This patch adds

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

Keeping the current behavior is fine for users who want to use it. The connecting to invisible pins issue needs to be looked at. The real issue is the libraries. We have to decide if we want to make the effort to convert our symbols away from hidden power pins. I don't think it's a good idea

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

>> Invisible pin support has to be maintained. I'm guessing some users >> still prefer it and there are legacy designs which cannot be broken. Couldn't invisible pins become visible? As a transition make them grey or something? Just changing how they are displayed would not break any

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

On Tue, Feb 07, 2017 at 01:57:53PM -0500, Wayne Stambaugh wrote: > On 2/7/2017 1:15 PM, Andy Peters wrote: > > > >> On Feb 7, 2017, at 8:16 AM, Nox wrote: > >> > >> From a user point of perspective I would claim that the issue only raises > >> because there is the

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

On 2/7/2017 1:15 PM, Andy Peters wrote: > >> On Feb 7, 2017, at 8:16 AM, Nox wrote: >> >> From a user point of perspective I would claim that the issue only raises >> because there is the possibility to make pins invisible. Maybe someone can >> explain to me the

Re: [Kicad-developers] More wxformbuilder

On 2/7/2017 11:02 AM, jp charras wrote: > Le 07/02/2017 à 14:29, Chris Pavlina a écrit : >> Commit 43cb4560bfcf0624e9707c4c512cc3ccce385ce9 >> >> Rewrite code for PANEL_PREV_3D because the way events were previously >> managed are not compatible with a good mouse event management. >> To

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

> On Feb 7, 2017, at 8:16 AM, Nox wrote: > > From a user point of perspective I would claim that the issue only raises > because there is the possibility to make pins invisible. Maybe someone can > explain to me the semantically need of invisible pins in general

Re: [Kicad-developers] RFC: Arbitrary color support

I can think of a few ways to approach it: 1) Don't change how color works in the UI of pcbnew for now. Change to wxColour under the hood, but keep the current color selections -- no user visible change, no problems, but also no new feature in pcbnew GAL. 2) Allow using the new color picker in

Re: [Kicad-developers] RFC: Arbitrary color support

I'm not sure how you would prevent "bad" legacy colors from being selected without limiting the color selection in the gal canvas. If you can pull it off without the code limiting colors in gal, still be useful in legacy, and have a reasonable design than I'm OK with it. Given that we are

Re: [Kicad-developers] More wxformbuilder

Le 07/02/2017 à 14:29, Chris Pavlina a écrit : > Commit43cb4560bfcf0624e9707c4c512cc3ccce385ce9 > > Rewrite code for PANEL_PREV_3D because the way events were previously managed > are not compatible with a good mouse event management. > To avoid a lot of tedious code, wxFormbuilder is

Re: [Kicad-developers] More wxformbuilder

On 2/7/2017 8:29 AM, Chris Pavlina wrote: > Commit43cb4560bfcf0624e9707c4c512cc3ccce385ce9 > > Rewrite code for PANEL_PREV_3D because the way events were previously managed > are not compatible with a good mouse event management. > To avoid a lot of tedious code, wxFormbuilder is used to

[Kicad-developers] UI policy

Currently our UI policy says to follow the GNOME user interface guidelines. ...has anybody read the GNOME HIG lately? It's really different from anything we have now, and generally pretty controversial. I don't think it's what it was back when we decided to use it. Unless we really want to start

Re: [Kicad-developers] RFC: Arbitrary color support

Would you accept the patch to move to wxColour if it were not possible to choose "bad" colors in the the layout tool? It would be easy to restrict the colors to the current set in the pcb/footprint editors and just allow user selection in the schematic/symbol editors for now. On Tue, Feb 7, 2017

Re: [Kicad-developers] RFC: Arbitrary color support

On 2/7/2017 9:00 AM, Chris Pavlina wrote: > On Tue, Feb 07, 2017 at 08:57:23AM -0500, Jon Evans wrote: >> Hi Simon, JP, >> >> I understand the issue with the colors chosen for OR-mixing. I thought a >> good first step would be to set the framework for the future when that is >> no longer relevant

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

From a user point of perspective I would claim that the issue only raises because there is the possibility to make pins invisible. Maybe someone can explain to me the semantically need of invisible pins in general (beside the fact that kicad needs it to solve n pads: 1 pin and global label

Re: [Kicad-developers] [PATCH] libedit: part deletion

I committed this patch. Thanks Oliver. Please keep in mind when submitting patches that fix bugs to include the bug report information in the commit message. At a minimum, "Fixes: lp:##" is required. It's also not a bad idea to include the link to the bug report even though our commit hook

Re: [Kicad-developers] RFC: Arbitrary color support

Hi Simon, JP, I understand the issue with the colors chosen for OR-mixing. I thought a good first step would be to set the framework for the future when that is no longer relevant (i.e. when there is no legacy canvas anymore). It can be a "under the hood" change only in pcbnew, until the legacy

Re: [Kicad-developers] [PATCH] Show zero thickness lines in GAL

Merged. Thank you On Tue, Feb 07, 2017 at 09:30:53PM +0800, John Beard wrote: > Hi, > > Here is a patch to show zero-thickness lines in GAL using the "outline width". > > This addressess https://bugs.launchpad.net/kicad/+bug/1501749 > > Cheers, > > John

[Kicad-developers] [PATCH] Show zero thickness lines in GAL

Hi, Here is a patch to show zero-thickness lines in GAL using the "outline width". This addressess https://bugs.launchpad.net/kicad/+bug/1501749 Cheers, John From 60dfc34c70493bf05f77ecd4dca7594b46798c8e Mon Sep 17 00:00:00 2001 From: John Beard Date: Tue, 7 Feb 2017

[Kicad-developers] More wxformbuilder

Commit 43cb4560bfcf0624e9707c4c512cc3ccce385ce9 Rewrite code for PANEL_PREV_3D because the way events were previously managed are not compatible with a good mouse event management. To avoid a lot of tedious code, wxFormbuilder is used to create the PANEL_PREV_3D_BASE class. ...didn't we agree

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

Yes I understand, but proposing that changing the code for everyone using it to something more confusing isnt really a good solution to me. Its a work-around that will be defacto standard. Alternatives to changing the netlist generation: - Remove all invisible pins altogether - Make all

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

You do realize that symbols are made and used by different people, right? The person placing a symbol in the schematic DOESN'T KNOW that the dumbass library designer put a hidden pin in it. They just wonder why ERC is complaining about a connection somewhere where there is no pin (that they can

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

I think having a pins function changing depending on its relative position to other pins is more confusing, especially if it is toggled by a checkbox saying "visible". In that case a some kind of indication is better. Not changing the connectivity of the pin by hardcoded logic. It seems to

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

On Tue, Feb 07, 2017 at 01:15:43PM +0100, Kristoffer Ödmark wrote: > I think the aim then should be to inform about this. I see the "invisible" > checkbox as being just that, it makes the pins invisible, but still > connected. > > Shouldnt this be a warning issue for the ERC, connecting to an

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

I think the aim then should be to inform about this. I see the "invisible" checkbox as being just that, it makes the pins invisible, but still connected. Shouldnt this be a warning issue for the ERC, connecting to an invisible pin that is not stacked? And as you said, you had to clean out

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

I wasnt saying its a good idea, but having invisible pins indicates that you want to connect to something that is not visible, its literaly there in the name. An invisible pin. I mean, otherwise there could be a stacked pin instead. Im not saying that invisible pins are good practise, but

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

Honestly I think that's one of the silliest things I've ever heard. Pins that you can't see should make connections that you can't see to wires that you can? The ONLY imaginable use case for this is stacks of pins. Every other possible case is a mistake. On Tue, Feb 07, 2017 at 11:09:44AM +0100,

Re: [Kicad-developers] RFC: Arbitrary color support

Let people choose. Have the default colors be wxDC-friendly. Trust me, nobody is choosing to work with eight-layer boards in legacy. On Tue, Feb 07, 2017 at 09:01:10AM +0100, jp charras wrote: > Le 07/02/2017 à 06:31, Simon Wells a écrit : > > i thought this wasn't possible due to wxDC

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

Honestly I think the invisible pins are supposed to work exactly as they are, that they should be able to connect, otherwise there are the "no connect" - pin type or the option of just removing the pin from the symbol altogether. - Kristoffer On 02/07/2017 10:02 AM, Oliver Walters wrote:

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

Perhaps this is a solution to that problem: If an invisible pin shares a net name and a position with a visible pin, it gets connected? That way the current "hack" for connecting multiple pins will still work. On 7 Feb 2017 19:57, "Kristoffer Ödmark" wrote: >

Re: [Kicad-developers] [PATCH] Delete whole tracks in GAL

The first of these patches has a mistake in the selection code, which used to clear the selection and replace it, and should now augment, not replace. Please use the attached patches instead. Thanks, John On Mon, Feb 6, 2017 at 12:37 AM, John Beard wrote: > Apparently

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

Kristoffer this is good feedback. I did not expect this to get pushed straight away, and perhaps there is a way forward that won't break schematics. Relying on implicit connected that is *not* displayed on the schematic seems like a very bad idea to me. I appreciate your use case (I currently

Re: [Kicad-developers] [PATCH] eeschema: invisible pin connection

This seems dangerous, I have seen a few design where there are 5-10 pins hidden under the same pin, excpecting them to be connected. I would rather this hidden connections were indicated in some way, this change disconnects lines and might break some users footprints-symbols connection. -

[Kicad-developers] [PATCH] eeschema: invisible pin connection

Hi all, The attached patch prevents invisible pins from being connected using the wire tool in eeschema. a) If you connect a wire endpoint to the same position as a pin endpoint, they are NOT connected visually b) Wires and insivible pins are also ignored during netlist creation c) This does not

Re: [Kicad-developers] RFC: Arbitrary color support

Le 07/02/2017 à 06:31, Simon Wells a écrit : > i thought this wasn't possible due to wxDC limitations Exactly, wxDC does not have a transparency feature to draw items. In this case, when you want to draw board layers with a transparency effect, the only one other way to do that is to use logic