Re: [Kicad-developers] GAL canvas behavior.

[Oliver Walters]

I think the object should remain selected after the context menu is closed.
But, right clicking on a *different* object should deselect the first one,
select the new one, and then open the context menu on the newly selected
item.

There are many times that erroneously deselecting the first item would
result in more work for the user, as they wanted to cancel the menu but not
the selection.

On 21 Jul 2017 03:22, "Wayne Stambaugh"  wrote:

> I've finally forced myself to start using the GAL canvas for new
> projects and I immediately ran into an unexpected behavior regarding
> context menus.  If I right click on an object, it gets selected and the
> context menu for that object is shown as expected.  If I change my mind
> and close the context menu with the escape key, the context menu
> disappears.  So far so good but here is where things get ugly.  The
> object from the canceled context menu is still selected so if I move the
> cursor to a different object and right click, the context menu from the
> previously (still) selected object appears and selecting a command from
> the context menu will be performed on the object at the first right
> click position rather than the object the cursor is currently over.
> This seems broken to me.  I have to hit the escape key a second time to
> deselect the initial object selection.  Is this the behavior we really
> want?  I would expect that the initial object would have been deselected
> when I aborted the context menu (or performed a command on the selected
> object) so the next right click would select the new object.  With the
> current behavior, I have to hit the escape key a second time to deselect
> the original selection.  Anyone who has been following the dev mailing
> list for any amount of time knows how much I dislike additional steps to
> accomplish a task.  This falls under that category in a big way.  Can
> this be changed to mimic the behavior of the legacy canvas?  If so, I
> will file a bug report.  If not, we need to discuss this before I am
> willing to kick the legacy canvas to the curb.
>
> Cheers,
>
> Wayne
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] GAL canvas behavior.

[Greg Smith]

(Sorry for the duplicate, Wayne. This time I replied all.)
I much prefer that the selected objects remain selected. If the selection took 
precision, especially for multi-object additive multiple selection, then having 
to reselect even a subset is arduous. The addition of the extra "Esc" key 
requirement is reduced because it is pressing the *same* key, where your hand 
already is on the keyboard.
 

On Thursday, July 20, 2017 12:22 PM, Wayne Stambaugh  
wrote:
 

 I've finally forced myself to start using the GAL canvas for new
projects and I immediately ran into an unexpected behavior regarding
context menus.  If I right click on an object, it gets selected and the
context menu for that object is shown as expected.  If I change my mind
and close the context menu with the escape key, the context menu
disappears.  So far so good but here is where things get ugly.  The
object from the canceled context menu is still selected so if I move the
cursor to a different object and right click, the context menu from the
previously (still) selected object appears and selecting a command from
the context menu will be performed on the object at the first right
click position rather than the object the cursor is currently over.
This seems broken to me.  I have to hit the escape key a second time to
deselect the initial object selection.  Is this the behavior we really
want?  I would expect that the initial object would have been deselected
when I aborted the context menu (or performed a command on the selected
object) so the next right click would select the new object.  With the
current behavior, I have to hit the escape key a second time to deselect
the original selection.  Anyone who has been following the dev mailing
list for any amount of time knows how much I dislike additional steps to
accomplish a task.  This falls under that category in a big way.  Can
this be changed to mimic the behavior of the legacy canvas?  If so, I
will file a bug report.  If not, we need to discuss this before I am
willing to kick the legacy canvas to the curb.

Cheers,

Wayne

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


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

[Kicad-developers] GAL canvas behavior.

[Wayne Stambaugh]

I've finally forced myself to start using the GAL canvas for new
projects and I immediately ran into an unexpected behavior regarding
context menus.  If I right click on an object, it gets selected and the
context menu for that object is shown as expected.  If I change my mind
and close the context menu with the escape key, the context menu
disappears.  So far so good but here is where things get ugly.  The
object from the canceled context menu is still selected so if I move the
cursor to a different object and right click, the context menu from the
previously (still) selected object appears and selecting a command from
the context menu will be performed on the object at the first right
click position rather than the object the cursor is currently over.
This seems broken to me.  I have to hit the escape key a second time to
deselect the initial object selection.  Is this the behavior we really
want?  I would expect that the initial object would have been deselected
when I aborted the context menu (or performed a command on the selected
object) so the next right click would select the new object.  With the
current behavior, I have to hit the escape key a second time to deselect
the original selection.  Anyone who has been following the dev mailing
list for any amount of time knows how much I dislike additional steps to
accomplish a task.  This falls under that category in a big way.  Can
this be changed to mimic the behavior of the legacy canvas?  If so, I
will file a bug report.  If not, we need to discuss this before I am
willing to kick the legacy canvas to the curb.

Cheers,

Wayne

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

Re: [Kicad-developers] Cursor behavior

[Jörg Hermann]

> Perhaps the algorithm should be slightly modified to use the pad if the mouse cursor is inside a
> pad, and the footprint origin if the mouse cursor is inside the footprint (obviously), but not
> inside a pad.
 

Excellent idea, in combination with Simon Küppers suggestion to highlight the move origin a perfect intuitive way!

___
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] Via tool in Pcbnew.

[Wayne Stambaugh]

Thank you Marcos!

On 7/20/2017 12:04 PM, Marcos Chaparro wrote:
> Hi Wayne,
> 
> On Thu, Jul 20, 2017 at 12:22 PM, Wayne Stambaugh  > wrote:
> 
> Please file bug reports against these issues. 
> 
> 
> routing videos filed as bug report:
> https://bugs.launchpad.net/kicad/+bug/1705520
> I tried to find a similar bug report without success, it could a be a
> duplicate
> 
> The DRC was reported here
> https://bugs.launchpad.net/kicad/+bug/1664173
> 
> Cheers
> 
> 
> 
> ___
> 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] Via tool in Pcbnew.

[Marcos Chaparro]

Hi Wayne,

On Thu, Jul 20, 2017 at 12:22 PM, Wayne Stambaugh 
wrote:

> Please file bug reports against these issues.


routing videos filed as bug report:
https://bugs.launchpad.net/kicad/+bug/1705520
I tried to find a similar bug report without success, it could a be a
duplicate

The DRC was reported here
https://bugs.launchpad.net/kicad/+bug/1664173

Cheers
___
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] simplied right click menu icons

[Fabrizio Tappero]

cheers and sorry for the back and forth.

Fabrizio


On Thu, Jul 20, 2017 at 5:33 PM, Wayne Stambaugh 
wrote:

> This look good to me.  I'm fine with the unified menu icons.  If no one
> has any objections, I will commit it.
>
> On 7/20/2017 8:45 AM, Fabrizio Tappero wrote:
> > Hi Wayne,
> > how are you?
> >
> > very cool. I have changed this patch so that everywhere:
> >
> > "Rotate 90 deg CW" -> "Rotate Clockwise"
> > "Rotate 90 deg CCW" -> "Rotate Counterclockwise"
> >
> > thanks a lot
> > Fabrizio
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Jul 19, 2017 at 3:35 PM, Wayne Stambaugh  > > wrote:
> >
> > On 7/19/2017 6:17 AM, Fabrizio Tappero wrote:
> > > Hi Wayne,
> > > Thanks for the many messages. I did not know that devs were so into
> > > translation...
> > >
> > > My overall effort is to uniformise the Kicad UI and make it
> consistent
> > > and as correct as possible.
> > >
> > > Currently in Kicad we are using "Rotate 90 deg CW" and "Rotate 90
> deg
> > > CCW" in many many menus (see below). This expression is also used
> in
> > > Inkscape, a pretty high standard software for vector image
> manipulation.
> > > I personally think that consistency is the most important aspect
> of my
> > > contributions and, despite loving internal conversations about
> > > translations, etc I think we need to pick what is considered the
> best
> > > expression and use it coherently in all kicad menus. I have the
> feeling
> > > that if I submit a similar patch in few months, this kind of
> discussion
> > > will come up again. In a way this is typical of open-source
> software, so
> > > maybe it is not a bad thing.
> >
> > I'm fine with consistent but consistently incorrect or confusing is
> no
> > better than inconsistent.
> >
> > >
> > > In my opinion I think it would be good not to reinvent
> expressions. I
> > > think "CW" and "CCW" is a perfectly understandable and usable
> expression.
> >
> > CW and CCW are not expressions.  They are abbreviations which may
> not be
> > understood outside of English.  I would prefer not to use
> abbreviations
> > except for units unless space is at a premium.  In this case, I don't
> > think there is a space issue.  Please use terms clockwise and
> > counterclockwise.  These are the correct English terms for rotation
> > direction.
> >
> > >
> > > The custom-defined rotation value is a new piece of info, thanks
> Wayne
> > > for that! does it apply to all rotations?
> >
> > This only applies when the user changes the default rotation angle
> from
> > 90 to something else.  The rotation angle is fixed to 90 in the
> > schematic, symbol library, and footprint library editors and is user
> > configurable in the board editor.
> >
> > >
> > > Please advise how to modify this patch to make it submittable.
> >
> > Use clockwise and counter clockwise instead of CW and CCW.  Either
> > remove the 90 deg rotation angle or use the user rotation angle in
> the
> > board editor menu string.  I don't have a preference.
> >
> > >
> > > Cheers
> > > Fabrizio
> > >
> > >
> > >
> > > Inline image 1
> > >
> > >
> > >
> > > On Wed, Jul 19, 2017 at 2:47 AM, Wayne Stambaugh <
> stambau...@gmail.com 
> > > >>
> wrote:
> > >
> > > On 7/18/2017 8:24 PM, Chris Pavlina wrote:
> > > >> (remember, this is localization, not literal translation)
> > > >
> > > > Thank you! en_US should be "counterclockwise" and
> "clockwise" (or
> > > > even CCW/CW would be easily understood), and different
> phrasings
> > > > should be used in different languages. Don't avoid
> "clockwise" in
> > > > English because the French don't use it. It's up to the
> translators
> > > > to decide how things should be phrased in their locale.
> > >
> > > Yes!  This is how it should be done.
> > >
> > > >
> > > > On Tue, Jul 18, 2017 at 07:19:35PM -0500, José Ignacio wrote:
> > > >> Clockwise and counter-clockwise are the most usual term in
> American
> > > >> Engish, other localizations should use the most usual term
> in their
> > > >> respective locales (remember, this is localization, not
> literal
> > > >> translation). For example in Argentinian Spanish it should
> be
> > > >> "Horario" and "Antihorario". Encoding information in the
> icons only
> > > >> is not a good idea, as users can disable them (or the
> system can
> > > >> disable them by default) also screen readers can't read
> icons
> > > >> (though i doubt many blind people would be using kicad to
> lay out
> > > >> circuits).
> > >

Re: [Kicad-developers] [PATCH] simplied right click menu icons

[Wayne Stambaugh]

This look good to me.  I'm fine with the unified menu icons.  If no one
has any objections, I will commit it.

On 7/20/2017 8:45 AM, Fabrizio Tappero wrote:
> Hi Wayne,
> how are you? 
> 
> very cool. I have changed this patch so that everywhere: 
> 
> "Rotate 90 deg CW" -> "Rotate Clockwise"
> "Rotate 90 deg CCW" -> "Rotate Counterclockwise"
> 
> thanks a lot
> Fabrizio
> 
> 
> 
> 
> 
> 
> 
> On Wed, Jul 19, 2017 at 3:35 PM, Wayne Stambaugh  > wrote:
> 
> On 7/19/2017 6:17 AM, Fabrizio Tappero wrote:
> > Hi Wayne,
> > Thanks for the many messages. I did not know that devs were so into
> > translation...
> >
> > My overall effort is to uniformise the Kicad UI and make it consistent
> > and as correct as possible.
> >
> > Currently in Kicad we are using "Rotate 90 deg CW" and "Rotate 90 deg
> > CCW" in many many menus (see below). This expression is also used in
> > Inkscape, a pretty high standard software for vector image manipulation.
> > I personally think that consistency is the most important aspect of my
> > contributions and, despite loving internal conversations about
> > translations, etc I think we need to pick what is considered the best
> > expression and use it coherently in all kicad menus. I have the feeling
> > that if I submit a similar patch in few months, this kind of discussion
> > will come up again. In a way this is typical of open-source software, so
> > maybe it is not a bad thing.
> 
> I'm fine with consistent but consistently incorrect or confusing is no
> better than inconsistent.
> 
> >
> > In my opinion I think it would be good not to reinvent expressions. I
> > think "CW" and "CCW" is a perfectly understandable and usable 
> expression.
> 
> CW and CCW are not expressions.  They are abbreviations which may not be
> understood outside of English.  I would prefer not to use abbreviations
> except for units unless space is at a premium.  In this case, I don't
> think there is a space issue.  Please use terms clockwise and
> counterclockwise.  These are the correct English terms for rotation
> direction.
> 
> >
> > The custom-defined rotation value is a new piece of info, thanks Wayne
> > for that! does it apply to all rotations?
> 
> This only applies when the user changes the default rotation angle from
> 90 to something else.  The rotation angle is fixed to 90 in the
> schematic, symbol library, and footprint library editors and is user
> configurable in the board editor.
> 
> >
> > Please advise how to modify this patch to make it submittable.
> 
> Use clockwise and counter clockwise instead of CW and CCW.  Either
> remove the 90 deg rotation angle or use the user rotation angle in the
> board editor menu string.  I don't have a preference.
> 
> >
> > Cheers
> > Fabrizio
> >
> >
> >
> > Inline image 1
> >
> >
> >
> > On Wed, Jul 19, 2017 at 2:47 AM, Wayne Stambaugh  
> > >> wrote:
> >
> > On 7/18/2017 8:24 PM, Chris Pavlina wrote:
> > >> (remember, this is localization, not literal translation)
> > >
> > > Thank you! en_US should be "counterclockwise" and "clockwise" (or
> > > even CCW/CW would be easily understood), and different phrasings
> > > should be used in different languages. Don't avoid "clockwise" in
> > > English because the French don't use it. It's up to the 
> translators
> > > to decide how things should be phrased in their locale.
> >
> > Yes!  This is how it should be done.
> >
> > >
> > > On Tue, Jul 18, 2017 at 07:19:35PM -0500, José Ignacio wrote:
> > >> Clockwise and counter-clockwise are the most usual term in 
> American
> > >> Engish, other localizations should use the most usual term in 
> their
> > >> respective locales (remember, this is localization, not literal
> > >> translation). For example in Argentinian Spanish it should be
> > >> "Horario" and "Antihorario". Encoding information in the icons 
> only
> > >> is not a good idea, as users can disable them (or the system can
> > >> disable them by default) also screen readers can't read icons
> > >> (though i doubt many blind people would be using kicad to lay out
> > >> circuits).
> > >>
> > >> On Tue, Jul 18, 2017 at 4:00 PM, Clemens Koller  
> > >>
> > >> wrote:
> > >>
> > >>> Hi!
> > >>>
> > >>> If we want to avoid clockwise (CW) and counterclockwise
> (CCW) I
> > >>> suggest to add a sign to 

Re: [Kicad-developers] Via tool in Pcbnew.

[Wayne Stambaugh]

Please file bug reports against these issues.  Missing features may not
be noticed during development so it's important if you find something
that is missing to report it.  I cannot guarantee that all of them will
get fixed but I'm willing to bet that many of these issues the gal devs
are not even aware exist.

On 7/20/2017 9:25 AM, Marcos Chaparro wrote:
> A few things I remember when using nighties.
> 
> * disable design rule checking button is ignored in GAL. I use it when I
> swap 2 pins in the schematic, I turn off drc, make the track change,
> then rebuild connectivity. Otherwise I end up deleting the whole track
> and starting over.
> * On legacy pressing E over a segment changes the segment width to the
> current track width. Same for vias. I acknowledge the new window that
> pops up can change the width, but maybe someone could complain (not me,
> just pointing that out). I don't see the use of changing the segment
> coordinates in that window yet.
> * Sometimes it pisses me off that I explicitly change the trace
> direction with / but when it reaches the pad the direction is changed. I
> back off from the pad, change the direction (/) again and when I get
> again into the pad the track direction is changed again. I guess the
> algorithm tries to avoid an extra segment -which makes sense- but
> sometimes I just need my track to be farther away from a noise source
> and I don't care about one less track angle.
> 
> See 2 quick videos showing the difference between routing behavior. The
> only thing I did between videos is to press F9
> 
> https://youtu.be/puhrZMf7bWg
> 
> https://youtu.be/vqwiCvMWAaI
> 
> 
> 
> Marcos
> 
> On Thu, Jul 20, 2017 at 9:16 AM, Lorenzo Marcantonio  > wrote:
> 
> On Thu, Jul 20, 2017 at 10:31:09PM +1200, hauptmech wrote:
> >
> > I'm with Heikki. I've been using the GAL canvas for a complex project. I
> > don't really have time to learn the nuances of the interactive router; I
> > found that highlight collisions kept it from doing stuff I did not want 
> in
> > tight layouts and I fall back to legacy for things like tweaking track 
> nodes
> > and when I get tired of dropped mouse clicks.
> 
> Strange, when it's set up correctly it can work like the old one.
> Another thing (but I think that was already fixed) is the 'don't
> check clearance' button, I needed it a while ago and didn't work
> under GAL.
> 
> 
> --
> Lorenzo Marcantonio
> 
> ___
> 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] Via tool in Pcbnew.

[Bernhard Stegmaier]

> On 20. Jul 2017, at 16:15, hauptmech  wrote:
> 
> The frequent mouse click drops I have not had time to understand enough to 
> file a bug report. Whether it is PNS event handling or the load put on the 
> system by PNS plus kicad or WX, I don't know.

I can confirm that, I also noticed these dropped/ignored mouse clicks when I 
did my last PCB.
Very annoying.

I was tempted to think that it might by only a macOS problem, since I didn’t 
see any reports yet.
I also didn’t find any real repro use-case to be able to debug deeper.


Regards,
Bernhard

> 
> On 20/07/17 23:41, Maciej Sumiński wrote:
>> Hi hauptmech,
>> 
>> On 07/20/2017 12:31 PM, hauptmech wrote:
>>> I'm with Heikki. I've been using the GAL canvas for a complex project. I
>>> don't really have time to learn the nuances of the interactive router; I
>>> found that highlight collisions kept it from doing stuff I did not want
>>> in tight layouts and I fall back to legacy for things like tweaking
>>> track nodes and when I get tired of dropped mouse clicks.
>> Is there any related bug report so we could investigate the problem?
>> 
>> We realize that *any* change will have its opponents, therefore PNS
>> offers the highlight collision mode which is meant to work as the legacy
>> router. What is the difference in your opinion?
>> 
>>> It's hard to articulate well, but I get the feeling that the interactive
>>> router is either based on a single companies layout culture, or, with
>>> the utmost respect for all the awesome hard work that's gone into it,
>>> the authors are copying features in other software rather than working
>>> with the needs and user stories of users that they are in contact with.
>> Do you agree it is very hard to satisfy everyone with a single solution?
>> KiCad offers multiple options to adjust it to your needs. We would love
>> to hear your story, but please keep in mind that we are simply unable to
>> fulfill all requests.
>> 
>> Regards,
>> Orson
> 
>> ___
>> 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] [PATCH] - Improved error messages

[Oliver Walters]

A lot of the error messages presented to the users are full of
developer-only data, that often serves to confuse rather than help end
users. However the developer data is great for bug reports and dev feedback.

I have updated the DisplayErrorMessage and DisplayInfoMessage functions to
have an extra information parameter, which is initially hidden in a "Show
details" drop-down box.

I have not fixed all the error messages. However I have updated a few to
start the ball rolling. In particular I have focused on messages that I
have seen and thought to be unhelpful.

I think that following this pattern can provide better UX when errors
occur, and improve the professional look of KiCad.

Patch set attached.

Regards,
Oliver
From 7c655a97c90c211cc805715d225ef687fa793d00 Mon Sep 17 00:00:00 2001
From: Oliver Walters 
Date: Thu, 20 Jul 2017 23:03:33 +1000
Subject: [PATCH 1/2] Added extra information to error and info messages

Optional extra information string which is displayed in a drop-down "details" box
---
 AUTHORS.txt   |  2 ++
 common/confirm.cpp| 51 ++-
 eeschema/annotate.cpp |  2 +-
 include/confirm.h | 17 +++--
 4 files changed, 52 insertions(+), 20 deletions(-)

diff --git a/AUTHORS.txt b/AUTHORS.txt
index 656723f..b32fd48 100644
--- a/AUTHORS.txt
+++ b/AUTHORS.txt
@@ -41,6 +41,8 @@ Mateusz Skowroński 
 Cheng Sheng 
 Google Inc.
 Kristoffer Ödmark 
+Oliver Walters 
+
 See also CHANGELOG.txt for contributors.
 
 
diff --git a/common/confirm.cpp b/common/confirm.cpp
index af25736..d8711b4 100644
--- a/common/confirm.cpp
+++ b/common/confirm.cpp
@@ -2,7 +2,7 @@
  * This program source code file is part of KiCad, a free EDA CAD application.
  *
  * Copyright (C) 2007 Jean-Pierre Charras, jp.charras at wanadoo.fr
- * Copyright (C) 1992-2013 KiCad Developers, see AUTHORS.txt for contributors.
+ * Copyright (C) 1992-2017 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
@@ -28,6 +28,7 @@
  */
 
 #include 
+#include 
 
 #include 
 #include 
@@ -70,31 +71,47 @@ void DisplayError( wxWindow* parent, const wxString& text, int displaytime )
 {
 wxMessageDialog* dialog;
 
-if( displaytime > 0 )
-dialog = new wxMessageDialog( parent, text, _( "Warning" ),
-  wxOK | wxCENTRE | wxICON_INFORMATION
-  | wxRESIZE_BORDER
-  );
-else
-dialog = new wxMessageDialog( parent, text, _( "Error" ),
-  wxOK | wxCENTRE | wxICON_ERROR
-  | wxRESIZE_BORDER
-  );
+int icon = displaytime > 0 ? wxICON_INFORMATION : wxICON_ERROR;
+
+dialog = new wxMessageDialog( parent, text, _( "Warning" ),
+  wxOK | wxCENTRE | wxRESIZE_BORDER | icon );
 
 dialog->ShowModal();
 dialog->Destroy();
 }
 
 
-void DisplayInfoMessage( wxWindow* parent, const wxString& text, int displaytime )
+void DisplayErrorMessage( wxWindow* aParent, const wxString& aText, const wxString aExtraInfo )
 {
-wxMessageDialog* dialog;
+wxRichMessageDialog* dlg;
 
-dialog = new wxMessageDialog( parent, text, _( "Info" ),
-  wxOK | wxCENTRE | wxICON_INFORMATION );
+dlg = new wxRichMessageDialog( aParent, aText, _( "Error" ),
+   wxOK | wxCENTRE | wxRESIZE_BORDER | wxICON_ERROR );
 
-dialog->ShowModal();
-dialog->Destroy();
+if( !aExtraInfo.IsEmpty() )
+{
+dlg->ShowDetailedText( aExtraInfo );
+}
+
+dlg->ShowModal();
+dlg->Destroy();
+}
+
+
+void DisplayInfoMessage( wxWindow* aParent, const wxString& aMessage, const wxString aExtraInfo )
+{
+wxRichMessageDialog* dlg;
+
+dlg = new wxRichMessageDialog( aParent, aMessage, _( "Info" ),
+   wxOK | wxCENTRE | wxRESIZE_BORDER | wxICON_INFORMATION );
+
+if( !aExtraInfo.IsEmpty() )
+{
+dlg->ShowDetailedText( aExtraInfo );
+}
+
+dlg->ShowModal();
+dlg->Destroy();
 }
 
 
diff --git a/eeschema/annotate.cpp b/eeschema/annotate.cpp
index 5f626b5..e1a50e1 100644
--- a/eeschema/annotate.cpp
+++ b/eeschema/annotate.cpp
@@ -85,7 +85,7 @@ void SCH_EDIT_FRAME::AnnotateComponents( bool  aAnnotateSchematic,
 {
 wxString msg;
 msg.Printf( _( "%d duplicate time stamps were found and replaced." ), count );
-DisplayInfoMessage( NULL, msg, 2 );
+DisplayInfoMessage( NULL, msg );
 }
 }
 
diff --git a/include/confirm.h b/include/confirm.h
index 

Re: [Kicad-developers] Via tool in Pcbnew.

[hauptmech]

Hi Orson,

I do agree that a single solution does not satisfy everyone, nor does it 
have to.


I was just adding my voice to Heikki's that the PNS router does not 
quite handle some of the basic tasks that I am needing to do, that the 
legacy interface does handle. The details are complex, partially rooted 
in the fact that net class based clearances are not a good approach for 
my current situation where I need to use mixed trace/space technology on 
the same nets. Meanwhile I'm dropping back to the legacy interface 
occasionally to make progress and that fact is significant in itself.


Dragging track nodes, including dragging the free end of a track that is 
in progress but also in the way of the track I'm laying, is the 
difference that causes me to drop back the most.


The assumption in the PNS that I want 45degree angles when dragging a 
track and that the free end of a track should be fixed, don't work for 
me. (However these are things I'd tweak to suit myself if others had no 
need)


The ability to delete a segment (or walkaround chain) is something from 
the legacy that I would bring over to my own branch if the core team did 
not.


The frequent mouse click drops I have not had time to understand enough 
to file a bug report. Whether it is PNS event handling or the load put 
on the system by PNS plus kicad or WX, I don't know.



On 20/07/17 23:41, Maciej Sumiński wrote:

Hi hauptmech,

On 07/20/2017 12:31 PM, hauptmech wrote:

I'm with Heikki. I've been using the GAL canvas for a complex project. I
don't really have time to learn the nuances of the interactive router; I
found that highlight collisions kept it from doing stuff I did not want
in tight layouts and I fall back to legacy for things like tweaking
track nodes and when I get tired of dropped mouse clicks.

Is there any related bug report so we could investigate the problem?

We realize that *any* change will have its opponents, therefore PNS
offers the highlight collision mode which is meant to work as the legacy
router. What is the difference in your opinion?


It's hard to articulate well, but I get the feeling that the interactive
router is either based on a single companies layout culture, or, with
the utmost respect for all the awesome hard work that's gone into it,
the authors are copying features in other software rather than working
with the needs and user stories of users that they are in contact with.

Do you agree it is very hard to satisfy everyone with a single solution?
KiCad offers multiple options to adjust it to your needs. We would love
to hear your story, but please keep in mind that we are simply unable to
fulfill all requests.

Regards,
Orson



___
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] Via tool in Pcbnew.

[Marcos Chaparro]

A few things I remember when using nighties.

* disable design rule checking button is ignored in GAL. I use it when I
swap 2 pins in the schematic, I turn off drc, make the track change, then
rebuild connectivity. Otherwise I end up deleting the whole track and
starting over.
* On legacy pressing E over a segment changes the segment width to the
current track width. Same for vias. I acknowledge the new window that pops
up can change the width, but maybe someone could complain (not me, just
pointing that out). I don't see the use of changing the segment coordinates
in that window yet.
* Sometimes it pisses me off that I explicitly change the trace direction
with / but when it reaches the pad the direction is changed. I back off
from the pad, change the direction (/) again and when I get again into the
pad the track direction is changed again. I guess the algorithm tries to
avoid an extra segment -which makes sense- but sometimes I just need my
track to be farther away from a noise source and I don't care about one
less track angle.

See 2 quick videos showing the difference between routing behavior. The
only thing I did between videos is to press F9

https://youtu.be/puhrZMf7bWg

https://youtu.be/vqwiCvMWAaI



Marcos

On Thu, Jul 20, 2017 at 9:16 AM, Lorenzo Marcantonio 
wrote:

> On Thu, Jul 20, 2017 at 10:31:09PM +1200, hauptmech wrote:
> >
> > I'm with Heikki. I've been using the GAL canvas for a complex project. I
> > don't really have time to learn the nuances of the interactive router; I
> > found that highlight collisions kept it from doing stuff I did not want
> in
> > tight layouts and I fall back to legacy for things like tweaking track
> nodes
> > and when I get tired of dropped mouse clicks.
>
> Strange, when it's set up correctly it can work like the old one. Another
> thing (but I think that was already fixed) is the 'don't check clearance'
> button, I needed it a while ago and didn't work under GAL.
>
>
> --
> Lorenzo Marcantonio
>
> ___
> 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] Via tool in Pcbnew.

[Wayne Stambaugh]

On 7/20/2017 6:04 AM, Lorenzo Marcantonio wrote:
> On Thu, Jul 20, 2017 at 12:47:50PM +0300, Heikki Pulkkinen wrote:
>> Hi Wayne
>>
>> Why not support legacy users? Why everybody should use gal canvas? Do not
>> have to answer, just try to understand your politics.
> 
> It's legacy because new tools are not available for it, like the P router
> 
> However before junking it *please* implement everything on the new one
> (like the cursor behaviour which is way more useful to measure than the
> new tool in the GAL view)
> 

I think most of the features have been implemented in the new canvas.
If they haven't please file a bug report so we can add them.  That is
the criteria for removing the legacy canvas.

___
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] Via tool in Pcbnew.

[Lorenzo Marcantonio]

On Thu, Jul 20, 2017 at 10:31:09PM +1200, hauptmech wrote:
> 
> I'm with Heikki. I've been using the GAL canvas for a complex project. I
> don't really have time to learn the nuances of the interactive router; I
> found that highlight collisions kept it from doing stuff I did not want in
> tight layouts and I fall back to legacy for things like tweaking track nodes
> and when I get tired of dropped mouse clicks.

Strange, when it's set up correctly it can work like the old one. Another thing 
(but I think that was already fixed) is the 'don't check clearance' button, I 
needed it a while ago and didn't work under GAL.


-- 
Lorenzo Marcantonio


signature.asc
Description: PGP 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] Via tool in Pcbnew.

[Wayne Stambaugh]

The legacy canvas is going to be removed after the v5 release so it
would be a waste of time to implement the via tool in the legacy canvas
only to have it removed a short time later.

On 7/20/2017 5:47 AM, Heikki Pulkkinen wrote:
> Hi Wayne
> 
> Why not support legacy users? Why everybody should use gal canvas? Do
> not have to answer, just try to understand your politics.
> 
> Regards
> Heikki
> 
> On Wed, Jul 19, 2017 at 4:15 PM, Wayne Stambaugh  > wrote:
> 
> Heikki,
> 
> I'm not suggesting that we add the new via tool to the legacy canvas.
> The legacy canvas is going to be removed after the v5 release so it
> doesn't make much sense.  However, having a toolbar button that does
> nothing will confuse users.  That why I suggested that we hide the via
> toolbar button when the legacy canvas is active.
> 
> Wayne
> 
> On 7/19/2017 3:25 AM, Heikki Pulkkinen wrote:
> > Hi Wayne
> >
> > You do not have to disable via tool in legacy canvas. I use it as via
> > stitching tool. I am terribly sorry, that It does not put vias when ever
> > you want. It is using same logic as via stitching, but it can be easily
> > changed to use same logic as gal canvas has.
> >
> > https://youtu.be/Tex8YyQaxE8
> >
> > regards
> > heikki
> >
> > On Tue, Jul 18, 2017 at 7:53 PM, Wayne Stambaugh  
> > >> wrote:
> >
> > We probably should disable or not even expose the via tool on the 
> right
> > toolbar in pcbnew when the legacy canvas is active since it doesn't 
> do
> > anything.  I think this will just confuse users.  I can file a bug
> > report if this helps.
> >
> > Cheers,
> >
> > Wayne
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> 
> >  >
> > Post to : kicad-developers@lists.launchpad.net
> 
> >  >
> > Unsubscribe : https://launchpad.net/~kicad-developers
> 
> >  >
> > More help   : https://help.launchpad.net/ListHelp
> 
> >  >
> >
> >
> 
> 

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

Re: [Kicad-developers] Cursor behavior

[Simon Küppers]

I am also currently not up to speed on this topic. However, what could
also benefit usability is to visually highlight the origin that is
being used during the move operation (maybe a green dot or something).



Am 20.07.2017 um 13:50 schrieb Lorenzo Marcantonio:
> On Thu, Jul 20, 2017 at 01:44:06PM +0200, jp charras wrote:
>> Perhaps the algorithm should be slightly modified to use the pad
>> if the mouse cursor is inside a pad, and the footprint origin if
>> the mouse cursor is inside the footprint (obviously), but not 
>> inside a pad.
> 
> Uhm. That could be, I noticed it a little while ago.
> 
>> It could be a more intuitive behavior.
> 
> I need to check with a more recent build, maybe these are all
> things that have already been fixed in the meantime.
> 
> Just remembering to not leave things behind :P
> 
> 
> 
> ___ 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] Cursor behavior

[Lorenzo Marcantonio]

On Thu, Jul 20, 2017 at 01:44:06PM +0200, jp charras wrote:
> Perhaps the algorithm should be slightly modified to use the pad if the mouse 
> cursor is inside a
> pad, and the footprint origin if the mouse cursor is inside the footprint 
> (obviously), but not
> inside a pad.

Uhm. That could be, I noticed it a little while ago.

> It could be a more intuitive behavior.

I need to check with a more recent build, maybe these are all things
that have already been fixed in the meantime.

Just remembering to not leave things behind :P

-- 
Lorenzo Marcantonio


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

Re: [Kicad-developers] Cursor behavior

[Maciej Sumiński]

Hi Jean-Pierre,

On 07/20/2017 01:44 PM, jp charras wrote:
[snip]
> 
> AFAIK, for me "old" issues related to the cursor and grid are fixed.
> 
> AFAIK, when moving a single footprint, the anchor point is either one of its
> pads or the footprint origin, the nearest candidate point from mouse cursor.
> 
> Perhaps the algorithm should be slightly modified to use the pad if the mouse 
> cursor is inside a
> pad, and the footprint origin if the mouse cursor is inside the footprint 
> (obviously), but not
> inside a pad.
> 
> It could be a more intuitive behavior.

Sounds like a clever idea. Let's wait for some more opinions, but I am
willing to implement this.

Regards,
Orson



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

Re: [Kicad-developers] Cursor behavior

[jp charras]

Le 20/07/2017 à 13:27, Maciej Sumiński a écrit :
> On 07/20/2017 12:37 PM, Lorenzo Marcantonio wrote:
>> On Thu, Jul 20, 2017 at 12:14:40PM +0200, Maciej Sumiński wrote:
>>> What do you exactly mean regarding the cursor behavior?
>>
>> For example the cursor moving on the grid and using space to take
>> measurement is way faster. AFAIK this is already WIP.
> 
> Is not it past the WIP stage already? If you use any recent commit,
> please check it out and let me know if it does not work.
> 
>> Also if you move a footprint in the GAL you use the point under the
>> cursor as anchor (not the component origin) so most of the time the
>> component gets placed out of grid.
> 
> When you drag a single footprint, the anchor point is either one of its
> pads or the footprint origin. For multiple components the anchor is
> aligned to the grid, meaning that components will stay on the grid.
> 
> Am I missing something here?
> 
> Regards,
> Orson
> 

AFAIK, for me "old" issues related to the cursor and grid are fixed.

AFAIK, when moving a single footprint, the anchor point is either one of its
pads or the footprint origin, the nearest candidate point from mouse cursor.

Perhaps the algorithm should be slightly modified to use the pad if the mouse 
cursor is inside a
pad, and the footprint origin if the mouse cursor is inside the footprint 
(obviously), but not
inside a pad.

It could be a more intuitive behavior.

-- 
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] Via tool in Pcbnew.

[Maciej Sumiński]

Hi hauptmech,

On 07/20/2017 12:31 PM, hauptmech wrote:
> 
> I'm with Heikki. I've been using the GAL canvas for a complex project. I
> don't really have time to learn the nuances of the interactive router; I
> found that highlight collisions kept it from doing stuff I did not want
> in tight layouts and I fall back to legacy for things like tweaking
> track nodes and when I get tired of dropped mouse clicks.

Is there any related bug report so we could investigate the problem?

We realize that *any* change will have its opponents, therefore PNS
offers the highlight collision mode which is meant to work as the legacy
router. What is the difference in your opinion?

> It's hard to articulate well, but I get the feeling that the interactive
> router is either based on a single companies layout culture, or, with
> the utmost respect for all the awesome hard work that's gone into it,
> the authors are copying features in other software rather than working
> with the needs and user stories of users that they are in contact with.

Do you agree it is very hard to satisfy everyone with a single solution?
KiCad offers multiple options to adjust it to your needs. We would love
to hear your story, but please keep in mind that we are simply unable to
fulfill all requests.

Regards,
Orson

> Not that the legacy canvas is a perfect interface.
> 
> On 20/07/17 22:04, Lorenzo Marcantonio wrote:
>> On Thu, Jul 20, 2017 at 12:47:50PM +0300, Heikki Pulkkinen wrote:
>>> Hi Wayne
>>>
>>> Why not support legacy users? Why everybody should use gal canvas? Do
>>> not
>>> have to answer, just try to understand your politics.
>> It's legacy because new tools are not available for it, like the P
>> router
>>
>> However before junking it *please* implement everything on the new one
>> (like the cursor behaviour which is way more useful to measure than the
>> new tool in the GAL view)



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

Re: [Kicad-developers] Cursor behavior

[Maciej Sumiński]

On 07/20/2017 12:37 PM, Lorenzo Marcantonio wrote:
> On Thu, Jul 20, 2017 at 12:14:40PM +0200, Maciej Sumiński wrote:
>> What do you exactly mean regarding the cursor behavior?
> 
> For example the cursor moving on the grid and using space to take
> measurement is way faster. AFAIK this is already WIP.

Is not it past the WIP stage already? If you use any recent commit,
please check it out and let me know if it does not work.

> Also if you move a footprint in the GAL you use the point under the
> cursor as anchor (not the component origin) so most of the time the
> component gets placed out of grid.

When you drag a single footprint, the anchor point is either one of its
pads or the footprint origin. For multiple components the anchor is
aligned to the grid, meaning that components will stay on the grid.

Am I missing something here?

Regards,
Orson



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

Re: [Kicad-developers] Cursor behavior (was: Via tool in Pcbnew.)

[Lorenzo Marcantonio]

On Thu, Jul 20, 2017 at 12:14:40PM +0200, Maciej Sumiński wrote:
> What do you exactly mean regarding the cursor behavior?

For example the cursor moving on the grid and using space to take
measurement is way faster. AFAIK this is already WIP.

Also if you move a footprint in the GAL you use the point under the
cursor as anchor (not the component origin) so most of the time the
component gets placed out of grid.

-- 
Lorenzo Marcantonio


signature.asc
Description: PGP 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] Via tool in Pcbnew.

[hauptmech]

I'm with Heikki. I've been using the GAL canvas for a complex project. I 
don't really have time to learn the nuances of the interactive router; I 
found that highlight collisions kept it from doing stuff I did not want 
in tight layouts and I fall back to legacy for things like tweaking 
track nodes and when I get tired of dropped mouse clicks.


It's hard to articulate well, but I get the feeling that the interactive 
router is either based on a single companies layout culture, or, with 
the utmost respect for all the awesome hard work that's gone into it, 
the authors are copying features in other software rather than working 
with the needs and user stories of users that they are in contact with.


Not that the legacy canvas is a perfect interface.

On 20/07/17 22:04, Lorenzo Marcantonio wrote:

On Thu, Jul 20, 2017 at 12:47:50PM +0300, Heikki Pulkkinen wrote:

Hi Wayne

Why not support legacy users? Why everybody should use gal canvas? Do not
have to answer, just try to understand your politics.

It's legacy because new tools are not available for it, like the P router

However before junking it *please* implement everything on the new one
(like the cursor behaviour which is way more useful to measure than the
new tool in the GAL view)



___
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] Cursor behavior (was: Via tool in Pcbnew.)

[Maciej Sumiński]

Hi Lorenzo,

On 07/20/2017 12:04 PM, Lorenzo Marcantonio wrote:
[snip]
> However before junking it *please* implement everything on the new one
> (like the cursor behaviour which is way more useful to measure than the
> new tool in the GAL view)

What do you exactly mean regarding the cursor behavior?

Regards,
Orson




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] Via tool in Pcbnew.

[Lorenzo Marcantonio]

On Thu, Jul 20, 2017 at 12:47:50PM +0300, Heikki Pulkkinen wrote:
> Hi Wayne
> 
> Why not support legacy users? Why everybody should use gal canvas? Do not
> have to answer, just try to understand your politics.

It's legacy because new tools are not available for it, like the P router

However before junking it *please* implement everything on the new one
(like the cursor behaviour which is way more useful to measure than the
new tool in the GAL view)

-- 
Lorenzo Marcantonio


signature.asc
Description: PGP 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] Via tool in Pcbnew.

[Heikki Pulkkinen]

Hi Wayne

Why not support legacy users? Why everybody should use gal canvas? Do not
have to answer, just try to understand your politics.

Regards
Heikki

On Wed, Jul 19, 2017 at 4:15 PM, Wayne Stambaugh 
wrote:

> Heikki,
>
> I'm not suggesting that we add the new via tool to the legacy canvas.
> The legacy canvas is going to be removed after the v5 release so it
> doesn't make much sense.  However, having a toolbar button that does
> nothing will confuse users.  That why I suggested that we hide the via
> toolbar button when the legacy canvas is active.
>
> Wayne
>
> On 7/19/2017 3:25 AM, Heikki Pulkkinen wrote:
> > Hi Wayne
> >
> > You do not have to disable via tool in legacy canvas. I use it as via
> > stitching tool. I am terribly sorry, that It does not put vias when ever
> > you want. It is using same logic as via stitching, but it can be easily
> > changed to use same logic as gal canvas has.
> >
> > https://youtu.be/Tex8YyQaxE8
> >
> > regards
> > heikki
> >
> > On Tue, Jul 18, 2017 at 7:53 PM, Wayne Stambaugh  > > wrote:
> >
> > We probably should disable or not even expose the via tool on the
> right
> > toolbar in pcbnew when the legacy canvas is active since it doesn't
> do
> > anything.  I think this will just confuse users.  I can file a bug
> > report if this helps.
> >
> > Cheers,
> >
> > Wayne
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > 
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > 
> > More help   : https://help.launchpad.net/ListHelp
> > 
> >
> >
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp