[Kicad-developers] [RFC] lp:1663990

[Oliver Walters]

Hi all,

I refer you to:
https://bugs.launchpad.net/kicad/+bug/1663990

With much more interest now in user contributions to the library, the issue
of system-dependent line-endings is becoming tedious.

I have had a look through the output formatter code, but I'm afraid it's a
bit confusing - I haven't been able to find where this problem is coming
from.

Can someone who is more familiar with the outputformatter / richio code
perhaps take a look at this one?

Thanks,
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] [RFC] Future of GitHub libraries

[Oliver Walters]

Kevin,

This is how I think it should work too. When I get some time I will look
into how the current github plugin works, perhaps it can be improved to
support this functionality.

On Thu, Feb 23, 2017 at 6:49 AM, Kevin Cozens  wrote:

> On 2017-02-17 09:30 AM, Wayne Stambaugh wrote:
>
>> On 2/16/2017 6:19 PM, Oliver Walters wrote:
>>
>>> iii) Excessive bandwidth - Each time a .pretty lib is loaded, it
>>> downloads a zip of the entire library? If we were making use of git
>>> functionality it would be simple to just update the library (and store a
>>> local cache) and thus only download the diff rather than re-download the
>>> entire thing.
>>>
>>
>> Once again, a git plugin solves this problem nicely.
>>
>
> Bandwidth can be saved by saving .pretty libs on the local hard drive
> instead of temporarily caching them. It also means ones that have been
> previously requested will be available even when the computer has no net
> access.
>
> When someone needs a .pretty lib you check if it is already on the local
> drive. If not, download it and save to the local drive. If the library is
> already on the local drive check the time and date of the remote copy. If
> the remote version is newer than the local copy download library and save
> it to the local HD.
>
> That's the simple way to reduce bandwidth requirements. The "download"
> portion of the process could involve using source code control to update
> the local copy instead of downloading the entire library.
>
> --
> Cheers!
>
> Kevin.
>
> http://www.ve3syb.ca/   |"Nerds make the shiny things that
> distract
> Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
> | powerful!"
> #include  | --Chris Hardwick
>
>
> ___
> 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] Future of GitHub libraries

[Oliver Walters]

Understood.

On Thu, Feb 23, 2017 at 8:51 AM, Wayne Stambaugh 
wrote:

> As long as it doesn't break the current github plugin behavior, then
> that's fine.  Otherwise it needs to be a separate plugin.
>
> On 2/22/2017 4:46 PM, Oliver Walters wrote:
> > Kevin,
> >
> > This is how I think it should work too. When I get some time I will look
> > into how the current github plugin works, perhaps it can be improved to
> > support this functionality.
> >
> > On Thu, Feb 23, 2017 at 6:49 AM, Kevin Cozens  > <mailto:ke...@ve3syb.ca>> wrote:
> >
> >     On 2017-02-17 09:30 AM, Wayne Stambaugh wrote:
> >
> > On 2/16/2017 6:19 PM, Oliver Walters wrote:
> >
> > iii) Excessive bandwidth - Each time a .pretty lib is
> loaded, it
> > downloads a zip of the entire library? If we were making use
> > of git
> > functionality it would be simple to just update the library
> > (and store a
> > local cache) and thus only download the diff rather than
> > re-download the
> > entire thing.
> >
> >
> > Once again, a git plugin solves this problem nicely.
> >
> >
> > Bandwidth can be saved by saving .pretty libs on the local hard
> > drive instead of temporarily caching them. It also means ones that
> > have been previously requested will be available even when the
> > computer has no net access.
> >
> > When someone needs a .pretty lib you check if it is already on the
> > local drive. If not, download it and save to the local drive. If the
> > library is already on the local drive check the time and date of the
> > remote copy. If the remote version is newer than the local copy
> > download library and save it to the local HD.
> >
> > That's the simple way to reduce bandwidth requirements. The
> > "download" portion of the process could involve using source code
> > control to update the local copy instead of downloading the entire
> > library.
> >
> > --
> > Cheers!
> >
> > Kevin.
> >
> > http://www.ve3syb.ca/   |"Nerds make the shiny things that
> > distract
> > Owner of Elecraft K2 #2172  | the mouth-breathers, and that's
> > why we're
> > | powerful!"
> > #include  | --Chris Hardwick
> >
> >
> > ___
> > 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] Stable release 4.0.6

[Oliver Walters]

All libraries have now been tagged as 4.0.6

On Wed, Feb 15, 2017 at 1:26 AM, Wayne Stambaugh 
wrote:

> Are there any outstanding issues to prevent rolling out a 4.0.6 stable
> release?  If not, I will set the version string and tag that commit as
> 4.0.6.  How much time do our source translators, doc devs, and library
> devs need to have everything ready?
>
> Thanks,
>
> 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] [RFC] 3D models repository

[Oliver Walters]

Hi everyone,

Recently I raised this issue:

https://lists.launchpad.net/kicad-developers/msg27922.html

There were some good responses, thanks for the input.

First task is going to be moving the 3D models, as this will be
significantly easier.

e.g. something like GitHub.com/KiCad/packages3D

To this end, I'd like some further information from those in the know:

A) is there any impediment to having the KISYS3DMOD envvar point to
somewhere different? e.g. ./KiCad/share/packages3D/
B) To the package managers, how much effort to package 3D models from a
separate repo?
C) to the docs maintainers, would there be much to change if we redirected
the 3D repo?
D) Generally, what other considerations would be required?

Essentially, if I made this change right now without telling anyone, what
would I break?

As a side note there have been some great recent contributions to the 3D
data, with a fair bit of momentum over at the forums.

Regards,
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] [RFC] 3D models repository

[Oliver Walters]

I would tend to agree. I know that the disk location doesn't really matter,
and it would be a pain to change, but having it as a direct subdirectory of
KiCad/share/ seems to make more intuitive sense to me.

On 25 Feb 2017 01:12, "Simon Wells"  wrote:

> why should packages be a subfolder of modules, it seems that they
> don't really belong in there and should be directly in the share/kicad
> folder
>
> On 25 February 2017 at 02:00, Adam Wolf 
> wrote:
> > Yeah, let me clarify--by "wouldn't be a problem" for OS X, I meant "if
> > you did it without saying where it's going and when it's changing", it
> > would break the OS X package, but the change would only take a minute
> > or two, and would be quickly testable.
> >
> > On Fri, Feb 24, 2017 at 6:57 AM, Wayne Stambaugh 
> wrote:
> >> On 2/24/2017 3:45 AM, Oliver Walters wrote:
> >>> Hi everyone,
> >>>
> >>> Recently I raised this issue:
> >>>
> >>> https://lists.launchpad.net/kicad-developers/msg27922.html
> >>>
> >>> There were some good responses, thanks for the input.
> >>>
> >>> First task is going to be moving the 3D models, as this will be
> >>> significantly easier.
> >>>
> >>> e.g. something like GitHub.com/KiCad/packages3D
> >>>
> >>> To this end, I'd like some further information from those in the know:
> >>>
> >>> A) is there any impediment to having the KISYS3DMOD envvar point to
> >>> somewhere different? e.g. ./KiCad/share/packages3D/
> >>
> >> I believe you mean share/kicad/modules/packages3d.  Why would change
> the
> >> install path?  Irregardless of what repo the 3D models are in, they
> >> should always get installed in this location.  Where else would be
> >> appropriate to install them?  Changing this path would most likely break
> >> everyone's 3D viewing experience.
> >>
> >>> B) To the package managers, how much effort to package 3D models from a
> >>> separate repo?
> >>
> >> I'll leave this to our package devs.
> >>
> >>> C) to the docs maintainers, would there be much to change if we
> >>> redirected the 3D repo?
> >>> D) Generally, what other considerations would be required?
> >>>
> >>> Essentially, if I made this change right now without telling anyone,
> >>> what would I break?
> >>
> >> I'm sure all of the package builders.  You would need to coordinate this
> >> change with the package devs.
> >>
> >>>
> >>> As a side note there have been some great recent contributions to the
> 3D
> >>> data, with a fair bit of momentum over at the forums.
> >>>
> >>> Regards,
> >>> 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
> >>>
> >>
> >>
> >> ___
> >> 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] 3D models repository

[Oliver Walters]

Cirilo,

Unless we made script generation of models completely idiot proof, I think
that requiring another niche toolset would only serve to increase the
already high barrier to entry for new users.

The 3D scripts require, currently:

- Freecad
- cadquery plugin

Plus the scripts themselves are a bit opaque to use.

I think that if we are going to distribute recipes for models rather than
the models themselves, that should be integrated into KiCad?

You're the expert on the 3D code, is there any possibility that we could
have a 3D wizard that operates in a similar way to the footprint wizard?
Then it would be fantastic to have the repo contain scripts as you say.

Connectors are an obvious use for parametric scripts as it takes lots of
space to store each of hundreds of variants.

Oliver


On 25 Feb 2017 8:44 AM, "Cirilo Bernardo"  wrote:

On Sat, Feb 25, 2017 at 1:12 AM, Simon Wells  wrote:
> why should packages be a subfolder of modules, it seems that they
> don't really belong in there and should be directly in the share/kicad
> folder
>

That would certainly be my preference. Since the root of the 3D models is
determined by KISYS3DMOD and hasn't had a hard-coded relation to the
*.lib files for quite a few years now, I would move it out of 'modules' and
into
a 'packages3d' directory. Looking at the structure on github,  'packages3d'
is currently the only directory within 'modules' so the modules directory
seems silly.


> On 25 February 2017 at 02:00, Adam Wolf 
wrote:
>> Yeah, let me clarify--by "wouldn't be a problem" for OS X, I meant "if
>> you did it without saying where it's going and when it's changing", it
>> would break the OS X package, but the change would only take a minute
>> or two, and would be quickly testable.
>>
>> On Fri, Feb 24, 2017 at 6:57 AM, Wayne Stambaugh 
wrote:
>>> On 2/24/2017 3:45 AM, Oliver Walters wrote:
>>>> Hi everyone,
>>>>
>>>> Recently I raised this issue:
>>>>
>>>> https://lists.launchpad.net/kicad-developers/msg27922.html
>>>>
>>>> There were some good responses, thanks for the input.
>>>>
>>>> First task is going to be moving the 3D models, as this will be
>>>> significantly easier.
>>>>
>>>> e.g. something like GitHub.com/KiCad/packages3D
>>>>
>>>> To this end, I'd like some further information from those in the know:
>>>>
>>>> A) is there any impediment to having the KISYS3DMOD envvar point to
>>>> somewhere different? e.g. ./KiCad/share/packages3D/
>>>
>>> I believe you mean share/kicad/modules/packages3d.  Why would change the
>>> install path?  Irregardless of what repo the 3D models are in, they
>>> should always get installed in this location.  Where else would be
>>> appropriate to install them?  Changing this path would most likely break
>>> everyone's 3D viewing experience.
>>>
>>>> B) To the package managers, how much effort to package 3D models from a
>>>> separate repo?
>>>
>>> I'll leave this to our package devs.
>>>
>>>> C) to the docs maintainers, would there be much to change if we
>>>> redirected the 3D repo?
>>>> D) Generally, what other considerations would be required?
>>>>
>>>> Essentially, if I made this change right now without telling anyone,
>>>> what would I break?
>>>
>>> I'm sure all of the package builders.  You would need to coordinate this
>>> change with the package devs.
>>>
>>>>
>>>> As a side note there have been some great recent contributions to the
3D
>>>> data, with a fair bit of momentum over at the forums.
>>>>
>>>> Regards,
>>>> Oliver

Some thought is needed about how to handle the 3D model repository in the
future. In the past we only had VRML which was pretty but next to useless
for mechanical verification. Now we have IGES and STEP in all the gloriously
ugly MCAD color schemes. Personally I only use IGES and STEP, but some
people like to have a STEP model for mechanical verification and a VRML
model for eyecandy. At the moment various scripts written to work with
Maurice's StepUp tool are the only scheme I'm aware of which make it easy
for people to have a STEP file while having improved material appearances
applied to the surfaces in a corresponding VRML file. I suspect it is
inevitable
that we start to have a diverse collection of 3D model sources:

a. old VRML models with no corresponding MCAD model
b. IGES/STEP models from manufa

Re: [Kicad-developers] [RFC] 3D models repository

[Oliver Walters]

I personally find the idea of on-demand model creation appealing.

I think that if we are to "promote" this as the preferred method, it should
be improved through simplification and consolidation.

Scripted models have only been added in the last week. Most of the models
are legacy (poor quality wrl made in wings etc). There are also now a lot
of models that have been generated via the spreadsheet functionality in
Freecad.

So already there are two competing scripting methods. What I want to
achieve is a simplified and unified library structure.

I realise that due to file size this is not so practical for the 3D models.

Perhaps a good idea is to dictate a scripting architecture that allows us
to be somewhat forward-compatible, and not actually provide 3D models.

The current scripts could be made more generic and "publish" their
parameters in such a way that an external tool can have some introspection
of the scripts. Much like the python footprint wizards currently work in
KiCad.

Then, a "helper" script can parse the generator scripts, and the user can
select which models to generate. This could even be run on KiCad install.

e.g. a list of checkboxes to install "all JST connectors" or "R0603".

Alternatively, we host all the generated models, and provide a download
tool which downloads models as required.

Thoughts?

On 25 Feb 2017 10:48 AM, "Cirilo Bernardo" 
wrote:

Hi Oliver,

 The scripts will easily generate many GB of data in time and for me it's
not
reasonable to download that amount of data. I think new users should simply
learn to read documentation and generate the models rather than downloading
them. Package maintainers can automatically run the scripts. Users will
still
have access to all the old VRML models and if they want to use the newer
models, especially the STEP+VRML models, they should learn to set up the
required tools. As I said, this requires a lot more thought.

 I suspect we can indeed develop our own parametric 3D modeling tools for
KiCad based on OCE and provide a scheme to specify good material
appearances for the VRML export as Maurice's tools do, but it's really a
question of time and planning.  Having scripts available in the official
repo
I think is a good start and will keep the expert users happy until someone
gets around to creating these specialised tools for kicad.

- Cirilo


On Sat, Feb 25, 2017 at 10:10 AM, Oliver Walters
 wrote:
> Cirilo,
>
> Unless we made script generation of models completely idiot proof, I think
> that requiring another niche toolset would only serve to increase the
> already high barrier to entry for new users.
>
> The 3D scripts require, currently:
>
> - Freecad
> - cadquery plugin
>
> Plus the scripts themselves are a bit opaque to use.
>
> I think that if we are going to distribute recipes for models rather than
> the models themselves, that should be integrated into KiCad?
>
> You're the expert on the 3D code, is there any possibility that we could
> have a 3D wizard that operates in a similar way to the footprint wizard?
> Then it would be fantastic to have the repo contain scripts as you say.
>
> Connectors are an obvious use for parametric scripts as it takes lots of
> space to store each of hundreds of variants.
>
> Oliver
>
>
> On 25 Feb 2017 8:44 AM, "Cirilo Bernardo" 
wrote:
>
> On Sat, Feb 25, 2017 at 1:12 AM, Simon Wells  wrote:
>> why should packages be a subfolder of modules, it seems that they
>> don't really belong in there and should be directly in the share/kicad
>> folder
>>
>
> That would certainly be my preference. Since the root of the 3D models is
> determined by KISYS3DMOD and hasn't had a hard-coded relation to the
> *.lib files for quite a few years now, I would move it out of 'modules'
and
> into
> a 'packages3d' directory. Looking at the structure on github,
'packages3d'
> is currently the only directory within 'modules' so the modules directory
> seems silly.
>
>
>> On 25 February 2017 at 02:00, Adam Wolf 
>> wrote:
>>> Yeah, let me clarify--by "wouldn't be a problem" for OS X, I meant "if
>>> you did it without saying where it's going and when it's changing", it
>>> would break the OS X package, but the change would only take a minute
>>> or two, and would be quickly testable.
>>>
>>> On Fri, Feb 24, 2017 at 6:57 AM, Wayne Stambaugh 
>>> wrote:
>>>> On 2/24/2017 3:45 AM, Oliver Walters wrote:
>>>>> Hi everyone,
>>>>>
>>>>> Recently I raised this issue:
>>>>>
>>>>> https://lists.launchpad.net/kicad-developers/msg27922.html
>>>&

Re: [Kicad-developers] [RFC] 3D models repository

[Oliver Walters]

Simon,

Are you saying we should host the models and provide them on demand?

I would agree. This way we can provide models independent of the source
(scripts, etc).

It also makes it way easier for users.

I like the idea of a KiCad-integrated model wizard but I'll leave that for
Cirilo to code when he has a free weekend.

I'll let all this percolate. Thanks for the input.

On 25 Feb 2017 1:41 PM, "Simon Wells"  wrote:

> i don't see why on-install and if it can be done at install time why
> not just do it on-demand of the model... if its slow cache but still
> ondemand,
>
> providing models that we gen will likely require a full stack of
> development as git/github isn't really ideal for stuff like this
>
> On 25 February 2017 at 15:15, Oliver Walters
>  wrote:
> > I personally find the idea of on-demand model creation appealing.
> >
> > I think that if we are to "promote" this as the preferred method, it
> should
> > be improved through simplification and consolidation.
> >
> > Scripted models have only been added in the last week. Most of the models
> > are legacy (poor quality wrl made in wings etc). There are also now a
> lot of
> > models that have been generated via the spreadsheet functionality in
> > Freecad.
> >
> > So already there are two competing scripting methods. What I want to
> achieve
> > is a simplified and unified library structure.
> >
> > I realise that due to file size this is not so practical for the 3D
> models.
> >
> > Perhaps a good idea is to dictate a scripting architecture that allows
> us to
> > be somewhat forward-compatible, and not actually provide 3D models.
> >
> > The current scripts could be made more generic and "publish" their
> > parameters in such a way that an external tool can have some
> introspection
> > of the scripts. Much like the python footprint wizards currently work in
> > KiCad.
> >
> > Then, a "helper" script can parse the generator scripts, and the user can
> > select which models to generate. This could even be run on KiCad install.
> >
> > e.g. a list of checkboxes to install "all JST connectors" or "R0603".
> >
> > Alternatively, we host all the generated models, and provide a download
> tool
> > which downloads models as required.
> >
> > Thoughts?
> >
> > On 25 Feb 2017 10:48 AM, "Cirilo Bernardo" 
> > wrote:
> >
> > Hi Oliver,
> >
> >  The scripts will easily generate many GB of data in time and for me it's
> > not
> > reasonable to download that amount of data. I think new users should
> simply
> > learn to read documentation and generate the models rather than
> downloading
> > them. Package maintainers can automatically run the scripts. Users will
> > still
> > have access to all the old VRML models and if they want to use the newer
> > models, especially the STEP+VRML models, they should learn to set up the
> > required tools. As I said, this requires a lot more thought.
> >
> >  I suspect we can indeed develop our own parametric 3D modeling tools for
> > KiCad based on OCE and provide a scheme to specify good material
> > appearances for the VRML export as Maurice's tools do, but it's really a
> > question of time and planning.  Having scripts available in the official
> > repo
> > I think is a good start and will keep the expert users happy until
> someone
> > gets around to creating these specialised tools for kicad.
> >
> > - Cirilo
> >
> >
> > On Sat, Feb 25, 2017 at 10:10 AM, Oliver Walters
> >  wrote:
> >> Cirilo,
> >>
> >> Unless we made script generation of models completely idiot proof, I
> think
> >> that requiring another niche toolset would only serve to increase the
> >> already high barrier to entry for new users.
> >>
> >> The 3D scripts require, currently:
> >>
> >> - Freecad
> >> - cadquery plugin
> >>
> >> Plus the scripts themselves are a bit opaque to use.
> >>
> >> I think that if we are going to distribute recipes for models rather
> than
> >> the models themselves, that should be integrated into KiCad?
> >>
> >> You're the expert on the 3D code, is there any possibility that we could
> >> have a 3D wizard that operates in a similar way to the footprint wizard?
> >> Then it would be fantastic to have the repo contain scripts as you say.
> >>
> >> Connectors are an obvious use for parametric scripts

Re: [Kicad-developers] [RFC] 3D models repository

[Oliver Walters]

Cirilo,

Some great ideas there - I was being more than slightly facetious by
suggesting it would be the work of a weekend :)

Should we have separate repositories for MCAD models and wrl? And a third
for scripts?


On 26 Feb 2017 08:31, "Cirilo Bernardo"  wrote:

On Sat, Feb 25, 2017 at 3:53 PM, Oliver Walters
 wrote:
> Simon,
>
> Are you saying we should host the models and provide them on demand?
>
> I would agree. This way we can provide models independent of the source
> (scripts, etc).
>
> It also makes it way easier for users.
>
> I like the idea of a KiCad-integrated model wizard but I'll leave that for
> Cirilo to code when he has a free weekend.
>

I'm sure it would take more than a weekend. Whatever your solution for
now, I think it is important to separate the old Wings3D/VRML models
from any models generated from MCAD. Better still, if there can be some
text file associated with each STEP/VRML pair (or script) stating the
author, source of data, and whether or not the mechanically important
dimensions were verified (and by who). Such text files with a 'checked by'
entry could also be useful for footprints and schematic symbols as well.

I'll put scripted STEP model generation on my list of things to do, but
given that existing bugs have the highest priority and then the PCB API
after that, I have no idea when I'll get around to it. For me the ideal
scripting solution would consist of (a) compiled C++ parametric tools
(b) python scripts (c) XML schema for describing the scripts and how to
invoke them (d) GUI for searching the XML files and magically creating
the menus for controlling parameters on the selected XML file. It's an
awful lot of work for what would be only a small improvement on Maurice's
current tools, but once (a) and (b) are done we will at least be in a
position to ship scripts rather than models and we could always have
some hard-coded tool for selecting and executing scripts in the short
term.

- Cirilo

> I'll let all this percolate. Thanks for the input.
>
> On 25 Feb 2017 1:41 PM, "Simon Wells"  wrote:
>>
>> i don't see why on-install and if it can be done at install time why
>> not just do it on-demand of the model... if its slow cache but still
>> ondemand,
>>
>> providing models that we gen will likely require a full stack of
>> development as git/github isn't really ideal for stuff like this
>>
>> On 25 February 2017 at 15:15, Oliver Walters
>>  wrote:
>> > I personally find the idea of on-demand model creation appealing.
>> >
>> > I think that if we are to "promote" this as the preferred method, it
>> > should
>> > be improved through simplification and consolidation.
>> >
>> > Scripted models have only been added in the last week. Most of the
>> > models
>> > are legacy (poor quality wrl made in wings etc). There are also now a
>> > lot of
>> > models that have been generated via the spreadsheet functionality in
>> > Freecad.
>> >
>> > So already there are two competing scripting methods. What I want to
>> > achieve
>> > is a simplified and unified library structure.
>> >
>> > I realise that due to file size this is not so practical for the 3D
>> > models.
>> >
>> > Perhaps a good idea is to dictate a scripting architecture that allows
>> > us to
>> > be somewhat forward-compatible, and not actually provide 3D models.
>> >
>> > The current scripts could be made more generic and "publish" their
>> > parameters in such a way that an external tool can have some
>> > introspection
>> > of the scripts. Much like the python footprint wizards currently work
in
>> > KiCad.
>> >
>> > Then, a "helper" script can parse the generator scripts, and the user
>> > can
>> > select which models to generate. This could even be run on KiCad
>> > install.
>> >
>> > e.g. a list of checkboxes to install "all JST connectors" or "R0603".
>> >
>> > Alternatively, we host all the generated models, and provide a download
>> > tool
>> > which downloads models as required.
>> >
>> > Thoughts?
>> >
>> > On 25 Feb 2017 10:48 AM, "Cirilo Bernardo" 
>> > wrote:
>> >
>> > Hi Oliver,
>> >
>> >  The scripts will easily generate many GB of data in time and for me
>> > it's
>> > not
>> > reasonable to download that amount of data. I think new users should
>> > simply
>> > learn to read

Re: [Kicad-developers] [RFC] 3D models repository

[Oliver Walters]

The licence on the legacy models I am unsure about.

Maurice, Rene, Jan and myself have been discussing the licence for models
that we create (script). It is GPL with an explicit exception stating that
models can be freely used and shared without normal GPL requirements.

If you look at Maurice's scripts (https://GitHub.com/easyw) he has already
implemented this.

Oliver

On 26 Feb 2017 11:25 AM, "Cirilo Bernardo" 
wrote:

I think one repository for the old VRML models, another for MCAD
models, and a third for scripts. In cases where an MCAD model has a
corresponding VRML model which has been specially crafted to look
better in the 3D viewer, that VRML model should be alongside the MCAD
model and in the MCAD directory.  I think this scheme gives us a path
to eventually deprecate the old VRML models as we build up
replacements on the MCAD side.

Package maintainers can decide what to offer on each platform and sort
out the dependencies. I imagine the old VRML will be included simply
because so many people use it; MCAD+VRML would probably be a separate
option due to the sheer volume, and some package maintainers might
decide to offer the scripts instead and pull in all the dependencies.
At any rate, the scripting option is definitely not for beginners.

There is also the issue of licenses for the models. A few users have
expressed concerns that some models are licensed under GPL (whatever
that means for something which is not software) but in general people
are concerned that kicad models may be of no value to them because (a)
licensing might be mixed and difficult to determine and (b) some
licenses may prevent them from using models in their commercial
projects.

- Cirilo

On Sun, Feb 26, 2017 at 10:02 AM, Oliver Walters
 wrote:
> Cirilo,
>
> Some great ideas there - I was being more than slightly facetious by
> suggesting it would be the work of a weekend :)
>
> Should we have separate repositories for MCAD models and wrl? And a third
> for scripts?
>
>
> On 26 Feb 2017 08:31, "Cirilo Bernardo"  wrote:
>
> On Sat, Feb 25, 2017 at 3:53 PM, Oliver Walters
>  wrote:
>> Simon,
>>
>> Are you saying we should host the models and provide them on demand?
>>
>> I would agree. This way we can provide models independent of the source
>> (scripts, etc).
>>
>> It also makes it way easier for users.
>>
>> I like the idea of a KiCad-integrated model wizard but I'll leave that
for
>> Cirilo to code when he has a free weekend.
>>
>
> I'm sure it would take more than a weekend. Whatever your solution for
> now, I think it is important to separate the old Wings3D/VRML models
> from any models generated from MCAD. Better still, if there can be some
> text file associated with each STEP/VRML pair (or script) stating the
> author, source of data, and whether or not the mechanically important
> dimensions were verified (and by who). Such text files with a 'checked by'
> entry could also be useful for footprints and schematic symbols as well.
>
> I'll put scripted STEP model generation on my list of things to do, but
> given that existing bugs have the highest priority and then the PCB API
> after that, I have no idea when I'll get around to it. For me the ideal
> scripting solution would consist of (a) compiled C++ parametric tools
> (b) python scripts (c) XML schema for describing the scripts and how to
> invoke them (d) GUI for searching the XML files and magically creating
> the menus for controlling parameters on the selected XML file. It's an
> awful lot of work for what would be only a small improvement on Maurice's
> current tools, but once (a) and (b) are done we will at least be in a
> position to ship scripts rather than models and we could always have
> some hard-coded tool for selecting and executing scripts in the short
> term.
>
> - Cirilo
>
>> I'll let all this percolate. Thanks for the input.
>>
>> On 25 Feb 2017 1:41 PM, "Simon Wells"  wrote:
>>>
>>> i don't see why on-install and if it can be done at install time why
>>> not just do it on-demand of the model... if its slow cache but still
>>> ondemand,
>>>
>>> providing models that we gen will likely require a full stack of
>>> development as git/github isn't really ideal for stuff like this
>>>
>>> On 25 February 2017 at 15:15, Oliver Walters
>>>  wrote:
>>> > I personally find the idea of on-demand model creation appealing.
>>> >
>>> > I think that if we are to "promote" this as the preferred method, it
>>> > should
>>> > be improved through simplification and consolidation.
>>> >
>>> > Scri

Re: [Kicad-developers] Eeschema crash on library component name mismatch

[Oliver Walters]

jp,

There were three library files with this issue:

* power.lib
* memory.lib
* transistors.lib

These have been addressed here -
https://github.com/KiCad/kicad-library/pull/1076 (autofix with the KLC
scripts!)

Oliver

On Wed, Mar 1, 2017 at 5:31 AM, jp charras  wrote:

> Le 28/02/2017 à 16:18, Julius Schmidt a écrit :
> >> Is this lib built with Kicad?
> >
> >> From
> > https://github.com/KiCad/kicad-library/blob/master/
> library/transistors.lib
> >
> > DEF BDW93 Q 0 0 Y N 1 F N
> > F0 "Q" 200 75 50 H V L CNN
> > F1 "BF240" 200 0 50 H V L CNN
> >
> > There may be other ones.
> >
>
> OK.
> This library looks like it was edited by hand, and broken (at least for
> this item)
>
> --
> 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] 3D models repository

[Oliver Walters]

Preview of the 3D library (working closely with Rene and Maurice, this is
coming together nicely).

https://github.com/KiCad/packages3D

On Mon, Feb 27, 2017 at 6:17 PM, Javier Serrano <
javier.serrano.par...@gmail.com> wrote:

> On Sun, Feb 26, 2017 at 11:55 PM, Cirilo Bernardo <
> cirilo.berna...@gmail.com> wrote:
>
>>
>> That depends on what you mean by 'free'. If the output is Public Domain
>> then
>> anyone can use it for whatever purpose they like and have no obligations.
>>
>
> Strictly speaking, I don't think we can actually put a creation of the
> type typically covered by copyright in the public domain. Copyright kicks
> in by default in most jurisdictions. Public domain is what happens when
> something is *not* subject to copyright. This can be because the law of a
> particular country says so, like in the case of US Government works [1] or,
> in the case of work of "normal" individuals, when copyright has expired.
> The closest to public domain you can get for things like images is a CC0
> license [2]. It says that you waive your rights under copyright law but
> only "to the extent allowed by law."
>
> So CC0 is definitely an option, and so is CC-SA if you want people who
> modify symbols/footprints/etc and publish the results, to do so under the
> same licensing. In that case, we need an additional statement clarifying
> that this obligation does not extend to the whole schematics/layout and
> other composite works.
>
> Cheers,
>
> Javier
>
> [1] https://www.law.cornell.edu/uscode/text/17/105
> [2] https://creativecommons.org/publicdomain/zero/1.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
>
>
___
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] Logo Consolidation

[Oliver Walters]

Hi all,

One small thing that has bugged me for a while is the various icons that
are considered "official" for Kicad.

The application, website, forum and github all use different icons.

Further, the application icon looks very cluttered when reduced to a small
size e.g. on window title bar.

I have put together a proposal for a single icon which can be used in
long-form or short-form for the various places. It also looks much better
at small scales, and (IMO) has better KiCad branding than the current
application icon.

http://imgur.com/a/Jjh3t

Not a final draft, just something I have thrown together so let's not
bike-shed it with font-choice or palette fine-tuning.

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] [RFC] Logo Consolidation

[Oliver Walters]

Ingo you are right, I think the logo works better without the "mask
setback" in white around the letter "i".

Thanks for the mockups :)

On Thu, Mar 2, 2017 at 6:41 PM, Ingo Kletti 
wrote:

> Hi,
>
> I like the use of the schematic/pcb elements.
>
> It also looks much better at small scales
>>
>
> I tried the scaling and made a mockup at icon resolutions from 16x16 to
> 64x64 with 8 pixel steps (16, 24, 32, etc.), see attachment. Scaling works
> good IMO, but cannot avoid bike-shedding:
>
> On the sizes 16x16 to 32x32, the white border around the 'i' looks muddy
> due to the scaling. Maybe using a brighter orange tone might suffice so
> that the border can be omitted completely without losing contrast.
>
> Cheers,
>
> Ingo
>
> ___
> 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] Logo Consolidation

[Oliver Walters]

Here is a revised version:

http://imgur.com/a/DysJm

On Thu, Mar 2, 2017 at 6:41 PM, Ingo Kletti 
wrote:

> Hi,
>
> I like the use of the schematic/pcb elements.
>
> It also looks much better at small scales
>>
>
> I tried the scaling and made a mockup at icon resolutions from 16x16 to
> 64x64 with 8 pixel steps (16, 24, 32, etc.), see attachment. Scaling works
> good IMO, but cannot avoid bike-shedding:
>
> On the sizes 16x16 to 32x32, the white border around the 'i' looks muddy
> due to the scaling. Maybe using a brighter orange tone might suffice so
> that the border can be omitted completely without losing contrast.
>
> Cheers,
>
> Ingo
>
> ___
> 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

[Oliver Walters]

Is there any objection to applying this patch in its current form? Note
that all it prevents is users accidentally joining pins that are already
invisible AND non-connect.

Cheers,
Oliver

On Wed, Feb 8, 2017 at 11:05 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Urgh, patch attached here.
>
> On Wed, Feb 8, 2017 at 11:04 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> I have amended the patch to only ignore connection of pins that are both
>> INVISIBLE and NC (Electrical Type = Not Connected). This will improve the
>> safety of the current libraries which do contain many parts with NC pins
>> set as invisible.
>>
>> It will also NOT change the behaviour of people using invisible pins for
>> one-to-many connection.
>>
>> Thoughts?
>>
>> On Tue, Feb 7, 2017 at 7:47 PM, Oliver Walters <
>> oliver.henry.walt...@gmail.com> 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

[Kicad-developers] [RFC] Strange libedit behaviour

[Oliver Walters]

I have recently noticed some very strange libedit behaviour, where
performing an action on a pin at a given location performs the same action
on all pins at that same location.

Consider the following examples, where two pins are located in the same x,y
position:

Example A - Edit Pin
- Place two pins in the same position
- Edit one (e.g. Press "E" and clarify selection
- Change anything except for pin number (name,  type, length)
- Hit "ok"
- All pins at that location will be set to the parameters in the window
(except for pin-number)

Example B - Delete pin
- Place two pins in the same position
- Delete one pin (after clarifying selection)
- All pins are deleted

The offending source code is here:

Example A
lib_pin.cpp

Here most functions to edit a given pin act on given pin children of the
parent, which is exposing all the other pins at the same location...


Example B
libeditframe.cpp : 1345

if( m_drawItem->Type() == LIB_PIN_T )
>
> {
>
> LIB_PIN*pin = (LIB_PIN*) m_drawItem;
>
> wxPoint pos = pin->GetPosition();
>
>
>> part->RemoveDrawItem( (LIB_ITEM*) pin, m_canvas, aDC );
>
>
>> if( SynchronizePins() )
>
> {
>
> LIB_PIN* tmp = part->GetNextPin();
>
>
>> while( tmp != NULL )
>
> {
>
> pin = tmp;
>
> tmp = part->GetNextPin( pin );
>
>
>> if( pin->GetPosition() != pos )
>
> continue;
>
>
>> part->RemoveDrawItem( (LIB_ITEM*) pin );
>
> }
>
> }
>
>
>> m_canvas->Refresh();
>
> }
>
>
Here we have LIB_PIN* item 'pin' which we can delete but then we go through
and delete all the other pins in the same spot?




a) Is this desired? It doesn't intuitively seem like desired behaviour from
a user perspective
b) Why is the code handled in such a convoluted manner here?
c) I would offer a fix but given how strange the code seems I shall await
information on a) and b) in case I am missing some intended feature.

Regards,
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] [RFC] Strange libedit behaviour

[Oliver Walters]

As an extra note to Example B in the above comment, deleting a pin also
deletes any pins in other units (for multi-unit symbols) that are in the
same location.

On Wed, Mar 8, 2017 at 12:04 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> I have recently noticed some very strange libedit behaviour, where
> performing an action on a pin at a given location performs the same action
> on all pins at that same location.
>
> Consider the following examples, where two pins are located in the same
> x,y position:
>
> Example A - Edit Pin
> - Place two pins in the same position
> - Edit one (e.g. Press "E" and clarify selection
> - Change anything except for pin number (name,  type, length)
> - Hit "ok"
> - All pins at that location will be set to the parameters in the window
> (except for pin-number)
>
> Example B - Delete pin
> - Place two pins in the same position
> - Delete one pin (after clarifying selection)
> - All pins are deleted
>
> The offending source code is here:
>
> Example A
> lib_pin.cpp
>
> Here most functions to edit a given pin act on given pin children of the
> parent, which is exposing all the other pins at the same location...
>
>
> Example B
> libeditframe.cpp : 1345
>
> if( m_drawItem->Type() == LIB_PIN_T )
>>
>> {
>>
>> LIB_PIN*pin = (LIB_PIN*) m_drawItem;
>>
>> wxPoint pos = pin->GetPosition();
>>
>>
>>> part->RemoveDrawItem( (LIB_ITEM*) pin, m_canvas, aDC );
>>
>>
>>> if( SynchronizePins() )
>>
>> {
>>
>> LIB_PIN* tmp = part->GetNextPin();
>>
>>
>>> while( tmp != NULL )
>>
>> {
>>
>> pin = tmp;
>>
>> tmp = part->GetNextPin( pin );
>>
>>
>>> if( pin->GetPosition() != pos )
>>
>> continue;
>>
>>
>>> part->RemoveDrawItem( (LIB_ITEM*) pin );
>>
>> }
>>
>> }
>>
>>
>>> m_canvas->Refresh();
>>
>> }
>>
>>
> Here we have LIB_PIN* item 'pin' which we can delete but then we go
> through and delete all the other pins in the same spot?
>
>
>
>
> a) Is this desired? It doesn't intuitively seem like desired behaviour
> from a user perspective
> b) Why is the code handled in such a convoluted manner here?
> c) I would offer a fix but given how strange the code seems I shall await
> information on a) and b) in case I am missing some intended feature.
>
> Regards,
> 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] [PATCH] eeschema - label editor

[Oliver Walters]

Attached is a small patch that addresses two usability issues in the label
editor in eeschema:

1. Set wxTextCtrl flag wxTE_RICH so that pressing Ctrl+Backspace deletes an
entire word, rather than inserting a strange character
2. Add numeric validation to the text size field


label-editor.patch
Description: Binary data
___
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

[Oliver Walters]

Wayne,

Is there any possibility that this will break existing schematic
> netlists?


There is no guarantee that this will not change netlist, especially as
netlist association is performed based on x,y position of pins.

I have just tested this, opening the same schematic in versions with this
patch ON / OFF. The NC connections are made / unmade whenever the schematic
is loaded.

I do not believe there is any way around this.

Oliver

On Wed, Mar 8, 2017 at 12:54 AM, Wayne Stambaugh 
wrote:

> Oliver,
>
> Is there any possibility that this will break existing schematic
> netlists?  I'm assuming this patch only prevents the user from
> generating new invisible/no-connect connections.
>
> Is anyone else opposed to this?
>
> Cheers,
>
> Wayne
>
> On 3/7/2017 7:33 AM, Oliver Walters wrote:
> > Is there any objection to applying this patch in its current form? Note
> > that all it prevents is users accidentally joining pins that are already
> > invisible AND non-connect.
> >
> > Cheers,
> > Oliver
> >
> > On Wed, Feb 8, 2017 at 11:05 PM, Oliver Walters
> > mailto:oliver.henry.walt...@gmail.com>>
> > wrote:
> >
> > Urgh, patch attached here.
> >
> > On Wed, Feb 8, 2017 at 11:04 PM, Oliver Walters
> >  > <mailto:oliver.henry.walt...@gmail.com>> wrote:
> >
> > I have amended the patch to only ignore connection of pins that
> > are both INVISIBLE and NC (Electrical Type = Not Connected).
> > This will improve the safety of the current libraries which do
> > contain many parts with NC pins set as invisible.
> >
> >     It will also NOT change the behaviour of people using invisible
> > pins for one-to-many connection.
> >
> > Thoughts?
> >
> > On Tue, Feb 7, 2017 at 7:47 PM, Oliver Walters
> >  > <mailto:oliver.henry.walt...@gmail.com>> 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
> > <http://i.imgur.com/3gModvW.png>
> >
> > after: http://i.imgur.com/r8O7c3Y.png
> > <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
> >
>
> ___
> 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

[Oliver Walters]

Then, can we look at this when the new eeschema file format is introduced?
Then we'll have the ability to map one pin to multiple pads so there'll be
no need for invisible pin connection.

On 9 Mar 2017 02:38, "Wayne Stambaugh"  wrote:

> Thank you for the reply.  If your patch is causing this, then I wont
> merge it.  Breaking schematics would violate our backwards compatibility
> policy.  I'm fine if we change the wire connection tool to prevent this
> in the future but we should not be changing existing connections.
>
>
> On 3/8/2017 4:20 AM, Oliver Walters wrote:
> > Wayne,
> >
> > Is there any possibility that this will break existing schematic
> > netlists?
> >
> >
> > There is no guarantee that this will not change netlist, especially as
> > netlist association is performed based on x,y position of pins.
> >
> > I have just tested this, opening the same schematic in versions with
> > this patch ON / OFF. The NC connections are made / unmade whenever the
> > schematic is loaded.
> >
> > I do not believe there is any way around this.
> >
> > Oliver
> >
> > On Wed, Mar 8, 2017 at 12:54 AM, Wayne Stambaugh  > <mailto:stambau...@gmail.com>> wrote:
> >
> > Oliver,
> >
> > Is there any possibility that this will break existing schematic
> > netlists?  I'm assuming this patch only prevents the user from
> > generating new invisible/no-connect connections.
> >
> > Is anyone else opposed to this?
> >
> > Cheers,
> >
> > Wayne
> >
> > On 3/7/2017 7:33 AM, Oliver Walters wrote:
> > > Is there any objection to applying this patch in its current form?
> Note
> > > that all it prevents is users accidentally joining pins that are
> already
> > > invisible AND non-connect.
> > >
> > > Cheers,
> > > Oliver
> > >
> > > On Wed, Feb 8, 2017 at 11:05 PM, Oliver Walters
> > >  > <mailto:oliver.henry.walt...@gmail.com>
> > <mailto:oliver.henry.walt...@gmail.com
> > <mailto:oliver.henry.walt...@gmail.com>>>
> > > wrote:
> > >
> > > Urgh, patch attached here.
> > >
> > > On Wed, Feb 8, 2017 at 11:04 PM, Oliver Walters
> > > mailto:oliver.henry.walters@
> gmail.com>
> > > <mailto:oliver.henry.walt...@gmail.com
> > <mailto:oliver.henry.walt...@gmail.com>>> wrote:
> > >
> > > I have amended the patch to only ignore connection of pins
> that
> > > are both INVISIBLE and NC (Electrical Type = Not
> Connected).
> > > This will improve the safety of the current libraries
> which do
> > > contain many parts with NC pins set as invisible.
> > >
> > > It will also NOT change the behaviour of people using
> invisible
> > > pins for one-to-many connection.
> > >
> > > Thoughts?
> > >
> > > On Tue, Feb 7, 2017 at 7:47 PM, Oliver Walters
> > >  oliver.henry.walt...@gmail.com>
> > > <mailto:oliver.henry.walt...@gmail.com
> > <mailto:oliver.henry.walt...@gmail.com>>> 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
> > > <http://i.imgur.com/3gModvW.png <

[Kicad-developers] [PATCH] eeschema - improve menu entry text

[Oliver Walters]

This patch changes the "Doc" string in the right-click menu for symbols in
eeschema

Current text -> "Doc"
New text -> "Open Documentation"


doc-string.patch
Description: Binary data
___
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 the busy cursor while loading libraries

[Oliver Walters]

>
> Slow?  I have noticed that the library loading slowness appeared with
> the new IO manager thing. Although I don't have any proff to quanify
> that.


I can also attest that (at least on Windows) the more recently nightlies
(corresponding to the new IO plugin, approximately) take ~10s to load a
library set that was previously < 1s.

Once the libraries are loaded, eeschema takes an additional length of time
(~10s) to open, whereas previously it opened "instantly"

On Thu, Mar 9, 2017 at 8:54 AM, Nick Østergaard  wrote:

> 2017-03-08 22:33 GMT+01:00 Wayne Stambaugh :
> > On 3/8/2017 4:08 PM, Chris Pavlina wrote:
> >> That's why I submitted such a trivial patch to the list first, I figured
> >> someone would say something ;)
> >>
> >> It does make sense to me, because the GUI is blocked. The busy cursor
> >> says to me "yes, the GUI is supposed to be blocked right now, it's not
> >> frozen". Even with a progress bar, it can seem unresponsive -
> >> particularly if 1) the progress bar ends up obscured, as can happen with
> >> 'weird' window managers sometimes, or 2) if a single library takes a
> >> particularly long time to load, which I'm sure will only get worse if we
> >> eventually allow loading them over the internet like for footprint libs.
> >
> > It's the old belt and suspender method.  Users have got to quit using
> > those 'weird' window managers.  It causes way too much grief.  I'm
> > surprised that a single library load takes long enough to need a busy
> > cursor but I'm not opposed to the patch.  Does the progress bar in
> > wxWidgets have a continuous mode?  That doesn't solve the hidden
> > progress window issue though.
> >
>
> I like the non-continous mode.
>
> Slow?  I have noticed that the library loading slowness appeared with
> the new IO manager thing. Although I don't have any proff to quanify
> that.
>
> >>
> >>
> >> On Wed, Mar 08, 2017 at 03:55:10PM -0500, Wayne Stambaugh wrote:
> >>> Does showing a progress dialog and a busy cursor at the same time make
> >>> sense?
> >>>
> >>> On 3/8/2017 3:36 PM, Chris Pavlina wrote:
>  Hi,
> 
>  This patch enables display of the "busy" cursor while schematic
>  libraries are being loaded. Tested on Linux, Windows 10, and macOS
>  10.12.
> 
> 
> 
>  ___
>  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] [PATCH] Show the busy cursor while loading libraries

[Oliver Walters]

>
> Doesn't that just depend on how big and how many libs are specied in
> the pro file?  This is of course project specific.


Yes, but I can do a direct comparison, opening the same project with an
older build and a newer build, and get glaringly different results in terms
of loading speed.

On Thu, Mar 9, 2017 at 9:56 AM, Nick Østergaard  wrote:

> 2017-03-08 23:52 GMT+01:00 Chris Pavlina :
> > On Thu, Mar 09, 2017 at 09:46:54AM +1100, Oliver Walters wrote:
> >> >
> >> > Slow?  I have noticed that the library loading slowness appeared with
> >> > the new IO manager thing. Although I don't have any proff to quanify
> >> > that.
> >>
> >>
> >> I can also attest that (at least on Windows) the more recently nightlies
> >> (corresponding to the new IO plugin, approximately) take ~10s to load a
> >> library set that was previously < 1s.
> >>
> >> Once the libraries are loaded, eeschema takes an additional length of
> time
> >> (~10s) to open, whereas previously it opened "instantly"
> >
> > I've noticed this too. Funny enough it doesn't seem to happen for all
> > projects for me. I wonder if it's something only being done sometimes,
> > or a polynomial time explosion.
> >
> > Either way someone needs to point the business end of a profiler at the
> > library loader.
> >
>
> Doesn't that just depend on how big and how many libs are specied in
> the pro file?  This is of course project specific.
>
> >>
> >> On Thu, Mar 9, 2017 at 8:54 AM, Nick Østergaard 
> wrote:
> >>
> >> > 2017-03-08 22:33 GMT+01:00 Wayne Stambaugh :
> >> > > On 3/8/2017 4:08 PM, Chris Pavlina wrote:
> >> > >> That's why I submitted such a trivial patch to the list first, I
> figured
> >> > >> someone would say something ;)
> >> > >>
> >> > >> It does make sense to me, because the GUI is blocked. The busy
> cursor
> >> > >> says to me "yes, the GUI is supposed to be blocked right now, it's
> not
> >> > >> frozen". Even with a progress bar, it can seem unresponsive -
> >> > >> particularly if 1) the progress bar ends up obscured, as can
> happen with
> >> > >> 'weird' window managers sometimes, or 2) if a single library takes
> a
> >> > >> particularly long time to load, which I'm sure will only get worse
> if we
> >> > >> eventually allow loading them over the internet like for footprint
> libs.
> >> > >
> >> > > It's the old belt and suspender method.  Users have got to quit
> using
> >> > > those 'weird' window managers.  It causes way too much grief.  I'm
> >> > > surprised that a single library load takes long enough to need a
> busy
> >> > > cursor but I'm not opposed to the patch.  Does the progress bar in
> >> > > wxWidgets have a continuous mode?  That doesn't solve the hidden
> >> > > progress window issue though.
> >> > >
> >> >
> >> > I like the non-continous mode.
> >> >
> >> > Slow?  I have noticed that the library loading slowness appeared with
> >> > the new IO manager thing. Although I don't have any proff to quanify
> >> > that.
> >> >
> >> > >>
> >> > >>
> >> > >> On Wed, Mar 08, 2017 at 03:55:10PM -0500, Wayne Stambaugh wrote:
> >> > >>> Does showing a progress dialog and a busy cursor at the same time
> make
> >> > >>> sense?
> >> > >>>
> >> > >>> On 3/8/2017 3:36 PM, Chris Pavlina wrote:
> >> > >>>> Hi,
> >> > >>>>
> >> > >>>> This patch enables display of the "busy" cursor while schematic
> >> > >>>> libraries are being loaded. Tested on Linux, Windows 10, and
> macOS
> >> > >>>> 10.12.
> >> > >>>>
> >> > >>>>
> >> > >>>>
> >> > >>>> ___
> >> > >>>> Mailing list: https://launchpad.net/~kicad-developers
> >> > >>>> Post to : kicad-developers@lists.launchpad.net
> >> > >>>> Unsubscribe : https://launchpad.net/~kicad-developers
> >> > >>>> More he

Re: [Kicad-developers] [RFC] Strange libedit behaviour

[Oliver Walters]

Can anyone provide some insight into why the pins are being edited in this
fashion? Why not just edit the pin directly as its pointer is passed to the
various edit / delete functions?

On Wed, Mar 8, 2017 at 12:59 AM, Sergey A. Borshch <
sb...@users.sourceforge.net> wrote:

> On 07.03.2017 15:07, Oliver Walters wrote:
>
>> As an extra note to Example B in the above comment, deleting a pin also
>> deletes
>> any pins in other units (for multi-unit symbols) that are in the same
>> location.
>>
> This bug appears again and again every year or two.
>
> --
> Regards,
>   Sergey A. Borshchmailto: sb...@sourceforge.net
> SB ELDI ltd. Riga, Latvia
>
> ___
> 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] Strange libedit behaviour

[Oliver Walters]

JP,

Ah, ok. I have not known of this behavior before - now that you say this I
can see the button you mean.

Thanks,

On Thu, Mar 9, 2017 at 6:31 PM, jp charras  wrote:

> Le 09/03/2017 à 00:52, Oliver Walters a écrit :
> > Can anyone provide some insight into why the pins are being edited in
> this fashion? Why not just
> > edit the pin directly as its pointer is passed to the various edit /
> delete functions?
> >
>
> When a symbol has many units, and units are interchangeable, pins are
> coupled for edition
> (because "units are interchangeable" *imply* there are at the same
> location)
>
> Therefore (but it can be disabled by a tool of the main horizontal
> toolbar) add, move and delete are
> coupled, to avoid breaking a symbol and make edition more easy.
> However, the shape and texts can be (and often must be) set for each pin.
>
> For "units are not interchangeable", pins are not coupled.
>
> This behavior exists since the beginning of Kicad, and is it really
> strange?
>
>
> --
> 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

[Kicad-developers] Footprint features - stable vs nightly

[Oliver Walters]

Hi all,

Can someone tell me a complete list of the differences between footprint
"features" in nightly and stable? There is a recent issue where someone
added a footprint using roundrect pads and broke a library for someone
using stable.

I can easily add a search for "roundrect" to the automated library checker
but what else should I be looking for?

As an aside, I think it would be **very** helpful if the footprint library
loader was able to skip over "bad" footprints and continue to load.
Currently a single bad footprint prevents any subsequent footprints from
loading. If we had the ability to skip bad ones, then we could add "future"
footprints and these would simply be ignored by stable version.

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] PCBnew polygons

[Oliver Walters]

I see that JP is working on courtyard overlap checks, which is very
exciting.

PCB features such as courtyard, board outline, etc would be much more user
friendly if they were implemented as polygons rather than individual lines.

Is implementing a general purpose polygon drawing class in the roadmap?
It's already possible for zones, and this works very well.

Polygons would be a huge time saver! Is anyone working on this?

Cheers
___
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] PCBnew polygons

[Oliver Walters]

If we were considering such an extension, we should really make it
extensible to more than just straight-line segments, even if those
extensions are not implemented immediately.

e.g. arc segments would be very useful!

On Mon, Mar 20, 2017 at 10:34 AM, José Ignacio 
wrote:

> It would be interesting to just implement a graphic polyline class that
> could work both in eeschema and pcbnew, it would be an extension of the
> existing line one, that could case a (nice) change in the file format.
>
> On Sun, Mar 19, 2017 at 4:43 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> I see that JP is working on courtyard overlap checks, which is very
>> exciting.
>>
>> PCB features such as courtyard, board outline, etc would be much more
>> user friendly if they were implemented as polygons rather than individual
>> lines.
>>
>> Is implementing a general purpose polygon drawing class in the roadmap?
>> It's already possible for zones, and this works very well.
>>
>> Polygons would be a huge time saver! Is anyone working on this?
>>
>> Cheers
>>
>> ___
>> 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] UI improvements

[Oliver Walters]

No matter what they are called, it should be *one* thing. Currently there
seems to be a few options.

Schematic items - symbol / chip / component
PCB item - footprint / module / package

On Thu, Mar 23, 2017 at 1:30 PM, Chris Pavlina 
wrote:

> Are we calling them "symbols" now? Internally they are called with
> "components" or "parts" depending on whether they are on a schematic...
>
> On Thu, Mar 23, 2017 at 03:25:03PM +1300, Simon Wells wrote:
> > just a slight segue is it not better to refer to symbols rather
> > than components? as with the footprints being seperated from the
> > symbols i don't see the justification for calling it a component (will
> > also require renaming other stuff)
> >
> > On 23 March 2017 at 12:12, Chris Pavlina 
> wrote:
> > > On Wed, Mar 22, 2017 at 11:53:40PM +0100, Clemens Koller wrote:
> > >> Hello, Fabrizio!
> > >>
> > >> The horizontal + vertical justify radio buttons could possibly be
> improved by showing the alignment visually as it's done in [1] by using a 3
> x 3 radio button matrix. It can also reduce the number of clicks to 1 to
> adjust hor + vert simultaneously.
> > >>
> > >> The timestamp is not human readable. It seems strange to me to dump
> it as hex-number on the UI. (WTF!?)
> > >
> > > I'm struggling to think of a use for this. Maybe for power users, to
> > > jump quickly to the component in the raw sch file by searching for it -
> > > but why not just search for the reference?
> > >
> > > I wonder how many people would complain if I took that out.
> > >
> > >>
> > >> The Component/Chip Name thingy seems to be lost a bit on the lower
> left. Maybe some sorting of the elements based on the usage/setup procedure
> as well as logic dependency could do some good.
> > >>
> > >> Regards,
> > >>
> > >> Clemens
> > >>
> > >> [1] https://wiki.openoffice.org/wiki/File:WG9-9.png
> > >>
> > >>
> > >>
> > >>
> > >> On 2017-03-22 10:32, Fabrizio Tappero wrote:
> > >> > hi guys,
> > >> > I am looking at some new icons that were introduced in kicad by the
> people who made the related functionalities and at the user experience in
> general. If any of you guys has any feedback about possible (aesthetic) UI
> improvements I would love to know.
> > >> >
> > >> > Specifically I am looking at this menu.
> > >> >
> > >> > Inline image 1
> > >> >
> > >> > the section "Chip Name" is a part that I use a lot and I find a
> little "mysterious". Before going further with a possible patch to improve
> a little the usability of it I would like to know if there is any of you
> interesting in giving an opinion. I would love to know from the person who
> made it what exactly is the Chip Name section for. I feel it is not so
> evident to the user.
> > >> >
> > >> > cheers
> > >> > Fabrizio
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > ___
> > >> > 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] [FEATURE] Component table viewer

[Oliver Walters]

Oh, that's embarrassing, it appear that I have attached the inverse of the
patch!

I'll send a new patch later today - sorry!


On Sun, Apr 2, 2017 at 1:15 AM, jp charras  wrote:

> Le 01/04/2017 à 14:53, Oliver Walters a écrit :
> > After a long break on this project I have finally rounded the edges off
> the component table viewer I
> > have been working on.
> >
> > This is a table/spreadsheet view of all the components in the schematic,
> which allows bulk editing,
> > grouping components, and exporting to CSV/TSV/HTML BOM.
> >
> > Here's some screenshots of it in action:
> >
> > http://imgur.com/gallery/WUwek
> >
> > I have tried to limit the complexity as far as possible, so that it's
> not too cumbersome for users.
> >
> > Any changes you make in the table are highlighted and can be reverted
> (back to the values in the
> > schematic).
> >
> > When you close the view, all changes are pushed back to the schematic,
> and the bulk-edit is pushed
> > to the undo-stack as a single item (meaning that you can easily undo all
> the changes you just made).
> >
> > Please let me know of any errors or edge cases!
> >
> > Patch has been rebased to latest master at time of this email.
> >
> > Cheers,
> > Oliver
> >
>
> Thanks Oliver.
>
> But are you sure this is the right patch?
> It looks like it remove many code, but does not add something.
>
>
> --
> 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] [FEATURE] Component table viewer

[Oliver Walters]

Just a friendly reminder about this, I haven't heard anything since
attaching the correct patches.

Cheers

On 7 Apr 2017 19:27, "Oliver Walters" 
wrote:

> I am very sorry about this, three mistakes in a row!
>
> It has been pointed out that I have attached the patches in the incorrect
> order.
>
> To prevent this I have attached a single patch for each commit. They are
> attached to this email (ignore previous patches) and should be applied in
> order _001 , _002.
>
> Sorry! :)
>
> On Sat, Apr 1, 2017 at 11:53 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> After a long break on this project I have finally rounded the edges off
>> the component table viewer I have been working on.
>>
>> This is a table/spreadsheet view of all the components in the schematic,
>> which allows bulk editing, grouping components, and exporting to
>> CSV/TSV/HTML BOM.
>>
>> Here's some screenshots of it in action:
>>
>> http://imgur.com/gallery/WUwek
>>
>> I have tried to limit the complexity as far as possible, so that it's not
>> too cumbersome for users.
>>
>> Any changes you make in the table are highlighted and can be reverted
>> (back to the values in the schematic).
>>
>> When you close the view, all changes are pushed back to the schematic,
>> and the bulk-edit is pushed to the undo-stack as a single item (meaning
>> that you can easily undo all the changes you just made).
>>
>> Please let me know of any errors or edge cases!
>>
>> Patch has been rebased to latest master at time of this email.
>>
>> 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] [FEATURE] Component table viewer

[Oliver Walters]

Thomas,

References are not displayed correctly when using duplicated
> subschematics.


Can you provide some more information? What is a duplicated subschematic?
What does an incorrectly displayed reference look like?

 Search functionality (using Ctrl+F) does not work with collapsed
> grouped references


I didn't even know there was a search function.


>  Even when the dialog says "Save and Close", it actually only writes
> the changes to the schematic. When you close the schematic you don't get
> a notification to save your work, as well as you are not able to click
> the save button when your only change was adjusting names of footprints
> using the component table viewer.


It sounds like the changes are not marking the schematic as "dirty". Can
someone with more knowledge than me in this area please point me to how I
would dirtify the schematic?

Cheers,
Oliver

On Sat, Apr 15, 2017 at 9:33 PM, Thomas Pointhuber  wrote:

> Hi Oliver,
>
> nice work, and I hope it get merged into master soon.
>
> Some issues I found so far (using your github branch):
>
> * References are not displayed correctly when using duplicated
> subschematics.
> * Search functionality (using Ctrl+F) does not work with collapsed
> grouped references
> * Even when the dialog says "Save and Close", it actually only writes
> the changes to the schematic. When you close the schematic you don't get
> a notification to save your work, as well as you are not able to click
> the save button when your only change was adjusting names of footprints
> using the component table viewer.
>
> Regards, Thomas
>
>
> ___
> 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] [FEATURE] Component table viewer

[Oliver Walters]

On Fri, Apr 14, 2017 at 7:51 PM, Nick Østergaard  wrote:

> Hmm, another small issue.
>
> When I have a part with a value of 10µ  in kicad it will render as
> 10µ in the html output (Big a-circumflex) It looks right in the csv.
>

I do not see this - http://i.imgur.com/iQ6jKBB.png

What OS are you running?


>
> 2017-04-14 11:07 GMT+02:00 Nick Østergaard :
> > I can confirmthat the assert I reported is fixed with the second patch.
> >
> > 2017-04-13 23:40 GMT+02:00 Oliver Walters  com>:
> >> Just a friendly reminder about this, I haven't heard anything since
> >> attaching the correct patches.
> >>
> >> Cheers
> >>
> >> On 7 Apr 2017 19:27, "Oliver Walters" 
> >> wrote:
> >>>
> >>> I am very sorry about this, three mistakes in a row!
> >>>
> >>> It has been pointed out that I have attached the patches in the
> incorrect
> >>> order.
> >>>
> >>> To prevent this I have attached a single patch for each commit. They
> are
> >>> attached to this email (ignore previous patches) and should be applied
> in
> >>> order _001 , _002.
> >>>
> >>> Sorry! :)
> >>>
> >>> On Sat, Apr 1, 2017 at 11:53 PM, Oliver Walters
> >>>  wrote:
> >>>>
> >>>> After a long break on this project I have finally rounded the edges
> off
> >>>> the component table viewer I have been working on.
> >>>>
> >>>> This is a table/spreadsheet view of all the components in the
> schematic,
> >>>> which allows bulk editing, grouping components, and exporting to
> >>>> CSV/TSV/HTML BOM.
> >>>>
> >>>> Here's some screenshots of it in action:
> >>>>
> >>>> http://imgur.com/gallery/WUwek
> >>>>
> >>>> I have tried to limit the complexity as far as possible, so that it's
> not
> >>>> too cumbersome for users.
> >>>>
> >>>> Any changes you make in the table are highlighted and can be reverted
> >>>> (back to the values in the schematic).
> >>>>
> >>>> When you close the view, all changes are pushed back to the schematic,
> >>>> and the bulk-edit is pushed to the undo-stack as a single item
> (meaning that
> >>>> you can easily undo all the changes you just made).
> >>>>
> >>>> Please let me know of any errors or edge cases!
> >>>>
> >>>> Patch has been rebased to latest master at time of this email.
> >>>>
> >>>> 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
> >>
>
___
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] [FEATURE] Component table viewer

[Oliver Walters]

Thomas, et al,

I have attached _003 patch which now ensures that the "Save" button is
activated when you make changes in the table.

Please apply this on top of the other two and let me know if it fixes that
issue.

Thanks,
Oliver

On Sat, Apr 15, 2017 at 9:33 PM, Thomas Pointhuber  wrote:

> Hi Oliver,
>
> nice work, and I hope it get merged into master soon.
>
> Some issues I found so far (using your github branch):
>
> * References are not displayed correctly when using duplicated
> subschematics.
> * Search functionality (using Ctrl+F) does not work with collapsed
> grouped references
> * Even when the dialog says "Save and Close", it actually only writes
> the changes to the schematic. When you close the schematic you don't get
> a notification to save your work, as well as you are not able to click
> the save button when your only change was adjusting names of footprints
> using the component table viewer.
>
> Regards, Thomas
>
>
> ___
> 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
>
>
From 6cef9ed2702e12b9aadbbdfc7228155f1befb875 Mon Sep 17 00:00:00 2001
From: Oliver Walters 
Date: Sun, 16 Apr 2017 16:43:59 +1000
Subject: [PATCH] Mark schematic as dirty

Notify schematic of changes when window is closed
---
 eeschema/dialogs/dialog_bom_editor.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/eeschema/dialogs/dialog_bom_editor.cpp b/eeschema/dialogs/dialog_bom_editor.cpp
index 12f77c6..f4b73b4 100644
--- a/eeschema/dialogs/dialog_bom_editor.cpp
+++ b/eeschema/dialogs/dialog_bom_editor.cpp
@@ -153,6 +153,8 @@ void DIALOG_BOM_EDITOR::OnBomEditorClosed( wxCloseEvent& event )
 m_bom->ApplyFieldChanges();
 m_parent->Refresh();
 }
+
+m_parent->OnModify();
 }
 
 Destroy();
-- 
2.7.4

___
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] [FEATURE] Component table viewer

[Oliver Walters]

JP,

Thanks for the feedback.

In the component table, multi-unit symbols are "compressed" into a single
entry. Change a field value for one and it will change for all units of
that symbol.

For "duplicate" references, perhaps the best approach is to only allow a
certain reference to be added once to the table?

However this does not represent the true state of the schematic - component
count would be incorrect, for one.

Any suggestions?

On 17 Apr 2017 00:31, "jp charras"  wrote:

Le 16/04/2017 à 15:12, Oliver Walters a écrit :
> It's not KiCad that "knows" to exclude testing points, etc - my Python
BOM script has a series of
> regex filters that remove a whole swathe of virtual components.
>
> Sometimes you actually want test points to be in the BoM e.g. for loading
probe hooks onto the board.
>
> Eventually I want to add such filtering to this tool but I'd rather have
the first round merged
> first before the feature set becomes too complicated.
>
> Can someone with intimate knowledge provide some info on how components
in sheets that are
> referenced multiple times should be annotated in the BOM? I feel that
sending a BOM with duplicate
> references is wrong...
>

See const wxString GetRef( const SCH_SHEET_PATH* sheet ) in sch_component.h

The field F0 is not really the reference. It is the reference current
displayed on the screen.
It is the reference only for simple hierarchies, because there is only one
reference by symbol.

Complex hierarchies (i.e. having more than one instance of a given sheet)
are always tricky to handle.
Especially, because the same component is shared by all instances, only the
reference is specific to
each instance.
By definition, all other fields are shared.
Therefore you cannot set for instance the value field (or the footprint
name field) of shared
components with different texts.
If a field is modified, it must be also modified in all rows linked to this
shared component in your
Component table viewer, which shows components as a flattened schematic
(like in a netlist).
(Perhaps all references of this shared component should be displayed in the
same row)

Components with multiple unites by package are also a bit tricky to manage.

Complex hierarchies having components with multiple unites by package are
*especially* tricky.

--
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] kicad.pro with all schematic libs

[Oliver Walters]

If all the libraries are added by default, it can take a significant amount
of time to load them when KiCad starts. Perhaps we need to better inform
users of the presence of these other libraries?

On 17 Apr 2017 08:55, "Andrey Kuznetsov"  wrote:

> Does the default lib list ship with the kicad-lib or the kicad main
> program?
> I think it should be the former so that the kicad-lib provides the
> defaults based on whatever libraries they deem stable and default, and
> kicad program reads in the lib list and loads the libraries in that list.
> Yes kicad will be dependent on kicad-lib in order to have any default
> libraries at all, but assuming people maintain kicad-lib it shouldn't be a
> problem.
>
> I too found it annoying that a lot of libraries were not loaded by default
> and I had to add them manually.
>
> On Sun, Apr 16, 2017 at 3:29 PM, Nick Østergaard 
> wrote:
>
>> I added kicad-lib-comitters, I would like to know why that think about
>> this.
>>
>> 2017-04-16 22:49 GMT+02:00 "Jörg Hermann" :
>> > Hello,
>> >
>> > KiCad ships with 92 schematic ibraries, but kicad.pro contains only 29.
>> > I suggest defaulting to have all libs in kicad.pro by replacing the 29
>> libs
>> > with my list.
>> > I suggest applying this to devel and stable.
>> >
>> > Best regards and happy easter eggs to all!
>> >
>> > Jörg Hermann
>> >
>> > LibName1=74xgxx
>> > LibName2=74xx
>> > LibName3=ac-dc
>> > LibName4=actel
>> > LibName5=adc-dac
>> > LibName6=allegro
>> > LibName7=Altera
>> > LibName8=analog_devices
>> > LibName9=analog_switches
>> > LibName10=atmel
>> > LibName11=audio
>> > LibName12=battery_management
>> > LibName13=bbd
>> > LibName14=bosch
>> > LibName15=brooktre
>> > LibName16=cmos_ieee
>> > LibName17=cmos4000
>> > LibName18=conn
>> > LibName19=contrib
>> > LibName20=cypress
>> > LibName21=dc-dc
>> > LibName22=device
>> > LibName23=digital-audio
>> > LibName24=diode
>> > LibName25=display
>> > LibName26=dsp
>> > LibName27=elec-unifil
>> > LibName28=ESD_Protection
>> > LibName29=ftdi
>> > LibName30=gennum
>> > LibName31=graphic
>> > LibName32=hc11
>> > LibName33=intel
>> > LibName34=interface
>> > LibName35=intersil
>> > LibName36=ir
>> > LibName37=Lattice
>> > LibName38=leds
>> > LibName39=linear
>> > LibName40=logo
>> > LibName41=maxim
>> > LibName42=mechanical
>> > LibName43=memory
>> > LibName44=microchip
>> > LibName45=microchip_dspic33dsc
>> > LibName46=microchip_pic10mcu
>> > LibName47=microchip_pic12mcu
>> > LibName48=microchip_pic16mcu
>> > LibName49=microchip_pic18mcu
>> > LibName50=microchip_pic24mcu
>> > LibName51=microchip_pic32mcu
>> > LibName52=microcontrollers
>> > LibName53=modules
>> > LibName54=motor_drivers
>> > LibName55=motorola
>> > LibName56=motors
>> > LibName57=msp430
>> > LibName58=nordicsemi
>> > LibName59=nxp
>> > LibName60=nxp_armmcu
>> > LibName61=onsemi
>> > LibName62=opto
>> > LibName63=Oscillators
>> > LibName64=philips
>> > LibName65=power
>> > LibName66=Power_Management
>> > LibName67=powerint
>> > LibName68=pspice
>> > LibName69=references
>> > LibName70=regul
>> > LibName71=relays
>> > LibName72=rfcom
>> > LibName73=sensors
>> > LibName74=silabs
>> > LibName75=siliconi
>> > LibName76=stm32
>> > LibName77=stm8
>> > LibName78=supertex
>> > LibName79=switches
>> > LibName80=texas
>> > LibName81=transf
>> > LibName82=transistors
>> > LibName83=triac_thyristor
>> > LibName84=ttl_ieee
>> > LibName85=valves
>> > LibName86=video
>> > LibName87=wiznet
>> > LibName88=Worldsemi
>> > LibName89=Xicor
>> > LibName90=xilinx
>> > LibName91=zetex
>> > LibName92=Zilog
>> >
>> >
>> >
>> > ___
>> > 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
>>
>
>
>
> --
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss the
> future [JFK]
>
> kandre...@gmail.com
> Live Long and Prosper,
> Andrey
>
> ___
> 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] [FEATURE] Component table viewer

[Oliver Walters]

JP, others,

After further investigation, I have worked out why the components with
duplicated references were displaying incorrectly.

Patch_004 is attached, Thomas can you confirm that it fixes the display for
you?

Kind Regards,
Oliver

On Mon, Apr 17, 2017 at 7:53 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> JP,
>
> Thanks for the feedback.
>
> In the component table, multi-unit symbols are "compressed" into a single
> entry. Change a field value for one and it will change for all units of
> that symbol.
>
> For "duplicate" references, perhaps the best approach is to only allow a
> certain reference to be added once to the table?
>
> However this does not represent the true state of the schematic -
> component count would be incorrect, for one.
>
> Any suggestions?
>
> On 17 Apr 2017 00:31, "jp charras"  wrote:
>
> Le 16/04/2017 à 15:12, Oliver Walters a écrit :
> > It's not KiCad that "knows" to exclude testing points, etc - my Python
> BOM script has a series of
> > regex filters that remove a whole swathe of virtual components.
> >
> > Sometimes you actually want test points to be in the BoM e.g. for
> loading probe hooks onto the board.
> >
> > Eventually I want to add such filtering to this tool but I'd rather have
> the first round merged
> > first before the feature set becomes too complicated.
> >
> > Can someone with intimate knowledge provide some info on how components
> in sheets that are
> > referenced multiple times should be annotated in the BOM? I feel that
> sending a BOM with duplicate
> > references is wrong...
> >
>
> See const wxString GetRef( const SCH_SHEET_PATH* sheet ) in sch_component.h
>
> The field F0 is not really the reference. It is the reference current
> displayed on the screen.
> It is the reference only for simple hierarchies, because there is only one
> reference by symbol.
>
> Complex hierarchies (i.e. having more than one instance of a given sheet)
> are always tricky to handle.
> Especially, because the same component is shared by all instances, only
> the reference is specific to
> each instance.
> By definition, all other fields are shared.
> Therefore you cannot set for instance the value field (or the footprint
> name field) of shared
> components with different texts.
> If a field is modified, it must be also modified in all rows linked to
> this shared component in your
> Component table viewer, which shows components as a flattened schematic
> (like in a netlist).
> (Perhaps all references of this shared component should be displayed in
> the same row)
>
> Components with multiple unites by package are also a bit tricky to manage.
>
> Complex hierarchies having components with multiple unites by package are
> *especially* tricky.
>
> --
> 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
>
>
>
From f1f954cc80992bc095849a2ddc6cc3bffad4f417 Mon Sep 17 00:00:00 2001
From: Oliver Walters 
Date: Mon, 17 Apr 2017 12:08:21 +1000
Subject: [PATCH] Fixed display of references for duplicate sheets

Display part reference rather than REFERENCE field value
---
 eeschema/bom_table_model.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eeschema/bom_table_model.cpp b/eeschema/bom_table_model.cpp
index a43d749..5301e95 100644
--- a/eeschema/bom_table_model.cpp
+++ b/eeschema/bom_table_model.cpp
@@ -456,7 +456,7 @@ bool BOM_TABLE_COMPONENT::AddUnit( SCH_REFERENCE aUnit )
 }
 break;
 case BOM_COL_ID_REFERENCE:
-value = cmp->GetField( REFERENCE )->GetText();
+value = aUnit.GetRef();
 break;
 case BOM_COL_ID_VALUE:
 value = cmp->GetField( VALUE )->GetText();
-- 
2.7.4

___
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] [FEATURE] Component table viewer

[Oliver Walters]

So how do we proceed here? Is there a 'global' undo stack? If not:

A) don't allow changes made in the component table viewer to be undone
B) Make an undo entry for each sheet that has changed symbols

A) is easier but the user would need to quit-without-save to undo changes

B) is more difficult and doesn't solve the undo operations getting out of
order either, as the user could inject another operation on a given sheet.

Suggestions?

On 18 Apr 2017 01:26, "Wayne Stambaugh"  wrote:

> On 4/17/2017 10:21 AM, jp charras wrote:
> > Le 17/04/2017 à 04:11, Oliver Walters a écrit :
> >> JP, others,
> >>
> >> After further investigation, I have worked out why the components with
> duplicated references were
> >> displaying incorrectly.
> >>
> >> Patch_004 is attached, Thomas can you confirm that it fixes the display
> for you?
> >>
> >> Kind Regards,
> >> Oliver
> >>
> >> On Mon, Apr 17, 2017 at 7:53 AM, Oliver Walters <
> oliver.henry.walt...@gmail.com
> >
> > Good work, Oliver!
> >
> > I found 2 issues (tested on W7)
> >
> > 1 - m_reloadTableButton is not correctly enabled/disabled.
> > This is due to the way events are managed, and this is OS dependent.
> > To avoid this issue, enable/disable it inside a wxUpdateUIEvent attached
> to this button.
> >
> > 2 - ESC key and ENTER keys do not dismiss the dialog.
> > This is due to the fact you do not have a wxStdDialogButtonSizer, and no
> OK and Cancel button.
> > Please, add it and use the OK button (as usual in a dialog) to transfer
> changes to schematic (do not
> > use a wxCloseEvent to manage that), and obviously Cancel just closes the
> dialog.
> > To do this transfer, just  override TransferDataFromWindow(), that is
> called by wxWidgets when
> > closing a dialog by the OK button.
> >
> > About other things, undo/redo lists should manage only changes made
> inside the corresponding sheet,
> > not in other sheets, to avoid inconsistencies and therefore crashes.
> >
>
> This is one of the reasons I've been reluctant to accept code that
> attempts to change the state of a SCH_SCREEN object other than the
> current SCH_SCREEN object.  It exposes a known flaw in our schematic
> undo/redo design and I have yet to see anyone update the undo/redo
> SCH_SCREEN stacks correctly.  I see the potential for serious issues if
> you do not keep the undo/redo stacks properly synced.  Once you allow
> the modification of information in the SCH_SCREEN object other than the
> current one, you need to update the undo/redo stack for the appropriate
> SCH_SCREEN object.  Otherwise, you wont be able to undo all of the
> changes correctly.
>
> ___
> 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] [FEATURE] Component table viewer

[Oliver Walters]

Cirilo,

Does this mean that the rendering is going to be platform dependent? Is
there a way to enforce consistent rendering?

On Tue, Apr 18, 2017 at 12:05 PM, Cirilo Bernardo  wrote:

> This is a UTF8 vs extended ASCII problem. In UTF8, micro is C2 B5;
> in extended ASCII Latin-1, C2 is the circumflex capital A and B5 is micro.
>
> - Cirilo
>
>
> On Fri, Apr 14, 2017 at 7:51 PM, Nick Østergaard 
> wrote:
> > Hmm, another small issue.
> >
> > When I have a part with a value of 10µ  in kicad it will render as
> > 10µ in the html output (Big a-circumflex) It looks right in the csv.
> >
> > 2017-04-14 11:07 GMT+02:00 Nick Østergaard :
> >> I can confirmthat the assert I reported is fixed with the second patch.
> >>
> >> 2017-04-13 23:40 GMT+02:00 Oliver Walters  com>:
> >>> Just a friendly reminder about this, I haven't heard anything since
> >>> attaching the correct patches.
> >>>
> >>> Cheers
> >>>
> >>> On 7 Apr 2017 19:27, "Oliver Walters" 
> >>> wrote:
> >>>>
> >>>> I am very sorry about this, three mistakes in a row!
> >>>>
> >>>> It has been pointed out that I have attached the patches in the
> incorrect
> >>>> order.
> >>>>
> >>>> To prevent this I have attached a single patch for each commit. They
> are
> >>>> attached to this email (ignore previous patches) and should be
> applied in
> >>>> order _001 , _002.
> >>>>
> >>>> Sorry! :)
> >>>>
> >>>> On Sat, Apr 1, 2017 at 11:53 PM, Oliver Walters
> >>>>  wrote:
> >>>>>
> >>>>> After a long break on this project I have finally rounded the edges
> off
> >>>>> the component table viewer I have been working on.
> >>>>>
> >>>>> This is a table/spreadsheet view of all the components in the
> schematic,
> >>>>> which allows bulk editing, grouping components, and exporting to
> >>>>> CSV/TSV/HTML BOM.
> >>>>>
> >>>>> Here's some screenshots of it in action:
> >>>>>
> >>>>> http://imgur.com/gallery/WUwek
> >>>>>
> >>>>> I have tried to limit the complexity as far as possible, so that
> it's not
> >>>>> too cumbersome for users.
> >>>>>
> >>>>> Any changes you make in the table are highlighted and can be reverted
> >>>>> (back to the values in the schematic).
> >>>>>
> >>>>> When you close the view, all changes are pushed back to the
> schematic,
> >>>>> and the bulk-edit is pushed to the undo-stack as a single item
> (meaning that
> >>>>> you can easily undo all the changes you just made).
> >>>>>
> >>>>> Please let me know of any errors or edge cases!
> >>>>>
> >>>>> Patch has been rebased to latest master at time of this email.
> >>>>>
> >>>>> 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
> >>>
> >
> > ___
> > 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] [FEATURE] Component table viewer

[Oliver Walters]

Wayne,

With this in mind, I am unsure how to determine (given a list of
components) which sheet they originate in.

I need a SCH_EDIT_FRAME* for each component, to work out where to push each
undo operation.

I have a list of SCH_REFERENCE objects, is there a way of determining where
each object originates? Could you point me in the right direction?

Regards,
Oliver

On Tue, Apr 18, 2017 at 6:30 AM, Wayne Stambaugh 
wrote:

> On 4/17/2017 4:18 PM, Oliver Walters wrote:
> > So how do we proceed here? Is there a 'global' undo stack? If not:
>
> Unfortunately there is no global undo stack.  Undo stacks are maintained
> for each unique SCH_SCREEN (schematic file) object.
>
> >
> > A) don't allow changes made in the component table viewer to be undone
> > B) Make an undo entry for each sheet that has changed symbols
> >
> > A) is easier but the user would need to quit-without-save to undo changes
>
> This is less than desirable
>
> >
> > B) is more difficult and doesn't solve the undo operations getting out
> > of order either, as the user could inject another operation on a given
> > sheet.
>
> This would be my preference.  Out of order operations are already an
> issue so this solution doesn't make that issue any worse.  Undo/redo is
> only available for the current sheet so the user would have to change
> sheets in order to undo anything changed in the component properties table.
>
> >
> > Suggestions?
> >
> > On 18 Apr 2017 01:26, "Wayne Stambaugh"  > <mailto:stambau...@gmail.com>> wrote:
> >
> > On 4/17/2017 10:21 AM, jp charras wrote:
> > > Le 17/04/2017 à 04:11, Oliver Walters a écrit :
> > >> JP, others,
> > >>
> > >> After further investigation, I have worked out why the components
> > with duplicated references were
> > >> displaying incorrectly.
> > >>
> > >> Patch_004 is attached, Thomas can you confirm that it fixes the
> > display for you?
> > >>
> > >> Kind Regards,
> > >> Oliver
> > >>
> > >> On Mon, Apr 17, 2017 at 7:53 AM, Oliver Walters
> > mailto:oliver.henry.walters@
> gmail.com>
> > >
> > > Good work, Oliver!
> > >
> > > I found 2 issues (tested on W7)
> > >
> > > 1 - m_reloadTableButton is not correctly enabled/disabled.
> > > This is due to the way events are managed, and this is OS
> dependent.
> > > To avoid this issue, enable/disable it inside a wxUpdateUIEvent
> > attached to this button.
> > >
> > > 2 - ESC key and ENTER keys do not dismiss the dialog.
> > > This is due to the fact you do not have a wxStdDialogButtonSizer,
> > and no OK and Cancel button.
> > > Please, add it and use the OK button (as usual in a dialog) to
> > transfer changes to schematic (do not
> > > use a wxCloseEvent to manage that), and obviously Cancel just
> > closes the dialog.
> > > To do this transfer, just  override TransferDataFromWindow(), that
> > is called by wxWidgets when
> > > closing a dialog by the OK button.
> > >
> > > About other things, undo/redo lists should manage only changes
> > made inside the corresponding sheet,
> > > not in other sheets, to avoid inconsistencies and therefore
> crashes.
> > >
> >
> > This is one of the reasons I've been reluctant to accept code that
> > attempts to change the state of a SCH_SCREEN object other than the
> > current SCH_SCREEN object.  It exposes a known flaw in our schematic
> > undo/redo design and I have yet to see anyone update the undo/redo
> > SCH_SCREEN stacks correctly.  I see the potential for serious issues
> if
> > you do not keep the undo/redo stacks properly synced.  Once you allow
> > the modification of information in the SCH_SCREEN object other than
> the
> > current one, you need to update the undo/redo stack for the
> appropriate
> > SCH_SCREEN object.  Otherwise, you wont be able to undo all of the
> > changes correctly.
> >
> > ___
> > 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

Re: [Kicad-developers] [FEATURE] Component table viewer

[Oliver Walters]

I have attached two more patches that address issues raised by Tom and JP:

_005:
- Adds OK/CANCEL dialog
- Removes onClose event
- Moves UI updates into onUpdateUI event

_006:
- Fixes editing of "duplicate" components (e.g. components on sheets that
are referenced multiple times)
- Editing one of these components will edit ALL instances of that component
in the table

I will next try to work out a sensible way of grouping the UNDO actions
per-sheet. In the mean time if anyone wants to provide feedback on the
latest patches, I would appreciate that.

Regards,
Oliver

On Tue, Apr 18, 2017 at 11:05 PM, Wayne Stambaugh 
wrote:

> On 4/18/2017 5:01 AM, Oliver Walters wrote:
> > Wayne,
> >
> > With this in mind, I am unsure how to determine (given a list of
> > components) which sheet they originate in.
>
> All of this information is in the SCH_REFERENCE object.  You will have
> to cross reference the SCH_SHEET_PATH to find the appropriate
> SCH_SCREEN for each object.  SCH_SCREEN (derived from BASE_SCREEN) is
> where the undo/redo stacks reside.
>
> >
> > I need a SCH_EDIT_FRAME* for each component, to work out where to push
> > each undo operation.
>
> You shouldn't need the SCH_EDIT_FRAME to find the undo/redo stack
> objects if you have the SCH_REFERENCE objects.  See above.
>
> >
> > I have a list of SCH_REFERENCE objects, is there a way of determining
> > where each object originates? Could you point me in the right direction?
> >
> > Regards,
> > Oliver
> >
> > On Tue, Apr 18, 2017 at 6:30 AM, Wayne Stambaugh  > <mailto:stambau...@gmail.com>> wrote:
> >
> > On 4/17/2017 4:18 PM, Oliver Walters wrote:
> > > So how do we proceed here? Is there a 'global' undo stack? If not:
> >
> > Unfortunately there is no global undo stack.  Undo stacks are
> maintained
> > for each unique SCH_SCREEN (schematic file) object.
> >
> > >
> > > A) don't allow changes made in the component table viewer to be
> undone
> > > B) Make an undo entry for each sheet that has changed symbols
> > >
> > > A) is easier but the user would need to quit-without-save to undo
> changes
> >
> > This is less than desirable
> >
> > >
> > > B) is more difficult and doesn't solve the undo operations getting
> out
> > > of order either, as the user could inject another operation on a
> given
> > > sheet.
> >
> > This would be my preference.  Out of order operations are already an
> > issue so this solution doesn't make that issue any worse.  Undo/redo
> is
> > only available for the current sheet so the user would have to change
> > sheets in order to undo anything changed in the component properties
> > table.
> >
> > >
> > > Suggestions?
> > >
> > > On 18 Apr 2017 01:26, "Wayne Stambaugh"  <mailto:stambau...@gmail.com>
> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
> wrote:
> > >
> > > On 4/17/2017 10:21 AM, jp charras wrote:
> > > > Le 17/04/2017 à 04:11, Oliver Walters a écrit :
> > > >> JP, others,
> > > >>
> > > >> After further investigation, I have worked out why the
> components
> > > with duplicated references were
> > > >> displaying incorrectly.
> > > >>
> > > >> Patch_004 is attached, Thomas can you confirm that it fixes
> the
> > > display for you?
> > > >>
> > > >> Kind Regards,
> > > >> Oliver
> > > >>
> > > >> On Mon, Apr 17, 2017 at 7:53 AM, Oliver Walters
> > >  > <mailto:oliver.henry.walt...@gmail.com>
> > <mailto:oliver.henry.walt...@gmail.com
> > <mailto:oliver.henry.walt...@gmail.com>>
> > > >
> > > > Good work, Oliver!
> > > >
> > > > I found 2 issues (tested on W7)
> > > >
> > > > 1 - m_reloadTableButton is not correctly enabled/disabled.
> > > > This is due to the way events are managed, and this is OS
> > dependent.
> > > > To avoid this issue, enable/disable it inside a
> wxUpdateUIEvent
> > > attached to this button.
> > > >
> > > &g

Re: [Kicad-developers] [FEATURE] Component table viewer

[Oliver Walters]

Wayne,

I have now fixed this such that UNDO actions are pushed to the UNDO stack
for the associated sheet. All UNDO actions for a given sheet are grouped so
a single Ctrl-Z will undo all components changed in the table (for the
given sheet).

Please find patch _007 attached (must be appli ed atop all previous
patches).

Let me know if you see any other pressing issues.

Regards,
Oliver

On Tue, Apr 18, 2017 at 6:30 AM, Wayne Stambaugh 
wrote:

> On 4/17/2017 4:18 PM, Oliver Walters wrote:
> > So how do we proceed here? Is there a 'global' undo stack? If not:
>
> Unfortunately there is no global undo stack.  Undo stacks are maintained
> for each unique SCH_SCREEN (schematic file) object.
>
> >
> > A) don't allow changes made in the component table viewer to be undone
> > B) Make an undo entry for each sheet that has changed symbols
> >
> > A) is easier but the user would need to quit-without-save to undo changes
>
> This is less than desirable
>
> >
> > B) is more difficult and doesn't solve the undo operations getting out
> > of order either, as the user could inject another operation on a given
> > sheet.
>
> This would be my preference.  Out of order operations are already an
> issue so this solution doesn't make that issue any worse.  Undo/redo is
> only available for the current sheet so the user would have to change
> sheets in order to undo anything changed in the component properties table.
>
> >
> > Suggestions?
> >
> > On 18 Apr 2017 01:26, "Wayne Stambaugh"  > <mailto:stambau...@gmail.com>> wrote:
> >
> > On 4/17/2017 10:21 AM, jp charras wrote:
> > > Le 17/04/2017 à 04:11, Oliver Walters a écrit :
> > >> JP, others,
> > >>
> > >> After further investigation, I have worked out why the components
> > with duplicated references were
> > >> displaying incorrectly.
> > >>
> > >> Patch_004 is attached, Thomas can you confirm that it fixes the
> > display for you?
> > >>
> > >> Kind Regards,
> > >> Oliver
> > >>
> > >> On Mon, Apr 17, 2017 at 7:53 AM, Oliver Walters
> > mailto:oliver.henry.walters@
> gmail.com>
> > >
> > > Good work, Oliver!
> > >
> > > I found 2 issues (tested on W7)
> > >
> > > 1 - m_reloadTableButton is not correctly enabled/disabled.
> > > This is due to the way events are managed, and this is OS
> dependent.
> > > To avoid this issue, enable/disable it inside a wxUpdateUIEvent
> > attached to this button.
> > >
> > > 2 - ESC key and ENTER keys do not dismiss the dialog.
> > > This is due to the fact you do not have a wxStdDialogButtonSizer,
> > and no OK and Cancel button.
> > > Please, add it and use the OK button (as usual in a dialog) to
> > transfer changes to schematic (do not
> > > use a wxCloseEvent to manage that), and obviously Cancel just
> > closes the dialog.
> > > To do this transfer, just  override TransferDataFromWindow(), that
> > is called by wxWidgets when
> > > closing a dialog by the OK button.
> > >
> > > About other things, undo/redo lists should manage only changes
> > made inside the corresponding sheet,
> > > not in other sheets, to avoid inconsistencies and therefore
> crashes.
> > >
> >
> > This is one of the reasons I've been reluctant to accept code that
> > attempts to change the state of a SCH_SCREEN object other than the
> > current SCH_SCREEN object.  It exposes a known flaw in our schematic
> > undo/redo design and I have yet to see anyone update the undo/redo
> > SCH_SCREEN stacks correctly.  I see the potential for serious issues
> if
> > you do not keep the undo/redo stacks properly synced.  Once you allow
> > the modification of information in the SCH_SCREEN object other than
> the
> > current one, you need to update the undo/redo stack for the
> appropriate
> > SCH_SCREEN object.  Otherwise, you wont be able to undo all of the
> > changes correctly.
> >
> > ___
> > 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 : ht

Re: [Kicad-developers] [FEATURE] Component table viewer

[Oliver Walters]

Wayne,

Is the behaviour I have implemented acceptable?

Regards,
Oliver

On Wed, Apr 19, 2017 at 12:13 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Wayne,
>
> I have now fixed this such that UNDO actions are pushed to the UNDO stack
> for the associated sheet. All UNDO actions for a given sheet are grouped so
> a single Ctrl-Z will undo all components changed in the table (for the
> given sheet).
>
> Please find patch _007 attached (must be appli ed atop all previous
> patches).
>
> Let me know if you see any other pressing issues.
>
> Regards,
> Oliver
>
> On Tue, Apr 18, 2017 at 6:30 AM, Wayne Stambaugh 
> wrote:
>
>> On 4/17/2017 4:18 PM, Oliver Walters wrote:
>> > So how do we proceed here? Is there a 'global' undo stack? If not:
>>
>> Unfortunately there is no global undo stack.  Undo stacks are maintained
>> for each unique SCH_SCREEN (schematic file) object.
>>
>> >
>> > A) don't allow changes made in the component table viewer to be undone
>> > B) Make an undo entry for each sheet that has changed symbols
>> >
>> > A) is easier but the user would need to quit-without-save to undo
>> changes
>>
>> This is less than desirable
>>
>> >
>> > B) is more difficult and doesn't solve the undo operations getting out
>> > of order either, as the user could inject another operation on a given
>> > sheet.
>>
>> This would be my preference.  Out of order operations are already an
>> issue so this solution doesn't make that issue any worse.  Undo/redo is
>> only available for the current sheet so the user would have to change
>> sheets in order to undo anything changed in the component properties
>> table.
>>
>> >
>> > Suggestions?
>> >
>> > On 18 Apr 2017 01:26, "Wayne Stambaugh" > > <mailto:stambau...@gmail.com>> wrote:
>> >
>> > On 4/17/2017 10:21 AM, jp charras wrote:
>> > > Le 17/04/2017 à 04:11, Oliver Walters a écrit :
>> > >> JP, others,
>> > >>
>> > >> After further investigation, I have worked out why the components
>> > with duplicated references were
>> > >> displaying incorrectly.
>> > >>
>> > >> Patch_004 is attached, Thomas can you confirm that it fixes the
>> > display for you?
>> > >>
>> > >> Kind Regards,
>> > >> Oliver
>> > >>
>> > >> On Mon, Apr 17, 2017 at 7:53 AM, Oliver Walters
>> > mailto:oliver.henry.walters@g
>> mail.com>
>> > >
>> > > Good work, Oliver!
>> > >
>> > > I found 2 issues (tested on W7)
>> > >
>> > > 1 - m_reloadTableButton is not correctly enabled/disabled.
>> > > This is due to the way events are managed, and this is OS
>> dependent.
>> > > To avoid this issue, enable/disable it inside a wxUpdateUIEvent
>> > attached to this button.
>> > >
>> > > 2 - ESC key and ENTER keys do not dismiss the dialog.
>> > > This is due to the fact you do not have a wxStdDialogButtonSizer,
>> > and no OK and Cancel button.
>> > > Please, add it and use the OK button (as usual in a dialog) to
>> > transfer changes to schematic (do not
>> > > use a wxCloseEvent to manage that), and obviously Cancel just
>> > closes the dialog.
>> > > To do this transfer, just  override TransferDataFromWindow(), that
>> > is called by wxWidgets when
>> > > closing a dialog by the OK button.
>> > >
>> > > About other things, undo/redo lists should manage only changes
>> > made inside the corresponding sheet,
>> > > not in other sheets, to avoid inconsistencies and therefore
>> crashes.
>> > >
>> >
>> > This is one of the reasons I've been reluctant to accept code that
>> > attempts to change the state of a SCH_SCREEN object other than the
>> > current SCH_SCREEN object.  It exposes a known flaw in our schematic
>> > undo/redo design and I have yet to see anyone update the undo/redo
>> > SCH_SCREEN stacks correctly.  I see the potential for serious
>> issues if
>> > you do not keep the undo/redo stacks properly synced.  Once you
>> allow
>> > the modification of information in 

Re: [Kicad-developers] [FEATURE] Component table viewer

[Oliver Walters]

Wayne,

I tend to agree actually, as I have been developing this the less I think
having a BoM export is appropriate:

1. Separation of tasks - it's simpler and cleaner just as an editing table
2. Python (etc) is way better at data manipulation
3. External scripts are by design much more flexible.

I have some ideas for improving BOM output but I am now thinking they would
be best served not integrated here.

I will remove the buttons and leave those thoughts for another conversation.

Oliver

On 24 Apr 2017 01:47, "Wayne Stambaugh"  wrote:

Oliver,

I finally got a chance to test your patch set and was a bit surprised
what I saw after following the conversation on the mailing list.  I was
under the impression that this was a generic component properties
editing grid not a BOM tool which is what it really is.  I like the idea
of being able to edit component fields in table form.  I'm less thrilled
about the BOM export options.  For those of you who haven't been around
very long, Eeschema used to have a BOM dialog.  It didn't allow for
editing field values but it contained options for various BOM output
types.  Initially this dialog was simple and contained only a few BOM
output types and options.  Of course everyone has their own idea of how
a BOM should be formatted so gradually over time, the BOM dialog and the
underlying BOM output code became a huge mess.  It was finally decided
that the design was no longer maintainable and removed.  It was replaced
by the current system along with samples that provided all of the same
BOM output options from the old BOM dialog.  Except for the field
editing grid, your dialog and BOM code looks a lot like the original BOM
dialog.  I can see the same thing happening all over again.  Why no use
the existing BOM generation code in your dialog rather than re-implement
code that does the exact same thing?  I'm not opposed to field editing
part of the dialog, but I see the BOM output part heading the same
direction as the old BOM dialog.

On 4/20/2017 1:59 AM, Oliver Walters wrote:
> Wayne,
>
> Is the behaviour I have implemented acceptable?
>
> Regards,
> Oliver
>
> On Wed, Apr 19, 2017 at 12:13 AM, Oliver Walters
> mailto:oliver.henry.walt...@gmail.com>>
> wrote:
>
> Wayne,
>
> I have now fixed this such that UNDO actions are pushed to the UNDO
> stack for the associated sheet. All UNDO actions for a given sheet
> are grouped so a single Ctrl-Z will undo all components changed in
> the table (for the given sheet).
>
> Please find patch _007 attached (must be appli ed atop all previous
> patches).
>
> Let me know if you see any other pressing issues.
>
> Regards,
> Oliver
>
> On Tue, Apr 18, 2017 at 6:30 AM, Wayne Stambaugh
> mailto:stambau...@gmail.com>> wrote:
>
> On 4/17/2017 4:18 PM, Oliver Walters wrote:
> > So how do we proceed here? Is there a 'global' undo stack? If
not:
>
> Unfortunately there is no global undo stack.  Undo stacks are
> maintained
> for each unique SCH_SCREEN (schematic file) object.
>
> >
> > A) don't allow changes made in the component table viewer to be
undone
> > B) Make an undo entry for each sheet that has changed symbols
> >
> > A) is easier but the user would need to quit-without-save to
undo changes
>
> This is less than desirable
>
> >
> > B) is more difficult and doesn't solve the undo operations
getting out
> > of order either, as the user could inject another operation on
a given
> > sheet.
>
> This would be my preference.  Out of order operations are already
an
> issue so this solution doesn't make that issue any worse.
> Undo/redo is
> only available for the current sheet so the user would have to
> change
> sheets in order to undo anything changed in the component
> properties table.
>
> >
> > Suggestions?
>     >
> > On 18 Apr 2017 01:26, "Wayne Stambaugh" mailto:stambau...@gmail.com>
> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
wrote:
> >
> > On 4/17/2017 10:21 AM, jp charras wrote:
> > > Le 17/04/2017 à 04:11, Oliver Walters a écrit :
> > >> JP, others,
> > >>
> > >> After further investigation, I have worked out why the
components
> > with duplicated references were
> > >> displaying incorrectly.
> > >>
> > &g

Re: [Kicad-developers] [FEATURE] Component table viewer

[Oliver Walters]

Hi Wayne,

Anything else you need me to do here?

Cheers

On 25 Apr 2017 18:22, "Oliver Walters" 
wrote:

> Wayne,
>
> I have reattached all patches including a new one which does the following:
>
> a) Removes BOM export
> b) Removes Save/Cancel dialog as per JP's request
> c) Fixes speed issue as per JP's request
> d) Small bugfix
>
> These should apply directly to latest master branch.
>
> Cheers
>
> On Tue, Apr 25, 2017 at 12:43 AM, Wayne Stambaugh 
> wrote:
>
>> Oliver,
>>
>> Thank you for your understanding on this issue.  Once you include the
>> patch to remove the BOM code, I will merge this into the master branch.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 4/23/2017 5:41 PM, Oliver Walters wrote:
>> > Wayne,
>> >
>> > I tend to agree actually, as I have been developing this the less I
>> > think having a BoM export is appropriate:
>> >
>> > 1. Separation of tasks - it's simpler and cleaner just as an editing
>> table
>> > 2. Python (etc) is way better at data manipulation
>> > 3. External scripts are by design much more flexible.
>> >
>> > I have some ideas for improving BOM output but I am now thinking they
>> > would be best served not integrated here.
>> >
>> > I will remove the buttons and leave those thoughts for another
>> conversation.
>> >
>> > Oliver
>> >
>> > On 24 Apr 2017 01:47, "Wayne Stambaugh" > > <mailto:stambau...@gmail.com>> wrote:
>> >
>> > Oliver,
>> >
>> > I finally got a chance to test your patch set and was a bit
>> surprised
>> > what I saw after following the conversation on the mailing list.  I
>> was
>> > under the impression that this was a generic component properties
>> > editing grid not a BOM tool which is what it really is.  I like the
>> idea
>> > of being able to edit component fields in table form.  I'm less
>> thrilled
>> > about the BOM export options.  For those of you who haven't been
>> around
>> > very long, Eeschema used to have a BOM dialog.  It didn't allow for
>> > editing field values but it contained options for various BOM output
>> > types.  Initially this dialog was simple and contained only a few
>> BOM
>> > output types and options.  Of course everyone has their own idea of
>> how
>> > a BOM should be formatted so gradually over time, the BOM dialog
>> and the
>> > underlying BOM output code became a huge mess.  It was finally
>> decided
>> > that the design was no longer maintainable and removed.  It was
>> replaced
>> > by the current system along with samples that provided all of the
>> same
>> >     BOM output options from the old BOM dialog.  Except for the field
>> > editing grid, your dialog and BOM code looks a lot like the
>> original BOM
>> > dialog.  I can see the same thing happening all over again.  Why no
>> use
>> > the existing BOM generation code in your dialog rather than
>> re-implement
>> > code that does the exact same thing?  I'm not opposed to field
>> editing
>> > part of the dialog, but I see the BOM output part heading the same
>> > direction as the old BOM dialog.
>> >
>> > On 4/20/2017 1:59 AM, Oliver Walters wrote:
>> > > Wayne,
>> > >
>> > > Is the behaviour I have implemented acceptable?
>> > >
>> > > Regards,
>> > > Oliver
>> > >
>> > > On Wed, Apr 19, 2017 at 12:13 AM, Oliver Walters
>> > > > > <mailto:oliver.henry.walt...@gmail.com>
>> > <mailto:oliver.henry.walt...@gmail.com
>> > <mailto:oliver.henry.walt...@gmail.com>>>
>> > > wrote:
>> > >
>> >     > Wayne,
>> > >
>> > > I have now fixed this such that UNDO actions are pushed to the
>> > UNDO
>> > > stack for the associated sheet. All UNDO actions for a given
>> sheet
>> > > are grouped so a single Ctrl-Z will undo all components
>> changed in
>> > > the table (for the given sheet).
>> > >
>> > > Please find patch _007 attached (must be appli ed atop all
>> > previous
>> > > patches).
>&g

[Kicad-developers] [FEATURE] Partial selection in pcbnew

[Oliver Walters]

I have attached a patch-set that implements "partial selection" of objects
when the selection box is dragged right-to-left.

L -> R = Objects must be completely enclosed to be selected
R -> L = Objects that intersect the selection rectangle will be selected.

To achieve this I had to fix a lot of the HitTest implementations as this
was broken for most shapes, under a variety of edge cases (some HitTest
code did not work at all).

There are two issues I see as outstanding, and am unsure how to proceed:

1. When editing a PCB, selecting part of a footprint (e.g. a line of the
courtyard) selects both that line and the entire footprint. This causes
some issues when the footprint is dragged around the PCB. I believe that
the line should not be selected separately, but the entire footprint should.

2. The inverse of 1. In the footprint editor, selecting a single graphical
item selects the entire footprint. Somehow I would like to filter the
selection such that individual items are selected but NOT the entire
footprint.

Feedback please! :)

I have fixed hit testing (both for wxPoint and EDA_RECT comparison) for:

- Pads (all shapes)
- Lines
- Circles
- Arcs
- Text items
- Zones
- Footprints

Cheers,
Oliver
From 688d986602189b24877dd3296f12d8adb2a5fd9f Mon Sep 17 00:00:00 2001
From: Oliver Walters 
Date: Fri, 21 Apr 2017 00:20:56 +1000
Subject: [PATCH 01/12] Alter selection mode based on drag direction

LEFT > RIGHT = Enclosed selection
RIGHT > LEFT = Touching selection
---
 include/preview_items/selection_area.h |  4 
 pcbnew/tools/selection_tool.cpp| 37 ++
 2 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/include/preview_items/selection_area.h b/include/preview_items/selection_area.h
index c860ee4..d45924b 100644
--- a/include/preview_items/selection_area.h
+++ b/include/preview_items/selection_area.h
@@ -76,6 +76,10 @@ public:
 return wxT( "SELECTION_AREA" );
 }
 
+VECTOR2I GetOrigin() const { return m_origin; }
+
+VECTOR2I GetEnd() const { return m_end; }
+
 private:
 
 /**
diff --git a/pcbnew/tools/selection_tool.cpp b/pcbnew/tools/selection_tool.cpp
index 494fb1c..d31eee7 100644
--- a/pcbnew/tools/selection_tool.cpp
+++ b/pcbnew/tools/selection_tool.cpp
@@ -500,21 +500,50 @@ bool SELECTION_TOOL::selectMultiple()
 
 // Mark items within the selection box as selected
 std::vector selectedItems;
+
+// Filter the view items based on the selection box
 BOX2I selectionBox = area.ViewBBox();
 view->Query( selectionBox, selectedItems ); // Get the list of selected items
 
 std::vector::iterator it, it_end;
 
+int width = area.GetEnd().x - area.GetOrigin().x;
+int height = area.GetEnd().y - area.GetOrigin().y;
+
+// Construct an EDA_RECT to determine BOARD_ITEM selection
+EDA_RECT selectionRect( wxPoint( area.GetOrigin().x, area.GetOrigin().y ),
+wxSize( width, height ) );
+
+selectionRect.Normalize();
+
 for( it = selectedItems.begin(), it_end = selectedItems.end(); it != it_end; ++it )
 {
 BOARD_ITEM* item = static_cast( it->first );
 
-// Add only those items that are visible and fully within the selection box
-if( !item->IsSelected() && selectable( item ) &&
-selectionBox.Contains( item->ViewBBox() ) )
+/* Selection mode depends on direction of drag-selection:
+ * Left > Right : Select objects that are fully enclosed by selection
+ * Right > Left : Select objects that are crossed by selection
+ */
+
+// Add only those items that are visible
+if( !item->IsSelected() && selectable( item ) )
 {
-select( item );
+if( item->HitTest( selectionRect, width >= 0) )
+{
+select( item );
+}
+
 }
+/*
+// Selecting left->right requires full enclosure
+if ( xDelta >= 0 && selectionBox.Contains( item->ViewBBox() ) )
+{
+select( item );
+}
+
+// Selecting right->left requires only
+else if
+*/
 }
 
 if( m_selection.Size() == 1 )
-- 
2.7.4

From db7ac6f20c515c590b652284f4a59645f664beb1 Mon Sep 17 00:00:00 2001
From: Oliver Walters 
Date: Fri, 21 Apr 2017 00:53:57 +1000
Subject: [PATCH 02/12] Fixed ::HitTest for Circle shape

- Testing against rectangle intersection now works correctly
- Previously tested against BoundingBox() not circle outline
---
 c

Re: [Kicad-developers] [FEATURE] Component table viewer

[Oliver Walters]

Wayne,

Thanks for merging!

I will address those points at some stage - there are other ideas I have
too but I thought it was better to get the first iteration done and make
incremental improvements.

Regards,
Oliver

On 3 May 2017 03:25, "Wayne Stambaugh"  wrote:

> Oliver,
>
> This is looking pretty good so I merged your patches into the master
> branch.  I do have a few minor changes that I would like you to make at
> some point:
>
> * Move the OK and Cancel buttons to the bottom of the dialog using a
> wxStdDialogButtonSizer.
>
> * Use dialog style wxDEFAULT_DIALOG_STYLE | wxRESIZE_BORDER.  This will
> remove the stay on top option from the dialog style and add the close
> button decorator to the title bar.
>
> * Set the initial column widths based on their contents rather than
> using a fixed width.
>
> This is a good start but hopefully over time this tool will be extended
> to become a component properties editor rather than just a component
> field editor.  This would be a lot more convenient than opening the
> component properties dialog for every component to edit component
> properties.
>
> Thank you for your contribution to KiCad.
>
> Cheers,
>
> Wayne
>
>
> On 4/25/2017 4:22 AM, Oliver Walters wrote:
> > Wayne,
> >
> > I have reattached all patches including a new one which does the
> following:
> >
> > a) Removes BOM export
> > b) Removes Save/Cancel dialog as per JP's request
> > c) Fixes speed issue as per JP's request
> > d) Small bugfix
> >
> > These should apply directly to latest master branch.
> >
> > Cheers
> >
> > On Tue, Apr 25, 2017 at 12:43 AM, Wayne Stambaugh  > <mailto:stambau...@gmail.com>> wrote:
> >
> > Oliver,
> >
> >     Thank you for your understanding on this issue.  Once you include the
> > patch to remove the BOM code, I will merge this into the master
> branch.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 4/23/2017 5:41 PM, Oliver Walters wrote:
> > > Wayne,
> > >
> > > I tend to agree actually, as I have been developing this the less I
> > > think having a BoM export is appropriate:
> > >
> > > 1. Separation of tasks - it's simpler and cleaner just as an
> editing table
> > > 2. Python (etc) is way better at data manipulation
> > > 3. External scripts are by design much more flexible.
> > >
> > > I have some ideas for improving BOM output but I am now thinking
> they
> > > would be best served not integrated here.
> > >
> > > I will remove the buttons and leave those thoughts for another
> conversation.
> > >
> > > Oliver
> > >
> > > On 24 Apr 2017 01:47, "Wayne Stambaugh"  <mailto:stambau...@gmail.com>
> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
> wrote:
> > >
> > > Oliver,
> > >
> > > I finally got a chance to test your patch set and was a bit
> > surprised
> > > what I saw after following the conversation on the mailing
> > list.  I was
> > > under the impression that this was a generic component
> properties
> > > editing grid not a BOM tool which is what it really is.  I
> > like the idea
> > > of being able to edit component fields in table form.  I'm
> > less thrilled
> > > about the BOM export options.  For those of you who haven't
> > been around
> > > very long, Eeschema used to have a BOM dialog.  It didn't
> > allow for
> > > editing field values but it contained options for various BOM
> > output
> > > types.  Initially this dialog was simple and contained only a
> > few BOM
> > > output types and options.  Of course everyone has their own
> > idea of how
> > > a BOM should be formatted so gradually over time, the BOM
> > dialog and the
> > > underlying BOM output code became a huge mess.  It was finally
> > decided
> > > that the design was no longer maintainable and removed.  It
> > was replaced
> >     > by the current system along with samples that provided all of
> > the same
> > > BOM output options from the old BOM dialog.  Except for the
> field
> > > editing grid, your dialog and BOM code looks a lo

[Kicad-developers] [PATCH] Fixes for component table view

[Oliver Walters]

Wayne, et al,

I have attached a small patch implementing some of the improvements that
you suggested.

- Default column width expanded to match text
- Changed dialog style

Regards,
Oliver
From fe131fbffd74aeed6c6675c8fffaffe06d218bcd Mon Sep 17 00:00:00 2001
From: Oliver Walters 
Date: Wed, 3 May 2017 15:24:58 +1000
Subject: [PATCH] Improvements for component table

Fixed default column width
Fixed dialog style
---
 eeschema/bom_table_model.cpp|  9 +---
 eeschema/dialogs/dialog_bom_editor.cpp  | 14 +++
 eeschema/dialogs/dialog_bom_editor_base.cpp |  2 +-
 eeschema/dialogs/dialog_bom_editor_base.fbp | 36 ++---
 eeschema/dialogs/dialog_bom_editor_base.h   |  2 +-
 5 files changed, 35 insertions(+), 28 deletions(-)

diff --git a/eeschema/bom_table_model.cpp b/eeschema/bom_table_model.cpp
index d531dbd..f22022a 100644
--- a/eeschema/bom_table_model.cpp
+++ b/eeschema/bom_table_model.cpp
@@ -395,7 +395,7 @@ bool BOM_TABLE_GROUP::HasValueChanged( BOM_COLUMN* aField ) const
  *
  * @aSort - Sort the references
  */
-wxArrayString BOM_TABLE_GROUP::GetReferences( bool aSort) const
+wxArrayString BOM_TABLE_GROUP::GetReferences( bool aSort ) const
 {
 wxArrayString refs;
 
@@ -805,13 +805,6 @@ wxDataViewColumn* BOM_TABLE_MODEL::AddColumn( BOM_COLUMN* aColumn, int aPosition
 if( !found )
 m_widget->AppendColumn( column );
 
-//TODO - wxCOL_WIDTH_AUTOSIZE prevents columns from thereafter being resized
-// This requires some further attention
-
-/**
-column->SetWidth( wxCOL_WIDTH_AUTOSIZE );
-column->SetWidth( column->GetWidth() );
-**/
 column->SetResizeable( true );
 
 return column;
diff --git a/eeschema/dialogs/dialog_bom_editor.cpp b/eeschema/dialogs/dialog_bom_editor.cpp
index 84c6b04..1924cd2 100644
--- a/eeschema/dialogs/dialog_bom_editor.cpp
+++ b/eeschema/dialogs/dialog_bom_editor.cpp
@@ -85,6 +85,20 @@ DIALOG_BOM_EDITOR::DIALOG_BOM_EDITOR( SCH_EDIT_FRAME* parent ) :
 
 Update();
 
+m_bomView->Update();
+
+// Set default column widths
+for( unsigned int ii = 0; ii < m_bomView->GetColumnCount(); ii++ )
+{
+auto col = m_bomView->GetColumn( ii );
+
+if( !col )
+continue;
+
+col->SetWidth( wxCOL_WIDTH_AUTOSIZE );
+col->SetResizeable( true );
+}
+
 Layout();
 GetSizer()->SetSizeHints( this );
 Centre();
diff --git a/eeschema/dialogs/dialog_bom_editor_base.cpp b/eeschema/dialogs/dialog_bom_editor_base.cpp
index 018e2b2..bb2f231 100644
--- a/eeschema/dialogs/dialog_bom_editor_base.cpp
+++ b/eeschema/dialogs/dialog_bom_editor_base.cpp
@@ -93,7 +93,7 @@ DIALOG_BOM_EDITOR_BASE::DIALOG_BOM_EDITOR_BASE( wxWindow* parent, wxWindowID id,
 	sbSizer4->Add( m_sdbSizer1, 1, wxEXPAND, 5 );
 	
 	
-	bSizer6->Add( sbSizer4, 1, wxEXPAND, 5 );
+	bSizer6->Add( sbSizer4, 0, wxEXPAND, 10 );
 	
 	
 	m_leftPanel->SetSizer( bSizer6 );
diff --git a/eeschema/dialogs/dialog_bom_editor_base.fbp b/eeschema/dialogs/dialog_bom_editor_base.fbp
index b6427b0..11f796f 100644
--- a/eeschema/dialogs/dialog_bom_editor_base.fbp
+++ b/eeschema/dialogs/dialog_bom_editor_base.fbp
@@ -44,8 +44,8 @@
 
 DIALOG_BOM_EDITOR_BASE
 
-1047,649
-wxCAPTION|wxMAXIMIZE_BOX|wxRESIZE_BORDER|wxSTAY_ON_TOP
+1047,800
+wxDEFAULT_DIALOG_STYLE|wxRESIZE_BORDER
 DIALOG_SHIM; dialog_shim.h
 BOM editor
 
@@ -344,11 +344,11 @@
 bSizer6
 wxVERTICAL
 none
-
+
 5
 wxEXPAND
 0
-
+
 wxID_ANY
 Options
 
@@ -445,11 +445,11 @@
 
 
 
-
+
 5
 wxALL|wxEXPAND
 0
-
+
  

Re: [Kicad-developers] [FEATURE] Partial selection in pcbnew

[Oliver Walters]

Tomasz,

I would be happy to put my new code in a more generic location. I was not
aware of common/geometry and simply fixed the ::HitTest() functions that
were already present for each shape.

I am a little confused by the numerous duplication of the "Rectangle" class
(SHAPE_RECT, EDA_RECT, BOX_2I, etc).

My guess as to how I should implement each HitTest is:

a) Construct a SHAPE_RECT from the EDA_RECT
b) Write generic SHAPE_RECT comparison classes for each other shape (arc,
circle, etc) where they do not already exist
c) Code each HitTest() function as a comindation of SHAPE_RECT tests as
defined in common/geometry?

Regards,
Oliver

On Fri, May 5, 2017 at 7:42 AM, Tomasz Wlostowski  wrote:

> On 02.05.2017 09:25, Oliver Walters wrote:
> > I have attached a patch-set that implements "partial selection" of
> > objects when the selection box is dragged right-to-left.
> >
> > L -> R = Objects must be completely enclosed to be selected
> > R -> L = Objects that intersect the selection rectangle will be selected.
> >
>
> Hi Olivier,
>
> I tested your patch and I like the way it works. As somebody suggested,
> changing the color of the selection area depending on the selection mode
> would make it easier to discover the new selection mode.
>
> > this was broken for most shapes, under a variety of edge cases (some
> > HitTest code did not work at all).
> >
> One remark about the HitTest() functions. We would prefer collision
> tests to be implemented in the geometry library (common/geometry) and so
> decoupled from the board objects to make these functions reusable. As a
> matter of a fact, the geometry library already does most collision
> checks between rectangles and other shapes (except for arcs and
> polysets). I noticed you're good with computational geometry, would you
> be able to move the features you wrote to the geometry library?
>
> Best,
> Tom
>
> > To achieve this I had to fix a lot of the HitTest implementations as
> > There are two issues I see as outstanding, and am unsure how to proceed:
> >
> > 1. When editing a PCB, selecting part of a footprint (e.g. a line of the
> > courtyard) selects both that line and the entire footprint. This causes
> > some issues when the footprint is dragged around the PCB. I believe that
> > the line should not be selected separately, but the entire footprint
> should.
> >
> > 2. The inverse of 1. In the footprint editor, selecting a single
> > graphical item selects the entire footprint. Somehow I would like to
> > filter the selection such that individual items are selected but NOT the
> > entire footprint.
> >
> > Feedback please! :)
> >
> > I have fixed hit testing (both for wxPoint and EDA_RECT comparison) for:
> >
> > - Pads (all shapes)
> > - Lines
> > - Circles
> > - Arcs
> > - Text items
> > - Zones
> > - Footprints
> >
> > 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
> >
>
>
___
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] [FEATURE] Partial selection in pcbnew

[Oliver Walters]

Currently most (all?) of the HitTest code uses intersection tests defined
for EDA_RECT (which is already a large duplication of code). Should I
refactor all of the ones I have touched to use the common/geometry routines?

On Fri, May 5, 2017 at 2:33 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Tomasz,
>
> I would be happy to put my new code in a more generic location. I was not
> aware of common/geometry and simply fixed the ::HitTest() functions that
> were already present for each shape.
>
> I am a little confused by the numerous duplication of the "Rectangle"
> class (SHAPE_RECT, EDA_RECT, BOX_2I, etc).
>
> My guess as to how I should implement each HitTest is:
>
> a) Construct a SHAPE_RECT from the EDA_RECT
> b) Write generic SHAPE_RECT comparison classes for each other shape (arc,
> circle, etc) where they do not already exist
> c) Code each HitTest() function as a comindation of SHAPE_RECT tests as
> defined in common/geometry?
>
> Regards,
> Oliver
>
> On Fri, May 5, 2017 at 7:42 AM, Tomasz Wlostowski <
> tomasz.wlostow...@cern.ch> wrote:
>
>> On 02.05.2017 09:25, Oliver Walters wrote:
>> > I have attached a patch-set that implements "partial selection" of
>> > objects when the selection box is dragged right-to-left.
>> >
>> > L -> R = Objects must be completely enclosed to be selected
>> > R -> L = Objects that intersect the selection rectangle will be
>> selected.
>> >
>>
>> Hi Olivier,
>>
>> I tested your patch and I like the way it works. As somebody suggested,
>> changing the color of the selection area depending on the selection mode
>> would make it easier to discover the new selection mode.
>>
>> > this was broken for most shapes, under a variety of edge cases (some
>> > HitTest code did not work at all).
>> >
>> One remark about the HitTest() functions. We would prefer collision
>> tests to be implemented in the geometry library (common/geometry) and so
>> decoupled from the board objects to make these functions reusable. As a
>> matter of a fact, the geometry library already does most collision
>> checks between rectangles and other shapes (except for arcs and
>> polysets). I noticed you're good with computational geometry, would you
>> be able to move the features you wrote to the geometry library?
>>
>> Best,
>> Tom
>>
>> > To achieve this I had to fix a lot of the HitTest implementations as
>> > There are two issues I see as outstanding, and am unsure how to proceed:
>> >
>> > 1. When editing a PCB, selecting part of a footprint (e.g. a line of the
>> > courtyard) selects both that line and the entire footprint. This causes
>> > some issues when the footprint is dragged around the PCB. I believe that
>> > the line should not be selected separately, but the entire footprint
>> should.
>> >
>> > 2. The inverse of 1. In the footprint editor, selecting a single
>> > graphical item selects the entire footprint. Somehow I would like to
>> > filter the selection such that individual items are selected but NOT the
>> > entire footprint.
>> >
>> > Feedback please! :)
>> >
>> > I have fixed hit testing (both for wxPoint and EDA_RECT comparison) for:
>> >
>> > - Pads (all shapes)
>> > - Lines
>> > - Circles
>> > - Arcs
>> > - Text items
>> > - Zones
>> > - Footprints
>> >
>> > 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
>> >
>>
>>
>
___
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] [FEATURE] Component table viewer

[Oliver Walters]

Steven,

Unless you mean something different to what I think "custom fields" means,
then this is already the case - any extra fields (beyond REFERENCE /
FOOTPRINT / DATSHEET / VALUE) are preesnt to be edited in the table...

On Fri, May 5, 2017 at 10:51 PM, Strontium  wrote:

> Hi Oliver,
>
> Just had a chance to check out your component table viewer, its nice.
> Great work.
>
> Is it on your roadmap to be able to view/edit a components custom fields?
>
> Regards,
> Steven
>
> On 03/05/17 05:35, Oliver Walters wrote:
>
>> Wayne,
>>
>> Thanks for merging!
>>
>> I will address those points at some stage - there are other ideas I have
>> too but I thought it was better to get the first iteration done and make
>> incremental improvements.
>>
>> Regards,
>> 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
>
___
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] [FEATURE] Component table viewer

[Oliver Walters]

>
> And it just so happens that in this schematic NO components have been
> edited to include these default fields/values, so, they don't show up in
> the component table.


I have a patch to fix this now - if a field is empty and a template value
exists, that is placed there instead.


> Also, editing Multipart components is a little quirky, If you change a
> field for a multi-part component, all "parts" update to that value, but if
> any parts have different values, only one is shown in the table and its not
> clear that the underlying multipart field is inconsistent.


This is a hard one as really, multi-part components should *not* have
different values in various fields! I had thought about adding another
level (with an arrow as you suggest) but I think it becomes too
complicated.

On Fri, May 5, 2017 at 11:46 PM, Strontium  wrote:

> Oliver,
>
> This is one of my components:
> http://i.imgur.com/QXyCXXt.png
>
> This is the component table:
> http://i.imgur.com/F2WTRC2.png
>
> The MFG, MPN or EQUIVOK fields in the component aren't shown in the table!
>
> And in doing that I worked out my problem :)
>
> I have MFG/MPN/EQUIVOK defined as "Default Fields" with default values.
> And because the component hasn't been edited, I can edit it and SEE the
> default fields and default values BUT unless I change something they are
> not saved with the component.  And it just so happens that in this
> schematic NO components have been edited to include these default
> fields/values, so, they don't show up in the component table.
>
> It would be nice if the "Default Fields" and their default values show in
> the table if they weren't defined for the component, maybe highlighted in
> some way (Italic, light grey, or something) to indicate they are defaulted
> and not actually set. But now I know why I couldn't see them its not a big
> deal so consider this an Enhancement request.
>
> Also, editing Multipart components is a little quirky, If you change a
> field for a multi-part component, all "parts" update to that value, but if
> any parts have different values, only one is shown in the table and its not
> clear that the underlying multipart field is inconsistent.  Again its not a
> big deal, I just noticed it.  Maybe multipart components should work like
> grouped components, i.e. you can click an arrow and see all the parts and
> edit them individually, or edit the top level component and set them all to
> the same value?  I'm not really sure if this is a good idea or not.
>
> I'm working on an external BOM management tool. It reads a schematic live
> while you edit it in Kicad, and costs it from octopart and/or a database of
> locally defined components, updating in real time.  This tool you have made
> is going to save me an enormous amount of time editing schematics and
> getting all the field metadata consistent.  Thank you.
>
> Two more enhancement ideas:
> 1. A way to update the schematic from edits without closing the table view.
> 2. A way to revert the last edit (undo)
>
> Steven
>
>
> On 05/05/17 20:56, Oliver Walters wrote:
>
> Steven,
>
> Unless you mean something different to what I think "custom fields" means,
> then this is already the case - any extra fields (beyond REFERENCE /
> FOOTPRINT / DATSHEET / VALUE) are preesnt to be edited in the table...
>
> On Fri, May 5, 2017 at 10:51 PM, Strontium  wrote:
>
>> Hi Oliver,
>>
>> Just had a chance to check out your component table viewer, its nice.
>> Great work.
>>
>> Is it on your roadmap to be able to view/edit a components custom fields?
>>
>> Regards,
>> Steven
>>
>> On 03/05/17 05:35, Oliver Walters wrote:
>>
>>> Wayne,
>>>
>>> Thanks for merging!
>>>
>>> I will address those points at some stage - there are other ideas I have
>>> too but I thought it was better to get the first iteration done and make
>>> incremental improvements.
>>>
>>> Regards,
>>> 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
>>
>
>
>
> ___
> 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] [FEATURE] Component table viewer

[Oliver Walters]

>
> Perhaps one feature request regarding custom fields would be (if possible)
> to select which field is used for grouping components, instead of just the
> value field. Either a custom field or one of the standard ones like
> footprint name or symbol name. Think editing all 0402 resistors, or all the
> connectors with the same footprint but different value, etc.


The default behaviour is that *all* fields must match for two components to
be considered "equal".

I have added an option for each column to be removed from this check, so
you can specify as many (or as few) columns as you like.

On Fri, May 5, 2017 at 11:50 PM, José Ignacio  wrote:

> Perhaps one feature request regarding custom fields would be (if possible)
> to select which field is used for grouping components, instead of just the
> value field. Either a custom field or one of the standard ones like
> footprint name or symbol name. Think editing all 0402 resistors, or all the
> connectors with the same footprint but different value, etc.
>
> Thank you very much for your excellent work!
> Jose
>
> On Fri, May 5, 2017 at 7:56 AM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> Steven,
>>
>> Unless you mean something different to what I think "custom fields"
>> means, then this is already the case - any extra fields (beyond REFERENCE /
>> FOOTPRINT / DATSHEET / VALUE) are preesnt to be edited in the table...
>>
>> On Fri, May 5, 2017 at 10:51 PM, Strontium  wrote:
>>
>>> Hi Oliver,
>>>
>>> Just had a chance to check out your component table viewer, its nice.
>>> Great work.
>>>
>>> Is it on your roadmap to be able to view/edit a components custom fields?
>>>
>>> Regards,
>>> Steven
>>>
>>> On 03/05/17 05:35, Oliver Walters wrote:
>>>
>>>> Wayne,
>>>>
>>>> Thanks for merging!
>>>>
>>>> I will address those points at some stage - there are other ideas I
>>>> have too but I thought it was better to get the first iteration done and
>>>> make incremental improvements.
>>>>
>>>> Regards,
>>>> 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
>>>
>>
>>
>> ___
>> 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] [FEATURE] Partial selection in pcbnew

[Oliver Walters]

Three further patch files attached:

- Different color select box based on direction
- Fixed HitTest for EDA_TEXT
- Control modifier unselects anything in rectangle.

The major piece of feedback I need right now is how to perfect the
behaviour of the tool in PCBNEW and MODEDIT:

a) PCBNEW

Selecting part of a MODULE (right to left) will select both the entire
module and also any parts of the module that you touched (lines, pads,
etc). Then, when you move the module, the doubly-selected items are moved
twice! It is hard to describe properly but if you try this you will see
what I mean.

b) MODEDIT

Selecting any item in the footprint selects the entire footprint, which is
highly undesirable. In this case I think the best approach is to filter the
MODULE from the selection entirely. But I am not sure how to do this.

Feedback welcome :)

Regards,
Oliver

On Tue, May 2, 2017 at 5:25 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> I have attached a patch-set that implements "partial selection" of objects
> when the selection box is dragged right-to-left.
>
> L -> R = Objects must be completely enclosed to be selected
> R -> L = Objects that intersect the selection rectangle will be selected.
>
> To achieve this I had to fix a lot of the HitTest implementations as this
> was broken for most shapes, under a variety of edge cases (some HitTest
> code did not work at all).
>
> There are two issues I see as outstanding, and am unsure how to proceed:
>
> 1. When editing a PCB, selecting part of a footprint (e.g. a line of the
> courtyard) selects both that line and the entire footprint. This causes
> some issues when the footprint is dragged around the PCB. I believe that
> the line should not be selected separately, but the entire footprint should.
>
> 2. The inverse of 1. In the footprint editor, selecting a single graphical
> item selects the entire footprint. Somehow I would like to filter the
> selection such that individual items are selected but NOT the entire
> footprint.
>
> Feedback please! :)
>
> I have fixed hit testing (both for wxPoint and EDA_RECT comparison) for:
>
> - Pads (all shapes)
> - Lines
> - Circles
> - Arcs
> - Text items
> - Zones
> - Footprints
>
> Cheers,
> Oliver
>
>
>
From fd1e30e1afa92f83b59ee169fddf2195c5788454 Mon Sep 17 00:00:00 2001
From: Oliver Walters 
Date: Fri, 5 May 2017 15:04:29 +1000
Subject: [PATCH 13/15] Alter selection area colours based on selection mode

- Left to Right is slightly blue (as current)
- Right to left is slightly green
---
 common/preview_items/selection_area.cpp | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/common/preview_items/selection_area.cpp b/common/preview_items/selection_area.cpp
index f66cb1d..a1a4813 100644
--- a/common/preview_items/selection_area.cpp
+++ b/common/preview_items/selection_area.cpp
@@ -29,6 +29,10 @@
 
 using namespace KIGFX::PREVIEW;
 
+// Selection area colours
+const COLOR4D SELECT_COLOR_L2R( 0.3, 0.3, 0.5, 0.3 );  // Slight blue
+const COLOR4D SELECT_COLOR_R2L( 0.3, 0.5, 0.3, 0.3 );  // Slight green
+
 
 SELECTION_AREA::SELECTION_AREA()
 {
@@ -50,6 +54,9 @@ const BOX2I SELECTION_AREA::ViewBBox() const
 
 void SELECTION_AREA::drawPreviewShape( KIGFX::GAL& aGal ) const
 {
+// Set the fill color based on the direction of selection
+aGal.SetFillColor( ( m_origin.x <= m_end.x ) ? SELECT_COLOR_L2R : SELECT_COLOR_R2L );
+
 aGal.DrawRectangle( m_origin, m_end );
 }
 
-- 
2.7.4

From 87d505b559ffcd7f2140f5f561db8d3097c0432a Mon Sep 17 00:00:00 2001
From: Oliver Walters 
Date: Fri, 5 May 2017 15:04:46 +1000
Subject: [PATCH 14/15] Use CTRL modifier to deselect items

---
 common/preview_items/selection_area.cpp |  4 ++--
 pcbnew/tools/selection_tool.cpp | 20 
 pcbnew/tools/selection_tool.h   |  3 +++
 3 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/common/preview_items/selection_area.cpp b/common/preview_items/selection_area.cpp
index a1a4813..001e6df 100644
--- a/common/preview_items/selection_area.cpp
+++ b/common/preview_items/selection_area.cpp
@@ -30,8 +30,8 @@
 using namespace KIGFX::PREVIEW;
 
 // Selection area colours
-const COLOR4D SELECT_COLOR_L2R( 0.3, 0.3, 0.5, 0.3 );  // Slight blue
-const COLOR4D SELECT_COLOR_R2L( 0.3, 0.5, 0.3, 0.3 );  // Slight green
+const COLOR4D SELECT_COLOR_L2R( 0.3, 0.3, 0.6, 0.3 );  // Slight blue
+const COLOR4D SELECT_COLOR_R2L( 0.3, 0.6, 0.3, 0.3 );  // Slight green
 
 
 SELECTION_AREA::SELECTION_AREA()
diff --git a/pcbnew/tools/selection_tool.cpp b/pcbnew/tools/selection_tool.cpp
index 0ea9529..a77e53e 100644
--- a/pcbnew/tools/selection_tool.cpp
+++ b/pcbnew/tools/selection_tool.cpp
@@ -230,6 +230,10 @@ int SELECTION_TOOL::Main( const TOOL_EVENT& aEvent )
 // become the new selection (discarding previously selected items)
 m_additive

Re: [Kicad-developers] [FEATURE] Partial selection in pcbnew

[Oliver Walters]

Maciej,

Thanks, I'll look into that. If you have a chance to look over what I've
done, I'd appreciate that :)

On Sat, May 6, 2017 at 10:17 PM, Maciej Suminski 
wrote:

> Hi Oliver,
>
> I have not tested the patches yet, but my gut feeling says that you miss
> calling SELECTION_TOOL::selectable() to filter out redundant items.
>
> Regards,
> Orson
>
> On 05/06/2017 09:21 AM, Oliver Walters wrote:
> > Three further patch files attached:
> >
> > - Different color select box based on direction
> > - Fixed HitTest for EDA_TEXT
> > - Control modifier unselects anything in rectangle.
> >
> > The major piece of feedback I need right now is how to perfect the
> > behaviour of the tool in PCBNEW and MODEDIT:
> >
> > a) PCBNEW
> >
> > Selecting part of a MODULE (right to left) will select both the entire
> > module and also any parts of the module that you touched (lines, pads,
> > etc). Then, when you move the module, the doubly-selected items are moved
> > twice! It is hard to describe properly but if you try this you will see
> > what I mean.
> >
> > b) MODEDIT
> >
> > Selecting any item in the footprint selects the entire footprint, which
> is
> > highly undesirable. In this case I think the best approach is to filter
> the
> > MODULE from the selection entirely. But I am not sure how to do this.
> >
> > Feedback welcome :)
> >
> > Regards,
> > Oliver
> >
> > On Tue, May 2, 2017 at 5:25 PM, Oliver Walters <
> > oliver.henry.walt...@gmail.com> wrote:
> >
> >> I have attached a patch-set that implements "partial selection" of
> objects
> >> when the selection box is dragged right-to-left.
> >>
> >> L -> R = Objects must be completely enclosed to be selected
> >> R -> L = Objects that intersect the selection rectangle will be
> selected.
> >>
> >> To achieve this I had to fix a lot of the HitTest implementations as
> this
> >> was broken for most shapes, under a variety of edge cases (some HitTest
> >> code did not work at all).
> >>
> >> There are two issues I see as outstanding, and am unsure how to proceed:
> >>
> >> 1. When editing a PCB, selecting part of a footprint (e.g. a line of the
> >> courtyard) selects both that line and the entire footprint. This causes
> >> some issues when the footprint is dragged around the PCB. I believe that
> >> the line should not be selected separately, but the entire footprint
> should.
> >>
> >> 2. The inverse of 1. In the footprint editor, selecting a single
> graphical
> >> item selects the entire footprint. Somehow I would like to filter the
> >> selection such that individual items are selected but NOT the entire
> >> footprint.
> >>
> >> Feedback please! :)
> >>
> >> I have fixed hit testing (both for wxPoint and EDA_RECT comparison) for:
> >>
> >> - Pads (all shapes)
> >> - Lines
> >> - Circles
> >> - Arcs
> >> - Text items
> >> - Zones
> >> - Footprints
> >>
> >> 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
> >
>
> ___
> 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] [FEATURE] Partial selection in pcbnew

[Oliver Walters]

Maciej,

That was it! Thanks for the hint.

#0016 attached, which fixes both issues:

a) No more double-selection of module and module-items (pads / lines / etc)
in PCBNEW
b) Disable selection of entire module in MODEDIT

As far as I can tell this patchset is now working very well.

Regards,
Oliver

On Sat, May 6, 2017 at 10:21 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Maciej,
>
> Thanks, I'll look into that. If you have a chance to look over what I've
> done, I'd appreciate that :)
>
> On Sat, May 6, 2017 at 10:17 PM, Maciej Suminski 
> wrote:
>
>> Hi Oliver,
>>
>> I have not tested the patches yet, but my gut feeling says that you miss
>> calling SELECTION_TOOL::selectable() to filter out redundant items.
>>
>> Regards,
>> Orson
>>
>> On 05/06/2017 09:21 AM, Oliver Walters wrote:
>> > Three further patch files attached:
>> >
>> > - Different color select box based on direction
>> > - Fixed HitTest for EDA_TEXT
>> > - Control modifier unselects anything in rectangle.
>> >
>> > The major piece of feedback I need right now is how to perfect the
>> > behaviour of the tool in PCBNEW and MODEDIT:
>> >
>> > a) PCBNEW
>> >
>> > Selecting part of a MODULE (right to left) will select both the entire
>> > module and also any parts of the module that you touched (lines, pads,
>> > etc). Then, when you move the module, the doubly-selected items are
>> moved
>> > twice! It is hard to describe properly but if you try this you will see
>> > what I mean.
>> >
>> > b) MODEDIT
>> >
>> > Selecting any item in the footprint selects the entire footprint, which
>> is
>> > highly undesirable. In this case I think the best approach is to filter
>> the
>> > MODULE from the selection entirely. But I am not sure how to do this.
>> >
>> > Feedback welcome :)
>> >
>> > Regards,
>> > Oliver
>> >
>> > On Tue, May 2, 2017 at 5:25 PM, Oliver Walters <
>> > oliver.henry.walt...@gmail.com> wrote:
>> >
>> >> I have attached a patch-set that implements "partial selection" of
>> objects
>> >> when the selection box is dragged right-to-left.
>> >>
>> >> L -> R = Objects must be completely enclosed to be selected
>> >> R -> L = Objects that intersect the selection rectangle will be
>> selected.
>> >>
>> >> To achieve this I had to fix a lot of the HitTest implementations as
>> this
>> >> was broken for most shapes, under a variety of edge cases (some HitTest
>> >> code did not work at all).
>> >>
>> >> There are two issues I see as outstanding, and am unsure how to
>> proceed:
>> >>
>> >> 1. When editing a PCB, selecting part of a footprint (e.g. a line of
>> the
>> >> courtyard) selects both that line and the entire footprint. This causes
>> >> some issues when the footprint is dragged around the PCB. I believe
>> that
>> >> the line should not be selected separately, but the entire footprint
>> should.
>> >>
>> >> 2. The inverse of 1. In the footprint editor, selecting a single
>> graphical
>> >> item selects the entire footprint. Somehow I would like to filter the
>> >> selection such that individual items are selected but NOT the entire
>> >> footprint.
>> >>
>> >> Feedback please! :)
>> >>
>> >> I have fixed hit testing (both for wxPoint and EDA_RECT comparison)
>> for:
>> >>
>> >> - Pads (all shapes)
>> >> - Lines
>> >> - Circles
>> >> - Arcs
>> >> - Text items
>> >> - Zones
>> >> - Footprints
>> >>
>> >> 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
>> >
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> Mor

Re: [Kicad-developers] Component table improvements

[Oliver Walters]

JP,

You are correct, wxID_CANCEL was all that was needed.

#004 is attached

Thanks for the feedback :)

On Mon, May 8, 2017 at 4:40 PM, jp charras  wrote:

> Le 08/05/2017 à 05:29, Oliver Walters a écrit :
> > JP,
> >
> > I was expecting this response :)
> >
> > I was happy to acquiesce initially on this style change as it was only
> my preference over yours, but
> > reading through the responses of a lot of people on the original thread,
> I believe that the
> > usability of simple OK and CANCEL buttons is not what people (not just
> myself) expect.
> >
> > a) Lots of people calling for an "Apply changes" button. This means
> "apply changes now, but keep
> > editing".
> > b) The "Discard changes" button is very useful, and is also different
> from "Apply changes and close"
> > c) In the context of the component table, "OK" and "Cancel" are somewhat
> obtuse.
> > d) An "OK" button performs the same actions as "Apply changes", then
> "Close"
> > e) A "Cancel" button performs the same actions as "Discard changes" then
> "Close"
> >
> > If I revert to using the wxStdDialogButtonSizer, there will be 4 buttons
> which perform confusing
> > combinations of the same actions!
> >
> > I think that "Apply Changes" "Revert changes" and "Close" are sufficient
> and have the benefit of
> > accurately describing what they do.
> >
> > I propose that I catch the ESCAPE_KEY event and this performs the same
> action as pressing the
> > "Close" button (asks for confirmation if there are unsaved changes,
> otherwise closes).
> >
> > Would this be acceptable?
> >
> > Kind regards
> > Oliver
>
>
> AFAIK, the ESC key issue is due to the fact there is no wxID_CANCEL event
> id attached to a button in
> the dialog.
> (the wxStdDialogButtonSizer fixes this issue just because it uses
> wxID_CANCEL for the Cancel button)
>
> Just using wxID_CANCEL for the close button should fix this issue.
> Try it.
>
> >
> > On Sun, May 7, 2017 at 9:00 PM, jp charras  <mailto:jp.char...@wanadoo.fr>> wrote:
> >
> > Le 06/05/2017 à 07:35, Oliver Walters a écrit :
> > > After feedback on the original thread
> > (https://lists.launchpad.net/kicad-developers/msg29057.html
> > <https://lists.launchpad.net/kicad-developers/msg29057.html>)
> > >
> > > I have made some further improvements to the component table:
> > >
> > > a) Add values from template fields where no value exists
> > > b) Allow users to specify which fields are used for sorting
> (default = all fields)
> > > c) Add an "Apply changes" button which updates components
> accordingly
> > > d) UI improvements
> > >
> > > Please find patches attached.
> >
> > Thanks, Oliver for all this very good work.
> >
> > But your last patch is partially a regression:
> > the ESC key does not work anymore.
> >
> > I suggest you to use the wxStdDialogButtonSizer container to manage
> OK, Cancel, Apply buttons (they
> > are all standard buttons).
> > This wxStdDialogButtonSizer container has many advantages for
> multi-platform applications (for
> > instance look and fell).
> >
> > "Revert Changes" button must be managed outside this container.
> >
> > >From my point of view, confirmation when the dialog is closed
> should not occur when clicking  OK or
> > Cancel button, only ESC key.
> >
> > However I am not sure if it is easy to manage ESC key and Cancel
> button with different options.
> >
> > --
> > Jean-Pierre CHARRAS
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers <
> https://launchpad.net/%7Ekicad-developers>
> > Post to : kicad-developers@lists.launchpad.net  kicad-developers@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~kicad-developers <
> https://launchpad.net/%7Ekicad-developers>
> > More help   : https://help.launchpad.net/ListHelp <
> https://help.launchpad.net/ListHelp>
> >
> >
>
>
> --
> Jean-Pierre CHARRAS
>
From bace329a706796187b2d43b0b1ce3ffdfbab47ca Mon Sep 17 00:00:00 2001
From: Oliver Walters 
Date: Mon, 8 May 2017 17:18:12 +1000
Subject: [PATCH] ESCAPE key closes dialog

-

Re: [Kicad-developers] Component table improvements

[Oliver Walters]

Thanks JP :)

On Mon, May 8, 2017 at 8:45 PM, jp charras  wrote:

> Le 08/05/2017 à 09:19, Oliver Walters a écrit :
> > JP,
> >
> > You are correct, wxID_CANCEL was all that was needed.
> >
> > #004 is attached
> >
> > Thanks for the feedback :)
> >
>
> Thanks.
> I committed your patches.
>
> --
> 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

Re: [Kicad-developers] [FEATURE] Partial selection in pcbnew

[Oliver Walters]

I was approaching this from having used mechanical CAD tools where the
direction of selection is the standard approach. Whatever function is
chosen, it will still be required that the users adjust to the new style,
manuals updated, etc.

Is assigning what is essentially the last remaining modifier key worth it
for this?

On 8 May 2017 23:55, "Nick Østergaard"  wrote:

2017-05-08 14:59 GMT+02:00 Maciej Sumiński :
> Hi Oliver,
>
> I took your set of patches for a test drive. I am glad that you thought
> about the subtractive mode in the selection tool, it really fits there.
> Regarding different selection modes - I like the idea, but I think the
> two modes should be more distinct, changing the selection direction
> might be not enough.
>

I personally prefer modifier keys as we are used to in Gimp and Inkscape.

> I observed another user trying out the tool and he could not tell how
> does it work, but noticed it is a bit different than the old tool.
>
> Perhaps one of the following would work:
>
> - change the selection box colors so they are easier to tell apart (my
> mate was surprised to find out there were two colors for the selection
box)
>
> - change the mode using a key modifier (I think only Alt is left free)
> or mouse button
>
> - add an option to select the default mode (though I do not really like
> having too many options to set)
>
> I agree with Tom about the geometry library. IIRC currently it is only
> used by the PNS router, but ultimately we would like to use it in the
> primary model. The library already provides methods to check for
> collisions between basic shapes, yet we still need a few more.
> It would be a pity to drop your code now, so perhaps we could merge the
> code as is and fix the methods during the model refactor.
>
> Just to let you know, there are a few code formatting violations (mostly
> not keeping two empty lines between method definitions in .cpp files),
> but as they are infrequent - I can handle them myself.
>
> Regards,
> Orson
>
> On 05/07/2017 02:11 AM, Oliver Walters wrote:
>> Maciej,
>>
>> That was it! Thanks for the hint.
>>
>> #0016 attached, which fixes both issues:
>>
>> a) No more double-selection of module and module-items (pads / lines /
etc)
>> in PCBNEW
>> b) Disable selection of entire module in MODEDIT
>>
>> As far as I can tell this patchset is now working very well.
>>
>> Regards,
>> Oliver
>>
>> On Sat, May 6, 2017 at 10:21 PM, Oliver Walters <
>> oliver.henry.walt...@gmail.com> wrote:
>>
>>> Maciej,
>>>
>>> Thanks, I'll look into that. If you have a chance to look over what I've
>>> done, I'd appreciate that :)
>>>
>>> On Sat, May 6, 2017 at 10:17 PM, Maciej Suminski <
maciej.sumin...@cern.ch>
>>> wrote:
>>>
>>>> Hi Oliver,
>>>>
>>>> I have not tested the patches yet, but my gut feeling says that you
miss
>>>> calling SELECTION_TOOL::selectable() to filter out redundant items.
>>>>
>>>> Regards,
>>>> Orson
>>>>
>>>> On 05/06/2017 09:21 AM, Oliver Walters wrote:
>>>>> Three further patch files attached:
>>>>>
>>>>> - Different color select box based on direction
>>>>> - Fixed HitTest for EDA_TEXT
>>>>> - Control modifier unselects anything in rectangle.
>>>>>
>>>>> The major piece of feedback I need right now is how to perfect the
>>>>> behaviour of the tool in PCBNEW and MODEDIT:
>>>>>
>>>>> a) PCBNEW
>>>>>
>>>>> Selecting part of a MODULE (right to left) will select both the entire
>>>>> module and also any parts of the module that you touched (lines, pads,
>>>>> etc). Then, when you move the module, the doubly-selected items are
>>>> moved
>>>>> twice! It is hard to describe properly but if you try this you will
see
>>>>> what I mean.
>>>>>
>>>>> b) MODEDIT
>>>>>
>>>>> Selecting any item in the footprint selects the entire footprint,
which
>>>> is
>>>>> highly undesirable. In this case I think the best approach is to
filter
>>>> the
>>>>> MODULE from the selection entirely. But I am not sure how to do this.
>>>>>
>>>>> Feedback welcome :)
>>>>>
>>>>> Regards,
>>>>> Oliver
>>>>>
>>>>> On Tue, May 2, 2017 at 5:25 PM, Oliver Walters <
>>>&

[Kicad-developers] [QUESTION] Multiple symbols in .sweet format

[Oliver Walters]

Hi all,

This is probably best addressed to Wayne, or anyone else who is keenly
interested in the new .sweet format.

Currently there is a very heated thread on the forums regarding different
resistor representations (people have too much time on their hands) -
https://forum.kicad.info/t/alternate-resistor-symbol-kicad-evaluation-for-company-use/6310/62

In the upcoming .sweet format is there to be any concept of multiple
representstions for schematic symbols? The obvious example is the resistor
symbol.

Regards,
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] [QUESTION] Multiple symbols in .sweet format

[Oliver Walters]

You're not missing anything, the forum post is a complete waste of time.

However, I'm simply wondering if an "alternative symbol without duplicating
component" is on the roadmap for .sweet.

On 9 May 2017 08:47, "Wayne Stambaugh"  wrote:

> On 5/8/2017 6:22 PM, Oliver Walters wrote:
> > Hi all,
> >
> > This is probably best addressed to Wayne, or anyone else who is keenly
> > interested in the new .sweet format.
> >
> > Currently there is a very heated thread on the forums regarding
> > different resistor representations (people have too much time on their
> > hands)
> > - https://forum.kicad.info/t/alternate-resistor-symbol-
> kicad-evaluation-for-company-use/6310/62
>
> I will refrain from such unnecessary discussions due to lack of time.
> There is absolutely nothing preventing users from using what ever
> resistor symbol they want.  I don't understand the issue.  Just create a
> new resistor symbol and give it a different name than 'R'.  Whether you
> put it in a new library or an existing library seems really doesn't
> matter.  Am I missing something else here?
>
> >
> > In the upcoming .sweet format is there to be any concept of multiple
> > representstions for schematic symbols? The obvious example is the
> > resistor symbol.
> >
> > Regards,
> > 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
> >
>
>
> ___
> 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] [FEATURE] Partial selection in pcbnew

[Oliver Walters]

Is there a way do draw a zoom-independent dashed line in GAL?

I have an updated idea on selection box rendering that I think would be
better.

1. Blue interior shows normal selection
2. Green interior shows additive selection
3. Red interior shows subtractive selection
4. Solid border shows bounding box selection
5. Dashed border shows partial selection mode.

This way all the selection options are presented to the user in a fairly
obvious manner.

On 9 May 2017 08:40, "José Ignacio"  wrote:

Or switching between object and grid snap :)

On Mon, May 8, 2017 at 5:34 PM, Wayne Stambaugh 
wrote:

> I tend to lean toward Oliver's approach.  Most CAD tools I've used have
> this type of includes vs intersects selection paradigm.  I don't see the
> need to tie up the modifier key if we don't have to.  I would prefer
> that we keep a modifier key open for something like orthogonal move.
>
> On 5/8/2017 5:51 PM, Oliver Walters wrote:
> > I was approaching this from having used mechanical CAD tools where the
> > direction of selection is the standard approach. Whatever function is
> > chosen, it will still be required that the users adjust to the new
> > style, manuals updated, etc.
> >
> > Is assigning what is essentially the last remaining modifier key worth
> > it for this?
> >
> > On 8 May 2017 23:55, "Nick Østergaard"  > <mailto:oe.n...@gmail.com>> wrote:
> >
> > 2017-05-08 14:59 GMT+02:00 Maciej Sumiński  > <mailto:maciej.sumin...@cern.ch>>:
> > > Hi Oliver,
> > >
> > > I took your set of patches for a test drive. I am glad that you
> > thought
> > > about the subtractive mode in the selection tool, it really fits
> > there.
> > > Regarding different selection modes - I like the idea, but I think
> the
> > > two modes should be more distinct, changing the selection direction
> > > might be not enough.
> > >
> >
> > I personally prefer modifier keys as we are used to in Gimp and
> > Inkscape.
> >
> > > I observed another user trying out the tool and he could not tell
> how
> > > does it work, but noticed it is a bit different than the old tool.
> > >
> > > Perhaps one of the following would work:
> > >
> > > - change the selection box colors so they are easier to tell apart
> (my
> > > mate was surprised to find out there were two colors for the
> > selection box)
> > >
> > > - change the mode using a key modifier (I think only Alt is left
> free)
> > > or mouse button
> > >
> > > - add an option to select the default mode (though I do not really
> > like
> > > having too many options to set)
> > >
> > > I agree with Tom about the geometry library. IIRC currently it is
> only
> > > used by the PNS router, but ultimately we would like to use it in
> the
> > > primary model. The library already provides methods to check for
> > > collisions between basic shapes, yet we still need a few more.
> > > It would be a pity to drop your code now, so perhaps we could
> > merge the
> > > code as is and fix the methods during the model refactor.
> > >
> > > Just to let you know, there are a few code formatting violations
> > (mostly
> > > not keeping two empty lines between method definitions in .cpp
> files),
> > > but as they are infrequent - I can handle them myself.
> > >
> > > Regards,
> > > Orson
> > >
> > > On 05/07/2017 02:11 AM, Oliver Walters wrote:
> > >> Maciej,
> > >>
> > >> That was it! Thanks for the hint.
> > >>
> > >> #0016 attached, which fixes both issues:
> > >>
> > >> a) No more double-selection of module and module-items (pads /
> > lines / etc)
> > >> in PCBNEW
> > >> b) Disable selection of entire module in MODEDIT
> > >>
> > >> As far as I can tell this patchset is now working very well.
> > >>
> > >> Regards,
> > >> Oliver
> > >>
> > >> On Sat, May 6, 2017 at 10:21 PM, Oliver Walters <
> > >> oliver.henry.walt...@gmail.com
> > <mailto:oliver.henry.walt...@gmail.com>> wrote:
> > >>
> > >>> Maciej,
> > >>>

Re: [Kicad-developers] [QUESTION] Multiple symbols in .sweet format

[Oliver Walters]

Thanks for the clarification :)

On Tue, May 9, 2017 at 9:06 AM, Wayne Stambaugh 
wrote:

> On 5/8/2017 7:01 PM, Oliver Walters wrote:
> > You're not missing anything, the forum post is a complete waste of time.
> >
> > However, I'm simply wondering if an "alternative symbol without
> > duplicating component" is on the roadmap for .sweet.
>
> There will be alternative body style similar support to the demorgan.
> There will not be any artificial limit on the number of alternate body
> styles (which currently is 1).  To be honest, I'm not a big fan of
> alternate body styles.  I just make a new symbol.  It's easier and much
> cleaner than alternate body styles.
>
> >
> > On 9 May 2017 08:47, "Wayne Stambaugh"  > <mailto:stambau...@gmail.com>> wrote:
> >
> > On 5/8/2017 6:22 PM, Oliver Walters wrote:
> > > Hi all,
> > >
> > > This is probably best addressed to Wayne, or anyone else who is
> keenly
> > > interested in the new .sweet format.
> > >
> > > Currently there is a very heated thread on the forums regarding
> > > different resistor representations (people have too much time on
> their
> > > hands)
> > > -
> > https://forum.kicad.info/t/alternate-resistor-symbol-
> kicad-evaluation-for-company-use/6310/62
> > <https://forum.kicad.info/t/alternate-resistor-symbol-
> kicad-evaluation-for-company-use/6310/62>
> >
> > I will refrain from such unnecessary discussions due to lack of time.
> > There is absolutely nothing preventing users from using what ever
> > resistor symbol they want.  I don't understand the issue.  Just
> create a
> > new resistor symbol and give it a different name than 'R'.  Whether
> you
> > put it in a new library or an existing library seems really doesn't
> > matter.  Am I missing something else here?
> >
> > >
> > > In the upcoming .sweet format is there to be any concept of
> multiple
> > > representstions for schematic symbols? The obvious example is the
> > > resistor symbol.
> > >
> > > Regards,
> > > Oliver
> > >
> > >
> > > ___
> > > 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
> > <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

[Kicad-developers] [REQUEST] Remove Wings from Windows Installer

[Oliver Walters]

I note that the Windows installer still finishes with the "You should
install Wings3D" message. Is anyone really still using this?

Perhaps the time has come to remove this message...
___
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] [REQUEST] Remove Wings from Windows Installer

[Oliver Walters]

Does Wings3D have any benefit over FreeCAD with regard to VRML support? I
certainly agree that we should perhaps suggest FreeCAD over Wings.

On Tue, May 9, 2017 at 11:16 AM, Cirilo Bernardo 
wrote:

> On Tue, May 9, 2017 at 10:13 AM, Oliver Walters
>  wrote:
> > I note that the Windows installer still finishes with the "You should
> > install Wings3D" message. Is anyone really still using this?
> >
> > Perhaps the time has come to remove this message...
> >
> > ___
> > 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
> >
>
> Personally I would like to discourage people from using Wings3D; however
> VRML
> is still supported and all the documentation refers to the Wings3D
> modeler. I would
> be happier to change the message from "You should install" to
> something else; after
> all Wings3D is not required for KiCad to work.
>
> If someone updates the documentation on 3D models then we can suggest
> FreeCAD for designers with 3d solid model requirements, Maurice's
> FreeCAD/StepUp
> tools for those who also want pretty VRML files, and Wings3D for those who
> only
> want pretty VRML files (but for some reason don't want to use StepUp).
> It would be
> good if we also had some documentation demonstrating how to create models
> in
> FreeCAD otherwise most new users will simply be overwhelmed and have
> little hope of
> doing what they want. Without such documentation I would be more
> inclined to mention
> StepUp (which Maurice has documented and supports) but not FreeCAD on its
> own.
>
> - 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

Re: [Kicad-developers] [REQUEST] Remove Wings from Windows Installer

[Oliver Walters]

Nick,

That sounds sufficient - at least we are aware of it :)

On Tue, May 9, 2017 at 3:40 PM, Nick Østergaard  wrote:

> I have decided to remove the VRML message for kicad 5.0 a long time
> ago, because we have the STEP and IGES plugin by that time.
>
> 2017-05-09 5:26 GMT+02:00 Cirilo Bernardo :
> > On Tue, May 9, 2017 at 11:19 AM, Oliver Walters
> >  wrote:
> >> Does Wings3D have any benefit over FreeCAD with regard to VRML support?
> I
> >> certainly agree that we should perhaps suggest FreeCAD over Wings.
> >>
> >
> > You can get better material appearances using Wings3D but it really is
> > a nuisance
> > to get right. For those who script their own models in FreeCAD it's
> > much better to
> > use StepUp and assign material appearances for VRML. However, I suspect
> some
> > people would still rather use Wings3D even though the resulting model
> has no
> > value whatsoever for mechanical use. I guess you could always set up
> > polls to see
> > what sort of responses you get from users.
> >
> > - Cirilo
> >
> >
> >> On Tue, May 9, 2017 at 11:16 AM, Cirilo Bernardo <
> cirilo.berna...@gmail.com>
> >> wrote:
> >>>
> >>> On Tue, May 9, 2017 at 10:13 AM, Oliver Walters
> >>>  wrote:
> >>> > I note that the Windows installer still finishes with the "You should
> >>> > install Wings3D" message. Is anyone really still using this?
> >>> >
> >>> > Perhaps the time has come to remove this message...
> >>> >
> >>> > ___
> >>> > 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
> >>> >
> >>>
> >>> Personally I would like to discourage people from using Wings3D;
> however
> >>> VRML
> >>> is still supported and all the documentation refers to the Wings3D
> >>> modeler. I would
> >>> be happier to change the message from "You should install" to
> >>> something else; after
> >>> all Wings3D is not required for KiCad to work.
> >>>
> >>> If someone updates the documentation on 3D models then we can suggest
> >>> FreeCAD for designers with 3d solid model requirements, Maurice's
> >>> FreeCAD/StepUp
> >>> tools for those who also want pretty VRML files, and Wings3D for those
> who
> >>> only
> >>> want pretty VRML files (but for some reason don't want to use StepUp).
> >>> It would be
> >>> good if we also had some documentation demonstrating how to create
> models
> >>> in
> >>> FreeCAD otherwise most new users will simply be overwhelmed and have
> >>> little hope of
> >>> doing what they want. Without such documentation I would be more
> >>> inclined to mention
> >>> StepUp (which Maurice has documented and supports) but not FreeCAD on
> its
> >>> own.
> >>>
> >>> - 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] [FEATURE] Partial selection in pcbnew

[Oliver Walters]

Two more patches for this set (attached)

0017 - Slight fix for arc segment hit test (line width was not accounted
for)
0018 - SELECTION_AREA color now indicates selection mode as discussed above:

a) Normal selection = BLUE
b) Addition selection = GREEN (Shift modifier)
c) Subtraction selection = RED (Control modifier)

Additionally the line color indicates whether it is window selection (left
to right) or crossing selection (right to left). This is in lieu of making
the line dashed which does not seem to be possible unless that is added to
GAL_CAIRO and GAL_OPENGL.

Regards,
Oliver

On Tue, May 9, 2017 at 3:22 PM, Andrey Kuznetsov 
wrote:

> What's CTRL taken by?
> I thought CTRL would be used to toggle grid snapping?
>
> On Mon, May 8, 2017 at 3:39 PM, José Ignacio 
> wrote:
>
>> Or switching between object and grid snap :)
>>
>> On Mon, May 8, 2017 at 5:34 PM, Wayne Stambaugh 
>> wrote:
>>
>>> I tend to lean toward Oliver's approach.  Most CAD tools I've used have
>>> this type of includes vs intersects selection paradigm.  I don't see the
>>> need to tie up the modifier key if we don't have to.  I would prefer
>>> that we keep a modifier key open for something like orthogonal move.
>>>
>>> On 5/8/2017 5:51 PM, Oliver Walters wrote:
>>> > I was approaching this from having used mechanical CAD tools where the
>>> > direction of selection is the standard approach. Whatever function is
>>> > chosen, it will still be required that the users adjust to the new
>>> > style, manuals updated, etc.
>>> >
>>> > Is assigning what is essentially the last remaining modifier key worth
>>> > it for this?
>>> >
>>> > On 8 May 2017 23:55, "Nick Østergaard" >> > <mailto:oe.n...@gmail.com>> wrote:
>>> >
>>> > 2017-05-08 14:59 GMT+02:00 Maciej Sumiński <
>>> maciej.sumin...@cern.ch
>>> > <mailto:maciej.sumin...@cern.ch>>:
>>> > > Hi Oliver,
>>> > >
>>> > > I took your set of patches for a test drive. I am glad that you
>>> > thought
>>> > > about the subtractive mode in the selection tool, it really fits
>>> > there.
>>> > > Regarding different selection modes - I like the idea, but I
>>> think the
>>> > > two modes should be more distinct, changing the selection
>>> direction
>>> > > might be not enough.
>>> > >
>>> >
>>> > I personally prefer modifier keys as we are used to in Gimp and
>>> > Inkscape.
>>> >
>>> > > I observed another user trying out the tool and he could not
>>> tell how
>>> > > does it work, but noticed it is a bit different than the old
>>> tool.
>>> > >
>>> > > Perhaps one of the following would work:
>>> > >
>>> > > - change the selection box colors so they are easier to tell
>>> apart (my
>>> > > mate was surprised to find out there were two colors for the
>>> > selection box)
>>> > >
>>> > > - change the mode using a key modifier (I think only Alt is left
>>> free)
>>> > > or mouse button
>>> > >
>>> > > - add an option to select the default mode (though I do not
>>> really
>>> > like
>>> > > having too many options to set)
>>> > >
>>> > > I agree with Tom about the geometry library. IIRC currently it
>>> is only
>>> > > used by the PNS router, but ultimately we would like to use it
>>> in the
>>> > > primary model. The library already provides methods to check for
>>> > > collisions between basic shapes, yet we still need a few more.
>>> > > It would be a pity to drop your code now, so perhaps we could
>>> > merge the
>>> > > code as is and fix the methods during the model refactor.
>>> > >
>>> > > Just to let you know, there are a few code formatting violations
>>> > (mostly
>>> > > not keeping two empty lines between method definitions in .cpp
>>> files),
>>> > > but as they are infrequent - I can handle them myself.
>>> > >
>>> > > Regards,
>>> > > Orson
>>

[Kicad-developers] [PATCH] BRIGHT_BOX line width is zoom independent

[Oliver Walters]

During my work on the Partial Selection feature (
https://lists.launchpad.net/kicad-developers/msg29329.html) I noticed the
BRIGHT_BOX tool (used in selection clarification) for the first time.

I also noticed that the line width for the BRIGHT_BOX changed with zoom
level, which seems like the incorrect behaviour to me (it's not an actual
item on the board and the width becomes very large at high zoom levels).

Attached is a simple patch that allows line widths to be specified as
zoom-independent (for Cairo and OpenGL GAL).

BRIGHT_BOX line is now 2 pixels wide no matter the zoom.

Cheers,
Oliver
From 08211aef3d619034f62bf096ed65375259051816 Mon Sep 17 00:00:00 2001
From: Oliver Walters 
Date: Tue, 9 May 2017 22:29:20 +1000
Subject: [PATCH] Zoom-independent stroke width for CAIRO_GAL

- SetLineWidth now has extra parameter aIgnoreZoom
- Default value is false (thus does not change existing code)
- Brightbox line width is fixed independent of zoom
---
 common/gal/cairo/cairo_gal.cpp   |  7 ++-
 common/preview_items/bright_box.cpp  |  2 +-
 include/gal/cairo/cairo_gal.h|  2 +-
 include/gal/graphics_abstraction_layer.h |  7 ++-
 pcbnew/tools/pcb_bright_box.cpp  | 35 +---
 5 files changed, 37 insertions(+), 16 deletions(-)

diff --git a/common/gal/cairo/cairo_gal.cpp b/common/gal/cairo/cairo_gal.cpp
index 1324811..f77e69d 100644
--- a/common/gal/cairo/cairo_gal.cpp
+++ b/common/gal/cairo/cairo_gal.cpp
@@ -456,10 +456,15 @@ void CAIRO_GAL::SetFillColor( const COLOR4D& aColor )
 }
 
 
-void CAIRO_GAL::SetLineWidth( double aLineWidth )
+void CAIRO_GAL::SetLineWidth( double aLineWidth, bool aIgnoresScale )
 {
 storePath();
 
+if( aIgnoresScale )
+{
+aLineWidth /= GetWorldScale();
+}
+
 lineWidth = aLineWidth;
 
 if( isGrouping )
diff --git a/common/preview_items/bright_box.cpp b/common/preview_items/bright_box.cpp
index cc55dfa..4bfb453 100644
--- a/common/preview_items/bright_box.cpp
+++ b/common/preview_items/bright_box.cpp
@@ -29,7 +29,7 @@
 using namespace KIGFX;
 
 const double BRIGHT_BOX::LINE_WIDTH = 1.0;
-const COLOR4D BRIGHT_BOX::BOX_COLOR = KIGFX::COLOR4D( 0.0, 1.0, 0.0, 1.0 );
+const COLOR4D BRIGHT_BOX::BOX_COLOR = KIGFX::COLOR4D( 0.0, 1.0, 0.0, 0.9 );
 
 BRIGHT_BOX::BRIGHT_BOX() :
 EDA_ITEM( NOT_USED ),// this item is never added to a BOARD so it needs no type
diff --git a/include/gal/cairo/cairo_gal.h b/include/gal/cairo/cairo_gal.h
index f86b5bf..2089ffc 100644
--- a/include/gal/cairo/cairo_gal.h
+++ b/include/gal/cairo/cairo_gal.h
@@ -169,7 +169,7 @@ public:
 virtual void SetFillColor( const COLOR4D& aColor ) override;
 
 /// @copydoc GAL::SetLineWidth()
-virtual void SetLineWidth( double aLineWidth ) override;
+virtual void SetLineWidth( double aLineWidth, bool aIgnoresScale = false ) override;
 
 /// @copydoc GAL::SetLayerDepth()
 virtual void SetLayerDepth( double aLayerDepth ) override;
diff --git a/include/gal/graphics_abstraction_layer.h b/include/gal/graphics_abstraction_layer.h
index 00e5bc9..a052ef2 100644
--- a/include/gal/graphics_abstraction_layer.h
+++ b/include/gal/graphics_abstraction_layer.h
@@ -262,8 +262,13 @@ public:
  *
  * @param aLineWidth is the line width.
  */
-virtual void SetLineWidth( double aLineWidth )
+virtual void SetLineWidth( double aLineWidth, bool aIgnoresScale = false )
 {
+if( aIgnoresScale )
+{
+aLineWidth /= GetWorldScale();
+}
+
 lineWidth = aLineWidth;
 }
 
diff --git a/pcbnew/tools/pcb_bright_box.cpp b/pcbnew/tools/pcb_bright_box.cpp
index aee6462..53dfd66 100644
--- a/pcbnew/tools/pcb_bright_box.cpp
+++ b/pcbnew/tools/pcb_bright_box.cpp
@@ -27,7 +27,7 @@
 
 using namespace KIGFX;
 
-const double PCB_BRIGHT_BOX::PCB_LINE_WIDTH = 10.0;
+const double PCB_BRIGHT_BOX::PCB_LINE_WIDTH = 2.0;
 
 
 PCB_BRIGHT_BOX::PCB_BRIGHT_BOX() :
@@ -42,21 +42,32 @@ void PCB_BRIGHT_BOX::ViewDraw( int aLayer, KIGFX::VIEW* aView ) const
 if( !m_item )
 return;
 
-if( m_item->Type() == PCB_TRACE_T )
+auto gal = aView->GetGAL();
+
+gal->SetIsStroke( true );
+gal->SetIsFill( false );
+gal->SetLineWidth( m_lineWidth, true );
+gal->SetStrokeColor( m_color );
+
+switch( m_item->Type() )
 {
-const TRACK* track = static_cast( m_item );
+default:
+// Default implementation draws item bounding box
+{
+BOX2I box = m_item->ViewBBox();
 
-auto gal = aView->GetGAL();
+gal->DrawRectangle( box.GetOrigin(), box.GetEnd() );
+}
+break;
 
-gal->SetIsStroke( true );
-gal->SetIsFill( false );
-gal->SetLineWidth( m_lineWidth );
-gal->SetStrokeColor( m_color );
+// PCB Segment
+case PCB_TRACE_T:
+{
+const TRACK* track = static_cast( m_item );
 
 gal->DrawSe

Re: [Kicad-developers] [QUESTION] Multiple symbols in .sweet format

[Oliver Walters]

Sorry I pushed this button ;)

I totally agree with all of this, I can't believe they've spent over a week
on this issue.

On 10 May 2017 04:34, "Wayne Stambaugh"  wrote:

> On 5/9/2017 1:14 PM, Andy Peters wrote:
> >
> >> On May 8, 2017, at 3:47 PM, Wayne Stambaugh 
> wrote:
> >>
> >> On 5/8/2017 6:22 PM, Oliver Walters wrote:
> >>> Hi all,
> >>>
> >>> This is probably best addressed to Wayne, or anyone else who is keenly
> >>> interested in the new .sweet format.
> >>>
> >>> Currently there is a very heated thread on the forums regarding
> >>> different resistor representations (people have too much time on their
> >>> hands)
> >>> - https://forum.kicad.info/t/alternate-resistor-symbol-
> kicad-evaluation-for-company-use/6310/62
> >>
> >> I will refrain from such unnecessary discussions due to lack of time.
> >> There is absolutely nothing preventing users from using what ever
> >> resistor symbol they want.  I don't understand the issue.  Just create a
> >> new resistor symbol and give it a different name than 'R'.  Whether you
> >> put it in a new library or an existing library seems really doesn't
> >> matter.  Am I missing something else here?
> >
> > The bitching is all about what the standard libraries should provide,
> and underlying it is the notion that the standard libraries should contain
> every symbol every user could possibly want, because nobody should have to
> make their own libraries.
> >
> > And, of course by saying “Just create a new resistor symbol,” you’ll get
> a bunch of angry users saying, “SEE! The developers don’t listen to us!”
>
> This comes up every so often and it never ceases to amaze me what people
> expect the KiCad project to do for free.  It really does nothing to make
> me (and I'm guessing other developers as well) want to help them.  It's
> a good thing none of these folks work for me because there employment
> would be short lived.  Even complex symbols don't take that long to
> create so they spent more time typing their arguments on a forum than it
> would have taken to just create the symbol.  Where is the sense in that?
>
> >
> > (I hope everyone can read through the facetiousness here.)
> >
> > Party on, Wayne
> >
> > -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] [FEATURE] Partial selection in pcbnew

[Oliver Walters]

Looks like JP has already fixed this :)

On Wed, May 10, 2017 at 10:56 PM, Wayne Stambaugh 
wrote:

> Windows builds on mingw using gcc 6.3.0 are broken.  Here is the
> compiler error:
>
> C:/msys64/home/wstambaugh/src/kicad-trunk/common/base_struct.cpp: In
> member function 'bool EDA_RECT::IntersectsCircleEdge(const wxPoint&,
> int, int) const':
> C:/msys64/home/wstambaugh/src/kicad-trunk/common/base_struct.cpp:592:17:
> error: expected unqualified-id before '=' token
>  wxPoint far = FarthestPointTo( aCenter );
>  ^
> C:/msys64/home/wstambaugh/src/kicad-trunk/common/base_struct.cpp:594:18:
> error: expected primary-expression before 'double'
>  double fx = (double) far.x;
>   ^~
> C:/msys64/home/wstambaugh/src/kicad-trunk/common/base_struct.cpp:594:18:
> error: expected ')' before 'double'
> C:/msys64/home/wstambaugh/src/kicad-trunk/common/base_struct.cpp:595:18:
> error: expected primary-expression before 'double'
>  double fy = (double) far.y;
>   ^~
> C:/msys64/home/wstambaugh/src/kicad-trunk/common/base_struct.cpp:595:18:
> error: expected ')' before 'double'
> make[2]: *** [common/CMakeFiles/common.dir/build.make:1200:
> common/CMakeFiles/common.dir/base_struct.cpp.obj] Error 1
> make[1]: *** [CMakeFiles/Makefile2:326:
> common/CMakeFiles/common.dir/all] Error 2
>
>
> On 5/10/2017 5:41 AM, Maciej Sumiński wrote:
> > Hi Oliver,
> >
> > Thank you very much for your effort, I have just pushed your patches to
> > the master branch.
> >
> > Regards,
> > Orson
> >
> > On 05/09/2017 09:32 AM, Oliver Walters wrote:
> >> Two more patches for this set (attached)
> >>
> >> 0017 - Slight fix for arc segment hit test (line width was not accounted
> >> for)
> >> 0018 - SELECTION_AREA color now indicates selection mode as discussed
> above:
> >>
> >> a) Normal selection = BLUE
> >> b) Addition selection = GREEN (Shift modifier)
> >> c) Subtraction selection = RED (Control modifier)
> >>
> >> Additionally the line color indicates whether it is window selection
> (left
> >> to right) or crossing selection (right to left). This is in lieu of
> making
> >> the line dashed which does not seem to be possible unless that is added
> to
> >> GAL_CAIRO and GAL_OPENGL.
> >>
> >> Regards,
> >> Oliver
> >>
> >> On Tue, May 9, 2017 at 3:22 PM, Andrey Kuznetsov 
> >> wrote:
> >>
> >>> What's CTRL taken by?
> >>> I thought CTRL would be used to toggle grid snapping?
> >>>
> >>> On Mon, May 8, 2017 at 3:39 PM, José Ignacio 
> >>> wrote:
> >>>
> >>>> Or switching between object and grid snap :)
> >>>>
> >>>> On Mon, May 8, 2017 at 5:34 PM, Wayne Stambaugh  >
> >>>> wrote:
> >>>>
> >>>>> I tend to lean toward Oliver's approach.  Most CAD tools I've used
> have
> >>>>> this type of includes vs intersects selection paradigm.  I don't see
> the
> >>>>> need to tie up the modifier key if we don't have to.  I would prefer
> >>>>> that we keep a modifier key open for something like orthogonal move.
> >>>>>
> >>>>> On 5/8/2017 5:51 PM, Oliver Walters wrote:
> >>>>>> I was approaching this from having used mechanical CAD tools where
> the
> >>>>>> direction of selection is the standard approach. Whatever function
> is
> >>>>>> chosen, it will still be required that the users adjust to the new
> >>>>>> style, manuals updated, etc.
> >>>>>>
> >>>>>> Is assigning what is essentially the last remaining modifier key
> worth
> >>>>>> it for this?
> >>>>>>
> >>>>>> On 8 May 2017 23:55, "Nick Østergaard"  >>>>>> <mailto:oe.n...@gmail.com>> wrote:
> >>>>>>
> >>>>>> 2017-05-08 14:59 GMT+02:00 Maciej Sumiński <
> >>>>> maciej.sumin...@cern.ch
> >>>>>> <mailto:maciej.sumin...@cern.ch>>:
> >>>>>> > Hi Oliver,
> >>>>>> >
> >>>>>> > I took your set of patches for a test drive. I am glad that
> you
> >>>>>> thought
> >>>>>> 

Re: [Kicad-developers] [FEATURE] Partial selection in pcbnew

[Oliver Walters]

JP,

I think that the code "wxPoint near" should also be changed to "wxPoint
nearpt" ('near' also seems to be a somewhat-reserved keyword)

On Wed, May 10, 2017 at 11:23 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Looks like JP has already fixed this :)
>
> On Wed, May 10, 2017 at 10:56 PM, Wayne Stambaugh 
> wrote:
>
>> Windows builds on mingw using gcc 6.3.0 are broken.  Here is the
>> compiler error:
>>
>> C:/msys64/home/wstambaugh/src/kicad-trunk/common/base_struct.cpp: In
>> member function 'bool EDA_RECT::IntersectsCircleEdge(const wxPoint&,
>> int, int) const':
>> C:/msys64/home/wstambaugh/src/kicad-trunk/common/base_struct.cpp:592:17:
>> error: expected unqualified-id before '=' token
>>  wxPoint far = FarthestPointTo( aCenter );
>>  ^
>> C:/msys64/home/wstambaugh/src/kicad-trunk/common/base_struct.cpp:594:18:
>> error: expected primary-expression before 'double'
>>  double fx = (double) far.x;
>>   ^~
>> C:/msys64/home/wstambaugh/src/kicad-trunk/common/base_struct.cpp:594:18:
>> error: expected ')' before 'double'
>> C:/msys64/home/wstambaugh/src/kicad-trunk/common/base_struct.cpp:595:18:
>> error: expected primary-expression before 'double'
>>  double fy = (double) far.y;
>>   ^~
>> C:/msys64/home/wstambaugh/src/kicad-trunk/common/base_struct.cpp:595:18:
>> error: expected ')' before 'double'
>> make[2]: *** [common/CMakeFiles/common.dir/build.make:1200:
>> common/CMakeFiles/common.dir/base_struct.cpp.obj] Error 1
>> make[1]: *** [CMakeFiles/Makefile2:326:
>> common/CMakeFiles/common.dir/all] Error 2
>>
>>
>> On 5/10/2017 5:41 AM, Maciej Sumiński wrote:
>> > Hi Oliver,
>> >
>> > Thank you very much for your effort, I have just pushed your patches to
>> > the master branch.
>> >
>> > Regards,
>> > Orson
>> >
>> > On 05/09/2017 09:32 AM, Oliver Walters wrote:
>> >> Two more patches for this set (attached)
>> >>
>> >> 0017 - Slight fix for arc segment hit test (line width was not
>> accounted
>> >> for)
>> >> 0018 - SELECTION_AREA color now indicates selection mode as discussed
>> above:
>> >>
>> >> a) Normal selection = BLUE
>> >> b) Addition selection = GREEN (Shift modifier)
>> >> c) Subtraction selection = RED (Control modifier)
>> >>
>> >> Additionally the line color indicates whether it is window selection
>> (left
>> >> to right) or crossing selection (right to left). This is in lieu of
>> making
>> >> the line dashed which does not seem to be possible unless that is
>> added to
>> >> GAL_CAIRO and GAL_OPENGL.
>> >>
>> >> Regards,
>> >> Oliver
>> >>
>> >> On Tue, May 9, 2017 at 3:22 PM, Andrey Kuznetsov 
>> >> wrote:
>> >>
>> >>> What's CTRL taken by?
>> >>> I thought CTRL would be used to toggle grid snapping?
>> >>>
>> >>> On Mon, May 8, 2017 at 3:39 PM, José Ignacio 
>> >>> wrote:
>> >>>
>> >>>> Or switching between object and grid snap :)
>> >>>>
>> >>>> On Mon, May 8, 2017 at 5:34 PM, Wayne Stambaugh <
>> stambau...@gmail.com>
>> >>>> wrote:
>> >>>>
>> >>>>> I tend to lean toward Oliver's approach.  Most CAD tools I've used
>> have
>> >>>>> this type of includes vs intersects selection paradigm.  I don't
>> see the
>> >>>>> need to tie up the modifier key if we don't have to.  I would prefer
>> >>>>> that we keep a modifier key open for something like orthogonal move.
>> >>>>>
>> >>>>> On 5/8/2017 5:51 PM, Oliver Walters wrote:
>> >>>>>> I was approaching this from having used mechanical CAD tools where
>> the
>> >>>>>> direction of selection is the standard approach. Whatever function
>> is
>> >>>>>> chosen, it will still be required that the users adjust to the new
>> >>>>>> style, manuals updated, etc.
>> >>>>>>
>> >>>>>> Is assigning what is essentially the last remaining modifier key
>> worth
>> >>>>>> it f

Re: [Kicad-developers] [FEATURE] Partial selection in pcbnew

[Oliver Walters]

JP,

Sorry, the code for ::ClosestPointTo "used to" have a variable called near.
I had since removed it. Never mind :)

On Wed, May 10, 2017 at 11:47 PM, jp charras  wrote:

> Le 10/05/2017 à 15:29, Oliver Walters a écrit :
> > JP,
> >
> > I think that the code "wxPoint near" should also be changed to "wxPoint
> nearpt" ('near' also seems
> > to be a somewhat-reserved keyword)
> >
>
> Sure, "far" and "near" must be avoided on Windows, they look like they are
> still reserved keyword.
>
> However, I do not find any occurrence of "wxPoint near" in Kicad code.
>
> Do you know where "wxPoint near" is used?
>
> --
> 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] [FEATURE] Partial selection in pcbnew

[Oliver Walters]

Looks like module text fields should be culled from the selection in
::SanitizeSelection if the parent module is also selected.

On 11 May 2017 04:15, "Joakim Asplund"  wrote:

> On Sat, May 6, 2017 at 9:21 AM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>>
>> a) PCBNEW
>>
>> Selecting part of a MODULE (right to left) will select both the entire
>> module and also any parts of the module that you touched (lines, pads,
>> etc). Then, when you move the module, the doubly-selected items are moved
>> twice! It is hard to describe properly but if you try this you will see
>> what I mean.
>>
>>
> Hi!
>
> I've noticed that this behavior can also be triggered by first selecting a
> component text field (such as the reference) and then while holding SHIFT
> either clicking the component it belongs to or using the selection
> rectangle. It seems to have been this way since a long time back, and is
> still like this in the master branch as of today, May 10.
>
> Doubly-selected text fields will move twice as far when the selected items
> are moved.
>
> Best regards,
> Joakim
>
___
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] Component table improvements

[Oliver Walters]

This feature was IN this branch of code but was vetoed. It was WYSIWYG BoM
with export to:

*SV
XML
HTML

Wayne mentioned that KiCad used to have such a BOM export tool but I
haven't been using KiCad long enough to have experienced it.

If there is real need for such a feature then I leave that to the project
leads to decide. I have the code still, and it could be implemented very
easily.

Cheers,
Oliver

On 12 May 2017 21:22, "Nick Østergaard"  wrote:

> Did you ever try  pcbnew > file > export > BOM?
>
> Den 12/05/2017 13.17 skrev "Kristoffer Ödmark" <
> kristofferodmar...@gmail.com>:
>
>> Doesnt really matter what delimiter is used.
>>
>> It would just feel better if kicad had a default BOM-generation built in.
>> Then I dont mind if someone prefers the alternative scritpting way to go
>> because they can generate html or pdf or pictures or whatever. A simple
>> delimiter based exporter as minimum would be nice. Bascially how it was
>> earlier, I think the plugin system made it less accesible and therefore a
>> regression.
>>
>> It became more "programmer oriented" then user oriented.
>>
>> - Kristoffer
>>
>>
>> On 05/12/2017 11:53 AM, Marco Ciampa wrote:
>>
>>> On Fri, May 12, 2017 at 10:25:49AM +0200, Kristoffer Ödmark wrote:
>>>
 Just to generate a .csv or a rahter a .tsv as the default.

>>>
>>> May I suggest a .?sv
>>>
>>> where the ? character is a "user defined character" that defaults to ...
>>> comma (or tab or what you want) Separated Values list?
>>>
>>> TIA
>>>
>>> --
>>>
>>>
>>> Marco Ciampa
>>>
>>> I know a joke about UDP, but you might not get it.
>>>
>>> 
>>>
>>>   GNU/Linux User #78271
>>>   FSFE fellow #364
>>>
>>> 
>>>
>>>
>>> ___
>>> 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] [FEATURE] Component table viewer

[Oliver Walters]

Thanks for the positive feedback everyone.

I have a couple of further improvements planned (but not much time atm).

A) left alignment of text (I agree)

B) ability to open footprint selector (perhaps using right-click context
menu). If someone with better knowledge of Kiway wants to do this one,
great.

C) Data filtering - ability to filter per row

D) context menu to quickly hide column, etc

Oliver


On 12 May 2017 20:50, "Clemens Koller"  wrote:

I am impressed!

This seems to be the first step towards what is called "Table Based Design
Entry" in some other tools.
The next step towards that would be to allow editing of pins and netnames
of the components (which are arranged in a hierarchical tree view).
And - the tricky part - update the visual representation of the connections
in the schematics (updating netnames of existing connections and by adding
netnames/labels to pins for new connections).

Thank you for your great work!

Clemens

On 2017-05-12 10:23, Steven Johnson wrote:
> To answer 3. Its a component field editor/viewer.  It allows you to
edit/view your component fields much easier than right clicking on each and
every symbol to see what the fields are set to.
>
> Its not really a BoM tool although it makes getting your BoM in order
much easier.
>
> For example a 10K resistor doesnt necessarily specify the
manufacturer/part number like a BoM would need to, although it can.  How
you use the fields is up to you the designer.
>
>
> On May 12, 2017 15:16, "Fabrizio Tappero" mailto:fabrizio.tapp...@gmail.com>> wrote:
>
> Hello,
> great work! this is a good BOM preview, but I am not really sure why
the BOM icon does not activate this table (like in Altium).
> I have done some testing and this is my feedback.
> 1) left alignment is advisable.  The current center alignment makes
the table hard to read.
> 2) for a reason I do not know, the current version (today nightly
built) has problem to group the "Description" field. Very strange
> 3) What exactly is this table? a "Generate quick BOM"? The current
pop up hint text says "Component table view" which I guess is incorrect
since you can edit fields. This would help me to make a better icon?
>
> Inline image 1
>
> Really great work. I love this new feature.
>
> cheers
> Fabrizio
>
>
>     On Sat, May 6, 2017 at 7:28 AM, Strontium mailto:strnty...@gmail.com>> wrote:
>
> Hi Oliver,
>
> On 06/05/17 12:13, Oliver Walters wrote:
>>
>> And it just so happens that in this schematic NO components
have been edited to include these default fields/values, so, they don't
show up in the component table.
>>
>>
>> I have a patch to fix this now - if a field is empty and a
template value exists, that is placed there instead.
>>
>>
>> Also, editing Multipart components is a little quirky, If
you change a field for a multi-part component, all "parts" update to that
value, but if any parts have different values, only one is shown in the
table and its not clear that the underlying multipart field is inconsistent.
>>
>>
>> This is a hard one as really, multi-part components should /not/
have different values in various fields! I had thought about adding another
level (with an arrow as you suggest) but I think it becomes too complicated.
> Yes, I agree with you on this, Its confusing that KiCad doesn't
synchronise those fields.  BUT I think maybe its done that way to help
facilitate swapping parts between multiple multi-part components.
>
> Maybe a developer who knows more about this can weigh in?  Is
having different field value/fields in a single multi-part component a
"Feature" or a "Quirk"?  And if a "Feature" what's its purpose?
>
> Steven
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers <
https://launchpad.net/~kicad-developers>
> Post to : 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] Component table improvements

[Oliver Walters]

JP,

This seems very sensible :)

Oliver

On 13 May 2017 04:18, "jp charras"  wrote:

> Le 12/05/2017 à 13:55, Oliver Walters a écrit :
> > This feature was IN this branch of code but was vetoed. It was WYSIWYG
> BoM with export to:
> >
> > *SV
> > XML
> > HTML
> >
> > Wayne mentioned that KiCad used to have such a BOM export tool but I
> haven't been using KiCad long
> > enough to have experienced it.
> >
> > If there is real need for such a feature then I leave that to the
> project leads to decide. I have
> > the code still, and it could be implemented very easily.
>
> Hi Oliver,
>
> As Wayne said, we don't like a BOM export tool *written in C++ inside* the
> Kicad code.
>
> Here is the reason:
> A few years ago, this code was existing and (as Wayne said) created the
> same BOM files (txt, csv...)
> as your code.
>
> What was the result:
> Roughly ever month, a bug or request was filled to change something in BOM
> files.
> I am guessing we cannot find 2 guys who want the same BOM format or option.
>
> Therefore, the C++ code inside the Kicad code was dropped, and replaced by
> external scripts (Python
> or XSL) to transform the XML netlist created by Kicad to an other list
> (BOM, but also other netlist
> formats).
>
> *Trust me*, this was a *wise* decision (It was not my decision, but was a
> good decision).
>
> Therefore: if you want to create the BOM you like, write a Python script
> to do that from a netlist
> (it is easy to run from Eeschema: see the BOM or Netlist generator), but
> do not try to merge this
> code in Kicad C++ sources: your script will never generate the "right" BOM.
> But a Python script is very easy to modify.
>
> There are already many BOM generators written in Python.
>
>
> --
> 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

[Kicad-developers] [PATCH] Component table text alignment

[Oliver Walters]

Simple patch that left-aligns text in component table viewer


0001-Component-table-is-left-aligned.patch
Description: Binary data
___
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] Bugfix for component table

[Oliver Walters]

Bug noted here - https://lists.launchpad.net/kicad-developers/msg29485.html

Patch attached to this email fixes glitch when user adds custom field with
same name as a default field.

Users can now do this to their heart's content.
From 43106de69511427cf841700be10da2d42ce8b6dd Mon Sep 17 00:00:00 2001
From: Oliver Walters 
Date: Tue, 23 May 2017 00:05:36 +1000
Subject: [PATCH] Fixed duplicate field names

- Now works correctly even if users overload default field names
---
 eeschema/bom_table_model.cpp | 32 ++--
 eeschema/sch_component.cpp   | 31 +--
 eeschema/sch_component.h |  4 ++--
 3 files changed, 49 insertions(+), 18 deletions(-)

diff --git a/eeschema/bom_table_model.cpp b/eeschema/bom_table_model.cpp
index 550b561..e2150d4 100644
--- a/eeschema/bom_table_model.cpp
+++ b/eeschema/bom_table_model.cpp
@@ -569,7 +569,7 @@ bool BOM_TABLE_COMPONENT::AddUnit( SCH_REFERENCE aUnit )
 
 // User fields
 default:
-value = cmp->GetFieldText( column->Title() );
+value = cmp->GetFieldText( column->Title(), false );
 break;
 }
 
@@ -705,7 +705,8 @@ void BOM_TABLE_COMPONENT::ApplyFieldChanges()
 field = cmp->GetField( DATASHEET );
 break;
 default:
-field = cmp->FindField( column->Title() );
+// Find the field by name (but ignore default fields)
+field = cmp->FindField( column->Title(), false );
 break;
 }
 
@@ -985,12 +986,31 @@ void BOM_TABLE_MODEL::AddComponentFields( SCH_COMPONENT* aCmp )
 
 fieldName = field->GetName();
 
-auto existing = ColumnList.GetColumnByTitle( fieldName );
+bool userMatchFound = false;
 
-// As columns are sorted by ID, we can allow user to
-// create a column with a "special" name
-if( existing && existing->Id() >= MANDATORY_FIELDS)
+// Search for the column within the existing columns
+for( auto col : ColumnList.Columns )
+{
+if( !col )
+{
+continue;
+}
+
+if( col->Title().Cmp( fieldName ) == 0 )
+{
+if( col->Id() >= BOM_COL_ID_USER )
+{
+userMatchFound = true;
+break;
+}
+}
+}
+
+// If a user-made column already exists with the same name, abort
+if( userMatchFound )
+{
 continue;
+}
 
 ColumnList.AddColumn( new BOM_COLUMN( ColumnList.NextFieldId(),
   BOM_COL_TYPE_USER,
diff --git a/eeschema/sch_component.cpp b/eeschema/sch_component.cpp
index 8c9f64b..edf8e46 100644
--- a/eeschema/sch_component.cpp
+++ b/eeschema/sch_component.cpp
@@ -769,20 +769,23 @@ SCH_FIELD* SCH_COMPONENT::GetField( int aFieldNdx ) const
 return (SCH_FIELD*) field;
 }
 
-wxString SCH_COMPONENT::GetFieldText( wxString aFieldName ) const
+wxString SCH_COMPONENT::GetFieldText( wxString aFieldName, bool aIncludeDefaultFields ) const
 {
-
 // Field name for comparison
 wxString cmpFieldName;
 
-// Default field names
-for ( unsigned int i=0; i___
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] Bugfix for component table

[Oliver Walters]

Cirilo,

I think the major issue here is that I introduced a previously
invisible-to-the-user field called "Description" which is lifted from the
.dcm file. Fabrizio had a custom field called "Description" as he did not
know that this other field existed.

Just as people would not have a custom field called "Footprint", I think
that once people realize that the "Description" field is inherent to the
symbol itself, they will rename such custom fields to something else.



Also, I note that there seems to be a duplication of fields already -
there's a "Datasheet" field and a "Documentation" field, one lives in the
.dcm file and one in the .lib file. This seems to be much more of a source
of confusion to me.

On Wed, May 24, 2017 at 8:20 AM, Cirilo Bernardo 
wrote:

> On Tue, May 23, 2017 at 1:10 PM, Wayne Stambaugh 
> wrote:
> > On 5/23/2017 4:17 AM, Fabrizio Tappero wrote:
> >> cheers Oliver,
> >> I do not know what a .dcm file is.
> >>
> >> I am not sure it is a good idea to have a in-built field called
> >> Description in the table viewer. But I can easily see how that is
> >> useful. I guess you would like to use this table to add info. This makes
> >> it non a table viewer. The current icon label says "Component table
> >> view" which I find ambiguous. Maybe Wayne can jump in with a proper name
> >> for it.
> >
> > The component information strings are not fields.  They are part of the
> > component definition and are not user definable.  There are four
> > component information definitions: name, description, key words (tags),
> > and documentation file name.  You could create fields with the same
> > names so I can understand how this could be confusing.
> >
> > Toolbar button tooltips should be a verb followed by a short
> > description.  In this case "Edit component properties" would work.
> >
>
> Perhaps the software should (re)assign the names of the first 4 fields and
> use a 2-part name to distinguish them from anything else? Maybe a special
> character at the front of the name would be enough - let's say '@'.  That
> shouldn't look too ugly and it's unlikely someone would begin a field name
> with '@' (or some other suitable character). At any rate, if the user can
> give an arbitrary field > 4 a name which happens to match a name of one
> of the first 4 fields, we need some scheme so that users (and machines!)
> can distinguish the special fields.
>
> - Cirilo
>
> >>
> >> I am having the feeling the development of this table did not come from
> >> a clean plan of having an XYZ tool. Or maybe is just me. Please dont get
> >> me wrong, I love this table (and the soon to come new icon) but it might
> >> be a good idea to drop the word viewer for it if we want the (great)
> >> ability to edit stuff.
> >>
> >> I hope this helps.
> >>
> >> Fabrizio
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Tue, May 23, 2017 at 10:00 AM, Oliver Walters
> >> mailto:oliver.henry.walt...@gmail.com
> >>
> >> wrote:
> >>
> >> Fabrizio,
> >>
> >> 1. You have added a custom field called "Description".
> >> 2. The table viewer has an "inbuild" field called "Description". It
> >> populates this field with the component description which is found
> >> in the .dcm files
> >>
> >> Here's what I see.
> >>
> >> Inline image 1
> >>
> >> Here I have added the custom "description" field with dummy data to
> >> only one component.
> >>
> >> The first "Description" column is filled with the symbol
> >> descriptions from the .dcm files in the library.
> >>
> >> If you are missing the .dcm files then your first column will be
> empty.
> >>
> >>
> >> On Tue, May 23, 2017 at 5:57 PM, Fabrizio Tappero
> >> mailto:fabrizio.tapp...@gmail.com>>
> wrote:
> >>
> >> Hi Oliver,
> >> not sure I understand the question. This is what my schematic
> >> components fields look like:
> >>
> >> Inline image 1
> >>
> >>
> >> cheers
> >> Fabrizio
> >>
> >>
> >> On Tue, May 23, 2017 at 9:53 AM, Andrey Kuznetsov
> >> mailto:ka

Re: [Kicad-developers] [PATCH] Bugfix for component table

[Oliver Walters]

I have just now tested this on Windows and can confirm this behavior. It is
very odd indeed.

Does anyone with more knowledge of wx (in particular wxDataViewCtrl) have
any experience with this behavior (only on Windows platform):

Oliver, found another unexpected behaviour.
> When I select a field to edit, for example to replace a "Part Number"
> field from AAA to BBB, when I type in BBB but instead of hitting enter, I
> click on the next field below it which belongs to another part, then BBB
> modifies that part's field instead of where the editing took place.


On Wed, May 24, 2017 at 9:14 AM, Andrey Kuznetsov 
wrote:

> Have you been able to reproduce the edit mode in field A changing data in
> field B when you click on the field B with a mouse?
>
> On Tue, May 23, 2017 at 3:51 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> Cirilo,
>>
>> I think the major issue here is that I introduced a previously
>> invisible-to-the-user field called "Description" which is lifted from the
>> .dcm file. Fabrizio had a custom field called "Description" as he did not
>> know that this other field existed.
>>
>> Just as people would not have a custom field called "Footprint", I think
>> that once people realize that the "Description" field is inherent to the
>> symbol itself, they will rename such custom fields to something else.
>>
>>
>>
>> Also, I note that there seems to be a duplication of fields already -
>> there's a "Datasheet" field and a "Documentation" field, one lives in the
>> .dcm file and one in the .lib file. This seems to be much more of a source
>> of confusion to me.
>>
>> On Wed, May 24, 2017 at 8:20 AM, Cirilo Bernardo <
>> cirilo.berna...@gmail.com> wrote:
>>
>>> On Tue, May 23, 2017 at 1:10 PM, Wayne Stambaugh 
>>> wrote:
>>> > On 5/23/2017 4:17 AM, Fabrizio Tappero wrote:
>>> >> cheers Oliver,
>>> >> I do not know what a .dcm file is.
>>> >>
>>> >> I am not sure it is a good idea to have a in-built field called
>>> >> Description in the table viewer. But I can easily see how that is
>>> >> useful. I guess you would like to use this table to add info. This
>>> makes
>>> >> it non a table viewer. The current icon label says "Component table
>>> >> view" which I find ambiguous. Maybe Wayne can jump in with a proper
>>> name
>>> >> for it.
>>> >
>>> > The component information strings are not fields.  They are part of the
>>> > component definition and are not user definable.  There are four
>>> > component information definitions: name, description, key words (tags),
>>> > and documentation file name.  You could create fields with the same
>>> > names so I can understand how this could be confusing.
>>> >
>>> > Toolbar button tooltips should be a verb followed by a short
>>> > description.  In this case "Edit component properties" would work.
>>> >
>>>
>>> Perhaps the software should (re)assign the names of the first 4 fields
>>> and
>>> use a 2-part name to distinguish them from anything else? Maybe a special
>>> character at the front of the name would be enough - let's say '@'.  That
>>> shouldn't look too ugly and it's unlikely someone would begin a field
>>> name
>>> with '@' (or some other suitable character). At any rate, if the user can
>>> give an arbitrary field > 4 a name which happens to match a name of one
>>> of the first 4 fields, we need some scheme so that users (and machines!)
>>> can distinguish the special fields.
>>>
>>> - Cirilo
>>>
>>> >>
>>> >> I am having the feeling the development of this table did not come
>>> from
>>> >> a clean plan of having an XYZ tool. Or maybe is just me. Please dont
>>> get
>>> >> me wrong, I love this table (and the soon to come new icon) but it
>>> might
>>> >> be a good idea to drop the word viewer for it if we want the (great)
>>> >> ability to edit stuff.
>>> >>
>>> >> I hope this helps.
>>> >>
>>> >> Fabrizio
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >&

Re: [Kicad-developers] [PATCH] Bugfix for component table

[Oliver Walters]

Fabrizio,

If the .dcm fields are all empty then that's a library management issue and
the developers forum is probably not the best place for discussing that :)

On 24 May 2017 17:11, "Fabrizio Tappero"  wrote:

Hi Oliver,

How would I realize that? "Description" field does not appear in the
schematic component properties window. Maximum freedom to add all fields
the user wants should, I think, be imperative. btw, all description field
content coming from .dcm is actually empty in all my schematics.

cheers
Fabrizio


On Wed, May 24, 2017 at 12:51 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Cirilo,
>
> I think the major issue here is that I introduced a previously
> invisible-to-the-user field called "Description" which is lifted from the
> .dcm file. Fabrizio had a custom field called "Description" as he did not
> know that this other field existed.
>
> Just as people would not have a custom field called "Footprint", I think
> that once people realize that the "Description" field is inherent to the
> symbol itself, they will rename such custom fields to something else.
>
>
>
> Also, I note that there seems to be a duplication of fields already -
> there's a "Datasheet" field and a "Documentation" field, one lives in the
> .dcm file and one in the .lib file. This seems to be much more of a source
> of confusion to me.
>
> On Wed, May 24, 2017 at 8:20 AM, Cirilo Bernardo <
> cirilo.berna...@gmail.com> wrote:
>
>> On Tue, May 23, 2017 at 1:10 PM, Wayne Stambaugh 
>> wrote:
>> > On 5/23/2017 4:17 AM, Fabrizio Tappero wrote:
>> >> cheers Oliver,
>> >> I do not know what a .dcm file is.
>> >>
>> >> I am not sure it is a good idea to have a in-built field called
>> >> Description in the table viewer. But I can easily see how that is
>> >> useful. I guess you would like to use this table to add info. This
>> makes
>> >> it non a table viewer. The current icon label says "Component table
>> >> view" which I find ambiguous. Maybe Wayne can jump in with a proper
>> name
>> >> for it.
>> >
>> > The component information strings are not fields.  They are part of the
>> > component definition and are not user definable.  There are four
>> > component information definitions: name, description, key words (tags),
>> > and documentation file name.  You could create fields with the same
>> > names so I can understand how this could be confusing.
>> >
>> > Toolbar button tooltips should be a verb followed by a short
>> > description.  In this case "Edit component properties" would work.
>> >
>>
>> Perhaps the software should (re)assign the names of the first 4 fields and
>> use a 2-part name to distinguish them from anything else? Maybe a special
>> character at the front of the name would be enough - let's say '@'.  That
>> shouldn't look too ugly and it's unlikely someone would begin a field name
>> with '@' (or some other suitable character). At any rate, if the user can
>> give an arbitrary field > 4 a name which happens to match a name of one
>> of the first 4 fields, we need some scheme so that users (and machines!)
>> can distinguish the special fields.
>>
>> - Cirilo
>>
>> >>
>> >> I am having the feeling the development of this table did not come from
>> >> a clean plan of having an XYZ tool. Or maybe is just me. Please dont
>> get
>> >> me wrong, I love this table (and the soon to come new icon) but it
>> might
>> >> be a good idea to drop the word viewer for it if we want the (great)
>> >> ability to edit stuff.
>> >>
>> >> I hope this helps.
>> >>
>> >> Fabrizio
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Tue, May 23, 2017 at 10:00 AM, Oliver Walters
>> >> mailto:oliver.henry.walt...@gmail.com
>> >>
>> >> wrote:
>> >>
>> >> Fabrizio,
>> >>
>> >> 1. You have added a custom field called "Description".
>> >> 2. The table viewer has an "inbuild" field called "Description". It
>> >> populates this field with the component description which is found
>> >> in the .dcm files
>> >>
>> >> Here's what I see.
>> >

[Kicad-developers] [FEATURE] [UI] Splashscreen Buttons

[Oliver Walters]

Attached is a very small patch that provides some visual improvements to
the KiCAD splash screen:

- Button bar extends to entire width of screen
- Consistent separation between buttons
- Improved button tooltips
- Associated code cleanup.

Oliver
From 72af3752273f14d4842958621a3ad51fcca36261 Mon Sep 17 00:00:00 2001
From: Oliver Walters 
Date: Wed, 24 May 2017 23:51:02 +1000
Subject: [PATCH] Improved button layout on splash screen

- Simplified code
- Button bar expands to fill entire screen width
---
 kicad/commandframe.cpp | 99 +++---
 kicad/kicad.h  | 12 ++
 kicad/mainframe.cpp|  5 ++-
 3 files changed, 61 insertions(+), 55 deletions(-)

diff --git a/kicad/commandframe.cpp b/kicad/commandframe.cpp
index 21ad7bb..d4cb520 100644
--- a/kicad/commandframe.cpp
+++ b/kicad/commandframe.cpp
@@ -32,15 +32,15 @@
 
 #include "kicad.h"
 
+// Amount of clearance between tool buttons
+const int BUTTON_SEPARATION = 5;
+
+// Buttons are larger than images by this amount
+const int BUTTON_EXPANSION  = 5;
 
 LAUNCHER_PANEL::LAUNCHER_PANEL( wxWindow* parent ) :
 wxPanel( parent, wxID_ANY )
 {
-m_bitmapButtons_maxHeight = 0;
-m_buttonSeparation = 10;// control of command buttons position
-m_buttonsListPosition.x = m_buttonSeparation;
-m_buttonsListPosition.y = m_buttonSeparation;
-m_buttonLastPosition= m_buttonsListPosition;
 
 // Add bitmap buttons to launch KiCad utilities:
 CreateCommandToolbar();
@@ -48,67 +48,76 @@ LAUNCHER_PANEL::LAUNCHER_PANEL( wxWindow* parent ) :
 
 int LAUNCHER_PANEL::GetPanelHeight() const
 {
-int height = m_buttonsListPosition.y + m_bitmapButtons_maxHeight
- + m_buttonSeparation;
-return height;
+return m_height + 2 * BUTTON_SEPARATION;
 }
 
 /**
- * Function CreateCommandToolbar
- * create the buttons to call Eeschema CvPcb, Pcbnew and GerbView
+ * Add application launcher buttons
+ * e.g. Eeschema, CvPcb, Pcbnew, GerbView
  */
 void LAUNCHER_PANEL::CreateCommandToolbar()
 {
-wxBitmapButton* btn;
+m_buttonSizer = new wxBoxSizer( wxHORIZONTAL );
 
-btn = AddBitmapButton( ID_TO_SCH, KiBitmap( icon_eeschema_xpm ) );
-btn->SetToolTip( _( "Eeschema - Electronic schematic editor" ) );
+AddButton( ID_TO_SCH,
+   KiBitmap( icon_eeschema_xpm ),
+   _( "Schematic layout editor" ) );
 
-btn = AddBitmapButton( ID_TO_SCH_LIB_EDITOR, KiBitmap( icon_libedit_xpm ) );
-btn->SetToolTip( _( "Schematic library editor" ) );
+AddButton( ID_TO_SCH_LIB_EDITOR,
+   KiBitmap( icon_libedit_xpm ),
+   _( "Schematic library editor" ) );
 
-btn = AddBitmapButton( ID_TO_PCB, KiBitmap( icon_pcbnew_xpm ) );
-btn->SetToolTip( _( "Pcbnew - Printed circuit board editor" ) );
+AddButton( ID_TO_PCB,
+   KiBitmap( icon_pcbnew_xpm ),
+   _( "PCB layout editor" ) );
 
-btn = AddBitmapButton( ID_TO_PCB_FP_EDITOR, KiBitmap( icon_modedit_xpm ) );
-btn->SetToolTip( _( "PCB footprint editor" ) );
+AddButton( ID_TO_PCB_FP_EDITOR,
+   KiBitmap( icon_modedit_xpm ),
+   _( "PCB library editor" ) );
 
-btn = AddBitmapButton( ID_TO_GERBVIEW, KiBitmap( icon_gerbview_xpm ) );
-btn->SetToolTip( _( "GerbView - Gerber viewer" ) );
+AddButton( ID_TO_GERBVIEW,
+   KiBitmap( icon_gerbview_xpm ),
+   _( "Gerber viewer" ) );
 
-btn = AddBitmapButton( ID_TO_BITMAP_CONVERTER, KiBitmap( icon_bitmap2component_xpm ) );
-btn->SetToolTip( _(
-"Bitmap2Component - Convert bitmap images to Eeschema\n"
-"or Pcbnew elements" ) );
+AddButton( ID_TO_BITMAP_CONVERTER,
+   KiBitmap( icon_bitmap2component_xpm ),
+   _( "Import bitmap\n"
+  "Convert bitmap images to schematic or PCB elements" ) );
 
-btn = AddBitmapButton( ID_TO_PCB_CALCULATOR, KiBitmap( icon_pcbcalculator_xpm ) );
-btn->SetToolTip( _( "Pcb calculator - Calculator for components, track width, etc." ) );
+AddButton( ID_TO_PCB_CALCULATOR,
+   KiBitmap( icon_pcbcalculator_xpm ),
+   _( "Calculator tools" ) );
 
-btn = AddBitmapButton( ID_TO_PL_EDITOR, KiBitmap( icon_pagelayout_editor_xpm ) );
-btn->SetToolTip( _( "Pl editor - Worksheet layout editor" ) );
-}
+AddButton( ID_TO_PL_EDITOR,
+   KiBitmap( icon_pagelayout_editor_xpm ),
+   _( "Worksheet layout editor" ) );
 
+// Add a stretchy spacer to make button bar fill the entire screen
+m_buttonSizer->AddStretchSpacer();
+
+SetSizer( m_buttonSizer );
+}
 
 /**
- * Function AddBitmapButton
- * add a  Bitmap Button (fast launch button) to the but

[Kicad-developers] [PATCH] Speed improvement for Duplicate functionality

[Oliver Walters]

Hey all,

I noticed that the Duplicate functionality in pcbnew / modedit was woefully
slow when copying more than a handful of items.

I benchmarked it with 1000 items, it took 58 seconds to perform the
duplication (KiCAD was at 100% CPU the whole time).

I have attached a patch that reduces this time to ~200ms for the same set
of items.

The speed issue is due to each item being passed through the tool framework
multiple times. The patch adds a tool function to select / deselect a list
of items with a single call

Regards,
Oliver
From 70822a2d7e831a047d98552ff4faf7eef8bc884a Mon Sep 17 00:00:00 2001
From: Oliver Walters 
Date: Sun, 28 May 2017 22:33:43 +1000
Subject: [PATCH] Improved speed of Duplicate action

- Removed repetitive tool calls
---
 pcbnew/tools/edit_tool.cpp  | 56 +++-
 pcbnew/tools/pcb_actions.h  |  6 
 pcbnew/tools/selection_tool.cpp | 72 -
 pcbnew/tools/selection_tool.h   |  6 
 4 files changed, 116 insertions(+), 24 deletions(-)

diff --git a/pcbnew/tools/edit_tool.cpp b/pcbnew/tools/edit_tool.cpp
index 2211fed..73a5907 100644
--- a/pcbnew/tools/edit_tool.cpp
+++ b/pcbnew/tools/edit_tool.cpp
@@ -297,7 +297,9 @@ int EDIT_TOOL::Main( const TOOL_EVENT& aEvent )
 
 // Drag items to the current cursor position
 for( auto item : selection )
+{
 static_cast( item )->Move( movement + m_offset );
+}
 }
 else if( !m_dragging )// Prepare to start dragging
 {
@@ -828,10 +830,14 @@ int EDIT_TOOL::MoveExact( const TOOL_EVENT& aEvent )
 }
 
 
+/**
+ * Duplicate items that are currently selected (by SELECTION_TOOL)
+ *
+ * Each selected item is duplicated and pushed to new_items list
+ * Old selection is cleared, and new items are then selected.
+ */
 int EDIT_TOOL::Duplicate( const TOOL_EVENT& aEvent )
 {
-// Note: original items are no more modified.
-
 bool increment = aEvent.IsAction( &PCB_ACTIONS::duplicateIncrement );
 
 // Be sure that there is at least one item that we can modify
@@ -843,28 +849,24 @@ int EDIT_TOOL::Duplicate( const TOOL_EVENT& aEvent )
 // we have a selection to work on now, so start the tool process
 PCB_BASE_EDIT_FRAME* editFrame = getEditFrame();
 
-std::vector old_items;
+std::vector new_items;
 
-for( auto item : selection )
-{
-if( item )
-old_items.push_back( static_cast( item ) );
-}
+BOARD_ITEM* orig_item = nullptr;
+BOARD_ITEM* dupe_item = nullptr;
 
-for( unsigned i = 0; i < old_items.size(); ++i )
+// Duplicate each selected item
+for( auto item : selection )
 {
-BOARD_ITEM* item = old_items[i];
-
-// Unselect the item, so we won't pick it up again
-// Do this first, so a single-item duplicate will correctly call
-// SetCurItem and show the item properties
-m_toolMgr->RunAction( PCB_ACTIONS::unselectItem, true, item );
+orig_item = static_cast( item );
 
-BOARD_ITEM* new_item = NULL;
+if( !orig_item )
+{
+continue;
+}
 
 if( m_editModules )
 {
-new_item = editFrame->GetBoard()->m_Modules->Duplicate( item, increment );
+dupe_item = editFrame->GetBoard()->m_Modules->Duplicate( orig_item, increment );
 }
 else
 {
@@ -874,23 +876,31 @@ int EDIT_TOOL::Duplicate( const TOOL_EVENT& aEvent )
 // so zones are not duplicated
 if( item->Type() != PCB_ZONE_AREA_T )
 #endif
-new_item = editFrame->GetBoard()->Duplicate( item );
+dupe_item = editFrame->GetBoard()->Duplicate( orig_item );
 }
 
-if( new_item )
+if( dupe_item )
 {
-m_commit->Add( new_item );
+// Clear the selection flag here, otherwise the SELECTION_TOOL
+// will not properly select it later on
+dupe_item->ClearSelected();
 
-// Select the new item, so we can pick it up
-m_toolMgr->RunAction( PCB_ACTIONS::selectItem, true, new_item );
+new_items.push_back( dupe_item );
+m_commit->Add( dupe_item );
 }
 }
 
+// Clear the old selection first
+m_toolMgr->RunAction( PCB_ACTIONS::selectionClear, true );
+
+// Select the new items
+m_toolMgr->RunAction( PCB_ACTIONS::selectItems, true, &new_items );
+
 // record the new items as added
 if( !selection.Empty() )
 {
 editFrame->DisplayToolMsg( wxString::Format( _( "Duplicated %d item(s)" ),
-(int) old_items.size() ) );
+(int) new_items.size() ) );
 
 // If items were duplicated, pick them up
 // this works well for "dropping" copies around and pushes

Re: [Kicad-developers] [PATCH] Speed improvement for Duplicate functionality

[Oliver Walters]

As a follow-up to this, I also notice that if you select a large number of
items, the UI hangs for a *very long* time after the selection is complete.
The same occurs when you click at an empty position to deselect all items.

Can be a minute or more for large numbers of items.

I have not been able to find the cause for this but I do not think it is
the fault of SELECTION_TOOL in this case.

Oliver

On Sun, May 28, 2017 at 10:40 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Hey all,
>
> I noticed that the Duplicate functionality in pcbnew / modedit was
> woefully slow when copying more than a handful of items.
>
> I benchmarked it with 1000 items, it took 58 seconds to perform the
> duplication (KiCAD was at 100% CPU the whole time).
>
> I have attached a patch that reduces this time to ~200ms for the same set
> of items.
>
> The speed issue is due to each item being passed through the tool
> framework multiple times. The patch adds a tool function to select /
> deselect a list of items with a single call
>
> Regards,
> 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] Hello & Questions to future Administration of Python Plugins

[Oliver Walters]

Having Python more accessible to core KiCAD functionality would be a very
good improvement IMHO.

Another example - python DRC scripts. Instead of hard-coding DRC checks,
have a folder of DRC scripts that user can select / deselect. Or add extra
scripts if they want them.

On Fri, Jun 2, 2017 at 5:46 PM, Fabrizio Tappero  wrote:

> Hi Simon,
> welcome to the group!
>
> Reading your interesting email I decided to write to you. I am interested
> as well in the python functionality for the purpose of implementing killing
> functionalities. via-fence generator is certainly an interesting thing.
>
> I spend long hours doing schematics at work and I love the idea of
> implementing python stuff that could make my life easier. Specifically I
> spend a long time in library component generation and I would love to do
> something about it. This could be done by creating new python (or non
> python) tools to import component info or to created tools to facilitate
> the contribution to the quality (and size) of the kicad lib. Not really
> sure what is best.
>
> Python scripts could be attached to F1, F2 and F3 general-purpose buttons.
> So that others can easily use these scripts. This people would probably
> make kicad better. This would be classified as "kicad user harvesting via
> python scripting for library component creation " ;-) a topic I always
> wanted to talk about on this mailing list.
>
> Regarding your scripting database idea. Kicad comes with some script for
> BOM generation and I guess lead developers would certainly consider adding
> more scripts into the main kicad repo.
>
> Cheers
> Fabrizio
>
>
>
>
> On Thu, Jun 1, 2017 at 8:01 PM, Simon Küppers  bochum.de> wrote:
>
>> Hi everyone,
>> Thanks Wayne for approving me to the developers mailing list.
>> I am very new to KiCAD (only heard of it some time ago) and just stumbled
>> upon a
>> Youtube Video of 2017 FOSDEM (I believe?) where Wayne presented the
>> current state of KiCAD.
>> As a result I had to see for myself and I am quite impressed of the
>> development of KiCAD in the
>> last years! Very impressive.
>>
>> I am a Researcher working in the areas of IC Design, (RF-) PCB Design and
>> I am also a quite
>> realiable programmer (thats what I think anyway :-)). I am used to EAGLE
>> CAD (from the oldern days)
>> and Altium Designer (ugh..). For IC Design we use Cadence Virtuoso.
>>
>> Now, what really kicks me off with KiCAD is the (still very early) Python
>> support. In my opinion, it is definitely
>> the right choice to pull some non-major functionality from the main KiCAD
>> core and implement it into Python.
>> Why? Simply because that way it is much easier for people to modify,
>> tweak, extend and bugfix the KiCAD software,
>> without having to study the KiCAD core. I want to be the living proof for
>> this fact ;-)
>>
>> I already have some ideas for pcbnew plugins. E.g. a Via-Fence Generator
>> (select a line-segment in pcbnew, start
>> generator and enjoy the vias to the left and right of the line). There is
>> similar functionality in Altium, but it
>> is very rudimentory and cannot be adjusted or tweaked very much. Also it
>> is sometimes quite buggy resulting in non-ideal via
>> placement and due to this we usually place those vias (with GCPW
>> transmission lines for example) by hand...
>> I think this would be a nice example of what non-proficient users could
>> add to KiCAD without ever touching anything belonging
>> to the KiCAD C++ core application (where the latter would not fit into my
>> available spare time due to its complexity, sorry!)
>>
>> Anyway, what I wanted to ask before even starting with the development is
>> the following. I know the current status of the
>> Python interface in pcbnew is very limited and "only" an interface
>> generated by SWIG. So I guess there will be some
>> heavy adjustments in the API in the future (which is fine with me).
>>
>> Is it planned in the future to make plugins part of the KiCAD
>> distribution (i.e. ship them within the distro packages?)?
>> (Or do KiCAD users have to find a way for organizing a repository of
>> KiCAD plugins?)
>> If yes, is the correct place to discuss their development (and request
>> features) in this mailing list? Or should the forums
>> be used instead/at first?
>>
>> I guess that is it for now. A big thanks to all the developers and
>> especially the CERN folks. I put in a donation a few days ago :-)
>>
>> Best Regards
>>
>> ___
>> 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] Speed improvement for Duplicate functionality

[Oliver Walters]

Friendly bump - has anyone had a chance to review this?

On Sun, May 28, 2017 at 11:14 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> As a follow-up to this, I also notice that if you select a large number of
> items, the UI hangs for a *very long* time after the selection is complete.
> The same occurs when you click at an empty position to deselect all items.
>
> Can be a minute or more for large numbers of items.
>
> I have not been able to find the cause for this but I do not think it is
> the fault of SELECTION_TOOL in this case.
>
> Oliver
>
> On Sun, May 28, 2017 at 10:40 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> Hey all,
>>
>> I noticed that the Duplicate functionality in pcbnew / modedit was
>> woefully slow when copying more than a handful of items.
>>
>> I benchmarked it with 1000 items, it took 58 seconds to perform the
>> duplication (KiCAD was at 100% CPU the whole time).
>>
>> I have attached a patch that reduces this time to ~200ms for the same set
>> of items.
>>
>> The speed issue is due to each item being passed through the tool
>> framework multiple times. The patch adds a tool function to select /
>> deselect a list of items with a single call
>>
>> Regards,
>> 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] menu icons

[Oliver Walters]

I have also noticed this on Linux version

On Tue, Jun 6, 2017 at 8:07 AM, Marco Ciampa  wrote:

> I work under Linux.
> I do not see any menu icon, either with the git compiled version or the
> snpy one.
> Is this normal?
>
> TIA
>
> Regards,
>
> --
>
>
> Marco Ciampa
>
> I know a joke about UDP, but you might not get it.
>
> 
>
>  GNU/Linux User #78271
>  FSFE fellow #364
>
> 
>
>
> ___
> 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] Speed improvement for Duplicate functionality

[Oliver Walters]

Thanks Maciej,

Any guess as to why the SELECT / UNSELECT of multiple objects takes a very
long time? I was unable to solve this problem.

Cheers,

Oliver

On Mon, Jun 12, 2017 at 7:29 PM, Maciej Sumiński 
wrote:

> Hi Oliver,
>
> I apologize for late answer, I was away from keyboard for the last 3
> weeks and now I am crawling through my mailbox.
>
> Well done, your changes resolve the issue correctly, so thank you for
> investigating the problem. I have just committed the patch with some
> minor changes (removed doxygen-style comments for functions from .cpp
> files, they are supposed to be located in headers [1]).
>
> Regards,
> Orson
>
> 1.
> http://kicad-source-mirror.readthedocs.io/en/latest/
> Documentation/development/coding-style-policy/#321-
> function-comments-function_comments
>
> On 05/28/2017 02:40 PM, Oliver Walters wrote:
> > Improved speed of Duplicate action
> >
> > - Removed repetitive tool calls
>
>
>
> ___
> 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] [GAL] Added fixed-width line rendering

[Oliver Walters]

This patch adds zoom-independent fixed-width line rendering to GAL.

GAL drawing tools can call SetFixedLineWidth( width ) to draw a line that
is the same width on screen (pixels) independent of the zoom level.

I have implemented this in two locations:

a) PCB_BRIGHTBOX - the selection clarification bright-box is very thin at
wide zoom, and very wide at narrow zoom. Now it is 3 pixels thick at all
zoom

b) RATS_NEST - Increased this to 2 pixels wide, it is much easier to see!
From 966c089b99ef77ecace7d340dfc274fc15fb23e5 Mon Sep 17 00:00:00 2001
From: Oliver Walters 
Date: Thu, 22 Jun 2017 23:41:00 +1000
Subject: [PATCH] Added fixed-width line rendering to GAL

Updated rendering for:
- BRIGHT_BOX
- RATSNEST
---
 common/preview_items/bright_box.cpp  |  4 ++--
 include/gal/graphics_abstraction_layer.h | 10 ++
 pcbnew/ratsnest_viewitem.cpp |  2 +-
 pcbnew/tools/pcb_bright_box.cpp  |  6 +-
 4 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/common/preview_items/bright_box.cpp b/common/preview_items/bright_box.cpp
index cc55dfa..8709ede 100644
--- a/common/preview_items/bright_box.cpp
+++ b/common/preview_items/bright_box.cpp
@@ -28,7 +28,7 @@
 
 using namespace KIGFX;
 
-const double BRIGHT_BOX::LINE_WIDTH = 1.0;
+const double BRIGHT_BOX::LINE_WIDTH = 3.0;
 const COLOR4D BRIGHT_BOX::BOX_COLOR = KIGFX::COLOR4D( 0.0, 1.0, 0.0, 1.0 );
 
 BRIGHT_BOX::BRIGHT_BOX() :
@@ -49,7 +49,7 @@ void BRIGHT_BOX::ViewDraw( int aLayer, KIGFX::VIEW* aView ) const
 
 gal->SetIsStroke( true );
 gal->SetIsFill( false );
-gal->SetLineWidth( m_lineWidth );
+gal->SetFixedLineWidth( m_lineWidth );
 gal->SetStrokeColor( m_color );
 
 BOX2I box = m_item->ViewBBox();
diff --git a/include/gal/graphics_abstraction_layer.h b/include/gal/graphics_abstraction_layer.h
index 1cac4e9..11d6047 100644
--- a/include/gal/graphics_abstraction_layer.h
+++ b/include/gal/graphics_abstraction_layer.h
@@ -259,6 +259,16 @@ public:
 }
 
 /**
+ * @brief Set a fixed line width which appears the same independent of zoom
+ *
+ * @param aLineWidth is the line width (in view pixels)
+ */
+virtual void SetFixedLineWidth( double aLineWidth )
+{
+SetLineWidth( aLineWidth / GetWorldScale() );
+}
+
+/**
  * @brief Set the line width.
  *
  * @param aLineWidth is the line width.
diff --git a/pcbnew/ratsnest_viewitem.cpp b/pcbnew/ratsnest_viewitem.cpp
index 2d8fff6..17f2bf2 100644
--- a/pcbnew/ratsnest_viewitem.cpp
+++ b/pcbnew/ratsnest_viewitem.cpp
@@ -58,7 +58,7 @@ void RATSNEST_VIEWITEM::ViewDraw( int aLayer, KIGFX::VIEW* aView ) const
 auto gal = aView->GetGAL();
 gal->SetIsStroke( true );
 gal->SetIsFill( false );
-gal->SetLineWidth( 1.0 );
+gal->SetFixedLineWidth( 2.0 );
 auto rs = aView->GetPainter()->GetSettings();
 auto color = rs->GetColor( NULL, LAYER_RATSNEST );
 int highlightedNet = rs->GetHighlightNetCode();
diff --git a/pcbnew/tools/pcb_bright_box.cpp b/pcbnew/tools/pcb_bright_box.cpp
index aee6462..e2b0abd 100644
--- a/pcbnew/tools/pcb_bright_box.cpp
+++ b/pcbnew/tools/pcb_bright_box.cpp
@@ -27,13 +27,9 @@
 
 using namespace KIGFX;
 
-const double PCB_BRIGHT_BOX::PCB_LINE_WIDTH = 10.0;
-
-
 PCB_BRIGHT_BOX::PCB_BRIGHT_BOX() :
 BRIGHT_BOX()
 {
-SetLineWidth( PCB_LINE_WIDTH );
 }
 
 
@@ -50,7 +46,7 @@ void PCB_BRIGHT_BOX::ViewDraw( int aLayer, KIGFX::VIEW* aView ) const
 
 gal->SetIsStroke( true );
 gal->SetIsFill( false );
-gal->SetLineWidth( m_lineWidth );
+gal->SetFixedLineWidth( m_lineWidth );
 gal->SetStrokeColor( m_color );
 
 gal->DrawSegment( track->GetStart(), track->GetEnd(), track->GetWidth() );
-- 
2.7.4

___
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] [GAL] Added fixed-width line rendering

[Oliver Walters]

Orson,

If you're willing to have a look at this feature I'd appreciate it. I have
no knowledge of the OpenGL GAL so it would be much quicker if you could
implement it :)

On 23 Jun 2017 08:23, "Maciej Suminski"  wrote:

> Hi Oliver,
>
> I have mixed feelings about this patch. This approach is ok for Cairo
> and non-cached targets in OpenGL, for cached targets it will still draw
> a line that is dependent on the zoom level.
>
> Ideally, the problem could be solved with shaders. I can give you some
> hints if you want to tackle this, otherwise I may try to code it myself
> next week.
>
> Regards,
> Orson
>
> On 06/22/2017 03:44 PM, Oliver Walters wrote:
> > This patch adds zoom-independent fixed-width line rendering to GAL.
> >
> > GAL drawing tools can call SetFixedLineWidth( width ) to draw a line that
> > is the same width on screen (pixels) independent of the zoom level.
> >
> > I have implemented this in two locations:
> >
> > a) PCB_BRIGHTBOX - the selection clarification bright-box is very thin at
> > wide zoom, and very wide at narrow zoom. Now it is 3 pixels thick at all
> > zoom
> >
> > b) RATS_NEST - Increased this to 2 pixels wide, it is much easier to see!
> >
> >
> >
> > ___
> > 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] 3D models repository

[Oliver Walters]

Wayne, Maciej, et al,

This has been sitting in my //todo for a while. Can I get some
clarification on the LICENSE issue and then I will ensure it is applied to
the repos:

Am I correct in my understanding that the following text is ALL that is
required (placed within a LICENSE file in each repo)?

"This work is licensed under the Creative Commons CC-BY-SA 4.0 License.
> To the extent that circuit schematics that use Licensed Material can be
> considered to be ‘Adapted Material’, then the copyright holder waives
> article 3.b of the license with respect to these schematics."


Or is this an addendum required to be made and I am required to include the
entire CC-BY-SA text?

Regards,
Oliver

On Tue, Apr 11, 2017 at 6:41 AM, Wayne Stambaugh 
wrote:

> I prefer the former.  Adding the license to fields would be cumbersome.
>
> Cheers,
>
> Wayne
>
> On 4/10/2017 4:43 PM, Maciej Suminski wrote:
> > The easiest way to include the license is to put a file containing the
> > text in the libraries repository. Alternatively, the text could be
> > stored in the 'License' field for symbols or 'Doc' property for
> > footprints, but it feels a bit too wordy to me.
> >
> > Cheers,
> > Orson
> >
> > On 04/07/2017 11:55 AM, Javier Serrano wrote:
> >> On Sun, Feb 26, 2017 at 6:21 PM, Wayne Stambaugh 
> >> wrote:
> >>
> >>> I'm still waiting for our friends at CERN for an answer on library
> >>> licensing.  We are leaning towards CC-SA with the use exception clause.
> >>> I turning out to be the longest time ever to write a single sentence.
> ;)
> >>>
> >>
> >> OK, better late than never. Here are the proposals:
> >>
> >> For schematics symbols and for complete symbol libraries:
> >>
> >> "This work is licensed under the Creative Commons CC-BY-SA 4.0 License.
> >> To the extent that circuit schematics that use Licensed Material can be
> >> considered to be ‘Adapted Material’, then the copyright holder waives
> >> article 3.b of the license with respect to these schematics."
> >>
> >> For footprints and libraries of footprints:
> >>
> >> "This work is licensed under the Creative Commons CC-BY-SA 4.0 License.
> >> To the extent that circuit layout that uses Licensed Material can be
> >> considered to be ‘Adapted Material’, then the copyright holder waives
> >> article 3.b of the license with respect to this layout."
> >>
> >> This assumes we want a "weak copyleft" regime for libraries, i.e. we
> want
> >> modifications to symbols/footprints/libraries to be published under the
> >> same license, but we don't want to force people to publish their
> complete
> >> designs under CC-BY-SA just because they used the KiCad libraries. Then
> >> there is the issue of how to embed this information in symbols, symbol
> >> libraries, footprints and footprint libraries. I am not competent to
> >> comment on that.
> >>
> >> Cheers,
> >>
> >> Javier
> >>
> >>
> >>
> >> ___
> >> 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] 3D models repository

[Oliver Walters]

Wayne, others,

A lot of input here, thanks everyone.

Based on the suggestions above, my proposal is as follows:



symbols licence file:


Copyright (C) 2017 KiCad

This work is licensed under the [Creative Commons CC-BY-SA 4.0 License](
https://creativecommons.org/licenses/by-sa/4.0/).

To the extent that circuit schematics that use Licensed Material can be
considered to be ‘Adapted Material’, then the copyright holder waives
article 3.b of the license with respect to these schematics.


footprints licence file:


Copyright (C) 2017 KiCad

This work is licensed under the [Creative Commons CC-BY-SA 4.0 License](
https://creativecommons.org/licenses/by-sa/4.0/).

To the extent that circuit layouts that use Licensed Material can be
considered to be ‘Adapted Material’, then the copyright holder waives
article 3.b of the license with respect to this layout.


3D models licence file:


Copyright (C) 2017 KiCad

This work is licensed under the [Creative Commons CC-BY-SA 4.0 License](
https://creativecommons.org/licenses/by-sa/4.0/).

To the extent that circuit models that use Licensed Material can be
considered to be ‘Adapted Material’, then the copyright holder waives
article 3.b of the license with respect to these models.


This will be a single file per repository.

Please let me know if this is sufficient (or otherwise). I am not willing
to make a call on the wording of this myself, but would like to ensure that
it is enacted soon.

Kind Regards,
Oliver

On Thu, Jun 29, 2017 at 3:40 AM, Wayne Stambaugh 
wrote:

> On 6/28/2017 12:18 M, Simon Richter wrote:
> > Hi,
> >
> > On 28.06.2017 16:48, Wayne Stambaugh wrote:
> >
> >> In source we typically do this:
> >>
> >>  * Copyright (C) 2017 Leet Hacker ,
> >>  * Copyright (C) 2017 KiCad Developers.
> >
> >> The user copy right is followed by the project copyright which is
> >> updated as the file is modified by other developers.
> >
> > I'm not sure the "project copyright" is actually correct from a legal
> > point of view, as there is no such legal entity as "KiCad Developers".
>
> "KiCad Developers" should probably be changed to "KiCad" as in the
> project.  They have been used interchangeably in the past so my
> motivation to change them would be low.
>
> >
> > What we're actually supposed to do is that whenever someone touches a
> > file (except for minor changes) is to create a new copyright line or
> > extend the list of years on the existing one.
> >
> > Minor changes below a certain threshold generally don't get a separate
> > copyright, and don't extend the protection period (so you shouldn't add
> > the current year for these either).
> >
> > So, Tom writes something in 2016:
> >
> >  * Copyricght 2016 Tom
> >
> > Then I change it in 2017
> >
> >  * Copyright 2016 Tom
> >  * Copyright 2017 Simon
> >
> > Then Tom changes it again:
> >
> >  * Copyright 2016,2017 Tom
> >  * Copyright 2017 Simon
>
> That is the point of the KiCad project copyright.  Minor changes do not
> change the original copyright holder.  The only time you should add your
> name to the copyright is if you rewrite most of the underlying code.
> This has been an unwritten rule and has happened quite a few times in
> the past.  Although this probably was not followed as strictly as it
> should have been.  We probably shouldn't be updating the individual
> copyright holder dates.  Only the KiCad copyright dates should be
> updated when the file is changed even if the person who changed it is
> the original copyright holder.
>
> >
> > IIRC the "(C)" is also not needed here, because we already have the word
> > "Copyright", which can only be abbreviated by using the © sign, not
> > ASCII art of it. Also, the list of years should not have ranges IIRC.
>
> This is semantics.  I don't think it's worth changing every source file
> to adhere to this.
>
> >
> >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

Re: [Kicad-developers] [RFC] 3D models repository

[Oliver Walters]

Would it be sufficient to drop the "Copyright (C) 2017 KiCad" header?

On Thu, Jun 29, 2017 at 5:28 PM, Javier Serrano <
javier.serrano.par...@gmail.com> wrote:

> On Thu, Jun 29, 2017 at 3:27 AM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> Wayne, others,
>>
>> A lot of input here, thanks everyone.
>>
>> Based on the suggestions above, my proposal is as follows:
>>
>> 
>> 
>>
>> symbols licence file:
>>
>> 
>> 
>> Copyright (C) 2017 KiCad
>>
>>
>  I agree with Simon that "KiCad" cannot be the copyright holder. Imagine
> for the sake of argument I need to contact the copyright holder. Say I
> would like to negotiate with him/her a change of licence. I want to use the
> material without being subject to the CC-BY-SA licence, and I am willing to
> pay for it. So I'd like to benefit from some kind of dual-licensing scheme,
> whereby I receive e.g. a copy of a 3D model file with a special licence
> just for me. Only the copyright holder can do that. Now I go to the file
> and I read "Copyright KiCad." Who should I speak to? Who has the right to
> do what I need? That's just an example. For any action where you would need
> the copyright holder to do something, you'd bump against the same issue.
> One could conceivably define KiCad as a valid legal entity, and then you
> could have KiCad be the copyright holder, as the FSF is the copyright
> holder of lots of code, but that's a strategic change to be discussed, I
> guess, with the project leader and the project initiator. Right now, KiCad
> cannot be the holder of any copyright. The same applies, IMHO, to "KiCad
> developers."
>
> Cheers,
>
> Javier
>
___
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] 3D models repository

[Oliver Walters]

Cirilo,

Can we stipulate as part of the license file that any contributors agree
implicitly that their generated models are released as public domain? i.e.
don't require explicit release from every contributor, as it is inherent to
the library LICENSE?

a) If you contribute model / footprint / symbol to KiCad libraries, they
can be distributed in accordance with [whatever license we choose here]

b) KiCad assumes no responsibility for the accuracy of the model data

c) Library data may be shared freely*

* Here "freely" is the current source of contention. I am all for having as
permissive a license as possible - I don't see any benefit from locking the
library down.

Oliver

On Sat, Jul 1, 2017 at 8:25 AM, Cirilo Bernardo 
wrote:

> On Thu, Jun 29, 2017 at 8:16 AM, Oliver Walters
>  wrote:
> > Would it be sufficient to drop the "Copyright (C) 2017 KiCad" header?
> >
>
> No, because we have no idea who holds copyright. KiCad cannot be a
> copyright holder
> because it is not a legal entity (person or corporation). We would
> need to maintain a text
> file which is a register of the copyright holders of each file.  To
> complicate things, many
> models are generated from parametric scripts.  The scripts themselves
> are copyright
> material but the models produced is a different matter. If you can get
> all script contributors
> to agree, then I think it would be best to release the generated
> models as Public Domain.
> Even this is not so simple because we would need to maintain a
> directory with declarations
> from script contributors to state that the output of the scripts are
> Public Domain. Even
> that is not so simple because some jurisdictions may not accept that
> mechanism.
>
> - Cirilo
>
> > On Thu, Jun 29, 2017 at 5:28 PM, Javier Serrano
> >  wrote:
> >>
> >> On Thu, Jun 29, 2017 at 3:27 AM, Oliver Walters
> >>  wrote:
> >>>
> >>> Wayne, others,
> >>>
> >>> A lot of input here, thanks everyone.
> >>>
> >>> Based on the suggestions above, my proposal is as follows:
> >>>
> >>>
> >>> 
> 
> >>>
> >>> symbols licence file:
> >>>
> >>>
> >>> 
> 
> >>> Copyright (C) 2017 KiCad
> >>>
> >>
> >>  I agree with Simon that "KiCad" cannot be the copyright holder. Imagine
> >> for the sake of argument I need to contact the copyright holder. Say I
> would
> >> like to negotiate with him/her a change of licence. I want to use the
> >> material without being subject to the CC-BY-SA licence, and I am
> willing to
> >> pay for it. So I'd like to benefit from some kind of dual-licensing
> scheme,
> >> whereby I receive e.g. a copy of a 3D model file with a special licence
> just
> >> for me. Only the copyright holder can do that. Now I go to the file and
> I
> >> read "Copyright KiCad." Who should I speak to? Who has the right to do
> what
> >> I need? That's just an example. For any action where you would need the
> >> copyright holder to do something, you'd bump against the same issue. One
> >> could conceivably define KiCad as a valid legal entity, and then you
> could
> >> have KiCad be the copyright holder, as the FSF is the copyright holder
> of
> >> lots of code, but that's a strategic change to be discussed, I guess,
> with
> >> the project leader and the project initiator. Right now, KiCad cannot
> be the
> >> holder of any copyright. The same applies, IMHO, to "KiCad developers."
> >>
> >> Cheers,
> >>
> >> Javier
> >
> >
> >
> > ___
> > 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] 3D models repository

[Oliver Walters]

>
> After that, people who contribute new symbols/fottprints/models should
> make copyright and license notices part of that submission, exactly as for
> source code.


This is going to be very burdensome - it is already quite a lot of work to
submit symbols / footprints against the KLC (KiCad Library Convention).
Requiring users to add license files will:

a) Bloat the libraries

b) Be beyond the ability or patience of most contributors.

I would strongly prefer an approach that essentially says "If you
contribute to the library, the symbols / footprints will be placed under
the existing license available in the LICENSE file."

 I had been operating under the assumption that we only had to consider the
license that applies to library data AFTER they have been accepted into the
library.

Allowing per-file licensing is going to be a real mess.

Oliver

On Sat, Jul 1, 2017 at 6:29 PM, Javier Serrano <
javier.serrano.par...@gmail.com> wrote:

> On Sat, Jul 1, 2017 at 1:21 AM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> Cirilo,
>>
>> Can we stipulate as part of the license file that any contributors agree
>> implicitly that their generated models are released as public domain? i.e.
>> don't require explicit release from every contributor, as it is inherent to
>> the library LICENSE?
>>
>> a) If you contribute model / footprint / symbol to KiCad libraries, they
>> can be distributed in accordance with [whatever license we choose here]
>>
>> b) KiCad assumes no responsibility for the accuracy of the model data
>>
>> c) Library data may be shared freely*
>>
>> * Here "freely" is the current source of contention. I am all for having
>> as permissive a license as possible - I don't see any benefit from locking
>> the library down.
>>
>
> I don't think we need to invent anything new here. Just agree on a
> licence: CC0, CC-BY-SA or GPL with addenda, etc. We could also decide to
> accept a set of licenses. Then contributors who submit a model with a
> different license don't get their model merged. This is how the source code
> part of KiCad operates (except it is not seen because to the best of my
> knowledge there has been no conflict so far), without the need of a
> separate agreement. I don't see a reason to do otherwise here. The only
> difference wrt the source code part is we are now starting from a situation
> where the copyright and licensing notices need to be filled for some past
> work. After that, people who contribute new symbols/fottprints/models
> should make copyright and license notices part of that submission, exactly
> as for source code.
>
> Cheers,
>
> Javier
>
___
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] 3D models repository

[Oliver Walters]

Let's take a step back:

Currently we have the 3Dmodels license -
https://github.com/KiCad/packages3D/wiki/Model-Licencing - which is
modelled after the GEDA project (as easyw mentioned previously).

I think this is straight-forward and is consistent with how we would like
to license symbols and footprints.

If the existing 3Dmodels license is adapted for symbols and footprints
(only a few sentences need to be changed), is this OK?

Oliver

On Sat, Jul 1, 2017 at 8:43 PM, Javier Serrano <
javier.serrano.par...@gmail.com> wrote:

> On Sat, Jul 1, 2017 at 10:35 AM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>>
>> After that, people who contribute new symbols/fottprints/models should
>>> make copyright and license notices part of that submission, exactly as for
>>> source code.
>>
>>
>> This is going to be very burdensome - it is already quite a lot of work
>> to submit symbols / footprints against the KLC (KiCad Library Convention).
>> Requiring users to add license files will:
>>
>> a) Bloat the libraries
>>
>> b) Be beyond the ability or patience of most contributors.
>>
>> I would strongly prefer an approach that essentially says "If you
>> contribute to the library, the symbols / footprints will be placed under
>> the existing license available in the LICENSE file."
>>
>>  I had been operating under the assumption that we only had to consider
>> the license that applies to library data AFTER they have been accepted into
>> the library.
>>
>> Allowing per-file licensing is going to be a real mess.
>>
>
> I understand your feeling. However, I think the fact that things will be
> more burdensome in the future is:
>
> a) inevitable once you accept many of the symbols, footprints and models
> are the subject of copyright.
> b) not (very) related to a given choice of license.
>
> Not dealing with this properly exposes users to legal uncertainty, as I
> argued earlier. There are many ways of dealing with this, and all have been
> tested in the source code realm. What you suggest, for example, is very
> similar to "Contributor License Agreements", which have their pros and
> cons, documented extensively on the Internet. The owner of a symbol is its
> creator. (S)he can then decide to grant rights through a license or give
> you or any other person the right to do so on his/her behalf. But all of
> this has to be done explicitly. There is no magic way of doing it without
> any extra burden.
>
> I am a bit sorry to bring in all these complications, but I think as KiCad
> gains a larger user base, in particular commercial users, we need to be a
> bit more solid on the legal side of things. Hopefully we get to a state
> where library contributors don't see this as much of an extra burden, as is
> already the case for source code contributors.
>
> Cheers,
>
> Javier
>
___
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] Partial selection for VIA class

[Oliver Walters]

In line with my previous work on partial object selection, I have attached
a small patch for partial selection on VIA object.

Regards,
Oliver
From 5ea51ee87aa1bbdb0f1e3060ced509715f19e3be Mon Sep 17 00:00:00 2001
From: Oliver Walters 
Date: Mon, 3 Jul 2017 20:36:22 +1000
Subject: [PATCH] Added partial selection for VIA class

---
 pcbnew/class_track.cpp | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/pcbnew/class_track.cpp b/pcbnew/class_track.cpp
index b7d6456..31f721a 100644
--- a/pcbnew/class_track.cpp
+++ b/pcbnew/class_track.cpp
@@ -1319,9 +1319,13 @@ bool VIA::HitTest( const EDA_RECT& aRect, bool aContained, int aAccuracy ) const
 box.Inflate( GetWidth() / 2 );
 
 if( aContained )
+{
 return arect.Contains( box );
+}
 else
-return arect.Intersects( box );
+{
+return arect.IntersectsCircle( GetStart(), GetWidth() / 2 );
+}
 }
 
 
-- 
2.7.4

___
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] renamed eeschema right click menu "copy" into "duplicate" and some more

[Oliver Walters]

I concur with "Ctrl+D", and also I feel that "duplicate" and "copy" should
be differentiated.

COPY - Copy the item into memory, ready for a paste
DUPLICATE - COPY and then immediately instantiate the copy onto the working
screen

On Tue, Jul 4, 2017 at 5:43 PM, Fabrizio Tappero  wrote:

> Hi Guys,
> I agree with making the CTRL+D the key for duplicated in eeschema so
> that it is coherent with the same duplicated key in pcbnew. I did not
> insist with Wayne on this because I felt he knew why it was a good
> idea not to do it.
>
> But if I can insist I insist ;-)
>
> Cheers
> Fabrizio
>
>
>
>
> On Mon, Jul 3, 2017 at 6:10 PM, Maciej Sumiński 
> wrote:
> > For the record, the patch is merged. I kept the old hot key for
> > duplication (as requested), but if I were to decide - I would go for
> > CTRL+D. Alternatively, I would change pcbnew to use C for duplicate,
> > just make the hot keys coherent.
> >
> > Cheers,
> > Orson
> >
> > On 06/23/2017 08:00 PM, Wayne Stambaugh wrote:
> >> Fabrizio,
> >>
> >> I took a look at this patch and have a few comments.
> >>
> >> It will need to be rebased since I've already removed the hierarchy tool
> >> and all related code.
> >>
> >> The ctrl-d hotkey is already used in pcbnew so I don't think changing it
> >> in eeschema makes sense.  I would keep 'C' in eeschema for consistency.
> >>
> >> I'm OK with the icon changes and the terminology change form "Copy" to
> >> "Duplicate".
> >>
> >> Thanks,
> >>
> >> Wayne
> >>
> >> On 6/20/2017 6:02 AM, Fabrizio Tappero wrote:
> >>> Hello,
> >>> following up on the recent proposal to rename the eeschema "copy"
> >>> command into "duplicate" and its shortcut I am sending this patch.
> >>>
> >>> Specifically this patch does the following:
> >>>
> >>> 1) rename eeschema right click menu item "Copy" into "Duplicate"
> >>> 2) rename eeschema right click menu item "Save block" into "Copy block"
> >>> 3) change "Duplicate" shortcut from "C" to "Ctrl-D"
> >>> 4) change eeschema right click menu item "Duplicate" icon from a copy
> >>> icon into a duplicate
> >>> 5) deletes right vertical toolbar "ascend/descend hierarchy" icon and
> >>> its unnecessary code. Please make sure I deleted all of it.
> >>> 6) replace few redundant icons in the eeschema right click menu into
> >>> more global icon (now global move icon)
> >>> 7) replace the "mirror_footprint_axisX.svg" for a more standard
> >>> "mirror" global icon.
> >>> 8) replaced eeschema right click menu "delete_text" icon with more
> >>> global "delete" icon
> >>>
> >>>
> >>> Cheers
> >>> Fabrizio
> >>>
> >>>
> >>>
> >>> ___
> >>> 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