Re: [Kicad-developers] Zoom vs Help

[Garth Corral]

On top of that, the hotkeys list is mostly wrong on OS X in that it shows Ctrl- 
as the modifier key when in fact it is Cmd- on OS X.


Garth


> On Jun 30, 2015, at 10:43 PM, Nick Østergaard  wrote:
> 
> On a side note: Please note that the right click context menu shows
> the correct (without alt+) keybinding to the zoom actions. There must
> be some inconsistency on how those labels are made.
> 
> 2015-07-01 2:37 GMT+02:00 Simon Richter :
>> Hi,
>> 
>> I've just tried to get context sensitive help using the F1 key, and
>> found that instead it zoomed in.
>> 
>> The menu claims that the hotkey for zooming in is Alt-F1, while the
>> hotkey list accessible with the '?' key lists F1 without qualifiers.
>> 
>> On Mac, Ctrl-'+' is used instead, which is fairly common in PC software
>> as well these days (IE and Firefox, for example).
>> 
>> Would it make sense to offer Ctrl-'+' and Ctrl-'-' on all platforms?
>> 
>> Would it make sense to reserve F1 for context help?
>> 
>>   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
>> 
> 
> ___
> 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



smime.p7s
Description: S/MIME cryptographic 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] Zoom vs Help

[Nick Østergaard]

On a side note: Please note that the right click context menu shows
the correct (without alt+) keybinding to the zoom actions. There must
be some inconsistency on how those labels are made.

2015-07-01 2:37 GMT+02:00 Simon Richter :
> Hi,
>
> I've just tried to get context sensitive help using the F1 key, and
> found that instead it zoomed in.
>
> The menu claims that the hotkey for zooming in is Alt-F1, while the
> hotkey list accessible with the '?' key lists F1 without qualifiers.
>
> On Mac, Ctrl-'+' is used instead, which is fairly common in PC software
> as well these days (IE and Firefox, for example).
>
> Would it make sense to offer Ctrl-'+' and Ctrl-'-' on all platforms?
>
> Would it make sense to reserve F1 for context help?
>
>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
>

___
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] PNS router - visualized cursor positions bug [BZR5846]

[Maciej Sumiński]

Thank you for noticing, should be fixed in 5850.

Regards,
Orson

On 06/30/2015 08:36 PM, Nick Østergaard wrote:
> I can confirm this issue on 5848 linux.
> 
> 2015-06-30 19:41 GMT+02:00 LordBlick :
>> After last patches I assume that there is problem with displayed cursor
>> positions - extra pixels are offset with both axes growth - efect is largest
>> visible close to down-right corner.
>> Attached superimposed different positions of the cursor to illustrate the
>> problem.
>>
>> --
>> Best Regards,
>> LordBlick
>>
>> ___
>> 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] Zoom vs Help

[Simon Richter]

Hi,

I've just tried to get context sensitive help using the F1 key, and
found that instead it zoomed in.

The menu claims that the hotkey for zooming in is Alt-F1, while the
hotkey list accessible with the '?' key lists F1 without qualifiers.

On Mac, Ctrl-'+' is used instead, which is fairly common in PC software
as well these days (IE and Firefox, for example).

Would it make sense to offer Ctrl-'+' and Ctrl-'-' on all platforms?

Would it make sense to reserve F1 for context help?

   Simon



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 user interface translations

[Marco Ciampa]

On Tue, Jun 30, 2015 at 09:42:03PM +0200, Nick Østergaard wrote:
> 2015-06-30 21:38 GMT+02:00 Nick Østergaard 
> > It is a conversion of the kicad bzr doc repo, converted to git, where
> > the internat folder is sperated into its own repo, such that is is not
> > with the docs, and the size is about 38M reposize (13M tree size)
> > compared to 1.6G. This preserves commit history, while seperating. I
> > also intend to have the compiled mo files in the repo, and just update
> > the cmake stuff to be able to build the mo files.
> 
> Clarificaiton: I don't want the mo files commited to the repo, I want
> cmake to be able to generate the mo files from the po files.

1000% agree.

-- 


Marco Ciampa

I know a joke about UDP, but you might not get it.

++
| GNU/Linux User  #78271 |
| FSFE fellow   #364 |
++


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

Re: [Kicad-developers] PNS diferential pair netnames update

[Simon Richter]

Hi,

On 30.06.2015 20:58, Andy Peters wrote:

> Some micro vendors offer peripheral configuration tools which set up the chip 
> per user needs. If that configuration could be imported, then the user 
> doesn’t really need to do any work at all.

For FPGAs, I wanted to go the route of exporting the mapping from KiCad
back into the FPGA toolchain, because it is probably easier to handle
swapping pins during routing that way. But eventually, both directions
should be supported.

> FPGAs don’t have standard peripherals but the ability to edit pins for 
> directional/type and give them a meaningful name would be welcome.

The pin name should still be "IOnnn" or "DIFFIOnnn+" or something such,
otherwise the mapping cannot be seen in the schematic anymore.

> I recognize that there’s the small matter of programming necessary to make 
> this all happen.

Indeed. But there are reasons why the pin table has such an open-ended
design, and allows collapsing on pin number.

   Simon




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 user interface translations

[Nick Østergaard]

2015-06-30 21:38 GMT+02:00 Nick Østergaard 
> It is a conversion of the kicad bzr doc repo, converted to git, where
> the internat folder is sperated into its own repo, such that is is not
> with the docs, and the size is about 38M reposize (13M tree size)
> compared to 1.6G. This preserves commit history, while seperating. I
> also intend to have the compiled mo files in the repo, and just update
> the cmake stuff to be able to build the mo files.

Clarificaiton: I don't want the mo files commited to the repo, I want
cmake to be able to generate the mo files from the po files.

___
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 user interface translations

[Nick Østergaard]

Since the release is imminent I would like to point out that we still
have some issue with the GUI translations. This is pointed out
somewhere in [1]. They are kept in the very big repo [2], which also
contains the old documentation and stuff. The documentation itself has
moved to ciampix' kicad-doc repo. (Can this be soon be moved under the
KiCad organisation on github.)

I would like to seperate out the po files [2] sort of like I have done in [3].

It is a conversion of the kicad bzr doc repo, converted to git, where
the internat folder is sperated into its own repo, such that is is not
with the docs, and the size is about 38M reposize (13M tree size)
compared to 1.6G. This preserves commit history, while seperating. I
also intend to have the compiled mo files in the repo, and just update
the cmake stuff to be able to build the mo files.

I would like to have some feedback and maybe a go ahead form the main
developers and the translators, about weather or not this is the way
to go or not. So what do you think?

One advantage of keeping the po files in another repository than the
source is that accesscontrol is easier to manage. Often translators
are not much involved in the coding part of it, and there might be
less strict commit access granted here than on the normal source repo.
This to keep this effort seperated from the developers, such that
those who don't want to use their time on managing translation patches
out of it.

Regards
Nick Østergaard

[1] 
https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg12824.html
[2] https://code.launchpad.net/~kicad-developers/kicad/doc
[3] https://github.com/nickoe/kicad-internat-only

___
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] PNS diferential pair netnames update

[Andy Peters]

> On Jun 30, 2015, at 11:14 AM, Simon Richter  wrote:
> 
> Hi,
> 
> On 30.06.2015 19:29, Andy Peters wrote:
> 
>>> Ideally, I'd like this as attributes on the component pins, and then
>>> either inherited directly or at least verified by the ERC.
> 
>> One argument against making this a pin attribute rather than a net 
>> attribute: FPGA pins can be single-ended or differential depending on the 
>> particular design. 
> 
> I have an evil plan for that: per-instance configuration options.

I envision you in your lair, rubbing your hands together and cackling with glee!

> In the symbol, I'd like to allow alternative configurations for each
> pin, along with dependencies.
> 
> This is most useful for connectors, which currently do not take part in
> ERC at all (by being declared "passive"); the per-instance configuration
> would allow pin types to be assigned without altering the component.

What I have done for connectors where I have a "standard usage” (JTAG 
connectors for Xilinx or Silicon Labs dongles) is to draw the symbols and give 
each pin the application-specific net name and pin type. The footprint matches 
the actual part, of course, and I have a “company part number” in the symbol 
which points to the right thing as well. The BOM, then, after processing, just 
calls out the proper vendor part number.

> For anything programmable, I/O lines can be narrowed down to "input" or
> "output"; I'd also like to give the user the option of using one of
> several names for the pin. E.g. if there is a dedicated SPI controller
> in the IC, there'd be a configuration "use the SPI controller", which
> sets up the pins as MISO (in), MOSI (out), SCLK (out) and CS (out), and
> a different configuration "use these pins as I/O", which would set them
> as "GPIO1" (bidi), "GPIO2" (bidi) etc., with the option of narrowing
> them down further. A differential pair would be another configuration.

Kicad would win a whole bunch of new converts if you (we, us, whomever) could 
do this. Basically, your suggestion is to add a “pin configurator” tool, which 
knows about some parts.

Say the part in question is an Atmel SAM3U4CA. Most I/O pins can be configured 
as just a standard I/O pin as well as being specific to one or two peripherals. 
This pin configurator tool would need to start at a higher level, then. You 
pick the peripherals you want to use, and then it “knows” how the pins in 
question should be configured, and sets the schematic symbol pin names (very 
helpful!) and port type appropriately. Pins not part of a peripheral but 
instead are GPIO can then be configured based on whether they’re in, out, or 
bidirectional, and the user should also be able to give them a name.

Some micro vendors offer peripheral configuration tools which set up the chip 
per user needs. If that configuration could be imported, then the user doesn’t 
really need to do any work at all.

FPGAs don’t have standard peripherals but the ability to edit pins for 
directional/type and give them a meaningful name would be welcome.

I recognize that there’s the small matter of programming necessary to make this 
all happen.

-a
___
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] PNS router - visualized cursor positions bug [BZR5846]

[Nick Østergaard]

I can confirm this issue on 5848 linux.

2015-06-30 19:41 GMT+02:00 LordBlick :
> After last patches I assume that there is problem with displayed cursor
> positions - extra pixels are offset with both axes growth - efect is largest
> visible close to down-right corner.
> Attached superimposed different positions of the cursor to illustrate the
> problem.
>
> --
> Best Regards,
> LordBlick
>
> ___
> 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] Layer alignment target

[Andy Peters]

> On Jun 29, 2015, at 11:53 PM, Nick Østergaard  wrote:
> 
> 2015-06-30 0:53 GMT+02:00 Andy Peters :
>> Someone on the Kicad.info forum asked about this. The only documentation 
>> about it is in the pcbnew.pdf where we are told that you use it to “Draw 
>> Alignment Marks (appearing on all layers).”

> What was the question?

“What is it supposed to do?”

-a
___
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] PNS diferential pair netnames update

[Simon Richter]

Hi,

On 30.06.2015 19:29, Andy Peters wrote:

>> Ideally, I'd like this as attributes on the component pins, and then
>> either inherited directly or at least verified by the ERC.

> One argument against making this a pin attribute rather than a net attribute: 
> FPGA pins can be single-ended or differential depending on the particular 
> design. 

I have an evil plan for that: per-instance configuration options.

In the symbol, I'd like to allow alternative configurations for each
pin, along with dependencies.

This is most useful for connectors, which currently do not take part in
ERC at all (by being declared "passive"); the per-instance configuration
would allow pin types to be assigned without altering the component.

For anything programmable, I/O lines can be narrowed down to "input" or
"output"; I'd also like to give the user the option of using one of
several names for the pin. E.g. if there is a dedicated SPI controller
in the IC, there'd be a configuration "use the SPI controller", which
sets up the pins as MISO (in), MOSI (out), SCLK (out) and CS (out), and
a different configuration "use these pins as I/O", which would set them
as "GPIO1" (bidi), "GPIO2" (bidi) etc., with the option of narrowing
them down further. A differential pair would be another configuration.

   Simon



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] PNS router - visualized cursor positions bug [BZR5846]

[LordBlick]

After last patches I assume that there is problem with displayed cursor 
positions - extra pixels are offset with both axes growth - efect is largest 
visible close to down-right corner.

Attached superimposed different positions of the cursor to illustrate the 
problem.

--
Best Regards,
LordBlick
___
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] PNS diferential pair netnames update

[Andy Peters]

> On Jun 29, 2015, at 4:56 PM, Simon Richter  wrote:
> 
> Hi,
> 
> On 30.06.2015 01:20, Chris Pavlina wrote:
> 
>> I'd happily implement the net tagging, though it'd require a bit of 
>> brainstorming from everyone on how those tags should be stored and 
>> shared with pcbnew.
> 
> I think it belongs in the netlist.
> 
> Ideally, I'd like this as attributes on the component pins, and then
> either inherited directly or at least verified by the ERC.

One argument against making this a pin attribute rather than a net attribute: 
FPGA pins can be single-ended or differential depending on the particular 
design. 

If your design flow says, “make a custom FPGA symbol for each design,” making a 
pin attribute indicating differential pairs is a great idea (as is making the 
pins input or output or bidirectional or tristate, instead of just making them 
all bidirectional in a “standard” symbol). (And this is great if you want to 
import pin assignments into the symbol from a constraint file.) (But I digress.)

But most people don’t go through that effort, so the attribute should be on the 
net.

> On one hand I like the idea of attaching pseudo components to the nets
> to add attributes, but some users might think of them as visual clutter.

We are an Altium shop at the day job, and we use differential nets all the 
time. I do think that the little red differential pair attribute indicator is 
clutter. It doesn’t indicate _which_ nets are the pairs; that’s handled by the 
net names with the _p _n suffix, so I think that the attribute indicator is 
redundant.

Now that I look at Tom’s example, where the attribute indicates everything you 
care about the net (including its partner), that’s not so bad! Assuming it can 
be hidden. And it makes the need to have a specific suffix or other magic 
netname go away. This user votes for Tom’s suggestion!

-
___
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] Mac nightlies update

[Adam Wolf]

Hi folks,

I'm pushing a minor change to the Mac build scripts this afternoon, which
will kick into effect for tonight's nightlies.

This is basically a bugfix.  There's a space in our Default Install Path,
and basically there was an interplay between bash and cmake and I couldn't
get them to play nicely.  I moved to using bash arrays to store the cmake
settings in--and it actually ended up triggering that fchmodat issue in
boost I posted about months ago, while still not solving the problem.

After a few solid hours of debugging this over a few months, I decided to
do as I threatened and rewrote the 30 line shell script in Python so I
could handle the tokenization myself, and everything appears to be working
now.  I only rewrote one tiny piece, but I think the whole thing will be
rewritten after the stable release because of the way packaging will be
changing.

Not only does this fix a few bugs on the tracker, I can now continue builds
for 10.7->10.10 on my development system as well as my build cluster.  This
has been holding *everything* up on my end, as I couldn't test quick
bugfixes on my system without it becoming very involved.

Adam Wolf
Cofounder and Engineer
W&L
___
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] two bugs: trace clearance display and hierarchical sheet pin name redraw fail

[LordBlick]

In response to a message written on 30.06.2015, 11:51, from Tomasz Wlostowski:

On 30.06.2015 11:34, LordBlick wrote:

- break(split) segment - needed when I want drag segment with slope („D”
shortcut), but only to some middle point. Manual joining two selected,
continuous segments bestead in the same line I see also useful.

Unfortunately I don't understand this point. Can you attach some drawing
explaining it?

I have problem with screnshoot of any opened menu(non-application shortcut is
blocked - my system haven't native screnshooter, but it's only separate, 
optional program, assigned to „Print Screen" key).

Just in legacy right-click on track, on that menu options you have „Break track”
with bitmaps_png/sources/break_line.svg image.
Join conception in s1.png (tracks in outline view).



- drag segment without slope (sometimes there is need to use other than
90/45° angle)

Possible to implement quickly, but with no shove/walkaround. Are you fine
with that?

- drag footprint with segment's ends

Again, it means no shove/walkaround, at least in the foreseeable future.
Besides, I don't see a clear use case for this feature (it may only work
reasonably well for 2-3 pad components)

2 x OK - sometimes manual intervention is required.



- drag segment end („M”)

In P&S, place the mouse over the end of a segment (or a node in a track) and
 press D.

That's not the same behavior, as you may observe in legacy… Other else is key
„G” assignment, sometimes useful too.



- accuracy path crossing (with 90° and lowest number of segments)

Sorry, I don't understand what you mean. Another drawing/sample board with
some description might be helpful here...

I mean snap new segment to gird axes, as possible of course, with directly join
to spilit segment, without any middle, angled segments)
See legacy.png and pns.png - PNS gives additional, not necessary segment, and
additionally routing does not keep gird - sometimes useful, but usually not. I
propose also holding Shift to skip gird snap.



- handle segment, when mouse pointer is also on pad area, which is segment
 area too.

Holding Shift while routing disables snapping to pads. There's also another
patch (Orson is going to merge it) that lets you clarify the selection prior
 to dragging a segment with P&S on.

OK, thanks for that hint, it's nice message, I haven't that knowledge before.


--
Best Regards,
LordBlick
___
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] Reduced line width of polygon in bitmap to footprint import.

[Marco Hess]

Good question. Did not try that. Is a width of 0 allowed?

On 30-Jun-15 18:14, Nick Østergaard wrote:


Why does the polygon even have a width? Can't it just be zero?

Den 30/06/2015 03.04 skrev "Marco Hess" >:


Minor patch to reduce the polygon line width used the
bitmap2component import. The existing 0.1 mm linewidth reduces the
accuracy of the imported bitmap outline. As it is a filled polygon
anyway, the line width can be quite small and gives
beter looking results this way.

diff --git a/bitmap2component/bitmap2component.cpp
b/bitmap2component/bitmap2component.cpp
index db11585..6717e0b 100644
--- a/bitmap2component/bitmap2component.cpp
+++ b/bitmap2component/bitmap2component.cpp
@@ -356,7 +356,7 @@ void BITMAPCONV_INFO::OuputOnePolygon(
KPolygon & aPolygon, const char * aBrdLay

 case PCBNEW_KICAD_MOD:
 {
-double width = 0.1;
+double width = 0.0001;
 fprintf( m_Outfile, "  (fp_poly (pts" );

 jj = 0;


___
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



--
Marco Hess
Through IP Pty. Ltd. - AUSTRALIA
www.through-ip.com  | marco.h...@through-ip.com
p: +61 407 78 55 66 | f: +61 8 8121 6191

___
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] two bugs: trace clearance display and hierarchical sheet pin name redraw fail

[Tomasz Wlostowski]

On 30.06.2015 11:34, LordBlick wrote:
> - break(split) segment - needed when I want drag segment with slope („D”
> shortcut), but only to some middle point. Manual joining two selected,
> continuous segments bestead in the same line I see also useful.
Hi,

Unfortunately I don't understand this point. Can you attach some drawing
explaining it?

> - drag segment without slope (sometimes there is need to use other than
> 90/45° angle)
Possible to implement quickly, but with no shove/walkaround. Are you
fine with that?

> - drag footprint with segment's ends
Again, it means no shove/walkaround, at least in the foreseeable future.
Besides, I don't see a clear use case for this feature (it may only work
reasonably well for 2-3 pad components)

> - drag segment end („M”)
In P&S, place the mouse over the end of a segment (or a node in a track)
and press D.

> - accuracy path crossing (with 90° and lowest number of segments)
Sorry, I don't understand what you mean. Another drawing/sample board
with some description might be helpful here...

> - handle segment, when mouse pointer is also on pad area, which is
> segment area too.
Holding Shift while routing disables snapping to pads. There's also
another patch (Orson is going to merge it) that lets you clarify the
selection prior to dragging a segment with P&S on.

Tom

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

Re: [Kicad-developers] two bugs: trace clearance display and hierarchical sheet pin name redraw fail

[LordBlick]

In response to a message written on 30.06.2015, 01:04, from Tomasz Wlostowski:

The behavior of the legacy router is buggy

Maybe is, but PNS does not offer many features, that legacy has:
- break(split) segment - needed when I want drag segment with slope („D” 
shortcut), but only to some middle point. Manual joining two selected, 
continuous segments bestead in the same line I see also useful.
- drag segment without slope (sometimes there is need to use other than 90/45° 
angle)

- drag footprint with segment's ends
- drag segment end („M”)
- accuracy path crossing (with 90° and lowest number of segments)
- handle segment, when mouse pointer is also on pad area, which is segment area 
too.
So I, as user, still must switch legacy/PNS… ;)
--
Best Regards,
LordBlick

___
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] Reduced line width of polygon in bitmap to footprint import.

[Nick Østergaard]

Why does the polygon even have a width? Can't it just be zero?
Den 30/06/2015 03.04 skrev "Marco Hess" :

> Minor patch to reduce the polygon line width used the bitmap2component
> import. The existing 0.1 mm linewidth reduces the
> accuracy of the imported bitmap outline. As it is a filled polygon anyway,
> the line width can be quite small and gives
> beter looking results this way.
>
> diff --git a/bitmap2component/bitmap2component.cpp
> b/bitmap2component/bitmap2component.cpp
> index db11585..6717e0b 100644
> --- a/bitmap2component/bitmap2component.cpp
> +++ b/bitmap2component/bitmap2component.cpp
> @@ -356,7 +356,7 @@ void BITMAPCONV_INFO::OuputOnePolygon( KPolygon &
> aPolygon, const char * aBrdLay
>
>  case PCBNEW_KICAD_MOD:
>  {
> -double width = 0.1;
> +double width = 0.0001;
>  fprintf( m_Outfile, "  (fp_poly (pts" );
>
>  jj = 0;
>
>
> ___
> 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] two bugs: trace clearance display and hierarchical sheet pin name redraw fail

[Tomasz Wlostowski]

On 30.06.2015 08:37, jp charras wrote:
> Le 30/06/2015 01:04, Tomasz Wlostowski a écrit :
>> On 30.06.2015 00:10, Andy Peters wrote:
>>> So it’s not a bug, per se, it’s a user’s expectations issue. Chris
>>> added my expectations (and I’m sure others have the same expectation)
>>> to the wishlist, but I don’t think it merits much attention unless
>>> the devs run out of things to do.
>>
>> Hi Andy,
>>
>> It's not only a matter of user expectations. The behavior of the legacy
>> router is buggy, as the DRC takes into account only the clearance of the
>> currently drawn ("head") trace. Obstacles with higher clearances are not
>> detected at all. 
> 
> This is absolutely *false*.
> the DRC perfectly takes in account the *clearance of each obstacle*.
> 
> You can also easily show *each clearance* in Preferences.
> Each item can be displayed with its own clearance.

I got misled by the fact that Kicad lets you override pad clearances
(and so managed to route a low clearance track close to what I thought
was a large clearance pad). Sorry for false claim ;)

> 
> But for high density board, usually only the clearance to the current
> track segment being edited is shown.
> 
> Also not perfect, it is a very good help, and yes, this feature should
> be considered in GAL mode.
Sure, I agree.

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