Re: [Kicad-developers] [PATCH] Add actions to linux desktop for start standalone applications from Kicad shortcut

[eldar.khayrullin]

Ping...

В Воскресенье, 22 апр. 2018 в 3:39 П. П., Eldar 
Khayrullin  написал:

Hello guys.
Look in the theme description.
The patch in attachement.
___
Mailing list: https://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] RegEx help

[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

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] RegEx help

[Shivpratap Chauhan]

According to documentation at
http://docs.wxwidgets.org/3.0/overview_resyntax.html

*? +? ?? {m}? {m,}? {m,n}? *Non-greedy* quantifiers, which match the same
possibilities, but prefer the smallest number rather than the largest
number of matches (see Matching
).

There seems to be difference greedy vs non-greedy quantifiers!


Thanks,
Shiv



On Sat, May 5, 2018 at 6:49 PM, Jeff Young  wrote:

> 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
>
>
___
Mailing list: https://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 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 
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, _( "&View" ) );
+
+AddMenuItem( viewMenu, ID_ZOOM_IN,
+ _( "Zoom &In" ), HELP_ZOOM_IN,
+ KiBitmap( zoom_in_xpm ) );
+
+AddMenuItem( viewMenu, ID_ZOOM_OUT,
+ _( "Zoom &Out" ), HELP_ZOOM_OUT,
+ KiBitmap( zoom_out_xpm ) );
+
+AddMenuItem( viewMenu, ID_ZOOM_PAGE,
+ _( "Zoom to &Fit" ), HELP_ZOOM_FIT,
+ KiBitmap( zoom_fit_in_page_xpm ) );
+
+AddMenuItem( viewMenu, ID_ZOOM_REDRAW,
+ _( "&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, _( "&Preferences" ) );
 
 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, _( "&Help" ) );
 
+AddMenuItem( helpMenu, wxID_HELP,
+ _( "Pcbnew &Manual" ),
+ _( "Open Pcbnew Manual" ),
+ KiBitmap( online_help_xpm ) );
+
+AddMenuItem( helpMenu, wxID_INDEX,
+ _( "&Getting Started in KiCad" ),
+ _( "Open \"Getting Started in KiCad\" guide for beginners" ),
+ KiBitmap( help_xpm ) );
+
 wxString text = AddHotkeyName( _( "&List Hotkeys..." ), g_3DViewer_Hokeys_Descr, HK_HELP );
 AddMenuItem( helpMenu, ID_MENU3D_HELP_HOTKEY_SHOW_CURRENT_LIST,
  text,
  _( "Displays the current hotkeys list and corresponding com

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

[Nick Østergaard]

Remember that a ascii freindly version can be used in the source and then
we can use the  unicode char in the translations. This is the reason there
is also a po file for english.

2018-05-04 17:59 GMT+02:00 jp charras :

>
>  Message transféré 
> Sujet : Re: [Kicad-developers] Fwd: Re: [PATCH] Adjust Menubar of 3D
> Viewer to common style
> Date : Thu, 3 May 2018 20:14:21 +0100
> De : Ruth Ivimey-Cook 
> Pour : jp charras 
>
> JP
>
> On 03/05/2018 18:45, jp charras wrote:
> > No.
> > Because only ASCII7 chars are allowed in strings to translate, because,
> AFAIK, I18N tools only
> > accept ASCII7 chars, not unicode char set.
> >
>
> I'm not quite sure if I've missed something, but it seems from:
>
> http://docs.wxwidgets.org/3.0.4/overview_unicode.html#
> overview_unicode_support_default
>
> that the ASCII7 limitation refers only to the compiled text file when
> using standard strings; and it
> seems the use of character escapes or L"" (wide) strings is supported.
>
> They give the examples:
>
> wxMessageBox(L"Salut \u00E0 toi!"); // U+00E0 is "Latin Small Letter a
> with Grave"
>
> wxMessageBox(wxString::FromUTF8("Salut \xC3\xA0 toi!"));
> // in UTF8 the character U+00E0 is encoded as 0xC3A0
>
> I cannot see any indication that a wxString passed to 
> wxTranslations::GetTranslatedString()
> is
> limited further than this.
>
> HTH
>
> Ruth
>
>
> The limitation is not in wxWidgets.
> It is in tools used to manage translations, that expect for input texts a
> ASCII7 string (poedit,
> gettext ...).
> Of course the output manage unicode strings.
>
> One can create strings with unicode chars, but there is no good way to do
> that:
> for instance
> use wxString::Format( _("Salut %c toi!"), 0x00E0)
>  (the string to translate is "Salut %c toi!")
> or
> wxString msg; msg << (_"Salut ") << wxChar(0x00E0) << _( " toi!");
>  (2 strings to translate _"Salut " and " toi!")
>
> the first is translatable, but not very readable in code
>
> the second is very bad because it is not really translatable, and not very
> readable in code.
> it is not really translatable because the order of words is fixed, and
> cannot be acceptable is other
> languages.
> Unfortunately it is sometimes used (even in Kicad code)
>
> --
> Jean-Pierre CHARRAS
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

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

[Wayne Stambaugh]

Thomas,

I merged your patches.  Thank you for your contribution to KiCad.

Cheers,

Wayne

On 05/05/2018 11:41 AM, Thomas Pointhuber wrote:

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



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


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

Re: [Kicad-developers] [RFC]: New non copper pad paste and mask clearances behavior V2

[Eeli Kaikkonen]

2018-05-03 23:39 GMT+03:00 Jeff Young :

> I’m happy to clean up the dialog if JP wants to check in what he has.
> Just let me know….
>

It looks cleaner now, but I noticed that the information is a bit
misleading. It says "solder mask and paste values are used only for pads on
copper layers" while actually it seems to be true for all the clearance
values, also the net pad clearance. That would make the text simpler and
shorter: "clearance values are used..."

I still don't know why the value fields should be editable for non-copper
pads because they are not applied anyways. Well, this is nitpicking, so it
can be ignored...

Eeli Kaikkonen
___
Mailing list: https://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] Was there a change in how the footprint name is stored inside the footprint files?

[Rene Pöschl]

It seems the footprint editor now includes the library name in the 
footprint name (first line of the footprint file)


Has this changed on purpose or is this a bug?


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

[Jeff Young]

Ahhh… I’m mixing up XPath and RegEx syntax.  ‘?’ is zero-or-one in XPath, not 
RegEx.

Thanks Shiv & Thomas.

Cheers,
Jeff


> On 5 May 2018, at 15:37, Shivpratap Chauhan  wrote:
> 
> According to documentation at 
> http://docs.wxwidgets.org/3.0/overview_resyntax.html 
> 
> 
> *? +? ?? {m}? {m,}? {m,n}?Non-greedy quantifiers, which match the same 
> possibilities, but prefer the smallest number rather than the largest number 
> of matches (see Matching 
> ).
> 
> There seems to be difference greedy vs non-greedy quantifiers!
> 
> 
> Thanks,
> Shiv
> 
> 
> 
> On Sat, May 5, 2018 at 6:49 PM, Jeff Young  > wrote:
> 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 
> 
> 
> 

___
Mailing list: https://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]: New non copper pad paste and mask clearances behavior V2

[Jeff Young]

Hmmm… I actually changed that on purpose because I thought the other was 
misleading.

We build the masks for the mask layers differently depending on whether or not 
the pads have any copper layers.

We don’t treat the pad clearance differently based on that constraint.

Now it’s true that we only check clearance between two items on the same copper 
layer, but that’s subtly different than “not on any copper layer”.

Perhaps too subtle?


> On 5 May 2018, at 20:19, Eeli Kaikkonen  wrote:
> 
> 
> 
> 2018-05-03 23:39 GMT+03:00 Jeff Young  >:
> I’m happy to clean up the dialog if JP wants to check in what he has.  Just 
> let me know….
> 
> It looks cleaner now, but I noticed that the information is a bit misleading. 
> It says "solder mask and paste values are used only for pads on copper 
> layers" while actually it seems to be true for all the clearance values, also 
> the net pad clearance. That would make the text simpler and shorter: 
> "clearance values are used..."
> 
> I still don't know why the value fields should be editable for non-copper 
> pads because they are not applied anyways. Well, this is nitpicking, so it 
> can be ignored...
> 
> Eeli Kaikkonen

___
Mailing list: https://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]: New non copper pad paste and mask clearances behavior V2

[Eeli Kaikkonen]

Are we talking about the same thing, and have I completely understood what
"net pad clearance" means? I don't quite get what you mean.

I'm talking about the pad-to-pad and pad-to-track clearances. Paste-only
and mask-only pads don't seem to have that at all in practice and it's not
applied to mask or paste layers even in pads which have copper layers.

For example I have experimental footprints with separate copper, paste and
mask pads in separate locations. When they are put into a board the mask or
paste pads of two different footprints can even overlap without DRC errors
while copper pads can't be too close to each other. If in the Display
Options I check Show pad clearance, the copper pads have clearance lines
around them but paste and mask pads don't. So I think that "Net pad
clearance" haven't had any effect for non-copper pads even before these
recent changes. There's no clearance value left in these four fields which
would be applied on non-copper pads (which Wayne called "aperture pads").

Based on that I think it would be correct to say "clearance values are used
only for pads on copper layers". Unless "pads on copper layers" is too
inaccurate. It looks like "pads which have at least one copper layer" would
be more accurate because that seems to make the difference whether
clearances are applied or not, and only the copper layers have "net pad
clearance". Anyways, the current text leads one to think that "net pad
clearance" would be used for non-copper pads.


Eeli Kaikkonen


2018-05-06 1:38 GMT+03:00 Jeff Young :

> Hmmm… I actually changed that on purpose because I thought the other was
> misleading.
>
> We build the masks for the mask layers differently depending on whether or
> not the pads have *any* copper layers.
>
> We don’t treat the pad clearance differently based on that constraint.
>
> Now it’s true that we only check clearance between two items on the same
> copper layer, but that’s subtly different than “not on any copper layer”.
>
> Perhaps too subtle?
>
>
> On 5 May 2018, at 20:19, Eeli Kaikkonen  wrote:
>
>
>
> 2018-05-03 23:39 GMT+03:00 Jeff Young :
>
>> I’m happy to clean up the dialog if JP wants to check in what he has.
>> Just let me know….
>>
>
> It looks cleaner now, but I noticed that the information is a bit
> misleading. It says "solder mask and paste values are used only for pads on
> copper layers" while actually it seems to be true for all the clearance
> values, also the net pad clearance. That would make the text simpler and
> shorter: "clearance values are used..."
>
> I still don't know why the value fields should be editable for non-copper
> pads because they are not applied anyways. Well, this is nitpicking, so it
> can be ignored...
>
> Eeli Kaikkonen
>
>
>
___
Mailing list: https://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]: New non copper pad paste and mask clearances behavior V2

[Jeff Young]

Yes, we’re talking about the same thing.  Net clearance only applies between 
items on the same layer: i.e. a track on F.Cu must not be within that distance 
of a pad on F.Cu.

But a track on B.Cu doesn’t have any clearance constraints against a pad on 
F.Cu.  It’s not that aperture pads have no clearance values, but rather that 
non-matching copper layers don’t have clearance values.  And that's the way 
it’s always been (unlike the behaviour of aperture pads which was just changed).

> On 6 May 2018, at 00:38, Eeli Kaikkonen  wrote:
> 
> 
> Are we talking about the same thing, and have I completely understood what 
> "net pad clearance" means? I don't quite get what you mean.
> 
> I'm talking about the pad-to-pad and pad-to-track clearances. Paste-only and 
> mask-only pads don't seem to have that at all in practice and it's not 
> applied to mask or paste layers even in pads which have copper layers.
> 
> For example I have experimental footprints with separate copper, paste and 
> mask pads in separate locations. When they are put into a board the mask or 
> paste pads of two different footprints can even overlap without DRC errors 
> while copper pads can't be too close to each other. If in the Display Options 
> I check Show pad clearance, the copper pads have clearance lines around them 
> but paste and mask pads don't. So I think that "Net pad clearance" haven't 
> had any effect for non-copper pads even before these recent changes. There's 
> no clearance value left in these four fields which would be applied on 
> non-copper pads (which Wayne called "aperture pads").
> 
> Based on that I think it would be correct to say "clearance values are used 
> only for pads on copper layers". Unless "pads on copper layers" is too 
> inaccurate. It looks like "pads which have at least one copper layer" would 
> be more accurate because that seems to make the difference whether clearances 
> are applied or not, and only the copper layers have "net pad clearance". 
> Anyways, the current text leads one to think that "net pad clearance" would 
> be used for non-copper pads.
> 
> 
> Eeli Kaikkonen
> 
> 
> 2018-05-06 1:38 GMT+03:00 Jeff Young mailto:j...@rokeby.ie>>:
> Hmmm… I actually changed that on purpose because I thought the other was 
> misleading.
> 
> We build the masks for the mask layers differently depending on whether or 
> not the pads have any copper layers.
> 
> We don’t treat the pad clearance differently based on that constraint.
> 
> Now it’s true that we only check clearance between two items on the same 
> copper layer, but that’s subtly different than “not on any copper layer”.
> 
> Perhaps too subtle?
> 
> 
>> On 5 May 2018, at 20:19, Eeli Kaikkonen > > wrote:
>> 
>> 
>> 
>> 2018-05-03 23:39 GMT+03:00 Jeff Young > >:
>> I’m happy to clean up the dialog if JP wants to check in what he has.  Just 
>> let me know….
>> 
>> It looks cleaner now, but I noticed that the information is a bit 
>> misleading. It says "solder mask and paste values are used only for pads on 
>> copper layers" while actually it seems to be true for all the clearance 
>> values, also the net pad clearance. That would make the text simpler and 
>> shorter: "clearance values are used..."
>> 
>> I still don't know why the value fields should be editable for non-copper 
>> pads because they are not applied anyways. Well, this is nitpicking, so it 
>> can be ignored...
>> 
>> Eeli Kaikkonen
> 
> 

___
Mailing list: https://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]: New non copper pad paste and mask clearances behavior V2

[Eeli Kaikkonen]

2018-05-06 2:48 GMT+03:00 Jeff Young :

> Yes, we’re talking about the same thing.  Net clearance only applies
> between items on the same layer: i.e. a track on F.Cu must not be within
> that distance of a pad on F.Cu.
>
> But a track on B.Cu doesn’t have any clearance constraints against a pad
> on F.Cu.  It’s not that aperture pads have no clearance values, but rather
> that non-matching copper layers don’t have clearance values.  And that's
> the way it’s always been (unlike the behaviour of aperture pads which was
> just changed).
>
>
>
OK. But non-copper pads (or non-copper layers in normal pads) don't have
"net pad clearance" at all, even when they collide with another pad's items
in the same layer. And because the other clearance values aren't applied to
aperture pads it would be appropriate to say "clearance values are used
only for pads on copper layers".
___
Mailing list: https://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] RegEx help

[Tiger12506]

No, '?' also means zero-or-one in RegEx syntax, it's just that it *also* 
happens to mean "make the previous quantity modifier non-greedy" if 
there is a previous quantity modifier. Notice the double-question mark 
regex in the documentation quote previously pasted. That one means make 
the zero-or-one quantifier non-greedy.


On 5/5/2018 5:58 PM, Jeff Young wrote:
Ahhh… I’m mixing up XPath and RegEx syntax.  ‘?’ is zero-or-one in 
XPath, not RegEx.


Thanks Shiv & Thomas.

Cheers,
Jeff


On 5 May 2018, at 15:37, Shivpratap Chauhan > wrote:


According to documentation at 
http://docs.wxwidgets.org/3.0/overview_resyntax.html


|*? +? ?? {m}? {m,}? {m,n}?| 	/Non-greedy/ quantifiers, which match 
the same possibilities, but prefer the smallest number rather than 
the largest number of matches (see Matching 
). 




There seems to be difference greedy vs non-greedy quantifiers!


Thanks,
Shiv



On Sat, May 5, 2018 at 6:49 PM, Jeff Young > wrote:


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






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