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

[Wayne Stambaugh]

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

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

[Maciej Suminski]

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

Re: [Kicad-developers] disable icons in menus by default on osx

[Andy Peters]

> On Apr 10, 2017, at 12:12 PM, Wayne Stambaugh  wrote:
> 
> I thought the reason that we added this option is so that users could
> choose if they wanted to show the icons in menus.  I seem to remember
> from the original discussion that some of our osx users didn't like the
> fact that they were compiled out of osx builds.  Do we really need to
> add the ugly #if defined()/#endif code?

I believe that the standard OS X user-interface design guidelines oppose 
in-menu icons. (I don’t care either way.)


___
Mailing list: https://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

[Wayne Stambaugh]

On 4/7/2017 5: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:

Yeah!  Would our esteemed library devs please add this license to
our libraries so we finally have some closure on this?

Thanks to CERN for providing the legal advice on this matter.

Cheers,

Wayne

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

Re: [Kicad-developers] disable icons in menus by default on osx

[Simon Wells]

this is only a single #ifdef to default it to off as osx has been as
long as i have been using it, its not compiling the icons out or
anything

On 11 April 2017 at 07:12, Wayne Stambaugh  wrote:
> I thought the reason that we added this option is so that users could
> choose if they wanted to show the icons in menus.  I seem to remember
> from the original discussion that some of our osx users didn't like the
> fact that they were compiled out of osx builds.  Do we really need to
> add the ugly #if defined()/#endif code?
>
> As for the icon size, fixing that would likely not be trivial.  A long
> time ago we used 16 X 16 images but users were complaining that they
> were too small as display resolution increased so we increased them to
> 24 X 24.  We could create an image library with multiple size images to
> resolve this issue.
>
> On 4/8/2017 6:55 AM, Simon Wells wrote:
>> also as noticed with this the icons seem overly huge for the menu, are
>> they actually the right size on any platform? as on osx at least if you
>> want the option there they should really be created at the right size so
>> that it fits in with how tall a row should be in a menu rather than
>> making each row huge as seen in screenshot
>>
>>
>>
>>
>> On 8 April 2017 at 22:42, Simon Wells > > wrote:
>>
>> Please see attached patch to disable icons in the menus by default
>> on osx
>>
>>
>>
>>
>> ___
>> Mailing list: https://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] disable icons in menus by default on osx

[Wayne Stambaugh]

I thought the reason that we added this option is so that users could
choose if they wanted to show the icons in menus.  I seem to remember
from the original discussion that some of our osx users didn't like the
fact that they were compiled out of osx builds.  Do we really need to
add the ugly #if defined()/#endif code?

As for the icon size, fixing that would likely not be trivial.  A long
time ago we used 16 X 16 images but users were complaining that they
were too small as display resolution increased so we increased them to
24 X 24.  We could create an image library with multiple size images to
resolve this issue.

On 4/8/2017 6:55 AM, Simon Wells wrote:
> also as noticed with this the icons seem overly huge for the menu, are
> they actually the right size on any platform? as on osx at least if you
> want the option there they should really be created at the right size so
> that it fits in with how tall a row should be in a menu rather than
> making each row huge as seen in screenshot
> 
> 
> 
> 
> On 8 April 2017 at 22:42, Simon Wells  > wrote:
> 
> Please see attached patch to disable icons in the menus by default
> on osx
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

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

[Fabrizio Tappero]

Hi Guys,
I actually did propose to change the names of the kicad tools few years
ago.

I personally think:

- all kicad tools should be renamed with 100% priority to users. Hence, for
example, the schematic editor should be called "schematic editor".
- rename kicad itself would also be a good idea but as JP says, kicad is
actually good enough for me. Google will eventually find it out.
- please let's stop using capital letters in all his possible combinations,
I am pretty sure no kicad user knows if it is KiCad, Kicad or kicad.
- I strongly think "ki-something" or "kicad-something" should be avoided.
- I am actually not surprised that some brand name sells more than others.
Very few people would like his girlfriend to be called "Rotox"

cheers
Fabrizio




On Mon, Apr 10, 2017 at 11:51 AM, Marco Ciampa  wrote:

> On Thu, Feb 02, 2017 at 05:59:00PM -0500, Chris Pavlina wrote:
> > On Thu, Feb 02, 2017 at 11:54:09PM +0100, Kristoffer Ödmark wrote:
> > > Why dont keep it dead simple, but still keeping the KiCAD brand?
> > >
> > > I suggest prefix every subprogram with kicad- and then use a either
> > > extremely well known abbreviation (PCB) or a descriptive english word.
> > >
> > > Examples:
> > >
> > > eeschema-> kicad-schematics
> > > pcbnew  -> kicad-layouts
> > > 3d-viewer   -> kicad-3d
> > > gerb-viewer -> kicad-gerbers
> > > whatever-> kicad-whatever
> > > 
> > >
> > > Self explaining names that are easy to use standalone as well as names
> that
> > > will not make a new users scoff and works well as binary filenames.
> >
> > Yes, I like this. I was talking about the names in the UI, mostly - this
> > is a good companion to that.
> >
> > >
> > > I really dislike having entirely different names for the binary and the
> > > shortcut-key/desktop-shortcut like ubuntu and their decision to have
> > > "Document Viewer" as the name for evince etc.
> >
> > Agreed.
> >
>
> Sorry for being so late...
>
> For what is worth my opinion, I strongly agree to both.
>
> BTW: apart from screenshots texts, search & replace can do miracles on
> all documentation in every language...
>
> --
>
>
> 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] CPolyLine -> SHAPE_POLY_SET refactor

[jp charras]

Le 10/04/2017 à 10:44, Tomasz Wlostowski a écrit :
> On 10.04.2017 09:18, jp charras wrote:
>>
>> Still remains serious issues in GAL mode about self intersecting and 
>> overlapping polygons after
>> creation or edition.
>> These issues exist since the beginning.
>> (They are not too hard to fix, because methods to fix them are written for 
>> the legacy mode, but need
>> a better knowledge I have to correctly manage undo/redo on GAL, due to the 
>> fact the number of
>> existing or new zones can change after cleaning or editing zones)
> 
> I don't think adding automatic zone splitting/merging in the GAL canvas
> (as in the legacy) will fix the problem in the long term, if we take
> into account that we need to import designs done with other tools. All
> of the software I've tried supports overlapping and self-intersecting
> zone outlines - therefore, the files saved by these programs may contain
> zones that Kicad will not handle correctly. Here's the solution I'd propose:
> - overlapping zones: the new connectivity algorithm does that ;-)
> - self-intersecting outlines: split to non-self-intersecting polygon
> when plotting. This way the gerber files exported by Kicad will be
> correct for all possible zone outlines.

Hi Tom,

- overlapping zones:
Should not create issues. This is more a usability problem:
Is it better to keep zones as separate entities, or better to merge them?
Each way has its advantages and drawbacks.

I do not have a strong opinion about overlapping zones (although you really can 
create strange things).

- self-intersecting outlines:
 * Usually create fill issue: just draw a butterfly in GAL and fill it: the 
result is not what one
can expect (only the half area of the zone is filled).
So *currently*, the filling algo need to be modified (a easy fix) but I am not 
sure it is the best way.
 * More strange shapes can be seen if a hole polygon intersects other holes or 
the main outline.
Just add a cutout to a zone, a cutout that breaks the parent zone into 2 zones!
(for instance a rectangular cutout that breaks into 2 separate areas its parent 
rectangular zone.)
The result is broken on GAL, ok on Legacy.
* And what is the meaning of a cutout area much bigger than its parent, and 
overlaps an other zone
bellowing the same net?

I still am of the opinion self intersecting outlines should be converted to non 
intersecting
outlines, and holes merged with main outline: it is much more easy to handle, 
both by code and by
the user.
Otherwise you can create really broken boards.

About plot files, I make a mistake:
only filled areas are plotted and they are strictly simple polygons.
And connectivity algo uses only filled areas.

Importing self intersecting polygons from other programs is a very minor 
problem, easy to fix.
We already fix many other incompatibilities.

> 
> 
>>
>> Note also usability issues in zones pop up menu (missing option to delete a 
>> cutout, and most
>> commands disabled when the zone tool is activated).
> We'll have a look, thanks!

Thanks.

> 
> Cheers,
> Tom
> 


-- 
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] [RFC] Application naming

[Marco Ciampa]

On Thu, Feb 02, 2017 at 05:59:00PM -0500, Chris Pavlina wrote:
> On Thu, Feb 02, 2017 at 11:54:09PM +0100, Kristoffer Ödmark wrote:
> > Why dont keep it dead simple, but still keeping the KiCAD brand?
> > 
> > I suggest prefix every subprogram with kicad- and then use a either
> > extremely well known abbreviation (PCB) or a descriptive english word.
> > 
> > Examples:
> > 
> > eeschema-> kicad-schematics
> > pcbnew  -> kicad-layouts
> > 3d-viewer   -> kicad-3d
> > gerb-viewer -> kicad-gerbers
> > whatever-> kicad-whatever
> > 
> > 
> > Self explaining names that are easy to use standalone as well as names that
> > will not make a new users scoff and works well as binary filenames.
> 
> Yes, I like this. I was talking about the names in the UI, mostly - this
> is a good companion to that.
> 
> > 
> > I really dislike having entirely different names for the binary and the
> > shortcut-key/desktop-shortcut like ubuntu and their decision to have
> > "Document Viewer" as the name for evince etc.
> 
> Agreed.
> 

Sorry for being so late...

For what is worth my opinion, I strongly agree to both.

BTW: apart from screenshots texts, search & replace can do miracles on
all documentation in every language...

--


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

Re: [Kicad-developers] [PATCH] CPolyLine -> SHAPE_POLY_SET refactor

[Cirilo Bernardo]

On Mon, Apr 10, 2017 at 8:44 AM, Tomasz Wlostowski
 wrote:
> On 10.04.2017 09:18, jp charras wrote:
>> Le 10/04/2017 à 08:39, Nick Østergaard a écrit :
>>> Hi JP,
>>>
>>> Yes I can confirm that it seems to work now, but since you mentioned
>>> that it was not fixed properly yet, I thought it was worth
>>> highlighting in this thread. Are unittests missing here for the
>>> geometry library or is this on a higher level?
>>
>> About SEG class, unittests works.
>>
>> It is more the fact when using a SEG class, you can now modify an other 
>> entity without clearly
>> notice in your code the other entity will be modified, by side effect, 
>> because now the SEG class
>> stores a reference to the other entity, not a copy of values.
>>
>> It is this side effect I do not like.
>
> Hi JP & Alessandro,
>
> I agree that keeping references to the points in the SEG class is not
> the very best idea. I would roll back to the original SEG class.
>
>>
>>
>> Still remains serious issues in GAL mode about self intersecting and 
>> overlapping polygons after
>> creation or edition.
>> These issues exist since the beginning.
>> (They are not too hard to fix, because methods to fix them are written for 
>> the legacy mode, but need
>> a better knowledge I have to correctly manage undo/redo on GAL, due to the 
>> fact the number of
>> existing or new zones can change after cleaning or editing zones)
>
> I don't think adding automatic zone splitting/merging in the GAL canvas
> (as in the legacy) will fix the problem in the long term, if we take
> into account that we need to import designs done with other tools. All
> of the software I've tried supports overlapping and self-intersecting
> zone outlines - therefore, the files saved by these programs may contain
> zones that Kicad will not handle correctly. Here's the solution I'd propose:
> - overlapping zones: the new connectivity algorithm does that ;-)
> - self-intersecting outlines: split to non-self-intersecting polygon
> when plotting. This way the gerber files exported by Kicad will be
> correct for all possible zone outlines.
>

I agree with (copying then) splitting self-intersecting zones when plotting;
this is the only simple way to retain the user's original design data while
also meeting the Gerber requirements.

Just for curiosity - do the algorithms know the difference between self-
overlap and self-intersect? For example if we have a snake eating its
tail the result should be a solid ring rather than a ring with a small region
missing due to the overlap region being treated as a hole.

- Cirilo

>
>>
>> Note also usability issues in zones pop up menu (missing option to delete a 
>> cutout, and most
>> commands disabled when the zone tool is activated).
> We'll have a look, thanks!
>
> Cheers,
> Tom
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [PATCH] CPolyLine -> SHAPE_POLY_SET refactor

[Tomasz Wlostowski]

On 10.04.2017 09:18, jp charras wrote:
> Le 10/04/2017 à 08:39, Nick Østergaard a écrit :
>> Hi JP,
>>
>> Yes I can confirm that it seems to work now, but since you mentioned
>> that it was not fixed properly yet, I thought it was worth
>> highlighting in this thread. Are unittests missing here for the
>> geometry library or is this on a higher level?
> 
> About SEG class, unittests works.
> 
> It is more the fact when using a SEG class, you can now modify an other 
> entity without clearly
> notice in your code the other entity will be modified, by side effect, 
> because now the SEG class
> stores a reference to the other entity, not a copy of values.
> 
> It is this side effect I do not like.

Hi JP & Alessandro,

I agree that keeping references to the points in the SEG class is not
the very best idea. I would roll back to the original SEG class.

> 
> 
> Still remains serious issues in GAL mode about self intersecting and 
> overlapping polygons after
> creation or edition.
> These issues exist since the beginning.
> (They are not too hard to fix, because methods to fix them are written for 
> the legacy mode, but need
> a better knowledge I have to correctly manage undo/redo on GAL, due to the 
> fact the number of
> existing or new zones can change after cleaning or editing zones)

I don't think adding automatic zone splitting/merging in the GAL canvas
(as in the legacy) will fix the problem in the long term, if we take
into account that we need to import designs done with other tools. All
of the software I've tried supports overlapping and self-intersecting
zone outlines - therefore, the files saved by these programs may contain
zones that Kicad will not handle correctly. Here's the solution I'd propose:
- overlapping zones: the new connectivity algorithm does that ;-)
- self-intersecting outlines: split to non-self-intersecting polygon
when plotting. This way the gerber files exported by Kicad will be
correct for all possible zone outlines.


> 
> Note also usability issues in zones pop up menu (missing option to delete a 
> cutout, and most
> commands disabled when the zone tool is activated).
We'll have a look, thanks!

Cheers,
Tom

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

Re: [Kicad-developers] [PATCH] CPolyLine -> SHAPE_POLY_SET refactor

[jp charras]

Le 10/04/2017 à 08:39, Nick Østergaard a écrit :
> Hi JP,
> 
> Yes I can confirm that it seems to work now, but since you mentioned
> that it was not fixed properly yet, I thought it was worth
> highlighting in this thread. Are unittests missing here for the
> geometry library or is this on a higher level?

About SEG class, unittests works.

It is more the fact when using a SEG class, you can now modify an other entity 
without clearly
notice in your code the other entity will be modified, by side effect, because 
now the SEG class
stores a reference to the other entity, not a copy of values.

It is this side effect I do not like.

About bugs reports for zones, zones had 3 different bugs:
* The outlines was broken when adding a corner (GAL) due to the SEG class 
change.
* Cutout outlines were incorrectly saved and read in .kicad_pcb files.
* Cutout outlines were incorrectly managed in GAL, when created: they were 
added as main outlines,
not holes in an existing main outline.

Still remains serious issues in GAL mode about self intersecting and 
overlapping polygons after
creation or edition.
These issues exist since the beginning.
(They are not too hard to fix, because methods to fix them are written for the 
legacy mode, but need
a better knowledge I have to correctly manage undo/redo on GAL, due to the fact 
the number of
existing or new zones can change after cleaning or editing zones)

Note also usability issues in zones pop up menu (missing option to delete a 
cutout, and most
commands disabled when the zone tool is activated).

> 
> Nick
> 
> 2017-04-10 8:21 GMT+02:00 jp charras :
>> Le 09/04/2017 à 22:18, Nick Østergaard a écrit :
>>> Hi Alejandro,
>>>
>>> It seems like there is a use case you may not have considered. The zone 
>>> cutout.
>>
>> I am thinking I recently fixed this issue.
>>
>> However I am not thrilled by commit f68ce306bdca0a2f5a1a234497ede6550ca79a0b 
>> for geometry/seg.h
>> Instead of storing coordinates, SEG stores after this commit references to 
>> VECTOR2I of an other entity.
>> It means when you (for some reason) modify a coordinate value in a SEG 
>> instance, you can modify also
>> the other entity, that is not expected.
>> (I saw that when I fixed the zone cutout issues).
>> It was one (but not the only one) reason cutouts did not work.
>>
>> However I am really not satisfied by the way polygon zones are created or 
>> edited in GAL:
>> they can easily be self intersecting (when created or when a corner is moved 
>> or deleted) or overlapping.
>>
>> In Kicad, polygons *cannot be* self intersecting (not accepted in Gerber 
>> files).
>>
>> In Legacy mode, they are tested and modified (break into 2 or more polygons, 
>> and/or merged with
>> similar zones) after each change.
>> This is mandatory to avoid broken zones.
>>
>>>
>>> See https://bugs.launchpad.net/kicad/+bug/1679795
>>>
>>>
>>> 2017-03-24 11:01 GMT+01:00 Maciej Sumiński :
 TL;DR: Everything seems fine, I am going to merge the branch today.

 For the record: I got the board that was showing the differences. I
 refilled zones using the master branch, then once again with the polygon
 refactor patch applied. Diff of zone polygons shows no difference.

 There were differences between the zones in the original file and the
 just refilled, so there could be a change in the filling algorithm in
 the meantime.

 I am going to merge the branch soon. Thank you Alejandro, I know it was
 a rough road, but we are really grateful for your work. Well done!

 Regards,
 Orson

 On 03/23/2017 09:19 AM, Maciej Sumiński wrote:
> Finally I had some time to test the branch and I could not find any
> problems, hence I would like to merge it. Let me know if there are any
> objections.
>
> @Nick:
> Could you give more details? I placed keepout zones and refilled zones
> for all demo boards, and every time I get exactly the same zones (diffed
> two .kicad_pcb files).
>
> Regards,
> Orson
>
> On 02/18/2017 08:13 PM, Nick Østergaard wrote:
>> I have noticed that Alejandro's branch does not have a clearance
>> distance to a keepout zone, which the old filling algorithm has.
>>
>> I am not sure what is really desired, but this could potentially break
>> old designs, although I like the new way where the zone goes to the
>> keepout edge.
>>
>> 2017-02-17 20:24 GMT+01:00 jp charras :
>>> Le 17/02/2017 à 19:41, Alejandro Garcia Montoro a écrit :
 Hi!

 The errors were caused by some asserts that contained functions that 
 needed to be called... My bad.
 Now the asserts are gone and the errors are handled via out_of_range 
 exceptions (they were related
 with possible illegal memory access),

 JP, I finally saw the zone filling error in the release 

Re: [Kicad-developers] [PATCH] CPolyLine -> SHAPE_POLY_SET refactor

[Nick Østergaard]

Hi JP,

Yes I can confrim that it seems to work now, but since you mentioned
that it was not fixed properly yet, I thought it was worth
highlighting in this thread. Are unittests missing here for the
geometry library or is this on a higher level?

Nick

2017-04-10 8:21 GMT+02:00 jp charras :
> Le 09/04/2017 à 22:18, Nick Østergaard a écrit :
>> Hi Alejandro,
>>
>> It seems like there is a use case you may not have considered. The zone 
>> cutout.
>
> I am thinking I recently fixed this issue.
>
> However I am not thrilled by commit f68ce306bdca0a2f5a1a234497ede6550ca79a0b 
> for geometry/seg.h
> Instead of storing coordinates, SEG stores after this commit references to 
> VECTOR2I of an other entity.
> It means when you (for some reason) modify a coordinate value in a SEG 
> instance, you can modify also
> the other entity, that is not expected.
> (I saw that when I fixed the zone cutout issues).
> It was one (but not the only one) reason cutouts did not work.
>
> However I am really not satisfied by the way polygon zones are created or 
> edited in GAL:
> they can easily be self intersecting (when created or when a corner is moved 
> or deleted) or overlapping.
>
> In Kicad, polygons *cannot be* self intersecting (not accepted in Gerber 
> files).
>
> In Legacy mode, they are tested and modified (break into 2 or more polygons, 
> and/or merged with
> similar zones) after each change.
> This is mandatory to avoid broken zones.
>
>>
>> See https://bugs.launchpad.net/kicad/+bug/1679795
>>
>>
>> 2017-03-24 11:01 GMT+01:00 Maciej Sumiński :
>>> TL;DR: Everything seems fine, I am going to merge the branch today.
>>>
>>> For the record: I got the board that was showing the differences. I
>>> refilled zones using the master branch, then once again with the polygon
>>> refactor patch applied. Diff of zone polygons shows no difference.
>>>
>>> There were differences between the zones in the original file and the
>>> just refilled, so there could be a change in the filling algorithm in
>>> the meantime.
>>>
>>> I am going to merge the branch soon. Thank you Alejandro, I know it was
>>> a rough road, but we are really grateful for your work. Well done!
>>>
>>> Regards,
>>> Orson
>>>
>>> On 03/23/2017 09:19 AM, Maciej Sumiński wrote:
 Finally I had some time to test the branch and I could not find any
 problems, hence I would like to merge it. Let me know if there are any
 objections.

 @Nick:
 Could you give more details? I placed keepout zones and refilled zones
 for all demo boards, and every time I get exactly the same zones (diffed
 two .kicad_pcb files).

 Regards,
 Orson

 On 02/18/2017 08:13 PM, Nick Østergaard wrote:
> I have noticed that Alejandro's branch does not have a clearance
> distance to a keepout zone, which the old filling algorithm has.
>
> I am not sure what is really desired, but this could potentially break
> old designs, although I like the new way where the zone goes to the
> keepout edge.
>
> 2017-02-17 20:24 GMT+01:00 jp charras :
>> Le 17/02/2017 à 19:41, Alejandro Garcia Montoro a écrit :
>>> Hi!
>>>
>>> The errors were caused by some asserts that contained functions that 
>>> needed to be called... My bad.
>>> Now the asserts are gone and the errors are handled via out_of_range 
>>> exceptions (they were related
>>> with possible illegal memory access),
>>>
>>> JP, I finally saw the zone filling error in the release build!
>>>
>>> Nick and JP, if you can pull and test the branch again and see if the 
>>> errors you saw are fixed, that
>>> would be great. Thank you.
>>>
>>> Best,
>>> Alejandro
>>
>>
>> At first glance, the issues I previously saw are gone.
>> Thanks.
>>
>>
>> --
>> Jean-Pierre CHARRAS
>
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [PATCH] CPolyLine -> SHAPE_POLY_SET refactor

[jp charras]

Le 09/04/2017 à 22:18, Nick Østergaard a écrit :
> Hi Alejandro,
> 
> It seems like there is a use case you may not have considered. The zone 
> cutout.

I am thinking I recently fixed this issue.

However I am not thrilled by commit f68ce306bdca0a2f5a1a234497ede6550ca79a0b 
for geometry/seg.h
Instead of storing coordinates, SEG stores after this commit references to 
VECTOR2I of an other entity.
It means when you (for some reason) modify a coordinate value in a SEG 
instance, you can modify also
the other entity, that is not expected.
(I saw that when I fixed the zone cutout issues).
It was one (but not the only one) reason cutouts did not work.

However I am really not satisfied by the way polygon zones are created or 
edited in GAL:
they can easily be self intersecting (when created or when a corner is moved or 
deleted) or overlapping.

In Kicad, polygons *cannot be* self intersecting (not accepted in Gerber files).

In Legacy mode, they are tested and modified (break into 2 or more polygons, 
and/or merged with
similar zones) after each change.
This is mandatory to avoid broken zones.

> 
> See https://bugs.launchpad.net/kicad/+bug/1679795
> 
> 
> 2017-03-24 11:01 GMT+01:00 Maciej Sumiński :
>> TL;DR: Everything seems fine, I am going to merge the branch today.
>>
>> For the record: I got the board that was showing the differences. I
>> refilled zones using the master branch, then once again with the polygon
>> refactor patch applied. Diff of zone polygons shows no difference.
>>
>> There were differences between the zones in the original file and the
>> just refilled, so there could be a change in the filling algorithm in
>> the meantime.
>>
>> I am going to merge the branch soon. Thank you Alejandro, I know it was
>> a rough road, but we are really grateful for your work. Well done!
>>
>> Regards,
>> Orson
>>
>> On 03/23/2017 09:19 AM, Maciej Sumiński wrote:
>>> Finally I had some time to test the branch and I could not find any
>>> problems, hence I would like to merge it. Let me know if there are any
>>> objections.
>>>
>>> @Nick:
>>> Could you give more details? I placed keepout zones and refilled zones
>>> for all demo boards, and every time I get exactly the same zones (diffed
>>> two .kicad_pcb files).
>>>
>>> Regards,
>>> Orson
>>>
>>> On 02/18/2017 08:13 PM, Nick Østergaard wrote:
 I have noticed that Alejandro's branch does not have a clearance
 distance to a keepout zone, which the old filling algorithm has.

 I am not sure what is really desired, but this could potentially break
 old designs, although I like the new way where the zone goes to the
 keepout edge.

 2017-02-17 20:24 GMT+01:00 jp charras :
> Le 17/02/2017 à 19:41, Alejandro Garcia Montoro a écrit :
>> Hi!
>>
>> The errors were caused by some asserts that contained functions that 
>> needed to be called... My bad.
>> Now the asserts are gone and the errors are handled via out_of_range 
>> exceptions (they were related
>> with possible illegal memory access),
>>
>> JP, I finally saw the zone filling error in the release build!
>>
>> Nick and JP, if you can pull and test the branch again and see if the 
>> errors you saw are fixed, that
>> would be great. Thank you.
>>
>> Best,
>> Alejandro
>
>
> At first glance, the issues I previously saw are gone.
> Thanks.
>
>
> --
> Jean-Pierre CHARRAS


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