Re: [Kicad-developers] Initial rc6 development.

[Strontium]

+1

On 19/05/18 01:27, Seth Hillbrand wrote:


​I'll second Tom's suggestion here.  Distros are free to package KiCad 
how they like, but we can create an AppImage[1] with GTK2 and 
wxpython​ that users can download from the website.  This would 
provide a way for all users to run KiCad even if their distro doesn't 
package the required libraries.  Bug reports on GTK3 could then be 
redirected to the AppImage download link.


-Seth

[1] https://appimage.org/


Am Fr., 18. Mai 2018 um 08:51 Uhr schrieb Tomasz Wlostowski 
>:


On 18/05/18 17:38, Wayne Stambaugh wrote:
> As we approach the v5 stable release, I want to discuss a
something we
> should seriously consider before we open the flood gates for new
feature
> merges after the v5 branch.  We are currently in an awkward position
> with regards to gtk3 builds on Linux.  Given that most distros
are now
> building wx against gtk3, we really should work towards fixing
this at
> the beginning of v6 and back porting it as soon as possible so
that we
> can better support the current Linux distros. Fortunately, most
distros
> have thankfully provided a gtk2 build version of wx in order to
build
> kicad.  However, they have not done the same thing for wxpython
so for
> most new distro releases, we have to build kicad without wxpython
> support.  I propose we spend some time immediately after the v5
release
> and fix the gtk3 issues before we start making major changes to
the code
> base so that it is not difficult to back port.  Anyone else have any
> thoughts on this?
>

Wayne,

I would put most of the effort on developing the GAL version of
eeschema. It's not our fault that Linux distros change the APIs of
essential system libraries every 2 years. As a short term solution, I
would propose distributing a distro-agnostic binary Kicad package that
includes all dependencies, including wx and gtk2 libraries. In the
longer run, GALified schematic editor is IMHO the way to go.

Best,
Tom



> Cheers,
>
> Wayne
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers

> Post to     : kicad-developers@lists.launchpad.net

> Unsubscribe : https://launchpad.net/~kicad-developers

> More help   : https://help.launchpad.net/ListHelp
>


___
Mailing list: https://launchpad.net/~kicad-developers

Post to     : kicad-developers@lists.launchpad.net

Unsubscribe : https://launchpad.net/~kicad-developers

More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://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] Some speed up patches

[Seth Hillbrand]

OK thanks for the input.  I'll push 1, 2 and 5.

On 4), I didn't think it eliminated checks that were needed.  If the zone
updated, everything was checked as before.  If only a track changed, it
still checks zone->track but doesn't check zone->zone, zone->via or
zone->pad.  Is there a reason that we needed those extra checks?

On 3), I the issues with commutative relationships make sense.  However, I
think that when items are routed such that their anchors overlap, then the
relationship is commutative.  Or do I miss a subtlety here?

Thanks-
Seth

Am Fr., 18. Mai 2018 um 14:23 Uhr schrieb Tomasz Wlostowski <
tomasz.wlostow...@cern.ch>:

> On 18/05/18 20:49, Seth Hillbrand wrote:
> > Gentle ping here.  If this doesn't interfere with your connectivity
> > algorithm work Tom, I'd like to merge these as they make routing the
> > board I'm working on now manageable (at least on my old machine).
>
> Hi Seth,
>
> I'm OK with patches 1, 2 and 5, feel free to merge them. 3 and 4 are
> risky, as they reduce the number of collision checks. The issue with the
> current collision check function(s) is that they are not commutative -
> so intersect(itemA, itemB) may not always be equal to intersect(itemB,
> itemA). That's why some of the dirty item checks were disabled, since
> searching only for dirty items' collisions may not find all colliding
> item pairs.
>
> This happens for instance where zone A has only a single vertex inside
> zone B. Same thing may happen when searching for via/track collisions. I
> would like to definitively fix this in V6 by doing full collision search
> (SHAPE_INDEX-based, as in the P code), but this means changing class
> BOARD to use R-trees and quite a lot of refactoring of existing code.
>
> Cheers,
> Tom
>
> PS. I have an early version of background thread connectivity branch (it
> also includes other speed optimizations). Have a look if you want:
>
> https://github.com/twlostow/kicad-dev/tree/tom-background-connectivity
>
>
___
Mailing list: https://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] Some speed up patches

[Tomasz Wlostowski]

On 18/05/18 20:49, Seth Hillbrand wrote:
> Gentle ping here.  If this doesn't interfere with your connectivity
> algorithm work Tom, I'd like to merge these as they make routing the
> board I'm working on now manageable (at least on my old machine).

Hi Seth,

I'm OK with patches 1, 2 and 5, feel free to merge them. 3 and 4 are
risky, as they reduce the number of collision checks. The issue with the
current collision check function(s) is that they are not commutative -
so intersect(itemA, itemB) may not always be equal to intersect(itemB,
itemA). That's why some of the dirty item checks were disabled, since
searching only for dirty items' collisions may not find all colliding
item pairs.

This happens for instance where zone A has only a single vertex inside
zone B. Same thing may happen when searching for via/track collisions. I
would like to definitively fix this in V6 by doing full collision search
(SHAPE_INDEX-based, as in the P code), but this means changing class
BOARD to use R-trees and quite a lot of refactoring of existing code.

Cheers,
Tom

PS. I have an early version of background thread connectivity branch (it
also includes other speed optimizations). Have a look if you want:

https://github.com/twlostow/kicad-dev/tree/tom-background-connectivity


___
Mailing list: https://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] Initial rc6 development.

[Carsten Schoenert]

Hello Seth,

Am 18.05.2018 um 22:27 schrieb Seth Hillbrand:
> ​Carsten-
> 
> I understand your concern and I think that this is valid.  I am not
> proposing that we ignore distribution decisions (that would be very
> counter-productive!)  And you are right, Debian works extremely well
> with KiCad.
> 
> Ubuntu 18.04, on the other hand is less pleasant.  If we want v5.0 users
> to have wxPython, we need either delay v5 in order to translate SWIG to
> SIP or make an AppImage/Flatpack thing.  Is there another option that
> I'm missing, apart from just ditching wxPython altogether?

Ubuntu is typically pulling packages from Debian testing and modifying
them if needed. So also happen to the KiCad packages from Debian testing
for Bionic. But Kicad on Debian testing is currently broken due the
symbol issues libwxgtk3.0-dev vs. libwxgtk3.0-gtk3-dev. Jeremy Bicha has
tried to fix this by doing a version 4.0.7+dfsg1-1ubuntu2 and has cherry
picked some changes from my current build setup for 5.0.0+rc1. But these
changes are pulling in the GTK+3 library libwxgtk3.0-gtk3 as dependency
for the kicad package. This itself isn't the problem as the root of the
problem is the wxpython package which is only available linked against
GTK+3.

I already would have uploaded the current 5.0.0+rc1 based packages
rebuild against GTK+2 libraries and disabled wxpython usage but right
now I can't build the documentation successfully so I can't upload
anything. The issue isn't the Kicad documentation itself but the current
set of texlive packages in Debian unstable. Ubuntu Bionic has already
disabled the build of documentation in version 4.0.7+dfsg1-1ubuntu1. But
I can't do this for Debian as this is a RC issue.

If someone wants to dig into the issue I posted the current problem on
kicad-doc-devs. I appreciate any help to solve the current build issue.

https://lists.launchpad.net/kicad-doc-devs/msg00128.html

-- 
Regards
Carsten Schoenert

___
Mailing list: https://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] 5.0 RC2 / release status

[Wayne Stambaugh]

Hi Rene,

On 05/18/2018 11:53 AM, Rene Pöschl wrote:
> On 18/05/18 16:44, Wayne Stambaugh wrote:
>> If any of our doc and library devs are on this mailing list, please
>> forward this information so we aren't making major changes to the docs
>> and libraries at the last minute.
>>
> 
> We have one important pull request open that i will fix up my self
> tomorrow if the contributor does not fix the remaining issues him self.
> (Removing duplicate power pins from symbols as this can be quite
> dangerous if the user connects them multiple times.)
> 
> After this is merged i will tag the library with "5.0.0-rc2" (Tomorrow
> evening)
> 
> After this tag is set we will no longer allow renaming of libs until v6
> development. (Adding new libs will still be allowed.)

I'm OK with this.

> 
> I will also create a kicad 4 compatibility backport for this lib. (The
> intention is to allow users to use the new library structure for new
> projects even if they can not update to a nightly build. This should
> reduce their work when they then switch over to kicad 5)
> 
> This backport will contain a reduced number of footprints as footprints
> with custom or roundrect pads are not supported by kicad 4. I will also
> backport the symbol libs. The 3d lib does not need any work in this
> regard but i will still ad a separate release tag to make it easier for
> users. Not sure if i will make a backport of the templates.
> Creating this backport will take some time but i hope to have it done
> one week after the rc2 tag is set.

Awesome!  I'm sure our v4 users will appreciate this.

> 
> 
> Regarding the issue about footprint connection you reported in [1]:
> All symbols that have a valid symbol in the footprint lib are now
> correctly connected. Sadly a lot of symbols still need footprints to be
> generated. (Symbols where in the lib that never had a valid footprint)
> Some of this will be fixed after the rc2 release. This will not impact
> the library structure so i assume we can include these changes in the
> final v5 release. (It will simply add more footprints.)

That fine by me.  If we are going add new symbol libraries during v5, I
don't see any reason not to add new footprints and footprint libraries.
We should try to avoid wholesale renaming and/or moving of libraries and
their contents to avoid headaches for users.  If we have any major
library reorganizations, we can always create a v5 branch as we do for
the KiCad source.

Thank you for all of your hard work on the libraries.  They really have
come a long way since v4 was released.

Cheers,

Wayne

> 
> [1]: https://github.com/KiCad/kicad-symbols/issues/520
> 
> ___
> Mailing list: https://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] Initial rc6 development.

[Seth Hillbrand]

​Carsten-

I understand your concern and I think that this is valid.  I am not
proposing that we ignore distribution decisions (that would be very
counter-productive!)  And you are right, Debian works extremely well with
KiCad.

Ubuntu 18.04, on the other hand is less pleasant.  If we want v5.0 users to
have wxPython, we need either delay v5 in order to translate SWIG to SIP or
make an AppImage/Flatpack thing.  Is there another option that I'm missing,
apart from just ditching wxPython altogether?

-S

Am Fr., 18. Mai 2018 um 12:51 Uhr schrieb Carsten Schoenert <
c.schoen...@t-online.de>:

> Hello Seth,
>
> Am 18.05.2018 um 19:27 schrieb Seth Hillbrand:
> >
> > ​I'll second Tom's suggestion here.  Distros are free to package KiCad
> > how they like, but we can create an AppImage[1] with GTK2 and wxpython​
> > that users can download from the website.  This would provide a way for
> > all users to run KiCad even if their distro doesn't package the required
> > libraries.  Bug reports on GTK3 could then be redirected to the AppImage
> > download link.
>
> please don't try to be clever that way and think twice before KiCad
> upstream will ignoring the decisions that are made by the Linux
> distributions. Such a behavior wouldn't be really distro friendly as
> proposed.
>
> GTK3+ was introduced in 2011 which is seven years from now, so it's not
> that this was changing every two years. And now we have already GTK4+
> available.
>
> Linux distributions are not really amused about shipped releases of
> software which are including embedded libraries as such things are a
> nightmare for supporting such software in a long term because they need
> to do then security fixes not only on the mainly shipped libraries
> packages but also in all package that are included a embedded copy. This
> isn't working really well and costs a lot of energy.
>
> From a Debian view the current state isn't that problematic as maybe
> someone is imagine. It's currently not clear if the dropping of GTK2+ is
> possible for the next release Buster (about one year from now). The
> freeze for the packages is in January 2019, this isn't that far away
> from now. My personal impression is that we will still have GTK2+
> related packages in Buster.
> The current stable release Stretch isn't a problem as the packages and
> versions are frozen.
>
> --
> Regards
> Carsten Schoenert
>
> ___
> Mailing list: https://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] Initial rc6 development.

[Carsten Schoenert]

Hello Seth,

Am 18.05.2018 um 19:27 schrieb Seth Hillbrand:
> 
> ​I'll second Tom's suggestion here.  Distros are free to package KiCad
> how they like, but we can create an AppImage[1] with GTK2 and wxpython​
> that users can download from the website.  This would provide a way for
> all users to run KiCad even if their distro doesn't package the required
> libraries.  Bug reports on GTK3 could then be redirected to the AppImage
> download link.

please don't try to be clever that way and think twice before KiCad
upstream will ignoring the decisions that are made by the Linux
distributions. Such a behavior wouldn't be really distro friendly as
proposed.

GTK3+ was introduced in 2011 which is seven years from now, so it's not
that this was changing every two years. And now we have already GTK4+
available.

Linux distributions are not really amused about shipped releases of
software which are including embedded libraries as such things are a
nightmare for supporting such software in a long term because they need
to do then security fixes not only on the mainly shipped libraries
packages but also in all package that are included a embedded copy. This
isn't working really well and costs a lot of energy.

From a Debian view the current state isn't that problematic as maybe
someone is imagine. It's currently not clear if the dropping of GTK2+ is
possible for the next release Buster (about one year from now). The
freeze for the packages is in January 2019, this isn't that far away
from now. My personal impression is that we will still have GTK2+
related packages in Buster.
The current stable release Stretch isn't a problem as the packages and
versions are frozen.

-- 
Regards
Carsten Schoenert

___
Mailing list: https://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] Some speed up patches

[Thomas Figueroa]

Hey Seth,

I had an issue where the zone wouldn’t refill at all after modification, 
leaving a zone that was visible in outline but not being connected to or filled 
in any way.
I’ll try to replicate it tonight, as I’ve since removed the patches, and give a 
more detailed overview of what I’ve found.

-Thomas



From: Kicad-developers 
 on 
behalf of Seth Hillbrand 
Sent: Friday, May 18, 2018 1:49:14 PM
To: KiCad Developers
Subject: Re: [Kicad-developers] Some speed up patches

Gentle ping here.  If this doesn't interfere with your connectivity algorithm 
work Tom, I'd like to merge these as they make routing the board I'm working on 
now manageable (at least on my old machine).

If you need more time to look it over, no worries.  Just want to make sure it 
doesn't slip through cracks.

Best-
Seth

Am Di., 15. Mai 2018 um 17:23 Uhr schrieb Seth Hillbrand 
>:
​Hi Tomasz (and others if interested)-

I'm attaching some patches to ​the connectivity search.  I know you are looking 
at moving some of this to a background thread 
(https://bugs.launchpad.net/kicad/+bug/1769408)
 so I wanted to make sure that I don't conflict with your work.

Let me know if you see any issues with these patches.

If anyone would like to see the effect of these patches, you can find a 
relatively complex board at 
https://github.com/ciaa/Hardware/tree/master/PCB/ACC/CIAA_ACC
 (60k segments).  The speedup becomes more noticeable as users insert 
additional tuned tracks as these create many small segments for connection.

Thanks-
Seth


___
Mailing list: https://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] Some speed up patches

[Seth Hillbrand]

Gentle ping here.  If this doesn't interfere with your connectivity
algorithm work Tom, I'd like to merge these as they make routing the board
I'm working on now manageable (at least on my old machine).

If you need more time to look it over, no worries.  Just want to make sure
it doesn't slip through cracks.

Best-
Seth

Am Di., 15. Mai 2018 um 17:23 Uhr schrieb Seth Hillbrand <
seth.hillbr...@gmail.com>:

> ​Hi Tomasz (and others if interested)-
>
> I'm attaching some patches to ​the connectivity search.  I know you are
> looking at moving some of this to a background thread (
> https://bugs.launchpad.net/kicad/+bug/1769408) so I wanted to make sure
> that I don't conflict with your work.
>
> Let me know if you see any issues with these patches.
>
> If anyone would like to see the effect of these patches, you can find a
> relatively complex board at
> https://github.com/ciaa/Hardware/tree/master/PCB/ACC/CIAA_ACC (60k
> segments).  The speedup becomes more noticeable as users insert additional
> tuned tracks as these create many small segments for connection.
>
> Thanks-
> Seth
>
>
>
___
Mailing list: https://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] Indeterministic netlist export for multiunit components

[Wayne Stambaugh]

You patch seems like a reasonable approach as an interim fix.  Go ahead
and merge it when you get a chance.

Cheers,

Wayne

On 05/18/2018 10:52 AM, Maciej Sumiński wrote:
> How about my patch? I do not dare to go for the ultimate solution right
> now, but is it acceptable as a stop gap measure for v5?
> 
> Cheers,
> Orson
> 
> On 05/18/2018 03:28 PM, Wayne Stambaugh wrote:
>> The suggestions made are all good and valid but I think to some extent
>> there will always be some ambiguity.  Users being users will make
>> mistakes filling in field data which will cause issues when annotating
>> and generating the netlist.  In complex designs with lots of multiple
>> units symbols it's not always possible to know which units should be
>> grouped together by reference.  More often that not, this cannot be
>> known until board layout time.  This is something that I am all to
>> familiar with because I do lots of designs with several dual and quad
>> op-amps.  I don't think we will ever be able to completely do this
>> without some ambiguity until some type of human brain interface is
>> created to allow us to know what the user wants versus what the user
>> specified.
>>
>> That being said, I suggest we define the behavior we want before we
>> start coding so there is no ambiguity it what we hope to accomplish.  A
>> simple bulleted list would be fine.  Once we define the desired
>> behavior, we should get some user input so that we don't create
>> something that doesn't work well for users.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 05/18/2018 08:44 AM, Jeff Young wrote:
>>> Hi Orson,
>>>
>>> The problem should become less prevalent over time: for 6.0 I plan on 
>>> fixing the multi-sheet undo issues so that we can update all units in 
>>> unison.  (Of course that still fails if you edit before annotating as we 
>>> then don’t know which units go with which.)
>>>
>>> But I agree that anytime we have a non-matching field across units it looks 
>>> like a bug to the user.  Your proposal is certainly an improvement in that 
>>> regard.
>>>
>>> I think the one thing that would be left would be to flag unit field 
>>> mismatches when annotating (or perhaps even try and group units by matching 
>>> their fields).  But that carries enough risk to relegate it to 6.0 along 
>>> with the undo stuff.
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>
 On 18 May 2018, at 12:16, Sergey A. Borshch  
 wrote:

 On 18.05.2018 11:14, Maciej Sumiński wrote:
> Hi,
> Recently I have found out that the netlist exporter uses an algorithm
> that for multiunit components uses non empty field values from the last
> processed unit [1]. The problem is that the processing order depends on
> the order of the units in the item list, so completely random.
 I want to remind that there is another bug in netlist generator related to 
 units processing order: https://bugs.launchpad.net/bugs/1704083

> Instead, I propose we try to get all field values from the first
> available unit (e.g. unit A), and resort to other units only if there
> are any fields left empty.
>
> To give an example of what can go wrong with such approach: recently I
> generated BOM and assembly documentation, where unit A had 'Mounted'
> field set to 'No'. I was surprised to find out that in the generated
> output it has been marked as mounted, as the unit B had 'Yes' set for
> the field. I would qualify it as a bug, but I seek your input before I
> proceed with pushing my changes. See my proposal in the attached patch.
 I think there no need in Artificial Intelligence while generating netlist 
 from incorrect schematics, but all fields in component units must be 
 consistent instead. I mean that changing in schematics editor any field in 
 one unit must also change same field in other units with same RefDes. 
 Automatic annotation must take into account all fields values and assign 
 different RefDes to units which differs with fields values.
 One more proposal - manual RefDes change shoud not be allowed with 
 appropriate warning if unit(s) with new RefDes already exist in schematics 
 and belongs to another component type or has different fields value(s). It 
 would be best helpful if warning message will show that units belongs to 
 different component types or which field value differs if component type 
 is the same.


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

Re: [Kicad-developers] Initial rc6 development.

[Jeff Young]

I still think we should do the full canvas + toolset for 6.0…

… or are we thinking we might port just the canvas change back to 5.0.1?

>> …

>> So my question is:
>> It is possible to use the GAL itself (restricted to the graphic layer), and 
>> keep the current
>> wxWidget management events in eeschema and page layout editor (although the 
>> graphics in pl_editor
>> are so basic we can redraw the full screen without any optimization each 
>> time a object is moving).
> 
> Hi JP,
> 
> Yes, it should be possible with some modifications to the current event
> handling code (mostly removing XOR draw calls). I have partly written a
> GAL canvas renderer for eeschema some time ago, let me dig it up and
> post it on Github.
> 
> Tom
> 
>> 
>>> 
>>> Best,
>>> Tom
>>> 
>>> 
>>> 
 Cheers,
 
 Wayne
>> 
>> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Initial rc6 development.

[Wayne Stambaugh]

For stable releases, I am not thrilled about steering users towards
appimage, flatpak, snap, etc type solutions.  They are fine for nightly
builds for users who want to run multiple versions.

On 05/18/2018 01:27 PM, Seth Hillbrand wrote:
> 
> ​I'll second Tom's suggestion here.  Distros are free to package KiCad
> how they like, but we can create an AppImage[1] with GTK2 and wxpython​
> that users can download from the website.  This would provide a way for
> all users to run KiCad even if their distro doesn't package the required
> libraries.  Bug reports on GTK3 could then be redirected to the AppImage
> download link.
> 
> -Seth
> 
> [1] https://appimage.org/
> 
> 
> Am Fr., 18. Mai 2018 um 08:51 Uhr schrieb Tomasz Wlostowski
> >:
> 
> On 18/05/18 17:38, Wayne Stambaugh wrote:
> > As we approach the v5 stable release, I want to discuss a something we
> > should seriously consider before we open the flood gates for new
> feature
> > merges after the v5 branch.  We are currently in an awkward position
> > with regards to gtk3 builds on Linux.  Given that most distros are now
> > building wx against gtk3, we really should work towards fixing this at
> > the beginning of v6 and back porting it as soon as possible so that we
> > can better support the current Linux distros.  Fortunately, most
> distros
> > have thankfully provided a gtk2 build version of wx in order to build
> > kicad.  However, they have not done the same thing for wxpython so for
> > most new distro releases, we have to build kicad without wxpython
> > support.  I propose we spend some time immediately after the v5
> release
> > and fix the gtk3 issues before we start making major changes to
> the code
> > base so that it is not difficult to back port.  Anyone else have any
> > thoughts on this?
> >
> 
> Wayne,
> 
> I would put most of the effort on developing the GAL version of
> eeschema. It's not our fault that Linux distros change the APIs of
> essential system libraries every 2 years. As a short term solution, I
> would propose distributing a distro-agnostic binary Kicad package that
> includes all dependencies, including wx and gtk2 libraries. In the
> longer run, GALified schematic editor is IMHO the way to go.
> 
> Best,
> Tom
> 
> 
> 
> > Cheers,
> >
> > Wayne
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@lists.launchpad.net
> 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://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] Initial rc6 development.

[Wayne Stambaugh]

On 05/18/2018 12:49 PM, Tomasz Wlostowski wrote:
> On 18/05/18 18:42, jp charras wrote:
>> Le 18/05/2018 à 17:51, Tomasz Wlostowski a écrit :
>>> On 18/05/18 17:38, Wayne Stambaugh wrote:
 As we approach the v5 stable release, I want to discuss a something we
 should seriously consider before we open the flood gates for new feature
 merges after the v5 branch.  We are currently in an awkward position
 with regards to gtk3 builds on Linux.  Given that most distros are now
 building wx against gtk3, we really should work towards fixing this at
 the beginning of v6 and back porting it as soon as possible so that we
 can better support the current Linux distros.  Fortunately, most distros
 have thankfully provided a gtk2 build version of wx in order to build
 kicad.  However, they have not done the same thing for wxpython so for
 most new distro releases, we have to build kicad without wxpython
 support.  I propose we spend some time immediately after the v5 release
 and fix the gtk3 issues before we start making major changes to the code
 base so that it is not difficult to back port.  Anyone else have any
 thoughts on this?

>>>
>>> Wayne,
>>>
>>> I would put most of the effort on developing the GAL version of
>>> eeschema. It's not our fault that Linux distros change the APIs of
>>> essential system libraries every 2 years. As a short term solution, I
>>> would propose distributing a distro-agnostic binary Kicad package that
>>> includes all dependencies, including wx and gtk2 libraries. In the
>>> longer run, GALified schematic editor is IMHO the way to go.
>>
>> Hi Tom,
>>
>> When we are talking about GAL, we are actually talking about 2 different 
>> things:
>> 1 - the GAL itself, that is the graphic part of "GAL"
>> 2 - the new event management, that has nothing to do with the graphic layer 
>> itself.
>>
>> Using the new event management could be a much more amount of work than 
>> writing the  graphic layer
>> code only.
>>
>> So my question is:
>> It is possible to use the GAL itself (restricted to the graphic layer), and 
>> keep the current
>> wxWidget management events in eeschema and page layout editor (although the 
>> graphics in pl_editor
>> are so basic we can redraw the full screen without any optimization each 
>> time a object is moving).
> 
> Hi JP,
> 
> Yes, it should be possible with some modifications to the current event
> handling code (mostly removing XOR draw calls). I have partly written a
> GAL canvas renderer for eeschema some time ago, let me dig it up and
> post it on Github.
> 
> Tom

How did you did code this?  I would think that it would be possible to
use a wxBitmapDC to draw upon and then blit it to the actual hardware
device context without any changes to drawing code (any thing derived
from wxDC can be passed to the drawing code).  This certainly would be
faster than drawing directly to the hardware device context.  The tricky
part with this in the past was getting the viewable area correct.  This
is how the legacy canvas in gerbview works (or at least it used to work
that way because rendering directly to the hardware device context was
too slow).

> 
>>
>>>
>>> Best,
>>> Tom
>>>
>>>
>>>
 Cheers,

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

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

Re: [Kicad-developers] Initial rc6 development.

[Wayne Stambaugh]

On 05/18/2018 01:13 PM, Jeff Young wrote:
> I still think we should do the full canvas + toolset for 6.0…
> 
> … or are we thinking we might port just the canvas change back to 5.0.1?

I think back porting the gtk3 fixes to v5 is going to become more
important pretty quickly.  Most linux distros are already shipping gtk3
builds of wx and I don't see them supporting gtk2 forever.  I don't want
to be in a place where we are spending time maintaining a gtk2 build
just so we can have a workable solution on linux.  In the end, we will
have to support gtk3 even without the rendering issues.  I'm not sure
these wont be more problematic than the rendering.

> 
>>> …
> 
>>> So my question is:
>>> It is possible to use the GAL itself (restricted to the graphic
>>> layer), and keep the current
>>> wxWidget management events in eeschema and page layout editor
>>> (although the graphics in pl_editor
>>> are so basic we can redraw the full screen without any optimization
>>> each time a object is moving).
>>
>> Hi JP,
>>
>> Yes, it should be possible with some modifications to the current event
>> handling code (mostly removing XOR draw calls). I have partly written a
>> GAL canvas renderer for eeschema some time ago, let me dig it up and
>> post it on Github.
>>
>> Tom
>>
>>>

 Best,
 Tom



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

___
Mailing list: https://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] Initial rc6 development.

[Seth Hillbrand]

​I'll second Tom's suggestion here.  Distros are free to package KiCad how
they like, but we can create an AppImage[1] with GTK2 and wxpython​ that
users can download from the website.  This would provide a way for all
users to run KiCad even if their distro doesn't package the required
libraries.  Bug reports on GTK3 could then be redirected to the AppImage
download link.

-Seth

[1] https://appimage.org/


Am Fr., 18. Mai 2018 um 08:51 Uhr schrieb Tomasz Wlostowski <
tomasz.wlostow...@cern.ch>:

> On 18/05/18 17:38, Wayne Stambaugh wrote:
> > As we approach the v5 stable release, I want to discuss a something we
> > should seriously consider before we open the flood gates for new feature
> > merges after the v5 branch.  We are currently in an awkward position
> > with regards to gtk3 builds on Linux.  Given that most distros are now
> > building wx against gtk3, we really should work towards fixing this at
> > the beginning of v6 and back porting it as soon as possible so that we
> > can better support the current Linux distros.  Fortunately, most distros
> > have thankfully provided a gtk2 build version of wx in order to build
> > kicad.  However, they have not done the same thing for wxpython so for
> > most new distro releases, we have to build kicad without wxpython
> > support.  I propose we spend some time immediately after the v5 release
> > and fix the gtk3 issues before we start making major changes to the code
> > base so that it is not difficult to back port.  Anyone else have any
> > thoughts on this?
> >
>
> Wayne,
>
> I would put most of the effort on developing the GAL version of
> eeschema. It's not our fault that Linux distros change the APIs of
> essential system libraries every 2 years. As a short term solution, I
> would propose distributing a distro-agnostic binary Kicad package that
> includes all dependencies, including wx and gtk2 libraries. In the
> longer run, GALified schematic editor is IMHO the way to go.
>
> Best,
> Tom
>
>
>
> > Cheers,
> >
> > Wayne
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://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] Initial rc6 development.

[Tomasz Wlostowski]

On 18/05/18 18:42, jp charras wrote:
> Le 18/05/2018 à 17:51, Tomasz Wlostowski a écrit :
>> On 18/05/18 17:38, Wayne Stambaugh wrote:
>>> As we approach the v5 stable release, I want to discuss a something we
>>> should seriously consider before we open the flood gates for new feature
>>> merges after the v5 branch.  We are currently in an awkward position
>>> with regards to gtk3 builds on Linux.  Given that most distros are now
>>> building wx against gtk3, we really should work towards fixing this at
>>> the beginning of v6 and back porting it as soon as possible so that we
>>> can better support the current Linux distros.  Fortunately, most distros
>>> have thankfully provided a gtk2 build version of wx in order to build
>>> kicad.  However, they have not done the same thing for wxpython so for
>>> most new distro releases, we have to build kicad without wxpython
>>> support.  I propose we spend some time immediately after the v5 release
>>> and fix the gtk3 issues before we start making major changes to the code
>>> base so that it is not difficult to back port.  Anyone else have any
>>> thoughts on this?
>>>
>>
>> Wayne,
>>
>> I would put most of the effort on developing the GAL version of
>> eeschema. It's not our fault that Linux distros change the APIs of
>> essential system libraries every 2 years. As a short term solution, I
>> would propose distributing a distro-agnostic binary Kicad package that
>> includes all dependencies, including wx and gtk2 libraries. In the
>> longer run, GALified schematic editor is IMHO the way to go.
> 
> Hi Tom,
> 
> When we are talking about GAL, we are actually talking about 2 different 
> things:
> 1 - the GAL itself, that is the graphic part of "GAL"
> 2 - the new event management, that has nothing to do with the graphic layer 
> itself.
> 
> Using the new event management could be a much more amount of work than 
> writing the  graphic layer
> code only.
> 
> So my question is:
> It is possible to use the GAL itself (restricted to the graphic layer), and 
> keep the current
> wxWidget management events in eeschema and page layout editor (although the 
> graphics in pl_editor
> are so basic we can redraw the full screen without any optimization each time 
> a object is moving).

Hi JP,

Yes, it should be possible with some modifications to the current event
handling code (mostly removing XOR draw calls). I have partly written a
GAL canvas renderer for eeschema some time ago, let me dig it up and
post it on Github.

Tom

> 
>>
>> Best,
>> Tom
>>
>>
>>
>>> Cheers,
>>>
>>> Wayne
> 
> 


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

Re: [Kicad-developers] Initial rc6 development.

[jp charras]

Le 18/05/2018 à 17:51, Tomasz Wlostowski a écrit :
> On 18/05/18 17:38, Wayne Stambaugh wrote:
>> As we approach the v5 stable release, I want to discuss a something we
>> should seriously consider before we open the flood gates for new feature
>> merges after the v5 branch.  We are currently in an awkward position
>> with regards to gtk3 builds on Linux.  Given that most distros are now
>> building wx against gtk3, we really should work towards fixing this at
>> the beginning of v6 and back porting it as soon as possible so that we
>> can better support the current Linux distros.  Fortunately, most distros
>> have thankfully provided a gtk2 build version of wx in order to build
>> kicad.  However, they have not done the same thing for wxpython so for
>> most new distro releases, we have to build kicad without wxpython
>> support.  I propose we spend some time immediately after the v5 release
>> and fix the gtk3 issues before we start making major changes to the code
>> base so that it is not difficult to back port.  Anyone else have any
>> thoughts on this?
>>
> 
> Wayne,
> 
> I would put most of the effort on developing the GAL version of
> eeschema. It's not our fault that Linux distros change the APIs of
> essential system libraries every 2 years. As a short term solution, I
> would propose distributing a distro-agnostic binary Kicad package that
> includes all dependencies, including wx and gtk2 libraries. In the
> longer run, GALified schematic editor is IMHO the way to go.

Hi Tom,

When we are talking about GAL, we are actually talking about 2 different things:
1 - the GAL itself, that is the graphic part of "GAL"
2 - the new event management, that has nothing to do with the graphic layer 
itself.

Using the new event management could be a much more amount of work than writing 
the  graphic layer
code only.

So my question is:
It is possible to use the GAL itself (restricted to the graphic layer), and 
keep the current
wxWidget management events in eeschema and page layout editor (although the 
graphics in pl_editor
are so basic we can redraw the full screen without any optimization each time a 
object is moving).

> 
> Best,
> Tom
> 
> 
> 
>> Cheers,
>>
>> Wayne


-- 
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] Initial rc6 development.

[Nick Østergaard]

As far ad I understand it SWIG and SIP are not compatible, so sonethung is
needed to transition to SIP, but given wxpython is pushing phoenix thay is
what we need to do, and with that we also gain gtk3 support.

fre. 18. maj 2018 18.13 skrev Wayne Stambaugh :

> On 05/18/2018 12:02 PM, Nick Østergaard wrote:
> > For wxpython, we "just" need to upgrade to phoenix, which supports gtk3.
>
> Has this been verified on all platforms?  I thought there were issues
> with our use of swig and the use of sip by the phoenix project.  If it's
> a drop in, all the better.
>
> >
> > 2018-05-18 18:01 GMT+02:00 Wayne Stambaugh  > >:
> >
> > Hi Tom,
> >
> >
> > On 05/18/2018 11:51 AM, Tomasz Wlostowski wrote:
> >
> > On 18/05/18 17:38, Wayne Stambaugh wrote:
> >
> > As we approach the v5 stable release, I want to discuss a
> > something we
> > should seriously consider before we open the flood gates for
> > new feature
> > merges after the v5 branch.  We are currently in an awkward
> > position
> > with regards to gtk3 builds on Linux.  Given that most
> > distros are now
> > building wx against gtk3, we really should work towards
> > fixing this at
> > the beginning of v6 and back porting it as soon as possible
> > so that we
> > can better support the current Linux distros.  Fortunately,
> > most distros
> > have thankfully provided a gtk2 build version of wx in order
> > to build
> > kicad.  However, they have not done the same thing for
> > wxpython so for
> > most new distro releases, we have to build kicad without
> > wxpython
> > support.  I propose we spend some time immediately after the
> > v5 release
> > and fix the gtk3 issues before we start making major changes
> > to the code
> > base so that it is not difficult to back port.  Anyone else
> > have any
> > thoughts on this?
> >
> >
> > Wayne,
> >
> > I would put most of the effort on developing the GAL version of
> > eeschema. It's not our fault that Linux distros change the APIs
> of
> > essential system libraries every 2 years. As a short term
> > solution, I
> > would propose distributing a distro-agnostic binary Kicad
> > package that
> > includes all dependencies, including wx and gtk2 libraries. In
> the
> > longer run, GALified schematic editor is IMHO the way to go.
> >
> > Best,
> > Tom
> >
> >
> > This still doesn't address the wxpython issue or the fact that v5
> > will always have to support gtk2.  Given our current stable release
> > turnover, it could (will?) be a few years before v6 is released.  It
> > also doesn't address the fact that the legacy canvas in eeschema
> > which will be part of v6 will require gtk2.  While a agree that this
> > is going to be a PITA, I just don't see how we can avoid it.
> >
> >
> >
> >
> >
> > Cheers,
> >
> > Wayne
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > 
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > 
> > More help   : https://help.launchpad.net/ListHelp
> > 
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > 
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > 
> > More help   : https://help.launchpad.net/ListHelp
> > 
> >
> >
>
___
Mailing list: https://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] Initial rc6 development.

[Wayne Stambaugh]

On 05/18/2018 12:02 PM, Nick Østergaard wrote:
> For wxpython, we "just" need to upgrade to phoenix, which supports gtk3.

Has this been verified on all platforms?  I thought there were issues
with our use of swig and the use of sip by the phoenix project.  If it's
a drop in, all the better.

> 
> 2018-05-18 18:01 GMT+02:00 Wayne Stambaugh  >:
> 
> Hi Tom,
> 
> 
> On 05/18/2018 11:51 AM, Tomasz Wlostowski wrote:
> 
> On 18/05/18 17:38, Wayne Stambaugh wrote:
> 
> As we approach the v5 stable release, I want to discuss a
> something we
> should seriously consider before we open the flood gates for
> new feature
> merges after the v5 branch.  We are currently in an awkward
> position
> with regards to gtk3 builds on Linux.  Given that most
> distros are now
> building wx against gtk3, we really should work towards
> fixing this at
> the beginning of v6 and back porting it as soon as possible
> so that we
> can better support the current Linux distros.  Fortunately,
> most distros
> have thankfully provided a gtk2 build version of wx in order
> to build
> kicad.  However, they have not done the same thing for
> wxpython so for
> most new distro releases, we have to build kicad without
> wxpython
> support.  I propose we spend some time immediately after the
> v5 release
> and fix the gtk3 issues before we start making major changes
> to the code
> base so that it is not difficult to back port.  Anyone else
> have any
> thoughts on this?
> 
> 
> Wayne,
> 
> I would put most of the effort on developing the GAL version of
> eeschema. It's not our fault that Linux distros change the APIs of
> essential system libraries every 2 years. As a short term
> solution, I
> would propose distributing a distro-agnostic binary Kicad
> package that
> includes all dependencies, including wx and gtk2 libraries. In the
> longer run, GALified schematic editor is IMHO the way to go.
> 
> Best,
> Tom
> 
> 
> This still doesn't address the wxpython issue or the fact that v5
> will always have to support gtk2.  Given our current stable release
> turnover, it could (will?) be a few years before v6 is released.  It
> also doesn't address the fact that the legacy canvas in eeschema
> which will be part of v6 will require gtk2.  While a agree that this
> is going to be a PITA, I just don't see how we can avoid it.
> 
> 
> 
> 
> 
> Cheers,
> 
> Wayne
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 

___
Mailing list: https://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] Initial rc6 development.

[Nick Østergaard]

For wxpython, we "just" need to upgrade to phoenix, which supports gtk3.

2018-05-18 18:01 GMT+02:00 Wayne Stambaugh :

> Hi Tom,
>
>
> On 05/18/2018 11:51 AM, Tomasz Wlostowski wrote:
>
>> On 18/05/18 17:38, Wayne Stambaugh wrote:
>>
>>> As we approach the v5 stable release, I want to discuss a something we
>>> should seriously consider before we open the flood gates for new feature
>>> merges after the v5 branch.  We are currently in an awkward position
>>> with regards to gtk3 builds on Linux.  Given that most distros are now
>>> building wx against gtk3, we really should work towards fixing this at
>>> the beginning of v6 and back porting it as soon as possible so that we
>>> can better support the current Linux distros.  Fortunately, most distros
>>> have thankfully provided a gtk2 build version of wx in order to build
>>> kicad.  However, they have not done the same thing for wxpython so for
>>> most new distro releases, we have to build kicad without wxpython
>>> support.  I propose we spend some time immediately after the v5 release
>>> and fix the gtk3 issues before we start making major changes to the code
>>> base so that it is not difficult to back port.  Anyone else have any
>>> thoughts on this?
>>>
>>>
>> Wayne,
>>
>> I would put most of the effort on developing the GAL version of
>> eeschema. It's not our fault that Linux distros change the APIs of
>> essential system libraries every 2 years. As a short term solution, I
>> would propose distributing a distro-agnostic binary Kicad package that
>> includes all dependencies, including wx and gtk2 libraries. In the
>> longer run, GALified schematic editor is IMHO the way to go.
>>
>> Best,
>> Tom
>>
>
> This still doesn't address the wxpython issue or the fact that v5 will
> always have to support gtk2.  Given our current stable release turnover, it
> could (will?) be a few years before v6 is released.  It also doesn't
> address the fact that the legacy canvas in eeschema which will be part of
> v6 will require gtk2.  While a agree that this is going to be a PITA, I
> just don't see how we can avoid it.
>
>
>
>>
>>
>> Cheers,
>>>
>>> Wayne
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://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] Initial rc6 development.

[Wayne Stambaugh]

Hi Tom,

On 05/18/2018 11:51 AM, Tomasz Wlostowski wrote:

On 18/05/18 17:38, Wayne Stambaugh wrote:

As we approach the v5 stable release, I want to discuss a something we
should seriously consider before we open the flood gates for new feature
merges after the v5 branch.  We are currently in an awkward position
with regards to gtk3 builds on Linux.  Given that most distros are now
building wx against gtk3, we really should work towards fixing this at
the beginning of v6 and back porting it as soon as possible so that we
can better support the current Linux distros.  Fortunately, most distros
have thankfully provided a gtk2 build version of wx in order to build
kicad.  However, they have not done the same thing for wxpython so for
most new distro releases, we have to build kicad without wxpython
support.  I propose we spend some time immediately after the v5 release
and fix the gtk3 issues before we start making major changes to the code
base so that it is not difficult to back port.  Anyone else have any
thoughts on this?



Wayne,

I would put most of the effort on developing the GAL version of
eeschema. It's not our fault that Linux distros change the APIs of
essential system libraries every 2 years. As a short term solution, I
would propose distributing a distro-agnostic binary Kicad package that
includes all dependencies, including wx and gtk2 libraries. In the
longer run, GALified schematic editor is IMHO the way to go.

Best,
Tom


This still doesn't address the wxpython issue or the fact that v5 will 
always have to support gtk2.  Given our current stable release turnover, 
it could (will?) be a few years before v6 is released.  It also doesn't 
address the fact that the legacy canvas in eeschema which will be part 
of v6 will require gtk2.  While a agree that this is going to be a PITA, 
I just don't see how we can avoid it.







Cheers,

Wayne


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





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

Re: [Kicad-developers] 5.0 RC2 / release status

[Rene Pöschl]

On 18/05/18 16:44, Wayne Stambaugh wrote:

If any of our doc and library devs are on this mailing list, please
forward this information so we aren't making major changes to the docs
and libraries at the last minute.



We have one important pull request open that i will fix up my self 
tomorrow if the contributor does not fix the remaining issues him self. 
(Removing duplicate power pins from symbols as this can be quite 
dangerous if the user connects them multiple times.)


After this is merged i will tag the library with "5.0.0-rc2" (Tomorrow 
evening)


After this tag is set we will no longer allow renaming of libs until v6 
development. (Adding new libs will still be allowed.)


I will also create a kicad 4 compatibility backport for this lib. (The 
intention is to allow users to use the new library structure for new 
projects even if they can not update to a nightly build. This should 
reduce their work when they then switch over to kicad 5)


This backport will contain a reduced number of footprints as footprints 
with custom or roundrect pads are not supported by kicad 4. I will also 
backport the symbol libs. The 3d lib does not need any work in this 
regard but i will still ad a separate release tag to make it easier for 
users. Not sure if i will make a backport of the templates.
Creating this backport will take some time but i hope to have it done 
one week after the rc2 tag is set.



Regarding the issue about footprint connection you reported in [1]:
All symbols that have a valid symbol in the footprint lib are now 
correctly connected. Sadly a lot of symbols still need footprints to be 
generated. (Symbols where in the lib that never had a valid footprint)
Some of this will be fixed after the rc2 release. This will not impact 
the library structure so i assume we can include these changes in the 
final v5 release. (It will simply add more footprints.)


[1]: https://github.com/KiCad/kicad-symbols/issues/520

___
Mailing list: https://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] Initial rc6 development.

[Tomasz Wlostowski]

On 18/05/18 17:38, Wayne Stambaugh wrote:
> As we approach the v5 stable release, I want to discuss a something we
> should seriously consider before we open the flood gates for new feature
> merges after the v5 branch.  We are currently in an awkward position
> with regards to gtk3 builds on Linux.  Given that most distros are now
> building wx against gtk3, we really should work towards fixing this at
> the beginning of v6 and back porting it as soon as possible so that we
> can better support the current Linux distros.  Fortunately, most distros
> have thankfully provided a gtk2 build version of wx in order to build
> kicad.  However, they have not done the same thing for wxpython so for
> most new distro releases, we have to build kicad without wxpython
> support.  I propose we spend some time immediately after the v5 release
> and fix the gtk3 issues before we start making major changes to the code
> base so that it is not difficult to back port.  Anyone else have any
> thoughts on this?
> 

Wayne,

I would put most of the effort on developing the GAL version of
eeschema. It's not our fault that Linux distros change the APIs of
essential system libraries every 2 years. As a short term solution, I
would propose distributing a distro-agnostic binary Kicad package that
includes all dependencies, including wx and gtk2 libraries. In the
longer run, GALified schematic editor is IMHO the way to go.

Best,
Tom



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


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

Re: [Kicad-developers] Indeterministic netlist export for multiunit components

[jp charras]

Le 18/05/2018 à 17:35, Kristoffer Ödmark a écrit :
> I think another stop gap measure is to have the ERC handle this, but 
> otherwise I am for Orson's patch. 

This is also my opinion.
And Orson's patch is very acceptable.

> 
> Better a defined bad behavior than an undefined random behavior is my opinion 
> :)
> 
> On Fri, May 18, 2018, 16:53 Maciej Sumiński  > wrote:
> 
> How about my patch? I do not dare to go for the ultimate solution right
> now, but is it acceptable as a stop gap measure for v5?
> 
> Cheers,
> Orson
> 
> On 05/18/2018 03:28 PM, Wayne Stambaugh wrote:
> > The suggestions made are all good and valid but I think to some extent
> > there will always be some ambiguity.  Users being users will make
> > mistakes filling in field data which will cause issues when annotating
> > and generating the netlist.  In complex designs with lots of multiple
> > units symbols it's not always possible to know which units should be
> > grouped together by reference.  More often that not, this cannot be
> > known until board layout time.  This is something that I am all to
> > familiar with because I do lots of designs with several dual and quad
> > op-amps.  I don't think we will ever be able to completely do this
> > without some ambiguity until some type of human brain interface is
> > created to allow us to know what the user wants versus what the user
> > specified.
> >
> > That being said, I suggest we define the behavior we want before we
> > start coding so there is no ambiguity it what we hope to accomplish.  A
> > simple bulleted list would be fine.  Once we define the desired
> > behavior, we should get some user input so that we don't create
> > something that doesn't work well for users.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 05/18/2018 08:44 AM, Jeff Young wrote:
> >> Hi Orson,
> >>
> >> The problem should become less prevalent over time: for 6.0 I plan on 
> fixing the multi-sheet
> undo issues so that we can update all units in unison.  (Of course that 
> still fails if you edit
> before annotating as we then don’t know which units go with which.)
> >>
> >> But I agree that anytime we have a non-matching field across units it 
> looks like a bug to the
> user.  Your proposal is certainly an improvement in that regard.
> >>
> >> I think the one thing that would be left would be to flag unit field 
> mismatches when
> annotating (or perhaps even try and group units by matching their 
> fields).  But that carries
> enough risk to relegate it to 6.0 along with the undo stuff.
> >>
> >> Cheers,
> >> Jeff.
> >>
> >>
> >>> On 18 May 2018, at 12:16, Sergey A. Borshch 
>  > wrote:
> >>>
> >>> On 18.05.2018 11:14, Maciej Sumiński wrote:
>  Hi,
>  Recently I have found out that the netlist exporter uses an algorithm
>  that for multiunit components uses non empty field values from the 
> last
>  processed unit [1]. The problem is that the processing order depends 
> on
>  the order of the units in the item list, so completely random.
> >>> I want to remind that there is another bug in netlist generator 
> related to units processing
> order: https://bugs.launchpad.net/bugs/1704083
> >>>
>  Instead, I propose we try to get all field values from the first
>  available unit (e.g. unit A), and resort to other units only if there
>  are any fields left empty.
> 
>  To give an example of what can go wrong with such approach: recently 
> I
>  generated BOM and assembly documentation, where unit A had 'Mounted'
>  field set to 'No'. I was surprised to find out that in the generated
>  output it has been marked as mounted, as the unit B had 'Yes' set for
>  the field. I would qualify it as a bug, but I seek your input before 
> I
>  proceed with pushing my changes. See my proposal in the attached 
> patch.
> >>> I think there no need in Artificial Intelligence while generating 
> netlist from incorrect
> schematics, but all fields in component units must be consistent instead. 
> I mean that changing
> in schematics editor any field in one unit must also change same field in 
> other units with same
> RefDes. Automatic annotation must take into account all fields values and 
> assign different
> RefDes to units which differs with fields values.
> >>> One more proposal - manual RefDes change shoud not be allowed with 
> appropriate warning if
> unit(s) with new RefDes already exist in schematics and belongs to 
> another component type or has
> different fields value(s). It would be best helpful if warning message 
> will show 

[Kicad-developers] Initial rc6 development.

[Wayne Stambaugh]

As we approach the v5 stable release, I want to discuss a something we
should seriously consider before we open the flood gates for new feature
merges after the v5 branch.  We are currently in an awkward position
with regards to gtk3 builds on Linux.  Given that most distros are now
building wx against gtk3, we really should work towards fixing this at
the beginning of v6 and back porting it as soon as possible so that we
can better support the current Linux distros.  Fortunately, most distros
have thankfully provided a gtk2 build version of wx in order to build
kicad.  However, they have not done the same thing for wxpython so for
most new distro releases, we have to build kicad without wxpython
support.  I propose we spend some time immediately after the v5 release
and fix the gtk3 issues before we start making major changes to the code
base so that it is not difficult to back port.  Anyone else have any
thoughts on this?

Cheers,

Wayne


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

Re: [Kicad-developers] Indeterministic netlist export for multiunit components

[Kristoffer Ödmark]

I think another stop gap measure is to have the ERC handle this, but
otherwise I am for Orsons patch.

Better a defined bad behavior than an undefined random behavior is my
opinion :)

On Fri, May 18, 2018, 16:53 Maciej Sumiński  wrote:

> How about my patch? I do not dare to go for the ultimate solution right
> now, but is it acceptable as a stop gap measure for v5?
>
> Cheers,
> Orson
>
> On 05/18/2018 03:28 PM, Wayne Stambaugh wrote:
> > The suggestions made are all good and valid but I think to some extent
> > there will always be some ambiguity.  Users being users will make
> > mistakes filling in field data which will cause issues when annotating
> > and generating the netlist.  In complex designs with lots of multiple
> > units symbols it's not always possible to know which units should be
> > grouped together by reference.  More often that not, this cannot be
> > known until board layout time.  This is something that I am all to
> > familiar with because I do lots of designs with several dual and quad
> > op-amps.  I don't think we will ever be able to completely do this
> > without some ambiguity until some type of human brain interface is
> > created to allow us to know what the user wants versus what the user
> > specified.
> >
> > That being said, I suggest we define the behavior we want before we
> > start coding so there is no ambiguity it what we hope to accomplish.  A
> > simple bulleted list would be fine.  Once we define the desired
> > behavior, we should get some user input so that we don't create
> > something that doesn't work well for users.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 05/18/2018 08:44 AM, Jeff Young wrote:
> >> Hi Orson,
> >>
> >> The problem should become less prevalent over time: for 6.0 I plan on
> fixing the multi-sheet undo issues so that we can update all units in
> unison.  (Of course that still fails if you edit before annotating as we
> then don’t know which units go with which.)
> >>
> >> But I agree that anytime we have a non-matching field across units it
> looks like a bug to the user.  Your proposal is certainly an improvement in
> that regard.
> >>
> >> I think the one thing that would be left would be to flag unit field
> mismatches when annotating (or perhaps even try and group units by matching
> their fields).  But that carries enough risk to relegate it to 6.0 along
> with the undo stuff.
> >>
> >> Cheers,
> >> Jeff.
> >>
> >>
> >>> On 18 May 2018, at 12:16, Sergey A. Borshch <
> sb...@users.sourceforge.net> wrote:
> >>>
> >>> On 18.05.2018 11:14, Maciej Sumiński wrote:
>  Hi,
>  Recently I have found out that the netlist exporter uses an algorithm
>  that for multiunit components uses non empty field values from the
> last
>  processed unit [1]. The problem is that the processing order depends
> on
>  the order of the units in the item list, so completely random.
> >>> I want to remind that there is another bug in netlist generator
> related to units processing order: https://bugs.launchpad.net/bugs/1704083
> >>>
>  Instead, I propose we try to get all field values from the first
>  available unit (e.g. unit A), and resort to other units only if there
>  are any fields left empty.
> 
>  To give an example of what can go wrong with such approach: recently I
>  generated BOM and assembly documentation, where unit A had 'Mounted'
>  field set to 'No'. I was surprised to find out that in the generated
>  output it has been marked as mounted, as the unit B had 'Yes' set for
>  the field. I would qualify it as a bug, but I seek your input before I
>  proceed with pushing my changes. See my proposal in the attached
> patch.
> >>> I think there no need in Artificial Intelligence while generating
> netlist from incorrect schematics, but all fields in component units must
> be consistent instead. I mean that changing in schematics editor any field
> in one unit must also change same field in other units with same RefDes.
> Automatic annotation must take into account all fields values and assign
> different RefDes to units which differs with fields values.
> >>> One more proposal - manual RefDes change shoud not be allowed with
> appropriate warning if unit(s) with new RefDes already exist in schematics
> and belongs to another component type or has different fields value(s). It
> would be best helpful if warning message will show that units belongs to
> different component types or which field value differs if component type is
> the same.
> >>>
> >>>
> >>> --
> >>> 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
> >>
> 

Re: [Kicad-developers] 5.0 RC2 / release status

[Adam Wolf]

MacOS is not 100% ready to go, but the large technical hurdles appear
to be past us.  Today I am working on adding OCE, which is a bit of a
pain, but the massive Python packaging rework is building solidly and
ngspice was just added.

If anyone is interested in helping with the macOS packaging, there are
a good handful of issues in the github repository that just require
someone who knows KiCad to download a dmg, install it, run KiCad, and
check that something works, and maybe write a few sentences on how to
verify that that feature works.

https://github.com/wayneandlayne/kicad-mac-builder/issues

Adam Wolf

On Fri, May 18, 2018 at 9:44 AM, Wayne Stambaugh  wrote:
> Hey Jon,
>
> A really nasty bug[1] was putting rc2 on hold.  The commit to fix it was
> just made yesterday.  I was just getting ready to make a last call so
> hear goes.
>
> I plan on tagging rc2 on Sunday evening barring any more show stoppers.
> I have one last bug to fix (template paths) which I should get done by
> today or tomorrow.  If anyone else has any bug fixes for rc2, please get
> them committed by then.  Once rc2 is tagged, the UI string freeze is
> officially in place.  No further UI string changes will be accepted
> except for spelling errors until after v5 is released.  The goal is to
> give our translators time to finish up the translations for v5 release.
> Hopefully this will take less than a month.
>
> Where do we stand on the package front?  Is macos packaging ready to go?
>  The goal would be to have everything ready to go within a week or two
> of tagging and branching v5.
>
> If any of our doc and library devs are on this mailing list, please
> forward this information so we aren't making major changes to the docs
> and libraries at the last minute.
>
> Thank you to everyone for all of your hard work.  Your efforts are
> greatly appreciated.
>
> Cheers,
>
> Wayne
>
> [1]: https://bugs.launchpad.net/kicad/+bug/1767826
>
> On 5/18/2018 10:29 AM, Jon Evans wrote:
>> Hi all,
>>
>> I've been mostly away from KiCad recently due to other things going on
>> in life, but I have been trying to follow the mailing list at least.
>> Seems like progress towards a RC2 release may have stalled, but it's not
>> clear why.  Meanwhile lots of small changes continue to go in to master
>> (I don't think that's necessarily a bad thing but I wonder whether or
>> not we know what the critical path is to RC2)
>>
>> Where do we stand / if someone like me has a few hours somewhere to push
>> on something, what is the most valuable area to look at?
>>
>> -Jon
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> Mailing list: https://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] Indeterministic netlist export for multiunit components

[Maciej Sumiński]

How about my patch? I do not dare to go for the ultimate solution right
now, but is it acceptable as a stop gap measure for v5?

Cheers,
Orson

On 05/18/2018 03:28 PM, Wayne Stambaugh wrote:
> The suggestions made are all good and valid but I think to some extent
> there will always be some ambiguity.  Users being users will make
> mistakes filling in field data which will cause issues when annotating
> and generating the netlist.  In complex designs with lots of multiple
> units symbols it's not always possible to know which units should be
> grouped together by reference.  More often that not, this cannot be
> known until board layout time.  This is something that I am all to
> familiar with because I do lots of designs with several dual and quad
> op-amps.  I don't think we will ever be able to completely do this
> without some ambiguity until some type of human brain interface is
> created to allow us to know what the user wants versus what the user
> specified.
> 
> That being said, I suggest we define the behavior we want before we
> start coding so there is no ambiguity it what we hope to accomplish.  A
> simple bulleted list would be fine.  Once we define the desired
> behavior, we should get some user input so that we don't create
> something that doesn't work well for users.
> 
> Cheers,
> 
> Wayne
> 
> On 05/18/2018 08:44 AM, Jeff Young wrote:
>> Hi Orson,
>>
>> The problem should become less prevalent over time: for 6.0 I plan on fixing 
>> the multi-sheet undo issues so that we can update all units in unison.  (Of 
>> course that still fails if you edit before annotating as we then don’t know 
>> which units go with which.)
>>
>> But I agree that anytime we have a non-matching field across units it looks 
>> like a bug to the user.  Your proposal is certainly an improvement in that 
>> regard.
>>
>> I think the one thing that would be left would be to flag unit field 
>> mismatches when annotating (or perhaps even try and group units by matching 
>> their fields).  But that carries enough risk to relegate it to 6.0 along 
>> with the undo stuff.
>>
>> Cheers,
>> Jeff.
>>
>>
>>> On 18 May 2018, at 12:16, Sergey A. Borshch  
>>> wrote:
>>>
>>> On 18.05.2018 11:14, Maciej Sumiński wrote:
 Hi,
 Recently I have found out that the netlist exporter uses an algorithm
 that for multiunit components uses non empty field values from the last
 processed unit [1]. The problem is that the processing order depends on
 the order of the units in the item list, so completely random.
>>> I want to remind that there is another bug in netlist generator related to 
>>> units processing order: https://bugs.launchpad.net/bugs/1704083
>>>
 Instead, I propose we try to get all field values from the first
 available unit (e.g. unit A), and resort to other units only if there
 are any fields left empty.

 To give an example of what can go wrong with such approach: recently I
 generated BOM and assembly documentation, where unit A had 'Mounted'
 field set to 'No'. I was surprised to find out that in the generated
 output it has been marked as mounted, as the unit B had 'Yes' set for
 the field. I would qualify it as a bug, but I seek your input before I
 proceed with pushing my changes. See my proposal in the attached patch.
>>> I think there no need in Artificial Intelligence while generating netlist 
>>> from incorrect schematics, but all fields in component units must be 
>>> consistent instead. I mean that changing in schematics editor any field in 
>>> one unit must also change same field in other units with same RefDes. 
>>> Automatic annotation must take into account all fields values and assign 
>>> different RefDes to units which differs with fields values.
>>> One more proposal - manual RefDes change shoud not be allowed with 
>>> appropriate warning if unit(s) with new RefDes already exist in schematics 
>>> and belongs to another component type or has different fields value(s). It 
>>> would be best helpful if warning message will show that units belongs to 
>>> different component types or which field value differs if component type is 
>>> the same.
>>>
>>>
>>> -- 
>>> 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
>>
> 
> ___
> Mailing list: 

Re: [Kicad-developers] 5.0 RC2 / release status

[Wayne Stambaugh]

Hey Jon,

A really nasty bug[1] was putting rc2 on hold.  The commit to fix it was
just made yesterday.  I was just getting ready to make a last call so
hear goes.

I plan on tagging rc2 on Sunday evening barring any more show stoppers.
I have one last bug to fix (template paths) which I should get done by
today or tomorrow.  If anyone else has any bug fixes for rc2, please get
them committed by then.  Once rc2 is tagged, the UI string freeze is
officially in place.  No further UI string changes will be accepted
except for spelling errors until after v5 is released.  The goal is to
give our translators time to finish up the translations for v5 release.
Hopefully this will take less than a month.

Where do we stand on the package front?  Is macos packaging ready to go?
 The goal would be to have everything ready to go within a week or two
of tagging and branching v5.

If any of our doc and library devs are on this mailing list, please
forward this information so we aren't making major changes to the docs
and libraries at the last minute.

Thank you to everyone for all of your hard work.  Your efforts are
greatly appreciated.

Cheers,

Wayne

[1]: https://bugs.launchpad.net/kicad/+bug/1767826

On 5/18/2018 10:29 AM, Jon Evans wrote:
> Hi all,
> 
> I've been mostly away from KiCad recently due to other things going on
> in life, but I have been trying to follow the mailing list at least. 
> Seems like progress towards a RC2 release may have stalled, but it's not
> clear why.  Meanwhile lots of small changes continue to go in to master
> (I don't think that's necessarily a bad thing but I wonder whether or
> not we know what the critical path is to RC2)
> 
> Where do we stand / if someone like me has a few hours somewhere to push
> on something, what is the most valuable area to look at?
> 
> -Jon
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://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] 5.0 RC2 / release status

[Maciej Sumiński]

Hi Jon,

Welcome back! There was one very serious issue [1] blocking RC2, but
fortunately it was fixed yesterday. Looking at the to-do list for v5
[2], there are three minor issues and two more serious bugs that may
need some extra data from the reporters. It would be great to have the
former two bugs closed for the final release, but I suppose we are ok
for RC2. At least it would get us some extra testing eyes.

Regards,
Orson

1. https://bugs.launchpad.net/kicad/+bug/1767826
2. https://launchpad.net/kicad/+milestone/5.0.0-rc2

On 05/18/2018 04:29 PM, Jon Evans wrote:
> Hi all,
> 
> I've been mostly away from KiCad recently due to other things going on in
> life, but I have been trying to follow the mailing list at least.  Seems
> like progress towards a RC2 release may have stalled, but it's not clear
> why.  Meanwhile lots of small changes continue to go in to master (I don't
> think that's necessarily a bad thing but I wonder whether or not we know
> what the critical path is to RC2)
> 
> Where do we stand / if someone like me has a few hours somewhere to push on
> something, what is the most valuable area to look at?
> 
> -Jon
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://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] 5.0 RC2 / release status

[Jon Evans]

Hi all,

I've been mostly away from KiCad recently due to other things going on in
life, but I have been trying to follow the mailing list at least.  Seems
like progress towards a RC2 release may have stalled, but it's not clear
why.  Meanwhile lots of small changes continue to go in to master (I don't
think that's necessarily a bad thing but I wonder whether or not we know
what the critical path is to RC2)

Where do we stand / if someone like me has a few hours somewhere to push on
something, what is the most valuable area to look at?

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

Re: [Kicad-developers] Another dialog preview

[Wayne Stambaugh]

Nice work.  This looks great!

I wouldn't worry too much about the out of process apps.  I suppose you
could set up a file watcher in both kicad and the out of process app to
update the preferences when the configuration or hotkey files change but
that may be more work than it's worth.

On 05/18/2018 05:21 AM, Jeff Young wrote:
> I should mention one caveat:  there’s a lot of preferences-specific code for 
> getting/setting the various properties (they’re not all tied directly to 
> wxConfigBase items), which means the panel implementations depend on 
> application-specific code.
> 
> When the preferences dialog is opened it automatically shows “Common” and 
> “Hotkeys”, but the rest will depend on the currently running (in-process) 
> applications.
> 
> Gerbview and the PageLayout editor appear to be always run in their own 
> processes, so they always appear on their own (with Common and Hotkeys).
> 
> Cheers,
> Jeff.
> ___
> Mailing list: https://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] Indeterministic netlist export for multiunit components

[Wayne Stambaugh]

The suggestions made are all good and valid but I think to some extent
there will always be some ambiguity.  Users being users will make
mistakes filling in field data which will cause issues when annotating
and generating the netlist.  In complex designs with lots of multiple
units symbols it's not always possible to know which units should be
grouped together by reference.  More often that not, this cannot be
known until board layout time.  This is something that I am all to
familiar with because I do lots of designs with several dual and quad
op-amps.  I don't think we will ever be able to completely do this
without some ambiguity until some type of human brain interface is
created to allow us to know what the user wants versus what the user
specified.

That being said, I suggest we define the behavior we want before we
start coding so there is no ambiguity it what we hope to accomplish.  A
simple bulleted list would be fine.  Once we define the desired
behavior, we should get some user input so that we don't create
something that doesn't work well for users.

Cheers,

Wayne

On 05/18/2018 08:44 AM, Jeff Young wrote:
> Hi Orson,
> 
> The problem should become less prevalent over time: for 6.0 I plan on fixing 
> the multi-sheet undo issues so that we can update all units in unison.  (Of 
> course that still fails if you edit before annotating as we then don’t know 
> which units go with which.)
> 
> But I agree that anytime we have a non-matching field across units it looks 
> like a bug to the user.  Your proposal is certainly an improvement in that 
> regard.
> 
> I think the one thing that would be left would be to flag unit field 
> mismatches when annotating (or perhaps even try and group units by matching 
> their fields).  But that carries enough risk to relegate it to 6.0 along with 
> the undo stuff.
> 
> Cheers,
> Jeff.
> 
> 
>> On 18 May 2018, at 12:16, Sergey A. Borshch  
>> wrote:
>>
>> On 18.05.2018 11:14, Maciej Sumiński wrote:
>>> Hi,
>>> Recently I have found out that the netlist exporter uses an algorithm
>>> that for multiunit components uses non empty field values from the last
>>> processed unit [1]. The problem is that the processing order depends on
>>> the order of the units in the item list, so completely random.
>> I want to remind that there is another bug in netlist generator related to 
>> units processing order: https://bugs.launchpad.net/bugs/1704083
>>
>>> Instead, I propose we try to get all field values from the first
>>> available unit (e.g. unit A), and resort to other units only if there
>>> are any fields left empty.
>>>
>>> To give an example of what can go wrong with such approach: recently I
>>> generated BOM and assembly documentation, where unit A had 'Mounted'
>>> field set to 'No'. I was surprised to find out that in the generated
>>> output it has been marked as mounted, as the unit B had 'Yes' set for
>>> the field. I would qualify it as a bug, but I seek your input before I
>>> proceed with pushing my changes. See my proposal in the attached patch.
>> I think there no need in Artificial Intelligence while generating netlist 
>> from incorrect schematics, but all fields in component units must be 
>> consistent instead. I mean that changing in schematics editor any field in 
>> one unit must also change same field in other units with same RefDes. 
>> Automatic annotation must take into account all fields values and assign 
>> different RefDes to units which differs with fields values.
>> One more proposal - manual RefDes change shoud not be allowed with 
>> appropriate warning if unit(s) with new RefDes already exist in schematics 
>> and belongs to another component type or has different fields value(s). It 
>> would be best helpful if warning message will show that units belongs to 
>> different component types or which field value differs if component type is 
>> the same.
>>
>>
>> -- 
>> 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
> 

___
Mailing list: https://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] Indeterministic netlist export for multiunit components

[Jeff Young]

Hi Orson,

The problem should become less prevalent over time: for 6.0 I plan on fixing 
the multi-sheet undo issues so that we can update all units in unison.  (Of 
course that still fails if you edit before annotating as we then don’t know 
which units go with which.)

But I agree that anytime we have a non-matching field across units it looks 
like a bug to the user.  Your proposal is certainly an improvement in that 
regard.

I think the one thing that would be left would be to flag unit field mismatches 
when annotating (or perhaps even try and group units by matching their fields). 
 But that carries enough risk to relegate it to 6.0 along with the undo stuff.

Cheers,
Jeff.


> On 18 May 2018, at 12:16, Sergey A. Borshch  
> wrote:
> 
> On 18.05.2018 11:14, Maciej Sumiński wrote:
>> Hi,
>> Recently I have found out that the netlist exporter uses an algorithm
>> that for multiunit components uses non empty field values from the last
>> processed unit [1]. The problem is that the processing order depends on
>> the order of the units in the item list, so completely random.
> I want to remind that there is another bug in netlist generator related to 
> units processing order: https://bugs.launchpad.net/bugs/1704083
> 
>> Instead, I propose we try to get all field values from the first
>> available unit (e.g. unit A), and resort to other units only if there
>> are any fields left empty.
> >
>> To give an example of what can go wrong with such approach: recently I
>> generated BOM and assembly documentation, where unit A had 'Mounted'
>> field set to 'No'. I was surprised to find out that in the generated
>> output it has been marked as mounted, as the unit B had 'Yes' set for
>> the field. I would qualify it as a bug, but I seek your input before I
>> proceed with pushing my changes. See my proposal in the attached patch.
> I think there no need in Artificial Intelligence while generating netlist 
> from incorrect schematics, but all fields in component units must be 
> consistent instead. I mean that changing in schematics editor any field in 
> one unit must also change same field in other units with same RefDes. 
> Automatic annotation must take into account all fields values and assign 
> different RefDes to units which differs with fields values.
> One more proposal - manual RefDes change shoud not be allowed with 
> appropriate warning if unit(s) with new RefDes already exist in schematics 
> and belongs to another component type or has different fields value(s). It 
> would be best helpful if warning message will show that units belongs to 
> different component types or which field value differs if component type is 
> the same.
> 
> 
> -- 
> 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] Indeterministic netlist export for multiunit components

[Sergey A. Borshch]

On 18.05.2018 11:14, Maciej Sumiński wrote:

Hi,

Recently I have found out that the netlist exporter uses an algorithm
that for multiunit components uses non empty field values from the last
processed unit [1]. The problem is that the processing order depends on
the order of the units in the item list, so completely random.
I want to remind that there is another bug in netlist generator related to units 
processing order: https://bugs.launchpad.net/bugs/1704083



Instead, I propose we try to get all field values from the first
available unit (e.g. unit A), and resort to other units only if there
are any fields left empty.

>

To give an example of what can go wrong with such approach: recently I
generated BOM and assembly documentation, where unit A had 'Mounted'
field set to 'No'. I was surprised to find out that in the generated
output it has been marked as mounted, as the unit B had 'Yes' set for
the field. I would qualify it as a bug, but I seek your input before I
proceed with pushing my changes. See my proposal in the attached patch.
I think there no need in Artificial Intelligence while generating netlist from 
incorrect schematics, but all fields in component units must be consistent 
instead. I mean that changing in schematics editor any field in one unit must 
also change same field in other units with same RefDes. Automatic annotation 
must take into account all fields values and assign different RefDes to units 
which differs with fields values.
 One more proposal - manual RefDes change shoud not be allowed with appropriate 
warning if unit(s) with new RefDes already exist in schematics and belongs to 
another component type or has different fields value(s). It would be best 
helpful if warning message will show that units belongs to different component 
types or which field value differs if component type is the same.



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

Re: [Kicad-developers] Another dialog preview

[Jeff Young]

I should mention one caveat:  there’s a lot of preferences-specific code for 
getting/setting the various properties (they’re not all tied directly to 
wxConfigBase items), which means the panel implementations depend on 
application-specific code.

When the preferences dialog is opened it automatically shows “Common” and 
“Hotkeys”, but the rest will depend on the currently running (in-process) 
applications.

Gerbview and the PageLayout editor appear to be always run in their own 
processes, so they always appear on their own (with Common and Hotkeys).

Cheers,
Jeff.
___
Mailing list: https://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] Indeterministic netlist export for multiunit components

[Maciej Sumiński]

Hi,

Recently I have found out that the netlist exporter uses an algorithm
that for multiunit components uses non empty field values from the last
processed unit [1]. The problem is that the processing order depends on
the order of the units in the item list, so completely random.

Instead, I propose we try to get all field values from the first
available unit (e.g. unit A), and resort to other units only if there
are any fields left empty.

To give an example of what can go wrong with such approach: recently I
generated BOM and assembly documentation, where unit A had 'Mounted'
field set to 'No'. I was surprised to find out that in the generated
output it has been marked as mounted, as the unit B had 'Yes' set for
the field. I would qualify it as a bug, but I seek your input before I
proceed with pushing my changes. See my proposal in the attached patch.

There is a discussion regarding sharing the field values among all units
[2], but I see there is a technical problem preventing such solution
right now.

Cheers,
Orson

1.
https://github.com/KiCad/kicad-source-mirror/blob/master/eeschema/netlist_exporters/netlist_exporter_generic.cpp#L94
2. https://bugs.launchpad.net/bugs/1765771
From 6ee2a072853de33ab72e5874998bb2b49f22c981 Mon Sep 17 00:00:00 2001
From: Maciej Suminski 
Date: Thu, 17 May 2018 17:10:26 +0200
Subject: [PATCH] Deterministic algorithm for picking field values in multiunit
 components

The original algorithm picked the value from the last component having
non empty value for a given field, but the processing order was
dependent on the layout of the components in the memory. It means that
for each component, the field values could have been taken from any
unit, randomly.

The patch improves the algorithm, trying to get all values from the unit
with the lowest number and resorts to other units only when there are
field values left empty.
---
 .../netlist_exporters/netlist_exporter_generic.cpp | 31 ++
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/eeschema/netlist_exporters/netlist_exporter_generic.cpp b/eeschema/netlist_exporters/netlist_exporter_generic.cpp
index 9556b2a22..2cf4cbc06 100644
--- a/eeschema/netlist_exporters/netlist_exporter_generic.cpp
+++ b/eeschema/netlist_exporters/netlist_exporter_generic.cpp
@@ -91,17 +91,18 @@ void NETLIST_EXPORTER_GENERIC::addComponentFields( XNODE* xcomp, SCH_COMPONENT*
 {
 if( comp->GetUnitCount() > 1 )
 {
-// Sadly, each unit of a component can have its own unique fields.  This block
-// finds the last non blank field and records it.  Last guy wins and the order
-// of units occuring in a schematic hierarchy is variable.  Therefore user
-// is best off setting fields into only one unit.  But this scavenger algorithm
-// will find any non blank fields in all units and use the last non-blank field
+// Sadly, each unit of a component can have its own unique fields. This
+// block finds the unit with the lowest number having a non blank field
+// value and records it.  Therefore user is best off setting fields
+// into only the first unit.  But this scavenger algorithm will find
+// any non blank fields in all units and use the first non-blank field
 // for each unique field name.
 
 COMP_FIELDS fields;
 wxStringref = comp->GetRef( aSheet );
 
 SCH_SHEET_LIST sheetList( g_RootSheet );
+int minUnit = comp->GetUnit();
 
 for( unsigned i = 0;  i < sheetList.size();  i++ )
 {
@@ -117,26 +118,34 @@ void NETLIST_EXPORTER_GENERIC::addComponentFields( XNODE* xcomp, SCH_COMPONENT*
 if( ref2.CmpNoCase( ref ) != 0 )
 continue;
 
-// The last guy wins.  User should only set fields in any one unit.
+int unit = comp2->GetUnit();
+
+// The lowest unit number wins.  User should only set fields in any one unit.
 // remark: IsVoid() returns true for empty strings or the "~" string (empty field value)
-if( !comp2->GetField( VALUE )->IsVoid() )
+if( !comp2->GetField( VALUE )->IsVoid()
+&& ( unit < minUnit || fields.value.IsEmpty() ) )
 fields.value = comp2->GetField( VALUE )->GetText();
 
-if( !comp2->GetField( FOOTPRINT )->IsVoid() )
+if( !comp2->GetField( FOOTPRINT )->IsVoid()
+&& ( unit < minUnit || fields.footprint.IsEmpty() ) )
 fields.footprint = comp2->GetField( FOOTPRINT )->GetText();
 
-if( !comp2->GetField( DATASHEET )->IsVoid() )
+if( !comp2->GetField( DATASHEET )->IsVoid()
+&& ( unit < minUnit || fields.datasheet.IsEmpty() ) )
 fields.datasheet = comp2->GetField( DATASHEET )->GetText();
 
 for( int fldNdx = 

Re: [Kicad-developers] Another dialog preview

[Maciej Sumiński]

Nice, this is how a modern settings dialog should look like!

Cheers,
Orson

On 05/17/2018 04:41 PM, Jeff Young wrote:
> Just thought I’d share something from my 6.0 tree:
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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