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 component
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 comme
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
https://code.launchpad.net/~john-j-beard/kicad/+git
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
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
wrote:
> I sugge
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 "Pcbnew",
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 star
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 in
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 the selection and replace
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
>
> 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 Walte
>
> 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,
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.
- Ciril
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 crawling
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 PM, Nick Østergaard wrote:
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
>
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 fix
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 incl
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 handl
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:
> Le 07/02/2017 à 14:29,
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. G
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 created
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 02
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 pa
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 mo
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 to
>> 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 designs.
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 possibility to make pins invisi
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 semantically need of invisible p
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 avoi
> 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 (beside the
> fact that kicad
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 GA
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 nearing
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 use
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
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 m
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
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
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 issu
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 s
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 (i.e. when there is no legacy canvas anymore).
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
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
__
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 18:21:26 +0800
Subject: [P
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
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 no-con
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 see
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 m
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 invi
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 pa
On Tue, Feb 07, 2017 at 12:44:45PM +0100, Kristoffer Ödmark wrote:
> 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 have seen numerous parts made by people who cl
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 that
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, K
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 limitations
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:
Kr
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:
> This seems dangerous, I have seen
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 those patches don't apply
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 hav
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.
- Kr
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
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 c
61 matches
Mail list logo
