[Kicad-developers] Footprint properties: Normal, Normal+Insert

[Chris Pavlina]

Can we rename "Normal" and "Normal+Insert" to "THT" and "SMT", or
"Through hole" and "Surface mount", or something similarly descriptive?
I *still* have to mouse over for the tooltip to remember which is
which...

-- 
Chris


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

[Kicad-developers] PCB forward compatibility

[Chris Pavlina]

The addition of (diff_pair_gap) and (diff_pair_width) has made it such
that NO PCBs made with 'master' builds can now be loaded in the 4.0
branch. Would a patch be accepted to do one of the following, to be
added to the 4.0 branch to ease future conversion from 4 to 5?

1. Fully backport saving diff pair dimensions to v4, but only write them
   to the file if they already existed in it at load. This way, v4
   writes files compatible with older v4 by default, but if editing a
   v5 file will not lose the data.

or:
2. Specifically ignore these options on load, since dropping them
   doesn't actually lose any PCB objects.

or:
3. Update the version number checker code I wrote before to have both
   Warnings and Errors, using Warnings when ignoring the unknown object
   and loading the board anyway will not lead to "important" data loss.
   Add these attributes to a list of unknown objects that generate
   Warnings.

I'm partial to #3. I'd be partial to #1 if I had more time on my hands,
but I'm not sure how much work it would be to backport. I can look into
doing it, but might have to fall back on #3.

-- 
Chris

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

Re: [Kicad-developers] Footprint properties: Normal, Normal+Insert

[Chris Pavlina]

Oh, good catch, thanks! Fixed.

On Thu, Dec 15, 2016 at 08:38:18PM +0100, easyw wrote:
> those terms should also be aligned in:
> 3d-viewer/3d_viewer/eda_3d_viewer.cpp
> 3d-viewer/3d_viewer/3d_toolbar.cpp
> 
> M
> 
> On 12/14/2016 8:51 PM, Chris Pavlina wrote:
> >Can we rename "Normal" and "Normal+Insert" to "THT" and "SMT", or
> >"Through hole" and "Surface mount", or something similarly descriptive?
> >I *still* have to mouse over for the tooltip to remember which is
> >which...
> >
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] PCB forward compatibility

[Chris Pavlina]

On Fri, Dec 16, 2016 at 07:55:20AM -0500, Wayne Stambaugh wrote:
> On 12/16/2016 6:03 AM, Tomasz Wlostowski wrote:
> > On 15.12.2016 20:02, Chris Pavlina wrote:
> >> The addition of (diff_pair_gap) and (diff_pair_width) has made it such
> >> that NO PCBs made with 'master' builds can now be loaded in the 4.0
> >> branch. Would a patch be accepted to do one of the following, to be
> >> added to the 4.0 branch to ease future conversion from 4 to 5?
> >>
> >> 1. Fully backport saving diff pair dimensions to v4, but only write them
> >>to the file if they already existed in it at load. This way, v4
> >>writes files compatible with older v4 by default, but if editing a
> >>v5 file will not lose the data.
> >>
> >> or:
> >> 2. Specifically ignore these options on load, since dropping them
> >>doesn't actually lose any PCB objects.
> >>
> >> or:
> >> 3. Update the version number checker code I wrote before to have both
> >>Warnings and Errors, using Warnings when ignoring the unknown object
> >>and loading the board anyway will not lead to "important" data loss.
> >>Add these attributes to a list of unknown objects that generate
> >>Warnings.
> > 
> > How about adding an additional section in the .pcb/.sch files describing
> > all objects used together with required versions and their descriptions,
> > e.g:
> > 
> > (object-info
> > 
> > (object "diff_pair_gap" ( minimum_version 4 ) ( severity warning )
> > (message "This file contains differential pair gap settings that come
> > with  version of Kicad. Older versions will not respect the defined
> > gap settings ) )
> > 
> > (object "fancy_geom_shape" ( minimum_version 12345 ) ( severity error )
> > 
> > )
> 
> I against polluting the board file format with this kind of information.
>  Any attempt to provide forward compatibility would require a complete
> change in the project philosophy.  We have always worked under the
> notion that backwards capability is a must.  Forward compatibility is
> something we would not provide due to the effort required to maintain
> it.  Given that KiCad has zero cost to the user, the need to provide
> forward compatibility is low.
> 
> As for the diff pair parameter issue, why not have an undefined value
> which doesn't get written unless it is set by the user.  If the user
> isn't using diff pairs, just don't write the diff pair parameter to the
> board file.  This should be simple and much easier to maintain.

I think that's acceptable. I'm not necessarily in favor of strict
forward compatiblity at all times, I just don't like that we took the
step of breaking ALL boards even if they don't use a feature.

I can make a patch to do that this weekend.

I'm not so much against listing version information for attributes, I
think it's a good step to take and has been proposed many times -
however what I really want here is something quick that can go into the
v4 branch so people aren't hit by this in the transition to v5. Tom's
suggestion is more complicated, and I'm not sure it's right for
backporting to v4. We could discuss implementing it in v5 going forward
for v6 though.

> 
> > 
> > Cheers,
> > Tom
> > 
> > 
> > 
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

[Kicad-developers] Our awful error messages

[Chris Pavlina]

There's another little project I'd like to work on in the month or so I
have off now:

https://misc.c4757p.com/outline-error.png

We have way too many error messages like that. That is, in my opinion,
completely unacceptable. It's confusing and intimidating to anyone
unfamiliar with kicad's... unique style of error reporting.

1. We should NOT say things like "from specctra_export.cpp :
fillBOUNDARY() line:1165". Who needs that? Users certainly do not.
Developers can attach a debugger and backtrace to see where the message
is from. Developers reading bug reports can grep the source for the
error text.

2. Similarly, we should NOT say things like "IO_ERROR". First of all
it's wrong, that is not an IO error, we need more exception classes.
Second of all what sort of user cares which internal exception class
triggered an error message??

3. Broken English. "Therefore use the board boundary box."? Come on.

Is anybody going to protest removing the silly dev information from the
error messages?

-- 
Chris

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

[Kicad-developers] Page settings in edit menu

[Chris Pavlina]

Can we put Page Settings back in the File menu where it was prior to
de46873? That's where it is in every other application I have ever used.

-- 
Chris

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

Re: [Kicad-developers] .SWEET file suggestion

[Chris Pavlina]

I second this suggestion. Numerous people have been proposing this for
quite a long time in IRC, it's a popular idea. A large number of parts
are configurable, and forcing the pins to be non-configurable makes ERC
pretty weak.

On Wed, Jan 04, 2017 at 07:22:37PM +1100, Oliver Walters wrote:
> As far as I am aware, this (
> https://lists.launchpad.net/kicad-developers/msg23302.html) is the latest
> proposal for the new symbol format.
> 
> Is this the case?
> 
> Reading through this I have an idea that I think will be very useful.
> 
> Currently each PIN can only have one TYPE (INPUT, OUTPUT, OPEN-COLLECTOR,
> etc) which means that for parts with multiple alternate-functions on a pin,
> ERC is essentially useless if the pin can be used as an INPUT or an OUTPUT
> (or something else).
> 
> Further, labelling all the possible alternate functions on a pin means that
> either the symbol grows exceedingly wide, or many functions are missed.
> 
> I suggest that the pin type should have facility for alternate functions to
> be specified which would solve both of these problems. Once a symbol is
> placed in the schematic, any multi-function pins are set to "default"
> values (e.g. GPIO for a micro) but the other functions can be selected.
> 
> See proposed "addition" to format here:
> 
> http://i.imgur.com/5m38eTT.png
> 
> Cheers,
> Oliver


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

Re: [Kicad-developers] [PATCH] Pcbnew, plot dialog: grey out advanced net attributes if Gerber X2 is unchecked.

[Chris Pavlina]

Looks good to me, I pushed it. Thank you for your contribution to KiCad.

It's easy for patches to slip through the cracks - in the future, don't
be afraid to bump a patch a bit sooner, say within a week or two.
Apologies for losing it.

On Wed, Jan 04, 2017 at 07:45:40PM +, Diego Herranz wrote:
> Hi,
> 
> Did anyone have a chance to look at this?
> 
> Many thanks.
> 
> Regards,
> Diego
> 
> On Tue, Nov 22, 2016 at 8:10 AM, Diego Herranz <
> diegoherr...@diegoherranz.com> wrote:
> 
> >
> > m_useGerberNetAttributes is useless if m_useGerberX2Attributes is not
> > checked.
> > So disabled (greyed out) when Gerber X2 gets unchecked to make it clear to
> > the user.
> > ---
> >  pcbnew/dialogs/dialog_plot.cpp  | 20 
> >  pcbnew/dialogs/dialog_plot.h|  3 ++-
> >  pcbnew/dialogs/dialog_plot_base.cpp |  4 +++-
> >  pcbnew/dialogs/dialog_plot_base.fbp |  2 +-
> >  pcbnew/dialogs/dialog_plot_base.h   |  3 ++-
> >  5 files changed, 28 insertions(+), 4 deletions(-)
> >
> >


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

[Kicad-developers] Commit messages

[Chris Pavlina]

Hey, I don't mean to be too obnoxious of a stickler, but can we work on
our commit messages just a bit? There are three things I'd really like
to see improved:

1. No vague messages like:
- 8e11d9b: very minor change.

Better: Realign comments

- 995940e: refinement

Better: Clean up qrcode_footprint_wizard

2. Shorter first line, for easier skimming of logs:
- 02fa963: DIALOG_FOOTPRINT_WIZARD_LIST: minor enhancement.
  qrcode_footprint_wizard.py: use filled polygons instead of square
  pads on silkscren layer.

Better as two commits:
- Add number column to DIALOG_FOOTPRINT_WIZARD_LIST
- Use filled polygons in *.SilkS in qrcode_footprint_wizard

3. Along similar lines, move the "Fixes: lp:nnn" to the next line:
- c45cc1d: Fixes: lp:1653146 (Assertion failed when trying to delete
  track with router tool active, in debug mode)

Better:
Fix assertion failure deleting track with router active

Fixes: lp:1653146
https://bugs.launchpad.net/kicad/+bug/1653146

I really don't want to single out any individuals in particular; these
were just the most readily available examples. It does get annoying when
reading logs though. Can we all try to agree to improve this?

-- 
Chris

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

Re: [Kicad-developers] [PATCH] Pcbnew, plot dialog: grey out advanced net attributes if Gerber X2 is unchecked.

[Chris Pavlina]

Okay, thanks for letting me know. If this was policy, I forgot about it.

Do you want me to rework the patch to use wxUpdateUIEvent?

On Thu, Jan 05, 2017 at 08:57:14AM -0500, Wayne Stambaugh wrote:
> Thanks Chris.  In the future, please make sure that contributions use
> wxUpdateUIEvent for updating UI states.  A single code path for updating
> UI element states prevents potential state conflicts when setting the
> state in multiple wxCommandEvents.  We have had issues with this in the
> past where a UI element state would get toggled in one command event and
> toggled again in a different command event causing the UI element state
> to be incorrect.
> 
> Cheers,
> 
> Wayne
> 
> On 1/4/2017 5:18 PM, Chris Pavlina wrote:
> > Looks good to me, I pushed it. Thank you for your contribution to KiCad.
> > 
> > It's easy for patches to slip through the cracks - in the future, don't
> > be afraid to bump a patch a bit sooner, say within a week or two.
> > Apologies for losing it.
> > 
> > On Wed, Jan 04, 2017 at 07:45:40PM +, Diego Herranz wrote:
> >> Hi,
> >>
> >> Did anyone have a chance to look at this?
> >>
> >> Many thanks.
> >>
> >> Regards,
> >> Diego
> >>
> >> On Tue, Nov 22, 2016 at 8:10 AM, Diego Herranz <
> >> diegoherr...@diegoherranz.com> wrote:
> >>
> >>>
> >>> m_useGerberNetAttributes is useless if m_useGerberX2Attributes is not
> >>> checked.
> >>> So disabled (greyed out) when Gerber X2 gets unchecked to make it clear to
> >>> the user.
> >>> ---
> >>>  pcbnew/dialogs/dialog_plot.cpp  | 20 
> >>>  pcbnew/dialogs/dialog_plot.h|  3 ++-
> >>>  pcbnew/dialogs/dialog_plot_base.cpp |  4 +++-
> >>>  pcbnew/dialogs/dialog_plot_base.fbp |  2 +-
> >>>  pcbnew/dialogs/dialog_plot_base.h   |  3 ++-
> >>>  5 files changed, 28 insertions(+), 4 deletions(-)
> >>>
> >>>
> > 
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Current state of ActionPlugin

[Chris Pavlina]

Frankly I don't think we should be encouraging users to use the Python API
until it is significantly improved. The issues JP raises make the API
completely unsuitable for plugin use. It's opaque and no users have any
idea how to write robust Python plugins given the current state of the API.

On Jan 10, 2017 09:55, "jp charras"  wrote:

Le 10/01/2017 à 15:18, Maciej Sumiński a écrit :
> Hi Jean-Samuel,
>
> I think your patch will facilitate use of 3rd party python plugins, as
> the current way of executing commands from the Python shell is not quite
> user friendly. I vote for merging the patch, but we need to fix some
> code formatting issues first.
>
> Also, I wonder if it would be the right thing to group menu entries by
> their categories to create submenus. It could be a simple way to
> organize the actions provided by python plugins. Just an idea.
>
> Another question is about the following lines:
> +if( IsGalCanvasActive() )
> +{
> +UseGalCanvas( GetGalCanvas() );
> +}
>
> What is exactly the goal here? If it is only about refreshing the
> canvas, then a simple Refresh() call should fix the problem.
>
> Regards,
> Orson
>

This is a good work.
Thanks Jean-Samuel.

However, before merging we have to take care of issues which can easily
crash Pcbnew:
Because a python script can modify the board outside the control of pcbnew
edit functions, I am
thinking problems will arise with undo/redo lists (invalid pointers),
ratsnest data and certainly a
few other things.

Especially for scripts which add or delete items, or change connectivity.

Of course, undo/redo lists are alway incorrect after running such scripts.
This is already a known issue for scripts that are run from the Pcbnew
python console.

--
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] Current state of ActionPlugin

[Chris Pavlina]

What do you do when the internal APIs change and the plugins stop
working?

I think encouraging people to use this is very dangerous. It is tied so
much into our internal APIs at the moment. The more people who use it,
the more everybody is going to scream every single time we change
anything. We have so much poorly structured code that needs to be
rewritten - I'm sure a lot of it *will* be when it comes time to remove
the legacy canvas. If we end up with this many users of the scripting
API, we will never be able to touch anything again without breaking
everything.

Wayne, JP: I'm making an appeal to you now to be conservative with
what you accept for use with the scripting API. This would be a very bad
point to lock ourselves into having to stabilize it as is. I do not
think we should be doing this until an interposing layer with a
formalized, stable API can be created.

On Tue, Jan 10, 2017 at 04:25:10PM +0100, Jean-Samuel Reynaud wrote:
> Hi,
> 
> Just from my point of view:
>  We use some python plugin currently and it's not really easy to open
> each time python console (and remember plugins name, call mode...).
> 
>  I'm agree with you: During devs of scripts it's crashing and my devs
> have to find the rigth way to process.
> 
>  But this kind of feature can increase number of users/devs of this kind
> of scripts and raise crash case easily.
> 
> Regards,
> Le 10/01/2017 à 16:00, Chris Pavlina a écrit :
> > Frankly I don't think we should be encouraging users to use the Python
> > API until it is significantly improved. The issues JP raises make the
> > API completely unsuitable for plugin use. It's opaque and no users have
> > any idea how to write robust Python plugins given the current state of
> > the API.
> > 
> > On Jan 10, 2017 09:55, "jp charras"  > <mailto:jp.char...@wanadoo.fr>> wrote:
> > 
> > Le 10/01/2017 à 15:18, Maciej Sumiński a écrit :
> > > Hi Jean-Samuel,
> > >
> > > I think your patch will facilitate use of 3rd party python plugins, as
> > > the current way of executing commands from the Python shell is not
> > quite
> > > user friendly. I vote for merging the patch, but we need to fix some
> > > code formatting issues first.
> > >
> > > Also, I wonder if it would be the right thing to group menu entries by
> > > their categories to create submenus. It could be a simple way to
> > > organize the actions provided by python plugins. Just an idea.
> > >
> > > Another question is about the following lines:
> > > +if( IsGalCanvasActive() )
> > > +{
> > > +UseGalCanvas( GetGalCanvas() );
> > > +}
> > >
> > > What is exactly the goal here? If it is only about refreshing the
> > > canvas, then a simple Refresh() call should fix the problem.
> > >
> > > Regards,
> > > Orson
> > >
> > 
> > This is a good work.
> > Thanks Jean-Samuel.
> > 
> > However, before merging we have to take care of issues which can
> > easily crash Pcbnew:
> > Because a python script can modify the board outside the control of
> > pcbnew edit functions, I am
> > thinking problems will arise with undo/redo lists (invalid
> > pointers), ratsnest data and certainly a
> > few other things.
> > 
> > Especially for scripts which add or delete items, or change
> > connectivity.
> > 
> > Of course, undo/redo lists are alway incorrect after running such
> > scripts.
> > This is already a known issue for scripts that are run from the
> > Pcbnew python console.
> > 
> > --
> > Jean-Pierre CHARRAS
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > <https://launchpad.net/~kicad-developers>
> > Post to : kicad-developers@lists.launchpad.net
> > <mailto:kicad-developers@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > <https://launchpad.net/~kicad-developers>
> > More help   : https://help.launchpad.net/ListHelp
> > <https://help.launchpad.net/ListHelp>
> > 
> > 
> > 
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Current state of ActionPlugin

[Chris Pavlina]

On Tue, Jan 10, 2017 at 05:12:56PM +0100, Jean-Samuel Reynaud wrote:
> 
> 
> Ok I understand, but Is it mean that we have to disable python scripting
> in all build by default ?

I can't make that call and I don't think it will be made. I do think we
shouldn't be encouraging *more* use of it at this point, though.

> 
> On daily build I manage, its activated by default...
> 
> On my side I will modify all plugin I use if the API change. They are
> based on a dev branch so I accept that.

You are much more capable of this than most people, I think. My concerns
are not specifically about you. I'm sure you find this feature useful;
that doesn't mean it's for full inclusion in KiCad proper.

> 
> An other point is that master branch is a *dev* branch ? So modification
> on file format, API... can happen.

...what?

> 
> Regards,
> Le 10/01/2017 à 16:54, Chris Pavlina a écrit :
> > What do you do when the internal APIs change and the plugins stop
> > working?
> > 
> > I think encouraging people to use this is very dangerous. It is tied so
> > much into our internal APIs at the moment. The more people who use it,
> > the more everybody is going to scream every single time we change
> > anything. We have so much poorly structured code that needs to be
> > rewritten - I'm sure a lot of it *will* be when it comes time to remove
> > the legacy canvas. If we end up with this many users of the scripting
> > API, we will never be able to touch anything again without breaking
> > everything.
> > 
> > Wayne, JP: I'm making an appeal to you now to be conservative with
> > what you accept for use with the scripting API. This would be a very bad
> > point to lock ourselves into having to stabilize it as is. I do not
> > think we should be doing this until an interposing layer with a
> > formalized, stable API can be created.
> > 
> > On Tue, Jan 10, 2017 at 04:25:10PM +0100, Jean-Samuel Reynaud wrote:
> >> Hi,
> >>
> >> Just from my point of view:
> >>  We use some python plugin currently and it's not really easy to open
> >> each time python console (and remember plugins name, call mode...).
> >>
> >>  I'm agree with you: During devs of scripts it's crashing and my devs
> >> have to find the rigth way to process.
> >>
> >>  But this kind of feature can increase number of users/devs of this kind
> >> of scripts and raise crash case easily.
> >>
> >> Regards,
> >> Le 10/01/2017 à 16:00, Chris Pavlina a écrit :
> >>> Frankly I don't think we should be encouraging users to use the Python
> >>> API until it is significantly improved. The issues JP raises make the
> >>> API completely unsuitable for plugin use. It's opaque and no users have
> >>> any idea how to write robust Python plugins given the current state of
> >>> the API.
> >>>
> >>> On Jan 10, 2017 09:55, "jp charras"  >>> <mailto:jp.char...@wanadoo.fr>> wrote:
> >>>
> >>> Le 10/01/2017 à 15:18, Maciej Sumiński a écrit :
> >>> > Hi Jean-Samuel,
> >>> >
> >>> > I think your patch will facilitate use of 3rd party python plugins, 
> >>> as
> >>> > the current way of executing commands from the Python shell is not
> >>> quite
> >>> > user friendly. I vote for merging the patch, but we need to fix some
> >>> > code formatting issues first.
> >>> >
> >>> > Also, I wonder if it would be the right thing to group menu entries 
> >>> by
> >>> > their categories to create submenus. It could be a simple way to
> >>> > organize the actions provided by python plugins. Just an idea.
> >>> >
> >>> > Another question is about the following lines:
> >>> > +if( IsGalCanvasActive() )
> >>> > +{
> >>> > +UseGalCanvas( GetGalCanvas() );
> >>> > +}
> >>> >
> >>> > What is exactly the goal here? If it is only about refreshing the
> >>> > canvas, then a simple Refresh() call should fix the problem.
> >>> >
> >>> > Regards,
> >>> > Orson
> >>> >
> >>>
> >>> This is a good work.
> >>> Thanks Jean-Samuel.
> >>>
> >>> However, b

Re: [Kicad-developers] Current state of ActionPlugin

[Chris Pavlina]

On Tue, Jan 10, 2017 at 05:50:02PM +0100, Jean-Samuel Reynaud wrote:
> > I'm sure you find this feature useful;
> > that doesn't mean it's for full inclusion in KiCad proper.
> Yes, many users of KiCad here on my side are waiting for a simpler use
> of script we use internally. Anyway I understand your position.

Making it simpler to use *these* scripts is putting the cart before the
horse, in a very dangerous way. Scripting needs to be fixed before we
encourage its use.

> 
> > 
> >>
> >> An other point is that master branch is a *dev* branch ? So modification
> >> on file format, API... can happen.
> > 
> > ...what?
> > 
> I mean that git master branch is for dev of new features. Those features
> are not necessary stable so it's logical that, for example, API for
> python will change in the future.

...er, master branch will become the new stable, you do realize we have
to keep that in mind?

> 
> 
> 

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

[Kicad-developers] Revert 9bc2bb2 "Fixed a VIEW_ITEM memory leak"

[Chris Pavlina]

I reverted commit 9bc2bb2 "Fixed a VIEW_ITEM memory leak", which caused
a segfault:

https://bugs.launchpad.net/kicad/+bug/1656481

Maybe we should be using smart pointers in these data structures... ;)

-- 
Chris

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

[Kicad-developers] Cosmetically enhancing the cosmetic enhancement

[Chris Pavlina]

This looks bad:

https://misc.c4757p.com/ugly.png

Really bad. Three of the same icon, with low enough contrast that I can
barely tell what it's a picture of... and seriously, prepending "** " to
mark the selected item? Really? Even text-mode applications that are
stuck doing things like that usually think to space over the deselected
ones too so everything still lines up...

If I prepared a patch to ditch the icon and display option buttons next
to those instead, would it be argued against?

-- 
Chris


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

Re: [Kicad-developers] Cosmetically enhancing the cosmetic enhancement

[Chris Pavlina]

That's what I think I'll have to do.

It can be annoying to have to fit within the GUI paradigm of all three
OSes... What I'd /really/ like is something that looks like this, with a
header:

 +--+
 | Canvas type  |
 |  |
 | ( )  Legacy  |
 | (O)  OpenGL  |
 | ( )  Cairo   |
 +--+

But I can't make that look good on OSX :((


On Sat, Jan 14, 2017 at 03:44:21PM +0100, Nick Østergaard wrote:
> I think that menu is a bit strange. Why not ditch the icon's for those
> canvas options and just a checkmark as used in the language menu?
> 
> 2017-01-14 15:35 GMT+01:00 Chris Pavlina :
> > This looks bad:
> >
> > https://misc.c4757p.com/ugly.png
> >
> > Really bad. Three of the same icon, with low enough contrast that I can
> > barely tell what it's a picture of... and seriously, prepending "** " to
> > mark the selected item? Really? Even text-mode applications that are
> > stuck doing things like that usually think to space over the deselected
> > ones too so everything still lines up...
> >
> > If I prepared a patch to ditch the icon and display option buttons next
> > to those instead, would it be argued against?
> >
> > --
> > Chris
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Cosmetically enhancing the cosmetic enhancement

[Chris Pavlina]

No. That serves the functional purpose, but not the aesthetic one. A
disabled menu item conveys to the user that it is not available for use,
so disabling the currently active item says exactly the opposite of what
it should: not "OpenGL is currently in use, so you can't switch to it"
but rather "OpenGL is unavailable for you to use".

An acceptable solution fulfills *both* purposes: it only allows the user
to make valid selections, and explains to the user what those selections
actually are.

On Sat, Jan 14, 2017 at 05:42:51PM +0200, Константин Барановский wrote:
> As variant, we may just disable menu entry for currently selected canvas.
> 
> 2017-01-14 16:51 GMT+02:00 Chris Pavlina :
> 
> > That's what I think I'll have to do.
> >
> > It can be annoying to have to fit within the GUI paradigm of all three
> > OSes... What I'd /really/ like is something that looks like this, with a
> > header:
> >
> >  +--+
> >  | Canvas type  |
> >  |  |
> >  | ( )  Legacy  |
> >  | (O)  OpenGL  |
> >  | ( )  Cairo   |
> >  +--+
> >
> > But I can't make that look good on OSX :((
> >
> >
> > On Sat, Jan 14, 2017 at 03:44:21PM +0100, Nick Østergaard wrote:
> > > I think that menu is a bit strange. Why not ditch the icon's for those
> > > canvas options and just a checkmark as used in the language menu?
> > >
> > > 2017-01-14 15:35 GMT+01:00 Chris Pavlina :
> > > > This looks bad:
> > > >
> > > > https://misc.c4757p.com/ugly.png
> > > >
> > > > Really bad. Three of the same icon, with low enough contrast that I can
> > > > barely tell what it's a picture of... and seriously, prepending "** "
> > to
> > > > mark the selected item? Really? Even text-mode applications that are
> > > > stuck doing things like that usually think to space over the deselected
> > > > ones too so everything still lines up...
> > > >
> > > > If I prepared a patch to ditch the icon and display option buttons next
> > > > to those instead, would it be argued against?
> > > >
> > > > --
> > > > Chris
> > > >
> > > >
> > > > ___
> > > > Mailing list: https://launchpad.net/~kicad-developers
> > > > Post to : kicad-developers@lists.launchpad.net
> > > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > > More help   : https://help.launchpad.net/ListHelp
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >

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

Re: [Kicad-developers] OT: Re: Cosmetically enhancing the cosmetic enhancement

[Chris Pavlina]

I agree that needing to switch canvases is bad. Unfortunately I really
do not think your idea is feasible.

On Sat, Jan 14, 2017 at 08:49:25PM +0100, Clemens Koller wrote:
> Sorry for trolling a bit, but...
> 
> On 2017-01-14 15:35, Chris Pavlina wrote:
> > This looks bad:
> > 
> > https://misc.c4757p.com/ugly.png
> > 
> > Really bad.
> 
> ...the need to switch canvases is the really bad thing - IMO.
> 
> Some non-programmers might not even know what OpenGL or Cairo is. And why do 
> they need to switch to ... what? There is no clear overview which functions 
> are available in which graphical backend included.
> 
> Is it possible - before we can eliminate the different backends - to switch 
> the canvases automatically depending on the function we want to execute? It's 
> like using macros with KiCAD - i.e. just send out a F11 keypress when you 
> start P&S routing. Can we just "fake" the three options away until we get the 
> legacy stuff cleaned up? Who really wants and needs to deal with canvases 
> while designing a PCB?
> 
> Regards,
> 
> Clemens
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Raytracing engine not displaying board from bottom orthogonal projection

[Chris Pavlina]

In the future, you should probably send only plain text mails to this
mailing list. My client is having trouble viewing your signed message;
I'm probably not the only one. Looks like gmail's web client doesn't
show it either.

On Sun, Jan 15, 2017 at 03:09:24PM -0500, Edward Johns wrote:


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

Re: [Kicad-developers] FW: Raytracing engine not displaying board from bottom orthogonal projection

[Chris Pavlina]

Pushed. Thank you

On Wed, Jan 18, 2017 at 10:49:02PM +, Mário Luzeiro wrote:
> Hello all,
> 
> Attached is a fix for the issue described by Edward. It also fixes another 
> precision issue (or bug) while rendering on some angles while using the 
> orthogonal projection.
> 
> Thanks Edward for using the 3Dviewer, hope you can share any cool renders 
> with the community.
> Let me know if you have any (very simple for me) suggestions or ideas that I 
> can improve it more..
> 
> Mario Luzeiro
> 
> -Original Message-
> From: Edward Johns [mailto:edwardgjoh...@gmail.com]
> Sent: Sunday, January 15, 2017 3:09 PM
> To: kicad-developers@lists.launchpad.net
> Subject: Raytracing engine not displaying board from bottom orthogonal
> projection
> 
> Hi, all.
> 
> I think I found a corner case related to the raytracing engine.  When
> viewing the board from the bottom using orthogonal projection, the board
> disappears and only some components that extend beyond the board outline are
> visible.  If you manually rotate even by a miniscule amount, the
> visualization is fixed.
> 
> On a side note, I use the product branch for design, but the development for
> modeling.  The 3d visualizations are getting to be pretty awesome.
> 
> Thanks and have a good one.
> 
> -Ed


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

[Kicad-developers] Diff pair length tuning is weird

[Chris Pavlina]

Uh...subject says it all. I very frequently get things like this when
using differential pair length tuning. Are these known bugs? I'm
constantly fighting with it.

https://misc.c4757p.com/diff-pair-length-tuning-potato.png


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

Re: [Kicad-developers] Diff pair length tuning is weird

[Chris Pavlina]

Unfortunately it looks like it would take me more time than I have to
learn the workings of that code :(

On Fri, Jan 20, 2017 at 05:06:29PM +0100, Tomasz Wlostowski wrote:
> On 20.01.2017 13:52, Chris Pavlina wrote:
> > Uh...subject says it all. I very frequently get things like this when
> > using differential pair length tuning. Are these known bugs? I'm
> > constantly fighting with it.
> > 
> > https://misc.c4757p.com/diff-pair-length-tuning-potato.png
> 
> Hi Chris,
> 
> I'm aware of this bug, we need more restrictive check of the
> combinations of meander amplitude and spacing vs trace width and gap. I
> can't work on this for the moment. If you want to, you could probably
> sanitize the amplitude/spacing parameters directly in
> PNS::DP_MEANDER_PLACER::Move() function.
> 
> Cheers,
> Tom
> 
> > 
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 

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

Re: [Kicad-developers] Improvements on reflection and refraction

[Chris Pavlina]

The code looks good, and the renders look even better. I'm going to
merge this. Thank you!

Old: https://misc.c4757p.com/graphics-card-hdmi.png
New: https://misc.c4757p.com/graphics-card-hdmi-new-reflections.png

Much more subtle and realistic. :)

On Sat, Jan 21, 2017 at 01:36:52PM +, Mário Luzeiro wrote:
> Hi all,
> 
> Attached is a patch that fixes some issues and improves the reflection and 
> refraction on 3D-viewer raytracing.
> Hope you can merge it.
> 
> This followed the critics sent by Chris Pavlina and Marcos Chaparro.
> Thanks for the feedback!
> 
> Mario Luzeiro


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

Re: [Kicad-developers] [PATCH] Make doc extension (pdf) are not case sensitive.

[Chris Pavlina]

Merged, thank you.

On Sun, Jan 22, 2017 at 04:45:31PM +0200, Константин Барановский wrote:
> By default in Linux, KiCad opens pdf-files in GIMP (on my system), so I
> setup it to open pdf with another app and it works if extension of the doc
> in lower case (pdf). But if extension in upper case (PDF), KiCad still
> opens it in GIMP.
> In attachment the patch that resolves this issue.


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

Re: [Kicad-developers] [PATCH] Tidy consts in D_PAD

[Chris Pavlina]

Merged. Thank you.

On Sun, Jan 22, 2017 at 06:32:52AM +0800, John Beard wrote:
> Hi,
> 
> There are a few accessors in D_PAD that could do with const qualifiers.
> 
> Also a few functions return non-POD objects by const value. This
> doesn't actually acheive anything, except forcing the compiler to
> forgo move operations and use copies instead, which is just less
> efficient. It doesn't actually convey any meaning about the data
> itself (the calling code is the one to decide if it wants to call its
> newly copied/moved object "const" or not). If the functions returned
> const ref or const pointer, then it would have meaning.
> 
> I didn't change them all, as some are overrides that are part of a
> larger inheriance hierarchy.
> 
> Cheers,
> 
> John


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

Re: [Kicad-developers] [PATCH] C++14-style std::make_unique for C++11

[Chris Pavlina]

After reading about the application of std::make_unique, I like it; I am
not opposed to merging this. I would, however, be in favor of modifying
it slightly to emit a warning or error if built under C++14, so that it
is not forgotten if and when we do make the transition to C++14 in the
future.

Is anybody else for or against this?

On Sun, Jan 22, 2017 at 12:38:07AM +0800, John Beard wrote:
> Hi,
> 
> This is a patch to add std::make_unique to common.h when the C++
> standard is C++11 (which it normally is for KiCad).
> 
> This simplifies code creating std::unique_ptr's and also means you can
> generally say "never use new". It also closes a potential for
> exception-unsafety concerning temporary "new"ed objects.
> 
> It's cribbed shamelessly from its proposal for C++14
> (https://isocpp.org/files/papers/N3656.txt), and that's more or less
> exactly how my GCC (6.3.1) implements it too. I've added the GCC
> comments in for good measure.
> 
> The idea here is that when KiCad one day moves on to C++14, this file
> can be removed entirely and forgetten!
> 
> Cheers,
> 
> John


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

Re: [Kicad-developers] [PATCH] Allow editing locked modules in modedit

[Chris Pavlina]

Merged. Thank you

On Mon, Jan 23, 2017 at 09:28:42AM +0800, John Beard wrote:
> This patch makes it possible to edit locked modules in the module editor.
> 
> Since you have to explicitly launch modedit to be able to change the
> module, and there is no change to pcbnew behaviour, editing locked
> modules still required explicit effort to do so (just like moving
> locked modules).
> 
> Fixes: LP 1591625
> 
> https://bugs.launchpad.net/kicad/+bug/1591625


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

[Kicad-developers] Autosave BS

[Chris Pavlina]

I'm talking to someone on IRC right now who lost two hours of routing
because pcbnew crashed, then deleted his autosave file before he could
make use of it. We need to put some new efforts into:

1. Never delete autosave data. He may have accidentally saved the board
before loading the autosave, I'm not sure - pcbnew deletes autosave when
saving - but there should be some proper protection against this.

2. Never overwrite potentially useful autosave data - if pcbnew is
reloaded, a previous autosave shouldn't be deleted either. It should
only be valid to delete autosave data if the board has not been modified
since the autosave was made.

3. Better recovery UI when loading after a crash.

It may be necessary to record in the autosave file which run of pcbnew
it was created in (timestamp at startup?) to distinguish between old
autosave data from a previous run (possible recovery source) and data
from the current run (may be overwritten).

I haven't completely thought this through yet, just starting a thread
for discussion. This is definitely a problem we need to do something
about.

-- Chris

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

[Kicad-developers] Bug report reply politeness

[Chris Pavlina]

Can developers who reply to bugs by handwaving an explanation that
totally misunderstands the point of the bug report and then set them
"Won't Fix" without any further comment please just... not do that? It
gives users an impression that the developers are rude and not grateful
for the user feedback. Stay away from the tracker if you can't be arsed
to be polite to users.

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

Re: [Kicad-developers] Autosave BS

[Chris Pavlina]

On Tue, Jan 24, 2017 at 09:09:45AM -0700, Andy Peters wrote:
> 
> > On Jan 23, 2017, at 4:26 PM, Chris Pavlina  wrote:
> > 
> > I'm talking to someone on IRC right now who lost two hours of routing
> > because pcbnew crashed, then deleted his autosave file before he could
> > make use of it. 
> 
> What, he couldn’t type Ctrl-S (or Cmd-S on a Mac) every few traces or so? I 
> have zero sympathy for that person.

It has nothing to do with sympathy and everything to do with accepting
responsibility. Just because he could have taken steps to prevent data
loss doesn't mean it wasn't KiCad that lost the data in the first place,
and thus our responsibility to fix.

> 
> There, I said it.
> 
> -a
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Autosave BS

[Chris Pavlina]

On Tue, Jan 24, 2017 at 03:15:33PM -0500, Mark Roszko wrote:
> To throw it out there.
> 
> To me a proper UI should not immediately popup but rather an very big
> banner of some sort saving "FILES AVAILABLE TO BE RECOVERED" above the
> workspace. Clicking on the banner opens the recovery window. It
> doesn't have to be an banner, just something obvious and distinct.
> 
> 
> Why? Users may open kicad and quickly hit keys by memory or by
> accident that could trigger accidental actions on the UI. You want
> actions to be fully intentional. MS Office does this by opening a
> toolbar to the left of the document offering recovery. It doesn't
> steal focus and you must intentionally take action.

This is a _very_ good point.

> 
> The alternative is a popup dialog but no focus is stolen from the main
> window when it opens
> and it has no default action selected for the enter key. In fact,
> navigation keys may want to be disabled.
> 
> 
> In comparison, OrCad Capture (schematics) on the other hand likes to
> just prompt a "Files can be recovered" OK? message box and more often
> than not I end up accidentally hitting the enter key when opening a
> project at work. Usually causing overwrites I didnt need to.
> 
> On Tue, Jan 24, 2017 at 11:42 AM, Chris Pavlina  
> wrote:
> > On Tue, Jan 24, 2017 at 09:09:45AM -0700, Andy Peters wrote:
> >>
> >> > On Jan 23, 2017, at 4:26 PM, Chris Pavlina  
> >> > wrote:
> >> >
> >> > I'm talking to someone on IRC right now who lost two hours of routing
> >> > because pcbnew crashed, then deleted his autosave file before he could
> >> > make use of it.
> >>
> >> What, he couldn’t type Ctrl-S (or Cmd-S on a Mac) every few traces or so? 
> >> I have zero sympathy for that person.
> >
> > It has nothing to do with sympathy and everything to do with accepting
> > responsibility. Just because he could have taken steps to prevent data
> > loss doesn't mean it wasn't KiCad that lost the data in the first place,
> > and thus our responsibility to fix.
> >
> >>
> >> There, I said it.
> >>
> >> -a
> >>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> -- 
> Mark

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

[Kicad-developers] Escapes in the s-expr format documentation

[Chris Pavlina]

In the file format specification at [1] via [2], we specify the
following for string escapes:

> Here is a legal string with an embedded quote: leg"23
> Here is the same string quoted, and because it is quoted the internal
> quote must be duplicated: "leg""23"

This is NOT how we are actually quoting strings: we are using \".

I suggest updating the format document rather than the code, because:

1) This avoids changing any actual files we write
2) Escaping quotes with "" is weird, especially considering we use
   backslash escapes in other places - be consistent

But no matter how we fix it, this should be fixed; people are using
these format documents to implement parsers (I just spoke to one).

[1] 
http://bazaar.launchpad.net/~stambaughw/kicad/doc-read-only/download/head:/1115%4016bec504-3128-0410-b3e8-8e38c2123bca:trunk%252Fkicad-doc%252Fdoc%252Fhelp%252Ffile_formats%252Ffile_formats.pdf/file_formats.pdf
[2] http://kicad-pcb.org/help/file-formats/

-- 
Chris

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

Re: [Kicad-developers] [PATCH] Changed the 3d model previewer to use spinboxes

[Chris Pavlina]

On Thu, Jan 26, 2017 at 09:49:40AM -0500, Wayne Stambaugh wrote:
> If no one is opposed to adding spin controls to the 3D model selection
> dialog, I'll commit this patch when I get a chance.  I've never been
> convinced that using a spin control to change a floating point number is
> terribly useful but I'm guessing some users will prefer this over manual
> entry of calculated values used by old curmudgeons like me.

I can see value in it. When you're moving around a 3D model, you don't
want to type in a specific value, you want to move it until it's
aligned. If the model is far off it can be hard to guess what the offset
should be like, so having a button to nudge it up and down could be nice.

Might want to hold off for a bit though as I think there was talk about
an updated patch in IRC, this might not be final

> 
> On 1/26/2017 6:11 AM, Kristoffer Ödmark wrote:
> > Hello!
> > 
> > One thing that has always bothered me is that when aligning 3D models to
> > fit the footprint, one have to type the value and test, delete
> > characters and test again. Very minor issue, but it still bothers me.
> > 
> > With a spinbox the values can be changed using the mouse only.
> > 
> > attaching the patch for this minor change.
> > 
> > - Kristoffer
> > 
> > 
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] PATCH: remove Ohm sign from multiplier bitmap

[Chris Pavlina]

I just pushed this; apologies for it getting lost. Thank you for your
contribution to KiCad.

On Fri, Nov 04, 2016 at 04:41:55PM +, Dan Weatherill wrote:
> Hi all,
> attached is a patch which removes the spurious "Ohm" sign from the multiplier 
> bitmaps in PCB calculator. This is bug #1005383 in launchpad
> 
> Regards,
> Dan W


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

Re: [Kicad-developers] PATCH: remove Ohm sign from multiplier bitmap

[Chris Pavlina]

I noticed the artifacts in the code too, but didn't see anything in the
graphic.

I would definitely take another update from anyone who wants to further
edit this:

- Remove any artifacts that may be present
- Use lower-case "k"
- Center the multiplier column better


On Fri, Jan 27, 2017 at 05:08:16AM +0100, Clemens Koller wrote:
> Hello!
> 
> Is it possible hat the new 1K seems to have some artefacts left behind from 
> editing the bitmaps?
> (Just by looking at the code.)
> 
> And would it make sense to use a lower case "k" SI metric prefix, because 
> it's kind of standard?
> 
> Regards,
> 
> Clemens
> 
> On 2017-01-26 21:45, Chris Pavlina wrote:
> > I just pushed this; apologies for it getting lost. Thank you for your
> > contribution to KiCad.
> > 
> > On Fri, Nov 04, 2016 at 04:41:55PM +, Dan Weatherill wrote:
> >> Hi all,
> >> attached is a patch which removes the spurious "Ohm" sign from the 
> >> multiplier 
> >> bitmaps in PCB calculator. This is bug #1005383 in launchpad
> >>
> >> Regards,
> >> Dan W
> > 
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] PATCH: remove Ohm sign from multiplier bitmap

[Chris Pavlina]

JP, even in your country the BIPM says kilo is lowercase "k":
http://www.bipm.org/en/measurement-units/prefixes.html

I have absolutely no idea what you mean by the "legal" notation,
everything I can find published by any standards organization whatsoever
(again, including BIPM who 1. is French, 2. is accepted as an authority
on SI matters) says kilo has lowercase "k". Can you cite a source?

On Fri, Jan 27, 2017 at 12:50:05PM +0100, jp charras wrote:
> Le 27/01/2017 à 12:26, Chris Pavlina a écrit :
> > I noticed the artifacts in the code too, but didn't see anything in the
> > graphic.
> > 
> > I would definitely take another update from anyone who wants to further
> > edit this:
> > 
> > - Remove any artifacts that may be present
> > - Use lower-case "k"
> 
> Interesting topic:
> In France, unit prefixes corresponding to a scaling factor > 1 are in upper 
> case and < 1 in lower case.
> This is the "legal" notation, and I am thinking this is an ISO normalization.
> therefore M is mega and m is milli.
> 
> Although K is kilo (the only one official notation) and k does not exist in 
> "legal" notation,
> therefore does not create ambiguity, I am curious to know the official 
> notation in other countries.
> (I mean: the right notation, not users who are not aware of standards are 
> using)
> 
> 
> > - Center the multiplier column better
> > 
> 
> 
> -- 
> Jean-Pierre CHARRAS
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [PATCH] Changed the 3d model previewer to use spinboxes

[Chris Pavlina]

Just tried this. It's REALLY nice to be able to nudge the model around
by turning the scroll wheel over the fields. <3

Anyone test this on something other than Linux yet? I'd like to see this
merged.

On Thu, Jan 26, 2017 at 05:24:17PM +0100, Kristoffer Ödmark wrote:
> Yes, you can still manually change the values, I tried that.
> 
> The only change I did to the code was to change the stepping of the offset
> to 0.1mm instead of 1 in this patch. the best thing is that you can now use
> the scrollwheel as well. Wich makes rotating stuff a breeze.
> 
> - Kristoffer
> 
> On 2017-01-26 17:09, Chris Pavlina wrote:
> >On Thu, Jan 26, 2017 at 09:49:40AM -0500, Wayne Stambaugh wrote:
> >>If no one is opposed to adding spin controls to the 3D model selection
> >>dialog, I'll commit this patch when I get a chance.  I've never been
> >>convinced that using a spin control to change a floating point number is
> >>terribly useful but I'm guessing some users will prefer this over manual
> >>entry of calculated values used by old curmudgeons like me.
> >
> >I can see value in it. When you're moving around a 3D model, you don't
> >want to type in a specific value, you want to move it until it's
> >aligned. If the model is far off it can be hard to guess what the offset
> >should be like, so having a button to nudge it up and down could be nice.
> >
> >Might want to hold off for a bit though as I think there was talk about
> >an updated patch in IRC, this might not be final
> >
> >>
> >>On 1/26/2017 6:11 AM, Kristoffer Ödmark wrote:
> >>>Hello!
> >>>
> >>>One thing that has always bothered me is that when aligning 3D models to
> >>>fit the footprint, one have to type the value and test, delete
> >>>characters and test again. Very minor issue, but it still bothers me.
> >>>
> >>>With a spinbox the values can be changed using the mouse only.
> >>>
> >>>attaching the patch for this minor change.
> >>>
> >>>- Kristoffer
> >>>
> >>>
> >>>
> >>>___
> >>>Mailing list: https://launchpad.net/~kicad-developers
> >>>Post to : kicad-developers@lists.launchpad.net
> >>>Unsubscribe : https://launchpad.net/~kicad-developers
> >>>More help   : https://help.launchpad.net/ListHelp
> >>>
> >>
> >>___
> >>Mailing list: https://launchpad.net/~kicad-developers
> >>Post to : kicad-developers@lists.launchpad.net
> >>Unsubscribe : https://launchpad.net/~kicad-developers
> >>More help   : https://help.launchpad.net/ListHelp
> >
> >___
> >Mailing list: https://launchpad.net/~kicad-developers
> >Post to : kicad-developers@lists.launchpad.net
> >Unsubscribe : https://launchpad.net/~kicad-developers
> >More help   : https://help.launchpad.net/ListHelp
> >


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

Re: [Kicad-developers] Call for testing.

[Chris Pavlina]

On Fri, Jan 27, 2017 at 05:21:42PM -0500, Wayne Stambaugh wrote:
> I finally got the new schematic I/O plugin fully functional for the
> current schematic and symbol library file formats.  When you have some
> time, please test this to see if I've missed anything.  I've pushed it
> to my repo on launchpad here:
> 
> https://code.launchpad.net/~stambaughw/kicad/+git/kicad-dev/+ref/use-symbol-library-table
> 
> There is a noticeable performance hit on start up when loading a
> schematic.

Holy crap, there is a performance hit of _over a minute_ loading the
project I'm working on!

I'm testing this though.

> I'm not sure why this is happening but I believe it has to
> do with the cache validity test being called on every symbol search.  I
> verified that the cache isn't being reloaded but I'm a bit surprised
> that there was as much of a performance hit.  If you happen to notice
> something I missed please let me know.  I am primarily concern with the
> accuracy and stability of the library file I/O at this point.  I tested
> everything I could think of against the current code and always got the
> same file results but there may have been some corner cases that I
> missed.  The performance hit will be temporary.  Once the symbol library
> table support is implemented, the symbol search through the entire
> library list will go away.  Either the symbol is in the library
> specified or it's not.  I will probably introduce lazy loading as well
> once the symbol library table is implemented as only libraries that
> contain symbols in the schematic will need to be loaded when the
> schematic is opened.  Many thanks in advance for the help.
> 
> Cheers,
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Call for testing.

[Chris Pavlina]

On Fri, Jan 27, 2017 at 07:28:09PM -0500, Wayne Stambaugh wrote:
> On 1/27/2017 6:02 PM, Chris Pavlina wrote:
> > On Fri, Jan 27, 2017 at 05:21:42PM -0500, Wayne Stambaugh wrote:
> >> I finally got the new schematic I/O plugin fully functional for the
> >> current schematic and symbol library file formats.  When you have some
> >> time, please test this to see if I've missed anything.  I've pushed it
> >> to my repo on launchpad here:
> >>
> >> https://code.launchpad.net/~stambaughw/kicad/+git/kicad-dev/+ref/use-symbol-library-table
> >>
> >> There is a noticeable performance hit on start up when loading a
> >> schematic.
> > 
> > Holy crap, there is a performance hit of _over a minute_ loading the
> > project I'm working on!
> 
> Debug or release build?  I saw significantly longer load times on debug
> builds although release builds were no speed demon either.  I'll step
> through it again tomorrow just to see if I missed where the cache may be
> getting reloaded.

Release build. Not a huge project either, seven pages and 354
components...

> 
> > 
> > I'm testing this though.
> > 
> >> I'm not sure why this is happening but I believe it has to
> >> do with the cache validity test being called on every symbol search.  I
> >> verified that the cache isn't being reloaded but I'm a bit surprised
> >> that there was as much of a performance hit.  If you happen to notice
> >> something I missed please let me know.  I am primarily concern with the
> >> accuracy and stability of the library file I/O at this point.  I tested
> >> everything I could think of against the current code and always got the
> >> same file results but there may have been some corner cases that I
> >> missed.  The performance hit will be temporary.  Once the symbol library
> >> table support is implemented, the symbol search through the entire
> >> library list will go away.  Either the symbol is in the library
> >> specified or it's not.  I will probably introduce lazy loading as well
> >> once the symbol library table is implemented as only libraries that
> >> contain symbols in the schematic will need to be loaded when the
> >> schematic is opened.  Many thanks in advance for the help.
> >>
> >> Cheers,
> >>
> >> Wayne
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] Call for testing.

[Chris Pavlina]

On Fri, Jan 27, 2017 at 11:32:06PM -0500, Wayne Stambaugh wrote:
> On 1/27/2017 7:40 PM, Chris Pavlina wrote:
> > On Fri, Jan 27, 2017 at 07:28:09PM -0500, Wayne Stambaugh wrote:
> >> On 1/27/2017 6:02 PM, Chris Pavlina wrote:
> >>> On Fri, Jan 27, 2017 at 05:21:42PM -0500, Wayne Stambaugh wrote:
> >>>> I finally got the new schematic I/O plugin fully functional for the
> >>>> current schematic and symbol library file formats.  When you have some
> >>>> time, please test this to see if I've missed anything.  I've pushed it
> >>>> to my repo on launchpad here:
> >>>>
> >>>> https://code.launchpad.net/~stambaughw/kicad/+git/kicad-dev/+ref/use-symbol-library-table
> >>>>
> >>>> There is a noticeable performance hit on start up when loading a
> >>>> schematic.
> >>>
> >>> Holy crap, there is a performance hit of _over a minute_ loading the
> >>> project I'm working on!
> >>
> >> Debug or release build?  I saw significantly longer load times on debug
> >> builds although release builds were no speed demon either.  I'll step
> >> through it again tomorrow just to see if I missed where the cache may be
> >> getting reloaded.
> > 
> > Release build. Not a huge project either, seven pages and 354
> > components...
> 
> I fixed the issue and pushed to my dev branch so it should be much more
> usable now.

Much better. It's still a bit slow relative to the old code but only
"several seconds" slow now.

> 
> > 
> >>
> >>>
> >>> I'm testing this though.
> >>>
> >>>> I'm not sure why this is happening but I believe it has to
> >>>> do with the cache validity test being called on every symbol search.  I
> >>>> verified that the cache isn't being reloaded but I'm a bit surprised
> >>>> that there was as much of a performance hit.  If you happen to notice
> >>>> something I missed please let me know.  I am primarily concern with the
> >>>> accuracy and stability of the library file I/O at this point.  I tested
> >>>> everything I could think of against the current code and always got the
> >>>> same file results but there may have been some corner cases that I
> >>>> missed.  The performance hit will be temporary.  Once the symbol library
> >>>> table support is implemented, the symbol search through the entire
> >>>> library list will go away.  Either the symbol is in the library
> >>>> specified or it's not.  I will probably introduce lazy loading as well
> >>>> once the symbol library table is implemented as only libraries that
> >>>> contain symbols in the schematic will need to be loaded when the
> >>>> schematic is opened.  Many thanks in advance for the help.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Wayne
> >>>>
> >>>> ___
> >>>> Mailing list: https://launchpad.net/~kicad-developers
> >>>> Post to : kicad-developers@lists.launchpad.net
> >>>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>>> More help   : https://help.launchpad.net/ListHelp
> >>
> 

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

Re: [Kicad-developers] Call for testing.

[Chris Pavlina]

Is it a known bug that in the schematic, symbols are seen as having no
library association? If I click on a part, it shows "Library: none" in
the status bar, and if I press ctrl+E over the part, libedit makes me
select a library.

On Fri, Jan 27, 2017 at 05:21:42PM -0500, Wayne Stambaugh wrote:
> I finally got the new schematic I/O plugin fully functional for the
> current schematic and symbol library file formats.  When you have some
> time, please test this to see if I've missed anything.  I've pushed it
> to my repo on launchpad here:
> 
> https://code.launchpad.net/~stambaughw/kicad/+git/kicad-dev/+ref/use-symbol-library-table
> 
> There is a noticeable performance hit on start up when loading a
> schematic.  I'm not sure why this is happening but I believe it has to
> do with the cache validity test being called on every symbol search.  I
> verified that the cache isn't being reloaded but I'm a bit surprised
> that there was as much of a performance hit.  If you happen to notice
> something I missed please let me know.  I am primarily concern with the
> accuracy and stability of the library file I/O at this point.  I tested
> everything I could think of against the current code and always got the
> same file results but there may have been some corner cases that I
> missed.  The performance hit will be temporary.  Once the symbol library
> table support is implemented, the symbol search through the entire
> library list will go away.  Either the symbol is in the library
> specified or it's not.  I will probably introduce lazy loading as well
> once the symbol library table is implemented as only libraries that
> contain symbols in the schematic will need to be loaded when the
> schematic is opened.  Many thanks in advance for the help.
> 
> Cheers,
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

[Kicad-developers] [PATCH] Reorder eeschema toolbar a bit

[Chris Pavlina]

Hi,

A number of users have been confused by the fact that the order of
toolbar buttons in eeschema no longer corresponds to the order in which
the tools are used, since changing the function of cvpcb. This patch
reorders them to:

https://misc.c4757p.com/new-eeschema-toolbar.png

The order of the final section is now:

- Library section
- libedit
- library browser
- modedit
- Schematic property editors
- Annotate
- ERC
- cvpcb
- netlist
- BOM
- pcbnew
- back-import

Additionally, I added a toolbar button for Plot to match what pcbnew
has.

Wayne, I'd really like it if this could be pulled into the 4.0 branch in
time for 4.0.6. It's a simple change and would improve the situation for
newbies a lot. This is something I've had to correct with them a number
of times.

-- 
Chris
>From ca7b5e6e884797b5fce2c82b2451135758f632fb Mon Sep 17 00:00:00 2001
From: Chris Pavlina 
Date: Sat, 28 Jan 2017 15:48:55 -0500
Subject: [PATCH] Reorder eeschema toolbar slightly

- Put the output generation steps (annotation through pcbnew) in the
  correct order as expected by the user running through them.

- Add a Plot button to match pcbnew
---
 eeschema/tool_sch.cpp | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/eeschema/tool_sch.cpp b/eeschema/tool_sch.cpp
index 86cfd6985..eccc40ef6 100644
--- a/eeschema/tool_sch.cpp
+++ b/eeschema/tool_sch.cpp
@@ -3,7 +3,7 @@
  *
  * Copyright (C) 2013 Jean-Pierre Charras, jp.charras at wanadoo.fr
  * Copyright (C) 2008-2011 Wayne Stambaugh 
- * Copyright (C) 2004-2016 KiCad Developers, see AUTHORS.txt for contributors.
+ * Copyright (C) 2004-2017 KiCad Developers, see AUTHORS.txt for contributors.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -74,6 +74,8 @@ void SCH_EDIT_FRAME::ReCreateHToolbar()
 m_mainToolBar->AddTool( wxID_PRINT, wxEmptyString, KiBitmap( print_button_xpm ),
 _( "Print schematic" ) );
 
+m_mainToolBar->AddTool( ID_GEN_PLOT_SCHEMATIC, wxEmptyString, KiBitmap( plot_xpm ),
+_( "Plot schematic" ) );
 
 m_mainToolBar->AddSeparator();
 
@@ -138,6 +140,10 @@ void SCH_EDIT_FRAME::ReCreateHToolbar()
 m_mainToolBar->AddTool( ID_TO_LIBVIEW, wxEmptyString, KiBitmap( library_browse_xpm ),
 HELP_RUN_LIB_VIEWER );
 
+// modedit is with libedit in a "library section" because the user must have footprints before
+// they can be assigned.
+m_mainToolBar->AddTool( ID_RUN_PCB_MODULE_EDITOR, wxEmptyString, KiBitmap( module_editor_xpm ),
+_( "Footprint Editor" ) );
 
 m_mainToolBar->AddSeparator();
 
@@ -147,6 +153,9 @@ void SCH_EDIT_FRAME::ReCreateHToolbar()
 m_mainToolBar->AddTool( ID_GET_ERC, wxEmptyString, KiBitmap( erc_xpm ),
 _( "Perform electrical rules check" ) );
 
+m_mainToolBar->AddTool( ID_RUN_CVPCB, wxEmptyString, KiBitmap( cvpcb_xpm ),
+_( "Run CvPcb to associate components and footprints" ) );
+
 m_mainToolBar->AddTool( ID_GET_NETLIST, wxEmptyString, KiBitmap( netlist_xpm ),
 _( "Generate netlist" ) );
 
@@ -156,14 +165,6 @@ void SCH_EDIT_FRAME::ReCreateHToolbar()
 
 m_mainToolBar->AddSeparator();
 
-// The user must have footprints before he can assign them.  So put this before CvPcb.
-
-m_mainToolBar->AddTool( ID_RUN_PCB_MODULE_EDITOR, wxEmptyString, KiBitmap( module_editor_xpm ),
-_( "Footprint Editor" ) );
-
-m_mainToolBar->AddTool( ID_RUN_CVPCB, wxEmptyString, KiBitmap( cvpcb_xpm ),
-_( "Run CvPcb to associate components and footprints" ) );
-
 m_mainToolBar->AddTool( ID_RUN_PCB, wxEmptyString, KiBitmap( pcbnew_xpm ),
 _( "Run Pcbnew to layout printed circuit board" ) );
 
-- 
2.11.0

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

Re: [Kicad-developers] [PATCH] Reorder eeschema toolbar a bit

[Chris Pavlina]

On Sat, Jan 28, 2017 at 04:26:06PM -0500, Wayne Stambaugh wrote:
> On 1/28/2017 3:56 PM, Chris Pavlina wrote:
> > Hi,
> > 
> > A number of users have been confused by the fact that the order of
> > toolbar buttons in eeschema no longer corresponds to the order in which
> > the tools are used, since changing the function of cvpcb. This patch
> > reorders them to:
> > 
> > https://misc.c4757p.com/new-eeschema-toolbar.png
> > 
> > The order of the final section is now:
> > 
> > - Library section
> > - libedit
> > - library browser
> > - modedit
> > - Schematic property editors
> > - Annotate
> > - ERC
> > - cvpcb
> > - netlist
> > - BOM
> > - pcbnew
> > - back-import
> > 
> 
> New users actually use the order of buttons on the toolbar as a guide
> for what steps need to be performed?  I would not have expected that.

Yup, I've seen quite a few who think they should be in order. They used
to be in order, even if coincidentally - I wonder if some older
tutorials point that out?

In any case, they should be in _some_ order, and the current one doesn't
make much sense to me.

> I
> can't think of any other application where that paradigm is used.  If no
> one else has any objections, I'm fine with the change as it's fairly minor.
> 
> > Additionally, I added a toolbar button for Plot to match what pcbnew
> > has.
> > 
> > Wayne, I'd really like it if this could be pulled into the 4.0 branch in
> > time for 4.0.6. It's a simple change and would improve the situation for
> > newbies a lot. This is something I've had to correct with them a number
> > of times.
> 
> I'm fine with this too as long as there are no major objections.
> 
> > 
> > 
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

[Kicad-developers] [PATCH] libedit: preselect active component when switching

[Chris Pavlina]

Hi,

This patch makes libedit preselect the current part when choosing the
next part to edit. That makes it easier to go through a library one part
at a time and not lose your place. I figure this is pretty
noncontroversial, so I'll push it in a day or so if nobody sees anything
wrong with it.

-- 
Chris
>From 78aea6145b8a6f21e7290238c07be987250af8b7 Mon Sep 17 00:00:00 2001
From: Chris Pavlina 
Date: Mon, 30 Jan 2017 16:53:48 -0500
Subject: [PATCH] libedit: preselect active component when switching

---
 eeschema/component_tree_search_container.cpp | 27 +++
 eeschema/getpart.cpp |  8 ++--
 eeschema/libedit.cpp |  8 ++--
 eeschema/sch_base_frame.h|  7 +--
 4 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/eeschema/component_tree_search_container.cpp b/eeschema/component_tree_search_container.cpp
index 815956873..ad7649a98 100644
--- a/eeschema/component_tree_search_container.cpp
+++ b/eeschema/component_tree_search_container.cpp
@@ -2,7 +2,7 @@
  * This program source code file is part of KiCad, a free EDA CAD application.
  *
  * Copyright (C) 2014 Henner Zeller 
- * Copyright (C) 2015 KiCad Developers, see change_log.txt for contributors.
+ * Copyright (C) 2015-2017 KiCad Developers, see AUTHORS.txt for contributors.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -445,6 +445,7 @@ void COMPONENT_TREE_SEARCH_CONTAINER::UpdateSearchTerm( const wxString& aSearch
 const wxTreeItemId root_id = m_tree->AddRoot( wxEmptyString );
 const TREE_NODE* first_match = NULL;
 const TREE_NODE* preselected_node = NULL;
+bool override_preselect = false;
 
 for( TREE_NODE* node : m_nodes )
 {
@@ -470,16 +471,26 @@ void COMPONENT_TREE_SEARCH_CONTAINER::UpdateSearchTerm( const wxString& aSearch
 node->TreeId = m_tree->AppendItem( node->Parent ? node->Parent->TreeId : root_id,
node_text );
 
-// If we are a nicely scored alias, we want to have it visible. Also, if there
-// is only a single library in this container, we want to have it unfolded
-// (example: power library).
-if( node->Type == TREE_NODE::TYPE_ALIAS
- && ( node->MatchScore > kLowestDefaultScore || m_libraries_added == 1 ) )
+// If there is only a single library in this container, we want to have it
+// unfolded (example: power library, libedit)
+if( node->Type == TREE_NODE::TYPE_ALIAS && m_libraries_added == 1 )
+{
+m_tree->Expand( node->TreeId );
+
+if( first_match == NULL )
+first_match = node;
+}
+
+// If we are a nicely scored alias, we want to have it visible.
+if( node->Type == TREE_NODE::TYPE_ALIAS && ( node->MatchScore > kLowestDefaultScore ) )
 {
 m_tree->Expand( node->TreeId );
 
 if( first_match == NULL )
 first_match = node;   // First, highest scoring: the "I am feeling lucky" element.
+
+// The user is searching, don't preselect!
+override_preselect = true;
 }
 
 // The first node that matches our pre-select criteria is choosen. 'First node'
@@ -497,12 +508,12 @@ void COMPONENT_TREE_SEARCH_CONTAINER::UpdateSearchTerm( const wxString& aSearch
 preselected_node = node;
 }
 
-if( first_match )  // Highest score search match pre-selected.
+if( first_match && ( !preselected_node || override_preselect ) )
 {
 m_tree->SelectItem( first_match->TreeId );
 m_tree->EnsureVisible( first_match->TreeId );
 }
-else if( preselected_node )// No search, so history item preselected.
+else if( preselected_node )
 {
 m_tree->SelectItem( preselected_node->TreeId );
 m_tree->EnsureVisible( preselected_node->TreeId );
diff --git a/eeschema/getpart.cpp b/eeschema/getpart.cpp
index 5a922f126..958bc1006 100644
--- a/eeschema/getpart.cpp
+++ b/eeschema/getpart.cpp
@@ -3,7 +3,7 @@
  *
  * Copyright (C) 2015 Jean-Pierre Charras, jp.charras at wanadoo.fr
  * Copyright (C) 2008-2012 Wayne Stambaugh 
- * Copyright (C) 2004-2015 KiCad Developers, see change_log.txt for contributors.
+ * Copyright (C) 2004-2017 KiCad Developers, see AUTHORS.txt for contributors.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -101,7 +101,8 @@ wxString SCH_BASE_FRAME::SelectComponentFromLibrary( const SCHLIB_FILTER* aFilte
  int&aHistoryLastUnit,
 

[Kicad-developers] [PATCH] libedit: add hotkey for Load Component

[Chris Pavlina]

Hi,

This patch adds a hotkey (default: Ctrl+L) to libedit for Load
Component. Just another simple workflow-quickener when doing a lot of
library edits. I'll push this one in a day too.

-- 
Chris
>From c45f9c2b740ca5e7a7ac264d50a7d59d57794f3b Mon Sep 17 00:00:00 2001
From: Chris Pavlina 
Date: Mon, 30 Jan 2017 17:30:05 -0500
Subject: [PATCH] libedit: add hotkey for Load Component

---
 eeschema/hotkeys.cpp | 8 +++-
 eeschema/hotkeys.h   | 3 ++-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/eeschema/hotkeys.cpp b/eeschema/hotkeys.cpp
index 43773b555..5deff742e 100644
--- a/eeschema/hotkeys.cpp
+++ b/eeschema/hotkeys.cpp
@@ -3,7 +3,7 @@
  *
  * Copyright (C) 2015 Jean-Pierre Charras, jp.charras at wanadoo.fr
  * Copyright (C) 2008-2011 Wayne Stambaugh 
- * Copyright (C) 2004-2016 KiCad Developers, see AUTHORS.txt for contributors.
+ * Copyright (C) 2004-2017 KiCad Developers, see AUTHORS.txt for contributors.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -211,6 +211,7 @@ static EDA_HOTKEY HkFindNextDrcMarker( _HKI( "Find Next DRC Marker" ), HK_FIND_N
 static EDA_HOTKEY HkZoomSelection( _HKI( "Zoom to Selection" ), HK_ZOOM_SELECTION, '@', ID_ZOOM_SELECTION );
 
 // Special keys for library editor:
+static EDA_HOTKEY HkLoadPart( _HKI( "Load Component" ), HK_LIBEDIT_LOAD_PART, 'L' + GR_KB_CTRL );
 static EDA_HOTKEY HkCreatePin( _HKI( "Create Pin" ), HK_LIBEDIT_CREATE_PIN, 'P' );
 static EDA_HOTKEY HkInsertPin( _HKI( "Repeat Pin" ), HK_REPEAT_LAST, WXK_INSERT );
 static EDA_HOTKEY HkMoveLibItem( _HKI( "Move Library Item" ), HK_LIBEDIT_MOVE_GRAPHIC_ITEM, 'M' );
@@ -314,6 +315,7 @@ static EDA_HOTKEY* schematic_Hotkey_List[] =
 static EDA_HOTKEY* libEdit_Hotkey_List[] =
 {
 &HkSaveLib,
+&HkLoadPart,
 &HkCreatePin,
 &HkInsertPin,
 &HkMoveLibItem,
@@ -752,6 +754,10 @@ bool LIB_EDIT_FRAME::OnHotKey( wxDC* aDC, int aHotKey, const wxPoint& aPosition,
 }
 break;
 
+case HK_LIBEDIT_LOAD_PART:
+LoadOneLibraryPart( cmd );
+break;
+
 case HK_LIBEDIT_CREATE_PIN:
 if( ! itemInEdit )
 {
diff --git a/eeschema/hotkeys.h b/eeschema/hotkeys.h
index 926288cbe..92211d3c7 100644
--- a/eeschema/hotkeys.h
+++ b/eeschema/hotkeys.h
@@ -2,7 +2,7 @@
  * This program source code file is part of KiCad, a free EDA CAD application.
  *
  * Copyright (C) 2007 Jean-Pierre Charras, jp.charras at wanadoo.fr
- * Copyright (C) 2014 KiCad Developers, see CHANGELOG.TXT for contributors.
+ * Copyright (C) 2014-2017 KiCad Developers, see AUTHORS.txt for contributors.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -43,6 +43,7 @@ enum hotkey_id_commnand {
 HK_LIBEDIT_MOVE_GRAPHIC_ITEM,
 HK_MOVEBLOCK_TO_DRAGBLOCK,
 HK_SAVE_BLOCK,
+HK_LIBEDIT_LOAD_PART,
 HK_LIBEDIT_CREATE_PIN,
 HK_DELETE_PIN,
 HK_ROTATE,
-- 
2.11.0

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

Re: [Kicad-developers] Add a cmake option for legacy canvas

[Chris Pavlina]

I think it's worth revisiting this. I know we're not ready to remove
legacy yet, but we're getting close. Starting to factor it out into a
switchable build option is a good way to make sure the transition is
smooth and help find anything that is still missing. Obviously the
default build option should be to keep legacy in, so users won't notice
anything.

On Sat, Sep 17, 2016 at 10:59:45PM +1200, Simon Wells wrote:
> As legacy canvas in pcbnew is legacy is it worth conditional compiling
> all the code related and only used by legacy canvas based on a cmake
> option aka something like
> 
> KICAD_BUILD_LEGACY_CANVAS with a default of ON, this will allow people
> who have no use for the legacy canvas as they have a truly functional
> opengl canvas to see in their usual workflow if anything is missing.
> 
> I realise that wayne is waiting on a replacement non-gl dependent GAL
> canvas before removing legacy, but in the interim is it worth making
> it an option making less work later on when its time to remove it
> 
> Simon
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [PATCH] Add exchange footprints to GAL

[Chris Pavlina]

On Tue, Jan 31, 2017 at 11:32:40PM +0800, John Beard wrote:
> Hi,
> 
> The attached patches add the "exchange footprints" command to the GAL edit 
> tool.
> 
> This is 1 out of 3 parts of
> https://bugs.launchpad.net/kicad/+bug/1541460. I'm not sure how to put
> this as a commit comment exactly.

Generally I close the bug with a comment requesting the submitter open
several new bugs for each part of the combined report.

*glares at Wayne*

;)

> 
> This is implemented as two segments:
> 
> * Put the dialog/exchange FP code into pcbnew/dialogs directory (as a
> header/implementation pair) where it can be reached by bother
> pcbframe.cpp and GAL tools. This also makes it easier to remove legacy
> calling code in future. No change is made to the functionality of the
> dialog.
> * Add the tool to the GAL, calling the dialog as needed.
> 
> The third patch is optional, but tidies up a copy-pasted selection
> routine into a named function and adds a little commentary to a couple
> of related existing functions.
> 
> Cheers,
> 
> John


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

Re: [Kicad-developers] [PATCH] Add exchange footprints to GAL

[Chris Pavlina]

On Tue, Jan 31, 2017 at 10:45:42AM -0500, Wayne Stambaugh wrote:
> On 1/31/2017 10:36 AM, Chris Pavlina wrote:
> > On Tue, Jan 31, 2017 at 11:32:40PM +0800, John Beard wrote:
> >> Hi,
> >>
> >> The attached patches add the "exchange footprints" command to the GAL edit 
> >> tool.
> >>
> >> This is 1 out of 3 parts of
> >> https://bugs.launchpad.net/kicad/+bug/1541460. I'm not sure how to put
> >> this as a commit comment exactly.
> > 
> > Generally I close the bug with a comment requesting the submitter open
> > several new bugs for each part of the combined report.
> > 
> > *glares at Wayne*
> > 
> > ;)
> 
> *Wayne glares back* ;)  I never get tired of asking people to file
> single issue bug reports when it's right there in the bug reporting page
> on launchpad under the heading "KiCad bug reporting guidelines:".  Sigh!
>  Maybe it needs to be in a bigger bold font in all capital letters?

Lol Wayne, _you_ filed this report!

> 
> > 
> >>
> >> This is implemented as two segments:
> >>
> >> * Put the dialog/exchange FP code into pcbnew/dialogs directory (as a
> >> header/implementation pair) where it can be reached by bother
> >> pcbframe.cpp and GAL tools. This also makes it easier to remove legacy
> >> calling code in future. No change is made to the functionality of the
> >> dialog.
> >> * Add the tool to the GAL, calling the dialog as needed.
> >>
> >> The third patch is optional, but tidies up a copy-pasted selection
> >> routine into a named function and adds a little commentary to a couple
> >> of related existing functions.
> >>
> >> Cheers,
> >>
> >> John
> > 
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 


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

Re: [Kicad-developers] Eeschema one_field_edit dialog setselection patch

[Chris Pavlina]

/home/cmp/git/kicad/eeschema/dialogs/dialog_edit_one_field.cpp: In member 
function ‘virtual bool DIALOG_EDIT_ONE_FIELD::TransferDataToWindow()’:
/home/cmp/git/kicad/eeschema/dialogs/dialog_edit_one_field.cpp:174:42: warning: 
comparison between signed and unsigned integer expressions [-Wsign-compare]
 if ( m_text.find_first_of( '?' ) != -1 )
   ^

wxString::find_first_of returns size_t, so that comparison will always
be false.

Fix this and I'll merge it - I've been wanting this for a while now :)

On Tue, Jan 31, 2017 at 06:46:05PM +, Diogo Condeço wrote:
> Hi all,
> 
> This patch selects the text in the dialog.
> For references the text selected is either the number or the ? (for
> unannotated symbols).
> 
> For the other cases the entire text is selected.
> 
> This has been tested in windows (
> http://downloads.kicad-pcb.org/windows/testing/patched/kicad-patched-540-35fc1f3-x86_64.exe)
> and osx.
> A previous version was also tested in linux so it also should be working
> since only the data selection changed.
> 
> Thanks
> 
> -- 
> Diogo Condeço


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

Re: [Kicad-developers] Eeschema one_field_edit dialog setselection patch

[Chris Pavlina]

Excellent. Looks good and workse well here - just pushed it. Thank you
for your contribution.

On Tue, Jan 31, 2017 at 08:46:52PM +, Diogo Condeço wrote:
> Hopefully both problems are corrected in this patch...
> 
> Sorry for the code formatting but I'm not that used to this particular
> format... and sometimes I'll give an extra space... I will try to be more
> careful next time.
> 
> Thanks,
> Diogo
> 
> On Tue, Jan 31, 2017 at 7:30 PM, Wayne Stambaugh 
> wrote:
> 
> > Diogo,
> >
> > Please pay attention to you code formatting.  I saw:
> >
> > if ( ... )
> >
> > instead of:
> >
> > if( ... )
> >
> > more than once in your patch.
> >
> > Thanks,
> >
> > Wayne
> >
> > On 1/31/2017 2:13 PM, Chris Pavlina wrote:
> > > /home/cmp/git/kicad/eeschema/dialogs/dialog_edit_one_field.cpp: In
> > member function ‘virtual bool DIALOG_EDIT_ONE_FIELD::
> > TransferDataToWindow()’:
> > > /home/cmp/git/kicad/eeschema/dialogs/dialog_edit_one_field.cpp:174:42:
> > warning: comparison between signed and unsigned integer expressions
> > [-Wsign-compare]
> > >  if ( m_text.find_first_of( '?' ) != -1 )
> > >^
> > >
> > > wxString::find_first_of returns size_t, so that comparison will always
> > > be false.
> > >
> > > Fix this and I'll merge it - I've been wanting this for a while now :)
> > >
> > > On Tue, Jan 31, 2017 at 06:46:05PM +, Diogo Condeço wrote:
> > >> Hi all,
> > >>
> > >> This patch selects the text in the dialog.
> > >> For references the text selected is either the number or the ? (for
> > >> unannotated symbols).
> > >>
> > >> For the other cases the entire text is selected.
> > >>
> > >> This has been tested in windows (
> > >> http://downloads.kicad-pcb.org/windows/testing/patched/
> > kicad-patched-540-35fc1f3-x86_64.exe)
> > >> and osx.
> > >> A previous version was also tested in linux so it also should be working
> > >> since only the data selection changed.
> > >>
> > >> Thanks
> > >>
> > >> --
> > >> Diogo Condeço
> > >
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to : kicad-developers@lists.launchpad.net
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help   : https://help.launchpad.net/ListHelp
> > >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
> 
> 
> 
> -- 
> Diogo Condeço


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

Re: [Kicad-developers] [PATCH] Reorder eeschema toolbar a bit

[Chris Pavlina]

Okay, just pushed this to both branches.

On Sat, Jan 28, 2017 at 04:26:06PM -0500, Wayne Stambaugh wrote:
> On 1/28/2017 3:56 PM, Chris Pavlina wrote:
> > Hi,
> > 
> > A number of users have been confused by the fact that the order of
> > toolbar buttons in eeschema no longer corresponds to the order in which
> > the tools are used, since changing the function of cvpcb. This patch
> > reorders them to:
> > 
> > https://misc.c4757p.com/new-eeschema-toolbar.png
> > 
> > The order of the final section is now:
> > 
> > - Library section
> > - libedit
> > - library browser
> > - modedit
> > - Schematic property editors
> > - Annotate
> > - ERC
> > - cvpcb
> > - netlist
> > - BOM
> > - pcbnew
> > - back-import
> > 
> 
> New users actually use the order of buttons on the toolbar as a guide
> for what steps need to be performed?  I would not have expected that.  I
> can't think of any other application where that paradigm is used.  If no
> one else has any objections, I'm fine with the change as it's fairly minor.
> 
> > Additionally, I added a toolbar button for Plot to match what pcbnew
> > has.
> > 
> > Wayne, I'd really like it if this could be pulled into the 4.0 branch in
> > time for 4.0.6. It's a simple change and would improve the situation for
> > newbies a lot. This is something I've had to correct with them a number
> > of times.
> 
> I'm fine with this too as long as there are no major objections.
> 
> > 
> > 
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [PATCH] Load library progress dialog

[Chris Pavlina]

This sounds really nice, I'm testing it now.

I'm not sure how, but you seem to have got another patch tangled up in
this one. I've attached a cleaned version for the convenience of anyone
else looking to test this.

On Thu, Feb 02, 2017 at 07:51:41PM +1100, Oliver Walters wrote:
> When first launching eeschema, if there are many libs selected it can take
> a while to load, and appears as if KiCAD is "hanging".
> 
> This patch adds a progress dialog which displays the status of library
> loading, for improved UX.

>From dc54026f0ba36fbbe544b32449b30f0dc1f9ae8c Mon Sep 17 00:00:00 2001
From: Oliver 
Date: Thu, 2 Feb 2017 16:48:29 +1100
Subject: [PATCH] Added progress dialogs for library loading

- Modal wxProgressDialog when loading symbol libraries (eeschema / libedit)
---
 eeschema/class_library.cpp | 26 +-
 eeschema/class_library.h   |  2 +-
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/eeschema/class_library.cpp b/eeschema/class_library.cpp
index 994616d..988ac32 100644
--- a/eeschema/class_library.cpp
+++ b/eeschema/class_library.cpp
@@ -44,6 +44,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -900,7 +901,7 @@ const wxString PART_LIBS::CacheName( const wxString& aFullProjectFilename )
 }
 
 
-void PART_LIBS::LoadAllLibraries( PROJECT* aProject ) throw( IO_ERROR, boost::bad_pointer )
+void PART_LIBS::LoadAllLibraries( PROJECT* aProject, bool aShowProgress ) throw( IO_ERROR, boost::bad_pointer )
 {
 wxStringfilename;
 wxStringlibs_not_found;
@@ -920,8 +921,26 @@ void PART_LIBS::LoadAllLibraries( PROJECT* aProject ) throw( IO_ERROR, boost::ba
 
 wxASSERT( !size() );// expect to load into "this" empty container.
 
+wxProgressDialog lib_dialog( _( "Loading symbol libraries" ),
+ wxEmptyString,
+ lib_names.GetCount(),
+ NULL,
+ wxPD_APP_MODAL );
+
+if( aShowProgress )
+{
+lib_dialog.Show();
+}
+
+wxString progress_message;
+
 for( unsigned i = 0; i < lib_names.GetCount();  ++i )
 {
+if( aShowProgress )
+{
+lib_dialog.Update( i, _( "Loading " + lib_names[i] ) );
+}
+
 wxFileName fn = lib_names[i];
 // lib_names[] does not store the file extension. Set it:
 fn.SetExt( SchematicLibraryFileExtension );
@@ -966,6 +985,11 @@ void PART_LIBS::LoadAllLibraries( PROJECT* aProject ) throw( IO_ERROR, boost::ba
 }
 }
 
+if( aShowProgress )
+{
+lib_dialog.Destroy();
+}
+
 // add the special cache library.
 wxString cache_name = CacheName( aProject->GetProjectFullName() );
 PART_LIB* cache_lib;
diff --git a/eeschema/class_library.h b/eeschema/class_library.h
index 31db70d..421bfdd 100644
--- a/eeschema/class_library.h
+++ b/eeschema/class_library.h
@@ -230,7 +230,7 @@ public:
  * loads all of the project's libraries into this container, which should
  * be cleared before calling it.
  */
-void LoadAllLibraries( PROJECT* aProject ) throw( IO_ERROR, boost::bad_pointer );
+void LoadAllLibraries( PROJECT* aProject, bool aShowProgress=true ) throw( IO_ERROR, boost::bad_pointer );
 
 /**
  * Function LibNamesAndPaths
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Load library progress dialog

[Chris Pavlina]

This is a very nice improvement, and the change is pretty trivial - I'm
going to merge it. Thank you!

On Thu, Feb 02, 2017 at 10:10:25PM +1100, Oliver Walters wrote:
> Ah, sorry Chris.
> 
> On Thu, Feb 2, 2017 at 10:09 PM, Chris Pavlina 
> wrote:
> 
> > This sounds really nice, I'm testing it now.
> >
> > I'm not sure how, but you seem to have got another patch tangled up in
> > this one. I've attached a cleaned version for the convenience of anyone
> > else looking to test this.
> >
> > On Thu, Feb 02, 2017 at 07:51:41PM +1100, Oliver Walters wrote:
> > > When first launching eeschema, if there are many libs selected it can
> > take
> > > a while to load, and appears as if KiCAD is "hanging".
> > >
> > > This patch adds a progress dialog which displays the status of library
> > > loading, for improved UX.
> >
> >

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

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

[Chris Pavlina]

Oops, I didn't mean to push this one at the same time, clumsy push
command - but it looks good too. I always hated that delete dialog.
Thank you!

On Thu, Feb 02, 2017 at 09:42:01PM +1100, Oliver Walters wrote:
> The attached patch removes the clunky "Delete Single Part" dialog in
> libedit, and re-uses the existing part-selector to find a component to
> delete.
> 
> Now, the user can use the filter tool to select a component for deletion.


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

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

[Chris Pavlina]

On second thought, I'm reverting it, I found a weird bug. Apologies for
the accidental push, I'll be more careful next time.

I *was* investigating what I thought was a minor bug (i.e. didn't keep
me from pushing the patch), but I found this. To reproduce:

1) Select a single-unit part
2) Delete one unit of a different, multi-unit part

The current part gets messed up, like: 
https://misc.c4757p.com/messed-up-part.png

Not sure if that's a rendering issue or if the pins are actually gone.

What I *was* looking at is that I thought deleting a unit would just
delete the entire part, and I was going to suggest one of two possible
fixes:

1) Modify the component selector to have a mode where it doesn't delete
units
2) Actually delete the unit, adding code to filter the part and remove
anything on the unit to be deleted and reorder subsequent units.

I was going to offer to write #2 myself, because that'd be really useful
to me. But you should probably fix the bug described above first and
resubmit.

ALSO, I was going to contribute a small patch to this to preselect the
current component just like I added to Load Component recently - I
attached a diff for that in case you want it, I had it all done before
noticing this.

On Thu, Feb 02, 2017 at 06:15:57AM -0500, Chris Pavlina wrote:
> Oops, I didn't mean to push this one at the same time, clumsy push
> command - but it looks good too. I always hated that delete dialog.
> Thank you!
> 
> On Thu, Feb 02, 2017 at 09:42:01PM +1100, Oliver Walters wrote:
> > The attached patch removes the clunky "Delete Single Part" dialog in
> > libedit, and re-uses the existing part-selector to find a component to
> > delete.
> > 
> > Now, the user can use the filter tool to select a component for deletion.
> 
diff --git a/eeschema/libedit.cpp b/eeschema/libedit.cpp
index 8e37b8ebc..41e77353a 100644
--- a/eeschema/libedit.cpp
+++ b/eeschema/libedit.cpp
@@ -522,6 +522,7 @@ void LIB_EDIT_FRAME::DeleteOnePart( wxCommandEvent& event )
 m_lastDrawItem = NULL;
 m_drawItem = NULL;
 
+LIB_PART* part = GetCurPart();
 PART_LIB* lib = GetCurLib();
 
 if( !lib )
@@ -538,7 +539,9 @@ void LIB_EDIT_FRAME::DeleteOnePart( wxCommandEvent& event )
 
 COMPONENT_TREE_SEARCH_CONTAINER search_container( Prj().SchLibs() );
 
+wxString name = part ? part->GetName() : wxString( wxEmptyString );
 search_container.AddLibrary( *lib );
+search_container.SetPreselectNode( name, /* aUnit */ 0 );
 
 wxString dialogTitle;
 dialogTitle.Printf( _( "Delete Component (%u items loaded)" ), search_container.GetComponentsCount() );
@@ -575,7 +578,7 @@ void LIB_EDIT_FRAME::DeleteOnePart( wxCommandEvent& event )
 if( !IsOK( this, msg ) )
 return;
 
-LIB_PART* part = GetCurPart();
+part = GetCurPart();
 
 if( !part || !part->HasAlias( libEntry->GetName() ) )
 {
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [RFC] Application naming

[Chris Pavlina]

I admit I'm getting self-indulgent here, this request is definitely a
bit "what Chris would do if made Dictator of KiCad", but... just testing
the waters here:

What do people think about, for either the 5.0 or 6.0 release, ditching
the old application names, in favor of everything being one tool under
the "KiCad" roof:

Eeschema-> Schematic editor
Pcbnew  -> PCB editor, or Layout editor, or Board editor
Cvpcb   -> "Assign Footprints"
Pl Editor   -> Title block editor
Bitmap2Component-> Remove as independent app, make "Import image" in
   libedit and modedit

I know this one is going to be controversial, but I don't really see the
point of these old names. They're... weird. Cvpcb - what does that even
mean? :P

-- 
Chris


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

Re: [Kicad-developers] [RFC] Application naming

[Chris Pavlina]

Yeah, but you don't need to if they're obvious. If the schematic editor
is called "schematic editor" and you tell a user to edit their
schematic, they'll find the schematic editor. :P

On Thu, Feb 02, 2017 at 04:58:10PM +0100, Nick Østergaard wrote:
> I myself quite like that the apps have unique names and notngeneric names
> like PCB editor, because it makes it easier when talking about a specific
> name rather a description.
> 
> Den 02/02/2017 14.56 skrev "Chris Pavlina" :
> 
> > I admit I'm getting self-indulgent here, this request is definitely a
> > bit "what Chris would do if made Dictator of KiCad", but... just testing
> > the waters here:
> >
> > What do people think about, for either the 5.0 or 6.0 release, ditching
> > the old application names, in favor of everything being one tool under
> > the "KiCad" roof:
> >
> > Eeschema-> Schematic editor
> > Pcbnew  -> PCB editor, or Layout editor, or Board editor
> > Cvpcb   -> "Assign Footprints"
> > Pl Editor   -> Title block editor
> > Bitmap2Component-> Remove as independent app, make "Import image" in
> >libedit and modedit
> >
> > I know this one is going to be controversial, but I don't really see the
> > point of these old names. They're... weird. Cvpcb - what does that even
> > mean? :P
> >
> > --
> > Chris
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >

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

Re: [Kicad-developers] [RFC] Application naming

[Chris Pavlina]

THANK YOU.

We argue about the bloody footprint workflow _constantly_, I can't
really say I appreciate another attempt to derail a thread by bringing
it back up.

On Thu, Feb 02, 2017 at 09:59:54AM -0600, Adam Wolf wrote:
> Hi folks!
> 
> If it isn't too much of an imposition, can we move this discussion
> about footprint and symbol philosophy that we seem to constantly have
> going into its own thread, or maybe even off-list?
> 
> Thanks!
> 
> Adam Wolf
> 
> On Thu, Feb 2, 2017 at 9:56 AM, Justin Partain
>  wrote:
> > At my workplace, we use this workflow as well.  Each real "part" is a symbol
> > as its base, with BOM info in the symbol properties, with a specific
> > footprint for each part. Out of the four EE's doing schematic/layout here,
> > we never open  CvPCB.
> >
> > --
> >
> > Justin Partain
> >
> > On Thu, Feb 2, 2017 at 10:28 AM, Clemens Koller  wrote:
> >>
> >> Hello, Chris!
> >>
> >> Eeschema-> Schematic editor
> >>
> >> Pcbnew  -> Layout editor
> >>
> >> Cvpcb   -> move it to Library editor or manager
> >>
> >> BTW: Assignment of a footprints seems to me completely odd at this level.
> >>
> >> When I create a part it consist of a partname, schematic symbol, an
> >> assigned footprint, a 3d-model, and some attributes all in
> >> one place. Then I grab that part by its partname (like the handle of a
> >> suitcase) and use it in the schematics. From there it gets
> >> forwarded to the layout, bill-of-materials and assembly data and
> >> optionally to an 3d-renderer without any additional tweaking.
> >>
> >> A part to buy, i.e. named "LTC6362CMS8" comes already with all the
> >> information to be placed in the suitcase - it has exactly one type of
> >> footprint (here MSOP-8, JEDEC MO-187-AA). I don't see any reason to assign
> >> different footprints to parts, because they usually have only one.
> >>
> >> It's a different story if there will be some solder yield tweaking to
> >> automagically replace/update *all* footprints of a design by using a
> >> different process library. (i.e. use RoundRect shapes vs. Rectangular 
> >> shapes
> >> to improve tombstoning or solderpaste release.)
> >> Here, we are thinking to generate footprints dynamically depending on
> >> soldering process parameters - but an MSOP-8 will still be an MSOP-8.
> >>
> >> Pl Editor   -> Template editor (we might want to edit other stuff as well
> >> such as board outlines for PCIe and similar things)
> >>
> >> Bitmap2Component -> Remove as independent app, make "Import image" in
> >> libedit and modedit (dito.)
> >>
> >>
> >> Regards,
> >>
> >> Clemens
> >>
> >>
> >> On 2017-02-02 14:56, Chris Pavlina wrote:
> >> > I admit I'm getting self-indulgent here, this request is definitely a
> >> > bit "what Chris would do if made Dictator of KiCad", but... just testing
> >> > the waters here:
> >> >
> >> > What do people think about, for either the 5.0 or 6.0 release, ditching
> >> > the old application names, in favor of everything being one tool under
> >> > the "KiCad" roof:
> >> >
> >> > Eeschema-> Schematic editor
> >> > Pcbnew  -> PCB editor, or Layout editor, or Board editor
> >> > Cvpcb   -> "Assign Footprints"
> >> > Pl Editor   -> Title block editor
> >> > Bitmap2Component-> Remove as independent app, make "Import image" in
> >> >libedit and modedit
> >> >
> >> > I know this one is going to be controversial, but I don't really see the
> >> > point of these old names. They're... weird. Cvpcb - what does that even
> >> > mean? :P
> >> >
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [RFC] Application naming

[Chris Pavlina]

On Thu, Feb 02, 2017 at 11:20:46AM -0600, José Ignacio wrote:
> On Thu, Feb 2, 2017 at 7:56 AM, Chris Pavlina 
> wrote:
> 
> > I admit I'm getting self-indulgent here, this request is definitely a
> > bit "what Chris would do if made Dictator of KiCad", but... just testing
> > the waters here:
> >
> > What do people think about, for either the 5.0 or 6.0 release, ditching
> > the old application names, in favor of everything being one tool under
> > the "KiCad" roof:
> >
> > Eeschema-> Schematic editor
> > Pcbnew  -> PCB editor, or Layout editor, or Board editor
> > Cvpcb   -> "Assign Footprints"
> > Pl Editor   -> Title block editor
> > Bitmap2Component-> Remove as independent app, make "Import image" in
> >libedit and modedit
> >
> > I know this one is going to be controversial, but I don't really see the
> > point of these old names. They're... weird. Cvpcb - what does that even
> > mean? :P
> >
> >
> What about this for short names (and the names of standalone
> executables/class files if they ever get refactored)
> 
> Eeschema -> KiSchem (kischem)
> Pcbnew -> KiPCB (kipcb)
> PL Editor -> KiPLEdit (kipledit)
> Modedit -> KiFPEdit (kifpedit)
> Libedit -> KiSymEdit (kisymedit)
> 
> The ki prefix sounds kinda forced/smurfy in some of these, but it's
> consistent and avoids collisions, then for the UI the long names Chris
> suggested would work fine, they are being used already.

I can't pronounce these, can you?

> 
> --
> Jose
> 
> --
> > Chris
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >

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

Re: [Kicad-developers] [RFC] Application naming

[Chris Pavlina]

I think I am going to seek out some user views on this. As usual it
doesn't do us much good to speculate about what non-developers want.

I will say that so far two users have told me that the weird names
confused them as beginners, and only established developers have argued
in favor of keeping them. ;)

On Thu, Feb 02, 2017 at 12:40:10PM -0500, Wayne Stambaugh wrote:
> I don't have a strong opinion one way or another but you should never
> underestimate the power of branding.  You can take the same car and
> change the manufacturer and model names and the same person who liked
> the car under one brand name will hate it under another brand name.  I
> never understood this myself but I'm not a marketing guru.  User are
> familiar with the application names and given that the applications can
> still be run in stand alone mode, it may make sense to keep them.
> 
> On 2/2/2017 8:56 AM, Chris Pavlina wrote:
> > I admit I'm getting self-indulgent here, this request is definitely a
> > bit "what Chris would do if made Dictator of KiCad", but... just testing
> > the waters here:
> > 
> > What do people think about, for either the 5.0 or 6.0 release, ditching
> > the old application names, in favor of everything being one tool under
> > the "KiCad" roof:
> > 
> > Eeschema-> Schematic editor
> > Pcbnew  -> PCB editor, or Layout editor, or Board editor
> > Cvpcb   -> "Assign Footprints"
> > Pl Editor   -> Title block editor
> > Bitmap2Component-> Remove as independent app, make "Import image" in
> >libedit and modedit
> 
> Rename or not, this change makes sense to me.  Being able to directly
> import an image as a symbol or footprint would be an improvement over
> the way it's currently done.  Although it would probably be useful for
> library developers to be able to run it as a stand alone app as well.
> 
> > 
> > I know this one is going to be controversial, but I don't really see the
> > point of these old names. They're... weird. Cvpcb - what does that even
> > mean? :P
> > 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [RFC] Application naming

[Chris Pavlina]

Keep in mind I am not suggesting changing the name of the whole package.
This is more like if Ford suggested changing Qxshift* to SelectShift[1].
It's a clearer name that tells what the thing does, and
really...nobody's going to miss "Qxshift".

[1] 
https://owner.ford.com/how-tos/vehicle-features/transmission/selectshift-automatic-transmission.html
* I really have no idea what Cvpcb means still.

On Thu, Feb 02, 2017 at 11:03:48AM -0700, Andy Peters wrote:
> 
> > On Feb 2, 2017, at 10:40 AM, Wayne Stambaugh  wrote:
> > 
> > I don't have a strong opinion one way or another but you should never
> > underestimate the power of branding.  You can take the same car and
> > change the manufacturer and model names and the same person who liked
> > the car under one brand name will hate it under another brand name.  I
> > never understood this myself but I'm not a marketing guru.  
> 
> A good example of this was when Ford decided that the Taurus model name had 
> run its course, so they changed the name to the Five Hundred. Sales tanked, 
> so they reverted back to Taurus.
> 
> I don’t get it, either.
> 
> -a
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [RFC] Application naming

[Chris Pavlina]

On Thu, Feb 02, 2017 at 01:07:05PM -0500, Wayne Stambaugh wrote:
> On 2/2/2017 1:08 PM, Chris Pavlina wrote:
> > Keep in mind I am not suggesting changing the name of the whole package.
> > This is more like if Ford suggested changing Qxshift* to SelectShift[1].
> > It's a clearer name that tells what the thing does, and
> > really...nobody's going to miss "Qxshift".
> > 
> > [1] 
> > https://owner.ford.com/how-tos/vehicle-features/transmission/selectshift-automatic-transmission.html
> > * I really have no idea what Cvpcb means still.
> 
> Me neither.  That was it's name when I joined the project.  Maybe JP
> could shed some light on this.

Whatever the outcome of this larger discussion is, can we please please
please rename cvpcb? ;)

> 
> > 
> > On Thu, Feb 02, 2017 at 11:03:48AM -0700, Andy Peters wrote:
> >>
> >>> On Feb 2, 2017, at 10:40 AM, Wayne Stambaugh  wrote:
> >>>
> >>> I don't have a strong opinion one way or another but you should never
> >>> underestimate the power of branding.  You can take the same car and
> >>> change the manufacturer and model names and the same person who liked
> >>> the car under one brand name will hate it under another brand name.  I
> >>> never understood this myself but I'm not a marketing guru.  
> >>
> >> A good example of this was when Ford decided that the Taurus model name 
> >> had run its course, so they changed the name to the Five Hundred. Sales 
> >> tanked, so they reverted back to Taurus.
> >>
> >> I don’t get it, either.
> >>
> >> -a
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [RFC] Application naming

[Chris Pavlina]

On Thu, Feb 02, 2017 at 01:07:05PM -0500, Wayne Stambaugh wrote:
> On 2/2/2017 1:08 PM, Chris Pavlina wrote:
> > Keep in mind I am not suggesting changing the name of the whole package.
> > This is more like if Ford suggested changing Qxshift* to SelectShift[1].
> > It's a clearer name that tells what the thing does, and
> > really...nobody's going to miss "Qxshift".
> > 
> > [1] 
> > https://owner.ford.com/how-tos/vehicle-features/transmission/selectshift-automatic-transmission.html
> > * I really have no idea what Cvpcb means still.
> 
> Me neither.  That was it's name when I joined the project.  Maybe JP
> could shed some light on this.

Found a French speaker :D "Composants vers PCB" seems like a good guess
:)

> 
> > 
> > On Thu, Feb 02, 2017 at 11:03:48AM -0700, Andy Peters wrote:
> >>
> >>> On Feb 2, 2017, at 10:40 AM, Wayne Stambaugh  wrote:
> >>>
> >>> I don't have a strong opinion one way or another but you should never
> >>> underestimate the power of branding.  You can take the same car and
> >>> change the manufacturer and model names and the same person who liked
> >>> the car under one brand name will hate it under another brand name.  I
> >>> never understood this myself but I'm not a marketing guru.  
> >>
> >> A good example of this was when Ford decided that the Taurus model name 
> >> had run its course, so they changed the name to the Five Hundred. Sales 
> >> tanked, so they reverted back to Taurus.
> >>
> >> I don’t get it, either.
> >>
> >> -a
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [RFC] Application naming

[Chris Pavlina]

*scratches head* must have missed this...now I sure look like an ass for
submitting that suggestion as if nobody else had ;)

On Thu, Feb 02, 2017 at 07:33:01PM +0100, jp charras wrote:
> Le 02/02/2017 à 15:41, Pedro Martin a écrit :
> > Hi Chris,
> > 
> > Maybe "Composant Vers pcb"?  Component to pcb.
> 
> Pedro, you are the winner!
> Merci, Pedro.
> 
> > 
> > Related to the other names, I don't mind.
> > 
> > I vote for Bitmap2Component as Import Image in libedit and modedit.
> > 
> > Regards,
> > Pedro.
> > 
> 
> 
> -- 
> Jean-Pierre CHARRAS
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [RFC] Application naming

[Chris Pavlina]

I'm not getting these emails that JP is replying to that seem to be
addressing me...

On Thu, Feb 02, 2017 at 07:54:02PM +0100, jp charras wrote:
> Le 02/02/2017 à 19:13, Pedro Martin a écrit :
> > Hi Chris,
> > 
> > Beginners solve this issue... reading the manual.

That's not the point. Silly quirks like these give a bad first
impression. They make people look at our software and think it's
unprofessional and poorly put together, and then they go use other
software.

> > 
> > Why not keep the actual names only because JP named them this way?

Why not keep the software originally exactly as JP wrote it in the
beginning?

> > 
> > Regards,
> > Pedro.
> > 
> 
> Thanks Pedro.
> But the major issue which must be taken in account it not that.
> 
> Changing names has serious results:
> * Documentation and all the translations has to be modified.
> Opinion was asked to devs, to users, but not to doc writers/translators,and 
> this is really not fair.
> * Links on Internet cannot be modified, and there are a lot of hits regarding 
> kicad:
> I really agree Cvpcb is not a good name, but just try "Cvpcb" on Google .
> 
> Before changing these names you have to  *seriously* think to the results.
> (Think about that not only twice, but 3 times about that)

I don't think "it's hard for us" should ever be a reason not to improve
the software, only a reason for where it goes in the set of priorities.

> 
> -- 
> Jean-Pierre CHARRAS
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [RFC] Application naming

[Chris Pavlina]

Can I just copy all this and claim I wrote it? It sounds good ;)

On Feb 2, 2017 2:11 PM, "Jon Evans"  wrote:

> As a mostly user and occasional code hacker, here are my thoughts:
>
> The EDA tool industry is trending towards more integration, as many of the
> commercial products were originally formed from separate applications
> (often from separate companies originally).  I have used a number of
> commercial products and they are all this way. Having separate applications
> with separate lineage makes for less-than-optimal usability and workflow,
> and so all the vendors are trying to move towards integration -- either by
> putting everything in a single binary, or more often, keeping multiple
> binaries, but branding them together, making sure the UIs look consistent,
> and having lots of integration between them so it doesn't feel like a
> struggle to go between the different binaries for different parts of the
> EDA workflow.
>
> So, I'm in favor of rebranding the KiCad applications, because I think
> it's in line with the work you all are doing to improve the user workflow
> and improve the integration between the schematic, layout, and library
> workflows.  I also think it would be good to include the name change in a
> "marketing message" to the user community about a focus on the whole EDA
> workflow, not separate applications in silos.  Even if you technically can
> run the schematic editor separate from the PCB layout tool, if you have the
> *mindset* that they are all pieces of the same puzzle and need to fit
> together, it can influence the philosophy of the project.
>
> But, as JP mentioned, this would be a big deal in terms of documentation
> and resources on the web.  I would suggest that the problems can be
> overcome, but only if the communications and timing of the change is
> handled well.
>
> -Jon
>
> On Thu, Feb 2, 2017 at 1:54 PM, jp charras  wrote:
>
>> Le 02/02/2017 à 19:13, Pedro Martin a écrit :
>> > Hi Chris,
>> >
>> > Beginners solve this issue... reading the manual.
>> >
>> > Why not keep the actual names only because JP named them this way?
>> >
>> > Regards,
>> > Pedro.
>> >
>>
>> Thanks Pedro.
>> But the major issue which must be taken in account it not that.
>>
>> Changing names has serious results:
>> * Documentation and all the translations has to be modified.
>> Opinion was asked to devs, to users, but not to doc
>> writers/translators,and this is really not fair.
>> * Links on Internet cannot be modified, and there are a lot of hits
>> regarding kicad:
>> I really agree Cvpcb is not a good name, but just try "Cvpcb" on Google .
>>
>> Before changing these names you have to  *seriously* think to the results.
>> (Think about that not only twice, but 3 times about that)
>>
>> --
>> Jean-Pierre CHARRAS
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Application naming

[Chris Pavlina]

On Thu, Feb 02, 2017 at 09:55:59PM +0100, Clemens Koller wrote:
> Hi!
> 
> On 2017-02-02 20:20, Pedro Martin wrote:
> > There is still the secret of the meaning of the Ki of Kicad.
> 
> And what is the cv in cvpcb?
> 
> bitmap2component seems also quite limited in case we are going to support svg 
> import...
> in, sure, an "Import..." menu option.
> 
> If we want project branded names (which are not my primary choices) it might 
> help to get better results by using more selective keywords in online search 
> engines:
> 
> KiSchematic
> KiLayout
> KiLibrary
> KiEdit
> KiTool
> KiSimulator
> KiCalculator
> KiWhatever

Stop suggesting things that can't be easily pronounced! Sticking Ki-
prefixes to everything doesn't help with that.

I don't see why we need to SEO this. Instead of searching for "how to
FOO in eeschema", just search for "how to FOO in kicad"!

> 
> Ki in german is used for "Künstliche Intelligenz" (artificial 
> intelligence)... but i've heard KiCad was mocked as KinderCad as well.
> 
> Regards,
> 
> Clemens
> 
> 
> > Regards,
> > Pedro.
> > 
> > 
> > El 02/02/17 a las 19:35, Chris Pavlina escribió:
> >> *scratches head* must have missed this...now I sure look like an ass for
> >> submitting that suggestion as if nobody else had ;)
> >>
> >> On Thu, Feb 02, 2017 at 07:33:01PM +0100, jp charras wrote:
> >>> Le 02/02/2017 � 15:41, Pedro Martin a �crit :
> >>>> Hi Chris,
> >>>>
> >>>> Maybe "Composant Vers pcb"?  Component to pcb.
> >>>
> >>> Pedro, you are the winner!
> >>> Merci, Pedro.
> >>>
> >>>>
> >>>> Related to the other names, I don't mind.
> >>>>
> >>>> I vote for Bitmap2Component as Import Image in libedit and modedit.
> >>>>
> >>>> Regards,
> >>>> Pedro.
> >>>>
> >>>
> >>>
> >>> --
> >>> Jean-Pierre CHARRAS
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> Post to : kicad-developers@lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> >>
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

[Kicad-developers] tools/property_tree

[Chris Pavlina]

Most recent commit is: Update tools/property_tree support so it builds again.

Entirely out of curiosity...what is tools/property_tree actually for? I
don't get what its purpose is.

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

Re: [Kicad-developers] [RFC] Application naming

[Chris Pavlina]

On Thu, Feb 02, 2017 at 11:54:09PM +0100, Kristoffer Ödmark wrote:
> Why dont keep it dead simple, but still keeping the KiCAD brand?
> 
> I suggest prefix every subprogram with kicad- and then use a either
> extremely well known abbreviation (PCB) or a descriptive english word.
> 
> Examples:
> 
> eeschema-> kicad-schematics
> pcbnew  -> kicad-layouts
> 3d-viewer   -> kicad-3d
> gerb-viewer -> kicad-gerbers
> whatever-> kicad-whatever
> 
> 
> Self explaining names that are easy to use standalone as well as names that
> will not make a new users scoff and works well as binary filenames.

Yes, I like this. I was talking about the names in the UI, mostly - this
is a good companion to that.

> 
> I really dislike having entirely different names for the binary and the
> shortcut-key/desktop-shortcut like ubuntu and their decision to have
> "Document Viewer" as the name for evince etc.

Agreed.

> 
> - Kristoffer
> 
> On 2017-02-02 22:04, Chris Pavlina wrote:
> >On Thu, Feb 02, 2017 at 09:55:59PM +0100, Clemens Koller wrote:
> >>Hi!
> >>
> >>On 2017-02-02 20:20, Pedro Martin wrote:
> >>>There is still the secret of the meaning of the Ki of Kicad.
> >>
> >>And what is the cv in cvpcb?
> >>
> >>bitmap2component seems also quite limited in case we are going to support 
> >>svg import...
> >>in, sure, an "Import..." menu option.
> >>
> >>If we want project branded names (which are not my primary choices) it 
> >>might help to get better results by using more selective keywords in online 
> >>search engines:
> >>
> >>KiSchematic
> >>KiLayout
> >>KiLibrary
> >>KiEdit
> >>KiTool
> >>KiSimulator
> >>KiCalculator
> >>KiWhatever
> >
> >Stop suggesting things that can't be easily pronounced! Sticking Ki-
> >prefixes to everything doesn't help with that.
> >
> >I don't see why we need to SEO this. Instead of searching for "how to
> >FOO in eeschema", just search for "how to FOO in kicad"!
> >
> >>
> >>Ki in german is used for "Künstliche Intelligenz" (artificial 
> >>intelligence)... but i've heard KiCad was mocked as KinderCad as well.
> >>
> >>Regards,
> >>
> >>Clemens
> >>
> >>
> >>>Regards,
> >>>Pedro.
> >>>
> >>>
> >>>El 02/02/17 a las 19:35, Chris Pavlina escribió:
> >>>>*scratches head* must have missed this...now I sure look like an ass for
> >>>>submitting that suggestion as if nobody else had ;)
> >>>>
> >>>>On Thu, Feb 02, 2017 at 07:33:01PM +0100, jp charras wrote:
> >>>>>Le 02/02/2017 � 15:41, Pedro Martin a �crit :
> >>>>>>Hi Chris,
> >>>>>>
> >>>>>>Maybe "Composant Vers pcb"?  Component to pcb.
> >>>>>
> >>>>>Pedro, you are the winner!
> >>>>>Merci, Pedro.
> >>>>>
> >>>>>>
> >>>>>>Related to the other names, I don't mind.
> >>>>>>
> >>>>>>I vote for Bitmap2Component as Import Image in libedit and modedit.
> >>>>>>
> >>>>>>Regards,
> >>>>>>Pedro.
> >>>>>>
> >>>>>
> >>>>>
> >>>>>--
> >>>>>Jean-Pierre CHARRAS
> >>>>>
> >>>>>___
> >>>>>Mailing list: https://launchpad.net/~kicad-developers
> >>>>>Post to : kicad-developers@lists.launchpad.net
> >>>>>Unsubscribe : https://launchpad.net/~kicad-developers
> >>>>>More help   : https://help.launchpad.net/ListHelp
> >>>>
> >>>
> >>>___
> >>>Mailing list: https://launchpad.net/~kicad-developers
> >>>Post to : kicad-developers@lists.launchpad.net
> >>>Unsubscribe : https://launchpad.net/~kicad-developers
> >>>More help   : https://help.launchpad.net/ListHelp
> >>>
> >>
> >>___
> >>Mailing list: https://launchpad.net/~kicad-developers
> >>Post to : kicad-developers@lists.launchpad.net
> >>Unsubscribe : https://launchpad.net/~kicad-developers
> >>More help   : https://help.launchpad.net/ListHelp
> >
> >___
> >Mailing list: https://launchpad.net/~kicad-developers
> >Post to : kicad-developers@lists.launchpad.net
> >Unsubscribe : https://launchpad.net/~kicad-developers
> >More help   : https://help.launchpad.net/ListHelp
> >
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Footprint Association and Filtering

[Chris Pavlina]

I don't have a chance to test this right now, but I REALLY like the
idea. As a (non-official) library maintainer I'd use the hell out of
this.

On Fri, Feb 03, 2017 at 10:40:30AM +1100, Oliver Walters wrote:
> bump :)
> 
> On Thu, Feb 2, 2017 at 1:28 AM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
> 
> > Hi all,
> >
> > Currently a lot of the .pretty libs have the library name (e.g.
> > "Socket_Strips.pretty") duplicated (or partly duplicated) in the footprint
> > name.
> >
> > This is (mainly) required to allow the footprint filtering in CvPCB to
> > match the filters defined for components.
> >
> > One case where this is very annoying is for the various
> > Connectors_xxx.pretty libraries (JST / Hirose / Harwin / etc). To reduce
> > the length of the filenames, a while ago the decision was made to remove
> > the Connector_ prefix from the individual filenames.
> >
> > However, this now means that generic connector symbols have to have
> > multiple footprint filters to match the various connector footprints.
> >
> > Looking through the code I saw that originally there was the option to
> > include the LibraryName: in the search string (which is what I wanted to
> > implement). However it was commented out as at some time a developer has
> > decided that this behaviour was "messy".
> >
> > I have attached a patch that does the following:
> >
> > 1. If a footprint filter contains a : (colon) character, then the filter
> > is matched against the pattern :
> > 2. If there is *no* : (colon) character present, then it is matched
> > against  (this is the current behaviour, and so will not
> > break any current footprint filters.
> > 3. The same behaviour applies for the manual filter string in CvPCB
> >
> > If merged, this will allow the .kicad_mod files to have significantly
> > shorter names and we can use the footprint association filters more
> > intelligently.
> >
> > Cheers,
> > Oliver
> >


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

[Kicad-developers] [RFC] Footprints in component selector

[Chris Pavlina]

Hi,

There's a feature I'd like to contribute if nobody objects (and if
nobody is working on something similar - let me know!). This should not
change or impede the existing standard KiCad workflow, but should help
out those who do it a bit differently.

I would like to add another section to the component selector in
eeschema. This section would have footprint preview, footprint 3D
preview, and footprint selection, behaving thus:

- If the component already has a footprint selected in the Footprint
  field, display that. Otherwise blank

- Dropdown box allows the user the choose between:
- Contents of the Footprint field
- Everything matching the component's footprint filter list
- "Other..." which calls up the full FP selector

This way, if the part already has a footprint selected the user can see
it, and if it has a list of acceptable parts, the user can choose it,
before placing the part in the schematic.

If the part has no footprint spec at all, these panels would be blank -
the user can still pick "Other" and choose one, or just place the part
directly with no change to the workflow.

-- 
Chris

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

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

[Chris Pavlina]

Nope, this doesn't fix the weird behavior. However, I have noticed that
it only happens in some specific case (the conditions of which I have
yet to properly identify), I just got lucky and found that case first.
Here are steps that should reproduce this:

1) Create and load a new project.
2) Open eeschema. Remove all libs, then add the library at [1], [2].
3) Open libedit and choose the Atmel library I attached.
4) Load component ATMEGA168A-AU.
5) Delete unit B of ATSAM4E16CA-AU.

Follow those steps *exactly* and it should happen.

Also, I'm not really happy with how units are being handled here. If I
select a single unit, it shouldn't delete the whole part - that's
misleading. If it's too troublesome to implement single-unit delete, we
should add a mode to the component selector widget to disable display of
units.

**However**, even if we just drop the unit selection from the dialog, I
really think it might be worth looking into why this happens when using
it...this is weird, may indicate some deeper bug...

[1] https://misc.c4757p.com/Atmel.lib
[2] https://misc.c4757p.com/Atmel.dcm

On Sat, Feb 04, 2017 at 07:14:42PM +1100, Oliver Walters wrote:
> Chris,
> 
> I have attached an updated patch that (at least on my end) fixes the
> unit-deletion bug.
> 
> Can you please confirm that you no longer see the erroneous behaviour?
> 
> I have also included your preselect patch.
> 
> Cheers, Oliver
> 
> On Thu, Feb 2, 2017 at 10:33 PM, Chris Pavlina 
> wrote:
> 
> > On second thought, I'm reverting it, I found a weird bug. Apologies for
> > the accidental push, I'll be more careful next time.
> >
> > I *was* investigating what I thought was a minor bug (i.e. didn't keep
> > me from pushing the patch), but I found this. To reproduce:
> >
> > 1) Select a single-unit part
> > 2) Delete one unit of a different, multi-unit part
> >
> > The current part gets messed up, like: https://misc.c4757p.com/
> > messed-up-part.png
> >
> > Not sure if that's a rendering issue or if the pins are actually gone.
> >
> > What I *was* looking at is that I thought deleting a unit would just
> > delete the entire part, and I was going to suggest one of two possible
> > fixes:
> >
> > 1) Modify the component selector to have a mode where it doesn't delete
> > units
> > 2) Actually delete the unit, adding code to filter the part and remove
> > anything on the unit to be deleted and reorder subsequent units.
> >
> > I was going to offer to write #2 myself, because that'd be really useful
> > to me. But you should probably fix the bug described above first and
> > resubmit.
> >
> > ALSO, I was going to contribute a small patch to this to preselect the
> > current component just like I added to Load Component recently - I
> > attached a diff for that in case you want it, I had it all done before
> > noticing this.
> >
> > On Thu, Feb 02, 2017 at 06:15:57AM -0500, Chris Pavlina wrote:
> > > Oops, I didn't mean to push this one at the same time, clumsy push
> > > command - but it looks good too. I always hated that delete dialog.
> > > Thank you!
> > >
> > > On Thu, Feb 02, 2017 at 09:42:01PM +1100, Oliver Walters wrote:
> > > > The attached patch removes the clunky "Delete Single Part" dialog in
> > > > libedit, and re-uses the existing part-selector to find a component to
> > > > delete.
> > > >
> > > > Now, the user can use the filter tool to select a component for
> > deletion.
> > >
> >


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

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

[Chris Pavlina]

Awesome! Glad it was something simple. Everything else looks good - I
just pushed it to master. I also pushed a commit to remove unit display
from this dialog entirely, since there's no support for deleting
individual units. Apologies for invalidating the work you did to sniff
out this bug - as it seemed intermittent I wasn't 100% sure it *was*
unit-related :\


On Sun, Feb 05, 2017 at 03:21:18PM +1100, Oliver Walters wrote:
> Ok, I have found the cause of this behaviour:
> 
> As the selection dialog's true purpose is to *select* a component, it was
> setting the m_unit* variable to the selected unit. If the currently
> selected part did not have at last as many units, it was showing a
> non-existent view of the selected part.
> 
> This has been addressed in the attached version of the patch.
> 
> Hopefully no more errors!
> 
> On Sun, Feb 5, 2017 at 12:36 AM, Chris Pavlina 
> wrote:
> 
> > Nope, this doesn't fix the weird behavior. However, I have noticed that
> > it only happens in some specific case (the conditions of which I have
> > yet to properly identify), I just got lucky and found that case first.
> > Here are steps that should reproduce this:
> >
> > 1) Create and load a new project.
> > 2) Open eeschema. Remove all libs, then add the library at [1], [2].
> > 3) Open libedit and choose the Atmel library I attached.
> > 4) Load component ATMEGA168A-AU.
> > 5) Delete unit B of ATSAM4E16CA-AU.
> >
> > Follow those steps *exactly* and it should happen.
> >
> > Also, I'm not really happy with how units are being handled here. If I
> > select a single unit, it shouldn't delete the whole part - that's
> > misleading. If it's too troublesome to implement single-unit delete, we
> > should add a mode to the component selector widget to disable display of
> > units.
> >
> > **However**, even if we just drop the unit selection from the dialog, I
> > really think it might be worth looking into why this happens when using
> > it...this is weird, may indicate some deeper bug...
> >
> > [1] https://misc.c4757p.com/Atmel.lib
> > [2] https://misc.c4757p.com/Atmel.dcm
> >
> > On Sat, Feb 04, 2017 at 07:14:42PM +1100, Oliver Walters wrote:
> > > Chris,
> > >
> > > I have attached an updated patch that (at least on my end) fixes the
> > > unit-deletion bug.
> > >
> > > Can you please confirm that you no longer see the erroneous behaviour?
> > >
> > > I have also included your preselect patch.
> > >
> > > Cheers, Oliver
> > >
> > > On Thu, Feb 2, 2017 at 10:33 PM, Chris Pavlina 
> > > wrote:
> > >
> > > > On second thought, I'm reverting it, I found a weird bug. Apologies for
> > > > the accidental push, I'll be more careful next time.
> > > >
> > > > I *was* investigating what I thought was a minor bug (i.e. didn't keep
> > > > me from pushing the patch), but I found this. To reproduce:
> > > >
> > > > 1) Select a single-unit part
> > > > 2) Delete one unit of a different, multi-unit part
> > > >
> > > > The current part gets messed up, like: https://misc.c4757p.com/
> > > > messed-up-part.png
> > > >
> > > > Not sure if that's a rendering issue or if the pins are actually gone.
> > > >
> > > > What I *was* looking at is that I thought deleting a unit would just
> > > > delete the entire part, and I was going to suggest one of two possible
> > > > fixes:
> > > >
> > > > 1) Modify the component selector to have a mode where it doesn't delete
> > > > units
> > > > 2) Actually delete the unit, adding code to filter the part and remove
> > > > anything on the unit to be deleted and reorder subsequent units.
> > > >
> > > > I was going to offer to write #2 myself, because that'd be really
> > useful
> > > > to me. But you should probably fix the bug described above first and
> > > > resubmit.
> > > >
> > > > ALSO, I was going to contribute a small patch to this to preselect the
> > > > current component just like I added to Load Component recently - I
> > > > attached a diff for that in case you want it, I had it all done before
> > > > noticing this.
> > > >
> > > > On Thu, Feb 02, 2017 at 06:15:57AM -0500, Chris Pavlina wrote:
> > > > > Oops, I didn't mean to push this one at the same time, clumsy push
> > > > > command - but it looks good too. I always hated that delete dialog.
> > > > > Thank you!
> > > > >
> > > > > On Thu, Feb 02, 2017 at 09:42:01PM +1100, Oliver Walters wrote:
> > > > > > The attached patch removes the clunky "Delete Single Part" dialog
> > in
> > > > > > libedit, and re-uses the existing part-selector to find a
> > component to
> > > > > > delete.
> > > > > >
> > > > > > Now, the user can use the filter tool to select a component for
> > > > deletion.
> > > > >
> > > >
> >
> >


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

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

[Chris Pavlina]

Hi,

This patch adds more information to the component selector. In
particular, it adds two things:

1. Display component description even for aliases.
2. Display all fields.

Screenshot: https://misc.c4757p.com/choose-component.png

It should be ready for commit, just pending review.

Upcoming changes:

1. Make datasheet a clickable link
2. Add footprint preview/selection discussed earlier
3. Rearrange dialog to make this all fit

-- 
Chris
>From bd18e1c54e4cdd8ae42d185410eabd42f7c4ef1b Mon Sep 17 00:00:00 2001
From: Chris Pavlina 
Date: Sun, 5 Feb 2017 14:18:29 -0500
Subject: [PATCH] Display more information in component selector

---
 common/string.cpp | 26 ++-
 eeschema/dialogs/dialog_choose_component.cpp  | 95 +--
 eeschema/dialogs/dialog_choose_component_base.cpp | 10 +--
 eeschema/dialogs/dialog_choose_component_base.fbp | 27 +++
 eeschema/dialogs/dialog_choose_component_base.h   |  5 +-
 eeschema/lib_field.cpp|  4 +-
 eeschema/lib_field.h  |  2 +-
 include/kicad_string.h|  5 ++
 8 files changed, 104 insertions(+), 70 deletions(-)

diff --git a/common/string.cpp b/common/string.cpp
index d0bfe33ed..8f35b83d6 100644
--- a/common/string.cpp
+++ b/common/string.cpp
@@ -1,7 +1,7 @@
 /*
  * This program source code file is part of KiCad, a free EDA CAD application.
  *
- * Copyright (C) 2004 KiCad Developers, see change_log.txt for contributors.
+ * Copyright (C) 2004-2017 KiCad Developers, see AUTHORS.txt for contributors.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -167,6 +167,30 @@ std::string EscapedUTF8( const wxString& aString )
 }
 
 
+wxString EscapedHTML( const wxString& aString )
+{
+wxString converted;
+
+for( wxUniChar c: aString )
+{
+if( c == '\"' )
+converted += """;
+else if( c == '\'' )
+converted += "'";
+else if( c == '&' )
+converted += "&";
+else if( c == '<' )
+converted += "<";
+else if( c == '>' )
+converted += ">";
+else
+converted += c;
+}
+
+return converted;
+}
+
+
 char* StrPurge( char* text )
 {
 static const char whitespace[] = " \t\n\r\f\v";
diff --git a/eeschema/dialogs/dialog_choose_component.cpp b/eeschema/dialogs/dialog_choose_component.cpp
index 04728a0d5..640182713 100644
--- a/eeschema/dialogs/dialog_choose_component.cpp
+++ b/eeschema/dialogs/dialog_choose_component.cpp
@@ -2,7 +2,7 @@
  * This program source code file is part of KiCad, a free EDA CAD application.
  *
  * Copyright (C) 2014 Henner Zeller 
- * Copyright (C) 2016 KiCad Developers, see AUTHORS.txt for contributors.
+ * Copyright (C) 2016-2017 KiCad Developers, see AUTHORS.txt for contributors.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 // Tree navigation helpers.
 static wxTreeItemId GetPrevItem( const wxTreeCtrl& tree, const wxTreeItemId& item );
@@ -44,7 +45,6 @@ DIALOG_CHOOSE_COMPONENT::DIALOG_CHOOSE_COMPONENT( SCH_BASE_FRAME* aParent, const
 m_external_browser_requested = false;
 m_received_doubleclick_in_tree = false;
 m_search_container->SetTree( m_libraryComponentTree );
-m_componentDetails->SetEditable( false );
 m_componentView->SetLayoutDirection( wxLayout_LeftToRight );
 
 m_libraryComponentTree->ScrollTo( m_libraryComponentTree->GetFocusedItem() );
@@ -221,70 +221,83 @@ bool DIALOG_CHOOSE_COMPONENT::updateSelection()
 
 m_componentView->Refresh();
 
-m_componentDetails->Clear();
+m_componentDetails->SetPage( wxEmptyString );
 
 if( selection == NULL )
 return false;
 
 m_componentDetails->Freeze();
-wxFont font_normal = m_componentDetails->GetFont();
-wxFont font_bold = m_componentDetails->GetFont();
-font_bold.SetWeight( wxFONTWEIGHT_BOLD );
-
-wxTextAttr headline_attribute;
-headline_attribute.SetFont( font_bold );
-wxTextAttr text_attribute;
-text_attribute.SetFont( font_normal );
 
 const wxString name = selection->GetName();
+wxString description = selection->GetDescription();
 
 if ( !name.empty() )
 {
-m_componentDetails->SetDefaultStyle( headline_attribute );
-m_componentDetails->AppendText( name );
+m_componentDetails->AppendToPage( "" );
+m_componentDetails->AppendToPage( EscapedHTML( name ) );
+m_componentDetails->AppendToPage( "" );
 }
 
-const wxString descriptio

[Kicad-developers] I'm working on a nice thing

[Chris Pavlina]

Still very early... I call it "componentchoosernew"

https://misc.c4757p.com/componentchoosernew.png

-- 
Chris

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

Re: [Kicad-developers] I'm working on a nice thing

[Chris Pavlina]

Awesome! I was going to do it last night but spent so much time trying
to make wx behave that I never got around to it. Thank you!

On Mon, Feb 06, 2017 at 10:38:55AM +0100, Tomasz Wlostowski wrote:
> On 06.02.2017 03:52, Chris Pavlina wrote:
> > Still very early... I call it "componentchoosernew"
> > 
> > https://misc.c4757p.com/componentchoosernew.png
> > 
> 
> Hi Chris,
> 
> If you have not yet started writing the footprint preview widget, I
> wrote one some time ago, you can use it if you want :)
> 
> https://github.com/twlostow/kicad-dev/blob/tom-footprint-preview-panel/pcbnew/footprint_preview_panel.cpp
> 
> Cheers,
> T.

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

Re: [Kicad-developers] I'm working on a nice thing

[Chris Pavlina]

Eagle converts should like it, it's rather inspired by their component
selector... ;)

It's coming together nicely. Footprint preview/selection won't be done
until probably the end of the week, but for now I just got clickable
datasheet links too :)

Wayne, once I get everything *but* the footprint preview done, would you
be okay with me ->Hide()ing the footprint panel and pushing to master as
it is? Even without that it's an improvement - no more monospace
faux-columns and much friendler data in the info box.

On Mon, Feb 06, 2017 at 01:54:03PM +0100, Tomasz Wlostowski wrote:
> On 06.02.2017 12:29, Chris Pavlina wrote:
> > Awesome! I was going to do it last night but spent so much time trying
> > to make wx behave that I never got around to it. Thank you!
> > 
> The feature you're working on is also awesome! Looking forward to see it
> in the master branch!
> 
> Tom
> > On Mon, Feb 06, 2017 at 10:38:55AM +0100, Tomasz Wlostowski wrote:
> >> On 06.02.2017 03:52, Chris Pavlina wrote:
> >>> Still very early... I call it "componentchoosernew"
> >>>
> >>> https://misc.c4757p.com/componentchoosernew.png
> >>>
> >>
> >> Hi Chris,
> >>
> >> If you have not yet started writing the footprint preview widget, I
> >> wrote one some time ago, you can use it if you want :)
> >>
> >> https://github.com/twlostow/kicad-dev/blob/tom-footprint-preview-panel/pcbnew/footprint_preview_panel.cpp
> >>
> >> Cheers,
> >> T.
> 

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

Re: [Kicad-developers] I'm working on a nice thing

[Chris Pavlina]

On Mon, Feb 06, 2017 at 02:16:26PM +, Mário Luzeiro wrote:
> Hi Chris,
> 
> What should be in that empty frame square below "Footprint"? (the footprint?) 
> and what is on the dropdown box?

Empty frame will have a footprint preview, both 2D and 3D (switchable).
The dropbox allows footprint selection.

> 
> Could I suggest that you try some other arrangement on the layout of that ui?
> The component filtered list, as you can see, in a regular use of the filter 
> it should output a short list. So you will get all that white space not used. 
> So I may prefer that it can be used by the other information..?.

I like this. I'm not sure if I like it *better* - I think I'll try
running both arrangements locally and see how they really feel in
action.

> 
> My suggestion:
> - The filter edit line only use the left side aligned with the component list 
> (so you will get that space of the empty line on the top) and you can use 
> that are for the component draw.
> - Place the component text info on the left below and aligned on same column 
> as the component list. And maybe you can use it more (vertical) compact as 
> there are some blank space there between the lines.
> - Place the Footprint frame below and aligned (same column) with component so 
> it will use the space of the component info (that I suggested to be placed on 
> the left)
> 
> oks.. its easier to look on the attached image ;)
> 
> Mario
> 
> From: Kicad-developers 
> [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of 
> Chris Pavlina [pavlina.ch...@gmail.com]
> Sent: 06 February 2017 02:52
> To: kicad-developers@lists.launchpad.net
> Subject: [Kicad-developers] I'm working on a nice thing
> 
> Still very early... I call it "componentchoosernew"
> 
> https://misc.c4757p.com/componentchoosernew.png
> 
> --
> Chris
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


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

Re: [Kicad-developers] [RFC] Application naming

[Chris Pavlina]

Well, the user response on the forum has been overwhelmingly in favor:

https://forum.kicad.info/t/non-devs-what-do-you-think-of-the-app-names/5147

That said, I'm in no hurry to do this - like I said, I'm just seeking
out opinions to know whether people agree with me or not. I'd like to
see it happen someday, but it's by no means high-priority.


On Thu, Feb 02, 2017 at 12:46:37PM -0500, Chris Pavlina wrote:
> I think I am going to seek out some user views on this. As usual it
> doesn't do us much good to speculate about what non-developers want.
> 
> I will say that so far two users have told me that the weird names
> confused them as beginners, and only established developers have argued
> in favor of keeping them. ;)
> 
> On Thu, Feb 02, 2017 at 12:40:10PM -0500, Wayne Stambaugh wrote:
> > I don't have a strong opinion one way or another but you should never
> > underestimate the power of branding.  You can take the same car and
> > change the manufacturer and model names and the same person who liked
> > the car under one brand name will hate it under another brand name.  I
> > never understood this myself but I'm not a marketing guru.  User are
> > familiar with the application names and given that the applications can
> > still be run in stand alone mode, it may make sense to keep them.
> > 
> > On 2/2/2017 8:56 AM, Chris Pavlina wrote:
> > > I admit I'm getting self-indulgent here, this request is definitely a
> > > bit "what Chris would do if made Dictator of KiCad", but... just testing
> > > the waters here:
> > > 
> > > What do people think about, for either the 5.0 or 6.0 release, ditching
> > > the old application names, in favor of everything being one tool under
> > > the "KiCad" roof:
> > > 
> > > Eeschema-> Schematic editor
> > > Pcbnew  -> PCB editor, or Layout editor, or Board editor
> > > Cvpcb   -> "Assign Footprints"
> > > Pl Editor   -> Title block editor
> > > Bitmap2Component-> Remove as independent app, make "Import image" in
> > >libedit and modedit
> > 
> > Rename or not, this change makes sense to me.  Being able to directly
> > import an image as a symbol or footprint would be an improvement over
> > the way it's currently done.  Although it would probably be useful for
> > library developers to be able to run it as a stand alone app as well.
> > 
> > > 
> > > I know this one is going to be controversial, but I don't really see the
> > > point of these old names. They're... weird. Cvpcb - what does that even
> > > mean? :P
> > > 
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] I'm working on a nice thing

[Chris Pavlina]

On Mon, Feb 06, 2017 at 02:55:35PM -0500, Wayne Stambaugh wrote:
> On 2/6/2017 7:59 AM, Chris Pavlina wrote:
> > Eagle converts should like it, it's rather inspired by their component
> > selector... ;)
> > 
> > It's coming together nicely. Footprint preview/selection won't be done
> > until probably the end of the week, but for now I just got clickable
> > datasheet links too :)
> > 
> > Wayne, once I get everything *but* the footprint preview done, would you
> > be okay with me ->Hide()ing the footprint panel and pushing to master as
> > it is? Even without that it's an improvement - no more monospace
> > faux-columns and much friendler data in the info box.
> 
> Please give me a chance to look at it.  I'll try to get too it by the
> end of the week.

Take your time, I know what traveling does to your schedule :)

> 
> Cheers,
> 
> Wayne
> 
> > 
> > On Mon, Feb 06, 2017 at 01:54:03PM +0100, Tomasz Wlostowski wrote:
> >> On 06.02.2017 12:29, Chris Pavlina wrote:
> >>> Awesome! I was going to do it last night but spent so much time trying
> >>> to make wx behave that I never got around to it. Thank you!
> >>>
> >> The feature you're working on is also awesome! Looking forward to see it
> >> in the master branch!
> >>
> >> Tom
> >>> On Mon, Feb 06, 2017 at 10:38:55AM +0100, Tomasz Wlostowski wrote:
> >>>> On 06.02.2017 03:52, Chris Pavlina wrote:
> >>>>> Still very early... I call it "componentchoosernew"
> >>>>>
> >>>>> https://misc.c4757p.com/componentchoosernew.png
> >>>>>
> >>>>
> >>>> Hi Chris,
> >>>>
> >>>> If you have not yet started writing the footprint preview widget, I
> >>>> wrote one some time ago, you can use it if you want :)
> >>>>
> >>>> https://github.com/twlostow/kicad-dev/blob/tom-footprint-preview-panel/pcbnew/footprint_preview_panel.cpp
> >>>>
> >>>> Cheers,
> >>>> T.
> >>
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] I'm working on a nice thing

[Chris Pavlina]

Preview at g...@github.com:cpavlina/kicad branch componentchooser.
Footprint part still pending.

On Sun, Feb 05, 2017 at 09:52:03PM -0500, Chris Pavlina wrote:
> Still very early... I call it "componentchoosernew"
> 
> https://misc.c4757p.com/componentchoosernew.png
> 
> -- 
> Chris

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

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

[Chris Pavlina]

I'm working on an eight-layer board and really can't wait for this to
hit pcbnew too. It's bloody impossible to tell layers apart with KiCad's
state-of-the-80s-art color system.

On Mon, Feb 06, 2017 at 10:03:11PM -0500, 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 handle arbitrary colors.  I
> think this is important and the right path for the future, but since it's a
> significant change, I wanted to get buy-in before going any farther down
> this road.  I can understand the reasons for using an enum for
> color--especially since it lets the developers restrict the colors to those
> that will work well with the drawing technique of the legacy canvases.
> But, since the new canvases will have no problem supporting arbitrary
> colors, I think it makes sense to start setting up the groundwork for that.
> 
> In my test code, I have replaced EDA_COLOR_T with wxColour, since that is
> used internally in a few places already, and it was pretty simple (although
> somewhat time-consuming) to replace all usages.  wxColour has the nice
> property of serializing/deserializing from hex color codes like "#80FC62"
> so that's what I use for storing in the settings for now (eventually I
> think color settings should be in their own files so that they can be
> traded by users).  Plus, there is a canned wxColourPicker widget that I can
> use in place of the custom color picker buttons that are used in the
> settings today.
> 
> You can see some screenshots of the (work-in-progress) settings dialog
> changes, and an example of a custom color theme in the schematic editor,
> here:
> http://imgur.com/a/MxMmb
> 
> So, any feedback from the core team?  Any reason why I shouldn't move
> forward with preparing a patch to move from EDA_COLOR_T to wxColour across
> the board?
> 
> Best,
> Jon


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

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

[Chris Pavlina]

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
> 
> 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 combination between colors (for transparency: the 
> OR operation.)
> 
> In other to achieve a good result, you cannot use any color for layers.
> You have to choose a set of colors which allows this good result.
> (by adjusting the 32 bits binary values of each color to ensure a good result 
> when 2 or more color
> values are ORed)
> 
> There are not a lot of suitable binary values.
> In all cases the background must be black (when using OR or transparency).
> 
> Note also Eeschema does not use currently transparency, and the choice of 
> colors is not critical.
> 
> > 
> > On 7 February 2017 at 17:00, Chris Pavlina  wrote:
> >> I'm working on an eight-layer board and really can't wait for this to
> >> hit pcbnew too. It's bloody impossible to tell layers apart with KiCad's
> >> state-of-the-80s-art color system.
> 
> I have made a few boards with 8 and one with 16 layers.
> There is no perfect way to see all layers.
> 
> I used Pcbnew and Altium (in a company which has a Altium license) to design 
> a 8 layers board (2
> very similar boards, one with Pcbnew, the other with Altium, because this 
> company used Altium).
> 
> Altium allows arbitrary colors and transparency, but a 8 layers board is not 
> easy to manage.
> 
> So do not expect allowing arbitrary colors and transparency will fix your 
> problem.
> (In the best case, it slightly helps).
> 
> 
> Having said that, using a selected set of colors does not imply using 
> EDA_COLOR_T in Kicad code.
> wxColor can be used instead of.
> 
> This is only the *color choice* in Pcbnew which is constrained in legacy 
> canvas.
> 
> EDA_COLOR_T comes from the fact the legacy graphic primitives where written 
> for an other library,
> not for wxWidgets.
> (Kicad was started before wxWidgets exists)
> 
> >>
> >> On Mon, Feb 06, 2017 at 10:03:11PM -0500, 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 handle arbitrary colors.  I
> >>> think this is important and the right path for the future, but since it's 
> >>> a
> >>> significant change, I wanted to get buy-in before going any farther down
> >>> this road.  I can understand the reasons for using an enum for
> >>> color--especially since it lets the developers restrict the colors to 
> >>> those
> >>> that will work well with the drawing technique of the legacy canvases.
> >>> But, since the new canvases will have no problem supporting arbitrary
> >>> colors, I think it makes sense to start setting up the groundwork for 
> >>> that.
> >>>
> >>> In my test code, I have replaced EDA_COLOR_T with wxColour, since that is
> >>> used internally in a few places already, and it was pretty simple 
> >>> (although
> >>> somewhat time-consuming) to replace all usages.  wxColour has the nice
> >>> property of serializing/deserializing from hex color codes like "#80FC62"
> >>> so that's what I use for storing in the settings for now (eventually I
> >>> think color settings should be in their own files so that they can be
> >>> traded by users).  Plus, there is a canned wxColourPicker widget that I 
> >>> can
> >>> use in place of the custom color picker buttons that are used in the
> >>> settings today.
> >>>
> >>> You can see some screenshots of the (work-in-progress) settings dialog
> >>> changes, and an example of a custom color theme in the schematic editor,
> >>> here:
> >>> http://imgur.com/a/MxMmb
> >>>
> >>> So, any feedback from the core team?  Any reason why I shouldn't move
> >>> forward with preparing a patch to move from EDA_COLOR_T to wxColour across
> >>> the boa

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

[Chris Pavlina]

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, Kristoffer Ödmark wrote:
> 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:
> >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 have a few symbols that do that
> >too).
> >
> >On Tue, Feb 7, 2017 at 7:57 PM, Kristoffer Ödmark
> >mailto:kristofferodmar...@gmail.com>> wrote:
> >
> >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.
> >
> >- Kristoffer
> >
> >
> >On 02/07/2017 09:47 AM, Oliver Walters wrote:
> >
> >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 affect the ability of invisible power-pins to
> >automatically connect to global power labels
> >
> >Is the current behavior of connecting invisible pins to wire
> >endpoints
> >desired? Or is it just an aberration?
> >
> >If there is a very good reason that pins not visible in the
> >schematic
> >are able to be connected silently?
> >
> >before: http://i.imgur.com/3gModvW.png
> >
> >after: http://i.imgur.com/r8O7c3Y.png
> >
> >(Note the 'dangling' wire-end indication)
> >
> >Cheers,
> >Oliver
> >
> >
> >
> >
> >___
> >Mailing list: https://launchpad.net/~kicad-developers
> >
> >Post to : kicad-developers@lists.launchpad.net
> >
> >Unsubscribe : https://launchpad.net/~kicad-developers
> >
> >More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
> >--
> > -Kristoffer
> >
> >___
> >Mailing list: https://launchpad.net/~kicad-developers
> >
> >Post to : kicad-developers@lists.launchpad.net
> >
> >Unsubscribe : https://launchpad.net/~kicad-developers
> >
> >More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
> 
> -- 
>  -Kristoffer
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

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

[Chris Pavlina]

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 clearly don't get that, as
they think invisible pins are a nice way to represent no-connect pins
visibly in libedit that don't show up in and clutter the schematic. Just
had to clean a bunch of those out of my own library that someone
submitted, and someone else said the official KiCad libs have a bunch
too. Not sure why you think it's so obvious when actual usage shows it's
not.

> 
> I mean, otherwise there could be a stacked pin instead. Im not saying that
> invisible pins are good practise, but thats not really for me to say.
> 
> What is silly is having invisible pins working as no-pins except if they are
> a stacked pin, well that doesnt sound clear to me.

What's silly is using them that way when you could just hide the pin
text. It's only the text that collides and makes them look bad.

Compromise: don't connect invisible pins of type "no connect". Remove
the stupidity in the design without screwing the people who depended on
it.

> 
> -Kristoffer
> 
> On 2017-02-07 12:33, Chris Pavlina wrote:
> >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, Kristoffer Ödmark wrote:
> >>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:
> >>>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 have a few symbols that do that
> >>>too).
> >>>
> >>>On Tue, Feb 7, 2017 at 7:57 PM, Kristoffer Ödmark
> >>>mailto:kristofferodmar...@gmail.com>> wrote:
> >>>
> >>>   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.
> >>>
> >>>   - Kristoffer
> >>>
> >>>
> >>>   On 02/07/2017 09:47 AM, Oliver Walters wrote:
> >>>
> >>>   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 affect the ability of invisible power-pins to
> >>>   automatically connect to global power labels
> >>>
> >>>   Is the current behavior of connecting invisible pins to wire
> >>>   endpoints
> >>>   desired? Or is it just an aberration?
> >>>
> >>>   If there is a very good reason that pins not visible in the
> >>>   schematic
> >>>   are able to be connected silently?
> >>>
> >>>   before: http://i.imgur.com/3gModvW.png
> >>>
> >>>   after: http://i.imgur.com/r8O7c3Y.png
> >>>
> >>>   (Note the 'dangling' wire-end indication)
> >>>
> >>>   Cheers,
> >>>   Oliver
> >>>
> >>>
> >>>
> >>>
> >>>   ___
> >>>   M

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

[Chris Pavlina]

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 invisible pin
> that is not stacked?
> 
> And as you said, you had to clean out parts that had invisible pins that
> that was supposed not to be connected. Fault of creating the symbol, I think
> the symbol should be reworked instead of hardcoding around faulty symbols.
> 
> There are many silly ways of using stuff, I dont agree that having a
> visibility checkbox determining if it is connectable is the right way,
> rather have a pop-up warning that says that you have connected to an
> invisible pin.

...you don't think kicad has enough popup warnings /yet/?! Are you
kidding?

The feature is confusing, it should be reworked to be less confusing.
Not leave it confusing and yell at the user when he gets confused.

> 
> - Kristoffer
> 
> On 2017-02-07 12:50, Chris Pavlina wrote:
> >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 clearly don't get that, as
> >they think invisible pins are a nice way to represent no-connect pins
> >visibly in libedit that don't show up in and clutter the schematic. Just
> >had to clean a bunch of those out of my own library that someone
> >submitted, and someone else said the official KiCad libs have a bunch
> >too. Not sure why you think it's so obvious when actual usage shows it's
> >not.
> >
> >>
> >>I mean, otherwise there could be a stacked pin instead. Im not saying that
> >>invisible pins are good practise, but thats not really for me to say.
> >>
> >>What is silly is having invisible pins working as no-pins except if they are
> >>a stacked pin, well that doesnt sound clear to me.
> >
> >What's silly is using them that way when you could just hide the pin
> >text. It's only the text that collides and makes them look bad.
> >
> >Compromise: don't connect invisible pins of type "no connect". Remove
> >the stupidity in the design without screwing the people who depended on
> >it.
> >
> >>
> >>-Kristoffer
> >>
> >>On 2017-02-07 12:33, Chris Pavlina wrote:
> >>>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, Kristoffer Ödmark wrote:
> >>>>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:
> >>>>>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 have a few symbols that do that
> >>>>>too).
> >>>>>
> >>>>>On Tue, Feb 7, 2017 at 7:57 PM, Kristoffer Ödmark
> >>>>>mailto:kristofferodmar...@gmail.com>> 
> >>>>>wrote:
> >>>>>
> >>>>>  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 connect

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

[Chris Pavlina]

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).

On Tue, Feb 07, 2017 at 01:46:17PM +0100, Kristoffer Ödmark wrote:
> 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 me this is still an issue that can be fixed by the ERC or
> checking manually. Not using the ERC is also bad practice, and reworking
> this way is just enforcing two bad behaviours.
> 
> To me every no-connect pin should not be able to be connected. Not depending
> on its visibility.
> 
> - Kristoffer
> 
> On 2017-02-07 13:22, Chris Pavlina wrote:
> >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 invisible pin
> >>that is not stacked?
> >>
> >>And as you said, you had to clean out parts that had invisible pins that
> >>that was supposed not to be connected. Fault of creating the symbol, I think
> >>the symbol should be reworked instead of hardcoding around faulty symbols.
> >>
> >>There are many silly ways of using stuff, I dont agree that having a
> >>visibility checkbox determining if it is connectable is the right way,
> >>rather have a pop-up warning that says that you have connected to an
> >>invisible pin.
> >
> >...you don't think kicad has enough popup warnings /yet/?! Are you
> >kidding?
> >
> >The feature is confusing, it should be reworked to be less confusing.
> >Not leave it confusing and yell at the user when he gets confused.
> >
> >>
> >>- Kristoffer
> >>
> >>On 2017-02-07 12:50, Chris Pavlina wrote:
> >>>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 clearly don't get that, as
> >>>they think invisible pins are a nice way to represent no-connect pins
> >>>visibly in libedit that don't show up in and clutter the schematic. Just
> >>>had to clean a bunch of those out of my own library that someone
> >>>submitted, and someone else said the official KiCad libs have a bunch
> >>>too. Not sure why you think it's so obvious when actual usage shows it's
> >>>not.
> >>>
> >>>>
> >>>>I mean, otherwise there could be a stacked pin instead. Im not saying that
> >>>>invisible pins are good practise, but thats not really for me to say.
> >>>>
> >>>>What is silly is having invisible pins working as no-pins except if they 
> >>>>are
> >>>>a stacked pin, well that doesnt sound clear to me.
> >>>
> >>>What's silly is using them that way when you could just hide the pin
> >>>text. It's only the text that collides and makes them look bad.
> >>>
> >>>Compromise: don't connect invisible pins of type "no connect". Remove
> >>>the stupidity in the design without screwing the people who depended on
> >>>it.
> >>>
> >>>>
> >>>>-Kristoffer
> >>>>
> >>>>On 2017-02-07 12:33, Chris Pavlina wrote:
> >>>>>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, Kristoffer Ödmark wrote:
> >>>>>>Honestly I think the i

[Kicad-developers] More wxformbuilder

[Chris Pavlina]

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 we should reduce the use of wxformbuilder in new
code? There are plenty of ways the tedious code could be avoided without
using it - for instance, that panel is very repetitive, a function could
be created to populate a section...

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

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

[Chris Pavlina]

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


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

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

[Chris Pavlina]

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).  It can
> be a "under the hood" change only in pcbnew, until the legacy canvas is
> removed.
> 
> BTW Chris, I also have some ideas for improving the visualization of very
> busy (dense and high layer count) boards, I will play with them soon...

Nice! I look forward to that. Definitely an area we can improve on.

> 
> -Jon
> 
> On Tue, Feb 7, 2017 at 6:32 AM, Chris Pavlina 
> wrote:
> 
> > 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
> > >
> > > 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 combination between colors (for transparency:
> > the OR operation.)
> > >
> > > In other to achieve a good result, you cannot use any color for layers.
> > > You have to choose a set of colors which allows this good result.
> > > (by adjusting the 32 bits binary values of each color to ensure a good
> > result when 2 or more color
> > > values are ORed)
> > >
> > > There are not a lot of suitable binary values.
> > > In all cases the background must be black (when using OR or
> > transparency).
> > >
> > > Note also Eeschema does not use currently transparency, and the choice
> > of colors is not critical.
> > >
> > > >
> > > > On 7 February 2017 at 17:00, Chris Pavlina 
> > wrote:
> > > >> I'm working on an eight-layer board and really can't wait for this to
> > > >> hit pcbnew too. It's bloody impossible to tell layers apart with
> > KiCad's
> > > >> state-of-the-80s-art color system.
> > >
> > > I have made a few boards with 8 and one with 16 layers.
> > > There is no perfect way to see all layers.
> > >
> > > I used Pcbnew and Altium (in a company which has a Altium license) to
> > design a 8 layers board (2
> > > very similar boards, one with Pcbnew, the other with Altium, because
> > this company used Altium).
> > >
> > > Altium allows arbitrary colors and transparency, but a 8 layers board is
> > not easy to manage.
> > >
> > > So do not expect allowing arbitrary colors and transparency will fix
> > your problem.
> > > (In the best case, it slightly helps).
> > >
> > >
> > > Having said that, using a selected set of colors does not imply using
> > EDA_COLOR_T in Kicad code.
> > > wxColor can be used instead of.
> > >
> > > This is only the *color choice* in Pcbnew which is constrained in legacy
> > canvas.
> > >
> > > EDA_COLOR_T comes from the fact the legacy graphic primitives where
> > written for an other library,
> > > not for wxWidgets.
> > > (Kicad was started before wxWidgets exists)
> > >
> > > >>
> > > >> On Mon, Feb 06, 2017 at 10:03:11PM -0500, 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 handle arbitrary
> > colors.  I
> > > >>> think this is important and the right path for the future, but since
> > it's a
> > > >>> significant change, I wanted to get buy-in before going any farther
> > down
> > > >>> this road.  I can understand the reasons for using an enum for
> > > >>> color--especially since it lets the developers restrict the colors
> > to those
> > > >>> that will work well with the drawing technique of the legacy
> > canvases.
> > > >>> But, since the new canvases wi

[Kicad-developers] UI policy

[Chris Pavlina]

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 making everything like [1]...does anyone think maybe we should
look for a new set of interface guidelines?

[1] https://developer.gnome.org/hig/stable/patterns.html.en

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

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

[Chris Pavlina]

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 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 
> >> issues)? Would be changing the "invisible" flag to a "hide-if-stacked" 
> >> flag feasable?
> > 
> > Professional electronics engineers and experienced layout people agree: 
> > invisible pins are a stupid idea and they should be banished. If you 
> > haven’t been screwed by invisible pins on a schematic, it’s only a matter 
> > of time.
> 
> Maybe the reason I've never been bit by this in 30+ years is that I'm
> not a professional.  I've never found it particularly dangerous except
> for new users who don't understand that electronics require power to
> operate.  Once you get over that hurdle, it's pretty obvious when your
> footprint power pins aren't connected.  That being said *always* check
> you symbols and footprints.  I don't care how much you paid from them or
> from what vendor you got them from, there is always a chance that they
> are incorrect.  If they are incorrect and you did not check them, that
> is *your* fault.  That is something I learned my first year out of
> college.  AFAIK, it still applies.

And yet, mistakes still do happen, no matter how much checking is done.
Software that is intelligently designed in a way that reduces the chance
of mistakes is a very good thing, particularly when a lot of money is on
the line.

> 
> > 
> > I suppose that the original idea for invisible pins began back in the days 
> > of SSI and MSI logic, where everything had one power rail called VCC and 
> > also a ground rail, and to avoid cluttering up the schematic, it was 
> > convenient to make the power pins on each part hidden and give them 
> > appropriate net names.
> 
> It was done so you didn't need to wire a whole bunch of pins in you
> schematic that you knew needed to be connected to power.  For us old
> timers, this was obvious.  Maybe they don't teach that in engineering
> school any more.  It also required less screen real estate.  There were
> no 28" high resolution monitors way back when.
> 
> Almost every board I've ever designed has multiple supply rails because
> I've mostly worked with analog I/O so the multiple supply argument is weak.
> 
> > 
> > Of course, that’s an immediate fail, as TTL has a +5V rail, and 4000-series 
> > CMOS parts could have whatever rail (within reason) the designer deemed 
> > appropriate.
> > 
> > Nowadays, with multiple rails on even simple designs, simply calling a 
> > power pin VCC and giving it the netname VCC and hiding it doesn’t work. 
> > 
> > And I see in this thread that there’s a use case — stacking power pins and 
> > hiding all but one, so when a wire is added to that one visible power pin 
> > it is added to all of them. That one can make a connection to an invisible 
> > pin baffles me.
> 
> Both of these things baffle me.  Stacking pins (visible or not) is much
> scarier than invisible power pins.  Connecting a wire to an invisible
> pin just seems confusing to me.  I'm guessing this is something that
> just got overlooked but fixing it could be tricky.
> 
> > 
> > Also, consider the technician who is bringing up a new board, or is trying 
> > to repair something. S/he wants to see power pins on the schematic, 
> > otherwise how can anyone begin to start debugging?
> > 
> > I understand the desire to avoid cluttering up a schematic by hiding pins. 
> > I mean, we deal with monster FPGAs and CPUs here, and generally there’s a 
> > page on the schematic just for FPGA power connections (and the decoupling 
> > caps and all that). But hiding those pins has zero benefit and increases 
> > the chances of an expensive screwup.
> > 
> > By all means, leave the capability for invisible pins in Kicad. But the 
> > standard libraries should never use them (for reasons Chris has mentioned) 
> > and their general use should be discouraged.
> 
> Invisible pin support has to be maintained.  I'm guessing some users
> still prefer it and there are legacy designs which cannot be broken.  As
> for our standard libraries, we would have to get the buy in of our
> library developers.  I'm not sure how receptive they would be to the idea.
> 
> > 
> > -a
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net

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

[Chris Pavlina]

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 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 more information to the component selector. In
> > particular, it adds two things:
> > 
> > 1. Display component description even for aliases.
> > 2. Display all fields.
> > 
> > Screenshot: https://misc.c4757p.com/choose-component.png
> > 
> > It should be ready for commit, just pending review.
> > 
> > Upcoming changes:
> > 
> > 1. Make datasheet a clickable link
> > 2. Add footprint preview/selection discussed earlier
> > 3. Rearrange dialog to make this all fit
> > 
> > 
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

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

[Chris Pavlina]

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 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 fixes a GAL usability quirk with the T hotkey (find and move).
> > 
> > Fixes: https://bugs.launchpad.net/kicad/+bug/1571214
> > 
> > Cheers,
> > 
> > John
> > 
> > 
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

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

[Chris Pavlina]

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 start and a "Disable hardware acceleration" option
  in the preferences to do it manually.

- Rename legacy/default to "Legacy Pcbnew", also make this an option in
  the preferences.

Both of these new options should default false.

On Wed, Feb 08, 2017 at 09:52:59AM +1100, Cirilo Bernardo wrote:
> 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
> the V5 release, each time pcbnew is started it should always
> default to GAL (or Cairo if someone is using a laptop from 2001).
> On top of that, each time a user decides to switch to the Legacy
> canvas I would throw up a nag screen to tell the user that the
> canvas they are selecting has been deprecated and will be
> removed in the next release and that the user should use the
> GAL canvas instead and report any missing or buggy tools
> via the bugtracker.
> 
> I think ripping out Legacy soon after release would be a good
> thing and will allow (some of us) to concentrate on improved
> modularity (and maintainability) of the code. Encouraging
> people to use GAL in V5 (while also discouraging them from
> using Legacy) should hopefully get us the bug reports we need
> to implement and polish up the GAL tools.
> 
> Any comments?
> 
> - Cirilo
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

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

[Chris Pavlina]

Since the recent updates to it, I have found the Cairo backend to be on
par with legacy. Have you tried using Cairo in a nightly build?

On Wed, Feb 08, 2017 at 10:48:45AM +0100, Martin Schreiber wrote:
> On Wednesday 08 February 2017 10:25:03 Mário Luzeiro wrote:
> >
> > I never investigate, maybe a miss some flags activation on my drivers
> > but I experienced to use an old GPU (NVidia) card and everything goes back
> > perfect!
> >
> Yup, sadly it is a matter-of-fact that OpenGL seldom works out of the box on 
> Linux. One normally spends days to try or compile several different drivers 
> and settings until it is somewhat working with all installed software, 
> sometimes it is not possible to achieve.
> And after the next kernel or X.Org update it is broken again...
> 
> Martin
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

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

[Chris Pavlina]

Something stands out from this email that's worth mentioning, I think:

> Admitted, I don't have the newest hardware but I like to have not so fast 
> machines in order to be forced to develop fast software. ;-)

WE DON'T. It is unreasonable to expect the developers of KiCad to lock
themselves into developing things compatible with toasters because that
is what you prefer. All we're asking is that people have OpenGL. Not a
state-of-the-art GPU with a million CUDA cores and fifty terabytes of
video RAM. OpenGL. The only thing I can imagine that logically follows
from "you can't rely on OpenGL because I use old hardware" is "you can't
rely on having a MMU because I run KiCad on my Cortex-M-based toaster".

Seriously, every $50 used laptop on Craigslist has OpenGL support.

On Wed, Feb 08, 2017 at 09:07:39AM +0100, Martin Schreiber wrote:
> On Tuesday 07 February 2017 23:52:59 Cirilo Bernardo wrote:
> >
> > I think ripping out Legacy soon after release would be a good
> > thing and will allow (some of us) to concentrate on improved
> > modularity (and maintainability) of the code. Encouraging
> > people to use GAL in V5 (while also discouraging them from
> > using Legacy) should hopefully get us the bug reports we need
> > to implement and polish up the GAL tools.
> >
> > Any comments?
> 
> I am relatively new to KiCad and I don't use it in production up to now 
> because I need to finish the interface to my other production environment 
> first, first of all I need to finish MSEkicadBOM.
> Before I decided to invest time into the KiCad project I tested it on 
> different Linux boxes. The only canvas which really worked was the legacy 
> canvas. The OpenGL canvas either had issues or did not work at all because of 
> various Linux driver problems. The performance of the legacy canvas was much 
> better than the performance of the OpenGL canvas on the machines I tested. 
> performance of Cairo canvas is even worse, almost unusable.
> Admitted, I don't have the newest hardware but I like to have not so fast 
> machines in order to be forced to develop fast software. ;-)
> 
> I recently had to revive a very old Orcad PCB-386 project on a stone age PC 
> with K6 processor and Windows 95 - what surprise, the performance and user 
> experience was on a par or even better than with current software on current 
> machines.
> 
> So please take into account that not all users have the newest machines, even 
> more users of free software who sometimes have a very low budget.
> 
> Martin
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

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

[Chris Pavlina]

As a Linux user for many years now, that has not been my experience.
And sorry, but from one Linux user to another, even if that is the case,
that's your choice to live with. If you're going to install Linux on a
system where it doesn't work well, it's not our fault if you refuse to
get basic things like OpenGL working properly.

On Wed, Feb 08, 2017 at 01:10:52PM +0100, Martin Schreiber wrote:
> On Wednesday 08 February 2017 12:35:40 Chris Pavlina wrote:
> >
> > Seriously, every $50 used laptop on Craigslist has OpenGL support.
> >
> Which normally doesn't work good enough on Linux out of the box.
> 
> Martin
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

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

[Chris Pavlina]

On Wed, Feb 08, 2017 at 01:28:16PM +0100, Martin Schreiber wrote:
> On Wednesday 08 February 2017 13:18:39 Chris Pavlina wrote:
> > As a Linux user for many years now, that has not been my experience.
> 
> You are a happy guy!
> I am the author of MSEide+MSEgui where users expect that it perfectly runs on 
> every Windows, Linux and OpenBSD version on any hardware with every possible 
> window manager in the universe, I know what I am talking about. :-)

I don't think you do, because you're using your experience developing an
IDE to claim that CAD software shouldn't need OpenGL. That is a very
basic requirement for anything of a graphical nature.

Does your software also run on systems without a memory management unit?
uClinux? Or do you have an explanation for why it is perfectly
reasonable for an IDE to expect such a thing?

> 
> Martin
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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