Re: [Kicad-developers] Feature request : Allow hide of Fab text reference designation

[José Ignacio]

That is a library issue, the way it is implemented in the kicad library is
making a text that references the refdes with "%R", that looks like a
normal text to kicad, so it has no way of knowing unless it gets tailored a
bit too specific to that library style. In my particular case i do not use
the kicad standard library (partly for that reason) and get the reference
designators in my fab aids by compositing the silkscreen layer onto the fab.

On Wed, May 2, 2018 at 4:41 PM, Brian Piccioni 
wrote:

> Sorry if this is not the correct venue for this request, of it has already
> been addressed.
>
>
>
> The issue:
>
>
>
>1. Reference designation is presented in the silkscreen and duplicated
>in many library parts as a FAB layer text.
>2. Silkscreen text is usually manually adjusted to make it readable
>prior to manufacturing.
>3. The position of the FAB layer reference designation is independent
>of the Silkscreen reference designation.
>4. Fab layer typically has part number, value or other information.
>5. As an assembly aid, it may be desirable to print the Fab layer.
>6. Because the Fab layer reference designation position is independent
>from the silkscreen reference designation, to print the Fab layer all Fab
>layer reference designation has to be manually adjusted to make it line up
>properly (i.e. like the silkscreen).
>7. This is redundant and unnecessary as the silkscreen reference
>designation has already been moved.
>8. It is easier to simply hide the Fab lay reference designation and
>print both the silkscreen and fab layer.
>
>
>
> Therefor I suggest a mechanism (perhaps in the Layers menu or Set Text
> Size menu) which selectively hides/unhides Fab layer reference designation.
>
> ___
> Mailing list: https://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

[Rene Pöschl]

This sounds like a reasonable solution for kicad 5 to me.
Thanks for taking care of it.

On 02/05/18 14:58, jp charras wrote:

Hi All,

Dick Hollenbeck ( who wrote a lot of code for Kicad) proposed to use global 
mask margin values only
for pad at least on a copper layer.

(I am thinking this is also what was expected by some of guys)

Attached, a patch to use global mask settings only for pads on copper layers to 
build the mask shape
(solder or paste layer) of the pad.

Therefore pads *only* on a solder or paste layer are no longer affected by 
global settings.
(The drawback is a change in the behavior of previous Pcbnew versions, but it 
should not impact a
lot of old boards or old footprints)

The change in code is very small.

I added a info message in dialogs, in the pad clearance setup sub-window to 
explain the purpose of
this setting.
This is perhaps the main problem, because a message in a dialog must be short, 
and yet understandable...
The info messages are not perfect.

Please, test it.



___
Mailing list: https://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] Proposed Geographic PCB Re-Annotation for Kicad 6

[Brian Piccioni]

Sorry if this is a duplicate: I originally sent if from my non-registered
email address.

 

Proposed Geographic PCB Re-Annotation for Kicad 6

I wrote a standalone program called RenumKiCadPCB which does a rules-based
geographical renumbering of PCB components and back-annotates the schematic
hierarchy and netlist.

As it stands, this is an external program written in c.

Having looked at the Kicad codebase I believe it can be incorporated into
Kicad as a standard function. Because this is common in commercial
electronic CAD I believe it would be appreciated by the user base. Manual
geographic re-annotation is time consuming and source of potential error. 

Currently the freestanding code works like this (summary):

1.  Drops into a primitive text based menu system for set up;
2.  Parses the schematic hierarchy to determine storage requirements and
file paths;
3.  Parses the PCB file to locate all components and their locations;
4.  Creates a sorted "change list" based upon the rules for sort
direction and the results of step 2;
5.  Makes backups of the schematics, PCB, and netlist;
6.  Updates all schematic symbol reference designations in accordance
with the "Change List";
7.  Updates the PCB reference designations and nets in accordance with
the "Change List";
8.  Updates the Netlist reference designations and nets in accordance
with the "Change List";
9.  Writes out the updated files.

There are various "traps", etc., if errors are detected.

Besides the issues of being a standalone program, the need to parse the
various file formats (SCH, Kicad_PCB, netlist) means that if simply ported
into Kicad the code would have to be constantly updated in order to
accommodate even small changes to the file formats.

Having spent some time looking at the Kicad code base, I am pretty sure all
but step 1 (the menu) and step 4 (creation of a rules-based change list) can
be replaced by calls to existing Kicad functions, in particular those used
for search and replace, editing text, etc.. I assume it is possible to spawn
eeSchema from PCBNew in order to do the search and replace on the schematic
hierarchy and to regenerate the netlist.

The Netlist Importer menu in PCB new would make a good prototype for the new
menu.

Use of existing Kicad functions would probably result in the code running
slower than it currently runs ( << 1 second for a large board) but that
should not be a problem since this is the sort of thing which is rarely run
more than a couple of times during the life of the project. 

Nevertheless, use of existing functions ensure the geographical reannotation
would be robust against any future changes to file formats, etc., since
reference designations and coordinates are inherent characteristics in an ee
CAD system.

 

Risks

I have to note that my participation has some risk:

1.  I am old (60) and have never written code as part of a large,
collaborative project: most of my programming experience is limited to
embedded designs;
2.  I have only a passing familiarity with c++;
3.  I am not used to the sort of documentation associated with Kicad;
4.  These imply a steep learning curve for an old guy;
5.  As such, it will probably take me much longer than a skilled
programmer to do this.

 

Therefore, it would be helpful if there was a mentor I could turn to for
some guidance, if the developers accept that this is a good idea.

I would appreciate any feedback. If you think this would not be a good thing
to pursue, please let me know.

 

Regards

 

Brian Piccioni

Documented Designs

 

___
Mailing list: https://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 (was: What are the smallest values for pad paste and mask clearances)

[Seth Hillbrand]

​Hi JP-

The patch seems to function as expected.  Minor issue is that the pad
properties dialog now opens to the second tab active and doesn't focus (so
pressing escape doesn't work until you click on the dialog).

I'm in favor of the change as long as we keep it minimized like you have.

-S
​



Am Mi., 2. Mai 2018 um 14:11 Uhr schrieb Jeff Young :

> Personally I think this is one of those times to be pragmatic.  Yes, the
> patch changes the interpretation of existing files (which in principle is a
> bad thing), but we’re willing to live with it in this case.
>
> I don’t have much of an opinion on the exact algorithm we should use.
>
> Cheers,
> Jeff.
>
> On 2 May 2018, at 21:57, Eeli Kaikkonen  wrote:
>
> The patch seems to work as intented.
>
> But I thought Wayne said this won't be done because it would alter
> interpretation of old existing board and footprints files. On the other
> hand it's hard to imagine someone having designed footprints and boards
> using and taking into consideration the global values, without noticing and
> using this trick of using a very small value instead.
>
> If this kind of change is made I think a more radical change would be more
> logical. Why use these clearances for non-copper pads at all? I just can't
> see why I or anyone would design a pad with certain dimensions and then
> alter those dimensions on purpose with those clearance values. For example
> I want a paste pad of 1.5x1.5mm. Why would I make it 2.0x2.0 and then
> calculate values for paste clearance and % to make it smaller? Being able
> to define the mask clearance for a paste-only pad makes even less sense.
> Therefore they could be ignored completely and the corresponding GUI items
> could be disabled or hidden. Instead of one explanation text which would
> cover all cases with all pads it could be conditional: in the copper pads
> it would read as it is, in the non-copper pads it would be "Clearance
> values are not used for non-copper pads" or something as simple.
>
> Eeli Kaikkonen
>
> 2018-05-02 15:58 GMT+03:00 jp charras :
>
>> Hi All,
>>
>> Dick Hollenbeck ( who wrote a lot of code for Kicad) proposed to use
>> global mask margin values only
>> for pad at least on a copper layer.
>>
>> (I am thinking this is also what was expected by some of guys)
>>
>
> Attached, a patch to use global mask settings only for pads on copper
>> layers to build the mask shape
>> (solder or paste layer) of the pad.
>>
>> Therefore pads *only* on a solder or paste layer are no longer affected
>> by global settings.
>> (The drawback is a change in the behavior of previous Pcbnew versions,
>> but it should not impact a
>> lot of old boards or old footprints)
>>
>> The change in code is very small.
>>
>> I added a info message in dialogs, in the pad clearance setup sub-window
>> to explain the purpose of
>> this setting.
>> This is perhaps the main problem, because a message in a dialog must be
>> short, and yet understandable...
>> The info messages are not perfect.
>>
>> Please, test it.
>>
>> --
>> 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

[Kicad-developers] Feature request : Allow hide of Fab text reference designation

[Brian Piccioni]

Sorry if this is not the correct venue for this request, of it has already
been addressed.

 

The issue:

 

1.  Reference designation is presented in the silkscreen and duplicated
in many library parts as a FAB layer text. 
2.  Silkscreen text is usually manually adjusted to make it readable
prior to manufacturing.
3.  The position of the FAB layer reference designation is independent
of the Silkscreen reference designation.
4.  Fab layer typically has part number, value or other information.
5.  As an assembly aid, it may be desirable to print the Fab layer.
6.  Because the Fab layer reference designation position is independent
from the silkscreen reference designation, to print the Fab layer all Fab
layer reference designation has to be manually adjusted to make it line up
properly (i.e. like the silkscreen).
7.  This is redundant and unnecessary as the silkscreen reference
designation has already been moved.
8.  It is easier to simply hide the Fab lay reference designation and
print both the silkscreen and fab layer.

 

Therefor I suggest a mechanism (perhaps in the Layers menu or Set Text Size
menu) which selectively hides/unhides Fab layer reference designation.

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

[Wayne Stambaugh]

Pragmatism is the reason I've asked JP to create this patch.  Rather 
than create a lot of extra work for our librarians and creating a file 
format change that doesn't really buy us much, I reconsidered my 
original decision.  I doubt many users are currently using "aperture 
pads" so I think the risk is low and the longer we push this off, the 
greater the problem will be.  I already have an announcement prepared 
for the website once this makes its way into the repo.  I will also post 
a link to the announcement on the user forum and update the Pcbnew 
documentation.


On 05/02/2018 05:11 PM, Jeff Young wrote:
Personally I think this is one of those times to be pragmatic.  Yes, the 
patch changes the interpretation of existing files (which in principle 
is a bad thing), but we’re willing to live with it in this case.


I don’t have much of an opinion on the exact algorithm we should use.

Cheers,
Jeff.

On 2 May 2018, at 21:57, Eeli Kaikkonen > wrote:


The patch seems to work as intented.

But I thought Wayne said this won't be done because it would alter 
interpretation of old existing board and footprints files. On the 
other hand it's hard to imagine someone having designed footprints and 
boards using and taking into consideration the global values, without 
noticing and using this trick of using a very small value instead.


If this kind of change is made I think a more radical change would be 
more logical. Why use these clearances for non-copper pads at all? I 
just can't see why I or anyone would design a pad with certain 
dimensions and then alter those dimensions on purpose with those 
clearance values. For example I want a paste pad of 1.5x1.5mm. Why 
would I make it 2.0x2.0 and then calculate values for paste clearance 
and % to make it smaller? Being able to define the mask clearance for 
a paste-only pad makes even less sense. Therefore they could be 
ignored completely and the corresponding GUI items could be disabled 
or hidden. Instead of one explanation text which would cover all cases 
with all pads it could be conditional: in the copper pads it would 
read as it is, in the non-copper pads it would be "Clearance values 
are not used for non-copper pads" or something as simple.


Eeli Kaikkonen

2018-05-02 15:58 GMT+03:00 jp charras >:


Hi All,

Dick Hollenbeck ( who wrote a lot of code for Kicad) proposed to
use global mask margin values only
for pad at least on a copper layer.

(I am thinking this is also what was expected by some of guys)

Attached, a patch to use global mask settings only for pads on
copper layers to build the mask shape
(solder or paste layer) of the pad.

Therefore pads *only* on a solder or paste layer are no longer
affected by global settings.
(The drawback is a change in the behavior of previous Pcbnew
versions, but it should not impact a
lot of old boards or old footprints)

The change in code is very small.

I added a info message in dialogs, in the pad clearance setup
sub-window to explain the purpose of
this setting.
This is perhaps the main problem, because a message in a dialog
must be short, and yet understandable...
The info messages are not perfect.

Please, test it.

-- 
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] [RFC]: New non copper pad paste and mask clearances behavior (was: What are the smallest values for pad paste and mask clearances)

[Jeff Young]

Personally I think this is one of those times to be pragmatic.  Yes, the patch 
changes the interpretation of existing files (which in principle is a bad 
thing), but we’re willing to live with it in this case.

I don’t have much of an opinion on the exact algorithm we should use.

Cheers,
Jeff.

> On 2 May 2018, at 21:57, Eeli Kaikkonen  wrote:
> 
> The patch seems to work as intented.
> 
> But I thought Wayne said this won't be done because it would alter 
> interpretation of old existing board and footprints files. On the other hand 
> it's hard to imagine someone having designed footprints and boards using and 
> taking into consideration the global values, without noticing and using this 
> trick of using a very small value instead.
> 
> If this kind of change is made I think a more radical change would be more 
> logical. Why use these clearances for non-copper pads at all? I just can't 
> see why I or anyone would design a pad with certain dimensions and then alter 
> those dimensions on purpose with those clearance values. For example I want a 
> paste pad of 1.5x1.5mm. Why would I make it 2.0x2.0 and then calculate values 
> for paste clearance and % to make it smaller? Being able to define the mask 
> clearance for a paste-only pad makes even less sense. Therefore they could be 
> ignored completely and the corresponding GUI items could be disabled or 
> hidden. Instead of one explanation text which would cover all cases with all 
> pads it could be conditional: in the copper pads it would read as it is, in 
> the non-copper pads it would be "Clearance values are not used for non-copper 
> pads" or something as simple.
> 
> Eeli Kaikkonen
> 
> 2018-05-02 15:58 GMT+03:00 jp charras  >:
> Hi All,
> 
> Dick Hollenbeck ( who wrote a lot of code for Kicad) proposed to use global 
> mask margin values only
> for pad at least on a copper layer.
> 
> (I am thinking this is also what was expected by some of guys)
>  
> Attached, a patch to use global mask settings only for pads on copper layers 
> to build the mask shape
> (solder or paste layer) of the pad.
> 
> Therefore pads *only* on a solder or paste layer are no longer affected by 
> global settings.
> (The drawback is a change in the behavior of previous Pcbnew versions, but it 
> should not impact a
> lot of old boards or old footprints)
> 
> The change in code is very small.
> 
> I added a info message in dialogs, in the pad clearance setup sub-window to 
> explain the purpose of
> this setting.
> This is perhaps the main problem, because a message in a dialog must be 
> short, and yet understandable...
> The info messages are not perfect.
> 
> Please, test it.
> 
> -- 
> Jean-Pierre CHARRAS
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [RFC]: New non copper pad paste and mask clearances behavior (was: What are the smallest values for pad paste and mask clearances)

[Eeli Kaikkonen]

The patch seems to work as intented.

But I thought Wayne said this won't be done because it would alter
interpretation of old existing board and footprints files. On the other
hand it's hard to imagine someone having designed footprints and boards
using and taking into consideration the global values, without noticing and
using this trick of using a very small value instead.

If this kind of change is made I think a more radical change would be more
logical. Why use these clearances for non-copper pads at all? I just can't
see why I or anyone would design a pad with certain dimensions and then
alter those dimensions on purpose with those clearance values. For example
I want a paste pad of 1.5x1.5mm. Why would I make it 2.0x2.0 and then
calculate values for paste clearance and % to make it smaller? Being able
to define the mask clearance for a paste-only pad makes even less sense.
Therefore they could be ignored completely and the corresponding GUI items
could be disabled or hidden. Instead of one explanation text which would
cover all cases with all pads it could be conditional: in the copper pads
it would read as it is, in the non-copper pads it would be "Clearance
values are not used for non-copper pads" or something as simple.

Eeli Kaikkonen

2018-05-02 15:58 GMT+03:00 jp charras :

> Hi All,
>
> Dick Hollenbeck ( who wrote a lot of code for Kicad) proposed to use
> global mask margin values only
> for pad at least on a copper layer.
>
> (I am thinking this is also what was expected by some of guys)
>

Attached, a patch to use global mask settings only for pads on copper
> layers to build the mask shape
> (solder or paste layer) of the pad.
>
> Therefore pads *only* on a solder or paste layer are no longer affected by
> global settings.
> (The drawback is a change in the behavior of previous Pcbnew versions, but
> it should not impact a
> lot of old boards or old footprints)
>
> The change in code is very small.
>
> I added a info message in dialogs, in the pad clearance setup sub-window
> to explain the purpose of
> this setting.
> This is perhaps the main problem, because a message in a dialog must be
> short, and yet understandable...
> The info messages are not perfect.
>
> Please, test it.
>
> --
> Jean-Pierre CHARRAS
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [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] Requesting feedback regarding "Update Footprints" menu item

[Eeli Kaikkonen]

2018-05-02 16:03 GMT+03:00 Jeff Young :

> I was mostly looking for feedback on how much people hated wide context
> menus.
>
> But someone else suggested just making the dialog title include “from
> library”, which sounded like a good idea…
>
> … except that it already does.  At that point I figured “good enough”.  ;)
>
>
We might be suprised if we saw some statistics on how many computer users
actually read the window titles. It's probably near zero. I meant that the
text would stand inside the dialog on top of the radio button options. I
saw the window title but knew it's not enough for average users.

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] Requesting feedback regarding "Update Footprints" menu item

[Jeff Young]

I was mostly looking for feedback on how much people hated wide context menus.

But someone else suggested just making the dialog title include “from library”, 
which sounded like a good idea… 

… except that it already does.  At that point I figured “good enough”.  ;)

Cheers,
Jeff.

> On 2 May 2018, at 13:00, Wayne Stambaugh  wrote:
> 
> Jeff,
> 
> I'm not sure what feedback you are looking for.  If I'm reading the
> forum post correctly, it appears the user was confused about the
> difference between "update footprint from library" and "change
> footprint".  This seems clear to me but then again, I'm not new to board
> layout software so maybe this is just a rookie mistake.
> 
> Cheers,
> 
> Wayne
> 
> On 5/1/2018 5:14 PM, Jeff Young wrote:
>> See https://forum.kicad.info/t/issue-updating-footprint-in-v5/10536/5.
>> 
>> 
>> ___
>> Mailing list: https://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] Layers widget font scaling

[Jeff Young]

It occurs to me that on MSW and OSX one can increase the system font size for 
readability.

So I’ve added code which only adjusts the font size if it’s larger than the 
layer widget swatch size, but does so uniformly on all platforms/apps.

Sound reasonable?

> On 2 May 2018, at 13:38, Wayne Stambaugh  wrote:
> 
> On 5/2/2018 8:11 AM, jp charras wrote:
>> Le 02/05/2018 à 11:03, Jeff Young a écrit :
>>> If your screen reports  a height of 900 pixels or less we scale the 
>>> system-default fontsize for PCB_EDIT_FRAME (but not FOOTPRINT_EDIT_FRAME).
>>> 
>>> This results in poor readability on at least some MSW systems 
>>> (https://bugs.launchpad.net/kicad/+bug/1767965) and for those with ageing 
>>> eyesight (i.e. me).
>>> 
>>> On OSX, it also doesn’t help as the row height is controlled by the 
>>> checkboxes.  So the list doesn’t actually get any shorter with the smaller 
>>> fonts (although it does get marginally less wide).
>>> 
>>> Judging by the screenshot in the above bug report, MSW also doesn’t really 
>>> benefit from the scaled font: the Render list is still much shorter than 
>>> the vertical icon bar.
>>> 
>>> I’d like to remove the scaling on at least OSX and MSW.  Are there any 
>>> objections, and are there any reasons not to remove it on GTK as well?
>>> 
>>> Thanks,
>>> Jeff.
>> 
>> AFAIK, reducing font size was useful when a lot of layers is used (16 to 32 
>> copper layers) and/or
>> there are long copper layer names or when a big font is in use.
>> 
>> Without removing this feature, the best way is to reduce the size with a 
>> minimal acceptable final
>> size ( for instance >= 8 points).
> 
> The problem with a fixed font size is on high dpi displays they may be
> unreadable.
> 
>> 
>> Obviously, if the default size is already small, a smaller size is not 
>> useful, and a reduced font
>> size gives not readable texts.
>> 
> 
> I propose that in the short term we use the reduced font only for gtk on
> linux where it seems to work fairly well.  In the future, we could just
> make the layer manager font a user option rather than try to guess what
> scaling may work on a given platform.
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [RFC]: New non copper pad paste and mask clearances behavior (was: What are the smallest values for pad paste and mask clearances)

[jp charras]

Hi All,

Dick Hollenbeck ( who wrote a lot of code for Kicad) proposed to use global 
mask margin values only
for pad at least on a copper layer.

(I am thinking this is also what was expected by some of guys)

Attached, a patch to use global mask settings only for pads on copper layers to 
build the mask shape
(solder or paste layer) of the pad.

Therefore pads *only* on a solder or paste layer are no longer affected by 
global settings.
(The drawback is a change in the behavior of previous Pcbnew versions, but it 
should not impact a
lot of old boards or old footprints)

The change in code is very small.

I added a info message in dialogs, in the pad clearance setup sub-window to 
explain the purpose of
this setting.
This is perhaps the main problem, because a message in a dialog must be short, 
and yet understandable...
The info messages are not perfect.

Please, test it.

-- 
Jean-Pierre CHARRAS
From 3fde6b1978fda791c6f21017967bce5a0391a720 Mon Sep 17 00:00:00 2001
From: jean-pierre charras 
Date: Wed, 2 May 2018 10:31:10 +0200
Subject: [PATCH] mask clearances: use global clearances only for pads on
 copper layers.

---
 pcbnew/class_pad.cpp   | 68 +++--
 pcbnew/class_pad.h | 26 ---
 .../dialog_edit_footprint_for_BoardEditor_base.cpp | 10 ++-
 .../dialog_edit_footprint_for_BoardEditor_base.fbp | 84 +++-
 .../dialog_edit_footprint_for_BoardEditor_base.h   |  6 +-
 .../dialog_edit_footprint_for_fp_editor_base.cpp   | 10 ++-
 .../dialog_edit_footprint_for_fp_editor_base.fbp   | 84 +++-
 .../dialog_edit_footprint_for_fp_editor_base.h |  6 +-
 pcbnew/dialogs/dialog_mask_clearance_base.cpp  | 15 ++--
 pcbnew/dialogs/dialog_mask_clearance_base.fbp  | 89 +-
 pcbnew/dialogs/dialog_mask_clearance_base.h|  9 ++-
 pcbnew/dialogs/dialog_pad_properties_base.cpp  | 10 +--
 pcbnew/dialogs/dialog_pad_properties_base.fbp  |  7 +-
 pcbnew/dialogs/dialog_pad_properties_base.h|  6 +-
 14 files changed, 364 insertions(+), 66 deletions(-)

diff --git a/pcbnew/class_pad.cpp b/pcbnew/class_pad.cpp
index 75540aa..58998ff 100644
--- a/pcbnew/class_pad.cpp
+++ b/pcbnew/class_pad.cpp
@@ -1,9 +1,9 @@
 /*
  * This program source code file is part of KiCad, a free EDA CAD application.
  *
- * Copyright (C) 2016 Jean-Pierre Charras, jp.charras at wanadoo.fr
+ * Copyright (C) 2018 Jean-Pierre Charras, jp.charras at wanadoo.fr
  * Copyright (C) 2012 SoftPLC Corporation, Dick Hollenbeck 
-  * Copyright (C) 1992-2016 KiCad Developers, see AUTHORS.txt for contributors.
+  * Copyright (C) 1992-2018 KiCad Developers, see AUTHORS.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
@@ -577,20 +577,30 @@ int D_PAD::GetClearance( BOARD_CONNECTED_ITEM* aItem ) 
const
 int D_PAD::GetSolderMaskMargin() const
 {
 int margin = m_LocalSolderMaskMargin;
-MODULE* module = GetParent();
 
-if( module )
+// The pad inherits the margin only to calculate a default shape,
+// therefore only if it is also a copper layer
+// Pads defined only on mask layers (and perhaps on other tech layers) use 
the shape
+// defined by the pad settings only
+bool isOnCopperLayer = ( m_layerMask & LSET::AllCuMask() ).any();
+
+if( isOnCopperLayer )
 {
-if( margin == 0 )
-{
-if( module->GetLocalSolderMaskMargin() )
-margin = module->GetLocalSolderMaskMargin();
-}
+MODULE* module = GetParent();
 
-if( margin == 0 )
+if( module )
 {
-BOARD* brd = GetBoard();
-margin = brd->GetDesignSettings().m_SolderMaskMargin;
+if( margin == 0 )
+{
+if( module->GetLocalSolderMaskMargin() )
+margin = module->GetLocalSolderMaskMargin();
+}
+
+if( margin == 0 )
+{
+BOARD* brd = GetBoard();
+margin = brd->GetDesignSettings().m_SolderMaskMargin;
+}
 }
 }
 
@@ -611,24 +621,34 @@ wxSize D_PAD::GetSolderPasteMargin() const
 {
 int margin = m_LocalSolderPasteMargin;
 double  mratio = m_LocalSolderPasteMarginRatio;
-MODULE* module = GetParent();
 
-if( module )
+// The pad inherits the margin only to calculate a default shape,
+// therefore only if it is also a copper layer.
+// Pads defined only on mask layers (and perhaps on other tech layers) use 
the shape
+// defined by the pad settings only
+bool isOnCopperLayer = ( m_layerMask & LSET::AllCuMask() ).any();
+
+if( isOnCopperLayer )
 {
-if( margin == 0 )
-margin = module->GetLocalSolderPasteMargin();
+MODULE* module = GetParent();
 
-BOARD * brd = GetBoard();
+

Re: [Kicad-developers] A reminder on Git commit comments

[Rene Pöschl]

Most of our contributors have no previous experience with git. So we 
really can not expect them to understand anything beyond the github 
workflow. (They are experts in electronics. Not IT) I also don't believe 
we should burden the contributors with too much with this.


This is even true for the maintainers. They are selected because they 
understand how to make good symbols and footprints. (Understanding of 
industry standards, limitations of manufacturing processes and the 
limitations of kicad)


For a lot of our casual contributors the current way of contributing is 
already too complex. I have seen a lot of them simply give up as soon as 
git did something they did not expect. This is especially common on the 
symbol lib side as it is likely that the contributor needs to do a 
manual merge because somebody else touched the same lib.


These casual contributions can in most cases be summarized as a single 
"added symbol for component x" message. The enduser might not be 
concerned on the detailed mistakes made by the contributor. (And if they 
are, the pull request is always linked to the contribution anyways.)
As we don't want users to hide their history from us maintainers (we 
want to see what they changed after feedback from us) we really do not 
want them to squash their commits (by using amend).


So the best solution might be to use the github squash merge feature 
instead of a normal merge and require the maintainer to write a good 
message about what changed. (Of course only if the contributor did not 
already make good commit messages.)



On 02/05/18 14:06, Wayne Stambaugh wrote:

This is why we have a commit message policy.  Obviously this isn't a
perfect solution.  Feel free to adopt this policy for library developer
commits.  There is always the hard line approach where you kick the
merge request back to the submitted and ask them to fix the commit
message or use `git commit --amend` to fix the commit message yourself.

On 5/1/2018 6:03 PM, Reece R. Pollack wrote:

I'd like to make an observation on some of the Git commit comments I'm
reading. Some of these commit log entries are really unhelpful.

When I was at University many, many years ago, students were taught to
place comments in their code. Many misunderstood the purpose of
comments, though, and would write code like this:

 x = x + 1;   /* Add 1 to x */


While the comment is totally correct, it's also totally useless. I can
/see/ that this line adds 1 to /x/; I don't need a comment to tell me
that. As a programmer coming along later, what I need to know is /why/ 1
is being added to /x/.

I'm seeing commit comments of the form "add one to x" in the KiCad
repos. These comments are useless. For an example, look at this commit
in the kicad-symbols repo:

 commit 4ada78e26774c841ce8ec33e8b221d04fed1f4c7
 Author: Rene Pöschl 
 Date:   Fri Apr 20 11:14:47 2018 +0200

 Remove Connector_Specialized files.

Great. I can /see/ that these files are being removed. That's obvious
from looking at the content of the commit. But there is no explanation
of why these files were deleted. Don't tell me that there was discussion
about this in email; even if that happened it's irrelevant. No one
should have to go chasing through an email archive hoping to understand
why a change was made. That's what the commit log entry is for.

I went back further in the Git logs for commits touching these files
hoping to find a more illuminating commit comment, but found nothing
helpful. In fact, I came across an earlier series of commits that are
even /less/ helpful:

 commit 467170586b106d00c4df185dc1683046e259b74c
 Author: evanshultz 
 Date:   Thu Apr 19 09:42:52 2018 -0700

 Just checking... still no dice

 commit 966a1a40aa36732d9c2404b044a4ef63bd0bb417
 Author: evanshultz 
 Date:   Thu Apr 19 09:36:28 2018 -0700

 Delete Connector_Specialized.lib

 commit aeb4270213da8a063f24163d6fa31e8521f08a83
 Author: evanshultz 
 Date:   Thu Apr 19 09:36:03 2018 -0700

 Delete Connector_Specialized.dcm

The top (latest) commit actually reverts the actions of the previous two
commits. So now I have the idea that there's some sort of disagreement
whether these files should be part of the repo or not. But I still have
no idea why.

In a previous job I was the poor sod (or arrogant bastard, take your
pick) who had to review commits before they were merged into the master
branch. I would have rejected commits like these immediately. With Open
Source development there's often less control over what gets merged and
what doesn't. But that just means it's all the more important for
everyone to make an effort to write good commit comments.

 From the KiCad source file
Documentation/development/commit-message-format.md:

 Commit messages should begin 

Re: [Kicad-developers] Layers widget font scaling

[Wayne Stambaugh]

On 5/2/2018 8:11 AM, jp charras wrote:
> Le 02/05/2018 à 11:03, Jeff Young a écrit :
>> If your screen reports  a height of 900 pixels or less we scale the 
>> system-default fontsize for PCB_EDIT_FRAME (but not FOOTPRINT_EDIT_FRAME).
>>
>> This results in poor readability on at least some MSW systems 
>> (https://bugs.launchpad.net/kicad/+bug/1767965) and for those with ageing 
>> eyesight (i.e. me).
>>
>> On OSX, it also doesn’t help as the row height is controlled by the 
>> checkboxes.  So the list doesn’t actually get any shorter with the smaller 
>> fonts (although it does get marginally less wide).
>>
>> Judging by the screenshot in the above bug report, MSW also doesn’t really 
>> benefit from the scaled font: the Render list is still much shorter than the 
>> vertical icon bar.
>>
>> I’d like to remove the scaling on at least OSX and MSW.  Are there any 
>> objections, and are there any reasons not to remove it on GTK as well?
>>
>> Thanks,
>> Jeff.
> 
> AFAIK, reducing font size was useful when a lot of layers is used (16 to 32 
> copper layers) and/or
> there are long copper layer names or when a big font is in use.
> 
> Without removing this feature, the best way is to reduce the size with a 
> minimal acceptable final
> size ( for instance >= 8 points).

The problem with a fixed font size is on high dpi displays they may be
unreadable.

> 
> Obviously, if the default size is already small, a smaller size is not 
> useful, and a reduced font
> size gives not readable texts.
> 

I propose that in the short term we use the reduced font only for gtk on
linux where it seems to work fairly well.  In the future, we could just
make the layer manager font a user option rather than try to guess what
scaling may work on a given platform.

___
Mailing list: https://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] Layers widget font scaling

[jp charras]

Le 02/05/2018 à 11:03, Jeff Young a écrit :
> If your screen reports  a height of 900 pixels or less we scale the 
> system-default fontsize for PCB_EDIT_FRAME (but not FOOTPRINT_EDIT_FRAME).
> 
> This results in poor readability on at least some MSW systems 
> (https://bugs.launchpad.net/kicad/+bug/1767965) and for those with ageing 
> eyesight (i.e. me).
> 
> On OSX, it also doesn’t help as the row height is controlled by the 
> checkboxes.  So the list doesn’t actually get any shorter with the smaller 
> fonts (although it does get marginally less wide).
> 
> Judging by the screenshot in the above bug report, MSW also doesn’t really 
> benefit from the scaled font: the Render list is still much shorter than the 
> vertical icon bar.
> 
> I’d like to remove the scaling on at least OSX and MSW.  Are there any 
> objections, and are there any reasons not to remove it on GTK as well?
> 
> Thanks,
> Jeff.

AFAIK, reducing font size was useful when a lot of layers is used (16 to 32 
copper layers) and/or
there are long copper layer names or when a big font is in use.

Without removing this feature, the best way is to reduce the size with a 
minimal acceptable final
size ( for instance >= 8 points).

Obviously, if the default size is already small, a smaller size is not useful, 
and a reduced font
size gives not readable texts.


-- 
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] A reminder on Git commit comments

[Wayne Stambaugh]

This is why we have a commit message policy.  Obviously this isn't a
perfect solution.  Feel free to adopt this policy for library developer
commits.  There is always the hard line approach where you kick the
merge request back to the submitted and ask them to fix the commit
message or use `git commit --amend` to fix the commit message yourself.

On 5/1/2018 6:03 PM, Reece R. Pollack wrote:
> I'd like to make an observation on some of the Git commit comments I'm
> reading. Some of these commit log entries are really unhelpful.
> 
> When I was at University many, many years ago, students were taught to
> place comments in their code. Many misunderstood the purpose of
> comments, though, and would write code like this:
> 
> x = x + 1;   /* Add 1 to x */
> 
> 
> While the comment is totally correct, it's also totally useless. I can
> /see/ that this line adds 1 to /x/; I don't need a comment to tell me
> that. As a programmer coming along later, what I need to know is /why/ 1
> is being added to /x/.
> 
> I'm seeing commit comments of the form "add one to x" in the KiCad
> repos. These comments are useless. For an example, look at this commit
> in the kicad-symbols repo:
> 
> commit 4ada78e26774c841ce8ec33e8b221d04fed1f4c7
> Author: Rene Pöschl 
> Date:   Fri Apr 20 11:14:47 2018 +0200
> 
>     Remove Connector_Specialized files.
> 
> Great. I can /see/ that these files are being removed. That's obvious
> from looking at the content of the commit. But there is no explanation
> of why these files were deleted. Don't tell me that there was discussion
> about this in email; even if that happened it's irrelevant. No one
> should have to go chasing through an email archive hoping to understand
> why a change was made. That's what the commit log entry is for.
> 
> I went back further in the Git logs for commits touching these files
> hoping to find a more illuminating commit comment, but found nothing
> helpful. In fact, I came across an earlier series of commits that are
> even /less/ helpful:
> 
> commit 467170586b106d00c4df185dc1683046e259b74c
> Author: evanshultz 
> Date:   Thu Apr 19 09:42:52 2018 -0700
> 
>     Just checking... still no dice
> 
> commit 966a1a40aa36732d9c2404b044a4ef63bd0bb417
> Author: evanshultz 
> Date:   Thu Apr 19 09:36:28 2018 -0700
> 
>     Delete Connector_Specialized.lib
> 
> commit aeb4270213da8a063f24163d6fa31e8521f08a83
> Author: evanshultz 
> Date:   Thu Apr 19 09:36:03 2018 -0700
> 
>     Delete Connector_Specialized.dcm
> 
> The top (latest) commit actually reverts the actions of the previous two
> commits. So now I have the idea that there's some sort of disagreement
> whether these files should be part of the repo or not. But I still have
> no idea why.
> 
> In a previous job I was the poor sod (or arrogant bastard, take your
> pick) who had to review commits before they were merged into the master
> branch. I would have rejected commits like these immediately. With Open
> Source development there's often less control over what gets merged and
> what doesn't. But that just means it's all the more important for
> everyone to make an effort to write good commit comments.
> 
> From the KiCad source file
> Documentation/development/commit-message-format.md:
> 
> Commit messages should begin with a subject line; try to limit this
> to no more
> than 50-72 characters. The body of the message should be separated
> from the
> subject by a blank line and wrapped at 72 characters. The body of a
> commit
> message should explain what the commit does and why, but do not
> explain *how*
> as the code itself should do that.
> 
> 
> 
> 
> ___
> Mailing list: https://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] Requesting feedback regarding "Update Footprints" menu item

[Wayne Stambaugh]

Jeff,

I'm not sure what feedback you are looking for.  If I'm reading the
forum post correctly, it appears the user was confused about the
difference between "update footprint from library" and "change
footprint".  This seems clear to me but then again, I'm not new to board
layout software so maybe this is just a rookie mistake.

Cheers,

Wayne

On 5/1/2018 5:14 PM, Jeff Young wrote:
> See https://forum.kicad.info/t/issue-updating-footprint-in-v5/10536/5.
> 
> 
> ___
> Mailing list: https://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] A reminder on Git commit comments

[Rene Pöschl]

Thanks for the reminder,
we will try to better our ways.

See: https://github.com/KiCad/kicad-symbols/issues/569

On 02/05/18 00:03, Reece R. Pollack wrote:
I'd like to make an observation on some of the Git commit comments I'm 
reading. Some of these commit log entries are really unhelpful.


When I was at University many, many years ago, students were taught to 
place comments in their code. Many misunderstood the purpose of 
comments, though, and would write code like this:


x = x + 1;   /* Add 1 to x */


While the comment is totally correct, it's also totally useless. I can 
/see/ that this line adds 1 to /x/; I don't need a comment to tell me 
that. As a programmer coming along later, what I need to know is /why/ 
1 is being added to /x/.


I'm seeing commit comments of the form "add one to x" in the KiCad 
repos. These comments are useless. For an example, look at this commit 
in the kicad-symbols repo:


commit 4ada78e26774c841ce8ec33e8b221d04fed1f4c7
Author: Rene Pöschl 
Date:   Fri Apr 20 11:14:47 2018 +0200

    Remove Connector_Specialized files.

Great. I can /see/ that these files are being removed. That's obvious 
from looking at the content of the commit. But there is no explanation 
of why these files were deleted. Don't tell me that there was 
discussion about this in email; even if that happened it's irrelevant. 
No one should have to go chasing through an email archive hoping to 
understand why a change was made. That's what the commit log entry is for.


I went back further in the Git logs for commits touching these files 
hoping to find a more illuminating commit comment, but found nothing 
helpful. In fact, I came across an earlier series of commits that are 
even /less/ helpful:


commit 467170586b106d00c4df185dc1683046e259b74c
Author: evanshultz 
Date:   Thu Apr 19 09:42:52 2018 -0700

    Just checking... still no dice

commit 966a1a40aa36732d9c2404b044a4ef63bd0bb417
Author: evanshultz 
Date:   Thu Apr 19 09:36:28 2018 -0700

    Delete Connector_Specialized.lib

commit aeb4270213da8a063f24163d6fa31e8521f08a83
Author: evanshultz 
Date:   Thu Apr 19 09:36:03 2018 -0700

    Delete Connector_Specialized.dcm

The top (latest) commit actually reverts the actions of the previous 
two commits. So now I have the idea that there's some sort of 
disagreement whether these files should be part of the repo or not. 
But I still have no idea why.


In a previous job I was the poor sod (or arrogant bastard, take your 
pick) who had to review commits before they were merged into the 
master branch. I would have rejected commits like these immediately. 
With Open Source development there's often less control over what gets 
merged and what doesn't. But that just means it's all the more 
important for everyone to make an effort to write good commit comments.


From the KiCad source file 
Documentation/development/commit-message-format.md:


Commit messages should begin with a subject line; try to limit
this to no more
than 50-72 characters. The body of the message should be separated
from the
subject by a blank line and wrapped at 72 characters. The body of
a commit
message should explain what the commit does and why, but do not
explain *how*
as the code itself should do that.




___
Mailing list: https://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] Layers widget font scaling

[Jeff Young]

If your screen reports  a height of 900 pixels or less we scale the 
system-default fontsize for PCB_EDIT_FRAME (but not FOOTPRINT_EDIT_FRAME).

This results in poor readability on at least some MSW systems 
(https://bugs.launchpad.net/kicad/+bug/1767965) and for those with ageing 
eyesight (i.e. me).

On OSX, it also doesn’t help as the row height is controlled by the checkboxes. 
 So the list doesn’t actually get any shorter with the smaller fonts (although 
it does get marginally less wide).

Judging by the screenshot in the above bug report, MSW also doesn’t really 
benefit from the scaled font: the Render list is still much shorter than the 
vertical icon bar.

I’d like to remove the scaling on at least OSX and MSW.  Are there any 
objections, and are there any reasons not to remove it on GTK as well?

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