Re: [Kicad-developers] Internal units in the KiCAD source code

[Thomas Pointhuber]

Hi Wayne,

I think, I was present at FOSDEM 2019 when talking about this issue.

From what I understand, the current approach requires KiCad to compile
the units for each package separately (because e.g. mapping IU<->mm is
always different). This has two big problems:

1. the same code has to be compiled multiple times.
2. there is no "true" mapping from IU to other units. When I for example
want to create a python API with one type of geometric primitives, this
is a real problem. When I want to script into eeschema and pcbnew at the
same time, how to choose the correct units?

The solution discussed was to move to 64bit and to use
constexpr/templates handling unit conversion. So a programmer can for
example enter 2mm and the compiler automatically converts it into the
internal unit like nm.

I'm still in favour of improving this. The same with angles.

Regards,
Thomas


Am 13.02.20 um 15:46 schrieb Wayne Stambaugh:
> Hi Johannes,
> 
> Thank you for your suggestion but the internal units for each format
> were chosen for a specific reason.  There really is no justifiable
> reason to change them as they have been carefully selected based on the
> requirements of the objects they represent.  Conversion code is provided
> for each internal unit so plotting to standard units such as
> millimeters, inches, etc is trivial.  I'm not opposed to adding support
> for changing the plot units.  I am opposed to changing the internal units.
> 
> Cheers,
> 
> Wayne
> 
> On 2/13/20 9:32 AM, Johannes Pfister wrote:
>> The KiCAD code uses all kinds of different units for distances.
>> Amongst other things I found:
>>   nm: pcbnew internal units
>>   10nm: Gerbview internal units
>>   100nm EEschema internal units
>>   1um: PL-Editor internal units
>>   0.1mil (2.54um): SetViewport
>>   1mil (25.4 um): WS_DRAW_ITEM_BASE and GetSizeMils
>> And the native File formats use mm (pcbnew) and mil (EEschema).
>> Something like SVG exports in 0.1 mil steps. I think that this is not
>> very consistent and something like a PLOTTER class needs to handle
>> different IU-sizes.
>>
>> My idea is to rewrite the internal units so that nm are used
>> everywhere inside the source code, and only parts that write or read
>> files and display data to or read data from the user should convert it
>> to another unit system. I don't want to change any file formats.
>> That would make it a bit more straightforward, more consistent, metric
>> and an SVG-Plotter would use a metric step size. The disadvantage
>> would be that there would be an about 2m or 4m limit in every
>> direction, assuming int is 32 bit, which is AFAIK true for all
>> platforms KiCAD current supports.
>>
>> Before i rewrite code, can you say what you guys think about it?
>>
>>
>> Johannes Pfister
>>
>> ___
>> Mailing list: https://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
> 



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

Re: [Kicad-developers] KiCad Assembly at 36C3

[Thomas Pointhuber]

Hi Carlo,

From last year, I know there are many KiCad interested persons, but only
a handful of people involved in the project itself. It would be nice
enough to organize a meetup where more than 4 people show up (compared
to 34c3).

Personally, I plan to do a "KiCad Beginner Workshop" again this year.
Last year was quite successful with around 200 participants.

https://events.ccc.de/congress/2018/wiki/index.php/Session:KiCad_Beginner_Workshop

Regards,
Thomas


Am 19.11.19 um 10:41 schrieb Carlo Maragno:
> Hi All,
> 
> The congress is getting close, I think we should consider the
> opportunity for a KiCad assembly [1].
> It would be cool to have a space to discuss about KiCad related topics
> and to show off our latest KiCad made projects.
> 
> I can volunteer to register the assembly on the Congress platform, but
> to do so a rough estimation of the people involved is needed. If you are
> interested just reply to this email.
> 
> Of course Wayne and the other lead developers think this is an
> especially bad idea please tell me. I will just be sad :'(
> 
> Carlo
> 
> [1]https://events.ccc.de/category/assemblies/#eng-call-for-assemblies
> 
> ___
> Mailing list: https://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

Re: [Kicad-developers] GitLab migration

[Thomas Pointhuber]

Hi,

if you are curious, Antonio Vázquez Blanco designed a example
ci-pipeline for gitlab. (you need to have a gitlab account to view it):

https://gitlab.com/kicad-mirror/kicad-source-mirror/tree/feature/gitlab-ci

It automatically creates Appimages for example.

Personally, I would really like it to have a continious delivery
pipeline integrated, which is able to create all the different
packages/deployment binaries.

Regards,
Thomas

Am 10.10.19 um 02:30 schrieb Andrew Lutsenko:
> Hi all,
> 
> Gitlab migration with it's proper support for CI/CD and merge requests
> can not come fast enough, I'm very excited that the move is planned.
> I've been using home-hosted gitlab instance for a while now and it's
> useful even for a single developer operation, it will be a lot more
> beneficial for a big project like KiCad. 
> 
> In terms of issues migration I think moving open issues via script and
> locking down launchpad tracker is the best option. Even if migrated
> issues and comments on them will be owned by some service account/bot.
> It should be doable to include enough information there so that it's
> clear who originally posted it and the context is not lost.
> 
> Regards,
> Andrew
> 
> 
> On Wed, Oct 9, 2019 at 4:36 PM Wayne Stambaugh  > wrote:
> 
> On 10/9/19 3:32 PM, Mark Roszko wrote:
> >>  I've applied for an open source GitLab license.  Assuming we get
> > accepted,
> >
> > Technically not required for now. The license just unlocks extra
> > features but the base free feature set is more than adequate for now.
> 
> I prefer some of the extra permission features that the license gives us
> over the free version.  I suspect we will be approved long before 5.1.5
> is released.
> 
> >
> >
> >>Would it be possible to migrate open bug reports to GitLab?  I suspect
> >>we could come up with a script like we did when we migrated from
> >>SourceForge.
> >
> > Basically, yes and no. You can copy the content of issues over no
> > problem. You cannot copy over the authors of comments and posts. It'll
> > have to done under some fake/throwaway user account for migration as
> > it'll become owner of them all.
> 
> If it's too problematic, I'm fine with leaving existing bug reports in
> Launchpad.  Not sure what to do with the open reports other than let
> them expire.
> 
> >
> >
> >>What to do about the mailing list?  GitLab doesn't support mailing
> lists
> >>yet so I'm thinking we leave the mailing list on Launchpad for the
> short
> >>term.  We can always migrate the mailing list at a later date or use
> >>some other communication tool such as discourse.
> >
> > Someone was adding mailing list functionality to GitLab a few
> months ago
> > but the PRs been sitting for a few months.
> > Yes, either a forum or google groups would be an alternative. 
> >
> > A forum can be inviting to the most inexperienced users. But because I
> > that I would say an absolute minimum is there must some level of
> > segregation to prevent developers being flooded with tech support.
> 
> That is one of the shortcomings of using a forum.  However, with
> adequate moderation (i.e. no support for non-development issues), it
> does provide a richer communication environment than a mailing list.  I
> don't have a strong preference one way or the other.  I was just
> throwing it out there as an alternative.
> 
> >
> >
> > On Wed, Oct 9, 2019 at 12:36 PM Wayne Stambaugh
> mailto:stambau...@gmail.com>
> > >> wrote:
> >
> >     The lead development team has been discussing migrating the KiCad
> >     project to GitLab[1].  Given the issues with Launchpad, I
> think this is
> >     a good move.  I've applied for an open source GitLab license. 
> Assuming
> >     we get accepted, I would like to start this process after the
> 5.1.5
> >     release.  Here is a short list of action items that need to be
> done for
> >     the source repo transition:
> >
> >     * Freeze the Launchpad source repo.
> >     * Push the frozen repo to GitLab.
> >     * Disable the Launcpad bug tracker.
> >     * Add a note and link to the Launcpad project page that the
> project is
> >     now hosted on GitLab.
> >     * Create blog announcement once the transition is complete.
> >
> >     There are a few unknowns:
> >
> >     Would it be possible to migrate open bug reports to GitLab?  I
> suspect
> >     we could come up with a script like we did when we migrated from
> >     SourceForge.
> >
> >     What to do about the mailing list?  GitLab doesn't support
> mailing lists
> >     yet so I'm thinking we leave the mailing list on Launchpad for
> the short
> 

Re: [Kicad-developers] Linker Error (self made...)

[Thomas Pointhuber]

Please go for it. The separate DLLs make it hard to design a python api
where eeschema and pcbnew can share resources.

Regards, Thomas

Am 28.08.19 um 16:03 schrieb Simon Richter:
> Hi,
> 
> On Wed, Aug 28, 2019 at 10:47:52AM +0200, Ian McInerney wrote:
> 
>> I think that the only way to really fix this is to split common up into
>> some smaller units,
> 
> I had the same idea already. This works for some parts (for example I was
> able to split off dlist as an experiment), but the base_units stuff cannot
> be turned into a library right now.
> 
> What might work would be defining the conversion factor in the Kiface
> instantiation code and pass it down through the *_FRAME hierarchy, but that
> would make all conversions require the frame as context (so it would break
> my plan for a gradual replacement). Once the unit code is merged, there
> isn't even a need to build separate DLLs anymore, we can just link
> everything together.
> 
>Simon
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 



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

Re: [Kicad-developers] [Patch] Fix some memory leaks

[Thomas Pointhuber]

Indeed,

there is actually a plan to improve this in the future. Personally, I
even wrote down a very rough idea myself:

https://github.com/pointhi/kicad-python/wiki/swig-interface-idea

I was able to compile eeschema with swig binding
(https://github.com/pointhi/kicad-source-mirror/commits/eeschema_swig),
but it looks like I need to wait until the unified coordinate system is
integrated, to start with the real work. Otherwise, sharing a common
library between eeschema and pcbnew could require a unnecessary number
of hacks.

Regards, Thomas

Am 13.08.19 um 18:41 schrieb Simon Richter:
> Hi,
> 
> On Tue, Aug 13, 2019 at 05:43:02PM +0200, Ian McInerney wrote:
> 
>> Smart pointers would definitely have been nicer to use, but the issue we
>> have with the board objects is they are passed out through SWIG to Python
>> currently, and SWIG doesn't seem to support unique_ptr, so I am not sure
>> how it would react if we gave it a deque of unique_ptrs. Anyone know if
>> that would break anything?
> 
> That would break horribly, indeed.
> 
> It would probably make sense to have a higher-level interface for
> scripting, and SWIG that instead of exposing the internals, breaking all
> the scripts everytime we improve something. :/
> 
>Simon
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 



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

Re: [Kicad-developers] PCBNew Find and "match words"

[Thomas Pointhuber]

That looks quite like the "Edit Symbol Fields" dialog. I would suggest
to extend this one instead of creating your own one.

What I would like to see is an advanced search for components, having at
least the filter features of cvpcb. This would allow ditching the
redundant dialogs for symbol and footprint selection.

Regards, Thomas

Am 27.07.19 um 09:31 schrieb Dino Ghilardi:
> Also as an example of possible U.I. for search, including common, simple
> and advanced options.
> 
> https://www.youtube.com/watch?v=QCMddxkKe8k
> 
> (starting around 0:18 of the video).
> 
> 
> Cheers,
> Dino.
> 
> 
> On 26/07/19 23:21, Jeff Young wrote:
>> Oh cool.  I’ll look into it….
>>
>>> On 26 Jul 2019, at 14:57, Wayne Stambaugh  wrote:
>>>
>>> I implemented regular expression search method in EDA_ITEM but I never
>>> finished hooking everything up at the UI level.  So unless someone
>>> removed it, it should still be there.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 7/26/19 3:41 PM, Jeff Young wrote:
 I went with something similar to Seth’s proposal, only based on
 Eeschema’s find (so no regular expressions yet).

 Most of the workings are down in EDA_ITEM, so if we add regex
 matching we’ll get it in both Eeschema and Pcbnew.

 Cheers,
 Jeff.


> On 26 Jul 2019, at 13:11, Seth Hillbrand  wrote:
>
> On 2019-07-26 14:39, Jeff Young wrote:
>> PCBNew’s current Find does a match against the whole string.  I think
>> it would be more intuitive with a ‘*’ in front and back of the search
>> string (so that it finds partial matches).
>> Any other opinions?
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
> Hi Jeff-
>
> Here's a mockup of something I was poking at a while ago. 
> Different processing for different purposes.  As long as we
> remember the checkboxes between uses, people's search preferences
> are allowed/respected.
>
> -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

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



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

Re: [Kicad-developers] [PATCH] Fix handling of filled circle in eagle importer (was only partly fixed)

[Thomas Pointhuber]

I would like to send a ping for my two eagle importer fixes.

The fix for handling filled circles should be included into 5.1.3, the
other one only affects nightly.

Both bugs can be reproduced with: https://github.com/SHA2017-badge/PCB

Bugs fixed for this specific board:

* silkscreen for button A and B are not filled (width=0)
* zone is not hatched

when you look a bit more on the eagle board, you will certainly find
some more import bugs which are not fixed at the moment :). (DRC,
silk-polygon,...)

Regards, Thomas

Am 12.07.19 um 21:26 schrieb Thomas Pointhuber:
> Hi,
> 
> I noticed that my fix for circles in the eagle import was only partial.
> Namely there is something like a "plain section", where I missed to
> handle the case of width=0. Now we fill those circles as well :).
> 
> Regard, Thomas
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 



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] [PATCH] Fix handling of filled circle in eagle importer (was only partly fixed)

[Thomas Pointhuber]

Hi,

I noticed that my fix for circles in the eagle import was only partial.
Namely there is something like a "plain section", where I missed to
handle the case of width=0. Now we fill those circles as well :).

Regard, Thomas
From 5cc1d5680dc70dd1aac7dc2c459ea79977e224c8 Mon Sep 17 00:00:00 2001
From: Thomas Pointhuber 
Date: Fri, 12 Jul 2019 21:18:42 +0200
Subject: [PATCH] Fix handling of filled circle in eagle importer (was only
 partly fixed)

Partly fixed in 4fc692f04b447f77c75f4538982f6b739d08c4e8, but missed
that there is a loadPlain where I need to handle this case as well.
---
 pcbnew/eagle_plugin.cpp | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/pcbnew/eagle_plugin.cpp b/pcbnew/eagle_plugin.cpp
index 55b596a51..c70faf9ce 100644
--- a/pcbnew/eagle_plugin.cpp
+++ b/pcbnew/eagle_plugin.cpp
@@ -645,12 +645,22 @@ void EAGLE_PLUGIN::loadPlain( wxXmlNode* aGraphics )
 DRAWSEGMENT* dseg = new DRAWSEGMENT( m_board );
 m_board->Add( dseg, ADD_APPEND );
 
+int width = c.width.ToPcbUnits();
+int radius = c.radius.ToPcbUnits();
+
+// with == 0 means filled circle
+if( width <= 0 )
+{
+width = radius;
+radius = radius / 2;
+}
+
 dseg->SetShape( S_CIRCLE );
 dseg->SetTimeStamp( EagleTimeStamp( gr ) );
 dseg->SetLayer( layer );
 dseg->SetStart( wxPoint( kicad_x( c.x ), kicad_y( c.y ) ) );
-dseg->SetEnd( wxPoint( kicad_x( c.x + c.radius ), kicad_y( c.y ) ) );
-dseg->SetWidth( c.width.ToPcbUnits() );
+dseg->SetEnd( wxPoint( kicad_x( c.x ) + radius, kicad_y( c.y ) ) );
+dseg->SetWidth( width );
 }
 m_xpath->pop();
 }
-- 
2.22.0



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] [PATCH] Add support for hatched zones in eagle import

[Thomas Pointhuber]

Hi,

I made a small patch to import hatched zones from eagle.

In this patch I removed the call to ```SetHatch``` which didn't seem to
do anything, and only was used when p.spacing was defined. Can someone
tell me if this was OK? Did not noticed any changes in behavior.

Regards, Thomas
From 5df6e279c635a888a1087a11f0d24d94fb64 Mon Sep 17 00:00:00 2001
From: Thomas Pointhuber 
Date: Fri, 12 Jul 2019 20:11:21 +0200
Subject: [PATCH] Add support for hatched zones in eagle import

---
 pcbnew/eagle_plugin.cpp | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/pcbnew/eagle_plugin.cpp b/pcbnew/eagle_plugin.cpp
index 55b596a51..871b90a6a 100644
--- a/pcbnew/eagle_plugin.cpp
+++ b/pcbnew/eagle_plugin.cpp
@@ -1199,12 +1199,15 @@ ZONE_CONTAINER* EAGLE_PLUGIN::loadPolygon( wxXmlNode* aPolyNode )
 zone->SetDoNotAllowCopperPour( true );
 zone->SetHatchStyle( ZONE_CONTAINER::NO_HATCH );
 }
+else if( p.pour == EPOLYGON::HATCH )
+{
+int spacing = p.spacing ? p.spacing->ToPcbUnits() : 50 * IU_PER_MILS;
 
-// if spacing is set the zone should be hatched
-// However, use the default hatch step, p.spacing value has no meaning for KiCad
-// TODO: see if this parameter is related to a grid fill option.
-if( p.spacing )
-zone->SetHatch( ZONE_CONTAINER::DIAGONAL_EDGE, zone->GetDefaultHatchPitch(), true );
+zone->SetFillMode( ZFM_HATCH_PATTERN );
+zone->SetHatchFillTypeThickness( p.width.ToPcbUnits() );
+zone->SetHatchFillTypeGap( spacing - p.width.ToPcbUnits() );
+zone->SetHatchFillTypeOrientation( 0 );
+}
 
 // We divide the thickness by half because we are tracing _inside_ the zone outline
 // This means the radius of curvature will be twice the size for an equivalent EAGLE zone
-- 
2.22.0



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

Re: [Kicad-developers] How often do we want to auto-fill zones?

[Thomas Pointhuber]

On the long run, what about improving the fill algorithm to be able to
only update affected regions?

e.g. As long as an update cannot split the zone and the update has no
overlap with other zones it should be possible to only recalculate parts
of the zone fill and ignoring the rest.

I know this is not easy, especially to find all possible edge-cases. On
the long run it could be a nice usability improvement for people routing
while showing the zone fill as well as to avoid having fills into tracks
(which caused some production failures in the past)


Regards,
Thomas

Am 05.07.19 um 18:13 schrieb Wayne Stambaugh:
> On 7/5/19 11:50 AM, Seth Hillbrand wrote:
>> On 2019-07-05 07:46, Jeff Young wrote:
>>> 1) If I move a footprint which is over a zone, the zone fill becomes
>>> stale.
>>>
>>> 2) If I move a zone which has footprints over it, the zone is re-filled.
>>>
>>> 3) If I edit the points of a zone and then de-select it, the zone is
>>> re-filled.
>>>
>>> Item (2) turns out to be a side effect of the PointEditor getting
>>> activated when the zone is selected for the move, and then refilling
>>> the zone when it is unselected.
>>>
>>> Do we want to keep that, or should I make it consistent with (1)?
>>>
>>> (Making it consistent will fix Wayne's crash, but I think I can find
>>> other ways of fixing it if we want to keep the behaviour.)
>>
>> Wow, is that what that crash was?  Nice sleuthing there!  Point editor
>> is going to be the death of us. :)
>>
>> Since we refill zones after they become stale internally, I think we
>> should be consistent and refill in case (1) also.  But this has some
>> nasty side effects when working in boards with extended fill times.  For
>> 5.1, I'd vote for leaving behavior as-is and adding a preference setting
>> for auto-refill stale zones in v6.  Then that can control all refills
>> including (1) as well as dragging a track over a filled zone area.
>>
>> -Seth
>>
> 
> I concur.  We should definitely make zone auto filling optional.  For
> complex boards the refill cost can be painful.
> 
> 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
> 



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

Re: [Kicad-developers] 6.0 string proposal

[Thomas Pointhuber]

Hi,

 

I would like to drop in this website to the discussion: https://utf8everywhere.org/

 

There are good points, and I would suggest either storing them internally with 8 or 32 bit.

 

Regards, Thomas

 

 

Gesendet: Dienstag, 30. April 2019 um 11:52 Uhr
Von: "Andrew Lutsenko" 
An: "Jeff Young" 
Cc: "KiCad Developers" 
Betreff: Re: [Kicad-developers] 6.0 string proposal



Hi,
I have no opinion on the matter but would add a reminder that wchar_t is platform and compiler dependent.

Consider using std::u32string instead of std::wstring if you want all code points to fit into one element.
 

Regards,

Andrew


 


On Tue, Apr 30, 2019 at 2:36 AM Jeff Young  wrote:

We had talked earlier about throwing the wxWidgets UTF8 compile switch to get rid of our wxString re-entrancy problems.  However, I noticed that the 6.0 work packages doc includes an item for std::string-ization of the BOARD.  (While a lot more work, this is a better solution because it also increases our gui-toolkit-choice flexibility.)

I’d like to propose that we use std::wstring for that.  UTF8 should *only* be an encoding format (similar to s-expr).  It should never be used internally.  That’s what unicode wchar_t’s are for.

And I’d like to propose that we extend std::wstring-ization to SCH_ITEM and LIB_ITEM.  (Then we can get rid of a bunch of our ugly mutex hacks.)
___
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

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





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

[Kicad-developers] There seems to be an serious issue with netlist handling in KiCad 5.1.1

[Thomas Pointhuber]

Hi,

 

I made a KiCad beginner workshop yesterday (with about 45 people), and at least two of the participants appared to run into serious issues regarding netlist handling. One of my colleguages as well (I hope he creates an bug-report soon).

 

The Issue appeared on KiCad 5.1.1, but it could be a regression already present in 5.1. Basically, it causes some nets to be not connected, which results in missing ratsnets in pcbnew as well as ERC errors (not-connected pads). Visually, all pins are shown as correctly connected in eeschema. In pcbnew those pads are not connected at all (so no ratsnets bug).

 

Dunno if this fix works for all people, but closing eeschema and opening it again causes a corrupted file warning (I think warning about an invalid netlist), which causes KiCad to create the netlist again and building a valid one which resolves the issue.

 

As summary: it seems there is a serious bug in KiCad 5.1.x which causes netlist errors and file corruptions.

 

I told everyone which had this problem to create a bug-report on launchpad to give some additional informations. If the issue is not found until KiCon, I would suggest to have one of the main-developers attend the beginner workshop to look for anyone having this issue and reproduce it.

 

Regards, Thomas

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

[Kicad-developers] Would someone please update Documentation/development/tool-framework.md

[Thomas Pointhuber]

Hi,

out of curiosity I'm currently trying to register a new tool, but no
success for now.

I noticed that "tool-framework.md" is no longer up-to-date (referring to
the Tutorial):

For example:

* "SetTransitions" is now "setTransitions"
* m_menu seems to be managed by PCB_TOOL now
* ...

It would be nice to get it up-to-date.

Regards, Thomas



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] [PATCH] Fix zero-width line and circle in eagle-import

[Thomas Pointhuber]

Hi,

compiling KiCad gave me a bunch of those warnings, indicating problems
with the eagle importer:

```
./pcbnew/eagle_plugin.cpp:1401:21: warning: implicit conversion from
'double' to 'int' changes value from 0.05 to 0 [-Wliteral-conversion]
width = DEFAULT_EDGE_WIDTH;
  ~ ^~
./include/board_design_settings.h:35:39: note: expanded from macro
'DEFAULT_EDGE_WIDTH'
#define DEFAULT_EDGE_WIDTH0.05
  ^~~~
```

I looked into the issue and found out that the handling for width==0 in
circles is currently wrongly implemented (it creates a filled circle),
beside of the obvious double -> int issue.

In case of wire with==0 I was not able to find a behavior other than it
is no longer visible in the editor. I kept the old behavior defined for
now (use default width), but correctly implemented it using the defined
default line width.

Regards, Thomas
From 7bf281cdec3614300b0fdf3b9ecf11eb6f6e72cf Mon Sep 17 00:00:00 2001
From: Thomas Pointhuber 
Date: Sat, 26 Jan 2019 16:16:35 +0100
Subject: [PATCH] [eagle-import] fix handling of filled circle and default
 layer width

---
 pcbnew/eagle_plugin.cpp | 40 ++--
 1 file changed, 6 insertions(+), 34 deletions(-)

diff --git a/pcbnew/eagle_plugin.cpp b/pcbnew/eagle_plugin.cpp
index 34510224f..422c0aa19 100644
--- a/pcbnew/eagle_plugin.cpp
+++ b/pcbnew/eagle_plugin.cpp
@@ -1395,22 +1395,7 @@ void EAGLE_PLUGIN::packageWire( MODULE* aModule, wxXmlNode* aTree ) const
 
 if( width <= 0 )
 {
-switch( layer )
-{
-case Edge_Cuts:
-width = DEFAULT_EDGE_WIDTH;
-break;
-case F_SilkS:
-case B_SilkS:
-width = DEFAULT_SILK_LINE_WIDTH;
-break;
-case F_CrtYd:
-case B_CrtYd:
-width = DEFAULT_COURTYARD_WIDTH;
-break;
-default:
-width = DEFAULT_LINE_WIDTH;
-}
+width = aModule->GetBoard()->GetDesignSettings().GetLineThickness( layer );
 }
 
 // FIXME: the cap attribute is ignored because kicad can't create lines
@@ -1732,32 +1717,19 @@ void EAGLE_PLUGIN::packagePolygon( MODULE* aModule, wxXmlNode* aTree ) const
 dwg->SetDrawCoord();
 }
 
-
 void EAGLE_PLUGIN::packageCircle( MODULE* aModule, wxXmlNode* aTree ) const
 {
 ECIRCLE e( aTree );
 PCB_LAYER_IDlayer = kicad_layer( e.layer );
 EDGE_MODULE*gr = new EDGE_MODULE( aModule, S_CIRCLE );
 int width = e.width.ToPcbUnits();
+int radius = e.radius.ToPcbUnits();
 
+// with == 0 means filled circle
 if( width <= 0 )
 {
-switch( layer )
-{
-case Edge_Cuts:
-width = DEFAULT_EDGE_WIDTH;
-break;
-case F_SilkS:
-case B_SilkS:
-width = DEFAULT_SILK_LINE_WIDTH;
-break;
-case F_CrtYd:
-case B_CrtYd:
-width = DEFAULT_COURTYARD_WIDTH;
-break;
-default:
-width = DEFAULT_LINE_WIDTH;
-}
+width = radius;
+radius = radius / 2;
 }
 
 aModule->GraphicalItemsList().PushBack( gr );
@@ -1775,7 +1747,7 @@ void EAGLE_PLUGIN::packageCircle( MODULE* aModule, wxXmlNode* aTree ) const
 gr->SetLayer( layer );
 gr->SetTimeStamp( EagleTimeStamp( aTree ) );
 gr->SetStart0( wxPoint( kicad_x( e.x ), kicad_y( e.y ) ) );
-gr->SetEnd0( wxPoint( kicad_x( e.x + e.radius ), kicad_y( e.y ) ) );
+gr->SetEnd0( wxPoint( kicad_x( e.x ) + radius, kicad_y( e.y ) ) );
 gr->SetDrawCoord();
 }
 
-- 
2.20.1



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

Re: [Kicad-developers] FOSDEM KiCad dinner.

[Thomas Pointhuber]

Hi Wayne,

 

I would like to attend this year again.

 

Regards,

Thomas




Gesendet: Montag, 07. Januar 2019 um 18:40 Uhr
Von: "Wayne Stambaugh" 
An: "KiCad Developers" 
Betreff: [Kicad-developers] FOSDEM KiCad dinner.

For those of you who don't know, the last few years at FOSDEM we have
had a KiCad dinner on Saturday evening which was open to all. Last year
we had well over 30 attendees which was very not manageable. This year
we have decided to limit the size to 15. So far we have 4 confirmed
attendees from the lead development team. I am now opening up requests
to the developers on the development mailing list. This includes our
library, documentation, and translation developers. Please RSVP me as
soon as possible if you are interested. Resevations will be on a first
come first serve basis until all 15 spots are reserved. Any remaining
spots will be open to sponsors and then to the general public.

Cheers,

Wayne

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




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

[Kicad-developers] Improve GLM check to ignore clang (which is working)

[Thomas Pointhuber]

Hi,

at the moment I revert the "Check for incompatible glm version" every
time I update the KiCad sources, because I'm using clang instead which
is working with the current glm version on arch linux.

My Patch binds the GLM check to GCC only, to allow other compilers to
work with newer GLM versions.

Regards,

Thomas
From 59fd03a63949d16b67c789038f681abbd9e67dfb Mon Sep 17 00:00:00 2001
From: Thomas Pointhuber 
Date: Sun, 6 Jan 2019 11:55:15 +0100
Subject: [PATCH] Fix check for incompatible glm version in cmake

Build fails on GCC, but not with Clang. Modify the check to only catch the
cases where GLM does not work for sure.

Reference: lp:1804030
* https://bugs.launchpad.net/kicad/+bug/1804030
---
 CMakeLists.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index a7b8f166a..6c907176e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -587,9 +587,9 @@ endif()
 # Find GLM library, required
 #
 find_package( GLM 0.9.5.1 REQUIRED )
-if( GLM_VERSION MATCHES "0.9.9.3" )
-MESSAGE( FATAL_ERROR "\nGLM version ${GLM_VERSION} is incompatible with KiCad.\n"
- "Please downgrade to GLM version 0.9.9.2 or older" )
+if( GLM_VERSION MATCHES "0.9.9.3" AND CMAKE_CXX_COMPILER_ID MATCHES "GNU")
+MESSAGE( FATAL_ERROR "\nGLM version ${GLM_VERSION} is incompatible with KiCad using GCC.\n"
+ "Please downgrade to GLM version 0.9.9.2 or older or use clang instead" )
 endif()
 
 add_definitions( -DGLM_FORCE_CTOR_INIT )
-- 
2.20.1



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

Re: [Kicad-developers] [RFC] Symbol library file format

[Thomas Pointhuber]

My ERC Proposal was more like a: we should at least think about it a bit
instead of writing the pin type near style and number/name. We can
specify ERC hints in a future-proof way without extending the current
implementation. Like:

(erc_hints (pin_type power_in))

This would allow us to specify new erc hints in the future without
splitting them up at different places in KiCad 7.

I'm in favor of pin properties. In fact I would like to have the ability
to specify properties for all important items. (Pin, Symbol, Net,
Sub-schematic, Label,...). Those can be used by users and 3rd-party
programs, as well as to quickly prototype new stuff like ERC rules.

Regards,
Thomas

Am 04.01.19 um 19:55 schrieb Wayne Stambaugh:
> I'm willing to add properties which are already defined to pins.  There
> has been talk about adding about adding electrical constraints for
> advance ERC testing to symbols but that will not be part of the v6
> implementation of the new file format.  It's going to be a lot of work
> to implement the features we've added to v6 so this would be outside the
> scope of the first version of the new file format.  I'm certainly open
> to discussing this as part of a later version of kicad.
> 
> On 1/2/19 3:52 PM, mark.vandoesb...@hetnet.nl wrote:
>> One thing I would like to have is user defined pin properties, just like
>> the part properties. Currently I use the BOM generator to generate a
>> software header file from the netlist. I have to use an additional file
>> to store the information I need. It would be nice if this information
>> can be stored in the symbol. This could be any kind of information, for
>> example bank number or clock region for an FPGA. Or driver strenght/speed
>> setting for a microcontroller.
>>
>> regards,
>>
>> Mark.
>>
>> Wayne Stambaugh  wrote:
>>
>>  I have updated and published the symbol file format[1] for comment.
>>  Hopefully there isn't too much to change.  The only thing to really
>>  finalize is the internal units.  The initial concept was unitless but
>>  the more I think about it and discuss with other developers, it makes
>>  more sense to use units for the following reasons:
>>
>>  1. It's easier to visualize in your head how the symbols on a given page
>>  size will layout.
>>
>>  2. Converting from other file formats (Eagle, Altium, etc) will be
>>  easier since most if not all of them have a defined unit.
>>
>>  I'm thinking 10u (or possibly 100u) will make a good internal units
>>  value.  Once we nail down the units, I will update the file format
>>  document accordingly.
>>
>>  Please keep in mind that this is the symbol library file format document
>>  so things like constraints belong in the schematic file format.  I will
>>  be posting the schematic file format as soon as I finish updating it.
>>
>>  Cheers,
>>
>>  Wayne
>>
>>  [1]:
>>  
>> https://docs.google.com/document/d/1lyL_8FWZRouMkwqLiIt84rd2Htg4v1vz8_2MzRKHRkc/edit
>>
>>
>>  ___
>>  Mailing list: https://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
> 



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

Re: [Kicad-developers] [RFC] Symbol library file format

[Thomas Pointhuber]

Hi,

 

I didn't unterstand the reason for the proposal at the start due to new schematic format, new dependencies,...

 

But thinking about it a bit more it really makes sense to me now. In the past, I wrote importer as well as exporter for the footprint file format, and using protobuf would likely simplify such work quite a bit (no requirement to write sexpr parser/writer, a FORMAL specification of the file format). Have you ever seen the import/export implementation in KiCad itself? I would call it a mess. Locale dependent code which requires workarounds, exporter written with string format which can have issues like missing space between brackets, importers, while written as propper Parser, it should actually be implemented in two stages (stage 1: parse sexpr, stage 2: parse data). Furthermore, you need to have those two completly separated pieces of code to actually produce/understand the same data.

 

In the end, it's the decision of the Developer implementing that stuff. But thinking about the current state, I would say even with sexpr format, the code needs to be refactored quite a bit to be less error-prone and easier to extend. Switching to protobuf should simplify import/export, couples the two parts tightly together, removes the burden to write the actual input/output stuff and simplifies the usage of the file format for 3rd party software (including propper validation). And, in comparsion to the current google-doc, it would be an actual FORMAL specification. I did not even found a normal specification for the .kicad_mod format for example. The best specification is the one where code is generated from. In this case you know there are no implementation differences and it is always up-to-date.

 

Regards,

Thomas

 

Gesendet: Donnerstag, 03. Januar 2019 um 19:06 Uhr
Von: "José Ignacio" 
An: anlutse...@gmail.com
Cc: "KiCad Developers" 
Betreff: Re: [Kicad-developers] [RFC] Symbol library file format


I think all this babble about data representations to be pointless and counterproductive. the S _expression_ parser is already implemented and it works fine, it is trivial to convert s-expressions to any other data representation you like, be it, xml, json or whatever comes up next week in NPM. The issue with the file format is really to come up with a good data model to represent the objects in kicad, and neither protobufs nor any of the other guys really does anything for us in that area, if anything that is the input that needs to be given to whatever parser generator, or manually generated parser process we choose to utilize. I think useful comments to the proposed format should see beyond the actual low level representation of the data and talk about the overall model being used to store it.
 


On Thu, Jan 3, 2019 at 3:37 AM Andrew Lutsenko  wrote:



Hi Martijn,
My guess is that most of the complexity is in switching to new data model in eeschema, which is going to happen anyway. Since with protobufs you don't concern yourself with parsing data the only tricky thing would be to seamlessly integrate proto codegen into build process on all platforms. 

Since eeschema data model is going to change without backward compatibility, file compatibility is out of the window too so this is good opportunity to change underlying format to something that is better in the long run. If we decide to go this route than ideally pcbnew would switch to proto at some point too, not necessarily in v6.

 

> Would it be feasible to support both in V6 and let the future tell us which one would prevail?  

What do you mean by prevailing? It's clear at this point that s-expressions are not a winner of global trends while I can guarantee that sizable portion of the data in the internet (except probably porn, lol) is exchanged in protobufs and thrift since all tech giants use them.

If you mean in terms of what KiCad users prefer I don't think vast majority would care either way. Both formats are easy to edit directly and protos are much better for devs because codegen takes all the routine out of data manipulation.

While having both formats coexist is theoretically possible I think it will only split the user base since people will pick one and stick to it. I think this is the case where devs should be empowered to make the choice, same as when switch to s-expressions happened.

Of course new version still needs to be able to read old files or at least some conversion utility needs to be provided to migrate projects to v6 so s-expressions code will not be going away for some time.

 

Andrew

 


On Wed, Jan 2, 2019 at 11:53 PM Martijn Kuipers  wrote:


 
 

On 3 Jan 2019, at 04:17, Andrew Lutsenko  wrote:
 




Wayne,
 

> There are some interesting and practical concepts with protobuf but it's
functionally a binary storage method which I am opposed to. 

 

That is a somewhat common misconception because protobufs are frequently used for 

Re: [Kicad-developers] [RFC] Symbol library file format

[Thomas Pointhuber]

Hi Carsten,

Unfortunate, I don't think the reality works like that. While my
experience with SPICE is quite sparse (especially inside KiCad), I do
NOT think in this case about open and free spice model for IC's. Not
everyone uses the KiCad supplied libraries but their own, and simple
spice stuff like putting some resistors together for an R-Network can be
done in the official as well.

Fully separate spice out of the symbol would not work anyway because
from what I noticed spice pin does not map to symbol pin in many cases.
You need to link that somewhere anyway. I'm heavily in favor of
simplifying handling of simulation for users. Integrating this into one
file would be less error-prone than separating simulation into multiple
additional files. Including external SPICE models would then be an
option, but not necessary.

A modular approach where SPICE is only one of many possibilities is in
my favor, but in a different way than you proposed (integrated in the
symbol). There is for example the topic of digital simulation, which
would require different types of models. We should at least think about
it so it can be integrated later in a nice way.

Regards,
Thomas

Am 02.01.19 um 11:05 schrieb Carsten Schoenert:
> Hello Thomas,
> 
> Am 02.01.19 um 10:39 schrieb Thomas Pointhuber:
>> * I do not see anything related to SPICE in this document. I would vote
>> to add it including the possibility to embedded spice models
>> (BASE64-encoded) into the symbol itself.
> 
> I disagree on that.
> Please do not mix two different main purposes and add more complexity.
> 
> Schematic simulation is a add-on, not a primary key feature of a symbol
> format or within Eeeschema.
> 
> Including such stuff into a schematic symbol make it harder to maintain
> the symbols in along term as you always need to touch the symbol no
> matter what peace need a update. But the (new extended) symbol format
> can get of course a new field of course for a referenced file to look
> at. Like similar done for associated footprints. Add a new environment
> variable like SPICE_MODEL_DIR to add a default folder.
> 
> Currently it's not clear how a open and free spice working model can
> look like, I really suggest to not create a own world for spice models.
> Make it modular so work needs to be done more than needed.
> 
> I also suggest to get in touch with Holger from the ngspice project
> about his thoughts and possible suggestions on this topic.
> 



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

Re: [Kicad-developers] [RFC] Symbol library file format

[Thomas Pointhuber]

Hi,

nice to see that the new file format is shaping up now. Some comments
from my side:

* I do not see anything related to SPICE in this document. I would vote
to add it including the possibility to embedded spice models
(BASE64-encoded) into the symbol itself.

* pin type as it is currently specified should be removed. Instead it
should be replaced with a more powerful electrical constraints
specification entity which includes the pin type, but allows the
addition of various other constrains as well, like:
  - output-voltage-range
  - voltage range for valid high/low signal
  - net/bus-type (e.g. I2C/SDA,...)
  - electrical hypergraph (to detect invalid connections between
galvanic separated net-groups)
  - ...

* specifying diff-pair in symbol itself without relying on a naming
convention?

* How are power symbols defined now?

Regards,
Thomas

Am 01.01.19 um 20:59 schrieb Wayne Stambaugh:
> I have updated and published the symbol file format[1] for comment.
> Hopefully there isn't too much to change.  The only thing to really
> finalize is the internal units.  The initial concept was unitless but
> the more I think about it and discuss with other developers, it makes
> more sense to use units for the following reasons:
> 
> 1. It's easier to visualize in your head how the symbols on a given page
> size will layout.
> 
> 2. Converting from other file formats (Eagle, Altium, etc) will be
> easier since most if not all of them have a defined unit.
> 
> I'm thinking 10u (or possibly 100u) will make a good internal units
> value.  Once we nail down the units, I will update the file format
> document accordingly.
> 
> Please keep in mind that this is the symbol library file format document
> so things like constraints belong in the schematic file format.  I will
> be posting the schematic file format as soon as I finish updating it.
> 
> Cheers,
> 
> Wayne
> 
> [1]:
> https://docs.google.com/document/d/1lyL_8FWZRouMkwqLiIt84rd2Htg4v1vz8_2MzRKHRkc/edit
> 
> 
> ___
> Mailing list: https://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] add KiCad on GSoC this year?

[Thomas Pointhuber]

Hi,

some reminder for next month: Starting with January 15th, mentoring
organizations can start submitting applications for the GSoC:

https://developers.google.com/open-source/gsoc/timeline

It would be a nice idea to apply this year, and get some students to
help with the development of KiCad 6.

I would suggest to advertise topics which are mostly standalone and
sound interesting/challenging, and where people currently not working
on, like: diff/merge tools, improved digital/analog simulation, signal
integrity, auto-router, improved push-shove,...

Regards,
Thomas



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

Re: [Kicad-developers] RFC: Moving footprint wizards to github

[Thomas Pointhuber]

Hi,

I'm in favor of managing the scripts like the library in a distinct
repository, but I would wait after 5.1 release, as well as not simply
copying the existing scripts into that repository.

I made a RFC on the forum some time ago how I would think such a
repository could look like, which would imply that the footprint wizards
are scriptable in the future, as well as they represent the reference
implementation for footprints (which are currently located in my own
repository):

https://forum.kicad.info/t/rfc-future-of-footprint-wizard-and-generator/12592

Regards, Thomas

Am 16.12.18 um 17:54 schrieb Wayne Stambaugh:
> On 12/15/2018 10:42 PM, Seth Hillbrand wrote:
>> Am 2018-12-15 21:09, schrieb Oliver Walters:
>>> Seth,
>>>
 I like this idea.  Coupled with a build/install CMake script in the
 repo
 would make iterating on the Python script development faster/easier.
>>>
>>> A cmake script sounds like a good idea, would you be willing to add
>>> this to the repo?
>>
>> Sure.  But let's give a few days for any objections before moving ahead.
>>  There may be concerns that I'm not thinking of.
>>
>> -S
>>
> 
> I'm not sure I like this idea.  I have no objections to scripts that are
> not distributed with KiCad to be maintained in any manner the developer
> see fit.  I would prefer that any source code that gets distributed with
> KiCad remain in the source repo.  I would not be opposed to removing the
> footprint wizards from KiCad and make them a separate project but I'm
> not sure all of our users would agree with installing them separately
> since they have been part of KiCad almost as long as the python
> scripting support.
> 
> 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
> 



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

Re: [Kicad-developers] [RFC 1/2] New coordinate framework

[Thomas Pointhuber]

Stupid question:

why not use long instead of int? Most computer systems nowadays are
64bit anyway. Are there Speed/Memory considerations which would block
this? I think having an unified codebase without unit quirks would be an
important improvement.

Regards, Thomas

Am 21.11.18 um 20:35 schrieb Wayne Stambaugh:
> On 11/21/2018 2:18 PM, Simon Richter wrote:
>> Hi,
>>
>> On 21.11.2018 20:02, jp charras wrote:
>>
>>> what do you mean by:
>>> "that the entire code uses nanometers as internal units
>> That would be the goal, to use the same internal unit everywhere.
>> Nanometers make the most sense, because of the metric/imperial
>> conversion issues you mention.
>>
>>> In Pcbnew, one nanometer is used mainly to avoid any conversion issue
>>> between inches and nanometers.
>>> Without this constraint, 10 nm will be better.
>>
>> Hm, 1mil is 25400nm, so we could even go to 100nm without introducing
>> conversion issues. Would that work for all apps?
> 
> This would break pcb files so nm has to stay for board and footprint
> files.  I was planning on using 100nm for the new schematic and symbol
> file formats since it seems to me that we really don't need any more
> absolute positional accuracy than that.
> 
>>
>>> By the way, I am pretty sure the the gtk3/Cairo overflow issue is not
>>> inside Kicad.
>>
>> Indeed, that is a Cairo problem, but I tried to debug this with -ftrapv,
>> and found that we have surprisingly many integer overflows within KiCad.
>>
>> They seem to be mostly harmless, but from a code quality point of view
>> I'd also like to see them gone.
> 
> These absolutely should be flagged and fixed whether they are harmless
> or not.  This is just a good coding policy.
> 
>>
>>Simon
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 



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

Re: [Kicad-developers] [RFC] wxPhoenix support

[Thomas Pointhuber]

Hi Wayne,

The console crash is already fixed in the merge request:
https://code.launchpad.net/~pointhi/kicad/+git/kicad/+merge/357605

Regards,
Thomas

Am 22.10.18 um 18:36 schrieb Wayne Stambaugh:
> Hey Thomas,
> 
> I looked over you merge request and it changes seem fine.  I still need
> to test it but until the console crash issue is resolved, I will not
> approve the patch.  Hopefully someone can help you out with the mutex
> locking issue.
> 
> Cheers,
> 
> Wayne



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] ideas to improve patch and CI integration

[Thomas Pointhuber]

Hi,

I think this topic will have many different point of views, but I think
it is important to discuss it anyway.

I'm now about 5 years on the project, started as library maintainer and
now sometimes with code contributions as well. I experienced at least a
few different types of how software projects can be design of a
management perspective to get work done.

Currently, there is the time where many big organizations (GNOME and
freedesktop.org for example) moved their development to custom GitLab
instances. And I would like to propose to think about that for KiCad as
well. Not because everyone does it, but because it would benefit the
project itself. There are various reasons I can think of right now:

* patches are sometimes simply forgotten on the mailing list
* it is pretty hard to find old patches on the mailing list unless you
have the e-mails stored on your account. You cannot search on launchpad
* CI integration of patches is missing. People need to run them explicit
before merging, or the automated build will fail at some point
* getting CI runs for various systems requires explicit request due to
missing automatization
* no automated linter checks (would require us to reformat the project)
* it's hard to track changes of patches, especially when modified,
squashed,...
* way better possibilities to view/edit/show history online
* review tools on Launchpad are cumbersome and rarely used. This should
be the standard in point of fact.
  * easier to handle a proper review than with e-mail
* easier to keep track how discussions evolved
* the project is currently split between Launchpad and GitHub, this
would allow us to combine all parts on one platform
* GitLab would theoretically allow us add custom differs for library review
* new contributors likely know GitHub/Gitlab workflow and can join more
easily

I know this is quite some heavy proposal due to change of workflow and
bug-migration. Nevertheless, we should at least discuss it.

PS: A college built a working GitLab CI script with export of build
artifacts. GitLab integration of Jenkins would be possible as well.

Regards,
Thomas



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] [RFC] wxPhoenix support

[Thomas Pointhuber]

Hi,

Now with Python 3 merged it would be nice to get support for (optional)
wxPhoenix support into 5.1 as well. I have a preliminary branch running,
which works on Linux quite well (wx3.0.4+GTK3+python3.7+wxPhoenix). It's
mainly based on
patch-sets @mmccoo wrote some time ago.

https://github.com/pointhi/kicad-source-mirror/tree/wx-python

For windows, nickoe helped me to get a first build of this branch with
Python2+wxPython to ensure the old stack is not broken. Unfortunately,
closing the scripting console causes pcbnew to hang and then crash.

https://jenkins.simonrichter.eu/job/windows-kicad-msys2-patch/169/

I was able to reproduce the problem on Linux with
(wx3.0.4+GTK3+python2.7+wxPython). It seems some mutex is not
initialized, but I don't know how to fix this issue. The bug is likely
introduced due to the fact that the new code uses wx.FindWindowById to
find the parent instead of providing a direct reference to the window.
Unfortunately, keeping the old code-path would require us to include
wxpy_api.h (which will be included in the next wxPhoenix release) and
the introduction of SIP as new dependency.

```
[Thread 0x7fffd6739700 (LWP 29045) exited]
12:39:51: Debug: pthread_mutex_[timed]lock(): mutex not initialized

Thread 1 "pcbnew" received signal SIGSEGV, Segmentation fault.
0x77492d50 in wxMutex::Lock() () from /usr/lib/libwx_baseu-3.0.so.0
(gdb) backtrace
#0  0x77492d50 in wxMutex::Lock() () at
/usr/lib/libwx_baseu-3.0.so.0
#1  0x77826cfb in wxApp::DoIdle() () at
/usr/lib/libwx_gtk3u_core-3.0.so.0
#2  0x77826e94 in  () at /usr/lib/libwx_gtk3u_core-3.0.so.0
#3  0x752ee271 in g_main_context_dispatch () at
/usr/lib/libglib-2.0.so.0
#4  0x752eff89 in  () at /usr/lib/libglib-2.0.so.0
#5  0x752f0f62 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#6  0x758e41af in gtk_main () at /usr/lib/libgtk-3.so.0
#7  0x77843c46 in wxGUIEventLoop::DoRun() () at
/usr/lib/libwx_gtk3u_core-3.0.so.0
#8  0x77390bae in wxEventLoopBase::Run() () at
/usr/lib/libwx_baseu-3.0.so.0
#9  0x77355517 in wxAppConsoleBase::MainLoop() () at
/usr/lib/libwx_baseu-3.0.so.0
#10 0x55589955 in APP_SINGLE_TOP::OnRun() (this=0x556b1f50)
at kicad/common/single_top.cpp:186
#11 0x773dd4c8 in wxEntry(int&, wchar_t**) () at
/usr/lib/libwx_baseu-3.0.so.0
#12 0x55584a50 in main(int, char**) (argc=1,
argv=0x7fffd9e8) at kicad/common/single_top.cpp:260
```



Regards,
Thomas





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

Re: [Kicad-developers] 5.1

[Thomas Pointhuber]

Hi,

I made an GTK3 build with wx3.0.4 and didn't noticed more bugs than with
wx3.1.1 and GTK3 on a quick glance.

I'm using X11 as display manager, and run a Arch based system.

Regards,
Thomas

Am 19.10.18 um 11:53 schrieb Carsten Schoenert:
> Hello Seth,
> 
> Am 18.10.18 um 21:52 schrieb s...@hillbrand.org:
>> * sense flipped here *  Debian 9 = python-wxgtk only uses gtk2 and 
>> Debian 10 = python-wxgtk only uses gtk3
> 
> yes, and for wxpython3.0 there is currently no backport for stretch
> available and probably will never be due the massive reverse depends the
> uploader would be responsible for.
> 
> Also on the wxwidget3.0 side we have two libraries in the archive of
> unstable/sid and testing/buster.
> 
> libwxgtk3.0-{0v5,dev} vs. libwxgtk3.0-gtk3-{0v5,dev}
> 
> The first is build with GTK2 bindings, the latter with GTK3+ bindings.
> KiCad even in unstable is using the former packages. Debian is planning
> to drop these and do the transition over to the latter version for Buster!
> 
> https://release.debian.org/transitions/html/wxwidgets3.0-gtk3.html
> https://bugs.debian.org/894663
> 
> 5.0.1 is almost unusable if build with libwxgtk3.0-gtk3-dev and right
> now the KiCad package in testing would become RC if the transition to
> libwxgtk3.0-gtk3-{0v5,dev} would start.
> 
> And applications which using libwxgtk3.0-gtk3-0v5 aren't usable under
> Wayland. It's all a mess.
> 
> I haven't build a recent devel version of KiCad against this GTK3+ based
> library of wxwidget3.0 so I can't say if the current HEAD would be
> better usable if linkend against libwxgtk3.0-gtk3-0v5.
> 
> Maybe Thomas P. has done this already?
> 



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

Re: [Kicad-developers] 5.1

[Thomas Pointhuber]

Hi,

I agree that GTK3 should be a first class citizen of supported toolkit
in the future.

I have gtk3 builds running for testing purpose, and at the moment
scrolling is the most annoying issue in my opinion, which makes it
nearly unusable to simply zoom in/out reliable:

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

Another things I noticed:

* Loading a board means window is heavily flickering (including
disappearing UI for a short time)
* some gui elements (+/- for discrete number entries) look misscaled or
have overflow issues with other elements.

When python3 is merged, we can try to get wxPhoenix support into 5.1 as
well. For now only with Linux build support, but this is better than
having no scripting console at all.

Short question: what does USE_WX_GRAPHICS_CONTEXT change? I didn't see
any differences on my gtk3 builds.

Please note I'm running wx3.1 which seems to have fixed some gtk3 issues
other might experiencing.

Regards,
Thomas

Am 18.10.18 um 21:48 schrieb s...@hillbrand.org:
> On 2018-10-18 10:10, Wayne Stambaugh wrote:
>> Hi John,
>>
>> The legacy canvas in the pcb tools and gerbview is slated for removal
>> during v6 development.  I image it will happen fairly quickly after 5.1
>> is released.  I also expect there to be great wailing and gnashing of
>> teeth once it's removed but keeping it around doesn't make sense.  We
>> will just have to suck it up, deal with the backlash, and fix any
>> lingering issues in the new tool framework and router as quickly as
>> possible.
>>
>> Cheers,
>>
>> Wayne
> 
> Hi Wayne-
> 
> We should probably start moving the default build on some Linuxes over
> to gtk3 as the gtk2/3 conflicts were one of the prime drivers to the
> GAL-legacy switch in eeschema.  This requires turning on
> -DUSE_WX_GRAPHICS_CONTEXT as well for these linuxes.
> 
> Unfortunately, this is an either/or in that Debian9 (and derivatives in
> Ubuntu) doesn't provide a python-wxgtk built against gtk2 and Debian
> 10/Ubuntu 18.04 don't provide python-wxgtk built against gtk3.
> 
> If we are keeping the Legacy canvas for 5.1, we'll need to iron out GTK3
> bugs.  This is potentially a not insubstantial amount of work as right
> now, GTK3 legacy view in pcbnew and gerbview does not display anything
> and a very garbled display in footprint editor.
> 
> How much effort do we want to expend on keeping legacy running in new
> systems?  Should we consider disabling legacy canvas if we enable GTK3
> in the build?  FWIW, GTK3 works fine for page layout editor and the
> various buttons and menus as far as I have found so far.  Also, GAL
> works as I expect
> 
> -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



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

Re: [Kicad-developers] [Proposal] merge optional Python3 support

[Thomas Pointhuber]

Hi,

I rebased the branch and fixed the few bracket issues I found:
* https://github.com/pointhi/kicad-source-mirror/tree/python3

Now with eeschema-gal merged, it would be nice to get this into upstream
as well.

Regards,
Thomas

> I noticed some K curly bracket placement that needs to be fixed but
> other than that, I'm fine with pushing it once eeschema-gal is merged.
>
> Cheers,
>
> Wayne



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

Re: [Kicad-developers] New version of net selector up

[Thomas Pointhuber]

Hi Jeff,

It seems the text input allows hover, but clicking on the input itself
does not focus to it. When it's on hover the insertion point appears but
typing in anything does not result in any change of the field or selector:

https://cloud.oe5tpo.com/s/AYbzTDJfLEz6sTC

Regards, Thomas

Am 27.09.18 um 19:57 schrieb Jeff Young:
> Hi Thomas,
> 
> When you say you can’t enter text into the filter, does the insertion point 
> show up there and just not the text, or can you not focus on it at all?
> 
> I only changed the list-item-padding for MSW, so if you’re still getting a 
> much-too-long list it looks like GTK wants a smaller padding like MSW, and 
> only OSX needs the larger.
> 
> Thanks,
> Jeff.
> 
> 
>> On 27 Sep 2018, at 18:44, Thomas Pointhuber  wrote:
>>
>> Hi Jeff,
>>
>> I like the idea, but it still has some problems on my system:
>>
>> * I cannot enter any text into the filter field
>> * It still expands to the bottom of screen (at least there are now
>> scroll bars)
>>
>>
>> As sidenote, I was required to revert e456ecd0a15d3fb to get it actually
>> built on wx3.1:
>>
>>
>> ```
>> kicad-source-mirror/eeschema/dialogs/dialog_fields_editor_global.cpp:727:21:
>> error: no member named 'SetColumnWidth' in 'WX_GRID'
>>m_grid->SetColumnWidth( col, std::min( std::max( 50,
>> textWidth ), maxWidth ) );
>>~~  ^
>> kicad-source-mirror/eeschema/dialogs/dialog_fields_editor_global.cpp:729:21:
>> error: no member named 'SetColumnWidth' in 'WX_GRID'
>>m_grid->SetColumnWidth( col, std::min( std::max( 100,
>> textWidth ), maxWidth ) );
>>~~  ^
>> kicad-source-mirror/eeschema/dialogs/dialog_fields_editor_global.cpp:869:13:
>> error: no member named 'SetColumnWidth' in 'WX_GRID'
>>m_grid->SetColumnWidth( m_dataModel->GetColsCount() - 1, 50 );
>>~~  ^
>> 3 errors generated.
>> ```
>>
>>
>> Application: kicad
>> Version: (6.0.0-rc1-dev-626-g13d6358dc), debug build
>> Libraries:
>>wxWidgets 3.1.1
>>libcurl/7.61.1 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2
>> (+libidn2/2.0.4) nghttp2/1.33.0
>> Platform: Linux 4.18.9-arch1-1-ARCH x86_64, 64 bit, Little endian, wxGTK
>> Build Info:
>>wxWidgets: 3.1.1 (wchar_t,wx containers) GTK+ 2.24
>>Boost: 1.68.0
>>OpenCASCADE Community Edition: 6.9.1
>>Curl: 7.61.1
>>Compiler: Clang 6.0.1 with C++ ABI 1002
>>
>> Build settings:
>>USE_WX_GRAPHICS_CONTEXT=OFF
>>USE_WX_OVERLAY=OFF
>>KICAD_SCRIPTING=ON
>>KICAD_SCRIPTING_MODULES=ON
>>KICAD_SCRIPTING_WXPYTHON=OFF
>>KICAD_SCRIPTING_ACTION_MENU=ON
>>BUILD_GITHUB_PLUGIN=ON
>>KICAD_USE_OCE=ON
>>KICAD_USE_OCC=OFF
>>KICAD_SPICE=ON
>>
>> Regards, Thomas
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 



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

Re: [Kicad-developers] New version of net selector up

[Thomas Pointhuber]

Hi Jeff,

I like the idea, but it still has some problems on my system:

* I cannot enter any text into the filter field
* It still expands to the bottom of screen (at least there are now
scroll bars)


As sidenote, I was required to revert e456ecd0a15d3fb to get it actually
built on wx3.1:


```
kicad-source-mirror/eeschema/dialogs/dialog_fields_editor_global.cpp:727:21:
error: no member named 'SetColumnWidth' in 'WX_GRID'
m_grid->SetColumnWidth( col, std::min( std::max( 50,
textWidth ), maxWidth ) );
~~  ^
kicad-source-mirror/eeschema/dialogs/dialog_fields_editor_global.cpp:729:21:
error: no member named 'SetColumnWidth' in 'WX_GRID'
m_grid->SetColumnWidth( col, std::min( std::max( 100,
textWidth ), maxWidth ) );
~~  ^
kicad-source-mirror/eeschema/dialogs/dialog_fields_editor_global.cpp:869:13:
error: no member named 'SetColumnWidth' in 'WX_GRID'
m_grid->SetColumnWidth( m_dataModel->GetColsCount() - 1, 50 );
~~  ^
3 errors generated.
```


Application: kicad
Version: (6.0.0-rc1-dev-626-g13d6358dc), debug build
Libraries:
wxWidgets 3.1.1
libcurl/7.61.1 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2
(+libidn2/2.0.4) nghttp2/1.33.0
Platform: Linux 4.18.9-arch1-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.1.1 (wchar_t,wx containers) GTK+ 2.24
Boost: 1.68.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.61.1
Compiler: Clang 6.0.1 with C++ ABI 1002

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON

Regards, Thomas



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

Re: [Kicad-developers] [PATCH] Print stacktrace when SIGSEGV or SIGABRT appears

[Thomas Pointhuber]

Hi Wayne,

thanks for reminder. I implemented a simple compile time switch to allow
maintainers to enable/disable crash reporting.

Regards, Thomas

Am 25.09.18 um 18:38 schrieb Wayne Stambaugh:
> Thomas,
> 
> I looked at your branch and it look like you haven't made your debug
> report code a build option yet.  This will definitely have to be done in
> order to merger this because we cannot guarantee full core dump reports
> so packagers will have to be able to build without the reporting in some
> cases.  I know it's less than ideal but unless you can ensure that a
> full crash dump can be included as part of the report, I see what other
> choice there is.
> 
> Cheers,
> 
> Wayne
> 
> On 9/22/2018 5:02 AM, Thomas Pointhuber wrote:
>> Hi,
>>
>> I fixed the mysn bug on my branch:
>> * https://github.com/pointhi/kicad-source-mirror/tree/crash_report
>>
>> Allowing people to enable/disable this feature sounds like a good idea.
>>
>> I tried gcore on linux to create coredumps of an running process, but
>> because it needs root privileges it cannot simply be integrated into the
>> reporter (it would be possible with PolKit I think).
>>
>> There also exists https://code.google.com/archive/p/google-coredumper
>> but it seems to be broken on newer linux systems (according to
>> stackoverflow)
>>
>> Regards, Thomas
>>
>> Am 22.09.18 um 04:05 schrieb Seth Hillbrand:
>>> Hi Simon-
>>>
>>> Am Fr., 21. Sep. 2018 um 18:24 Uhr schrieb Simon Richter
>>> mailto:simon.rich...@hogyros.de>>:
>>>
>>> Hi,
>>>
>>> On 22.09.2018 02:12, Seth Hillbrand wrote:
>>>
>>> >>    It will need a way to turn it off.
>>>
>>> > Say a command-line switch? e.g --disable-crashreporter
>>>
>>> The distro maintainers probably need a compile time option for apport,
>>> I'd prefer that as well because I don't have to remember it when
>>> starting.
>>>
>>>
>>> OK, how about a CMAKE flag KICAD_CRASHREPORTER_DEFAULT=OFF/ON?  Then we
>>> have two command line flags
>>> --enable-crashreporter/--disable-crashreporter to override the default.
>>>
>>> Thoughts?
>>>
>>> -S
>>>
>>> ___
>>> Mailing list: https://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
> 



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

Re: [Kicad-developers] [PATCH] Print stacktrace when SIGSEGV or SIGABRT appears

[Thomas Pointhuber]

Hi,

I fixed the mysn bug on my branch:
* https://github.com/pointhi/kicad-source-mirror/tree/crash_report

Allowing people to enable/disable this feature sounds like a good idea.

I tried gcore on linux to create coredumps of an running process, but
because it needs root privileges it cannot simply be integrated into the
reporter (it would be possible with PolKit I think).

There also exists https://code.google.com/archive/p/google-coredumper
but it seems to be broken on newer linux systems (according to
stackoverflow)

Regards, Thomas

Am 22.09.18 um 04:05 schrieb Seth Hillbrand:
> Hi Simon-
> 
> Am Fr., 21. Sep. 2018 um 18:24 Uhr schrieb Simon Richter
> mailto:simon.rich...@hogyros.de>>:
> 
> Hi,
> 
> On 22.09.2018 02:12, Seth Hillbrand wrote:
> 
> >>    It will need a way to turn it off.
> 
> > Say a command-line switch? e.g --disable-crashreporter
> 
> The distro maintainers probably need a compile time option for apport,
> I'd prefer that as well because I don't have to remember it when
> starting.
> 
> 
> OK, how about a CMAKE flag KICAD_CRASHREPORTER_DEFAULT=OFF/ON?  Then we
> have two command line flags
> --enable-crashreporter/--disable-crashreporter to override the default.
> 
> Thoughts?
> 
> -S
> 
> ___
> Mailing list: https://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

Re: [Kicad-developers] [PATCH] Print stacktrace when SIGSEGV or SIGABRT appears

[Thomas Pointhuber]

Hi Wayne,

thanks for proposing wxDebugReport. I didn't knew about that. I fixed
the format issues using clang-format, and fixed a little windows bug as
well (which was found by an wx developer). Furthermore I added some
preprocessor macro to not overwrite AddContext for wx versions > 3.1.1
because It's already fixed in upstream since a day and will be included
in future releases :)

https://github.com/wxWidgets/wxWidgets/pull/940

Personally, I only tested this on Linux x64 with wx 3.1

Regards,
Thomas

Am 21.09.18 um 16:01 schrieb Wayne Stambaugh:
> Hi Thomas,
> 
> I like this much better than your previous patch.  What platforms have
> you tested this on?  Also, please fix the coding policy[1] issues in
> your patch.  You can use uncrustify or clang-format if you don't want to
> do it by hand.
> 
> Cheers,
> 
> Wayne
> 
> [1]:
> http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html
> 
> On 9/20/2018 5:49 AM, Thomas Pointhuber wrote:
>> Hi Tom,
>>
>> based on your proposal I fixed the Stack Walker (I think it should also
>> be fixed upstream). I was required to duplicate quite some wx code and
>> we probably need to add an additional copyright notice.
>>
>> The stack now looks like this, and I verified that I can find the
>> location of a crash using addr2line:
>> ```
>>   
>> > module="pcbnew/pcbnew"/>
>> > module="pcbnew/pcbnew"/>
>> > module="pcbnew/pcbnew"/>
>> > module="/usr/lib/libwx_baseu-3.1.so.1"/>
>> > module="/usr/lib/libpthread.so.0"/>
>> > address="7f60af434bb1" module="/usr/lib/libc.so.6"/>
>> > module="/usr/lib/libglib-2.0.so.0"/>
>> > address="7f60ae796f62" module="/usr/lib/libglib-2.0.so.0"/>
>> > address="7f60aedb914e" module="/usr/lib/libgtk-x11-2.0.so.0"/>
>> > offset="0083" address="7f60b1acc463"
>> module="/usr/lib/libwx_gtk2u_core-3.1.so.1"/>
>> ...
>> ```
>>
>> the current code is more or less a minimal implementation. It would be a
>> good idea to add the build parameters like displayed in about_config,
>> configuration files, environment variables,... in the future as well.
>>
>> Regards,
>> Thomas
>>
>> Am 19.09.18 um 20:36 schrieb Tomasz Wlostowski:
>>> On 19/09/18 20:13, Thomas Pointhuber wrote:
>>>>
>>>> I rewrote it to use wxDebugReport and wxHandleFatalExceptions. What I
>>>> noticed (at least for my build setup), the stack-trace is unusable in
>>>> this version for me because it lacks all kicad internals:
>>>
>>> Hi Thomas,
>>>
>>> I like a lot your idea of having a builtin crash reporter (especially
>>> under Windows/OSX where people struggle to get a stack trace, Linux
>>> users sooner or later are forced to figure out how to use a
>>> debugger...). I also second Wayne's comment that it must work on all
>>> platforms, so please no glibc-specific code.
>>>
>>> wxDebugReport is IMHO a good starting point, but for some reasons that
>>> are beyond my understanding, wxWidgets doesn't output raw addresses of
>>> the functions in the call stack and if there's no symbols in the file
>>> (and its dependent DLLs), the trace file is indeed useless.
>>>
>>> Luckily wxStackFrame contains all the necessary information. The
>>> function to blame is XmlStackWalker::OnStackFrame(...). A quick hack
>>> like the one below can add raw addresses to the XML dump:
>>>
>>> -- snip --
>>>
>>> if(func.empty())
>>> func = wxT("");
>>>
>>> nodeFrame->AddAttribute(wxT("function"), func);
>>> HexProperty(nodeFrame, wxT("offset"), frame.GetOffset());
>>> HexProperty(nodeFrame, wxT("address"), reinterpret_cast>> unsigned int>(frame.GetAddress()));
>>>
>>> -- snip --
>>>
>>> Cheers,
>>> Tom
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Pos

Re: [Kicad-developers] [PATCH] Print stacktrace when SIGSEGV or SIGABRT appears

[Thomas Pointhuber]

Hi Tom,

based on your proposal I fixed the Stack Walker (I think it should also
be fixed upstream). I was required to duplicate quite some wx code and
we probably need to add an additional copyright notice.

The stack now looks like this, and I verified that I can find the
location of a crash using addr2line:
```
  










...
```

the current code is more or less a minimal implementation. It would be a
good idea to add the build parameters like displayed in about_config,
configuration files, environment variables,... in the future as well.

Regards,
Thomas

Am 19.09.18 um 20:36 schrieb Tomasz Wlostowski:
> On 19/09/18 20:13, Thomas Pointhuber wrote:
>>
>> I rewrote it to use wxDebugReport and wxHandleFatalExceptions. What I
>> noticed (at least for my build setup), the stack-trace is unusable in
>> this version for me because it lacks all kicad internals:
> 
> Hi Thomas,
> 
> I like a lot your idea of having a builtin crash reporter (especially
> under Windows/OSX where people struggle to get a stack trace, Linux
> users sooner or later are forced to figure out how to use a
> debugger...). I also second Wayne's comment that it must work on all
> platforms, so please no glibc-specific code.
> 
> wxDebugReport is IMHO a good starting point, but for some reasons that
> are beyond my understanding, wxWidgets doesn't output raw addresses of
> the functions in the call stack and if there's no symbols in the file
> (and its dependent DLLs), the trace file is indeed useless.
> 
> Luckily wxStackFrame contains all the necessary information. The
> function to blame is XmlStackWalker::OnStackFrame(...). A quick hack
> like the one below can add raw addresses to the XML dump:
> 
> -- snip --
> 
> if(func.empty())
>   func = wxT("");
> 
> nodeFrame->AddAttribute(wxT("function"), func);
> HexProperty(nodeFrame, wxT("offset"), frame.GetOffset());
> HexProperty(nodeFrame, wxT("address"), reinterpret_cast unsigned int>(frame.GetAddress()));
> 
> -- snip --
> 
> Cheers,
> Tom
> 
From dcb15b221033c69b2afcf186c8f9f9cdb7137ce2 Mon Sep 17 00:00:00 2001
From: Thomas Pointhuber 
Date: Wed, 19 Sep 2018 17:45:27 +0200
Subject: [PATCH] Add initial debug reporter to handle crashes

Based on wxDebugReportCompress, but with some adjustments to have
an actual useful stacktrace. To do this some code parts of wx had
to be duplicated to be able to overwrite them.

To convert the offset to actual lines "addr2line" can be used
---
 CMakeLists.txt  |   2 +-
 common/CMakeLists.txt   |   1 +
 common/debug_report.cpp | 257 
 common/single_top.cpp   |  12 +-
 include/debug_report.h  |  57 +
 kicad/kicad.cpp |  12 +-
 6 files changed, 336 insertions(+), 5 deletions(-)
 create mode 100644 common/debug_report.cpp
 create mode 100644 include/debug_report.h

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 903835f24..6cfc08f44 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -575,7 +575,7 @@ add_definitions( -DWX_COMPATIBILITY )
 # See line 49 of CMakeModules/FindwxWidgets.cmake
 set( wxWidgets_CONFIG_OPTIONS ${wxWidgets_CONFIG_OPTIONS} --static=no )
 
-find_package( wxWidgets 3.0.0 COMPONENTS gl aui adv html core net base xml stc REQUIRED )
+find_package( wxWidgets 3.0.0 COMPONENTS gl aui adv html core net base xml stc qa REQUIRED )
 
 # Include wxWidgets macros.
 include( ${wxWidgets_USE_FILE} )
diff --git a/common/CMakeLists.txt b/common/CMakeLists.txt
index dadfad1ae..6f345f9c1 100644
--- a/common/CMakeLists.txt
+++ b/common/CMakeLists.txt
@@ -256,6 +256,7 @@ set( COMMON_SRCS
 confirm.cpp
 convert_basic_shapes_to_polygon.cpp
 copy_to_clipboard.cpp
+debug_report.cpp
 dialog_shim.cpp
 displlst.cpp
 draw_frame.cpp
diff --git a/common/debug_report.cpp b/common/debug_report.cpp
new file mode 100644
index 0..995305803
--- /dev/null
+++ b/common/debug_report.cpp
@@ -0,0 +1,257 @@
+/*
+ * This program source code file is part of KiCad, a free EDA CAD application.
+ *
+ * Copyright (C) 2017 KiCad Developers, see CHANGELOG.txt for contributors.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, you may find one here:
+ * http://www.gnu.org/li

Re: [Kicad-developers] [PATCH] Print stacktrace when SIGSEGV or SIGABRT appears

[Thomas Pointhuber]

Hi,

I rewrote it to use wxDebugReport and wxHandleFatalExceptions. What I
noticed (at least for my build setup), the stack-trace is unusable in
this version for me because it lacks all kicad internals:

```
  














  
```

compared to the stack-trace of glibc, which allows actual debugging
using addr2line:

```
/usr/lib/libc.so.6(+0x37e00)[0x7fa71d60be00]
/usr/lib/libc.so.6(__poll+0x51)[0x7fa71d6c4bb1]
/usr/lib/libglib-2.0.so.0(+0x6cee0)[0x7fa71c82aee0]
/usr/lib/libglib-2.0.so.0(g_main_loop_run+0xd2)[0x7fa71c82bf62]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xc3)[0x7fa71d0c2df3]
/usr/lib/libwx_gtk2u_core-3.1.so.1(_ZN14wxGUIEventLoop5DoRunEv+0x25)[0x7fa71fc9b155]
/usr/lib/libwx_baseu-3.1.so.1(_ZN15wxEventLoopBase3RunEv+0x93)[0x7fa71f3f55c3]
/usr/lib/libwx_baseu-3.1.so.1(_ZN16wxAppConsoleBase8MainLoopEv+0x56)[0x7fa71f3b7f36]
pcbnew/pcbnew(+0x37035)[0x55cc4c3d6035]
/usr/lib/libwx_baseu-3.1.so.1(_Z7wxEntryRiPPw+0x45)[0x7fa71f4480d5]
pcbnew/pcbnew(+0x32130)[0x55cc4c3d1130]
/usr/lib/libc.so.6(__libc_start_main+0xf3)[0x7fa71d5f8223]
pcbnew/pcbnew(_start+0x2e)[0x55cc4c3d0f9e]
```

The easiest fix would be to simply copy this stack-trace into the
debug-report as well, if glibc is available.

@Simon,

while it is true that we cannot rely on defined behaviour, most of the
time the stuff is still working. In my implementation, I tried to keep
the amount of called functions low and use stateless functions if
possible. This should prevent most possible errors while executing it.

Nevertheless, I think trying to get some debug info is still better than
simply crash. Using wxDebugReport would mean we have to execute way more
code to get an report, but with the advantage to get more information
into it as well (and platform independent).

Regards, Thomas

Am 19.09.18 um 19:48 schrieb Simon Richter:
> Hi,
> 
> On 19.09.2018 18:38, Thomas Pointhuber wrote:
> 
>> For now, it uses the glibc backtrace function to print a basic
>> stack-trace onto the console, and if possible a crash dump file in the
>> current working directory.
> 
> Then it needs to at least be made glibc specific.
> 
> I'm not fond of these debugging aides inside programs, because IMO
> programs should do one thing and one thing only. Crashed programs are
> crashed, and should not try to do anything that may depend on the
> program state. That most likely includes formatted output.
> 
> Ubuntu, Windows and MacOS have dedicated crash reporting tools that work
> from outside the crashed process and know how to capture all threads and
> full memory contents.
> 
> For that to work we'd need to archive debug information and match it
> against crash reports.
> 
>Simon
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 



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] [PATCH] Print stacktrace when SIGSEGV or SIGABRT appears

[Thomas Pointhuber]

Hi,

I wrote some basic crash-handler based on signal handler code published
on the mailinglist some time ago:

* https://lists.launchpad.net/kicad-developers/msg27148.html

For now, it uses the glibc backtrace function to print a basic
stack-trace onto the console, and if possible a crash dump file in the
current working directory.

Unfortunately printing pretty stack-traces is not easy, which means at
the moment users need to manually prettify them when required. To do
this the tools addr2line and c++filt can be used to find the actual
location of the crash.

Nevertheless, it is better than nothing at all. And it could be
especially helpful to find rare crashes which are hard to reproduce.

Regards, Thomas
From 36b475a828e0587069a31c4163908bcfefb7 Mon Sep 17 00:00:00 2001
From: Thomas Pointhuber 
Date: Wed, 19 Sep 2018 17:45:27 +0200
Subject: [PATCH] Print stacktrace when SIGSEGV or SIGABRT appears

Based on the Signal Handler code of John Beard:
* https://lists.launchpad.net/kicad-developers/msg27148.html

To convert the addresses to actual lines "addr2line" can be used
To demangle the symbol names "c++filt" can be used
---
 common/CMakeLists.txt |  1 +
 common/app_signal_handler.cpp | 95 +++
 common/single_top.cpp |  5 ++
 include/app_signal_handler.h  | 67 
 kicad/kicad.cpp   |  5 ++
 5 files changed, 173 insertions(+)
 create mode 100644 common/app_signal_handler.cpp
 create mode 100644 include/app_signal_handler.h

diff --git a/common/CMakeLists.txt b/common/CMakeLists.txt
index dadfad1ae..499baa635 100644
--- a/common/CMakeLists.txt
+++ b/common/CMakeLists.txt
@@ -241,6 +241,7 @@ set( COMMON_SRCS
 ${COMMON_PAGE_LAYOUT_SRCS}
 ${COMMON_PREVIEW_ITEMS_SRCS}
 ${PLOTTERS_CONTROL_SRCS}
+app_signal_handler.cpp
 base_struct.cpp
 bezier_curves.cpp
 bin_mod.cpp
diff --git a/common/app_signal_handler.cpp b/common/app_signal_handler.cpp
new file mode 100644
index 0..3cf9dd6db
--- /dev/null
+++ b/common/app_signal_handler.cpp
@@ -0,0 +1,95 @@
+/*
+ * This program source code file is part of KiCad, a free EDA CAD application.
+ *
+ * Copyright (C) 2017 KiCad Developers, see CHANGELOG.txt for contributors.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, you may find one here:
+ * http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
+ * or you may search the http://www.gnu.org website for the version 2 license,
+ * or you may write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA
+ */
+
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+#define BACKTRACE_ARRAY_SIZE 64
+#define TMP_BUFFER_SIZE 64
+
+
+void APP_SIGNAL_HANDLER::RegisterSignalHandler( int sig, SigHandler handler )
+{
+signal( sig, handler );
+}
+
+void APP_SIGNAL_HANDLER::BacktraceSignalHandler( int sig )
+{
+APP_SIGNAL_HANDLER::WriteBacktraceReport( STDERR_FILENO, sig );
+
+time_t timer;
+struct tm* tm_info;
+
+time(  );
+tm_info = localtime(  );
+
+char tmp_buffer[TMP_BUFFER_SIZE];
+
+// Write crashdump into the current working directory
+strftime( tmp_buffer, TMP_BUFFER_SIZE, "kicad%Y%m%d_%H%M%S.crash", tm_info );
+dprintf( STDERR_FILENO, "\nwrite crashdump to: \"%s\"\n", tmp_buffer );
+int fd = open( tmp_buffer, O_CREAT|O_WRONLY|O_APPEND, S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH );
+if( fd >= 0 )
+{
+dprintf( fd, "=== KiCad Crashdump ===\n" );
+
+strftime( tmp_buffer, TMP_BUFFER_SIZE, "%Y-%m-%d %H:%M:%S", tm_info );
+dprintf( fd, "Time: %s\n", tmp_buffer );
+
+APP_SIGNAL_HANDLER::WriteBacktraceReport( fd, sig );
+
+close( fd );
+}
+else
+{
+dprintf( STDERR_FILENO, "[unable to write report to disk]\n" );
+}
+
+
+quick_exit( EXIT_FAILURE );
+}
+
+
+void APP_SIGNAL_HANDLER::WriteBacktraceReport( int fd, int sig, int skip )
+{
+dprintf( fd, "Error: signal %d (%s)\n", sig, strsignal( sig ) );
+
+dprintf( fd, "Backtrace:\n" );
+
+void *array[BACKTRACE_ARRAY_SIZE];
+size_t size;
+
+size = backtrace( array, BACKTRACE_ARRAY_SIZE );
+
+backtrace_symbols_fd( array+skip, size-skip, fd );
+
+if( size == BACKTRACE_ARRAY_SIZE )
+{
+dprintf( fd, &

Re: [Kicad-developers] GAL canvas strategy - testers needed!

[Thomas Pointhuber]

Hi,

Navigating in the schematic hierarchy seems to be broken a bit. Just
zoom in a bit and enter/leave sub-sheets. You will see the cursor
warping to some weird position, and the sheet is not displayed as whole.
In my case often a blank area appears after entering/leaving the
sub-sheet. The expected behaviour would be no mouse warping and showing
the full schematic sheet.

Application: eeschema
Version: (6.0.0-rc1-dev-470-ge78a310f4), debug build
Libraries:
wxWidgets 3.1.1
libcurl/7.61.1 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2
(+libidn2/2.0.4) nghttp2/1.32.0
Platform: Linux 4.18.7-arch1-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.1.1 (wchar_t,wx containers) GTK+ 2.24
Boost: 1.67.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.61.1
Compiler: Clang 6.0.1 with C++ ABI 1002

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON



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] [Proposal] merge optional Python3 support

[Thomas Pointhuber]

Hi,

I posted this proposal on launchpad, but no answers so far:
* see: https://bugs.launchpad.net/kicad/+bug/1785119

As some already noticed, I made patches to get Python 3 working with
KiCad (has to be explicit enabled). Windows and Linux tests were
successful and I think it can be merged to allow more widespread
testing. Default builds will be still running Python2, but this would
allow for example Linux distributions to build with Python3 when they
drop Python2 support.

My work can be viewed on:
* https://github.com/pointhi/kicad-source-mirror/tree/python3

Regards, Thomas



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

Re: [Kicad-developers] [PATCH] Fix focus bug and possible race-condition for path deletion

[Thomas Pointhuber]

Ping: please review and merge this little patch

On 30.08.18 14:23, Thomas Pointhuber wrote:
> Hi,
> 
> a small follow-up patch for
> https://bugs.launchpad.net/kicad/+bug/1788873 which fixes some remaining
> issues
> 
> Regards, Thomas
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 



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] [PATCH] Fix focus bug and possible race-condition for path deletion

[Thomas Pointhuber]

Hi,

a small follow-up patch for
https://bugs.launchpad.net/kicad/+bug/1788873 which fixes some remaining
issues

Regards, Thomas
From 7599429256c815142272db6bc1f0e8be64f174de Mon Sep 17 00:00:00 2001
From: Thomas Pointhuber 
Date: Thu, 30 Aug 2018 14:21:01 +0200
Subject: [PATCH] Fix focus bug and possible race-condition for path deletion
 dialog

---
 common/dialogs/dialog_configure_paths.cpp | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/common/dialogs/dialog_configure_paths.cpp b/common/dialogs/dialog_configure_paths.cpp
index 6d8586a6a..5266a47a0 100644
--- a/common/dialogs/dialog_configure_paths.cpp
+++ b/common/dialogs/dialog_configure_paths.cpp
@@ -374,7 +374,7 @@ void DIALOG_CONFIGURE_PATHS::OnRemoveEnvVar( wxCommandEvent& event )
 {
 int curRow = m_EnvVars->GetGridCursorRow();
 
-if( curRow < 0 )
+if( curRow < 0 || m_EnvVars->GetNumberRows() <= curRow )
 return;
 else if( IsEnvVarImmutable( m_EnvVars->GetCellValue( curRow, EV_NAME_COL ) ) )
 {
@@ -394,11 +394,8 @@ void DIALOG_CONFIGURE_PATHS::OnDeleteSearchPath( wxCommandEvent& event )
 {
 int curRow = m_SearchPaths->GetGridCursorRow();
 
-if( !m_SearchPaths->HasFocus() || curRow < 0 )
-{
-m_SearchPaths->SetFocus();
+if( curRow < 0 || m_SearchPaths->GetNumberRows() <= curRow )
 return;
-}
 
 m_SearchPaths->CommitPendingChanges( true /* silent mode; we don't care if it's valid */ );
 m_SearchPaths->DeleteRows( curRow, 1 );
-- 
2.18.0



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] [PATCH] Modify style of the action plugin panel to follow common style, fix Assert

[Thomas Pointhuber]

Hi,

I modified panel_pcbnew_action_plugins_base to follow the default style
of the table with button up/down. Furthermore, I found out the code
raises an assert when no plugins are present, and fixed this issue as well.

Patch is available on GitHub as well:
https://github.com/pointhi/kicad-source-mirror/commits/action_plugin_panel

Regards, Thomas
From 6a94d1baa506272565fe1959cb1950ba62be66fe Mon Sep 17 00:00:00 2001
From: Thomas Pointhuber 
Date: Mon, 27 Aug 2018 13:37:11 +0200
Subject: [PATCH] Modify style of the action plugin panel to follow common
 style

and fix of an assert:
* m_grid->DeleteRows does not like to get a numRows of zero
---
 .../dialogs/panel_pcbnew_action_plugins.cpp   |  7 ++--
 .../panel_pcbnew_action_plugins_base.cpp  | 23 ++-
 .../panel_pcbnew_action_plugins_base.fbp  | 38 ---
 .../panel_pcbnew_action_plugins_base.h|  2 +-
 4 files changed, 42 insertions(+), 28 deletions(-)

diff --git a/pcbnew/dialogs/panel_pcbnew_action_plugins.cpp b/pcbnew/dialogs/panel_pcbnew_action_plugins.cpp
index 3887fe9b2..d9e1d93aa 100644
--- a/pcbnew/dialogs/panel_pcbnew_action_plugins.cpp
+++ b/pcbnew/dialogs/panel_pcbnew_action_plugins.cpp
@@ -35,8 +35,8 @@ PANEL_PCBNEW_ACTION_PLUGINS::PANEL_PCBNEW_ACTION_PLUGINS( PCB_EDIT_FRAME* aFrame
 m_genericIcon = KiBitmap( hammer_xpm );
 m_grid->PushEventHandler( new GRID_TRICKS( m_grid ) );
 
-m_moveUpButton->SetBitmap( KiBitmap( up_xpm ) );
-m_moveDownButton->SetBitmap( KiBitmap( down_xpm ) );
+m_moveUpButton->SetBitmap( KiBitmap( small_up_xpm ) );
+m_moveDownButton->SetBitmap( KiBitmap( small_down_xpm ) );
 m_reloadButton->SetBitmap( KiBitmap( refresh_xpm ) );
 }
 
@@ -155,7 +155,8 @@ bool PANEL_PCBNEW_ACTION_PLUGINS::TransferDataFromWindow()
 bool PANEL_PCBNEW_ACTION_PLUGINS::TransferDataToWindow()
 {
 m_grid->Freeze();
-m_grid->DeleteRows( 0, m_grid->GetNumberRows() );
+if( m_grid->GetNumberRows() != 0 )
+m_grid->DeleteRows( 0, m_grid->GetNumberRows() );
 
 const auto& orderedPlugins = m_frame->GetOrderedActionPlugins();
 m_grid->AppendRows( orderedPlugins.size() );
diff --git a/pcbnew/dialogs/panel_pcbnew_action_plugins_base.cpp b/pcbnew/dialogs/panel_pcbnew_action_plugins_base.cpp
index d8f890904..98fae006b 100644
--- a/pcbnew/dialogs/panel_pcbnew_action_plugins_base.cpp
+++ b/pcbnew/dialogs/panel_pcbnew_action_plugins_base.cpp
@@ -1,5 +1,5 @@
 ///
-// C++ code generated with wxFormBuilder (version Jul 11 2018)
+// C++ code generated with wxFormBuilder (version Jul 14 2018)
 // http://www.wxformbuilder.org/
 //
 // PLEASE DO *NOT* EDIT THIS FILE!
@@ -14,7 +14,7 @@
 PANEL_PCBNEW_ACTION_PLUGINS_BASE::PANEL_PCBNEW_ACTION_PLUGINS_BASE( wxWindow* parent, wxWindowID id, const wxPoint& pos, const wxSize& size, long style ) : wxPanel( parent, id, pos, size, style )
 {
 	wxBoxSizer* bPanelSizer;
-	bPanelSizer = new wxBoxSizer( wxHORIZONTAL );
+	bPanelSizer = new wxBoxSizer( wxVERTICAL );
 	
 	wxBoxSizer* bGridSizer;
 	bGridSizer = new wxBoxSizer( wxVERTICAL );
@@ -56,25 +56,28 @@ PANEL_PCBNEW_ACTION_PLUGINS_BASE::PANEL_PCBNEW_ACTION_PLUGINS_BASE( wxWindow* pa
 	bPanelSizer->Add( bGridSizer, 1, wxALIGN_LEFT|wxEXPAND|wxLEFT, 0 );
 	
 	wxBoxSizer* bButtonsSizer;
-	bButtonsSizer = new wxBoxSizer( wxVERTICAL );
+	bButtonsSizer = new wxBoxSizer( wxHORIZONTAL );
 	
 	m_moveUpButton = new wxBitmapButton( this, wxID_ANY, wxNullBitmap, wxDefaultPosition, wxDefaultSize, 0 );
-	m_moveUpButton->SetMinSize( wxSize( 32,32 ) );
+	m_moveUpButton->SetMinSize( wxSize( 30,30 ) );
 	
-	bButtonsSizer->Add( m_moveUpButton, 0, wxALIGN_TOP|wxALL, 5 );
+	bButtonsSizer->Add( m_moveUpButton, 0, wxLEFT|wxRIGHT, 5 );
 	
 	m_moveDownButton = new wxBitmapButton( this, wxID_ANY, wxNullBitmap, wxDefaultPosition, wxDefaultSize, 0 );
-	m_moveDownButton->SetMinSize( wxSize( 32,32 ) );
+	m_moveDownButton->SetMinSize( wxSize( 30,30 ) );
 	
-	bButtonsSizer->Add( m_moveDownButton, 0, wxALL, 5 );
+	bButtonsSizer->Add( m_moveDownButton, 0, wxRIGHT, 5 );
+	
+	
+	bButtonsSizer->Add( 0, 0, 0, wxEXPAND|wxLEFT|wxRIGHT, 5 );
 	
 	m_reloadButton = new wxBitmapButton( this, wxID_ANY, wxNullBitmap, wxDefaultPosition, wxDefaultSize, 0 );
-	m_reloadButton->SetMinSize( wxSize( 32,32 ) );
+	m_reloadButton->SetMinSize( wxSize( 30,30 ) );
 	
-	bButtonsSizer->Add( m_reloadButton, 0, wxALL, 5 );
+	bButtonsSizer->Add( m_reloadButton, 0, wxLEFT|wxRIGHT, 5 );
 	
 	
-	bPanelSizer->Add( bButtonsSizer, 0, wxALIGN_RIGHT|wxALIGN_TOP, 0 );
+	bPanelSizer->Add( bButtonsSizer, 0, wxEXPAND, 0 );
 	
 	
 	this->SetSizer( bPanelSizer );
diff --git a/pcbnew/dialogs/panel_pcbnew_action_plugins_base.fbp b/pcbnew/dialogs/panel_pcbnew_action_plugins_base.fbp
index 6c91f1fd1..2f67cd812 100644
--- a/pcbnew/dialogs/p

[Kicad-developers] [PATCH] Do not show footprint wizard menue entry when scripting is disabled

[Thomas Pointhuber]

Hi,

while poking around the code I apparently found some missing #ifdef
statements.

Regards, Thomas
From 41dc18ac5c96313a465c2b721dc756bb7a2be79b Mon Sep 17 00:00:00 2001
From: Thomas Pointhuber 
Date: Sat, 25 Aug 2018 18:30:34 +0200
Subject: [PATCH] Do not show footprint wizard menu when scripting is disabled

---
 pcbnew/footprint_tree_pane.cpp  | 2 ++
 pcbnew/menubar_footprint_editor.cpp | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/pcbnew/footprint_tree_pane.cpp b/pcbnew/footprint_tree_pane.cpp
index dd8d92309..f6e124e83 100644
--- a/pcbnew/footprint_tree_pane.cpp
+++ b/pcbnew/footprint_tree_pane.cpp
@@ -66,8 +66,10 @@ FOOTPRINT_TREE_PANE::FOOTPRINT_TREE_PANE( FOOTPRINT_EDIT_FRAME* aParent )
 menuLibrary->AppendSeparator();
 AddMenuItem( menuLibrary.get(), ID_MODEDIT_NEW_MODULE, _( "New " ),
  KiBitmap( new_component_xpm ) );
+#ifdef KICAD_SCRIPTING
 AddMenuItem( menuLibrary.get(), ID_MODEDIT_NEW_MODULE_FROM_WIZARD, _( " Footprint..." ),
  KiBitmap( new_component_xpm ) );
+#endif
 AddMenuItem( menuLibrary.get(), ID_MODEDIT_IMPORT_PART, _( " Footprint..." ),
  KiBitmap( import_part_xpm ) );
 
diff --git a/pcbnew/menubar_footprint_editor.cpp b/pcbnew/menubar_footprint_editor.cpp
index 8ce386500..0e80039a3 100644
--- a/pcbnew/menubar_footprint_editor.cpp
+++ b/pcbnew/menubar_footprint_editor.cpp
@@ -70,10 +70,12 @@ void FOOTPRINT_EDIT_FRAME::ReCreateMenuBar()
  text, _( "Create a new footprint" ),
  KiBitmap( new_footprint_xpm ) );
 
+#ifdef KICAD_SCRIPTING
 AddMenuItem( fileMenu, ID_MODEDIT_NEW_MODULE_FROM_WIZARD,
  _( " Footprint..." ),
  _( "Create a new footprint using the footprint wizard" ),
  KiBitmap( module_wizard_xpm ) );
+#endif
 
 fileMenu->AppendSeparator();
 
-- 
2.18.0



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] [PATCH] get initial Python 3 support

[Thomas Pointhuber]

Hi,

I managed to get KiCad to run with Python 3 as well as did some quick
verification that basic methods are working using CLI (loading boards,
calling a method of it).

Bugreport: https://bugs.launchpad.net/kicad/+bug/1785119

My Branch: https://github.com/pointhi/kicad-source-mirror/tree/python3

scripting inside of kicad was not tested because I'm not really familiar
with it right now, as well as because of known wx problems with that stuff.

For now it can be enabled using -DKICAD_SCRIPTING_PYTHON3=ON
It is not possible to export modules for python 2 and python 3 with one
build at the moment, but this should a thing which can be fixed in the
build-script.

I made some small changes to existing python code to get it working on
both versions. To my knowledge and tests the scripts should not have
changed behavior.

Regards, Thomas



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

Re: [Kicad-developers] [PATCH] Python FP wizard helper: docstrings and rounded/chamfered rects

[Thomas Pointhuber]

Hi

As Nick already mentioned, I did one of the last attempts of a
high-level abstraction. The goal would be to have this as proposal for
an official API in the KiCad 6 release (and I will likely carry on with
the work on July).

My goal would be to have a "pythonic" and natural to use API, which
means to not represent the internal data structures in a 1:1 fashion.
This therefore requires me to combine/split kicad objects into python
object of different structure, but I think I already did some good
examples how that could work out.

I am happy to get any input for the current solution and ideas for
further improvements.

Regards, Thomas

Am 2018-06-12 um 15:47 schrieb Nick Østergaard:
> I am not sure if this will slightly derail this patch's topic. Sorry if
> that is the case and tell me to back off.
> 
> There have been multiple attempts on getting the python API in better
> shape. Originally it was Ajo and some others with
> https://github.com/kicad/kicad-python
> 
> But the most recent work is on
> https://github.com/pointhi/kicad-python
> 
> Which is different from the initial work. I don't really know the state
> of that work.
> 
> I would like to see a supported API, but I guess this could be blocked
> slightly because of the wxpython phoenix story.
> 
> 
> 
> 2018-06-12 15:34 GMT+02:00 John Beard  >:
> 
> Hi Nick and Wayne,
> 
> The patches as they are don't hook into the existing Python API
> doxygen stuff as it's not exactly the same as the Python API, it's a
> helper layer on top of that, and I was't sure if that would be OK.
> 
> I will take a look at adding it to the existing Python doc
> generation if that's an acceptable way to present it.
> 
> Cheers,
> 
> John
> 
> On Tue, Jun 12, 2018 at 2:11 PM, Nick Østergaard  > wrote:
> 
> We already have doxygen generation for the python API, although
> people say that it is easier to read the C++ one. It is
> generated with the doxygen-python make target.
> See http://docs.kicad-pcb.org/doxygen-python/
> 
> 
> Does the additions in 0002 add to the normal python docs?
> 
> 2018-06-12 15:07 GMT+02:00 Wayne Stambaugh  >:
> 
> Hey John,
> 
> I like the idea of using doxygen to document the python
> plugins.  The
> current Doxyfile does not include .py files so that would
> need to
> change.  Before we do that, I would like to see a new
> section (maybe
> "Python Plugins") added to the documentation to separate the
> python
> plugin code from the c++ source documentation.  I can commit
> your patch
> as is and you can make the doxygen changes in a later patch
> or I can
> wait for you to create a new patch with all of the changes. 
> I'm fine
> either way.
> 
> Cheers,
> 
> Wayne
> 
> On 6/4/2018 7:33 AM, John Beard wrote:
> > Hi,
> >
> > Here is a simple patch sequence for the Python Footprint
> Wizard helpers:
> >
> > 1) Minor spelling and formatting tidy-up
> > 2) Add docstrings for the wizard base. As this is intended
> to be used
> > by writers of new plugins, having the functions documented
> is probably
> > a Good Idea (TM)
> > 3) Add rounded rectangle and chamfered rectangle helpers.
> Useful for
> > some footprints or even board outlines.
> >
> > I used Doxygen-style docstrings, but I haven't actually
> done anything
> > about building actual output docs with it. Any thoughts of
> if that
> > should be done, and if so, where to put it?
> >
> > There shouldn't be anything here that will break existing
> plugins, the
> > only API changes are additions.
> >
> > Cheers,
> >
> > John
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> 
> > Post to     : kicad-developers@lists.launchpad.net
> 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> 
> > More help   : https://help.launchpad.net/ListHelp
> 
> >
> 
> ___
>   

Re: [Kicad-developers] More default fields in schematic

[Thomas Pointhuber]

I agree that it would be very beneficial (especially for 3rd-party
tools) to have a standardized naming convention.

Related discussions:

 *
https://forum.kicad.info/t/default-manufacturers-part-number-field-in-kicad-libraries/4387/65

 * https://github.com/KiCad/kicad-library/issues/808

I don't see much harm done when new projects have some standard names
set as "Default Fields". It rather simplifies the work and would for
example also allow the library to add MPN in the future.

My 50cents: I would prefer "Manufacturer Part Number" or similar instead
of the abbreviation "MPN", to help new users understanding the meaning
of the field.

Regards, Thomas

Am 2018-05-21 um 15:13 schrieb Marcos Chaparro:
> I second Kristoffer. Some made with kicad examples are mine, some use
> #mfg and some use MPN because there is no common way to address a
> basic thing like a part number and for me it changed over the years,
> rendering old projects hard to maintain. Now I'leaning towards MPN
> only because kicost didn't support (or I coudnlt figure out) a #mfg
> field.
>
> Those who want a different field name can add a new field and use it,
> but IMO kicad needs some common ground on this particular issue.
>
> Marcos
>
> On Mon, May 21, 2018 at 8:55 AM, Kristoffer Ödmark
> >
> wrote:
>
> No, that is one usage of it, some people likes to make the
> schematic their bom, some tools and services can also rely on such
> values.
>
> Once again, the only people complaining are the ones that do not
> use it, and also the ones that will not be affected. Sure name it
> PartNum and use it the way you describe, you would never use any
> other tools to interact anyway, since that apparently is not your
> job... I only want there to be a common denomination for the the
> field names by default.
>
> Because right now, anyone who actually uses the Schematic this
> way, which are quite many will always have to randomly define and
> abbreviate the same field, which just hinders anything smart to be
> done on top of it.
>
> To better go with your thinking, I suggest you remove all the
> keybindings i KiCad, and then set them to what you want. That way
> you will get the current field experience. Everything is better
> with no defaults, amiright?
>
>  -Kristoffer
>
> On 2018-05-21 06:13, Jean-Paul Louis wrote:
>
> That discussion once again shows how people misunderstand the
> concept of part number.
> In a schematic, the part number attached to a RefDes should be
> unique AND NOT a manufacturer number.
>    There should be a one to one relationship between a part
> number (symbol) and a physical shape, so the PCB will be a
> unit manufacturable only when the BOM is generated, and is one
> to one relationship between part number and Mfg part number.
> The BOM is only for manufacturing assembly and procurement purpose
> and does not need to be part of the design database, so
> Manufacturing can use Equivalent Mfg numbers for a given part
> number. That’s why many companies use internal numbering
> systems that are non picture coded and just sequential.
> The relationship Symbol, Shape, Supplier is the responsibility
> of the master library, not the designers.
>
> Just my $0.02,
> Jean-Paul
> N1JPL
>
>
>
> On May 20, 2018, at 6:27 PM, Andrey Kuznetsov
> > wrote:
>
> I agree, I had the same issue when I was doing my board, I
> needed a field for all components, and I had to manually
> add it for every item, there was no way to add this field
> to all components at the same time or to have it add by
> default from the addition of a new component to the sheet.
>
> Which reminds me, Cadence Designer has tools to manipulate
> fields on a large scale, whether to add, delete, show,
> hide, etc, this is something that would be nice to have in
> KiCAD, either that or a table of all components for the
> sheet or schematic and columns for each field, with
> ability to show/hide each cell individually.
>
> I think the ultimate goal is to make the Symbol Table more
> useful, but that'll take to long for v5 so if Kristoffer's
> patch allows an easy way to add fields to all components
> or similar, I'd say do it because people will be pissed
> and waste their time doing it for every component in their
> schematic.
>
> On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark
>  > wrote:
> I 

Re: [Kicad-developers] [PATCH] Adjust Menubar of 3D Viewer to common style

[Thomas Pointhuber]

Hi Wayne,

I updated the patches accordingly.

Regard,

Thomas


Am 2018-05-04 um 18:09 schrieb Wayne Stambaugh:
> Yes, please update your patch to use the terms "Clockwise" and
> "Counterclockwise" which is consistent with the rest of kicad.
>
> Thanks,
>
> Wayne
>
From 8fd84d7b122235af0a0cabec41e5379f41006ae8 Mon Sep 17 00:00:00 2001
From: Thomas Pointhuber <thomas.pointhu...@gmx.at>
Date: Thu, 26 Apr 2018 20:58:49 +0200
Subject: [PATCH 1/2] Adjust Menubar of 3D Viewer to common style

---
 3d-viewer/3d_viewer/3d_menubar.cpp | 96 ++
 3d-viewer/3d_viewer/3d_toolbar.cpp | 12 ++--
 2 files changed, 102 insertions(+), 6 deletions(-)

diff --git a/3d-viewer/3d_viewer/3d_menubar.cpp b/3d-viewer/3d_viewer/3d_menubar.cpp
index 9c00afb79..e04d018a3 100644
--- a/3d-viewer/3d_viewer/3d_menubar.cpp
+++ b/3d-viewer/3d_viewer/3d_menubar.cpp
@@ -34,6 +34,7 @@
 #include <3d_canvas/cinfo3d_visu.h>
 #include 
 #include <3d_viewer_id.h>
+#include "help_common_strings.h"
 
 extern struct EDA_HOTKEY_CONFIG g_3DViewer_Hokeys_Descr[];
 
@@ -44,6 +45,7 @@ void EDA_3D_VIEWER::CreateMenuBar()
 wxMenuBar* menuBar   = new wxMenuBar;
 wxMenu*fileMenu  = new wxMenu;
 wxMenu*editMenu  = new wxMenu;
+wxMenu*viewMenu  = new wxMenu;
 wxMenu*prefsMenu = new wxMenu;
 wxMenu*helpMenu  = new wxMenu;
 
@@ -68,6 +70,72 @@ void EDA_3D_VIEWER::CreateMenuBar()
  _( "Copy 3D Image" ),
  KiBitmap( copy_xpm ) );
 
+menuBar->Append( viewMenu, _( "" ) );
+
+AddMenuItem( viewMenu, ID_ZOOM_IN,
+ _( "Zoom " ), HELP_ZOOM_IN,
+ KiBitmap( zoom_in_xpm ) );
+
+AddMenuItem( viewMenu, ID_ZOOM_OUT,
+ _( "Zoom " ), HELP_ZOOM_OUT,
+ KiBitmap( zoom_out_xpm ) );
+
+AddMenuItem( viewMenu, ID_ZOOM_PAGE,
+ _( "Zoom to " ), HELP_ZOOM_FIT,
+ KiBitmap( zoom_fit_in_page_xpm ) );
+
+AddMenuItem( viewMenu, ID_ZOOM_REDRAW,
+ _( "" ), HELP_ZOOM_REDRAW,
+ KiBitmap( zoom_redraw_xpm ) );
+
+viewMenu->AppendSeparator();
+
+AddMenuItem( viewMenu, ID_ROTATE3D_X_NEG,
+ _( "Rotate X Clockwise" ),
+ KiBitmap( rotate_neg_x_xpm ) );
+
+AddMenuItem( viewMenu, ID_ROTATE3D_X_POS,
+ _( "Rotate X Counterclockwise" ),
+ KiBitmap( rotate_pos_x_xpm ) );
+
+viewMenu->AppendSeparator();
+
+AddMenuItem( viewMenu, ID_ROTATE3D_Y_NEG,
+ _( "Rotate Y Clockwise" ),
+ KiBitmap( rotate_neg_y_xpm ) );
+
+AddMenuItem( viewMenu, ID_ROTATE3D_Y_POS,
+ _( "Rotate Y Counterclockwise" ),
+ KiBitmap( rotate_pos_y_xpm ) );
+
+viewMenu->AppendSeparator();
+
+AddMenuItem( viewMenu, ID_ROTATE3D_Z_NEG,
+ _( "Rotate Z Clockwise" ),
+ KiBitmap( rotate_neg_z_xpm ) );
+
+AddMenuItem( viewMenu, ID_ROTATE3D_Z_POS,
+ _( "Rotate Z Counterclockwise" ),
+ KiBitmap( rotate_pos_z_xpm ) );
+
+viewMenu->AppendSeparator();
+
+AddMenuItem( viewMenu, ID_MOVE3D_LEFT,
+ _( "Move left" ),
+ KiBitmap( left_xpm ) );
+
+AddMenuItem( viewMenu, ID_MOVE3D_RIGHT,
+ _( "Move right" ),
+ KiBitmap( right_xpm ) );
+
+AddMenuItem( viewMenu, ID_MOVE3D_UP,
+ _( "Move up" ),
+ KiBitmap( up_xpm ) );
+
+AddMenuItem( viewMenu, ID_MOVE3D_DOWN,
+ _( "Move down" ),
+ KiBitmap( down_xpm ) );
+
 menuBar->Append( prefsMenu, _( "" ) );
 
 AddMenuItem( prefsMenu, ID_MENU3D_MOUSEWHEEL_PANNING,
@@ -76,6 +144,10 @@ void EDA_3D_VIEWER::CreateMenuBar()
 
 prefsMenu->AppendSeparator();
 
+AddMenuItem( prefsMenu, ID_TOOL_SET_VISIBLE_ITEMS,
+ _( "Display Options" ),
+ KiBitmap( read_setup_xpm ) );
+
 AddMenuItem( prefsMenu, ID_MENU3D_REALISTIC_MODE,
  _( "Realistic Mode" ),
  KiBitmap( use_3D_copper_thickness_xpm ), wxITEM_CHECK );
@@ -304,12 +376,36 @@ void EDA_3D_VIEWER::CreateMenuBar()
 // /
 menuBar->Append( helpMenu, _( "" ) );
 
+AddMenuItem( helpMenu, wxID_HELP,
+ _( "Pcbnew " ),
+ _( "Open Pcbnew Manual" ),
+ KiBitmap( online_help_xpm ) );
+
+AddMenuItem( helpMenu, wxID_INDEX,
+ _( " Started in KiCad" ),
+ _( "Open \"Getting Started in KiCad\&quo

Re: [Kicad-developers] RegEx help

[Thomas Pointhuber]

Hi Jeff,

I think the regex you want is: ".*\$(\{.+\}|\(.+\)).*"  (Note, I didn't
escape anything)

The best way to develop regex would be by using tools like
https://www.debuggex.com or https://regexr.com

For example, the regex I gave you:
https://www.debuggex.com/r/MTdQVK1dJHXhXtsF


Basics:
. any character
* means any number (0 or more) of the previous character or group
? means zero or one occurrence of the previous character or group (in
your case useless)
^ begin of string
$ end of string


"[^}]*" means any number of character except "}"


The question is if you really want allow random strings before/after the
environment var, because this means the exclusion of } would not work.

Environment variables are normally limited to alphanumeric and
underscore, I think. This means, instead of ".+" I would use "\w+" to
match the name.

Regards, Thomas

Am 2018-05-05 um 15:19 schrieb Jeff Young:
> We have a couple of regular expressions of the form:
>
> wxRegEx re( ".*?\\$\\{(.+?)\\}.*?", wxRE_ADVANCED );
>
> Now perhaps I’m too old to remember this stuff correctly, but .*? is
> redundant, isn’t it?
>
> And shouldn’t .+? just be .*?  (And for that matter, shouldn’t it
> really be [^}]*?)
>
> Thanks,
> Jeff.
>
>
> Note that I’m looking at this because it needs to check for both ${…}
> and $(…) formatted envvars, which I think boils down to:
>
> .*(\\$\\{([^}]*)\\})|(\\$\\(([^)]*)\\)).*
>
>
> ___
> Mailing list: https://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

Re: [Kicad-developers] [PATCH] Adjust Menubar of 3D Viewer to common style

[Thomas Pointhuber]

so I should change it to CW and CCW? I assume the tooltip text of the
panel should also be change accordingly.

Regards, Thomas


Am 2018-05-03 um 19:44 schrieb Wayne Stambaugh:
> On 5/3/2018 1:28 PM, jp charras wrote:
>> Le 03/05/2018 à 18:44, Wayne Stambaugh a écrit :
>>> I did notice one thing that is a bit odd in the first patch.  The rotate
>>> menu entries use -> and <- to signify clockwise and counter-clockwise
>>> directions.  I'm not sure this is clear to the user.  If we need to
>>> avoid the verbosity of CW and CCW then maybe we should use + and - instead.
>>>
>> I am never thrilled by using + and - instead of CW and CCW.
>>
>> Just because I do not know what is the meaning of + (or -)
>>
>> If + is the positive rotation using mathematical positive angle rotation 
>> definition, it is
>> equivalent to CCW.
>> But I am not sure this is the way it is understood by all users and I find 
>> this notation ambiguous.
>>
> Me neither.  I prefer CW and CCW.  + and - were suggestions as an
> improvement over -> and <-.  It appears that the menu icons actually
> show the correct axis rotation.
>
> ___
> Mailing list: https://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

Re: [Kicad-developers] [PATCH] Adjust Menubar of 3D Viewer to common style

[Thomas Pointhuber]

it would be cool to merge this before rc2 :)

Regards, Thomas


Am 2018-04-26 um 21:58 schrieb Thomas Pointhuber:
> Hi,
>
> I did some rebase and rewrite of the patch and removed for now the
> changes in "file" and "edit" to have something hopefully mergable. It
> consists of two patches. The first adds some new entries, the second one
> removes all those menus which are available in an already existing
> dialog and thus removes some complexity from the menus.
>
>
> Available also on GitHub:
> https://github.com/pointhi/kicad-source-mirror/tree/3d_viewer_menu-2
>
>
> Regards,
>
> Thomas
>




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

Re: [Kicad-developers] [PATCH] Adjust Menubar of 3D Viewer to common style

[Thomas Pointhuber]

Hi,

I did some rebase and rewrite of the patch and removed for now the
changes in "file" and "edit" to have something hopefully mergable. It
consists of two patches. The first adds some new entries, the second one
removes all those menus which are available in an already existing
dialog and thus removes some complexity from the menus.


Available also on GitHub:
https://github.com/pointhi/kicad-source-mirror/tree/3d_viewer_menu-2


Regards,

Thomas

From e07d87ae41db6c64c65aba91b95d1d28b6960e8a Mon Sep 17 00:00:00 2001
From: Thomas Pointhuber <thomas.pointhu...@gmx.at>
Date: Thu, 26 Apr 2018 20:58:49 +0200
Subject: [PATCH 1/2] Adjust Menubar of 3D Viewer to common style

---
 3d-viewer/3d_viewer/3d_menubar.cpp | 96 ++
 1 file changed, 96 insertions(+)

diff --git a/3d-viewer/3d_viewer/3d_menubar.cpp b/3d-viewer/3d_viewer/3d_menubar.cpp
index 9c00afb79..39386ca4c 100644
--- a/3d-viewer/3d_viewer/3d_menubar.cpp
+++ b/3d-viewer/3d_viewer/3d_menubar.cpp
@@ -34,6 +34,7 @@
 #include <3d_canvas/cinfo3d_visu.h>
 #include 
 #include <3d_viewer_id.h>
+#include "help_common_strings.h"
 
 extern struct EDA_HOTKEY_CONFIG g_3DViewer_Hokeys_Descr[];
 
@@ -44,6 +45,7 @@ void EDA_3D_VIEWER::CreateMenuBar()
 wxMenuBar* menuBar   = new wxMenuBar;
 wxMenu*fileMenu  = new wxMenu;
 wxMenu*editMenu  = new wxMenu;
+wxMenu*viewMenu  = new wxMenu;
 wxMenu*prefsMenu = new wxMenu;
 wxMenu*helpMenu  = new wxMenu;
 
@@ -68,6 +70,72 @@ void EDA_3D_VIEWER::CreateMenuBar()
  _( "Copy 3D Image" ),
  KiBitmap( copy_xpm ) );
 
+menuBar->Append( viewMenu, _( "" ) );
+
+AddMenuItem( viewMenu, ID_ZOOM_IN,
+ _( "Zoom " ), HELP_ZOOM_IN,
+ KiBitmap( zoom_in_xpm ) );
+
+AddMenuItem( viewMenu, ID_ZOOM_OUT,
+ _( "Zoom " ), HELP_ZOOM_OUT,
+ KiBitmap( zoom_out_xpm ) );
+
+AddMenuItem( viewMenu, ID_ZOOM_PAGE,
+ _( "Zoom to " ), HELP_ZOOM_FIT,
+ KiBitmap( zoom_fit_in_page_xpm ) );
+
+AddMenuItem( viewMenu, ID_ZOOM_REDRAW,
+ _( "" ), HELP_ZOOM_REDRAW,
+ KiBitmap( zoom_redraw_xpm ) );
+
+viewMenu->AppendSeparator();
+
+AddMenuItem( viewMenu, ID_ROTATE3D_X_NEG,
+ _( "Rotate X <-" ),
+ KiBitmap( rotate_neg_x_xpm ) );
+
+AddMenuItem( viewMenu, ID_ROTATE3D_X_POS,
+ _( "Rotate X ->" ),
+ KiBitmap( rotate_pos_x_xpm ) );
+
+viewMenu->AppendSeparator();
+
+AddMenuItem( viewMenu, ID_ROTATE3D_Y_NEG,
+ _( "Rotate Y <-" ),
+ KiBitmap( rotate_neg_y_xpm ) );
+
+AddMenuItem( viewMenu, ID_ROTATE3D_Y_POS,
+ _( "Rotate Y ->" ),
+ KiBitmap( rotate_pos_y_xpm ) );
+
+viewMenu->AppendSeparator();
+
+AddMenuItem( viewMenu, ID_ROTATE3D_Z_NEG,
+ _( "Rotate Z <-" ),
+ KiBitmap( rotate_neg_z_xpm ) );
+
+AddMenuItem( viewMenu, ID_ROTATE3D_Z_POS,
+ _( "Rotate Z ->" ),
+ KiBitmap( rotate_pos_z_xpm ) );
+
+viewMenu->AppendSeparator();
+
+AddMenuItem( viewMenu, ID_MOVE3D_LEFT,
+ _( "Move left" ),
+ KiBitmap( left_xpm ) );
+
+AddMenuItem( viewMenu, ID_MOVE3D_RIGHT,
+ _( "Move right" ),
+ KiBitmap( right_xpm ) );
+
+AddMenuItem( viewMenu, ID_MOVE3D_UP,
+ _( "Move up" ),
+ KiBitmap( up_xpm ) );
+
+AddMenuItem( viewMenu, ID_MOVE3D_DOWN,
+ _( "Move down" ),
+ KiBitmap( down_xpm ) );
+
 menuBar->Append( prefsMenu, _( "" ) );
 
 AddMenuItem( prefsMenu, ID_MENU3D_MOUSEWHEEL_PANNING,
@@ -76,6 +144,10 @@ void EDA_3D_VIEWER::CreateMenuBar()
 
 prefsMenu->AppendSeparator();
 
+AddMenuItem( prefsMenu, ID_TOOL_SET_VISIBLE_ITEMS,
+ _( "Display Options" ),
+ KiBitmap( read_setup_xpm ) );
+
 AddMenuItem( prefsMenu, ID_MENU3D_REALISTIC_MODE,
  _( "Realistic Mode" ),
  KiBitmap( use_3D_copper_thickness_xpm ), wxITEM_CHECK );
@@ -304,12 +376,36 @@ void EDA_3D_VIEWER::CreateMenuBar()
 // /
 menuBar->Append( helpMenu, _( "" ) );
 
+AddMenuItem( helpMenu, wxID_HELP,
+ _( "Pcbnew " ),
+ _( "Open Pcbnew Manual" ),
+ KiBitmap( online_help_xpm ) );
+
+AddMenuItem( helpMenu, wxID_INDEX,
+ _( " Started in KiCad" ),
+ _( "Open

Re: [Kicad-developers] [PATCH] Adjust Menubar of 3D Viewer to common style

[Thomas Pointhuber]

Hi Jeff,

I would still place the clipboard option into the file menu. Preferably
below the Export Entry because it would be more logical to find. The
current location of the clipboard item is because Eeschema also located
this menu item in the exports menu and I simpily tried for consistency.

Regards, Thomas


Am 2018-04-06 um 16:12 schrieb Jeff Young:
> Hi Thomas,
>
> I don’t think I’d nest the two export options just for the sake of 
> consistency.  Nested menus are harder to use, and should only be resorted to 
> when necessary (either when room on the menu is an issue, or when progressive 
> disclosure is desired).
>
> Copy 3D Image goes to the clipboard, and therefore must stay on the Edit menu 
> (although it could be shortened to just Copy).
>
> The Preferences & View menu stuff looks good.  I agree that we should get rid 
> of all the menu options that are in the Display Options dialog.
>
> Cheers,
> Jeff.
>
>
>> On 4 Apr 2018, at 13:34, Thomas Pointhuber <thomas.pointhu...@gmx.at> wrote:
>>
>> Hi,
>>
>> some time ago there were adjustments to have a common design of the
>> menubar in all applications. This initial patch does some basic
>> adjustions of the 3D-Viewer in this direction, but things like
>> displaying Hotkeys was not added.
>>
>>
>> One question regarding improvements based on that patch would be:
>>
>> There exists now a "Display Options" Dialog. In my point of view this
>> would allow us to remove quite a few submenus. What do you think about
>> that? Currently you need to cause a resize event to get the view updated
>> (https://bugs.launchpad.net/kicad/+bug/1612419), which means using the
>> Dialog requires the same number of events for an action and thus the
>> submenu does not even provide better efficiency.
>>
>>
>> Patch can also be found on GitHub:
>> https://github.com/pointhi/kicad-source-mirror/tree/3d_viewer_menu
>>
>>
>> Regards, Thomas
>>
>> <0001-Adjust-Menubar-of-3D-Viewer-to-common-style.patch>___
>> Mailing list: https://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] [PATCH] Adjust Menubar of 3D Viewer to common style

[Thomas Pointhuber]

Hi,

some time ago there were adjustments to have a common design of the
menubar in all applications. This initial patch does some basic
adjustions of the 3D-Viewer in this direction, but things like
displaying Hotkeys was not added.


One question regarding improvements based on that patch would be:

There exists now a "Display Options" Dialog. In my point of view this
would allow us to remove quite a few submenus. What do you think about
that? Currently you need to cause a resize event to get the view updated
(https://bugs.launchpad.net/kicad/+bug/1612419), which means using the
Dialog requires the same number of events for an action and thus the
submenu does not even provide better efficiency.


Patch can also be found on GitHub:
https://github.com/pointhi/kicad-source-mirror/tree/3d_viewer_menu


Regards, Thomas

From 53e344fe2ee450b852f49b635ac89542080e0dd8 Mon Sep 17 00:00:00 2001
From: Thomas Pointhuber <thomas.pointhu...@gmx.at>
Date: Wed, 4 Apr 2018 14:17:20 +0200
Subject: [PATCH] Adjust Menubar of 3D Viewer to common style

---
 3d-viewer/3d_viewer/3d_toolbar.cpp | 124 +
 1 file changed, 112 insertions(+), 12 deletions(-)

diff --git a/3d-viewer/3d_viewer/3d_toolbar.cpp b/3d-viewer/3d_viewer/3d_toolbar.cpp
index 3027b1dee..d5c1ec240 100644
--- a/3d-viewer/3d_viewer/3d_toolbar.cpp
+++ b/3d-viewer/3d_viewer/3d_toolbar.cpp
@@ -35,6 +35,8 @@
 #include 
 #include <3d_viewer_id.h>
 
+#include "help_common_strings.h"
+
 
 void EDA_3D_VIEWER::ReCreateMainToolbar()
 {
@@ -141,30 +143,100 @@ void EDA_3D_VIEWER::CreateMenuBar()
 
 wxMenuBar* menuBar   = new wxMenuBar;
 wxMenu*fileMenu  = new wxMenu;
-wxMenu*editMenu  = new wxMenu;
+wxMenu*viewMenu  = new wxMenu;
 wxMenu*prefsMenu = new wxMenu;
 wxMenu*helpMenu  = new wxMenu;
 
 menuBar->Append( fileMenu, _( "" ) );
 
-AddMenuItem( fileMenu, ID_MENU_SCREENCOPY_PNG,
- _( "Export Current View as PNG..." ),
+// Export options
+// /
+wxMenu* exportMenu = new wxMenu;
+
+AddMenuItem( exportMenu, ID_MENU_SCREENCOPY_PNG,
+ _( "PNG..." ), _( "Export Current View as PNG..." ),
  KiBitmap( export_xpm ) );
 
-AddMenuItem( fileMenu, ID_MENU_SCREENCOPY_JPEG,
- _( "Export Current View as JPEG..." ),
+AddMenuItem( exportMenu, ID_MENU_SCREENCOPY_JPEG,
+ _( "JPEG..." ), _( "Export Current View as JPEG..." ),
  KiBitmap( export_xpm ) );
 
+AddMenuItem( exportMenu, ID_TOOL_SCREENCOPY_TOCLIBBOARD,
+ _( "3D View to Clipboard" ),
+ KiBitmap( copy_xpm ) );
+
+AddMenuItem( fileMenu, exportMenu,
+ ID_GEN_EXPORT_FILE, _( "E" ),
+ _( "Export Current View" ), KiBitmap( export_xpm ) );
+
 fileMenu->AppendSeparator();
-AddMenuItem( fileMenu, wxID_EXIT,
- _( "" ),
- KiBitmap( exit_xpm ) );
+AddMenuItem( fileMenu, wxID_EXIT, _( "" ), _( "Close 3D Viewer" ), KiBitmap( exit_xpm ) );
 
-menuBar->Append( editMenu, _( "" ) );
+menuBar->Append( viewMenu, _( "" ) );
 
-AddMenuItem( editMenu, ID_TOOL_SCREENCOPY_TOCLIBBOARD,
- _( "Copy 3D Image" ),
- KiBitmap( copy_xpm ) );
+AddMenuItem( viewMenu, ID_ZOOM_IN,
+ _( "Zoom " ), HELP_ZOOM_IN,
+ KiBitmap( zoom_in_xpm ) );
+
+AddMenuItem( viewMenu, ID_ZOOM_OUT,
+ _( "Zoom " ), HELP_ZOOM_OUT,
+ KiBitmap( zoom_out_xpm ) );
+
+AddMenuItem( viewMenu, ID_ZOOM_PAGE,
+ _( "Zoom to " ), HELP_ZOOM_FIT,
+ KiBitmap( zoom_fit_in_page_xpm ) );
+
+AddMenuItem( viewMenu, ID_ZOOM_REDRAW,
+ _( "" ), HELP_ZOOM_REDRAW,
+ KiBitmap( zoom_redraw_xpm ) );
+
+viewMenu->AppendSeparator();
+
+AddMenuItem( viewMenu, ID_ROTATE3D_X_NEG,
+ _( "Rotate X <-" ),
+ KiBitmap( rotate_neg_x_xpm ) );
+
+AddMenuItem( viewMenu, ID_ROTATE3D_X_POS,
+ _( "Rotate X ->" ),
+ KiBitmap( rotate_pos_x_xpm ) );
+
+viewMenu->AppendSeparator();
+
+AddMenuItem( viewMenu, ID_ROTATE3D_Y_NEG,
+ _( "Rotate Y <-" ),
+ KiBitmap( rotate_neg_y_xpm ) );
+
+AddMenuItem( viewMenu, ID_ROTATE3D_Y_POS,
+ _( "Rotate Y ->" ),
+ KiBitmap( rotate_pos_y_xpm ) );
+
+viewMenu->AppendSeparator();
+
+AddMenuItem( viewMenu, ID_ROTATE3D_Z_NEG,
+ _( "Rotate

Re: [Kicad-developers] Feedback on 6.0 work

[Thomas Pointhuber]

Hi Jeff,

it looks more clear than the current version.

I would hide the text properties (with the exception of Show) by
default. I don't think many people would change for example the position
or orientation using this dialog. Every text attribute also has its own
menu as well which can be used for editing. Instead use the gained space
to add a footprint preview as it was developed for the symbol chooser.
It's annoying to first click on the footprint row to be able to
view/change it.


Another idea is to think about the "Footprint Properties" as well, while
designing this window. Having an approach which works on both worlds
would result in a more consistent design.


Coulf the widget (tree view + scrolling + add/delete/up/down buttons) be
generalized, so it can be used in other places as well? I especially
think about the "Design Rules Editor" which lacks such functions for
example. "Library Editor" is another place where it would fit.

Regards,
Thomas

Am 2018-03-17 um 15:04 schrieb Jeff Young:
> I could use some feedback on a bit of 6.0 work I’m doing before I go
> any farther with it.  First up is the direct-edit Symbol Properties
> dialog:
>
>
> This is the “in schematic” version.  If it looks good, I can go on and
> do the “in libedit” version.
>
> If you want to play with it, it’s on my public 6.0 branch
> here: https://git.launchpad.net/~jeyjey/kicad/?h=6.0
> 
>
> Thanks,
> 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




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] KiCad 5 and the Github footprint wizard?

[Thomas Pointhuber]

Hi,

at least in the nightly it is still possible to add GitHub libraries
using "Append with Wizard".

Will this change? Because when someone uses this feature, it only
references to the old legacy repositories, without a clue about that.


Regards, Thomas




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

Re: [Kicad-developers] Polygons: should have outline mode to draw Edge.Cuts

[Thomas Pointhuber]

Hi,

as librarian I would also note that an improved Edge:Cuts behaviour
should take in account footprints which define Edge Connectors or cutouts.

At the moment, cutouts are incorrectly rendered in the 3d-viewer when
showing a single footprint, because there is no difference to a board
outline
in the actual file representation. Edge Connectors are especially
tricky, because KiCad requires the Edge.Cuts primitives to match
exactly. I think it
would make sense to add such connectors to the library as well in the
future, but using them would be to tortuous at the moment.

Regards,
Thomas

Am 2017-11-21 um 15:48 schrieb easyw:
> Hi Henner,
>
> I know this is outside the KiCad branch, but if you want to manage
> complex board edges including arcs, ellipses or bsplines, you may
> consider useful KiCad StepUp...
> Recently I've added a feature to allow the user to design the pcb edge
> in FreeCAD and push it to KiCad_pcb board file.
>
> The collaboration between FreeCAD and KiCad is bi-directional, then
> revisions are possible...
> You may have a look at a small tutorial here
> https://youtu.be/n44iBpu_YjY
> and at the KiCad info forum page
> https://forum.kicad.info/t/kicad-stepup-the-sketcher-for-getting-to-blinky/7826
>
>
> The idea is to manage complex board edges in a mechanical environment
> to be able to check collisions and dimension constraints.
>
> Regards
> Maurice
>
> On 11/21/2017 6:42 AM, Henner Zeller wrote:
>> Hi,
>> So polygons are very neat as they employ the nice polygon drawing
>> features we are used to from zone drawing [*1].
>>
>> A missing feature here is to _not_ have them filled but simply an
>> outline. Why ? This would be _very_ useful to draw Edge.Cuts.
>> Currently, the only way is to draw single lines, which are then hard
>> to adjust later, as they all fall apart into separate lines, and have
>> to be edited manually.
>>
>> Now, if that could be drawn with the polygon tool, that would remove a
>> hge pain having to deal with outlines (and yes, I know the usual
>> advice to draw that separately and import as DXF. But what if I could
>> just do simple polygons directly ?).
>>
>> Also what we could get for almost free then: Chamfers and Fillets. I
>> like to have boards with rounded corners [*2], but currently this is
>> of course a torture to do manually and and dread it every time it
>> comes to that part of the project: draw a rectangle with the line
>> tool. Do circles in the corners and manually calculate where the
>> center and the start point is, shorten the lines accordingly to match
>> the length shorter the radius. Do that on all four corners. That
>> easily takes several minutes and high concentration. And god forbid
>> one wants to change that again later ...
>>
>> Now how wounderful that would be if that could be done with the
>> Polygon tool and I just choose to have a fillet or camfer. If this is
>> something nobody is working on yet and if people think this is a good
>> idea, I might have a look over the Thanksgiving days.
>>
>> Cheers,
>>    Henner.
>>
>>
>> [*1] also see my mail before [All kinds of glitches], Polygons as-is
>> are currently broken and maybe the concept should be merged with the
>> zone ?
>>
>> [*2]
>> https://raw.githubusercontent.com/hzeller/quadrigotion/master/img/tmc2660-quad-render.jpg
>>
>> ___
>> Mailing list: https://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




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

Re: [Kicad-developers] Cursor behavior

[Thomas Pointhuber]

about 1), I would suggest to change the selection behaviour of locked
footprints, to only select when parts of the footprint (line, pad,...)
are explicitly selected (not the area between). Area selection should
also not include locked footprints. This is likely something where users
want to specify the behaviour.

Handling of pcb-edges as footprints is such a case, where this behaviour
would be very handy. Allowing us to lock primitives like lines would
also be something I would consider useful.

Regards, Thomas


Am 2017-07-22 um 03:13 schrieb Marcos Chaparro:
> Good points, I'm especially excited about 1), our pcb edges are
> usually footprints, so I'm always working inside a footprint, which is
> continuously getting selected.
>
> Cheers
>
>
> On Jul 21, 2017 18:34, "Piotr Esden-Tempski"  > wrote:
>
> Hi,
>
> > On Jul 20, 2017, at 4:44 AM, jp charras  > wrote:
> >
> [SNIP]
> >
> > AFAIK, when moving a single footprint, the anchor point is
> either one of its
> > pads or the footprint origin, the nearest candidate point from
> mouse cursor.
> >
> > Perhaps the algorithm should be slightly modified to use the pad
> if the mouse cursor is inside a
> > pad, and the footprint origin if the mouse cursor is inside the
> footprint (obviously), but not
> > inside a pad.
> >
> > It could be a more intuitive behavior.
>
>
> Very good idea, usually if I click on a component I do not want to
> move it by the pad unless I explicitly want to do that. Your
> solution is definitely better than the current behavior.
>
> On the component and general item selection topic.
>
> 1) If a component is very large in the current zoom level it
> should be ignored. It makes it very difficult to select small
> components that end up on the opposite side of a large component.
> It is also very unlikely the user will want to move the thing that
> is not even visible at the moment because it is 10x the size of
> the viewport. :)
> 2) Add the option to use a button to flip through potential
> selections. Having to use the mouse to select the component I
> meant from a list of candidates is really annoying. Other software
> packages have a nicer behavior for this: select a component and
> allow swapping through candidates using the right mouse button
> (this could be a keyboard shortcut too) and then confirm with
> another left click. (a good example is how the package with a bird
> does that, this is one of the few things I miss from using that
> software on daily basis. :) )
>
> I hope this is useful in some way.
>
> Just a few of my own 2c regarding the component selection behavior. :D
>
> Cheers,
> Piotr
> ___
> Mailing list: https://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



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

Re: [Kicad-developers] Kudos and Re: Copy/Paste/Cut defaults to ctrl + c, v, x as most other software.

[Thomas Pointhuber]

I think using "zoom as center of zoom" by default would be the better
default choise, because it's the one most users are used too by other
software as well. From the people I know, everyone changes this settings
as one of their first actions.


Am 2017-07-03 um 16:52 schrieb Greg Smith:
> Thank you for this! I think this is one of the things that make newcomers 
> confused about the UI. Another is the pan cursor to zoom center. But I really 
> like that functionality for mouse only navigation. You can turn it off then 
> you have the more common "zoom using cursor as center of zoom". Which are 
> both much better than the other common technique of zoom from center 
> regardless of cursor location. Kudos to developers for the more useful 
> options (in my opinion). If the current operation wasn't the default, I would 
> have been less confused but would have taken me longer to find the better (in 
> my opinion) current default.
>
> Greg S.
>
>> On Jul 3, 2017, at 6:51 AM, Kristoffer Ödmark  
>> wrote:
>>
>> Hey!
>>
>> I made the copy/paste/cut functionality work as someone new to the software 
>> might expect. That is, the cut command now actually puts the block in 
>> clipboard and then deletes the block, compared to just deleting it (wtf)?
>>
>> They are also bound to the almost universal defaults of ctrl+c/v/x.
>>
>> - Kristoffer
>> <0001-Eeschema-copy-cut-paste-to-ctrl-c-x-v.patch>
>> ___
>> Mailing list: https://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




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

Re: [Kicad-developers] Undo/Redo behavior across schematic

[Thomas Pointhuber]

What about storing undo information per sheet as done now, but allow
optional grouping of such a operation across sheets.

When KiCad detects the user want's to undo a operation which affects
multiple sheets, he get's a message to chose about reverting the change
only in the the current sheet / or globally.

Regards, Thomas

Am 2017-04-18 um 14:55 schrieb Jon Evans:
> (branched from the component table viewer thread)
>
> In my opinion, a schematic with multiple sheets is not like a text
> editor with multiple documents.  The schematic editor is working on a
> single project, and it should be way more common to apply operations
> (that might want to be undone) to all schematic sheets, than it is to
> apply operations across all files you happen to have open in a text
> editor (other than "find in files", of course).
>
> In my experience, other EDA tools work around the "undoing global
> changes" issue that JP mentioned in the same way that text editors do
> when you replace in multiple files -- they warn the user that the
> change cannot be undone, and sometimes leave the files/sheets in an
> "unsaved" state so there is actually a way to undo it for certain
> files (i.e. by closing them without saving)
>
> -Jon
>
> On Tue, Apr 18, 2017 at 7:46 AM, Nox  > wrote:
>
> I agree with you about the multi file editor behaviour. There it
> is natural that the undo/redo works per file. But is this
> behaviour also reasonable for a schematic? I just checked the
> behaviour of visual studio. There global replacement will be
> reverted if the stack is in sync. Else only the active document is
> affected. So I guess you are right. We have to first agree which
> way redo/undo should work. Personally I would perfere to move to a
> "mixed" or global redo/undo.
>
> What do you think: how hard will it be to implement a "container"
> undo/redo item which batchs multiple changes (e.g. for component
> changes, annotation, etc) and has an ID to check with all open
> sheets if the top most change matches. Of course it is
> questionable if a "silent" partial undo/redo is the best way to
> handle desynced stacks. Or might a global redo/undo will be easier
> to maintain? Or should global operations simply always "break" the
> local undo/redo stacks (so our "state of the art"-handling)?
>
> P.S: should we branch the discussion here maybe?
>
>
>
> Am 18.04.2017 um 09:12 schrieb jp charras:
>
> Le 17/04/2017 à 22:51, Nox a écrit :
>
> I know that I already suggested that in another context
> but what about changing the undo/redo
> semantic to the more common approach to maintain an global
> undo/redo stack and switch the view
> accordingly? I know that the "per screen" is the
> established way in kicad and that it is very
> dangerous to break existing workflows. But the undo/redo
> behaviour is currently hardly
> "understandable" for beginners. E.g. why does the undo not
> follow my actions but stays on one view?
> Why does exporting the netlist break the undo? Why can
> automatic annotation not be reverted? The
> undo list wiped on a frequently basis that personally i
> hardly trust into the undo functionality at
> all.
>
> Would it be an option to introduce a "test version" of a
> global undo/redo to get some feedback from
> the crowed which way would be preferred?
>
> For me, the problem is not to have a global or per screen
> undo/redo list, but what an user is
> expecting when undoing/redoing a change.
>
> We *always* expect to undo the last change.
> Any undo/redo system has this behavior.
>
> Now consider an editor (the schematic editor with 3 sheets for
> instance, but this is also the case
> of text editors with 3 files opened and currently edited).
>
> 1 - in sheet1 you call a tool (component table editor,
> automatic annotation) which modify all sheets.
>
> 2 - after  that you enter sheet2 and make new changes then
> sheet3 and also make new changes.
>
> 3 - back to sheet1 and try to undelete the latest change in
> this sheet: this is the global change
> (i.e. annotation). This is possible in sheet1.
> But how can you undo this annotation in others sheets: this is
> not the latest change and cannot be
> undone safely (you can have deleted/replaced/edited a symbol
> in other sheets, or deleted a sheet):
> what is the actual meaning of "undo the annotation" in other
> sheets).
>
> And ultimately:
> What a undo (and therefore redo) command must undo:
> 1 - the latest change in the full 

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

[Thomas Pointhuber]

Hi Oliver,

I can confirm the issue is now fixed.


Some other issues found:

* Please update all duplicated references when someone changes a value,
to show that more than one reference was updated by this edit (as
already done for group edit).

* undo/redo operation of symbols update by your tool only works on the
sheet you started the component table view, and only for changed
components which were placed on that sheet.


From my side, I don't see any merge blocker. All remaining issues I
found could be addressed later.

Regards, Thomas


Am 2017-04-17 um 04:11 schrieb Oliver Walters:
> JP, others,
>
> After further investigation, I have worked out why the components with
> duplicated references were displaying incorrectly.
>
> Patch_004 is attached, Thomas can you confirm that it fixes the
> display for you?
>
> Kind Regards,
> Oliver
>
> On Mon, Apr 17, 2017 at 7:53 AM, Oliver Walters
>  > wrote:
>
> JP,
>
> Thanks for the feedback.
>
> In the component table, multi-unit symbols are "compressed" into a
> single entry. Change a field value for one and it will change for
> all units of that symbol. 
>
> For "duplicate" references, perhaps the best approach is to only
> allow a certain reference to be added once to the table?
>
> However this does not represent the true state of the schematic -
> component count would be incorrect, for one.
>
> Any suggestions?
>
> On 17 Apr 2017 00:31, "jp charras"  > wrote:
>
> Le 16/04/2017 à 15:12, Oliver Walters a écrit :
> > It's not KiCad that "knows" to exclude testing points, etc -
> my Python BOM script has a series of
> > regex filters that remove a whole swathe of virtual components.
> >
> > Sometimes you actually want test points to be in the BoM
> e.g. for loading probe hooks onto the board.
> >
> > Eventually I want to add such filtering to this tool but I'd
> rather have the first round merged
> > first before the feature set becomes too complicated.
> >
> > Can someone with intimate knowledge provide some info on how
> components in sheets that are
> > referenced multiple times should be annotated in the BOM? I
> feel that sending a BOM with duplicate
> > references is wrong...
> >
>
> See const wxString GetRef( const SCH_SHEET_PATH* sheet ) in
> sch_component.h
>
> The field F0 is not really the reference. It is the reference
> current displayed on the screen.
> It is the reference only for simple hierarchies, because there
> is only one reference by symbol.
>
> Complex hierarchies (i.e. having more than one instance of a
> given sheet) are always tricky to handle.
> Especially, because the same component is shared by all
> instances, only the reference is specific to
> each instance.
> By definition, all other fields are shared.
> Therefore you cannot set for instance the value field (or the
> footprint name field) of shared
> components with different texts.
> If a field is modified, it must be also modified in all rows
> linked to this shared component in your
> Component table viewer, which shows components as a flattened
> schematic (like in a netlist).
> (Perhaps all references of this shared component should be
> displayed in the same row)
>
> Components with multiple unites by package are also a bit
> tricky to manage.
>
> Complex hierarchies having components with multiple unites by
> package are *especially* tricky.
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
>
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

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

[Thomas Pointhuber]

Hi Oliver,

nice work, and I hope it get merged into master soon.

Some issues I found so far (using your github branch):

* References are not displayed correctly when using duplicated
subschematics.
* Search functionality (using Ctrl+F) does not work with collapsed
grouped references
* Even when the dialog says "Save and Close", it actually only writes
the changes to the schematic. When you close the schematic you don't get
a notification to save your work, as well as you are not able to click
the save button when your only change was adjusting names of footprints
using the component table viewer.

Regards, Thomas



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

Re: [Kicad-developers] Change behaviour of selectCopper and selectNet feature

[Thomas Pointhuber]

Hi Marciej,

I also think the easiest way to trigger/check this bug is applying my
patch and adding a breakpoint after the following line to inspect the
internal state of the zone:

if( aSourceItem.Type() == PCB_ZONE_AREA_T )

But this can be done locally for testing purpose, and my patch shouldn't
be merged into the official repo until a bugfix for the zone behavior is
made.

The rendering issues are created by the capture program, so nothing to
worry about. I need to find a better program in the future.

Regards,

Thomas


Am 2017-02-27 um 18:13 schrieb Maciej Sumiński:
> Hi Thomas,
>
> I see your point, but before we merge your patch, we need to address the
> other problem first. I would like to see a bug report, but I guess this
> behavior is hard to trigger without applying your patch first.
>
> BTW. are the rendering glitches visible in the linked video occurring in
> KiCad as well?
>
> Regards,
> Orson
>
> On 02/24/2017 12:28 AM, Thomas Pointhuber wrote:
>> Hy,
>>
>> I think the "select Copper" and "select Net" feature should also select
>> zones, and not only track's and via's.
>>
>> When thinking about a user which doesn't know the behavior of the
>> "select Copper" feature, it should be the expected assumption that this
>> feature is really selecting the interconnected copper area, and not only
>> interconnected track's and via's.
>>
>> This patch adds this behavior.
>>
>> Unfortunately the patch is not working in all cases at the moment, due
>> to a regression which triggers an assert, when someone want's to "select
>> Copper" on a zone which is not filled but the internal state say's
>> other. It seems IsFilled return's true in some cases where the zone is
>> actually not filled.
>>
>> I created a video which I illustrates such a case where the variable is
>> not set as expected: https://owncloud.oe5tpo.com/index.php/s/YxqNpq4NxebmJGW
>>
>> Regards, Thomas
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp




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] Change behaviour of selectCopper and selectNet feature

[Thomas Pointhuber]

Hy,

I think the "select Copper" and "select Net" feature should also select
zones, and not only track's and via's.

When thinking about a user which doesn't know the behavior of the
"select Copper" feature, it should be the expected assumption that this
feature is really selecting the interconnected copper area, and not only
interconnected track's and via's.

This patch adds this behavior.

Unfortunately the patch is not working in all cases at the moment, due
to a regression which triggers an assert, when someone want's to "select
Copper" on a zone which is not filled but the internal state say's
other. It seems IsFilled return's true in some cases where the zone is
actually not filled.

I created a video which I illustrates such a case where the variable is
not set as expected: https://owncloud.oe5tpo.com/index.php/s/YxqNpq4NxebmJGW

Regards, Thomas

From fa155e76d34430c14069ed76a03031febb3c37b1 Mon Sep 17 00:00:00 2001
From: Thomas Pointhuber <thomas.pointhu...@gmx.at>
Date: Thu, 23 Feb 2017 22:32:51 +0100
Subject: [PATCH] Select zones using selectCopper or selectNet command

---
 pcbnew/tools/selection_tool.cpp | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/pcbnew/tools/selection_tool.cpp b/pcbnew/tools/selection_tool.cpp
index 96eda2c07..db3c514ed 100644
--- a/pcbnew/tools/selection_tool.cpp
+++ b/pcbnew/tools/selection_tool.cpp
@@ -33,6 +33,7 @@ using namespace std::placeholders;
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -133,11 +134,12 @@ private:
 const auto& selection = getToolManager()->GetTool()->GetSelection();
 
 bool connItem = ( S_C::OnlyType( PCB_VIA_T ) || S_C::OnlyType( PCB_TRACE_T ) )( selection );
+bool connArea = ( S_C::OnlyType( PCB_ZONE_AREA_T ) )( selection );
 bool sheetSelEnabled = ( S_C::OnlyType( PCB_MODULE_T ) )( selection );
 
-Enable( getMenuId( PCB_ACTIONS::selectNet ), connItem );
-Enable( getMenuId( PCB_ACTIONS::selectCopper ), connItem );
 Enable( getMenuId( PCB_ACTIONS::selectConnection ), connItem );
+Enable( getMenuId( PCB_ACTIONS::selectCopper ), connItem || connArea );
+Enable( getMenuId( PCB_ACTIONS::selectNet ), connItem || connArea );
 Enable( getMenuId( PCB_ACTIONS::selectSameSheet ), sheetSelEnabled );
 }
 
@@ -722,9 +724,16 @@ void SELECTION_TOOL::selectAllItemsConnectedToTrack( TRACK& aSourceTrack )
 
 void SELECTION_TOOL::selectAllItemsConnectedToItem( BOARD_CONNECTED_ITEM& aSourceItem )
 {
+if( aSourceItem.Type() == PCB_ZONE_AREA_T ) {
+ZONE_CONTAINER& zone = static_cast<ZONE_CONTAINER&>( aSourceItem );
+
+if( !zone.IsFilled() ) {
+return;
+}
+}
 RN_DATA* ratsnest = getModel()->GetRatsnest();
 std::list<BOARD_CONNECTED_ITEM*> itemsList;
-ratsnest->GetConnectedItems( , itemsList, (RN_ITEM_TYPE)( RN_TRACKS | RN_VIAS ) );
+ratsnest->GetConnectedItems( , itemsList, (RN_ITEM_TYPE)( RN_TRACKS | RN_VIAS | RN_ZONES) );
 
 for( BOARD_CONNECTED_ITEM* i : itemsList )
 select( i );
@@ -736,7 +745,7 @@ void SELECTION_TOOL::selectAllItemsOnNet( int aNetCode )
 RN_DATA* ratsnest = getModel()->GetRatsnest();
 std::list<BOARD_CONNECTED_ITEM*> itemsList;
 
-ratsnest->GetNetItems( aNetCode, itemsList, (RN_ITEM_TYPE)( RN_TRACKS | RN_VIAS ) );
+ratsnest->GetNetItems( aNetCode, itemsList, (RN_ITEM_TYPE)( RN_TRACKS | RN_VIAS | RN_ZONES ) );
 
 for( BOARD_CONNECTED_ITEM* i : itemsList )
 select( i );
-- 
2.11.1



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] Ideas about improving of the *.kicad_mod filestructure and *.pretty directories

[Thomas Pointhuber]

Hy,

as Library maintainer I got some insights about the various file formats and as 
well their current
limits. Inspired by the current eeschema file format rework I would propose 
some changes for the
footprint files as well.


Adding features which are planned for eeschema (or already implemented):

 * bezier function
 * properties
 * datasheet urls


Other ideas:

 * adding something like a group attribute or allow folders inside *.pretty 
folders.

   Currently our *.pretty folders are getting bigger and bigger and adding an 
additional level
   in the tree selector would likely improve UX. (For example we have now a 
*.pretty folder
   with >500 footprints of a single manufacturer)

 * From what I learned, *.pretty folders are currently specified to only 
contain *.kicad_mod files.
   From a logical view (As well as for maintainability and consistency) we 
should add the 3d files
   into those directories as well.

 * there are cases where footprints need cuttings inside the pcb, which are not 
round or oval.
   It's possible to use Edge.Cuts inside the footprint (with external editing) 
which works, but
   it would be a good idea to specify this case. (Which would also allow us to 
display those
   footprints correctly inside the 3d viewer)


Regards,

Thomas Pointhuber



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