Re: [Kicad-developers] [RFC] Application naming

[Jon Evans]

As a mostly user and occasional code hacker, here are my thoughts:

The EDA tool industry is trending towards more integration, as many of the
commercial products were originally formed from separate applications
(often from separate companies originally).  I have used a number of
commercial products and they are all this way. Having separate applications
with separate lineage makes for less-than-optimal usability and workflow,
and so all the vendors are trying to move towards integration -- either by
putting everything in a single binary, or more often, keeping multiple
binaries, but branding them together, making sure the UIs look consistent,
and having lots of integration between them so it doesn't feel like a
struggle to go between the different binaries for different parts of the
EDA workflow.

So, I'm in favor of rebranding the KiCad applications, because I think it's
in line with the work you all are doing to improve the user workflow and
improve the integration between the schematic, layout, and library
workflows.  I also think it would be good to include the name change in a
"marketing message" to the user community about a focus on the whole EDA
workflow, not separate applications in silos.  Even if you technically can
run the schematic editor separate from the PCB layout tool, if you have the
*mindset* that they are all pieces of the same puzzle and need to fit
together, it can influence the philosophy of the project.

But, as JP mentioned, this would be a big deal in terms of documentation
and resources on the web.  I would suggest that the problems can be
overcome, but only if the communications and timing of the change is
handled well.

-Jon

On Thu, Feb 2, 2017 at 1:54 PM, jp charras  wrote:

> Le 02/02/2017 à 19:13, Pedro Martin a écrit :
> > Hi Chris,
> >
> > Beginners solve this issue... reading the manual.
> >
> > Why not keep the actual names only because JP named them this way?
> >
> > Regards,
> > Pedro.
> >
>
> Thanks Pedro.
> But the major issue which must be taken in account it not that.
>
> Changing names has serious results:
> * Documentation and all the translations has to be modified.
> Opinion was asked to devs, to users, but not to doc
> writers/translators,and this is really not fair.
> * Links on Internet cannot be modified, and there are a lot of hits
> regarding kicad:
> I really agree Cvpcb is not a good name, but just try "Cvpcb" on Google .
>
> Before changing these names you have to  *seriously* think to the results.
> (Think about that not only twice, but 3 times about that)
>
> --
> 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

[Kicad-developers] RFC: Arbitrary color support

[Jon Evans]

Hi all,

I started working on the idea of a color theme system for KiCad, starting
with the schematic editor.

This change relies on a complete removal of EDA_COLOR_T from the code, and
replacement with a color structure that can handle arbitrary colors.  I
think this is important and the right path for the future, but since it's a
significant change, I wanted to get buy-in before going any farther down
this road.  I can understand the reasons for using an enum for
color--especially since it lets the developers restrict the colors to those
that will work well with the drawing technique of the legacy canvases.
But, since the new canvases will have no problem supporting arbitrary
colors, I think it makes sense to start setting up the groundwork for that.

In my test code, I have replaced EDA_COLOR_T with wxColour, since that is
used internally in a few places already, and it was pretty simple (although
somewhat time-consuming) to replace all usages.  wxColour has the nice
property of serializing/deserializing from hex color codes like "#80FC62"
so that's what I use for storing in the settings for now (eventually I
think color settings should be in their own files so that they can be
traded by users).  Plus, there is a canned wxColourPicker widget that I can
use in place of the custom color picker buttons that are used in the
settings today.

You can see some screenshots of the (work-in-progress) settings dialog
changes, and an example of a custom color theme in the schematic editor,
here:
http://imgur.com/a/MxMmb

So, any feedback from the core team?  Any reason why I shouldn't move
forward with preparing a patch to move from EDA_COLOR_T to wxColour across
the board?

Best,
Jon
___
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: Arbitrary color support

[Jon Evans]

Hi Simon, JP,

I understand the issue with the colors chosen for OR-mixing.  I thought a
good first step would be to set the framework for the future when that is
no longer relevant (i.e. when there is no legacy canvas anymore).  It can
be a "under the hood" change only in pcbnew, until the legacy canvas is
removed.

BTW Chris, I also have some ideas for improving the visualization of very
busy (dense and high layer count) boards, I will play with them soon...

-Jon

On Tue, Feb 7, 2017 at 6:32 AM, Chris Pavlina 
wrote:

> Let people choose. Have the default colors be wxDC-friendly. Trust me,
> nobody is choosing to work with eight-layer boards in legacy.
>
> On Tue, Feb 07, 2017 at 09:01:10AM +0100, jp charras wrote:
> > Le 07/02/2017 à 06:31, Simon Wells a écrit :
> > > i thought this wasn't possible due to wxDC limitations
> >
> > Exactly, wxDC does not have a transparency feature to draw items.
> >
> > In this case, when you want to draw board layers with a transparency
> effect, the only one other way
> > to do that is to use logic combination between colors (for transparency:
> the OR operation.)
> >
> > In other to achieve a good result, you cannot use any color for layers.
> > You have to choose a set of colors which allows this good result.
> > (by adjusting the 32 bits binary values of each color to ensure a good
> result when 2 or more color
> > values are ORed)
> >
> > There are not a lot of suitable binary values.
> > In all cases the background must be black (when using OR or
> transparency).
> >
> > Note also Eeschema does not use currently transparency, and the choice
> of colors is not critical.
> >
> > >
> > > On 7 February 2017 at 17:00, Chris Pavlina 
> wrote:
> > >> I'm working on an eight-layer board and really can't wait for this to
> > >> hit pcbnew too. It's bloody impossible to tell layers apart with
> KiCad's
> > >> state-of-the-80s-art color system.
> >
> > I have made a few boards with 8 and one with 16 layers.
> > There is no perfect way to see all layers.
> >
> > I used Pcbnew and Altium (in a company which has a Altium license) to
> design a 8 layers board (2
> > very similar boards, one with Pcbnew, the other with Altium, because
> this company used Altium).
> >
> > Altium allows arbitrary colors and transparency, but a 8 layers board is
> not easy to manage.
> >
> > So do not expect allowing arbitrary colors and transparency will fix
> your problem.
> > (In the best case, it slightly helps).
> >
> >
> > Having said that, using a selected set of colors does not imply using
> EDA_COLOR_T in Kicad code.
> > wxColor can be used instead of.
> >
> > This is only the *color choice* in Pcbnew which is constrained in legacy
> canvas.
> >
> > EDA_COLOR_T comes from the fact the legacy graphic primitives where
> written for an other library,
> > not for wxWidgets.
> > (Kicad was started before wxWidgets exists)
> >
> > >>
> > >> On Mon, Feb 06, 2017 at 10:03:11PM -0500, Jon Evans wrote:
> > >>> Hi all,
> > >>>
> > >>> I started working on the idea of a color theme system for KiCad,
> starting
> > >>> with the schematic editor.
> > >>>
> > >>> This change relies on a complete removal of EDA_COLOR_T from the
> code, and
> > >>> replacement with a color structure that can handle arbitrary
> colors.  I
> > >>> think this is important and the right path for the future, but since
> it's a
> > >>> significant change, I wanted to get buy-in before going any farther
> down
> > >>> this road.  I can understand the reasons for using an enum for
> > >>> color--especially since it lets the developers restrict the colors
> to those
> > >>> that will work well with the drawing technique of the legacy
> canvases.
> > >>> But, since the new canvases will have no problem supporting arbitrary
> > >>> colors, I think it makes sense to start setting up the groundwork
> for that.
> > >>>
> > >>> In my test code, I have replaced EDA_COLOR_T with wxColour, since
> that is
> > >>> used internally in a few places already, and it was pretty simple
> (although
> > >>> somewhat time-consuming) to replace all usages.  wxColour has the
> nice
> > >>> property of serializing/deserializing from hex color codes like
> "#80FC62"
> > >>> so that's what

Re: [Kicad-developers] RFC: Arbitrary color support

[Jon Evans]

Would you accept the patch to move to wxColour if it were not possible to
choose "bad" colors in the the layout tool?  It would be easy to restrict
the colors to the current set in the pcb/footprint editors and just allow
user selection in the schematic/symbol editors for now.

On Tue, Feb 7, 2017 at 10:19 AM, Wayne Stambaugh 
wrote:

> On 2/7/2017 9:00 AM, Chris Pavlina wrote:
> > On Tue, Feb 07, 2017 at 08:57:23AM -0500, Jon Evans wrote:
> >> Hi Simon, JP,
> >>
> >> I understand the issue with the colors chosen for OR-mixing.  I thought
> a
> >> good first step would be to set the framework for the future when that
> is
> >> no longer relevant (i.e. when there is no legacy canvas anymore).  It
> can
> >> be a "under the hood" change only in pcbnew, until the legacy canvas is
> >> removed.
> >>
> >> BTW Chris, I also have some ideas for improving the visualization of
> very
> >> busy (dense and high layer count) boards, I will play with them soon...
> >
> > Nice! I look forward to that. Definitely an area we can improve on.
>
> Since the schematic editor canvas doesn't support transparency, you
> could make the colors anything you want.  In the board editor, the layer
> managers handles colors for both legacy and gal canvases so I'm not sure
> it makes sense until the legacy canvas is deprecated.
>
> >
> >>
> >> -Jon
> >>
> >> On Tue, Feb 7, 2017 at 6:32 AM, Chris Pavlina 
> >> wrote:
> >>
> >>> Let people choose. Have the default colors be wxDC-friendly. Trust me,
> >>> nobody is choosing to work with eight-layer boards in legacy.
> >>>
> >>> On Tue, Feb 07, 2017 at 09:01:10AM +0100, jp charras wrote:
> >>>> Le 07/02/2017 à 06:31, Simon Wells a écrit :
> >>>>> i thought this wasn't possible due to wxDC limitations
> >>>>
> >>>> Exactly, wxDC does not have a transparency feature to draw items.
> >>>>
> >>>> In this case, when you want to draw board layers with a transparency
> >>> effect, the only one other way
> >>>> to do that is to use logic combination between colors (for
> transparency:
> >>> the OR operation.)
> >>>>
> >>>> In other to achieve a good result, you cannot use any color for
> layers.
> >>>> You have to choose a set of colors which allows this good result.
> >>>> (by adjusting the 32 bits binary values of each color to ensure a good
> >>> result when 2 or more color
> >>>> values are ORed)
> >>>>
> >>>> There are not a lot of suitable binary values.
> >>>> In all cases the background must be black (when using OR or
> >>> transparency).
> >>>>
> >>>> Note also Eeschema does not use currently transparency, and the choice
> >>> of colors is not critical.
> >>>>
> >>>>>
> >>>>> On 7 February 2017 at 17:00, Chris Pavlina 
> >>> wrote:
> >>>>>> I'm working on an eight-layer board and really can't wait for this
> to
> >>>>>> hit pcbnew too. It's bloody impossible to tell layers apart with
> >>> KiCad's
> >>>>>> state-of-the-80s-art color system.
> >>>>
> >>>> I have made a few boards with 8 and one with 16 layers.
> >>>> There is no perfect way to see all layers.
> >>>>
> >>>> I used Pcbnew and Altium (in a company which has a Altium license) to
> >>> design a 8 layers board (2
> >>>> very similar boards, one with Pcbnew, the other with Altium, because
> >>> this company used Altium).
> >>>>
> >>>> Altium allows arbitrary colors and transparency, but a 8 layers board
> is
> >>> not easy to manage.
> >>>>
> >>>> So do not expect allowing arbitrary colors and transparency will fix
> >>> your problem.
> >>>> (In the best case, it slightly helps).
> >>>>
> >>>>
> >>>> Having said that, using a selected set of colors does not imply using
> >>> EDA_COLOR_T in Kicad code.
> >>>> wxColor can be used instead of.
> >>>>
> >>>> This is only the *color choice* in Pcbnew which is constrained in
> legacy
> >>> canvas.
> >>>>
> >>>> EDA_COLOR_T comes from the fact the legacy graphic primiti

Re: [Kicad-developers] RFC: Arbitrary color support

[Jon Evans]

I can think of a few ways to approach it:

1) Don't change how color works in the UI of pcbnew for now.  Change to
wxColour under the hood, but keep the current color selections -- no user
visible change, no problems, but also no new feature in pcbnew GAL.

2) Allow using the new color picker in GAL canvas of pcbnew.  When user
changes from legacy to GAL, no problem.  When user changes from GAL to
legacy, now there is the question of what to do.  We could:

2a) Reset layer colors to the legacy defaults
2b) Set layer colors to the "closest" legacy default to what the user set
in GAL (how to define "closest" requires some testing I think) --
optionally give a notice to the user that their colors have been modified
because of the switch to legacy.
2c) Warn the user that they have changed to colors that won't work right in
legacy canvas, and advise them to manually reset their layer colors.
Things will look weird until the user does so.

Any preference for the above?

-Jon

On Tue, Feb 7, 2017 at 11:20 AM, Wayne Stambaugh 
wrote:

> I'm not sure how you would prevent "bad" legacy colors from being
> selected without limiting the color selection in the gal canvas.  If you
> can pull it off without the code limiting colors in gal, still be useful
> in legacy, and have a reasonable design than I'm OK with it.  Given that
> we are nearing a feature freeze for the next stable release, if you
> cannot have this ready reasonably soon (next month or two), then it will
> have to be pushed back to the version 6 release.
>
> Cheers,
>
> Wayne
>
> On 2/7/2017 10:27 AM, Jon Evans wrote:
> > Would you accept the patch to move to wxColour if it were not possible
> > to choose "bad" colors in the the layout tool?  It would be easy to
> > restrict the colors to the current set in the pcb/footprint editors and
> > just allow user selection in the schematic/symbol editors for now.
> >
> > On Tue, Feb 7, 2017 at 10:19 AM, Wayne Stambaugh  > <mailto:stambau...@gmail.com>> wrote:
> >
> > On 2/7/2017 9:00 AM, Chris Pavlina wrote:
> > > On Tue, Feb 07, 2017 at 08:57:23AM -0500, Jon Evans wrote:
> > >> Hi Simon, JP,
> > >>
> > >> I understand the issue with the colors chosen for OR-mixing.  I
> thought a
> > >> good first step would be to set the framework for the future when
> that is
> > >> no longer relevant (i.e. when there is no legacy canvas
> anymore).  It can
> > >> be a "under the hood" change only in pcbnew, until the legacy
> canvas is
> > >> removed.
> > >>
> > >> BTW Chris, I also have some ideas for improving the visualization
> of very
> > >> busy (dense and high layer count) boards, I will play with them
> soon...
> > >
> > > Nice! I look forward to that. Definitely an area we can improve on.
> >
> > Since the schematic editor canvas doesn't support transparency, you
> > could make the colors anything you want.  In the board editor, the
> layer
> > managers handles colors for both legacy and gal canvases so I'm not
> sure
> > it makes sense until the legacy canvas is deprecated.
> >
> > >
> > >>
> > >> -Jon
> > >>
> > >> On Tue, Feb 7, 2017 at 6:32 AM, Chris Pavlina
> > mailto:pavlina.ch...@gmail.com>>
> > >> wrote:
> > >>
> > >>> Let people choose. Have the default colors be wxDC-friendly.
> > Trust me,
> > >>> nobody is choosing to work with eight-layer boards in legacy.
> > >>>
> > >>> On Tue, Feb 07, 2017 at 09:01:10AM +0100, jp charras wrote:
> > >>>> Le 07/02/2017 à 06:31, Simon Wells a écrit :
> > >>>>> i thought this wasn't possible due to wxDC limitations
> > >>>>
> > >>>> Exactly, wxDC does not have a transparency feature to draw
> items.
> > >>>>
> > >>>> In this case, when you want to draw board layers with a
> > transparency
> > >>> effect, the only one other way
> > >>>> to do that is to use logic combination between colors (for
> > transparency:
> > >>> the OR operation.)
> > >>>>
> > >>>> In other to achieve a good result, you cannot use any color for
> > layers.
> > >>>> You have to choose a set of colors which allows this good
> result.
> > 

Re: [Kicad-developers] RFC: Arbitrary color support

[Jon Evans]

Hi Orson,

I have started down the road of using COLOR4D as I think it's a better idea
than introducing so much woven dependency on wxWidgets.  But, I ran into a
concern that I thought I'd ask the devs about...

Since COLOR4D is part of libgal, if I want to use COLOR4D as part of the
color config system (which I do), that means adding libgal as a dependency
of (all of?) the binaries.  Or, I could hoist COLOR4D out of GAL into
common.

Any preferences as to how to approach that?

Wayne -- I will do some tests on "auto-picking" legacy colors and see how
good/bad it looks.

Thanks,
Jon

On Tue, Feb 7, 2017 at 4:34 PM, Maciej Suminski 
wrote:

> Hi Jon,
>
> On 02/07/2017 04:03 AM, Jon Evans wrote:
> > Hi all,
> >
> > I started working on the idea of a color theme system for KiCad, starting
> > with the schematic editor.
> >
> > This change relies on a complete removal of EDA_COLOR_T from the code,
> and
> > replacement with a color structure that can handle arbitrary colors.
>
> Have at look at COLOR4D (include/gal/color4d.h), it may be a good
> starting point. It has a constructor taking wxColour as the argument, if
> you prefer wx classes.
>
> GAL should be capable of using any color you like (see e.g.
> PCB_RENDER_SETTINGS in pcbnew/painter.cpp. The only problem is the color
> picker, and as you have already noticed, resolving the new colors in the
> legacy canvas. IMHO resorting to the closest 'safe' color is the best
> option.
>
> Your work-in-progress screenshots look very neat. I would love to see
> the final version.
>
> Regards,
> Orson
>
> > I
> > think this is important and the right path for the future, but since
> it's a
> > significant change, I wanted to get buy-in before going any farther down
> > this road.  I can understand the reasons for using an enum for
> > color--especially since it lets the developers restrict the colors to
> those
> > that will work well with the drawing technique of the legacy canvases.
> > But, since the new canvases will have no problem supporting arbitrary
> > colors, I think it makes sense to start setting up the groundwork for
> that.
> >
> > In my test code, I have replaced EDA_COLOR_T with wxColour, since that is
> > used internally in a few places already, and it was pretty simple
> (although
> > somewhat time-consuming) to replace all usages.  wxColour has the nice
> > property of serializing/deserializing from hex color codes like "#80FC62"
> > so that's what I use for storing in the settings for now (eventually I
> > think color settings should be in their own files so that they can be
> > traded by users).  Plus, there is a canned wxColourPicker widget that I
> can
> > use in place of the custom color picker buttons that are used in the
> > settings today.
> >
> > You can see some screenshots of the (work-in-progress) settings dialog
> > changes, and an example of a custom color theme in the schematic editor,
> > here:
> > http://imgur.com/a/MxMmb
> >
> > So, any feedback from the core team?  Any reason why I shouldn't move
> > forward with preparing a patch to move from EDA_COLOR_T to wxColour
> across
> > the board?
> >
> > Best,
> > Jon
> >
> >
> >
> > ___
> > 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] Arbitrary color support update

[Jon Evans]

Hi all,

I've made some good progress on arbitrary color support since I was stuck
at home due to snow today :-)  I implemented it in pcbnew GAL canvas, and
have logic for switching to legacy colors when the user switches to legacy
canvas, that seems to work pretty well in my opinion.

Here's a sneak peek of arbitrary colors in pcbnew (GAL):
http://i.imgur.com/xWm0vFk.jpg

If you want to take a look at the code, it's in my branch
"eeschema_color_themes" here:
https://github.com/craftyjon/kicad.git

It is not yet ready to submit as a patch, for a few reasons:

- Have to hear from the core devs whether it's okay to make everything
depend on libgal, or if not, I need to move COLOR4D out to common.

- I am not sure if DXF exporting works, haven't tested it yet (it relied on
EDA_COLOR_T for layer differentiation)

- I need to do a lot more testing on the areas that were affected by the
removal of EDA_COLOR_T  that I haven't been looking closely at

- I have no idea if this works on Windows or Mac -- I should be able to set
up a Windows build environment soon, but can't test on Mac.

Feedback welcome!

Thanks,
Jon
___
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: Arbitrary color support

[Jon Evans]

OK, sounds good.  That's the way it's implemented now on my branch.

On Fri, Feb 10, 2017 at 2:35 AM, Maciej Suminski 
wrote:

> Hi Jon,
>
> Normally, when you use external libraries, you would simply link every
> library you need, even if only a single class/function is needed. I
> would prefer to keep libgal decoupled from everything else, so my
> preference would be to link other apps with libgal instead of migrating
> parts of it to libcommon.
>
> Regards,
> Orson
>
> On 02/09/2017 04:07 PM, Jon Evans wrote:
> > Hi Orson,
> >
> > I have started down the road of using COLOR4D as I think it's a better
> idea
> > than introducing so much woven dependency on wxWidgets.  But, I ran into
> a
> > concern that I thought I'd ask the devs about...
> >
> > Since COLOR4D is part of libgal, if I want to use COLOR4D as part of the
> > color config system (which I do), that means adding libgal as a
> dependency
> > of (all of?) the binaries.  Or, I could hoist COLOR4D out of GAL into
> > common.
> >
> > Any preferences as to how to approach that?
> >
> > Wayne -- I will do some tests on "auto-picking" legacy colors and see how
> > good/bad it looks.
> >
> > Thanks,
> > Jon
> >
> > On Tue, Feb 7, 2017 at 4:34 PM, Maciej Suminski  >
> > wrote:
> >
> >> Hi Jon,
> >>
> >> On 02/07/2017 04:03 AM, Jon Evans wrote:
> >>> Hi all,
> >>>
> >>> I started working on the idea of a color theme system for KiCad,
> starting
> >>> with the schematic editor.
> >>>
> >>> This change relies on a complete removal of EDA_COLOR_T from the code,
> >> and
> >>> replacement with a color structure that can handle arbitrary colors.
> >>
> >> Have at look at COLOR4D (include/gal/color4d.h), it may be a good
> >> starting point. It has a constructor taking wxColour as the argument, if
> >> you prefer wx classes.
> >>
> >> GAL should be capable of using any color you like (see e.g.
> >> PCB_RENDER_SETTINGS in pcbnew/painter.cpp. The only problem is the color
> >> picker, and as you have already noticed, resolving the new colors in the
> >> legacy canvas. IMHO resorting to the closest 'safe' color is the best
> >> option.
> >>
> >> Your work-in-progress screenshots look very neat. I would love to see
> >> the final version.
> >>
> >> Regards,
> >> Orson
> >>
> >>> I
> >>> think this is important and the right path for the future, but since
> >> it's a
> >>> significant change, I wanted to get buy-in before going any farther
> down
> >>> this road.  I can understand the reasons for using an enum for
> >>> color--especially since it lets the developers restrict the colors to
> >> those
> >>> that will work well with the drawing technique of the legacy canvases.
> >>> But, since the new canvases will have no problem supporting arbitrary
> >>> colors, I think it makes sense to start setting up the groundwork for
> >> that.
> >>>
> >>> In my test code, I have replaced EDA_COLOR_T with wxColour, since that
> is
> >>> used internally in a few places already, and it was pretty simple
> >> (although
> >>> somewhat time-consuming) to replace all usages.  wxColour has the nice
> >>> property of serializing/deserializing from hex color codes like
> "#80FC62"
> >>> so that's what I use for storing in the settings for now (eventually I
> >>> think color settings should be in their own files so that they can be
> >>> traded by users).  Plus, there is a canned wxColourPicker widget that I
> >> can
> >>> use in place of the custom color picker buttons that are used in the
> >>> settings today.
> >>>
> >>> You can see some screenshots of the (work-in-progress) settings dialog
> >>> changes, and an example of a custom color theme in the schematic
> editor,
> >>> here:
> >>> http://imgur.com/a/MxMmb
> >>>
> >>> So, any feedback from the core team?  Any reason why I shouldn't move
> >>> forward with preparing a patch to move from EDA_COLOR_T to wxColour
> >> across
> >>> the board?
> >>>
> >>> Best,
> >>> Jon
> >>>
> >>>
> >>>
> >>> ___
> &

[Kicad-developers] [PATCH] Correctly filter copyable objects for copy hotkey (Fixes lp:1571316)

[Jon Evans]

Hi,

Minor patch to eeschema attached to fix reported issue with clarify menu.

-Jon
From 315b745a1db89c06240b42f544502a9cefaa2ad4 Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Sat, 11 Feb 2017 13:29:22 -0500
Subject: [PATCH] Correctly filter copyable objects for copy hotkey (Fixes
 lp:1571316)

---
 eeschema/hotkeys.cpp|  2 +-
 eeschema/sch_collectors.cpp | 10 ++
 eeschema/sch_collectors.h   |  5 +
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/eeschema/hotkeys.cpp b/eeschema/hotkeys.cpp
index c25f68f..bd0d1b9 100644
--- a/eeschema/hotkeys.cpp
+++ b/eeschema/hotkeys.cpp
@@ -575,7 +575,7 @@ bool SCH_EDIT_FRAME::OnHotKey( wxDC* aDC, int aHotKey, const wxPoint& aPosition,
 
 if( aItem == NULL )
 {
-aItem = LocateAndShowItem( aPosition, SCH_COLLECTOR::MovableItems );
+aItem = LocateAndShowItem( aPosition, SCH_COLLECTOR::CopyableItems );
 
 if( aItem == NULL )
 break;
diff --git a/eeschema/sch_collectors.cpp b/eeschema/sch_collectors.cpp
index a467d24..671c611 100644
--- a/eeschema/sch_collectors.cpp
+++ b/eeschema/sch_collectors.cpp
@@ -199,6 +199,16 @@ const KICAD_T SCH_COLLECTOR::OrientableItems[] = {
 };
 
 
+const KICAD_T SCH_COLLECTOR::CopyableItems[] = {
+SCH_TEXT_T,
+SCH_LABEL_T,
+SCH_GLOBAL_LABEL_T,
+SCH_HIERARCHICAL_LABEL_T,
+SCH_COMPONENT_T,
+EOT
+};
+
+
 SEARCH_RESULT SCH_COLLECTOR::Inspect( EDA_ITEM* aItem, void* aTestData )
 {
 if( aItem->Type() != LIB_PIN_T && !aItem->HitTest( m_RefPos ) )
diff --git a/eeschema/sch_collectors.h b/eeschema/sch_collectors.h
index 3485413..93f2efb 100644
--- a/eeschema/sch_collectors.h
+++ b/eeschema/sch_collectors.h
@@ -113,6 +113,11 @@ public:
 static const KICAD_T OrientableItems[];
 
 /**
+ * A scan list for schematic items that can be copied/duplicated.
+ */
+static const KICAD_T CopyableItems[];
+
+/**
  * Constructor SCH_COLLECTOR
  */
 SCH_COLLECTOR( const KICAD_T* aScanTypes = SCH_COLLECTOR::AllItems )
-- 
2.7.4

___
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: Change UX for item selection clarification

[Jon Evans]

Hi all,

I had been thinking about proposing this already as a UX enhancement, and
then while looking through the starter bugs realized that lp:1154020 [1] is
actually quite difficult to solve in a nice way due to the popup menu used
for clarification today, so I decided to send it out now.

I propose that we change the selection code to "guess" at the item the user
wanted to select, and let the user cycle through the set of items that are
near the last point they clicked with a hotkey (and possible a context menu
option "Next").  This is similar to how the commercial tools I've used work.

A few more ideas about this:

- The currently selected item needs to be indicated somehow.  Currently we
don't highlight all items when selected (for example, fields) and so either
highlighting which item you are selecting or showing it in the message
panel would be required for this to be friendly.

- This would tie in nicely to selection filtering stuff that other devs are
working on.  Turning on a selection filter mode ("components only", "text
objects only", etc) would restrict the set of items that can be picked, and
greatly increase the chance that the right item will be selected on the
first click.

- Some commercial tools have "focus" modes, which are kind of like filters,
but they don't restrict what you can select, but rather influence what will
be selected first.  So if you are in "component focus mode" and you select
a component with a label on top, the component will always be selected
first.

- We could map two hotkeys next to each other (for example "," and "." on
QWERTY keyboards) and let people step forward and backward through the
clarification list

I think this change would make item selection faster, allow fixing some
long-standing bugs, and work nicely with enhancements to selection
filtering that are coming.  The one downside is that you would no longer
get a list of all items that are underneath the cursor, but I can't see the
value in that information.

Any thoughts on this?

Best,
Jon

[1] https://bugs.launchpad.net/kicad/+bug/1154020
___
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: Change UX for item selection clarification

[Jon Evans]

Proof of concept: https://www.youtube.com/watch?v=JfnXPosOHcY
(when you see the selection changing, I'm hitting the new hotkey I made for
cycling through items)

On Sat, Feb 11, 2017 at 2:24 PM, Chris Pavlina 
wrote:

> I wish I had thoughts more verbose than "yes" right now... Yeah, this is
> how most tools work, and it's quite intuitive. I would be 100% in favor
> of implementing it this way.
>
> On Sat, Feb 11, 2017 at 02:21:08PM -0500, Jon Evans wrote:
> > Hi all,
> >
> > I had been thinking about proposing this already as a UX enhancement, and
> > then while looking through the starter bugs realized that lp:1154020 [1]
> is
> > actually quite difficult to solve in a nice way due to the popup menu
> used
> > for clarification today, so I decided to send it out now.
> >
> > I propose that we change the selection code to "guess" at the item the
> user
> > wanted to select, and let the user cycle through the set of items that
> are
> > near the last point they clicked with a hotkey (and possible a context
> menu
> > option "Next").  This is similar to how the commercial tools I've used
> work.
> >
> > A few more ideas about this:
> >
> > - The currently selected item needs to be indicated somehow.  Currently
> we
> > don't highlight all items when selected (for example, fields) and so
> either
> > highlighting which item you are selecting or showing it in the message
> > panel would be required for this to be friendly.
> >
> > - This would tie in nicely to selection filtering stuff that other devs
> are
> > working on.  Turning on a selection filter mode ("components only", "text
> > objects only", etc) would restrict the set of items that can be picked,
> and
> > greatly increase the chance that the right item will be selected on the
> > first click.
> >
> > - Some commercial tools have "focus" modes, which are kind of like
> filters,
> > but they don't restrict what you can select, but rather influence what
> will
> > be selected first.  So if you are in "component focus mode" and you
> select
> > a component with a label on top, the component will always be selected
> > first.
> >
> > - We could map two hotkeys next to each other (for example "," and "." on
> > QWERTY keyboards) and let people step forward and backward through the
> > clarification list
> >
> > I think this change would make item selection faster, allow fixing some
> > long-standing bugs, and work nicely with enhancements to selection
> > filtering that are coming.  The one downside is that you would no longer
> > get a list of all items that are underneath the cursor, but I can't see
> the
> > value in that information.
> >
> > Any thoughts on this?
> >
> > Best,
> > Jon
> >
> > [1] https://bugs.launchpad.net/kicad/+bug/1154020
>
>
___
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: Change UX for item selection clarification

[Jon Evans]

I was going to add a context menu entry for "next selection", is that
obvious enough to you or do you think there should be extra hints?

On Feb 11, 2017 18:14, "Chris Pavlina"  wrote:

> Very nice. I only think it needs to be a bit more obvious how to do it.
>
> On Sat, Feb 11, 2017 at 05:49:05PM -0500, Jon Evans wrote:
> > Proof of concept: https://www.youtube.com/watch?v=JfnXPosOHcY
> > (when you see the selection changing, I'm hitting the new hotkey I made
> for
> > cycling through items)
> >
> > On Sat, Feb 11, 2017 at 2:24 PM, Chris Pavlina 
> > wrote:
> >
> > > I wish I had thoughts more verbose than "yes" right now... Yeah, this
> is
> > > how most tools work, and it's quite intuitive. I would be 100% in favor
> > > of implementing it this way.
> > >
> > > On Sat, Feb 11, 2017 at 02:21:08PM -0500, Jon Evans wrote:
> > > > Hi all,
> > > >
> > > > I had been thinking about proposing this already as a UX
> enhancement, and
> > > > then while looking through the starter bugs realized that lp:1154020
> [1]
> > > is
> > > > actually quite difficult to solve in a nice way due to the popup menu
> > > used
> > > > for clarification today, so I decided to send it out now.
> > > >
> > > > I propose that we change the selection code to "guess" at the item
> the
> > > user
> > > > wanted to select, and let the user cycle through the set of items
> that
> > > are
> > > > near the last point they clicked with a hotkey (and possible a
> context
> > > menu
> > > > option "Next").  This is similar to how the commercial tools I've
> used
> > > work.
> > > >
> > > > A few more ideas about this:
> > > >
> > > > - The currently selected item needs to be indicated somehow.
> Currently
> > > we
> > > > don't highlight all items when selected (for example, fields) and so
> > > either
> > > > highlighting which item you are selecting or showing it in the
> message
> > > > panel would be required for this to be friendly.
> > > >
> > > > - This would tie in nicely to selection filtering stuff that other
> devs
> > > are
> > > > working on.  Turning on a selection filter mode ("components only",
> "text
> > > > objects only", etc) would restrict the set of items that can be
> picked,
> > > and
> > > > greatly increase the chance that the right item will be selected on
> the
> > > > first click.
> > > >
> > > > - Some commercial tools have "focus" modes, which are kind of like
> > > filters,
> > > > but they don't restrict what you can select, but rather influence
> what
> > > will
> > > > be selected first.  So if you are in "component focus mode" and you
> > > select
> > > > a component with a label on top, the component will always be
> selected
> > > > first.
> > > >
> > > > - We could map two hotkeys next to each other (for example "," and
> "." on
> > > > QWERTY keyboards) and let people step forward and backward through
> the
> > > > clarification list
> > > >
> > > > I think this change would make item selection faster, allow fixing
> some
> > > > long-standing bugs, and work nicely with enhancements to selection
> > > > filtering that are coming.  The one downside is that you would no
> longer
> > > > get a list of all items that are underneath the cursor, but I can't
> see
> > > the
> > > > value in that information.
> > > >
> > > > Any thoughts on this?
> > > >
> > > > Best,
> > > > Jon
> > > >
> > > > [1] https://bugs.launchpad.net/kicad/+bug/1154020
> > >
> > >
>
___
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: Change UX for item selection clarification

[Jon Evans]

Hi Clemens, thanks for the suggestions!  I will take some time to think
about them.

Hi Kristoffer, I understand there will be people like you who want the
current system, and I am trying to figure out the best way to propose
something that would be accepted by all.  The current system has some
problems -- both actual bugs like the one I referred to (basically having
the popup menu breaks double-clicking), and also limits the possibility of
implementing certain features.

The core of the issue is how KiCad thinks about selection of objects
compared to most other software that deals with graphical objects that the
user interacts with.

Most applications have the concept of a "selection set" that contains 0 or
more objects.  You can select one or more objects, and then separately from
the action of selecting, you can do things to the objects.  KiCad uses a
more "immediate" concept of selection -- you select an object at the same
time as doing something to it.  For certain use cases, KiCad's style is
actually faster -- fewer user inputs needed to do things.  For other use
cases, KiCad is slower or cannot do things.  For example, because KiCad has
no real concept of a selection set right now (blocks don't really work the
same way, at least the way blocks are implemented now), you can't pick
arbitrary objects and move them together, or align them to each other,
etc.  You can only drag-select to pick a block of all objects inside your
drag rectangle, which often isn't want you want.

I am going to keep working on my proof of concept, and since it will
basically change the selection model of KiCad to be more like other
applications, I will hide this behind a setting in the preferences, so that
people who look at my branch can switch between the old and new behavior
and see which they prefer.

I imagine that if this feature gets accepted into KiCad, it will likely be
a user-selectable option, since it makes big changes to the behavior that
old KiCad users expect.  But, I'm going to advocate for it anyway, because
I think that moving to a user interface that is more similar to most
applications is the right thing to do to increase KiCad user base and
reduce the barrier to people switching from other tools.

Best,
Jon

On Sun, Feb 12, 2017 at 8:13 AM, Kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> Hmm, I am a fan of the selection menu that pops up actually, I would like
> to keep it.
>
> I think that the list can be used simultaneous with the hotkeys and
> autoselection. Just hide it whenever another action is invoked on the item
> that is curently selected in the list.
>
> - Kristoffer
>
> On 2017-02-12 00:16, Jon Evans wrote:
>
>> I was going to add a context menu entry for "next selection", is that
>> obvious enough to you or do you think there should be extra hints?
>>
>> On Feb 11, 2017 18:14, "Chris Pavlina" > <mailto:pavlina.ch...@gmail.com>> wrote:
>>
>> Very nice. I only think it needs to be a bit more obvious how to do
>> it.
>>
>> On Sat, Feb 11, 2017 at 05:49:05PM -0500, Jon Evans wrote:
>> > Proof of concept: https://www.youtube.com/watch?v=JfnXPosOHcY
>> <https://www.youtube.com/watch?v=JfnXPosOHcY>
>> > (when you see the selection changing, I'm hitting the new hotkey I
>> made for
>> > cycling through items)
>> >
>> > On Sat, Feb 11, 2017 at 2:24 PM, Chris Pavlina
>> mailto:pavlina.ch...@gmail.com>>
>>
>> > wrote:
>> >
>>     > > I wish I had thoughts more verbose than "yes" right now... Yeah,
>> this is
>> > > how most tools work, and it's quite intuitive. I would be 100%
>> in favor
>> > > of implementing it this way.
>> > >
>> > > On Sat, Feb 11, 2017 at 02:21:08PM -0500, Jon Evans wrote:
>> > > > Hi all,
>> > > >
>> > > > I had been thinking about proposing this already as a UX
>> enhancement, and
>> > > > then while looking through the starter bugs realized that
>> lp:1154020 [1]
>> > > is
>> > > > actually quite difficult to solve in a nice way due to the
>> popup menu
>> > > used
>> > > > for clarification today, so I decided to send it out now.
>> > > >
>> > > > I propose that we change the selection code to "guess" at the
>> item the
>> > > user
>> > > > wanted to select, and let the user cycle through the set of
>> items that
>> > > are
>> > > >

Re: [Kicad-developers] RFC: Change UX for item selection clarification

[Jon Evans]

Hi John,

I am mainly looking at eeschema right now, so I haven't studied the GAL
code closely yet.  pcbnew's behavior in GAL canvas is certainly better than
legacy and eeschema, but still does some odd things that I want to look
at.  I will have to get familiar with GAL in order to see how my change to
eeschema's behavior would apply once it's ported to using GAL.

The change I've made in my branch doesn't change the behavior you mention
-- if you have nothing selected, hitting a hotkey still searches under the
cursor for something and selects it for the action.  Right now, in my "new
selection mode", it will not prompt you to clarify your selection if you
hit a hotkey while hovering over multiple items -- it will do the action on
the top item.  I need to play with it more to see if this is the best
behavior or whether it makes sense to bring back the popup menu for this
case.  It might make sense to have a popup menu here, because (1) it
doesn't matter that the popup menu breaks double-clicking because you're
using a keyboard hotkey, and (2) ideally you would only hit this scenario
rarely once we have good selection filtering commands, because generally
you will already be in the proper filter mode to (for example) only select
components for moving, etc.

Best,
Jon

On Sun, Feb 12, 2017 at 7:12 PM, John Beard  wrote:

> On Mon, Feb 13, 2017 at 6:39 AM, Jon Evans  wrote:
> >
> > The core of the issue is how KiCad thinks about selection of objects
> > compared to most other software that deals with graphical objects that
> the
> > user interacts with.
> >
> > Most applications have the concept of a "selection set" that contains 0
> or
> > more objects.  You can select one or more objects, and then separately
> from
> > the action of selecting, you can do things to the objects.  KiCad uses a
> > more "immediate" concept of selection -- you select an object at the same
> > time as doing something to it.
>
> Hi Jon,
>
> Are you talking about the GAL canvases, or legacy? The GAL canvases do
> have a concept of the "current selection", which is what is used by
> actions, and the drag selection works a lot like a "normal" graphical
> program like Inkscape, for example.
>
> You can also use Shift-click to add items to a selection, before
> invoking an action.
>
> Invoking an action without a selection often has an additional special
> behaviour - select whatever is currently under the cursor and act on
> that. Generally, you see this in hotkeys, e.g. 'M', and this saves a
> lot of clicking if you only want to deal with one item.
>
> Cheers,
>
> John
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Differential pair DRC Errors

[Jon Evans]

I took a quick look at the DRC code, and it looks like it is doing an
exclusive check on the minimum distances for clearance -- i.e. it is
requiring the clearance be greater than the minimum, not greater or equal.
I'm not familiar enough with this part of the code to want to submit a
patch for this now, but maybe someone who is familiar can comment on
whether there is a reason that it is done this way.

-Jon

On Sun, Feb 12, 2017 at 8:08 PM, Andy Peters  wrote:

>
> > On Feb 12, 2017, at 5:59 PM, Andy Peters  wrote:
> >
> > I am using a nightly build from 26 January 2017 on a Mac.
> >
> > The design has a handful of differential pairs. I have set up design
> rules for most nets in the design as 1.6 mm trace width and 1.6 mm
> clearance. I created a net class for the pairs with those clearances and
> widths and made that the “diff pair width” and “diff pair gap” too.
> >
> > Then I set the “Differential Pair Dimensions” in the Dimensions menu to
> that same width and gap. Aside: why is this step necessary? Why doesn’t the
> differential routing use the net classes set up by default?
> >
> > I route the signals and run the DRC, and for every corner in the trace
> pairs, I get an ErrType(x): “Two Track Ends Too Close” complaint. Sometimes
> it’s ErrType(16), sometimes it’s ErrType(17), the rest ErrType(18), but
> they are for all corners. See the picture. This doesn’t make any sense.
>
> This was reported as a bug over a year ago: https://bugs.launchpad.net/
> kicad/+bug/1533551
> ___
> 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] Differential pair DRC Errors

[Jon Evans]

I verified using Novak's test case on the Launchpad bug report.  DRC error
is generated if the distance between the tracks is exactly equal to the
clearance.
If you increase the spacing by the minimum distance recognized by the
software's precision, the DRC passes.
So, I think it's an issue of DRC specification -- The code currently
requires that the clearance be *larger* than the minimum in the design
rules.
The diff pair router is setting the spacing to the minimum (exactly) which
causes this bug.

IMHO, the DRC code should be changed to "larger or equal to", but I am not
sure if there is some subtle reason why it is implemented this way.
If you tell KiCad that you can go down to 2mm clearance, you should be able
to design something with *exactly* 2mm clearance :-)

-Jon

On Mon, Feb 13, 2017 at 11:15 AM, Andy Peters  wrote:

>
> > On Feb 13, 2017, at 2:06 AM, Clemens Koller  wrote:
> >
> > Hello!
> >
> > If the global minimum mandatory clearance/spacing (pitch) of a design
> (due to manufacturing limitations) is set (& activated) it should complain
> when some other settings are violating that.
>
> I purposely set the differential gap and trace width to something higher
> than the global minimum to see if that would have an effect, and it didn’t.
>
> > It could be assisting if the user gets a clear warning when the
> differential pair dimensions violate the design limitations and then give
> options to
> > a) reset the differential pair dimenstion to the global minumum, which
> is x.
> > b) create an exception for the differential pairs (the DRC need to
> handle that).
> > c) adjust the global design limitations accordingly.
> >
> > If b) or c) is selected, the Ok button should be labelled with "Ok, I
> really know what I do..." ;-).
>
> Differential routing in the GAL canvas with “shove” as the default routing
> mode should result in never having a DRC clearance failure. Let’s expand on
> that — all routing in that mode should never result in a DRC clearance (or
> width) fail. I remember the first time I tried differential routing and it
> wouldn’t let me draw any traces because the default diff width/gap violated
> my global minimums.
>
> So the question is: what is the real source of the error? Is it in the
> routing algorithm that allows the user to place differential traces that
> violate the design rules, or is it, as Jon Evans wrote, an error in the
> post-routing DRC code?
>
> -a
>
> > On 2017-02-13 03:15, Jon Evans wrote:
> >> I took a quick look at the DRC code, and it looks like it is doing an
> exclusive check on the minimum distances for clearance -- i.e. it is
> requiring the clearance be greater than the minimum, not greater or equal.
> >> I'm not familiar enough with this part of the code to want to submit a
> patch for this now, but maybe someone who is familiar can comment on
> whether there is a reason that it is done this way.
> >>
> >> -Jon
> >>
> >> On Sun, Feb 12, 2017 at 8:08 PM, Andy Peters  de...@latke.net>> wrote:
> >>
> >>
> >>> On Feb 12, 2017, at 5:59 PM, Andy Peters  de...@latke.net>> wrote:
> >>>
> >>> I am using a nightly build from 26 January 2017 on a Mac.
> >>>
> >>> The design has a handful of differential pairs. I have set up design
> rules for most nets in the design as 1.6 mm trace width and 1.6 mm
> clearance. I created a net class for the pairs with those clearances and
> widths and made that the “diff pair width” and “diff pair gap” too.
> >>>
> >>> Then I set the “Differential Pair Dimensions” in the Dimensions menu
> to that same width and gap. Aside: why is this step necessary? Why doesn’t
> the differential routing use the net classes set up by default?
> >>>
> >>> I route the signals and run the DRC, and for every corner in the trace
> pairs, I get an ErrType(x): “Two Track Ends Too Close” complaint. Sometimes
> it’s ErrType(16), sometimes it’s ErrType(17), the rest ErrType(18), but
> they are for all corners. See the picture. This doesn’t make any sense.
> >>
> >>This was reported as a bug over a year ago:
> https://bugs.launchpad.net/kicad/+bug/1533551 <https://bugs.launchpad.net/
> kicad/+bug/1533551>
> >>___
> >>Mailing list: https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers>
> >>Post to : kicad-developers@lists.launchpad.net  kicad-developers@lists.launchpad.net>
> >>Unsubscribe : https://launchpad.net/~kicad-developers <
> https://launchpad

Re: [Kicad-developers] OT: Trends in number of on-chip I/Os...

[Jon Evans]

Here are some approaches I know about (some of these available in KiCad
today, some of them not until tomorrow :-)

- Splitting up the part into logical blocks as Mark said

- Depending on user preference / company policy, using component attributes
to map all power and ground pins rather than showing them on the schematic
(i.e. hidden pins)

- Importing symbol pinout from a spreadsheet -- the vendor typically will
provide a spreadsheet (or tool for generating spreadsheet based on how you
choose the alternate functions of pins), and then you import this into your
library tool.

- Some tools can even generate the symbols from a spreadsheet (you just
have a column in the spreadsheet that assigns the pins to a logical block,
and each block gets a symbol generated)

- High-end EDA tools usually have DRC rules for checking that you have
appropriate number of bypass capacitors for the power pins, and that they
are located close enough to the power pins.

- When it comes time to do the layout, with large BGAs, some tools have
nice ways to break them up into zones and apply different fan-out behavior
based on the zone, to maximize the escape pathways (and thereby minimize
the number of layers needed for fan-out):  See page 167 of this somewhat
interesting book:
http://www.aetpcb.com/aet/net_resources/help/BGA_Breakouts_and_Routing.pdf

Food for thought...

-Jon

On Tue, Feb 14, 2017 at 9:20 AM, Mark Roszko  wrote:

> You split up the one part into multiple blocks with common
> functionality grouped the same way you may have a U9A and U9B of a
> logic IC with two gates. You'll just use quite a few pages
>
> ___
> 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] GerbView GAL port

[Jon Evans]

Hi all,

I want to get familiar with the GAL codebase, and it occurred to me that it
might be fun to play with porting GerbView to GAL.  I know it is on the 6.x
roadmap, but it seemed to me that it would be mostly not dependent on any
other changes that I see on the roadmap or have seen people talking about
on the mailing list.

- Is anyone currently working on this?

- Does anyone think it would be a bad idea for me to start working on this
now?

- If a GAL port is "feature-complete", is there any reason for the app to
retain the legacy graphics code, or can it just provide OpenGL and Cairo
backends?  My impression is the only think keeping legacy canvas in pcbnew
is feature differences between legacy and GAL, but I wanted to check if
there are other reasons.

- In my first hour of looking at the code for this, it seems like the GAL
code currently has some interdependence with pcbnew that needs to be
straightened out before using GAL in other applications.  For example,
EDA_DRAW_PANEL_GAL depends on PCB_PAINTER, not a generic PAINTER.  Is this
an open problem for anyone to tackle, or does anyone actively have plans to
refactor this?

Best,
Jon
___
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] GerbView GAL port

[Jon Evans]

Hi all, thanks for the feedback.

Jon -- I will reach out to Mark and see what his plans are/were.

JP -- Thanks for the explanation

Tom -- Thanks for the explanation.  I agree it's a good idea to look into
Cairo for printing.

Yes, I should be able to fix the issue with PAINTER.

-Jon

On Wed, Feb 15, 2017 at 3:44 AM, Tomasz Wlostowski <
tomasz.wlostow...@cern.ch> wrote:

> On 14.02.2017 19:38, Jon Evans wrote:
> > Hi all,
> >
> > I want to get familiar with the GAL codebase, and it occurred to me that
> > it might be fun to play with porting GerbView to GAL.  I know it is on
> > the 6.x roadmap, but it seemed to me that it would be mostly not
> > dependent on any other changes that I see on the roadmap or have seen
> > people talking about on the mailing list.
> >
> Hi Jon,
>
> Many thanks for your involvement. I think working on a GAL port of
> GerbView is a great idea, even though it's not planned (yet) for the
> nearest release.
>
> > - Is anyone currently working on this?
>
> I don't think so.
>
> >
> > - If a GAL port is "feature-complete", is there any reason for the app
> > to retain the legacy graphics code, or can it just provide OpenGL and
> > Cairo backends?  My impression is the only think keeping legacy canvas
> > in pcbnew is feature differences between legacy and GAL, but I wanted to
> > check if there are other reasons.
>
> Except for printing mentioned by JP, there's no reason to keep legacy
> drawing code. I'm quite sure, though, printing could be handled by
> GAL-Cairo with some minor modifications.
>
> >
> > - In my first hour of looking at the code for this, it seems like the
> > GAL code currently has some interdependence with pcbnew that needs to be
> > straightened out before using GAL in other applications.  For example,
> > EDA_DRAW_PANEL_GAL depends on PCB_PAINTER, not a generic PAINTER.  Is
> > this an open problem for anyone to tackle, or does anyone actively have
> > plans to refactor this?
>
> It's an obvious mistake, EDA_DRAW_PANEL_GAL should depend on the base
> PAINTER class, and the PCB_PAINTER should be created in the
> PCB_DRAW_PANEL_GAL. Would you be able to fix this?
>
> Cheers,
> Tom
>
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] Setup PCB painter in the PCB draw class rather than the base class

[Jon Evans]

Hi all,

Patch attached for the issue I mentioned in the GerbView thread.
This will allow creation of other derived classes of EDA_DRAW_PANEL_GAL.

Best,
Jon
From c0b68d55bac543cdd10cffe9a82650c6d2259349 Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Wed, 15 Feb 2017 21:06:05 -0500
Subject: [PATCH] Setup painter in PCB_DRAW_PANEL_GAL instead of
 EDA_DRAW_PANEL_GAL

---
 common/draw_panel_gal.cpp | 6 ++
 pcbnew/pcb_draw_panel_gal.cpp | 4 
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/common/draw_panel_gal.cpp b/common/draw_panel_gal.cpp
index 614a068..e14181d 100644
--- a/common/draw_panel_gal.cpp
+++ b/common/draw_panel_gal.cpp
@@ -73,10 +73,7 @@ EDA_DRAW_PANEL_GAL::EDA_DRAW_PANEL_GAL( wxWindow* aParentWindow, wxWindowID aWin
 #endif
 EnableScrolling( false, false );// otherwise Zoom Auto disables GAL canvas
 
-m_painter = new KIGFX::PCB_PAINTER( m_gal );
-
 m_view = new KIGFX::VIEW( true );
-m_view->SetPainter( m_painter );
 m_view->SetGAL( m_gal );
 
 Connect( wxEVT_SIZE, wxSizeEventHandler( EDA_DRAW_PANEL_GAL::onSize ), NULL, this );
@@ -131,7 +128,6 @@ EDA_DRAW_PANEL_GAL::~EDA_DRAW_PANEL_GAL()
 
 assert( !m_drawing );
 
-delete m_painter;
 delete m_viewControls;
 delete m_view;
 delete m_gal;
@@ -165,6 +161,8 @@ void EDA_DRAW_PANEL_GAL::onPaint( wxPaintEvent& WXUNUSED( aEvent ) )
 PROF_COUNTER totalRealTime;
 #endif /* PROFILE */
 
+wxASSERT( m_painter );
+
 m_drawing = true;
 KIGFX::PCB_RENDER_SETTINGS* settings = static_cast( m_painter->GetSettings() );
 
diff --git a/pcbnew/pcb_draw_panel_gal.cpp b/pcbnew/pcb_draw_panel_gal.cpp
index 422a5a4..efa3dd9 100644
--- a/pcbnew/pcb_draw_panel_gal.cpp
+++ b/pcbnew/pcb_draw_panel_gal.cpp
@@ -107,6 +107,9 @@ EDA_DRAW_PANEL_GAL( aParentWindow, aWindowId, aPosition, aSize, aOptions, aGalTy
 setDefaultLayerOrder();
 setDefaultLayerDeps();
 
+m_painter = new KIGFX::PCB_PAINTER( m_gal );
+m_view->SetPainter( m_painter );
+
 // Load display options (such as filled/outline display of items).
 // Can be made only if the parent window is an EDA_DRAW_FRAME (or a derived class)
 // which is not always the case (namely when it is used from a wxDialog like the pad editor)
@@ -122,6 +125,7 @@ EDA_DRAW_PANEL_GAL( aParentWindow, aWindowId, aPosition, aSize, aOptions, aGalTy
 
 PCB_DRAW_PANEL_GAL::~PCB_DRAW_PANEL_GAL()
 {
+delete m_painter;
 delete m_worksheet;
 delete m_ratsnest;
 }
-- 
2.7.4

___
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] Move layer color settings from child class to base class RENDER_SETTINGS

[Jon Evans]

Hi all,

This patch follows up on the one I sent earlier, to finish removing
dependency on pcbnew for the GAL draw panel.  Since layer color settings
will be useful in other applications, I moved them from PCB_RENDER_SETTINGS
up to RENDER_SETTINGS.  I left GetColor() in the pcb class for now, but if
I make progress on enabling GAL in GerbView it might become more obvious
how that should be refactored into the base class.

Best,
Jon
From 7122ee9236d230bdd49bb40cabca166b1b15347c Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Wed, 15 Feb 2017 22:26:03 -0500
Subject: [PATCH] Move layer colors from PCB_RENDER_SETTINGS to
 RENDER_SETTINGS

---
 common/draw_panel_gal.cpp |  6 ++
 common/painter.cpp|  8 
 include/painter.h | 36 
 pcbnew/pcb_painter.cpp| 14 --
 pcbnew/pcb_painter.h  | 39 ---
 5 files changed, 46 insertions(+), 57 deletions(-)

diff --git a/common/draw_panel_gal.cpp b/common/draw_panel_gal.cpp
index e14181d..69002a6 100644
--- a/common/draw_panel_gal.cpp
+++ b/common/draw_panel_gal.cpp
@@ -30,7 +30,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 

 #include 
 #include 
@@ -39,8 +39,6 @@
 #include 
 #include 

-#include   // display options definition
-
 #ifdef PROFILE
 #include 
 #endif /* PROFILE */
@@ -164,7 +162,7 @@ void EDA_DRAW_PANEL_GAL::onPaint( wxPaintEvent& WXUNUSED( aEvent ) )
 wxASSERT( m_painter );

 m_drawing = true;
-KIGFX::PCB_RENDER_SETTINGS* settings = static_cast( m_painter->GetSettings() );
+KIGFX::RENDER_SETTINGS* settings = static_cast( m_painter->GetSettings() );

 // Scrollbars broken in GAL on OSX
 #ifndef __WXMAC__
diff --git a/common/painter.cpp b/common/painter.cpp
index 0d6b1f0..60d6614 100644
--- a/common/painter.cpp
+++ b/common/painter.cpp
@@ -62,6 +62,14 @@ void RENDER_SETTINGS::update()
 {
 m_hiContrastColor = COLOR4D( m_hiContrastFactor, m_hiContrastFactor, m_hiContrastFactor,
  m_layerOpacity );
+
+// Calculate darkened/highlighted variants of layer colors
+for( int i = 0; i < TOTAL_LAYER_COUNT; i++ )
+{
+m_layerColorsHi[i]   = m_layerColors[i].Brightened( m_highlightFactor );
+m_layerColorsDark[i] = m_layerColors[i].Darkened( 1.0 - m_highlightFactor );
+m_layerColorsSel[i]  = m_layerColors[i].Brightened( m_selectFactor );
+}
 }


diff --git a/include/painter.h b/include/painter.h
index cf586fa..cf6cefc 100644
--- a/include/painter.h
+++ b/include/painter.h
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 class EDA_ITEM;
@@ -207,6 +208,29 @@ public:
 m_backgroundColor = aColor;
 }

+/**
+ * Function GetLayerColor
+ * Returns the color used to draw a layer.
+ * @param aLayer is the layer number.
+ */
+inline const COLOR4D& GetLayerColor( int aLayer ) const
+{
+return m_layerColors[aLayer];
+}
+
+/**
+ * Function SetLayerColor
+ * Changes the color used to draw a layer.
+ * @param aLayer is the layer number.
+ * @param aColor is the new color.
+ */
+inline void SetLayerColor( int aLayer, const COLOR4D& aColor )
+{
+m_layerColors[aLayer] = aColor;
+
+update();   // recompute other shades of the color
+}
+
 protected:
 /**
  * Function update
@@ -217,6 +241,18 @@ protected:

 std::set m_activeLayers; ///< Stores active layers number

+///> Colors for all layers (normal)
+COLOR4D m_layerColors[TOTAL_LAYER_COUNT];
+
+///> Colors for all layers (highlighted)
+COLOR4D m_layerColorsHi[TOTAL_LAYER_COUNT];
+
+///> Colors for all layers (selected)
+COLOR4D m_layerColorsSel[TOTAL_LAYER_COUNT];
+
+///> Colors for all layers (darkened)
+COLOR4D m_layerColorsDark[TOTAL_LAYER_COUNT];
+
 /// Parameters for display modes
 boolm_hiContrastEnabled;///< High contrast display mode on/off
 COLOR4D m_hiContrastColor;  ///< Color used for high contrast display mode
diff --git a/pcbnew/pcb_painter.cpp b/pcbnew/pcb_painter.cpp
index 94bae89..2206052 100644
--- a/pcbnew/pcb_painter.cpp
+++ b/pcbnew/pcb_painter.cpp
@@ -225,20 +225,6 @@ const COLOR4D& PCB_RENDER_SETTINGS::GetColor( const VIEW_ITEM* aItem, int aLayer
 }


-void PCB_RENDER_SETTINGS::update()
-{
-RENDER_SETTINGS::update();
-
-// Calculate darkened/highlighted variants of layer colors
-for( int i = 0; i < TOTAL_LAYER_COUNT; i++ )
-{
-m_layerColorsHi[i]   = m_layerColors[i].Brightened( m_highlightFactor );
-m_layerColorsDark[i] = m_layerColors[i].Darkened( 1.0 - m_highlightFactor );
-m_layerColorsSel[i]  = m_layerColors[i].Brightened( m_selectFactor );
-}
-}
-
-
 PCB_PAINTER::PCB_PAINTER( GAL* aGal ) :
 PAINTER( aGal )
 {
diff --git a/pcbnew/pcb_painter.h b/pcbnew/pcb_painter.h
index 718f619..25235fb 100644
--- 

Re: [Kicad-developers] [PATCH] Move layer color settings from child class to base class RENDER_SETTINGS

[Jon Evans]

Thanks Orson!

Actually the weird patch numbers were due to a mistake in my git
format-patch command, so nothing too mysterious :-)  But I will have some
things coming up for sure...

Best,
Jon

On Thu, Feb 16, 2017 at 11:41 AM, Maciej Sumiński 
wrote:

> Hi Jon,
>
> I have just pushed your both patches. Now you made me curious what else
> is there between 0001-Setup-painter and 0006-Move-layer-colors. Thank
> you very much!
>
> Regards,
> Orson
>
> On 02/16/2017 04:30 AM, Jon Evans wrote:
> > Hi all,
> >
> > This patch follows up on the one I sent earlier, to finish removing
> > dependency on pcbnew for the GAL draw panel.  Since layer color settings
> > will be useful in other applications, I moved them from
> PCB_RENDER_SETTINGS
> > up to RENDER_SETTINGS.  I left GetColor() in the pcb class for now, but
> if
> > I make progress on enabling GAL in GerbView it might become more obvious
> > how that should be refactored into the base class.
> >
> > Best,
> > Jon
> >
> >
> >
> > ___
> > 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] Remove dependence on LAYER_ID from EDA_DRAW_PANEL_GAL

[Jon Evans]

Hi all,

Another refactoring of the GAL base classes, this time to not depend on
LAYER_ID, which is specific to pcbnew.

Best,
Jon
From 3862fa138b5b60204617cc065e972857fd2fd1b9 Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Thu, 16 Feb 2017 19:59:31 -0500
Subject: [PATCH] Remove dependence on LAYER_ID from EDA_DRAW_PANEL_GAL

---
 common/draw_panel_gal.cpp  |  4 ++--
 include/class_draw_panel_gal.h |  5 ++---
 pcbnew/pcb_draw_panel_gal.h| 17 +++--
 3 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/common/draw_panel_gal.cpp b/common/draw_panel_gal.cpp
index 69002a6..98c1b00 100644
--- a/common/draw_panel_gal.cpp
+++ b/common/draw_panel_gal.cpp
@@ -302,7 +302,7 @@ void EDA_DRAW_PANEL_GAL::StopDrawing()
 }
 
 
-void EDA_DRAW_PANEL_GAL::SetHighContrastLayer( LAYER_ID aLayer )
+void EDA_DRAW_PANEL_GAL::SetHighContrastLayer( int aLayer )
 {
 // Set display settings for high contrast mode
 KIGFX::RENDER_SETTINGS* rSettings = m_view->GetPainter()->GetSettings();
@@ -316,7 +316,7 @@ void EDA_DRAW_PANEL_GAL::SetHighContrastLayer( LAYER_ID aLayer )
 }
 
 
-void EDA_DRAW_PANEL_GAL::SetTopLayer( LAYER_ID aLayer )
+void EDA_DRAW_PANEL_GAL::SetTopLayer( int aLayer )
 {
 m_view->ClearTopLayers();
 m_view->SetTopLayer( aLayer );
diff --git a/include/class_draw_panel_gal.h b/include/class_draw_panel_gal.h
index f1828b8..13e7671 100644
--- a/include/class_draw_panel_gal.h
+++ b/include/class_draw_panel_gal.h
@@ -33,7 +33,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -150,13 +149,13 @@ public:
  * Function SetHighContrastLayer
  * Takes care of display settings for the given layer to be displayed in high contrast mode.
  */
-virtual void SetHighContrastLayer( LAYER_ID aLayer );
+virtual void SetHighContrastLayer( int aLayer );
 
 /**
  * Function SetTopLayer
  * Moves the selected layer to the top, so it is displayed above all others.
  */
-virtual void SetTopLayer( LAYER_ID aLayer );
+virtual void SetTopLayer( int aLayer );
 
 virtual void GetMsgPanelInfo( std::vector& aList )
 {
diff --git a/pcbnew/pcb_draw_panel_gal.h b/pcbnew/pcb_draw_panel_gal.h
index 6e1f724..db84a47 100644
--- a/pcbnew/pcb_draw_panel_gal.h
+++ b/pcbnew/pcb_draw_panel_gal.h
@@ -26,6 +26,7 @@
 #define PCB_DRAW_PANEL_GAL_H_
 
 #include 
+#include 
 
 namespace KIGFX
 {
@@ -66,10 +67,22 @@ public:
 void UseColorScheme( const COLORS_DESIGN_SETTINGS* aSettings );
 
 ///> @copydoc EDA_DRAW_PANEL_GAL::SetHighContrastLayer()
-virtual void SetHighContrastLayer( LAYER_ID aLayer ) override;
+virtual void SetHighContrastLayer( int aLayer ) override
+{
+SetHighContrastLayer( static_cast< LAYER_ID >( aLayer ) );
+}
+
+///> SetHighContrastLayer(), with some extra smarts for PCB
+void SetHighContrastLayer( LAYER_ID aLayer );
 
 ///> @copydoc EDA_DRAW_PANEL_GAL::SetTopLayer()
-virtual void SetTopLayer( LAYER_ID aLayer ) override;
+virtual void SetTopLayer( int aLayer ) override
+{
+SetTopLayer( static_cast< LAYER_ID >( aLayer ) );
+}
+
+///> SetTopLayer(), with some extra smarts for PCB
+void SetTopLayer( LAYER_ID aLayer );
 
 /**
  * Function SyncLayersVisibility
-- 
2.7.4

___
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] Future of GitHub libraries

[Jon Evans]

Hi Clemens, just wanted to give another perspective that goes against your
last line -- Just wanted to say that some of us are very happy to use SCM
daily.

At my workplace, we use Git to store electronics designs and
symbol/footprint libraries.  It started with the electronics people who
also do software (and so already knew how to use Git) and spread to the
rest of the electronics people, who find it easy to use despite not being
familiar with software version control.  It works really well despite not
being integrated into the tools we use.

In my opinion, one important part of the data storage technology is to have
a "diff" viewer for EDA data.  Most of the commercial vendors provide
something, although the quality and ease of use vary.  But, if you can use
a special tool to compare two revisions of a symbol, or footprint, or
schematic, or PCB, then using Git as the underlying revision control
mechanism works really well.

This is why making a diff viewer for KiCad data is on my (long) list of
"things that would take KiCad closer to the high-end commercial tools" that
maybe one day I will have a chance to work on -- I have seen some people
talking about this feature request on forums, but as far as I can tell, no
one has made a proof of concept yet.

(Of course, if you have already created Gerber files, there are ways to do
it)
https://github.com/madworm/KiCad-Stuff/tree/master/scripts/visual-diffs_on_gerber-files
You can see in the README how this can be used directly from Git

Best,
Jon

On Sat, Feb 18, 2017 at 8:31 AM, Clemens Koller  wrote:

> Hi, Andy!
>
> On 2017-02-17 19:51, Andy Peters wrote:
> >> On Feb 17, 2017, at 8:31 AM, Clemens Koller  wrote:
> >> And: In the long-term we might also think about using git for project
> and design management and versioning. (We could even store undo's and
> redo's in git?)
> >
> > Except that not everyone likes or uses git. I use Subversion for my
> projects.
>
> Sure. That's why people created git svn...
> Sometimes it just might be sufficient to consider that there are already
> some solutions out there.
>
> But as others suggested already:
> Nobody should need to mess with an scm tool on a daily basis when doing
> electronics design.
> It should be wrapped nicely behind the frontends.
>
> Regards,
>
> Clemens
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Change from EDA_COLOR_T to COLOR4D and arbitrary color support

[Jon Evans]

Hi all,

Attached is a follow-up patch to the COLOR4D change above -- I reverted
from using wxColourPickerCtrl back to wxBitmapButton in the eeschema color
config, because I finally got my Windows 10 testing environment set up, and
found out that for some reason wxColourPickerCtrl looks really ugly in
Windows 10.

Best,
Jon

On Fri, Feb 10, 2017 at 8:43 PM, Jon Evans  wrote:

> Hi all,
>
> Attached is a (rather large!) patch that changes the internal color
> representation to COLOR4D across the codebase (except for places that
> directly deal with wx, where wxColour is used).
>
> This patch also enables arbitrary color selection for schematic and symbol
> library editor, as well as pcbnew in the GAL canvas.  GerbView and pcbnew
> legacy canvas still use the old color picker.  Colors will be coerced into
> the legacy palette when switching from GAL to legacy, in a way that tries
> to preserve the hue and value.
>
> Colors are serialized to the settings in CSS format, because it supports
> alpha and represents color components the same way COLOR4D does (as
> floating-point values from 0 to 1)
>
> Tested on Linux.  Can't test on Windows or Mac yet, sorry.
> I realize this is a large changeset and might take a while to review, so
> just ping me if it stops applying on master and I'll update it.
>
> Best,
> Jon
>


0002-Revert-from-wxColourPickerCtrl-to-wxBitmapButton.patch
Description: Binary data
___
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] Refactor COMMON_ACTIONS into a base and derived class

[Jon Evans]

Hi Orson,

I can definitely pull the pcb_actions into their respective files, I will
do that and send another patch.

Best,
Jon

On Mon, Feb 20, 2017 at 4:25 AM, John Beard  wrote:

> HI Orson,
>
> I think that sounds like a sensible idea. Having a huge central list
> of actions has a bit of a code smell for me, as it's a big header than
> then needs including everywhere. Smaller lists that are included along
> with their tool's headers (if needed), or even actions that are
> totally hidden in implementations for when the action only works
> during an interactive tool feels much nicer.
>
> The file now called common_actions.cpp (maybe pcb_actions.cpp or
> something in future) would need to include most of these headers so it
> can still map legacy event IDs, but that's how it should be - a file
> that needs lots, includes lots.
>
> Cheers,
>
> John
>
>
> On Mon, Feb 20, 2017 at 4:58 PM, Maciej Sumiński
>  wrote:
> > Hi Jon,
> >
> > I see the point of your patch, as COMMON_ACTIONS are now a bit misused.
> > They should not keep majority of the TOOL_ACTIONs, as many of them are
> > pcbnew specific, but there are still actions that will be shared with
> > other applications (e.g. zoom & grid control, move/rotate/flip).
> >
> > For some time I was also wondering whether it would not be better to
> > move the actions to their corresponding tools, as is done e.g. in
> > pcbnew/router/router_tool.cpp (ACT_* objects), and leave only truly
> > generic actions in {COMMON,PCB}_ACTIONS.
> >
> > What do you think about splitting the current set to PCB_ACTIONS and
> > COMMON_ACTIONS, perhaps moving some of them to the tools source files?
> >
> > Regards,
> > Orson
> >
> > On 02/17/2017 04:56 AM, Jon Evans wrote:
> >> Hi all,
> >>
> >> More preparation for GerbView GAL port: this patch pulls a virtual
> ACTIONS
> >> class out of pcbnew and renames the COMMON_ACTIONS to PCB_ACTIONS for
> >> clarity.
> >>
> >> Best,
> >> Jon
> >>
> >>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Change from EDA_COLOR_T to COLOR4D and arbitrary color support

[Jon Evans]

Thanks Orson, no I don't mind changing to static consts!

Best,
Jon

On Mon, Feb 20, 2017 at 12:50 PM, Maciej Sumiński 
wrote:

> Hi Jon,
>
> I have just tested the patch, and I really like it. I just need to test
> it a bit longer, as there are numerous changes, but I am in favor of
> merging the patch.
>
> I also applied one more patch changing a few defines (UNSPECIFIED,
> BLACK, WHITE) to static consts, I hope you do not mind.
>
> If there are other people interested in testing, I have rebased the
> changes [1] on the current master. There are also a few minor code
> formatting fixes.
>
> Regards,
> Orson
>
> 1. https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+ref/colors
>
> On 02/18/2017 09:24 PM, Jon Evans wrote:
> > Hi all,
> >
> > Attached is a follow-up patch to the COLOR4D change above -- I reverted
> > from using wxColourPickerCtrl back to wxBitmapButton in the eeschema
> color
> > config, because I finally got my Windows 10 testing environment set up,
> and
> > found out that for some reason wxColourPickerCtrl looks really ugly in
> > Windows 10.
> >
> > Best,
> > Jon
> >
> > On Fri, Feb 10, 2017 at 8:43 PM, Jon Evans  wrote:
> >
> >> Hi all,
> >>
> >> Attached is a (rather large!) patch that changes the internal color
> >> representation to COLOR4D across the codebase (except for places that
> >> directly deal with wx, where wxColour is used).
> >>
> >> This patch also enables arbitrary color selection for schematic and
> symbol
> >> library editor, as well as pcbnew in the GAL canvas.  GerbView and
> pcbnew
> >> legacy canvas still use the old color picker.  Colors will be coerced
> into
> >> the legacy palette when switching from GAL to legacy, in a way that
> tries
> >> to preserve the hue and value.
> >>
> >> Colors are serialized to the settings in CSS format, because it supports
> >> alpha and represents color components the same way COLOR4D does (as
> >> floating-point values from 0 to 1)
> >>
> >> Tested on Linux.  Can't test on Windows or Mac yet, sorry.
> >> I realize this is a large changeset and might take a while to review, so
> >> just ping me if it stops applying on master and I'll update it.
> >>
> >> Best,
> >> Jon
> >>
> >
> >
> >
> > ___
> > 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] [PATCH] Refactor COMMON_ACTIONS into a base and derived class

[Jon Evans]

Hi Orson,

I've attached a follow-up patch that moves all TOOL_ACTIONs out of
pcb_actions.cpp and creates a COMMON_TOOLS class for storing
cross-application tools.  I was not able to move all zoom/grid tools
because of dependencies on pcbnew that need to be resolved -- I did not
want to take on the refactoring needed to fix this in this patch, but I
plan on looking at it in the near future.

Best,
Jon

On Mon, Feb 20, 2017 at 11:13 AM, Maciej Sumiński 
wrote:

> Thank you John, we really appreciate your efforts.
>
> Regards,
> Orson
>
> On 02/20/2017 03:50 PM, Jon Evans wrote:
> > Hi Orson,
> >
> > I can definitely pull the pcb_actions into their respective files, I will
> > do that and send another patch.
> >
> > Best,
> > Jon
> >
> > On Mon, Feb 20, 2017 at 4:25 AM, John Beard 
> wrote:
> >
> >> HI Orson,
> >>
> >> I think that sounds like a sensible idea. Having a huge central list
> >> of actions has a bit of a code smell for me, as it's a big header than
> >> then needs including everywhere. Smaller lists that are included along
> >> with their tool's headers (if needed), or even actions that are
> >> totally hidden in implementations for when the action only works
> >> during an interactive tool feels much nicer.
> >>
> >> The file now called common_actions.cpp (maybe pcb_actions.cpp or
> >> something in future) would need to include most of these headers so it
> >> can still map legacy event IDs, but that's how it should be - a file
> >> that needs lots, includes lots.
> >>
> >> Cheers,
> >>
> >> John
> >>
> >>
> >> On Mon, Feb 20, 2017 at 4:58 PM, Maciej Sumiński
> >>  wrote:
> >>> Hi Jon,
> >>>
> >>> I see the point of your patch, as COMMON_ACTIONS are now a bit misused.
> >>> They should not keep majority of the TOOL_ACTIONs, as many of them are
> >>> pcbnew specific, but there are still actions that will be shared with
> >>> other applications (e.g. zoom & grid control, move/rotate/flip).
> >>>
> >>> For some time I was also wondering whether it would not be better to
> >>> move the actions to their corresponding tools, as is done e.g. in
> >>> pcbnew/router/router_tool.cpp (ACT_* objects), and leave only truly
> >>> generic actions in {COMMON,PCB}_ACTIONS.
> >>>
> >>> What do you think about splitting the current set to PCB_ACTIONS and
> >>> COMMON_ACTIONS, perhaps moving some of them to the tools source files?
> >>>
> >>> Regards,
> >>> Orson
> >>>
> >>> On 02/17/2017 04:56 AM, Jon Evans wrote:
> >>>> Hi all,
> >>>>
> >>>> More preparation for GerbView GAL port: this patch pulls a virtual
> >> ACTIONS
> >>>> class out of pcbnew and renames the COMMON_ACTIONS to PCB_ACTIONS for
> >>>> clarity.
> >>>>
> >>>> Best,
> >>>> Jon
> >>>>
> >>>>
> >>>>
> >>>> ___
> >>>> Mailing list: https://launchpad.net/~kicad-developers
> >>>> Post to : kicad-developers@lists.launchpad.net
> >>>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>>> More help   : https://help.launchpad.net/ListHelp
> >>>>
> >>>
> >>>
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> Post to : kicad-developers@lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> >>>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >
>
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Refactor COMMON_ACTIONS into a base and derived class

[Jon Evans]

This time with the patch attached :)

On Mon, Feb 20, 2017 at 1:12 PM, Jon Evans  wrote:

> Hi Orson,
>
> I've attached a follow-up patch that moves all TOOL_ACTIONs out of
> pcb_actions.cpp and creates a COMMON_TOOLS class for storing
> cross-application tools.  I was not able to move all zoom/grid tools
> because of dependencies on pcbnew that need to be resolved -- I did not
> want to take on the refactoring needed to fix this in this patch, but I
> plan on looking at it in the near future.
>
> Best,
> Jon
>
> On Mon, Feb 20, 2017 at 11:13 AM, Maciej Sumiński  > wrote:
>
>> Thank you John, we really appreciate your efforts.
>>
>> Regards,
>> Orson
>>
>> On 02/20/2017 03:50 PM, Jon Evans wrote:
>> > Hi Orson,
>> >
>> > I can definitely pull the pcb_actions into their respective files, I
>> will
>> > do that and send another patch.
>> >
>> > Best,
>> > Jon
>> >
>> > On Mon, Feb 20, 2017 at 4:25 AM, John Beard 
>> wrote:
>> >
>> >> HI Orson,
>> >>
>> >> I think that sounds like a sensible idea. Having a huge central list
>> >> of actions has a bit of a code smell for me, as it's a big header than
>> >> then needs including everywhere. Smaller lists that are included along
>> >> with their tool's headers (if needed), or even actions that are
>> >> totally hidden in implementations for when the action only works
>> >> during an interactive tool feels much nicer.
>> >>
>> >> The file now called common_actions.cpp (maybe pcb_actions.cpp or
>> >> something in future) would need to include most of these headers so it
>> >> can still map legacy event IDs, but that's how it should be - a file
>> >> that needs lots, includes lots.
>> >>
>> >> Cheers,
>> >>
>> >> John
>> >>
>> >>
>> >> On Mon, Feb 20, 2017 at 4:58 PM, Maciej Sumiński
>> >>  wrote:
>> >>> Hi Jon,
>> >>>
>> >>> I see the point of your patch, as COMMON_ACTIONS are now a bit
>> misused.
>> >>> They should not keep majority of the TOOL_ACTIONs, as many of them are
>> >>> pcbnew specific, but there are still actions that will be shared with
>> >>> other applications (e.g. zoom & grid control, move/rotate/flip).
>> >>>
>> >>> For some time I was also wondering whether it would not be better to
>> >>> move the actions to their corresponding tools, as is done e.g. in
>> >>> pcbnew/router/router_tool.cpp (ACT_* objects), and leave only truly
>> >>> generic actions in {COMMON,PCB}_ACTIONS.
>> >>>
>> >>> What do you think about splitting the current set to PCB_ACTIONS and
>> >>> COMMON_ACTIONS, perhaps moving some of them to the tools source files?
>> >>>
>> >>> Regards,
>> >>> Orson
>> >>>
>> >>> On 02/17/2017 04:56 AM, Jon Evans wrote:
>> >>>> Hi all,
>> >>>>
>> >>>> More preparation for GerbView GAL port: this patch pulls a virtual
>> >> ACTIONS
>> >>>> class out of pcbnew and renames the COMMON_ACTIONS to PCB_ACTIONS for
>> >>>> clarity.
>> >>>>
>> >>>> Best,
>> >>>> Jon
>> >>>>
>> >>>>
>> >>>>
>> >>>> ___________
>> >>>> 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://launch

Re: [Kicad-developers] [PATCH] Fix layer color swatches in Linux

[Jon Evans]

FWIW, this is what my expecations were as a new user when I started with
KiCad (for what would happen with a single left-click) based on how things
work in other applications with layer managers I have used (ECAD, graphics,
etc):

http://i.imgur.com/Euh2Gjwl.png

-Jon

On Tue, Feb 21, 2017 at 12:04 PM, Chris Pavlina 
wrote:

> By the way.
>
> https://forum.kicad.info/t/developer-feedback-poll-layer-manager/5421
>
> Feel free to add your own responses. The results look pretty conclusive
> right now ;)
>
> On Tue, Feb 21, 2017 at 11:40:05AM -0500, Chris Pavlina wrote:
> > Sent to wrong recipient.
> >
> > On Tue, Feb 21, 2017 at 11:38:43AM -0500, Chris Pavlina wrote:
> > > On Tue, Feb 21, 2017 at 05:24:14PM +0100, jp charras wrote:
> > > > Le 21/02/2017 à 16:07, Chris Pavlina a écrit :
> > > > > On Tue, Feb 21, 2017 at 09:35:34AM -0500, Wayne Stambaugh wrote:
> > > > >> My only issue with this change is that the tooltip letting the
> user know
> > > > >> that a left button double click or a middle button click would
> allow
> > > > >> them to change the color is gone.  Other than that, it looks
> great.  I
> > > > >> like the use of Bind instead of Connect.  Bind has a much cleaner
> > > > >> interface than Connect and according to the wx folks is the
> proper way
> > > > >> to handle events.
> > > > >
> > > > > The tooltip is useless, nobody is going to hover over them for long
> > > > > enough to see it. I was just talking to someone this morning who
> never
> > > > > found the tooltip because he was too busy clicking on the buttons
> to
> > > > > make them work.
> > > > >
> > > > > Every other color well in every other application opens its
> selection
> > > > > dialog with a single left click. Why can't ours?
> > > >
> > > > First you have to decide if the main purpose is to select the active
> layer or to change the color layer.
> > > > The answer will give also the answer to "Why can't ours".
> > > >
> > > > For me the answer is not obvious, but my opinion is:
> > > > the primary purpose of the layer manager is to select the working
> layer.
> > > > Therefore the single left click should change the layer, whatever
> you are clicking.
> > > >
> > > > If the primary purpose of the layer manager is to select the color,
> then a single left click should
> > > > open the color dialog.
> > >
> > > This isn't "the layer manager", it's a color well IN the layer manager.
> > >
> > > >
> > > > If the single left click opens the dialog, be sure many times, when
> clicking inside the layer
> > > > manager, you will open the dialog, instead of changing the active
> layer, especially if you are too
> > > > busy clicking on the window to verify the exact position of the
> mouse.
> > > > (It frequently happened to me when the single click was opening the
> dialog)
> > > >
> > > > A wise decision is never obvious.
> > > > (A reason like "other applications do that" is not necessary a good
> reason.
> > > > Each application has its constraints and its compromises)
> > >
> > > YES IT IS. Consistency is the single most important way to make an
> > > interface understandable. A box containing a color is a color well, and
> > > color wells behave the exact same way in everything that isn't kicad.
> > >
> > > Next you'll tell me "File->Open opening a file in other applications is
> > > not a good reason it shouldn't display a photo of a llama in KiCad".
> > >
> > > >
> > > > >
> > > > >>
> > > > >> On 2/21/2017 8:04 AM, John Beard wrote:
> > > > >>> Hi,
> > > > >>>
> > > > >>> These patches fix the layer/render widget swatches in Linux
> under new
> > > > >>> GTK+ toolkits. Fix for: https://bugs.launchpad.net/
> kicad/+bug/1605411
> > > > >>>
> > > > >>> The patches remove the "button" nature of the swatches, since
> they
> > > > >>> weren't actually actuated by a single click, so the button
> affordance
> > > > >>> was misleading anyway. Also on OSX, the button was invisible, so
> it
> > > > >>> just looked like a flat swatch anyway.
> > > > >>>
> > > > >>> * Linux as it was:
> > > > >>> https://drive.google.com/file/d/0BxVhl5qZbpYoZlZPeXV1Q0ttT2s/
> view
> > > > >>> * OSX as it was:
> > > > >>> https://launchpadlibrarian.net/274428737/Screen%20Shot%
> 202016-07-22%20at%2019.40.14.png
> > > > >>> * Linux after this patch: see attachment
> > > > >>>
> > > > >>> This is followed by a refactor to pull the swatch logic out of
> the
> > > > >>> layer widget into common, where it can be used by other clients,
> for
> > > > >>> example the eeschema display color dialog, if wanted.
> > > > >>>
> > > > >>> Patch #3 is a simple replacement of old WX Connect with Bind for
> > > > >>> consistency in that file.
> > > > >>>
> > > > >>> Cheers,
> > > > >>>
> > > > >>> John
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> ___
> > > > >>> Mailing list: https://launchpad.net/~kicad-developers
> > > > >>> Post to : kicad-developers@lists.launchpad.net
> > > > >>> Unsubscribe : https://launchpad.ne

Re: [Kicad-developers] [PATCH] Fix layer color swatches in Linux

[Jon Evans]

Yeah, this is going to be a problem any time there is a situation where
KiCad does it differently than "the standard", but has been doing it that
way forever.  No easy fix that pleases both the old users and the new
users.  Other open source software has had this problem too (GIMP, etc)

My own thoughts on the matter are that I want to never have to change layer
using the layer picker, and always have it hidden.  Based on the behavior
of other tools I have used, I think that it is possible to greatly reduce
the need to manually change layers, and especially to do so with the mouse
rather than a hotkey.

-Jon

On Tue, Feb 21, 2017 at 1:18 PM, Wayne Stambaugh 
wrote:

> I can just hear users howling already when they left click the color
> swatch thinking that they are selecting the layer and then have to
> dismiss the color select dialog to continue working.  If we cannot come
> up with a better solution, it may be best to leave sleeping dogs lie.  I
> wonder how many of the 75% of voters in the poll would response to
> having to dismiss the color selection dialog every time they
> inadvertently left clicked the color button?  This may be a case of
> ignorance being bliss.
>
> On 2/21/2017 12:54 PM, Jon Evans wrote:
> > FWIW, this is what my expecations were as a new user when I started with
> > KiCad (for what would happen with a single left-click) based on how
> > things work in other applications with layer managers I have used (ECAD,
> > graphics, etc):
> >
> > http://i.imgur.com/Euh2Gjwl.png
> >
> > -Jon
> >
> > On Tue, Feb 21, 2017 at 12:04 PM, Chris Pavlina  > <mailto:pavlina.ch...@gmail.com>> wrote:
> >
> > By the way.
> >
> > https://forum.kicad.info/t/developer-feedback-poll-layer-
> manager/5421 <https://forum.kicad.info/t/developer-feedback-poll-layer-
> manager/5421>
> >
> > Feel free to add your own responses. The results look pretty
> conclusive
> > right now ;)
> >
> > On Tue, Feb 21, 2017 at 11:40:05AM -0500, Chris Pavlina wrote:
> > > Sent to wrong recipient.
> > >
> > > On Tue, Feb 21, 2017 at 11:38:43AM -0500, Chris Pavlina wrote:
> > > > On Tue, Feb 21, 2017 at 05:24:14PM +0100, jp charras wrote:
> > > > > Le 21/02/2017 à 16:07, Chris Pavlina a écrit :
> > > > > > On Tue, Feb 21, 2017 at 09:35:34AM -0500, Wayne Stambaugh
> wrote:
> > > > > >> My only issue with this change is that the tooltip letting
> > the user know
> > > > > >> that a left button double click or a middle button click
> > would allow
> > > > > >> them to change the color is gone.  Other than that, it
> > looks great.  I
> > > > > >> like the use of Bind instead of Connect.  Bind has a much
> > cleaner
> > > > > >> interface than Connect and according to the wx folks is the
> > proper way
> > > > > >> to handle events.
> > > > > >
> > > > > > The tooltip is useless, nobody is going to hover over them
> > for long
> > > > > > enough to see it. I was just talking to someone this morning
> > who never
> > > > > > found the tooltip because he was too busy clicking on the
> > buttons to
> > > > > > make them work.
> > > > > >
> > > > > > Every other color well in every other application opens its
> > selection
> > > > > > dialog with a single left click. Why can't ours?
> > > > >
> > > > > First you have to decide if the main purpose is to select the
> > active layer or to change the color layer.
> > > > > The answer will give also the answer to "Why can't ours".
> > > > >
> > > > > For me the answer is not obvious, but my opinion is:
> > > > > the primary purpose of the layer manager is to select the
> > working layer.
> > > > > Therefore the single left click should change the layer,
> > whatever you are clicking.
> > > > >
> > > > > If the primary purpose of the layer manager is to select the
> > color, then a single left click should
> > > > > open the color dialog.
> > > >
> > > > This isn't "the layer manager", it's a color well IN the layer
> > manager.
> > > >
> > > >

Re: [Kicad-developers] [PATCH] Change from EDA_COLOR_T to COLOR4D and arbitrary color support

[Jon Evans]

Yes, they are ready to merge.

Best,
Jon

On Feb 22, 2017 03:37, "Maciej Sumiński"  wrote:

> I got a response from Wayne saying he is ok with the changes (I suppose
> the mail was meant to be sent here). Do you think the patches ready to
> be merged? They seem complete to me, but I just want to confirm.
>
> Regards,
> Orson
>
> On 02/20/2017 06:55 PM, Jon Evans wrote:
> > Thanks Orson, no I don't mind changing to static consts!
> >
> > Best,
> > Jon
> >
> > On Mon, Feb 20, 2017 at 12:50 PM, Maciej Sumiński <
> maciej.sumin...@cern.ch>
> > wrote:
> >
> >> Hi Jon,
> >>
> >> I have just tested the patch, and I really like it. I just need to test
> >> it a bit longer, as there are numerous changes, but I am in favor of
> >> merging the patch.
> >>
> >> I also applied one more patch changing a few defines (UNSPECIFIED,
> >> BLACK, WHITE) to static consts, I hope you do not mind.
> >>
> >> If there are other people interested in testing, I have rebased the
> >> changes [1] on the current master. There are also a few minor code
> >> formatting fixes.
> >>
> >> Regards,
> >> Orson
> >>
> >> 1. https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+ref/colors
> >>
> >> On 02/18/2017 09:24 PM, Jon Evans wrote:
> >>> Hi all,
> >>>
> >>> Attached is a follow-up patch to the COLOR4D change above -- I reverted
> >>> from using wxColourPickerCtrl back to wxBitmapButton in the eeschema
> >> color
> >>> config, because I finally got my Windows 10 testing environment set up,
> >> and
> >>> found out that for some reason wxColourPickerCtrl looks really ugly in
> >>> Windows 10.
> >>>
> >>> Best,
> >>> Jon
> >>>
> >>> On Fri, Feb 10, 2017 at 8:43 PM, Jon Evans  wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> Attached is a (rather large!) patch that changes the internal color
> >>>> representation to COLOR4D across the codebase (except for places that
> >>>> directly deal with wx, where wxColour is used).
> >>>>
> >>>> This patch also enables arbitrary color selection for schematic and
> >> symbol
> >>>> library editor, as well as pcbnew in the GAL canvas.  GerbView and
> >> pcbnew
> >>>> legacy canvas still use the old color picker.  Colors will be coerced
> >> into
> >>>> the legacy palette when switching from GAL to legacy, in a way that
> >> tries
> >>>> to preserve the hue and value.
> >>>>
> >>>> Colors are serialized to the settings in CSS format, because it
> supports
> >>>> alpha and represents color components the same way COLOR4D does (as
> >>>> floating-point values from 0 to 1)
> >>>>
> >>>> Tested on Linux.  Can't test on Windows or Mac yet, sorry.
> >>>> I realize this is a large changeset and might take a while to review,
> so
> >>>> just ping me if it stops applying on master and I'll update it.
> >>>>
> >>>> Best,
> >>>> Jon
> >>>>
> >>>
> >>>
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> Post to : kicad-developers@lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> >>>
> >>
> >>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >>
> >
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Change from EDA_COLOR_T to COLOR4D and arbitrary color support

[Jon Evans]

Hi Wayne, is this a requirement to merge the existing patches or something
you'd like to see before the 5.0 release?  I can definitely add that, but I
was planning to address that with my color themes feature -- the default
KiCad colors would be a "read-only" theme that people could always revert
to.

Best,
Jon

On Wed, Feb 22, 2017 at 8:44 AM, Wayne Stambaugh 
wrote:

> One thing I would like to see (unless I missed it) is a reset to default
> color feature.  This would be useful for legacy canvas users where
> getting the colors correct is critical for decent board/footprint canvas
> rendering.
>
> On 2/22/2017 3:36 AM, Maciej Sumiński wrote:
> > I got a response from Wayne saying he is ok with the changes (I suppose
> > the mail was meant to be sent here). Do you think the patches ready to
> > be merged? They seem complete to me, but I just want to confirm.
> >
> > Regards,
> > Orson
> >
> > On 02/20/2017 06:55 PM, Jon Evans wrote:
> >> Thanks Orson, no I don't mind changing to static consts!
> >>
> >> Best,
> >> Jon
> >>
> >> On Mon, Feb 20, 2017 at 12:50 PM, Maciej Sumiński <
> maciej.sumin...@cern.ch>
> >> wrote:
> >>
> >>> Hi Jon,
> >>>
> >>> I have just tested the patch, and I really like it. I just need to test
> >>> it a bit longer, as there are numerous changes, but I am in favor of
> >>> merging the patch.
> >>>
> >>> I also applied one more patch changing a few defines (UNSPECIFIED,
> >>> BLACK, WHITE) to static consts, I hope you do not mind.
> >>>
> >>> If there are other people interested in testing, I have rebased the
> >>> changes [1] on the current master. There are also a few minor code
> >>> formatting fixes.
> >>>
> >>> Regards,
> >>> Orson
> >>>
> >>> 1. https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+ref/colors
> >>>
> >>> On 02/18/2017 09:24 PM, Jon Evans wrote:
> >>>> Hi all,
> >>>>
> >>>> Attached is a follow-up patch to the COLOR4D change above -- I
> reverted
> >>>> from using wxColourPickerCtrl back to wxBitmapButton in the eeschema
> >>> color
> >>>> config, because I finally got my Windows 10 testing environment set
> up,
> >>> and
> >>>> found out that for some reason wxColourPickerCtrl looks really ugly in
> >>>> Windows 10.
> >>>>
> >>>> Best,
> >>>> Jon
> >>>>
> >>>> On Fri, Feb 10, 2017 at 8:43 PM, Jon Evans  wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> Attached is a (rather large!) patch that changes the internal color
> >>>>> representation to COLOR4D across the codebase (except for places that
> >>>>> directly deal with wx, where wxColour is used).
> >>>>>
> >>>>> This patch also enables arbitrary color selection for schematic and
> >>> symbol
> >>>>> library editor, as well as pcbnew in the GAL canvas.  GerbView and
> >>> pcbnew
> >>>>> legacy canvas still use the old color picker.  Colors will be coerced
> >>> into
> >>>>> the legacy palette when switching from GAL to legacy, in a way that
> >>> tries
> >>>>> to preserve the hue and value.
> >>>>>
> >>>>> Colors are serialized to the settings in CSS format, because it
> supports
> >>>>> alpha and represents color components the same way COLOR4D does (as
> >>>>> floating-point values from 0 to 1)
> >>>>>
> >>>>> Tested on Linux.  Can't test on Windows or Mac yet, sorry.
> >>>>> I realize this is a large changeset and might take a while to
> review, so
> >>>>> just ping me if it stops applying on master and I'll update it.
> >>>>>
> >>>>> Best,
> >>>>> Jon
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> ___
> >>>> Mailing list: https://launchpad.net/~kicad-developers
> >>>> Post to : kicad-developers@lists.launchpad.net
> >>>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>>> More help   : https://help.launchpad.net/ListHelp
> >>>>
> >>>
> >>>
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> Post to : kicad-developers@lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> >>>
> >>>
> >>
> >
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
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] Change from EDA_COLOR_T to COLOR4D and arbitrary color support

[Jon Evans]

Hi Diogo,

Unfortunately I cannot test on Mac OS at all, and can't test on any
platform this minute.
But, I think you have to change that line to:

wxPen pen( GetParent()->GetGridColor().ToColour(), h );

-Jon

On Wed, Feb 22, 2017 at 1:05 PM, Diogo Condeço 
wrote:

> Hi Jon,
>
> Your patch 0001 on this thread introduced a bug which makes kicad unable
> to build...
>
> a52250a91e24733ce798ad8baa4597032d49d11e this was the commit.
>
> kicad/common/draw_panel.cpp:757:15: error: no matching constructor for 
> initialization of 'wxPen'
> wxPen pen( GetParent()->GetGridColor(), h );
>
>
> This is on a macos machine with clang.
>
> Thanks,
>
> Diogo
>
>
> On Wed, Feb 22, 2017 at 4:56 PM, Maciej Sumiński 
> wrote:
>
>> Great, so now they are in the master repository. Thank you for the
>> patches.
>>
>> Regards,
>> Orson
>>
>> On 02/22/2017 02:10 PM, Jon Evans wrote:
>> > Yes, they are ready to merge.
>> >
>> > Best,
>> > Jon
>> >
>> > On Feb 22, 2017 03:37, "Maciej Sumiński" 
>> wrote:
>> >
>> >> I got a response from Wayne saying he is ok with the changes (I suppose
>> >> the mail was meant to be sent here). Do you think the patches ready to
>> >> be merged? They seem complete to me, but I just want to confirm.
>> >>
>> >> Regards,
>> >> Orson
>> >>
>> >> On 02/20/2017 06:55 PM, Jon Evans wrote:
>> >>> Thanks Orson, no I don't mind changing to static consts!
>> >>>
>> >>> Best,
>> >>> Jon
>> >>>
>> >>> On Mon, Feb 20, 2017 at 12:50 PM, Maciej Sumiński <
>> >> maciej.sumin...@cern.ch>
>> >>> wrote:
>> >>>
>> >>>> Hi Jon,
>> >>>>
>> >>>> I have just tested the patch, and I really like it. I just need to
>> test
>> >>>> it a bit longer, as there are numerous changes, but I am in favor of
>> >>>> merging the patch.
>> >>>>
>> >>>> I also applied one more patch changing a few defines (UNSPECIFIED,
>> >>>> BLACK, WHITE) to static consts, I hope you do not mind.
>> >>>>
>> >>>> If there are other people interested in testing, I have rebased the
>> >>>> changes [1] on the current master. There are also a few minor code
>> >>>> formatting fixes.
>> >>>>
>> >>>> Regards,
>> >>>> Orson
>> >>>>
>> >>>> 1. https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+ref/colors
>> >>>>
>> >>>> On 02/18/2017 09:24 PM, Jon Evans wrote:
>> >>>>> Hi all,
>> >>>>>
>> >>>>> Attached is a follow-up patch to the COLOR4D change above -- I
>> reverted
>> >>>>> from using wxColourPickerCtrl back to wxBitmapButton in the eeschema
>> >>>> color
>> >>>>> config, because I finally got my Windows 10 testing environment set
>> up,
>> >>>> and
>> >>>>> found out that for some reason wxColourPickerCtrl looks really ugly
>> in
>> >>>>> Windows 10.
>> >>>>>
>> >>>>> Best,
>> >>>>> Jon
>> >>>>>
>> >>>>> On Fri, Feb 10, 2017 at 8:43 PM, Jon Evans 
>> wrote:
>> >>>>>
>> >>>>>> Hi all,
>> >>>>>>
>> >>>>>> Attached is a (rather large!) patch that changes the internal color
>> >>>>>> representation to COLOR4D across the codebase (except for places
>> that
>> >>>>>> directly deal with wx, where wxColour is used).
>> >>>>>>
>> >>>>>> This patch also enables arbitrary color selection for schematic and
>> >>>> symbol
>> >>>>>> library editor, as well as pcbnew in the GAL canvas.  GerbView and
>> >>>> pcbnew
>> >>>>>> legacy canvas still use the old color picker.  Colors will be
>> coerced
>> >>>> into
>> >>>>>> the legacy palette when switching from GAL to legacy, in a way that
>> >>>> tries
>> >>>>>> to preserve the hue and value.
>> >>>>&g

Re: [Kicad-developers] [PATCH] Change from EDA_COLOR_T to COLOR4D and arbitrary color support

[Jon Evans]

Thanks Chris.
That line was hidden inside an #if block that only compiles for Mac, so
it's possible there are others that also need to be fixed -- anywhere
expecting a wxColour will now get COLOR4D and needs the ".ToColour()"
added.  Unfortunately I can't search through the code right now, but will
also be more available in ~6 hours

-Jon

On Wed, Feb 22, 2017 at 1:59 PM, Chris Pavlina 
wrote:

> I'll have a look at MacOS build tonight if Diogo doesn't figure it out
> first.
>
> On Feb 22, 2017 1:57 PM, "Jon Evans"  wrote:
>
>> Hi Diogo,
>>
>> Unfortunately I cannot test on Mac OS at all, and can't test on any
>> platform this minute.
>> But, I think you have to change that line to:
>>
>> wxPen pen( GetParent()->GetGridColor().ToColour(), h );
>>
>> -Jon
>>
>> On Wed, Feb 22, 2017 at 1:05 PM, Diogo Condeço 
>> wrote:
>>
>>> Hi Jon,
>>>
>>> Your patch 0001 on this thread introduced a bug which makes kicad unable
>>> to build...
>>>
>>> a52250a91e24733ce798ad8baa4597032d49d11e this was the commit.
>>>
>>> kicad/common/draw_panel.cpp:757:15: error: no matching constructor for 
>>> initialization of 'wxPen'
>>> wxPen pen( GetParent()->GetGridColor(), h );
>>>
>>>
>>> This is on a macos machine with clang.
>>>
>>> Thanks,
>>>
>>> Diogo
>>>
>>>
>>> On Wed, Feb 22, 2017 at 4:56 PM, Maciej Sumiński <
>>> maciej.sumin...@cern.ch> wrote:
>>>
>>>> Great, so now they are in the master repository. Thank you for the
>>>> patches.
>>>>
>>>> Regards,
>>>> Orson
>>>>
>>>> On 02/22/2017 02:10 PM, Jon Evans wrote:
>>>> > Yes, they are ready to merge.
>>>> >
>>>> > Best,
>>>> > Jon
>>>> >
>>>> > On Feb 22, 2017 03:37, "Maciej Sumiński" 
>>>> wrote:
>>>> >
>>>> >> I got a response from Wayne saying he is ok with the changes (I
>>>> suppose
>>>> >> the mail was meant to be sent here). Do you think the patches ready
>>>> to
>>>> >> be merged? They seem complete to me, but I just want to confirm.
>>>> >>
>>>> >> Regards,
>>>> >> Orson
>>>> >>
>>>> >> On 02/20/2017 06:55 PM, Jon Evans wrote:
>>>> >>> Thanks Orson, no I don't mind changing to static consts!
>>>> >>>
>>>> >>> Best,
>>>> >>> Jon
>>>> >>>
>>>> >>> On Mon, Feb 20, 2017 at 12:50 PM, Maciej Sumiński <
>>>> >> maciej.sumin...@cern.ch>
>>>> >>> wrote:
>>>> >>>
>>>> >>>> Hi Jon,
>>>> >>>>
>>>> >>>> I have just tested the patch, and I really like it. I just need to
>>>> test
>>>> >>>> it a bit longer, as there are numerous changes, but I am in favor
>>>> of
>>>> >>>> merging the patch.
>>>> >>>>
>>>> >>>> I also applied one more patch changing a few defines (UNSPECIFIED,
>>>> >>>> BLACK, WHITE) to static consts, I hope you do not mind.
>>>> >>>>
>>>> >>>> If there are other people interested in testing, I have rebased the
>>>> >>>> changes [1] on the current master. There are also a few minor code
>>>> >>>> formatting fixes.
>>>> >>>>
>>>> >>>> Regards,
>>>> >>>> Orson
>>>> >>>>
>>>> >>>> 1. https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+ref/c
>>>> olors
>>>> >>>>
>>>> >>>> On 02/18/2017 09:24 PM, Jon Evans wrote:
>>>> >>>>> Hi all,
>>>> >>>>>
>>>> >>>>> Attached is a follow-up patch to the COLOR4D change above -- I
>>>> reverted
>>>> >>>>> from using wxColourPickerCtrl back to wxBitmapButton in the
>>>> eeschema
>>>> >>>> color
>>>> >>>>> config, because I finally got my Windows 10 testing environment
>>>> set up,
>>>> >>>> and
>>>

Re: [Kicad-developers] [PATCH] Fix layer color swatches in Linux

[Jon Evans]

I agree with JP.  Move colors out of layer manager into a separate dialog,
add more powerful features for GAL.  This ties in to my plans to add color
theme support and also some other ideas I have for new display modes in GAL.

Another feature I want to clone from a commercial product is saved "display
schemes" which are at a minimum, a set of layers hidden/visible.  So you
just pick your "routing" scheme or your "placement" scheme, etc, and it
automatically sets up the layer visibility to your preference.  In addition
to visibility, this could do things with transparency, etc...

-Jon

On Wed, Feb 22, 2017 at 2:13 PM, jp charras  wrote:

> Le 22/02/2017 à 19:43, Simon Wells a écrit :
> > one option is to not have the color indicator as a control at all,
> > have it as only an indicator and if you double click on the layer
> > widget row (or right click -> properties) you get another dialog that
> > then has a real color well control. This will remove the hacky
> > behaviour on a button and also make it so that later on (when its
> > supported) you can change the layer name and type. while reducing the
> > area of single misclick. I have done a very quick gimp mockup where
> > the color is moved right to the edge, but it is currently missing
> > visibility and active layer indicators, visibility should probably be
> > done through an eye rather than checkbox, As the checkbox can also
> > fool people into thinking its disabling the layer not just changing
> > its visibility
> >
>
> A similar option is to not have the color indicator as a control at all,
> and to add in the main menu
> a new entry like "color management", especially if we consider changing
> color/transparency layers is
> not as frequent as changing the active layer.
>
> The current color dialog must be redesigned to the GAL, because GAL is by
> far more powerful than the
> legacy mode.
>
> Especially, currently there is no known way (by users) to adjust the
> transparency of layers.
> But this feature exists in GAL since a very long time.
>
> And later, add (in this menu/dialog) the ability to manage:
> * The Hight Contrast mode (adjust the transparency of not active layers)
> * The transparency of zones (if it is possible in GAL mode)
> * Manage group of layers colors: for instance the default group like now,
> but the ability to define
> a set of visible layers with perhaps transparency for "not visible"
> layers: for instance to route
> critical signals, show top and bottom layer with default tranparency/color
> setup, and other layers
> with very low transparency (or really invisible).
>
> (Choice between groups made by the context right popup menu for fast
> selection)
>
> Trying to just enhance the current color dialog, and trying to modify the
> clicks in layers managers
> is for me just write an outdated code.
>
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] Move ZoomFitScreen and ZoomPreset to common

[Jon Evans]

Hi all,

This patch finishes off the refactor I did a few days ago, by enabling
ZoomFitScreen to work without knowledge of the BOARD class.

In order to make this work, I changed the way GetBoundingBox and
ComputeBoundingBox work so that the call sites of GetBoundingBox don't have
to also call ComputeBoundingBox if they don't need to use the
aBoardEdgesOnly flag.

Those with good knowledge of BOARD should review this to make sure I caught
all the instances where we should mark the bounding box as needing to be
re-computed.

Best,
Jon
From 153167789cffbedb8861f2832f640ef86f3d4505 Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Wed, 22 Feb 2017 23:31:26 -0500
Subject: [PATCH] Move ZoomFitScreen and ZoomPreset from PCBNEW_CONTROL to
 COMMON_TOOLS

In order to prevent call sites of BOARD::GetBoundingBox() needing to
call BOARD::ComputeBoundingBox(), also implement a dirty-flag in BOARD
that will re-compute the bounding box when board objects change.

This allows COMMON_TOOLS to implement ZoomFitScreen without knowledge
of the BOARD class.
---
 common/tool/common_tools.cpp| 65 +++
 include/tool/common_tools.h |  2 ++
 pcbnew/class_board.cpp  | 29 +-
 pcbnew/class_board.h|  9 --
 pcbnew/tools/pcbnew_control.cpp | 68 -
 pcbnew/tools/pcbnew_control.h   |  4 ---
 6 files changed, 101 insertions(+), 76 deletions(-)

diff --git a/common/tool/common_tools.cpp b/common/tool/common_tools.cpp
index b5b7b07..9dbe2fd 100644
--- a/common/tool/common_tools.cpp
+++ b/common/tool/common_tools.cpp
@@ -98,6 +98,69 @@ int COMMON_TOOLS::ZoomCenter( const TOOL_EVENT& aEvent )
 }
 
 
+int COMMON_TOOLS::ZoomFitScreen( const TOOL_EVENT& aEvent )
+{
+KIGFX::VIEW* view = getView();
+EDA_DRAW_PANEL_GAL* galCanvas = m_frame->GetGalCanvas();
+EDA_ITEM* model = getModel();
+
+BOX2I boardBBox = model->ViewBBox();
+VECTOR2D scrollbarSize = VECTOR2D( galCanvas->GetSize() - galCanvas->GetClientSize() );
+VECTOR2D screenSize = view->ToWorld( galCanvas->GetClientSize(), false );
+
+if( boardBBox.GetWidth() == 0 || boardBBox.GetHeight() == 0 )
+{
+// Empty view
+view->SetScale( 17.0 ); // works fine for the standard worksheet frame
+
+view->SetCenter( screenSize / 2.0 );
+}
+else
+{
+VECTOR2D vsize = boardBBox.GetSize();
+double scale = view->GetScale() / std::max( fabs( vsize.x / screenSize.x ),
+fabs( vsize.y / screenSize.y ) );
+
+view->SetScale( scale );
+view->SetCenter( boardBBox.Centre() );
+}
+
+
+// Take scrollbars into account
+VECTOR2D worldScrollbarSize = view->ToWorld( scrollbarSize, false );
+view->SetCenter( view->GetCenter() + worldScrollbarSize / 2.0 );
+
+return 0;
+}
+
+
+int COMMON_TOOLS::ZoomPreset( const TOOL_EVENT& aEvent )
+{
+unsigned int idx = aEvent.Parameter();
+std::vector& zoomList = m_frame->GetScreen()->m_ZoomList;
+KIGFX::VIEW* view = m_frame->GetGalCanvas()->GetView();
+KIGFX::GAL* gal = m_frame->GetGalCanvas()->GetGAL();
+
+m_frame->SetPresetZoom( idx );
+
+if( idx == 0 )  // Zoom Auto
+{
+return ZoomFitScreen( aEvent );
+}
+else if( idx >= zoomList.size() )
+{
+assert( false );
+return 0;
+}
+
+double selectedZoom = zoomList[idx];
+double zoomFactor = gal->GetWorldScale() / gal->GetZoomFactor();
+view->SetScale( 1.0 / ( zoomFactor * selectedZoom ) );
+
+return 0;
+}
+
+
 // Grid control
 int COMMON_TOOLS::GridNext( const TOOL_EVENT& aEvent )
 {
@@ -135,6 +198,8 @@ void COMMON_TOOLS::SetTransitions()
 Go( &COMMON_TOOLS::ZoomInOutCenter,ACTIONS::zoomInCenter.MakeEvent() );
 Go( &COMMON_TOOLS::ZoomInOutCenter,ACTIONS::zoomOutCenter.MakeEvent() );
 Go( &COMMON_TOOLS::ZoomCenter, ACTIONS::zoomCenter.MakeEvent() );
+Go( &COMMON_TOOLS::ZoomFitScreen,  ACTIONS::zoomFitScreen.MakeEvent() );
+Go( &COMMON_TOOLS::ZoomPreset, ACTIONS::zoomPreset.MakeEvent() );
 
 Go( &COMMON_TOOLS::GridNext,   ACTIONS::gridNext.MakeEvent() );
 Go( &COMMON_TOOLS::GridPrev,   ACTIONS::gridPrev.MakeEvent() );
diff --git a/include/tool/common_tools.h b/include/tool/common_tools.h
index c37d0cd..9f60402 100644
--- a/include/tool/common_tools.h
+++ b/include/tool/common_tools.h
@@ -48,6 +48,8 @@ public:
 int ZoomInOut( const TOOL_EVENT& aEvent );
 int ZoomInOutCenter( const TOOL_EVENT& aEvent );
 int ZoomCenter( const TOOL_EVENT& aEvent );
+int ZoomFitScreen( const TOOL_EVENT& aEvent );
+int ZoomPreset( const TOOL_EVENT& aEvent );
 
 // Grid control
 int GridNext( const TOOL_EVENT& aEvent );
diff --git a/pcbn

Re: [Kicad-developers] [PATCH] Move ZoomFitScreen and ZoomPreset to common

[Jon Evans]

Hi Orson,

Here's an updated patch with the changes you requested.  The only issue is,
without some kind of caching, I had to change the call sites that were
interested in the board bounding box with edges only, so the patch has
grown in scope.  Let me know if this looks better.

Best,
Jon

On Thu, Feb 23, 2017 at 4:17 AM, Maciej Sumiński 
wrote:

> Hi Jon,
>
> I really like the generic approach in the zoom methods. This part I
> would merge instantly, but there is an issue with caching the board
> bounding box. It does not take into account that items already added to
> board may change their position and affect the bounding box. I would
> remove caching completely, what do you think?
>
> If you are going to modify the patch, would you rename boardBBox in
> COMMON_TOOLS::ZoomFitScreen() to bbox or anything that is not related to
> board? Thank you in advance.
>
> Regards,
> Orson
>
> On 02/23/2017 05:34 AM, Jon Evans wrote:
> > Hi all,
> >
> > This patch finishes off the refactor I did a few days ago, by enabling
> > ZoomFitScreen to work without knowledge of the BOARD class.
> >
> > In order to make this work, I changed the way GetBoundingBox and
> > ComputeBoundingBox work so that the call sites of GetBoundingBox don't
> have
> > to also call ComputeBoundingBox if they don't need to use the
> > aBoardEdgesOnly flag.
> >
> > Those with good knowledge of BOARD should review this to make sure I
> caught
> > all the instances where we should mark the bounding box as needing to be
> > re-computed.
> >
> > Best,
> > Jon
> >
> >
> >
> > ___
> > 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
>
>
From 5ea384e2975e0fe7df0817a189522486c8a411ee Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Wed, 22 Feb 2017 23:31:26 -0500
Subject: [PATCH] Move ZoomFitScreen and ZoomPreset from PCBNEW_CONTROL to
 COMMON_TOOLS

BOARD::GetBoundingBox() now directly calls BOARD::ComputeBoundingBox()
and there is a new method BOARD::GetBoardEdgesBoundingBox() used for
call sites that needed to use ComputeBoundingBox( true ) in the past.

This allows COMMON_TOOLS to implement ZoomFitScreen without knowledge
of the BOARD class.
---
 common/tool/common_tools.cpp| 65 +++
 include/tool/common_tools.h |  2 +
 pcbnew/autorouter/auto_place_footprints.cpp |  2 +-
 pcbnew/autorouter/routing_matrix.cpp|  4 +-
 pcbnew/autorouter/spread_footprints.cpp |  2 +-
 pcbnew/basepcbframe.cpp |  2 +-
 pcbnew/board_netlist_updater.cpp|  2 +-
 pcbnew/class_board.cpp  |  5 ++-
 pcbnew/class_board.h| 14 --
 pcbnew/dialogs/dialog_export_idf.cpp|  2 +-
 pcbnew/dialogs/dialog_update_pcb.cpp|  2 +-
 pcbnew/eagle_plugin.cpp |  2 +-
 pcbnew/exporters/export_idf.cpp |  2 +-
 pcbnew/exporters/gen_drill_report_files.cpp |  2 +-
 pcbnew/netlist.cpp  |  2 +-
 pcbnew/specctra_export.cpp  |  2 +-
 pcbnew/tools/pcbnew_control.cpp | 68 -
 pcbnew/tools/pcbnew_control.h   |  4 --
 18 files changed, 93 insertions(+), 91 deletions(-)

diff --git a/common/tool/common_tools.cpp b/common/tool/common_tools.cpp
index b5b7b07..37e46d1 100644
--- a/common/tool/common_tools.cpp
+++ b/common/tool/common_tools.cpp
@@ -98,6 +98,69 @@ int COMMON_TOOLS::ZoomCenter( const TOOL_EVENT& aEvent )
 }
 
 
+int COMMON_TOOLS::ZoomFitScreen( const TOOL_EVENT& aEvent )
+{
+KIGFX::VIEW* view = getView();
+EDA_DRAW_PANEL_GAL* galCanvas = m_frame->GetGalCanvas();
+EDA_ITEM* model = getModel();
+
+BOX2I bBox = model->ViewBBox();
+VECTOR2D scrollbarSize = VECTOR2D( galCanvas->GetSize() - galCanvas->GetClientSize() );
+VECTOR2D screenSize = view->ToWorld( galCanvas->GetClientSize(), false );
+
+if( bBox.GetWidth() == 0 || bBox.GetHeight() == 0 )
+{
+// Empty view
+view->SetScale( 17.0 ); // works fine for the standard worksheet frame
+
+view->SetCenter( screenSize / 2.0 );
+}
+else
+{
+VECTOR2D vsize = bBox.GetSize();
+double scale = view->GetScale() / std::max( fabs( vsiz

Re: [Kicad-developers] Strange COLOR4D::LegacyMix( COLOR4D aColor ) optimization

[Jon Evans]

Hi JP,

You could well be right, I did not perform cycle counting on this method,
just kept the map lookup because that is what was used before.  It would be
a better optimization (if one if even needed) to come up with a fast way of
hashing a COLOR4D so that it can be used as a key in a key-value store.
Please feel free to change how this works, I am not attached to it.

Best,
Jon

On Thu, Feb 23, 2017 at 10:24 AM, jp charras  wrote:

> Hi Jon,
>
> When searching a fix to an issue in legacy mode (incorrect calculation of
> ORed wxColors), I had a
> look at
> COLOR4D::LegacyMix( COLOR4D aColor )
>
> and for me the optimization to calculate the mix between 2 wxColors need
> more calculation than the
> basic calculation.
> optimization: normalize and convert 8 double to int, search in map and
> normalize 4 int to double
> direct calculation (faster):
> normalize and convert 6 double to int, and normalize 3 int to double.
>
> Am I missed something?
>
> Thanks.
>
> --
> 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] Strange COLOR4D::LegacyMix( COLOR4D aColor ) optimization

[Jon Evans]

By the way, thanks for fixing issue with EDA_COLOR_T constructor, I had
that fixed locally but for some reason it did not make it in to my patch.
Sorry about that.  I will have some more time tonight to look at other
color issues if you run in to them.  If not, I will keep working on
GerbView.

Best,
Jon

On Thu, Feb 23, 2017 at 10:47 AM, Jon Evans  wrote:

> Hi JP,
>
> You could well be right, I did not perform cycle counting on this method,
> just kept the map lookup because that is what was used before.  It would be
> a better optimization (if one if even needed) to come up with a fast way of
> hashing a COLOR4D so that it can be used as a key in a key-value store.
> Please feel free to change how this works, I am not attached to it.
>
> Best,
> Jon
>
> On Thu, Feb 23, 2017 at 10:24 AM, jp charras 
> wrote:
>
>> Hi Jon,
>>
>> When searching a fix to an issue in legacy mode (incorrect calculation of
>> ORed wxColors), I had a
>> look at
>> COLOR4D::LegacyMix( COLOR4D aColor )
>>
>> and for me the optimization to calculate the mix between 2 wxColors need
>> more calculation than the
>> basic calculation.
>> optimization: normalize and convert 8 double to int, search in map and
>> normalize 4 int to double
>> direct calculation (faster):
>> normalize and convert 6 double to int, and normalize 3 int to double.
>>
>> Am I missed something?
>>
>> Thanks.
>>
>> --
>> 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] Torrents for KiCad distribution

[Jon Evans]

Does anyone have stats on what the typical bandwidth transfer is from the
download server over time (such as when there is a release)?  If there is a
problem (i.e. the current server slows down too much or costs too much when
there is a release and lots of people download at once), it would be useful
to know the scale of the problem to be able to think about what possible
solutions would be most effective (such as torrents, using a CDN, etc)

-Jon

On Thu, Feb 23, 2017 at 4:07 PM, Simon Wells  wrote:

> I believe the server is located in France
>
> Being located most distantly from the kicad download servers i have no
> issues with the speeds from the download server, If we were qt and had
> 2.x GB downloads and the speed was complete crap like i get from qt i
> would encourage torrents. but from downloads.kicad-pcb.org i normally
> max out my connection (ADSL) as such i don't believe they are
> necessary
>
> On 24 February 2017 at 08:57, Chris Pavlina 
> wrote:
> > On Thu, Feb 23, 2017 at 08:02:55PM +0100, Ingo Kletti wrote:
> >> Am Donnerstag, 23. Februar 2017, 09:49:41 schrieben Sie:
> >> > No plans currently. Do you think enough people would use them for it
> to
> >> > really work?
> >>
> >> I have no idea and, as far as I understood the concept of torrents, you
> could
> >> not tell the number of downloads, just a sum of Bytes transferred
> (provided
> >> the tracker server keeps a record of this).
> >>
> >> Using torrents to distribute KiCad was an idea that came up today since
> the
> >> next stable release is only a few days away and providing torrents could
> >> probably remedy the hammering of the server during the first days.
> >
> > Agreed, if people would actually use them it'd be a decent way to
> > lighten the server's load. I wouldn't mind it myself, certainly, but
> > then I'm not a packager
> >
> >>
> >> Regards,
> >>
> >> Ingo
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Move ZoomFitScreen and ZoomPreset to common

[Jon Evans]

We need a solution that allows GetBoundingBox to be called blindly, without
knowing if (or how) an EDA_ITEM subclass needs to have the bounding box
updated.

Does anyone have ideas about how complicated it would be to give the BOARD
class knowledge of whether or not anything inside it has changed?  This is
what I tried to implement at first, but Orson pointed out that the way I
did it would miss some kinds of changes.

Figuring out the above also seems useful for other reasons -- for example,
autosave / backup features are easier to implement if there is a global
"dirty/clean" flag for things like BOARD.

If there is no good way to implement caching, I guess another way would be
to implement caching at the sites that use the BOARD bounding box heavily
(autorouter etc)

-Jon

On Fri, Feb 24, 2017 at 9:22 AM, Wayne Stambaugh 
wrote:

> On 2/24/2017 4:16 AM, Maciej Sumiński wrote:
> > Hi Jon,
> >
> > The current version looks much better to me. From what I see there is no
> > actual bounding box caching, as GetBoundingBox() always calls
> > ComputeBoundingBox(). I am fine with that, but before I push the patch I
> > need to ask: does anyone know why the board bounding box is cached? I
> > believe it must have been done to boost performance of certain parts of
> > the code, but I wonder if it is really necessary. Especially that one
> > needs to know that it has to be updated using ComputeBoundingBox().
>
> It was cached so it didn't need to be recalculated every time the
> bounding box was required.  It should or at least it did recalculate
> only when the changes were made since the last call to fetch the
> bounding box.  On very complex boards, this can take a while.  Getting
> the bounding box is called fairly often so this can add up.  I don't see
> any reason to recalculate the bounding box on every get bounding box
> call.  If the current bounding box behavior is broken, then it should be
> fixed.  I don't see any reason to get rid of the caching method.  If you
> are operating outside of the normal methods for adding and/or editing
> board objects that prevents the correct bounding box from being
> calculated, that is your fault and you need to fix your code accordingly.
>
> >
> > Just by looking at the code, I noticed that the autorouter calls
> > BOARD::GetBoundingBox() frequently, but I could not see much difference
> > with caching disabled. Likely, the routing algorithm takes significantly
> > more time than the bounding box calculations.
> >
> > Personally I would completely remove m_BoundingBox field instead of
> > making it mutable. Also, I have noticed there are a few places where the
> > bounding box is overridden with SetBoundingBox(). It seems to me a bit
> > dubious, as bounding box should depend solely on the items belonging to
> > the board. I attach a patch to show what I would change. Any comments,
> > especially from Wayne & Jean-Pierre?
> >
> > Regards,
> > Orson
> >
> > On 02/23/2017 01:49 PM, Jon Evans wrote:
> >> Hi Orson,
> >>
> >> Here's an updated patch with the changes you requested.  The only issue
> is,
> >> without some kind of caching, I had to change the call sites that were
> >> interested in the board bounding box with edges only, so the patch has
> >> grown in scope.  Let me know if this looks better.
> >>
> >> Best,
> >> Jon
> >>
> >> On Thu, Feb 23, 2017 at 4:17 AM, Maciej Sumiński <
> maciej.sumin...@cern.ch>
> >> wrote:
> >>
> >>> Hi Jon,
> >>>
> >>> I really like the generic approach in the zoom methods. This part I
> >>> would merge instantly, but there is an issue with caching the board
> >>> bounding box. It does not take into account that items already added to
> >>> board may change their position and affect the bounding box. I would
> >>> remove caching completely, what do you think?
> >>>
> >>> If you are going to modify the patch, would you rename boardBBox in
> >>> COMMON_TOOLS::ZoomFitScreen() to bbox or anything that is not related
> to
> >>> board? Thank you in advance.
> >>>
> >>> Regards,
> >>> Orson
> >>>
> >>> On 02/23/2017 05:34 AM, Jon Evans wrote:
> >>>> Hi all,
> >>>>
> >>>> This patch finishes off the refactor I did a few days ago, by enabling
> >>>> ZoomFitScreen to work without knowledge of the BOARD class.
> >>>>
> >>>> In order to make this work, I changed the way GetBoundingBox and
> >>&

[Kicad-developers] GerbView GAL: issue with draw order and negative items

[Jon Evans]

Hi all,

I've run into a problem while porting GerbView to GAL that doesn't have an
obvious best solution to me, so I thought I would ask those with more
knowledge of the GAL for ideas.

Gerber files rely on a fixed draw order.  This becomes important when some
draw objects in the file are negative, because they must "unpaint" things
that appeared earlier in the file, but not things later in the file.

My initial approach to the GAL port was to create a painter that paints
each GERBER_DRAW_ITEM, and add all GERBER_DRAW_ITEMS to the VIEW upon file
load.  This works, as long as there aren't negative objects in the Gerber
file.  Since VIEW calls upon objects to be painted in an order that doesn't
necessarily have anything to do with the order they were added to the VIEW
(because of being stored in an R-Tree), negative objects don't properly
mask positive ones.

One solution would be to just add entire Gerber images to the VIEW instead
of the draw objects within the images, and then the drawing code could draw
all items at once and make sure to do it in the right order, but this seems
like an ugly hack and I think it would bypass the off-screen object culling
and possibly cause other problems / make some features harder to implement.

Another would be to implement some sort of render order sorting inside
VIEW, but I haven't looked in to that much yet, so I'm not sure how
complicated it would be.

Does anyone have suggestions for this problem?

Thanks,
Jon
___
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] GerbView GAL: issue with draw order and negative items

[Jon Evans]

Hi Tom,

Thanks very much for the suggestions, I will look in to doing it this way.

Hi Chris, as you might tell from Tom's response, the existing tree does not
keep track of insertion order and draw priority, but I will take the
approach of adding that feature.

I have a sample of a board with Gerber files for several layers that use
negative draw mode.  Since the goal is to have GerbView use GAL without
losing any features from the existing (legacy) draw code, it must support
negative objects, even if they are rare.  In fact, they are implemented
currently as drawing the background color, as you suggest.

Best,
Jon


On Mon, Feb 27, 2017 at 6:10 AM, Tomasz Wlostowski <
tomasz.wlostow...@cern.ch> wrote:

> On 26.02.2017 20:49, Jon Evans wrote:
> > Hi all,
> >
> > I've run into a problem while porting GerbView to GAL that doesn't have
> > (...)
> > Another would be to implement some sort of render order sorting inside
> > VIEW, but I haven't looked in to that much yet, so I'm not sure how
> > complicated it would be.
> >
> > Does anyone have suggestions for this problem?
>
> Hi Jon,
>
> Many thanks for your excellent work.
>
> One of possible ways to solve your problem is to:
> - Add an additional field (say, m_drawPriority) in VIEW_ITEM_DATA
> containing the drawing priority
> - Modify VIEW::redrawRect() and VIEW::drawItem to first collect all
> drawable items, sort them by m_drawPriority and then draw.
> - The m_drawPriority could be accessed by additional methods in the VIEW
> class and by default initialized to subsequent values as items are added
> to a VIEW.
> - Sorting could be optional, for large PCB views it might affect
> performance.
>
> Cheers,
> Tom
>
> PS. If you have time, feel free to C++11-ize the VIEW code ;-)
>
>
>
> >
> > Thanks,
> > Jon
> >
> >
> > ___
> > 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] Add drawing priority support to VIEW

[Jon Evans]

Hi all,

Thanks to Tom's suggestion on how to approach this, I've got it working and
now GerbView can properly render negative objects in GAL.  This patch
should have no impact on pcbnew.

By the way, I'm getting close to feeling like I can share the work I'm
doing on GerbView in a private branch, but there are still a few things
that are broken enough that it doesn't make sense to subject other people
to them :-)

Best,
Jon
From ad6a5f7a5213cec224f1dd70a620e29af321f5fd Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Mon, 27 Feb 2017 18:40:27 -0500
Subject: [PATCH] Add drawing priority support to VIEW

Call UseDrawPriority( true ) after creating GAL to enable.

VIEW::Add() gets a new optional argument to specify the draw order
when adding an item.  If the new argument is left default, the draw
order will increment with each call of VIEW::Add().
---
 common/view/view.cpp | 40 ++--
 include/view/view.h  | 28 +++-
 2 files changed, 61 insertions(+), 7 deletions(-)

diff --git a/common/view/view.cpp b/common/view/view.cpp
index b661115..6018e7b 100644
--- a/common/view/view.cpp
+++ b/common/view/view.cpp
@@ -89,6 +89,7 @@ private:
 VIEW*   m_view; ///< Current dynamic view the item is assigned to.
 int m_flags;///< Visibility flags
 int m_requiredUpdate;   ///< Flag required for updating
+int m_drawPriority; ///< Order to draw this item in a layer, lowest first

 ///> Helper for storing cached items group ids
 typedef std::pair GroupPair;
@@ -260,7 +261,9 @@ VIEW::VIEW( bool aIsDynamic ) :
 m_mirrorX( false ), m_mirrorY( false ),
 m_painter( NULL ),
 m_gal( NULL ),
-m_dynamic( aIsDynamic )
+m_dynamic( aIsDynamic ),
+m_useDrawPriority( false ),
+m_nextDrawPriority( 0 )
 {
 m_boundary.SetMaximum();
 m_allItems.reserve( 32768 );
@@ -301,12 +304,16 @@ void VIEW::AddLayer( int aLayer, bool aDisplayOnly )
 }


-void VIEW::Add( VIEW_ITEM* aItem )
+void VIEW::Add( VIEW_ITEM* aItem, int aDrawPriority )
 {
 int layers[VIEW_MAX_LAYERS], layers_count;

+if( aDrawPriority < 0 )
+aDrawPriority = m_nextDrawPriority++;
+
 aItem->m_viewPrivData = new VIEW_ITEM_DATA;
 aItem->m_viewPrivData->m_view = this;
+aItem->m_viewPrivData->m_drawPriority = aDrawPriority;

 aItem->ViewGetLayers( layers, layers_count );
 aItem->viewPrivData()->saveLayers( layers, layers_count );
@@ -812,8 +819,8 @@ void VIEW::UpdateAllLayersOrder()

 struct VIEW::drawItem
 {
-drawItem( VIEW* aView, int aLayer ) :
-view( aView ), layer( aLayer )
+drawItem( VIEW* aView, int aLayer, bool aUseDrawPriority ) :
+view( aView ), layer( aLayer ), useDrawPriority( aUseDrawPriority )
 {
 }

@@ -827,13 +834,29 @@ struct VIEW::drawItem
 if( !drawCondition )
 return true;

-view->draw( aItem, layer );
+if( useDrawPriority )
+drawItems.push_back( aItem );
+else
+view->draw( aItem, layer );

 return true;
 }

+void deferredDraw()
+{
+std::sort( drawItems.begin(), drawItems.end(),
+   []( VIEW_ITEM* a, VIEW_ITEM* b ) -> bool {
+   return b->viewPrivData()->m_drawPriority < a->viewPrivData()->m_drawPriority;
+   });
+
+for( auto item : drawItems )
+view->draw( item, layer );
+}
+
 VIEW* view;
 int layer, layers[VIEW_MAX_LAYERS];
+bool useDrawPriority;
+std::vector drawItems;
 };


@@ -843,11 +866,14 @@ void VIEW::redrawRect( const BOX2I& aRect )
 {
 if( l->visible && IsTargetDirty( l->target ) && areRequiredLayersEnabled( l->id ) )
 {
-drawItem drawFunc( this, l->id );
+drawItem drawFunc( this, l->id, m_useDrawPriority );

 m_gal->SetTarget( l->target );
 m_gal->SetLayerDepth( l->renderingOrder );
 l->items->Query( aRect, drawFunc );
+
+if( m_useDrawPriority )
+drawFunc.deferredDraw();
 }
 }
 }
@@ -955,6 +981,8 @@ void VIEW::Clear()
 for( LAYER_MAP_ITER i = m_layers.begin(); i != m_layers.end(); ++i )
 i->second.items->RemoveAll();

+m_nextDrawPriority = 0;
+
 m_gal->ClearCache();
 }

diff --git a/include/view/view.h b/include/view/view.h
index 6de865a..108b2df 100644
--- a/include/view/view.h
+++ b/include/view/view.h
@@ -79,9 +79,11 @@ public:
 /**
  * Function Add()
  * Adds a VIEW_ITEM to the view.
+ * Set aDrawPriority to -1 to assign sequential priorities.
  * @param aItem: item to be added. No ownership is given
+ * @param aDrawPriority: priority to draw this item on its layer, lowest first.
  */
-void Add( VIEW_ITEM* aItem );
+ 

Re: [Kicad-developers] [PATCH] Add drawing priority support to VIEW

[Jon Evans]

Hi,

The attached patch needs to be applied after the one in my first message,
turns out that I didn't properly rebuild pcbnew and needed to change
board_commit to match the new VIEW::Add() signature.

Best,
Jon

On Mon, Feb 27, 2017 at 6:44 PM, Jon Evans  wrote:

> Hi all,
>
> Thanks to Tom's suggestion on how to approach this, I've got it working
> and now GerbView can properly render negative objects in GAL.  This patch
> should have no impact on pcbnew.
>
> By the way, I'm getting close to feeling like I can share the work I'm
> doing on GerbView in a private branch, but there are still a few things
> that are broken enough that it doesn't make sense to subject other people
> to them :-)
>
> Best,
> Jon
>
From 392576d32a868021856cf38070ed969b8d0a96e5 Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Mon, 27 Feb 2017 21:31:45 -0500
Subject: [PATCH] Fix std::bind calls after change to VIEW::Add

---
 pcbnew/board_commit.cpp | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/pcbnew/board_commit.cpp b/pcbnew/board_commit.cpp
index e245782..bad4616 100644
--- a/pcbnew/board_commit.cpp
+++ b/pcbnew/board_commit.cpp
@@ -117,7 +117,7 @@ void BOARD_COMMIT::Push( const wxString& aMessage )
 if( boardItem->Type() == PCB_MODULE_T )
 {
 MODULE* mod = static_cast( boardItem );
-mod->RunOnChildren( std::bind( &KIGFX::VIEW::Add, view, _1 ) );
+mod->RunOnChildren( std::bind( &KIGFX::VIEW::Add, view, _1, -1 ) );
 }
 }
 else
@@ -327,7 +327,7 @@ void BOARD_COMMIT::Revert()
 {
 MODULE* newModule = static_cast( item );
 newModule->RunOnChildren( std::bind( &EDA_ITEM::ClearFlags, _1, SELECTED ) );
-newModule->RunOnChildren( std::bind( &KIGFX::VIEW::Add, view, _1 ) );
+newModule->RunOnChildren( std::bind( &KIGFX::VIEW::Add, view, _1, -1 ) );
 }
 
 view->Add( item );
@@ -355,7 +355,7 @@ void BOARD_COMMIT::Revert()
 {
 MODULE* newModule = static_cast( item );
 newModule->RunOnChildren( std::bind( &EDA_ITEM::ClearFlags, _1, SELECTED ) );
-newModule->RunOnChildren( std::bind( &KIGFX::VIEW::Add, view, _1 ) );
+newModule->RunOnChildren( std::bind( &KIGFX::VIEW::Add, view, _1, -1 ) );
 }
 
 view->Add( item );
-- 
2.7.4

___
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] Add drawing priority support to VIEW

[Jon Evans]

One more fixup patch -- this should teach me to not try to work on two
things at once

On Mon, Feb 27, 2017 at 9:32 PM, Jon Evans  wrote:

> Hi,
>
> The attached patch needs to be applied after the one in my first message,
> turns out that I didn't properly rebuild pcbnew and needed to change
> board_commit to match the new VIEW::Add() signature.
>
> Best,
> Jon
>
> On Mon, Feb 27, 2017 at 6:44 PM, Jon Evans  wrote:
>
>> Hi all,
>>
>> Thanks to Tom's suggestion on how to approach this, I've got it working
>> and now GerbView can properly render negative objects in GAL.  This patch
>> should have no impact on pcbnew.
>>
>> By the way, I'm getting close to feeling like I can share the work I'm
>> doing on GerbView in a private branch, but there are still a few things
>> that are broken enough that it doesn't make sense to subject other people
>> to them :-)
>>
>> Best,
>> Jon
>>
>
>
From 11cb83aff770d26103eaa09d710dab8066b1f9e7 Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Mon, 27 Feb 2017 21:41:36 -0500
Subject: [PATCH] Fix more std::bind calls after change to VIEW::Add

---
 pcbnew/footprint_preview_panel.cpp | 2 +-
 pcbnew/netlist.cpp | 2 +-
 pcbnew/pcb_draw_panel_gal.cpp  | 2 +-
 pcbnew/undo_redo.cpp   | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/pcbnew/footprint_preview_panel.cpp b/pcbnew/footprint_preview_panel.cpp
index 17873a5..1502a9c 100644
--- a/pcbnew/footprint_preview_panel.cpp
+++ b/pcbnew/footprint_preview_panel.cpp
@@ -202,7 +202,7 @@ void FOOTPRINT_PREVIEW_PANEL::renderFootprint(  MODULE *module )
 Freeze();
 GetView()->Clear();
 module->SetParent ( &*m_dummyBoard );
-module->RunOnChildren( boost::bind( &KIGFX::VIEW::Add, GetView(), _1 ) );
+module->RunOnChildren( boost::bind( &KIGFX::VIEW::Add, GetView(), _1, -1 ) );
 
 GetView()->Add ( module );
 
diff --git a/pcbnew/netlist.cpp b/pcbnew/netlist.cpp
index b6288b4..c0a836a 100644
--- a/pcbnew/netlist.cpp
+++ b/pcbnew/netlist.cpp
@@ -158,7 +158,7 @@ void PCB_EDIT_FRAME::ReadPcbNetlist( const wxString& aNetlistFileName,
 // Reload modules
 for( MODULE* module = board->m_Modules; module; module = module->Next() )
 {
-module->RunOnChildren( std::bind( &KIGFX::VIEW::Add, view, _1 ) );
+module->RunOnChildren( std::bind( &KIGFX::VIEW::Add, view, _1, -1 ) );
 view->Add( module );
 }
 
diff --git a/pcbnew/pcb_draw_panel_gal.cpp b/pcbnew/pcb_draw_panel_gal.cpp
index efa3dd9..3742f13 100644
--- a/pcbnew/pcb_draw_panel_gal.cpp
+++ b/pcbnew/pcb_draw_panel_gal.cpp
@@ -150,7 +150,7 @@ void PCB_DRAW_PANEL_GAL::DisplayBoard( const BOARD* aBoard )
 // Load modules and its additional elements
 for( MODULE* module = aBoard->m_Modules; module; module = module->Next() )
 {
-module->RunOnChildren( std::bind( &KIGFX::VIEW::Add, m_view, _1 ) );
+module->RunOnChildren( std::bind( &KIGFX::VIEW::Add, m_view, _1, -1 ) );
 m_view->Add( module );
 }
 
diff --git a/pcbnew/undo_redo.cpp b/pcbnew/undo_redo.cpp
index f0ee448..bb4b4a6 100644
--- a/pcbnew/undo_redo.cpp
+++ b/pcbnew/undo_redo.cpp
@@ -477,7 +477,7 @@ void PCB_BASE_EDIT_FRAME::PutDataInPreviousState( PICKED_ITEMS_LIST* aList, bool
 if( item->Type() == PCB_MODULE_T )
 {
 MODULE* newModule = static_cast( item );
-newModule->RunOnChildren( std::bind( &KIGFX::VIEW::Add, view, _1 ) );
+newModule->RunOnChildren( std::bind( &KIGFX::VIEW::Add, view, _1, -1 ) );
 newModule->RunOnChildren( std::bind( &BOARD_ITEM::ClearFlags, _1, EDA_ITEM_ALL_FLAGS ));
 }
 
@@ -508,7 +508,7 @@ void PCB_BASE_EDIT_FRAME::PutDataInPreviousState( PICKED_ITEMS_LIST* aList, bool
 if( item->Type() == PCB_MODULE_T )
 {
 MODULE* module = static_cast( item );
-module->RunOnChildren( std::bind( &KIGFX::VIEW::Add, view, _1) );
+module->RunOnChildren( std::bind( &KIGFX::VIEW::Add, view, _1, -1 ) );
 }
 
 view->Add( item );
-- 
2.7.4

___
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] Move ZoomFitScreen and ZoomPreset to common

[Jon Evans]

I'm finally back to this problem now that I have some other WIP committed.

As far as I can tell, there two paths to go down for this problem:

1) Implement auto-caching of the bounding box.  This requires some
mechanism to tell BOARD that it needs to update the cache, be it OBSERVABLE
or some other update function added to BOARD_ITEM.  No matter how it's
done, this method seems not great to me because it requires touching a ton
of code to provide coverage for every possible entry point that could end
up having an effect on the bounding box.

2) Have two different calls to get the bounding box for an EDA_ITEM, one
that always re-generates the cache and one that just returns a cached
value.  Update the call sites that hit the bounding box frequently
(autorouter, etc) to make use of the cached value; keep the call sites that
always re-generate the bounding box in today's code working that way.
Performance shouldn't be any better or worse than it is now.

3) Track whether a board is clean/dirty in some other way besides looking
at BOARD_ITEMs.  This might not be practical while we still support legacy,
but once there is only GAL, I could see this maybe being possible through
the tool framework.  For example, actions could be marked as possibly
impacting the board or not (i.e. move item does, zoom does not)

So, unless someone suggests otherwise, I'm going to try implementing #2,
and suggest #3 as a future improvement that would improve performance for
some edge case operations (i.e. "zoom to fit screen" would be instantaneous
if nothing has modified the board since the last time the bbox was cached,
even on large boards)

-Jon

On Fri, Feb 24, 2017 at 11:01 AM, Wayne Stambaugh 
wrote:

> On 2/24/2017 10:30 AM, Maciej Sumiński wrote:
> > Most of the operations one can do on a BOARD_ITEM potentially affects
> > the board bounding box. It means there might be many places where the
> > notifications should be added.
> >
> > Some time ago, Michael Steinberg has put in place OBSERVABLE class
> > (include/observable.h) that could facilitate the task.
>
> It could be useful but I'm not sure it would be a better design than the
> child object informing it's parent that it's bounding box has changed.
> I'm not sure the additional code would make the code any more readable.
> The only benefit would be if other observers were required.
>
> >
> > With the current approach, developers have to guess whether to update
> > the bounding box with ComputeBoundingBox() or take the cached value.
> > Update is called in very few places, so I really wonder what kind of
> > magic makes it work, but I might have missed something here.
>
> This solution would require limiting the entry points in the BOARD
> object that allow changes to the BOARD's child items.  Conceptually this
> is probably easier to understand but requires developers to be diligent
> when making changes to the BOARD object or not trying to bypass these
> entry points.
>
> >
> > Regards,
> > Orson
> >
> > On 02/24/2017 04:06 PM, Wayne Stambaugh wrote:
> >> Every BOARD_ITEM has a parent/child relationship or at least it did if
> >> someone did not break it.  You can always find the parent BOARD object
> >> by walking up the BOARD_ITEM parent list.  There is already a
> >> BOARD_ITEM::GetBoard() call that should return the parent board.  You
> >> could use that to notify the BOARD object when a child BOARD_ITEM change
> >> effects the bounding box.
> >>
> >> On 2/24/2017 9:27 AM, Jon Evans wrote:
> >>> We need a solution that allows GetBoundingBox to be called blindly,
> >>> without knowing if (or how) an EDA_ITEM subclass needs to have the
> >>> bounding box updated.
> >>>
> >>> Does anyone have ideas about how complicated it would be to give the
> >>> BOARD class knowledge of whether or not anything inside it has changed?
> >>> This is what I tried to implement at first, but Orson pointed out that
> >>> the way I did it would miss some kinds of changes.
> >>>
> >>> Figuring out the above also seems useful for other reasons -- for
> >>> example, autosave / backup features are easier to implement if there is
> >>> a global "dirty/clean" flag for things like BOARD.
> >>>
> >>> If there is no good way to implement caching, I guess another way would
> >>> be to implement caching at the sites that use the BOARD bounding box
> >>> heavily (autorouter etc)
> >>>
> >>> -Jon
> >>>
> >>> On Fri, Feb 24, 2017 at 9:22 AM, Wayne Stambaugh  >>> <mailto:stamb

Re: [Kicad-developers] [PATCH] Move ZoomFitScreen and ZoomPreset to common

[Jon Evans]

Update: after some more testing, I think Orson's patch on top of mine is
the way to go.  It pulls the computation out of the loops for autorouter,
and that's the only place where the board's bounding box is used
repetitively.  Since the other call sites are only going to get the
bounding box intermittently, I don't think it's worth any effort doing
complicated things to track and recompute the bounding box when things are
changed.

So, I think my patch and Orson's should be merged.

-Jon

On Tue, Feb 28, 2017 at 6:51 PM, Jon Evans  wrote:

> I'm finally back to this problem now that I have some other WIP committed.
>
> As far as I can tell, there two paths to go down for this problem:
>
> 1) Implement auto-caching of the bounding box.  This requires some
> mechanism to tell BOARD that it needs to update the cache, be it OBSERVABLE
> or some other update function added to BOARD_ITEM.  No matter how it's
> done, this method seems not great to me because it requires touching a ton
> of code to provide coverage for every possible entry point that could end
> up having an effect on the bounding box.
>
> 2) Have two different calls to get the bounding box for an EDA_ITEM, one
> that always re-generates the cache and one that just returns a cached
> value.  Update the call sites that hit the bounding box frequently
> (autorouter, etc) to make use of the cached value; keep the call sites that
> always re-generate the bounding box in today's code working that way.
> Performance shouldn't be any better or worse than it is now.
>
> 3) Track whether a board is clean/dirty in some other way besides looking
> at BOARD_ITEMs.  This might not be practical while we still support legacy,
> but once there is only GAL, I could see this maybe being possible through
> the tool framework.  For example, actions could be marked as possibly
> impacting the board or not (i.e. move item does, zoom does not)
>
> So, unless someone suggests otherwise, I'm going to try implementing #2,
> and suggest #3 as a future improvement that would improve performance for
> some edge case operations (i.e. "zoom to fit screen" would be instantaneous
> if nothing has modified the board since the last time the bbox was cached,
> even on large boards)
>
> -Jon
>
> On Fri, Feb 24, 2017 at 11:01 AM, Wayne Stambaugh 
> wrote:
>
>> On 2/24/2017 10:30 AM, Maciej Sumiński wrote:
>> > Most of the operations one can do on a BOARD_ITEM potentially affects
>> > the board bounding box. It means there might be many places where the
>> > notifications should be added.
>> >
>> > Some time ago, Michael Steinberg has put in place OBSERVABLE class
>> > (include/observable.h) that could facilitate the task.
>>
>> It could be useful but I'm not sure it would be a better design than the
>> child object informing it's parent that it's bounding box has changed.
>> I'm not sure the additional code would make the code any more readable.
>> The only benefit would be if other observers were required.
>>
>> >
>> > With the current approach, developers have to guess whether to update
>> > the bounding box with ComputeBoundingBox() or take the cached value.
>> > Update is called in very few places, so I really wonder what kind of
>> > magic makes it work, but I might have missed something here.
>>
>> This solution would require limiting the entry points in the BOARD
>> object that allow changes to the BOARD's child items.  Conceptually this
>> is probably easier to understand but requires developers to be diligent
>> when making changes to the BOARD object or not trying to bypass these
>> entry points.
>>
>> >
>> > Regards,
>> > Orson
>> >
>> > On 02/24/2017 04:06 PM, Wayne Stambaugh wrote:
>> >> Every BOARD_ITEM has a parent/child relationship or at least it did if
>> >> someone did not break it.  You can always find the parent BOARD object
>> >> by walking up the BOARD_ITEM parent list.  There is already a
>> >> BOARD_ITEM::GetBoard() call that should return the parent board.  You
>> >> could use that to notify the BOARD object when a child BOARD_ITEM
>> change
>> >> effects the bounding box.
>> >>
>> >> On 2/24/2017 9:27 AM, Jon Evans wrote:
>> >>> We need a solution that allows GetBoundingBox to be called blindly,
>> >>> without knowing if (or how) an EDA_ITEM subclass needs to have the
>> >>> bounding box updated.
>> >>>
>> >>> Does anyone have ideas about how complicated it would be t

[Kicad-developers] [PATCH] Fix zoom controls in footprint viewer

[Jon Evans]

This got overlooked in common_tools refactor

-Jon
From 5eeb0dbf18477b9358335a0943c0aeb0767307ad Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Tue, 28 Feb 2017 21:58:15 -0500
Subject: [PATCH] Register common tools in footprint viewer to fix zoom
 controls

---
 pcbnew/modview_frame.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/pcbnew/modview_frame.cpp b/pcbnew/modview_frame.cpp
index 5e21d39..7cb3695 100644
--- a/pcbnew/modview_frame.cpp
+++ b/pcbnew/modview_frame.cpp
@@ -55,6 +55,7 @@
 
 #include 
 #include 
+#include 
 #include "tools/pcbnew_control.h"
 #include "tools/pcb_actions.h"
 
@@ -201,6 +202,7 @@ FOOTPRINT_VIEWER_FRAME::FOOTPRINT_VIEWER_FRAME( KIWAY* aKiway, wxWindow* aParent
 drawPanel->SetEventDispatcher( m_toolDispatcher );
 
 m_toolManager->RegisterTool( new PCBNEW_CONTROL );
+m_toolManager->RegisterTool( new COMMON_TOOLS );
 m_toolManager->InitTools();
 
 // If a footprint was previously loaded, reload it
-- 
2.7.4

___
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] Move ZoomFitScreen and ZoomPreset to common

[Jon Evans]

Wayne, Orson's latest patch is basically Option 2 but implemented another
way.  Can you check it out and let us know if you are OK merging it as-is,
or if we should change the implementation to be more like what I described?

Thanks,
Jon

On Wed, Mar 1, 2017 at 8:43 AM, Wayne Stambaugh 
wrote:

> Option 2 seems fine.  It may be easier to just add an option argument to
> the existing GetBoundingBox() function to either return the cached
> bounding box or recalculate the bounding box on demand rather than
> create a different function for the cached vs. uncached version.
>
> On 3/1/2017 2:51 AM, Maciej Sumiński wrote:
> > Wayne, what do you think? If it is acceptable, then I would like to
> > merge the patches. I should not judge my code, as I might be tempted to
> > consider it a good solution.
> >
> > In case my proposal to cache the bounding box in autorouter code is not
> > approved, then I would say #2 would do the job.
> >
> > Cheers,
> > Orson
> >
> > On 03/01/2017 01:23 AM, Jon Evans wrote:
> >> Update: after some more testing, I think Orson's patch on top of mine is
> >> the way to go.  It pulls the computation out of the loops for
> autorouter,
> >> and that's the only place where the board's bounding box is used
> >> repetitively.  Since the other call sites are only going to get the
> >> bounding box intermittently, I don't think it's worth any effort doing
> >> complicated things to track and recompute the bounding box when things
> are
> >> changed.
> >>
> >> So, I think my patch and Orson's should be merged.
> >>
> >> -Jon
> >>
> >> On Tue, Feb 28, 2017 at 6:51 PM, Jon Evans  wrote:
> >>
> >>> I'm finally back to this problem now that I have some other WIP
> committed.
> >>>
> >>> As far as I can tell, there two paths to go down for this problem:
> >>>
> >>> 1) Implement auto-caching of the bounding box.  This requires some
> >>> mechanism to tell BOARD that it needs to update the cache, be it
> OBSERVABLE
> >>> or some other update function added to BOARD_ITEM.  No matter how it's
> >>> done, this method seems not great to me because it requires touching a
> ton
> >>> of code to provide coverage for every possible entry point that could
> end
> >>> up having an effect on the bounding box.
> >>>
> >>> 2) Have two different calls to get the bounding box for an EDA_ITEM,
> one
> >>> that always re-generates the cache and one that just returns a cached
> >>> value.  Update the call sites that hit the bounding box frequently
> >>> (autorouter, etc) to make use of the cached value; keep the call sites
> that
> >>> always re-generate the bounding box in today's code working that way.
> >>> Performance shouldn't be any better or worse than it is now.
> >>>
> >>> 3) Track whether a board is clean/dirty in some other way besides
> looking
> >>> at BOARD_ITEMs.  This might not be practical while we still support
> legacy,
> >>> but once there is only GAL, I could see this maybe being possible
> through
> >>> the tool framework.  For example, actions could be marked as possibly
> >>> impacting the board or not (i.e. move item does, zoom does not)
> >>>
> >>> So, unless someone suggests otherwise, I'm going to try implementing
> #2,
> >>> and suggest #3 as a future improvement that would improve performance
> for
> >>> some edge case operations (i.e. "zoom to fit screen" would be
> instantaneous
> >>> if nothing has modified the board since the last time the bbox was
> cached,
> >>> even on large boards)
> >>>
> >>> -Jon
> >>>
> >>> On Fri, Feb 24, 2017 at 11:01 AM, Wayne Stambaugh <
> stambau...@gmail.com>
> >>> wrote:
> >>>
> >>>> On 2/24/2017 10:30 AM, Maciej Sumiński wrote:
> >>>>> Most of the operations one can do on a BOARD_ITEM potentially affects
> >>>>> the board bounding box. It means there might be many places where the
> >>>>> notifications should be added.
> >>>>>
> >>>>> Some time ago, Michael Steinberg has put in place OBSERVABLE class
> >>>>> (include/observable.h) that could facilitate the task.
> >>>>
> >>>> It could be useful but I'm not sure it would be a better design than
> the

Re: [Kicad-developers] [PATCH] Move ZoomFitScreen and ZoomPreset to common

[Jon Evans]

It was in this thread; I've attached them both again for convenience.  The
"0001-Remove-BOARD-SetBoundingBox.patch" is applied after applying the
other patch.

On Wed, Mar 1, 2017 at 8:59 AM, Wayne Stambaugh 
wrote:

> On 3/1/2017 8:54 AM, Jon Evans wrote:
> > Wayne, Orson's latest patch is basically Option 2 but implemented
> > another way.  Can you check it out and let us know if you are OK merging
> > it as-is, or if we should change the implementation to be more like what
> > I described?
>
> I don't remember seeing this patch.  Was it posted to the dev list?
>
> >
> > Thanks,
> > Jon
> >
> > On Wed, Mar 1, 2017 at 8:43 AM, Wayne Stambaugh  > <mailto:stambau...@gmail.com>> wrote:
> >
> > Option 2 seems fine.  It may be easier to just add an option
> argument to
> > the existing GetBoundingBox() function to either return the cached
> > bounding box or recalculate the bounding box on demand rather than
> > create a different function for the cached vs. uncached version.
> >
> > On 3/1/2017 2:51 AM, Maciej Sumiński wrote:
> > > Wayne, what do you think? If it is acceptable, then I would like to
> > > merge the patches. I should not judge my code, as I might be
> > tempted to
> > > consider it a good solution.
> > >
> > > In case my proposal to cache the bounding box in autorouter code
> > is not
> > > approved, then I would say #2 would do the job.
> > >
> > > Cheers,
> > > Orson
> > >
> > > On 03/01/2017 01:23 AM, Jon Evans wrote:
> > >> Update: after some more testing, I think Orson's patch on top of
> > mine is
> > >> the way to go.  It pulls the computation out of the loops for
> > autorouter,
> > >> and that's the only place where the board's bounding box is used
> > >> repetitively.  Since the other call sites are only going to get
> the
> > >> bounding box intermittently, I don't think it's worth any effort
> > doing
> > >> complicated things to track and recompute the bounding box when
> > things are
> > >> changed.
> > >>
> > >> So, I think my patch and Orson's should be merged.
> > >>
> > >> -Jon
> > >>
> > >> On Tue, Feb 28, 2017 at 6:51 PM, Jon Evans  > <mailto:j...@craftyjon.com>> wrote:
> > >>
> > >>> I'm finally back to this problem now that I have some other WIP
> > committed.
> > >>>
> > >>> As far as I can tell, there two paths to go down for this
> problem:
> > >>>
> > >>> 1) Implement auto-caching of the bounding box.  This requires
> some
> > >>> mechanism to tell BOARD that it needs to update the cache, be it
> > OBSERVABLE
> > >>> or some other update function added to BOARD_ITEM.  No matter
> > how it's
> > >>> done, this method seems not great to me because it requires
> > touching a ton
> > >>> of code to provide coverage for every possible entry point that
> > could end
> > >>> up having an effect on the bounding box.
> > >>>
> > >>> 2) Have two different calls to get the bounding box for an
> > EDA_ITEM, one
> > >>> that always re-generates the cache and one that just returns a
> > cached
> > >>> value.  Update the call sites that hit the bounding box
> frequently
> > >>> (autorouter, etc) to make use of the cached value; keep the call
> > sites that
> > >>> always re-generate the bounding box in today's code working that
> > way.
> > >>> Performance shouldn't be any better or worse than it is now.
> > >>>
> > >>> 3) Track whether a board is clean/dirty in some other way
> > besides looking
> > >>> at BOARD_ITEMs.  This might not be practical while we still
> > support legacy,
> > >>> but once there is only GAL, I could see this maybe being
> > possible through
> > >>> the tool framework.  For example, actions could be marked as
> > possibly
> > >>> impacting the board or not (i.e. move item does, zoom does not)
> > >>>
> 

Re: [Kicad-developers] [Request for Tests] Experimental icon options in Kicad

[Jon Evans]

I think in the "real world" people usually solve this by either using
vector icons or (more commonly I think) using icon formats that store a
number of different resolutions (16x16, 32x32, 48x48, etc) and picking the
best one based on the screen DPI.  (This is how Android works).

The upside is that this lets you make the icons look good at any resolution.
The downside is that now you have to draw 2-3 icons instead of one for each
function...

-Jon

On Wed, Mar 1, 2017 at 2:45 PM, Julius Schmidt  wrote:

> I have a 2560x1440 14" display here. I have no idea what wxWidgets queries
> for "system dpi" (I'm running dwm), but I've tested the icon scaling
> setting.
>
> Since it just scales the bitmaps it looks pretty terrible on this display
> (even on the lowest scaled setting, 1.5).
> Obviously vectorised icons would be best but maybe a better scaling
> algorithm could make it less painful.
>
>
> On Wed, 1 Mar 2017, Wayne Stambaugh wrote:
>
> On 3/1/2017 11:15 AM, jp charras wrote:
>>
>>> Le 01/03/2017 à 15:05, Wayne Stambaugh a écrit :
>>>
 I'm OK with making the menu icons a user option rather than a build time
 option.  I really don't have a preference on this issue so give the
 people what they want.

 The bitmap scaling is a separate issue and needs to be tested by users
 with high dpi displays.  I don't recall anyone reporting back on this
 yet.  I suppose we could make it a build config option and have some
 custom builds available for users to test but I don't want to make this
 a default until we have some input.

>>>
>>> I could commit the menu icons on/off as user option.
>>>
>>
>> I am fine with that if there are no objections.
>>
>>
>>> The bitmap scaling needs to be tested, and is not yet ready for use,
>>> just suitable only for tests.
>>> (It needs more work before committing)
>>>
>>
>> If you know anyone who has a high dpi display, please give them a nudge
>> to test this.  We are getting quite a few users who are using high dpi
>> displays so we need to address this sooner rather than later.
>>
>>
>>>
 On 3/1/2017 7:06 AM, Fabrizio Tappero wrote:

> Hi Guys,
> I do not have a HDPI monitor but I just would like to add that in my
> opinion it might be a good idea to have the option of showing and not
> showing menu icons.
>
> Regarding the resizing I have no opinion.
>
> Cheers
> Fabrizio
>
>
>
>
> On Mon, Feb 27, 2017 at 4:34 PM, Wayne Stambaugh  > wrote:
>
> On 2/21/2017 11:48 AM, Mark Roszko wrote:
>> Ah.
>>
>> I had a better patch for this but I never submitted that scales
> the
>> icons 100% to intended size regardless of the display DPI without
> the
>> need for "size scale options".
>>  wxWidgets has the functions to calcuate the correct scale, it's
> just
>> not exposed
>> to fix bitmaps in 3.0 but its in 3.1. I wrote a simple patch to
> make it
>> work in 3.0.
>>
>> I'll have to go dig it up somewhere
>
> Mark,
>
> If you have a better solution for these please forward it so we
> can take
> a look at it.
>
> Has anyone with a high dpi monitor had a chance to test this yet?
> If so
> please give us some feedback.
>
> Of course I would be more than willing to accept the donation of a
> high
> dpi computer to work on this issue. :)
>
> Thanks,
>
> Wayne
>

>>>
>>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
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] Move ZoomFitScreen and ZoomPreset to common

[Jon Evans]

The caching was only used by the auto router before. Orson's patch
implements local caching in the auto router, and other sites just
regenerate the bbox when they need to retrieve it, which is the same
behavior as before.

We can't add a caching system that didn't exist before without the board
dirty flag that I mentioned would be a ton of work to implement.

-Jon

On Mar 1, 2017 16:25, "Wayne Stambaugh"  wrote:

I thought we were retaining the cached behavior for existing code and
implementing a secondary feature to always recalculate the bounding box.
 It looks to me as though the cached behavior has completely been
removed unless I'm missing something.

On 3/1/2017 9:07 AM, Jon Evans wrote:
> It was in this thread; I've attached them both again for convenience.
> The "0001-Remove-BOARD-SetBoundingBox.patch" is applied after applying
> the other patch.
>
> On Wed, Mar 1, 2017 at 8:59 AM, Wayne Stambaugh  <mailto:stambau...@gmail.com>> wrote:
>
> On 3/1/2017 8:54 AM, Jon Evans wrote:
> > Wayne, Orson's latest patch is basically Option 2 but implemented
> > another way.  Can you check it out and let us know if you are OK
merging
> > it as-is, or if we should change the implementation to be more like
what
> > I described?
>
> I don't remember seeing this patch.  Was it posted to the dev list?
>
> >
> > Thanks,
> > Jon
> >
> > On Wed, Mar 1, 2017 at 8:43 AM, Wayne Stambaugh <
stambau...@gmail.com <mailto:stambau...@gmail.com>
> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>> wrote:
> >
> > Option 2 seems fine.  It may be easier to just add an option
> argument to
> > the existing GetBoundingBox() function to either return the
cached
> > bounding box or recalculate the bounding box on demand rather
than
> > create a different function for the cached vs. uncached version.
> >
> > On 3/1/2017 2:51 AM, Maciej Sumiński wrote:
> > > Wayne, what do you think? If it is acceptable, then I would
> like to
> > > merge the patches. I should not judge my code, as I might be
> > tempted to
> > > consider it a good solution.
> > >
> > > In case my proposal to cache the bounding box in autorouter
code
> > is not
> > > approved, then I would say #2 would do the job.
> > >
> > > Cheers,
> > > Orson
> > >
> > > On 03/01/2017 01:23 AM, Jon Evans wrote:
> > >> Update: after some more testing, I think Orson's patch on
> top of
> > mine is
> > >> the way to go.  It pulls the computation out of the loops for
> > autorouter,
> > >> and that's the only place where the board's bounding box is
> used
> > >> repetitively.  Since the other call sites are only going to
>     get the
> > >> bounding box intermittently, I don't think it's worth any
> effort
> > doing
> > >> complicated things to track and recompute the bounding box
when
> > things are
> > >> changed.
> > >>
> > >> So, I think my patch and Orson's should be merged.
> > >>
> > >> -Jon
> > >>
> > >> On Tue, Feb 28, 2017 at 6:51 PM, Jon Evans
> mailto:j...@craftyjon.com>
> > <mailto:j...@craftyjon.com <mailto:j...@craftyjon.com>>> wrote:
> > >>
> > >>> I'm finally back to this problem now that I have some
> other WIP
> > committed.
> > >>>
> > >>> As far as I can tell, there two paths to go down for this
> problem:
> > >>>
> > >>> 1) Implement auto-caching of the bounding box.  This
> requires some
> > >>> mechanism to tell BOARD that it needs to update the cache,
> be it
> > OBSERVABLE
> > >>> or some other update function added to BOARD_ITEM.  No
matter
> > how it's
> > >>> done, this method seems not great to me because it requires
> > touching a ton
> > >>> of code to provide coverage for every possible entry point
> that
> > could end
> > >>> up having an effect 

Re: [Kicad-developers] [RFC] Logo Consolidation

[Jon Evans]

Oliver, I think the latest version looks super good IMHO.  Nice work.

On Fri, Mar 3, 2017 at 9:48 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Here is a revised version:
>
> http://imgur.com/a/DysJm
>
> On Thu, Mar 2, 2017 at 6:41 PM, Ingo Kletti 
> wrote:
>
>> Hi,
>>
>> I like the use of the schematic/pcb elements.
>>
>> It also looks much better at small scales
>>>
>>
>> I tried the scaling and made a mockup at icon resolutions from 16x16 to
>> 64x64 with 8 pixel steps (16, 24, 32, etc.), see attachment. Scaling works
>> good IMO, but cannot avoid bike-shedding:
>>
>> On the sizes 16x16 to 32x32, the white border around the 'i' looks muddy
>> due to the scaling. Maybe using a brighter orange tone might suffice so
>> that the border can be omitted completely without losing contrast.
>>
>> Cheers,
>>
>> Ingo
>>
>> ___
>> 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] Somes download stats on daily build for PPA

[Jon Evans]

Cool! Are there stats available for the website packages? It would be
interesting to see a comparison of the other OS's and stable vs. daily
builds.

On Fri, Mar 3, 2017 at 1:07 PM, Jean-Samuel Reynaud 
wrote:

> Hi All,
>
> I had made some statistics on downloads for KiCad daily builds. This is
> valid only for PPA (Ubuntu...) on last 3 months.
>
>
> To summarize:
> - Major distribution used by our daily build users:
> Ubuntu xenial (16.04) LTS
>
> - Download are most of them in amd64 arch (95% ~ 5%) except for some old
> distro releases
>
> - Between 4K and 7K downloads per month.
>
>
> Find attached a graphical overview...
>
> Regards,
>
> ___
> 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] GerbView GAL: Ready for alpha testing; need more sample Gerber files

[Jon Evans]

Hi all,

My implementation of GAL into GerbView is far enough along that I would
like people who use GerbView a lot (and have some time) to try building it
and running it.

http://i.imgur.com/W6afbRu.jpg

You can get the code here:
https://github.com/craftyjon/kicad.git branch: gerbview_gal

The following things are still missing and will be implemented before I
consider it ready to merge:

- Selection of items
- Highlighting of items (nets, etc)
- A few edge case painting branches (need your help here with test
material!)
- Some improvements to transparency and a new "diff" display mode that I'm
working on
- DCODE display is currently not done in a good way
- A number of code refactorings should happen under the hood before merge.

I need help now in looking for rendering issues with certain Gerber files.
So far, the files I've tried work fine.  If you have a Gerber file that
throws an ASSERT or displays differently in GAL than it does in legacy,
please let me know, and send me the file if possible!

Thanks,
Jon
___
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] GerbView GAL: Ready for alpha testing; need more sample Gerber files

[Jon Evans]

Dcode should be better now than it was an hour ago, depending on when you
pulled.
I'm working on DCode performance at the moment.

-Jon

On Sat, Mar 4, 2017 at 4:23 PM, Nick Østergaard  wrote:

> Nice.
>
> The D-codes do indeed look funky.
>
> I note that the grid is drawn with lines, not with dots and it is in
> legacy. (In pcbnew we can choose either)
>
> Your branch seems to be much slower than 4.0.5, when zooming i and out
> and having the dcodes enabled.
>
> 2017-03-04 20:35 GMT+01:00 Jon Evans :
> > Hi all,
> >
> > My implementation of GAL into GerbView is far enough along that I would
> like
> > people who use GerbView a lot (and have some time) to try building it and
> > running it.
> >
> > http://i.imgur.com/W6afbRu.jpg
> >
> > You can get the code here:
> > https://github.com/craftyjon/kicad.git branch: gerbview_gal
> >
> > The following things are still missing and will be implemented before I
> > consider it ready to merge:
> >
> > - Selection of items
> > - Highlighting of items (nets, etc)
> > - A few edge case painting branches (need your help here with test
> > material!)
> > - Some improvements to transparency and a new "diff" display mode that
> I'm
> > working on
> > - DCODE display is currently not done in a good way
> > - A number of code refactorings should happen under the hood before
> merge.
> >
> > I need help now in looking for rendering issues with certain Gerber
> files.
> > So far, the files I've tried work fine.  If you have a Gerber file that
> > throws an ASSERT or displays differently in GAL than it does in legacy,
> > please let me know, and send me the file if possible!
> >
> > Thanks,
> > Jon
> >
> > ___
> > 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] GerbView GAL: Ready for alpha testing; need more sample Gerber files

[Jon Evans]

A few more notes:

- Grid settings hasn't been added in the GUI yet; I'll be taking that from
pcbnew so user can pick dot/line/small
- Negative items don't work in Cairo canvas yet.

On Sat, Mar 4, 2017 at 4:28 PM, Jon Evans  wrote:

> Dcode should be better now than it was an hour ago, depending on when you
> pulled.
> I'm working on DCode performance at the moment.
>
> -Jon
>
> On Sat, Mar 4, 2017 at 4:23 PM, Nick Østergaard  wrote:
>
>> Nice.
>>
>> The D-codes do indeed look funky.
>>
>> I note that the grid is drawn with lines, not with dots and it is in
>> legacy. (In pcbnew we can choose either)
>>
>> Your branch seems to be much slower than 4.0.5, when zooming i and out
>> and having the dcodes enabled.
>>
>> 2017-03-04 20:35 GMT+01:00 Jon Evans :
>> > Hi all,
>> >
>> > My implementation of GAL into GerbView is far enough along that I would
>> like
>> > people who use GerbView a lot (and have some time) to try building it
>> and
>> > running it.
>> >
>> > http://i.imgur.com/W6afbRu.jpg
>> >
>> > You can get the code here:
>> > https://github.com/craftyjon/kicad.git branch: gerbview_gal
>> >
>> > The following things are still missing and will be implemented before I
>> > consider it ready to merge:
>> >
>> > - Selection of items
>> > - Highlighting of items (nets, etc)
>> > - A few edge case painting branches (need your help here with test
>> > material!)
>> > - Some improvements to transparency and a new "diff" display mode that
>> I'm
>> > working on
>> > - DCODE display is currently not done in a good way
>> > - A number of code refactorings should happen under the hood before
>> merge.
>> >
>> > I need help now in looking for rendering issues with certain Gerber
>> files.
>> > So far, the files I've tried work fine.  If you have a Gerber file that
>> > throws an ASSERT or displays differently in GAL than it does in legacy,
>> > please let me know, and send me the file if possible!
>> >
>> > Thanks,
>> > Jon
>> >
>> > ___
>> > 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] GerbView GAL: Ready for alpha testing; need more sample Gerber files

[Jon Evans]

Sounds good. For now I just did a quick edit to allow choosing grid style,
but I'll wait for your new settings widget rather than porting any more GAL
settings GUI.

Thanks,
Jon

On Mar 5, 2017 15:52, "John Beard"  wrote:

On 4 March 2017 21:37:56 GMT+00:00, Jon Evans  wrote:
>A few more notes:
>
>- Grid settings hasn't been added in the GUI yet; I'll be taking that
>from
>pcbnew so user can pick dot/line/small

Hi Jon,

I haven't had a chance to recompile yet (full disclosure!) but this
sounds great.

For the GAL settings, I was planning to break out the GAL settings
from the Pcbnew Display Settings dialog into a reusable widget than
can be embedded into tabs in each GAL-enabled program and acts on a
passed-on GAL_DISPLAY_OPTIONS instance. Currently the footprint editor
also lacks grid style control as well.

Having to separately add all GAL-specific display options to each
dialog would otherwise become a bit of a maintenance headache.

Cheers,

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

Re: [Kicad-developers] GerbView GAL: Ready for alpha testing; need more sample Gerber files

[Jon Evans]

Hi JP,
Thanks for the tip, I hadn't noticed the test files.

I now get all tests passing except for the ones related to negative images
and objects... there are still problems there to solve (working on it).  In
fact, it looks to me like we now can draw a few things properly that were
not drawn properly in 4.x!

Best,
Jon

On Mon, Mar 6, 2017 at 10:55 AM, jp charras  wrote:

> Le 04/03/2017 à 20:35, Jon Evans a écrit :
> > Hi all,
> >
> > My implementation of GAL into GerbView is far enough along that I would
> like people who use GerbView
> > a lot (and have some time) to try building it and running it.
> >
> > http://i.imgur.com/W6afbRu.jpg
> >
> > You can get the code here:
> > https://github.com/craftyjon/kicad.git branch: gerbview_gal
> >
> > The following things are still missing and will be implemented before I
> consider it ready to merge:
> >
> > - Selection of items
> > - Highlighting of items (nets, etc)
> > - A few edge case painting branches (need your help here with test
> material!)
> > - Some improvements to transparency and a new "diff" display mode that
> I'm working on
> > - DCODE display is currently not done in a good way
> > - A number of code refactorings should happen under the hood before
> merge.
> >
> > I need help now in looking for rendering issues with certain Gerber
> files.  So far, the files I've
> > tried work fine.  If you have a Gerber file that throws an ASSERT or
> displays differently in GAL
> > than it does in legacy, please let me know, and send me the file if
> possible!
> >
> > Thanks,
> > Jon
>
> Thanks Jon, for this important work.
>
> You have  many test files in /gerbview/gerber_test_files
>
> Each file is a test for a given Gerber feature.
>
> Currently, apertures from aperture macros are not displayed in GAL mode.
>
> --
> 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] GerbView GAL: Ready for alpha testing; need more sample Gerber files

[Jon Evans]

In aperture-circle-flash-with_hole.gbr, one of the holes should be square.
They are all drawn as circular in 4.x as well as in master, but now
correctly drawn with square hole in my branch.

In apertures_rotated_and_arcs_in_tracks.gbr, some weird artifacts show up
in 4.x in Linux, but I can't reproduce them in Windows. No artifacts in my
branch on GAL canvas.  This one I want to investigate some more.

As far as I can tell, negative objects work properly in legacy master
branch (not sure about 4.0), but they don't work properly in my branch
yet.  For negative images, I guess I will need to create a "backdrop"
object that the image objects can cut into, since in legacy it just uses
the wxDC background to cut away from.

Best,
Jon

On Tue, Mar 7, 2017 at 2:15 AM, Nick Østergaard  wrote:

> Which things?
>
> 2017-03-07 4:40 GMT+01:00 Jon Evans :
> > Hi JP,
> > Thanks for the tip, I hadn't noticed the test files.
> >
> > I now get all tests passing except for the ones related to negative
> images
> > and objects... there are still problems there to solve (working on it).
> In
> > fact, it looks to me like we now can draw a few things properly that were
> > not drawn properly in 4.x!
> >
> > Best,
> > Jon
> >
> > On Mon, Mar 6, 2017 at 10:55 AM, jp charras 
> wrote:
> >>
> >> Le 04/03/2017 à 20:35, Jon Evans a écrit :
> >> > Hi all,
> >> >
> >> > My implementation of GAL into GerbView is far enough along that I
> would
> >> > like people who use GerbView
> >> > a lot (and have some time) to try building it and running it.
> >> >
> >> > http://i.imgur.com/W6afbRu.jpg
> >> >
> >> > You can get the code here:
> >> > https://github.com/craftyjon/kicad.git branch: gerbview_gal
> >> >
> >> > The following things are still missing and will be implemented before
> I
> >> > consider it ready to merge:
> >> >
> >> > - Selection of items
> >> > - Highlighting of items (nets, etc)
> >> > - A few edge case painting branches (need your help here with test
> >> > material!)
> >> > - Some improvements to transparency and a new "diff" display mode that
> >> > I'm working on
> >> > - DCODE display is currently not done in a good way
> >> > - A number of code refactorings should happen under the hood before
> >> > merge.
> >> >
> >> > I need help now in looking for rendering issues with certain Gerber
> >> > files.  So far, the files I've
> >> > tried work fine.  If you have a Gerber file that throws an ASSERT or
> >> > displays differently in GAL
> >> > than it does in legacy, please let me know, and send me the file if
> >> > possible!
> >> >
> >> > Thanks,
> >> > Jon
> >>
> >> Thanks Jon, for this important work.
> >>
> >> You have  many test files in /gerbview/gerber_test_files
> >>
> >> Each file is a test for a given Gerber feature.
> >>
> >> Currently, apertures from aperture macros are not displayed in GAL mode.
> >>
> >> --
> >> 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] [PATCH] Add setting to have GAL draw axes on the grid

[Jon Evans]

Hi all,

This patch adds the ability for GAL to draw axes when drawing the grid.
Right now this is only going to be used for GerbView.

Best,
Jon
From 384c6e7ca96421645f69976f695e52733b424469 Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Tue, 7 Mar 2017 21:33:19 -0500
Subject: [PATCH] Add setting to have GAL draw axes on the grid

---
 common/gal/cairo/cairo_gal.cpp|  3 ++-
 common/gal/gal_display_options.cpp| 10 +-
 common/gal/graphics_abstraction_layer.cpp | 21 +
 common/gal/opengl/opengl_gal.cpp  | 19 +++
 include/gal/gal_display_options.h |  3 +++
 include/gal/graphics_abstraction_layer.h  | 12 
 6 files changed, 66 insertions(+), 2 deletions(-)

diff --git a/common/gal/cairo/cairo_gal.cpp b/common/gal/cairo/cairo_gal.cpp
index e499c9b..060c411 100644
--- a/common/gal/cairo/cairo_gal.cpp
+++ b/common/gal/cairo/cairo_gal.cpp
@@ -87,6 +87,7 @@ CAIRO_GAL::CAIRO_GAL( GAL_DISPLAY_OPTIONS& aDisplayOptions,
 
 // Grid color settings are different in Cairo and OpenGL
 SetGridColor( COLOR4D( 0.1, 0.1, 0.1, 0.8 ) );
+SetAxesColor( COLOR4D( BLUE ) );
 
 // Allocate memory for pixel storage
 allocateBitmaps();
@@ -825,7 +826,7 @@ void CAIRO_GAL::drawGridLine( const VECTOR2D& aStartPoint, const VECTOR2D& aEndP
 {
 cairo_move_to( currentContext, aStartPoint.x, aStartPoint.y );
 cairo_line_to( currentContext, aEndPoint.x, aEndPoint.y );
-cairo_set_source_rgba( currentContext, gridColor.r, gridColor.g, gridColor.b, strokeColor.a );
+cairo_set_source_rgba( currentContext, strokeColor.r, strokeColor.g, strokeColor.b, strokeColor.a );
 cairo_stroke( currentContext );
 }
 
diff --git a/common/gal/gal_display_options.cpp b/common/gal/gal_display_options.cpp
index 3df7c3c..803adf3 100644
--- a/common/gal/gal_display_options.cpp
+++ b/common/gal/gal_display_options.cpp
@@ -35,6 +35,7 @@ static const wxString GalGLAntialiasingKeyword( "OpenGLAntialiasingMode" );
 static const wxString GalGridStyleConfig( "GridStyle" );
 static const wxString GalGridLineWidthConfig( "GridLineWidth" );
 static const wxString GalGridMaxDensityConfig( "GridMaxDensity" );
+static const wxString GalGridAxesEnabledConfig( "GridAxesEnabled" );
 
 
 static const UTIL::CFG_MAP aaModeConfigVals =
@@ -59,7 +60,8 @@ GAL_DISPLAY_OPTIONS::GAL_DISPLAY_OPTIONS()
 : gl_antialiasing_mode( OPENGL_ANTIALIASING_MODE::NONE ),
   m_gridStyle( GRID_STYLE::DOTS ),
   m_gridLineWidth( 0.5 ),
-  m_gridMinSpacing( 10 )
+  m_gridMinSpacing( 10 ),
+  m_axesEnabled( false )
 {}
 
 
@@ -81,6 +83,9 @@ void GAL_DISPLAY_OPTIONS::ReadConfig( wxConfigBase* aCfg, wxString aBaseName )
 aCfg->Read( aBaseName + GalGridMaxDensityConfig,
 &m_gridMinSpacing, 10 );
 
+aCfg->Read( aBaseName + GalGridAxesEnabledConfig,
+&m_axesEnabled, false );
+
 NotifyChanged();
 }
 
@@ -98,6 +103,9 @@ void GAL_DISPLAY_OPTIONS::WriteConfig( wxConfigBase* aCfg, wxString aBaseName )
 
 aCfg->Write( aBaseName + GalGridMaxDensityConfig,
  m_gridMinSpacing );
+
+aCfg->Write( aBaseName + GalGridAxesEnabledConfig,
+ m_axesEnabled );
 }
 
 
diff --git a/common/gal/graphics_abstraction_layer.cpp b/common/gal/graphics_abstraction_layer.cpp
index f9182f7..3d83d05 100644
--- a/common/gal/graphics_abstraction_layer.cpp
+++ b/common/gal/graphics_abstraction_layer.cpp
@@ -110,6 +110,12 @@ bool GAL::updatedGalDisplayOptions( const GAL_DISPLAY_OPTIONS& aOptions )
 refresh = true;
 }
 
+if( options.m_axesEnabled != axesEnabled )
+{
+axesEnabled = options.m_axesEnabled;
+refresh = true;
+}
+
 // tell the derived class if the base class needs an update or not
 return refresh;
 }
@@ -335,6 +341,21 @@ void GAL::DrawGrid()
 }
 }
 }
+
+// Draw axes if desired
+if( axesEnabled )
+{
+SetIsFill( false );
+SetIsStroke( true );
+SetStrokeColor( axesColor );
+SetLineWidth( marker );
+
+drawGridLine( VECTOR2D( worldStartPoint.x, 0 ),
+  VECTOR2D( worldEndPoint.x, 0 ) );
+
+drawGridLine( VECTOR2D( 0, worldStartPoint.y ),
+  VECTOR2D( 0, worldEndPoint.y ) );
+}
 }
 
 
diff --git a/common/gal/opengl/opengl_gal.cpp b/common/gal/opengl/opengl_gal.cpp
index 8a6ddf0..b0f2e62 100644
--- a/common/gal/opengl/opengl_gal.cpp
+++ b/common/gal/opengl/opengl_gal.cpp
@@ -129,6 +129,7 @@ OPENGL_GAL::OPENGL_GAL( GAL_DISPLAY_OPTIONS& aDisplayOptions, wxWindow* aParent,
 
 // Grid color settings are different in Cairo and OpenGL
 SetGridColor( COLOR4D( 0.8, 0.8, 0.8, 0.1 ) );
+SetAxesColor( COLOR4D( BLUE ) );
 
 // Tesselator initialization
 tesselator = gluNewTess();
@@ -994,6 +995,24 @@ void OPENGL_GAL::DrawGrid()
   

[Kicad-developers] [PATCH] Add method to GAL for drawing arc segments

[Jon Evans]

This new GAL API is needed for drawing outlined arc segments (like
DrawSegment() does for straight segments) because the current API DrawArc()
treats filled arcs like pie pieces, which is not what is needed for
GerbView.

Best,
Jon
From 596b288c755b8f2034cf0a50370243be9d02869d Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Wed, 8 Mar 2017 21:44:48 -0500
Subject: [PATCH] Add DrawArcSegment() GAL method, to support drawing outlined
 arcs

---
 common/gal/cairo/cairo_gal.cpp   | 47 +
 common/gal/opengl/opengl_gal.cpp | 90 
 include/gal/cairo/cairo_gal.h|  4 ++
 include/gal/graphics_abstraction_layer.h | 17 ++
 include/gal/opengl/opengl_gal.h  |  4 ++
 5 files changed, 162 insertions(+)

diff --git a/common/gal/cairo/cairo_gal.cpp b/common/gal/cairo/cairo_gal.cpp
index 060c411..61f78c0 100644
--- a/common/gal/cairo/cairo_gal.cpp
+++ b/common/gal/cairo/cairo_gal.cpp
@@ -199,6 +199,8 @@ void CAIRO_GAL::DrawSegment( const VECTOR2D& aStartPoint, const VECTOR2D& aEndPo
 
 cairo_save( currentContext );
 
+cairo_set_source_rgba( currentContext, strokeColor.r, strokeColor.g, strokeColor.b, strokeColor.a );
+
 cairo_translate( currentContext, aStartPoint.x, aStartPoint.y );
 cairo_rotate( currentContext, lineAngle );
 
@@ -255,6 +257,51 @@ void CAIRO_GAL::DrawArc( const VECTOR2D& aCenterPoint, double aRadius, double aS
 }
 
 
+void CAIRO_GAL::DrawArcSegment( const VECTOR2D& aCenterPoint, double aRadius, double aStartAngle,
+double aEndAngle, double aWidth )
+{
+SWAP( aStartAngle, >, aEndAngle );
+
+if( isFillEnabled )
+{
+cairo_arc( currentContext, aCenterPoint.x, aCenterPoint.y, aRadius, aStartAngle, aEndAngle );
+cairo_set_source_rgba( currentContext, fillColor.r, fillColor.g, fillColor.b, fillColor.a );
+cairo_stroke( currentContext );
+}
+else
+{
+double width = aWidth / 2.0;
+VECTOR2D startPoint( cos( aStartAngle ) * aRadius,
+ sin( aStartAngle ) * aRadius );
+VECTOR2D endPoint( cos( aEndAngle ) * aRadius,
+   sin( aEndAngle ) * aRadius );
+
+cairo_save( currentContext );
+
+cairo_set_source_rgba( currentContext, strokeColor.r, strokeColor.g, strokeColor.b, strokeColor.a );
+
+cairo_translate( currentContext, aCenterPoint.x, aCenterPoint.y );
+
+cairo_new_sub_path( currentContext );
+cairo_arc( currentContext, 0, 0, aRadius - width, aStartAngle, aEndAngle );
+
+cairo_new_sub_path( currentContext );
+cairo_arc( currentContext, 0, 0, aRadius + width, aStartAngle, aEndAngle );
+
+cairo_new_sub_path( currentContext );
+cairo_arc_negative( currentContext, startPoint.x, startPoint.y, width, aStartAngle, aStartAngle + M_PI );
+
+cairo_new_sub_path( currentContext );
+cairo_arc( currentContext, endPoint.x, endPoint.y, width, aEndAngle, aEndAngle + M_PI );
+
+cairo_restore( currentContext );
+flushPath();
+}
+
+isElementAdded = true;
+}
+
+
 void CAIRO_GAL::DrawRectangle( const VECTOR2D& aStartPoint, const VECTOR2D& aEndPoint )
 {
 // Calculate the diagonal points
diff --git a/common/gal/opengl/opengl_gal.cpp b/common/gal/opengl/opengl_gal.cpp
index 1a98b8b..1c1781d 100644
--- a/common/gal/opengl/opengl_gal.cpp
+++ b/common/gal/opengl/opengl_gal.cpp
@@ -589,6 +589,96 @@ void OPENGL_GAL::DrawArc( const VECTOR2D& aCenterPoint, double aRadius, double a
 }
 
 
+void OPENGL_GAL::DrawArcSegment( const VECTOR2D& aCenterPoint, double aRadius, double aStartAngle,
+ double aEndAngle, double aWidth )
+{
+if( aRadius <= 0 )
+return;
+
+// Swap the angles, if start angle is greater than end angle
+SWAP( aStartAngle, >, aEndAngle );
+
+const double alphaIncrement = 2.0 * M_PI / CIRCLE_POINTS;
+
+Save();
+currentManager->Translate( aCenterPoint.x, aCenterPoint.y, 0.0 );
+
+if( isStrokeEnabled )
+{
+currentManager->Color( strokeColor.r, strokeColor.g, strokeColor.b, strokeColor.a );
+
+double width = aWidth / 2.0;
+VECTOR2D startPoint( cos( aStartAngle ) * aRadius,
+ sin( aStartAngle ) * aRadius );
+VECTOR2D endPoint( cos( aEndAngle ) * aRadius,
+   sin( aEndAngle ) * aRadius );
+
+drawStrokedSemiCircle( startPoint, width, aStartAngle + M_PI );
+drawStrokedSemiCircle( endPoint, width, aEndAngle );
+
+VECTOR2D pOuter( cos( aStartAngle ) * ( aRadius + width ),
+ sin( aStartAngle ) * ( aRadius + width ) );
+
+VECTOR2D pInner( cos( aStartAngle ) * ( aRadius - width ),
+ sin( aStartAngle ) * ( aRadius - width ) );
+
+double alpha;
+
+for( alpha = aStartAn

Re: [Kicad-developers] Footprint preview panel - faster initialization (Tom?)

[Jon Evans]

Hi Chris,

I'm not an expert, but based on what I've learned playing with GAL so far...
As it stands right now, you will have to keep around an EDA_DRAW_PANEL_GAL,
because as far as I can tell there is too much interdependence between the
underlying GAL context, VIEW, and the draw panel.
I am not familiar enough with wxWidgets to know what would happen if you
tried to keep a single draw panel widget around, and attach/detach it from
the component selector dynamically.  But, if that is supported, you should
be able to have your GAL panel start/stop drawing as needed.

-Jon

On Thu, Mar 9, 2017 at 2:27 PM, Chris Pavlina 
wrote:

> I'm trying to speed up my new component selector, since the previous one
> loaded and searched so quickly. I don't want a serious efficiency
> regression in one of the most used dialogs in eeschema.
>
> Since optimizing the column sizing cache and data sorting, the slowest
> part is now loading FOOTPRINT_PREVIEW_PANEL, which has to initialize a
> GAL.
>
> Tom/Orson/anyone else who knows GAL - can you think of a reasonable way
> to either speed up the initialization or retain an initialized copy
> between dialog invocations? I'm thinking about just keeping the dialog
> in memory all the time and hiding it when not in use instead of
> destroying and reinstantiating it - will this cause any problems with
> GAL no longer having something to draw to? (Bear in mind I'm unfamiliar
> with both GAL and how wxWidgets handles graphics here.)
>
> If it provides any relevant information, I'm currently forcing Cairo
> mode in the component selector, to avoid having to deal with graphics
> support in a simple dialog (since drawing efficiency is not required).
>
> --
> Chris
>
> ___
> 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] refactor BRIGHT_BOX to common

[Jon Evans]

Hi,

Quick refactor to allow use of BRIGHT_BOX from GerbView

Best,
Jon
From 527b2cd85e0ef9249e552577cfe07054b363cc88 Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Sat, 11 Mar 2017 00:46:03 -0500
Subject: [PATCH] Refactor BRIGHT_BOX to common so it can be used by other
 programs

---
 common/CMakeLists.txt   |  1 +
 common/tool/bright_box.cpp  | 64 ++
 include/tool/bright_box.h   | 99 +
 pcbnew/CMakeLists.txt   |  2 +-
 pcbnew/tools/bright_box.cpp | 72 --
 pcbnew/tools/bright_box.h   | 87 
 pcbnew/tools/pcb_bright_box.cpp | 63 ++
 pcbnew/tools/pcb_bright_box.h   | 48 
 pcbnew/tools/selection_tool.cpp |  4 +-
 9 files changed, 278 insertions(+), 162 deletions(-)
 create mode 100644 common/tool/bright_box.cpp
 create mode 100644 include/tool/bright_box.h
 delete mode 100644 pcbnew/tools/bright_box.cpp
 delete mode 100644 pcbnew/tools/bright_box.h
 create mode 100644 pcbnew/tools/pcb_bright_box.cpp
 create mode 100644 pcbnew/tools/pcb_bright_box.h

diff --git a/common/CMakeLists.txt b/common/CMakeLists.txt
index ce319cd..8a7c27e 100644
--- a/common/CMakeLists.txt
+++ b/common/CMakeLists.txt
@@ -318,6 +318,7 @@ set( COMMON_SRCS
 tool/tool_menu.cpp
 tool/conditional_menu.cpp
 tool/selection_conditions.cpp
+tool/bright_box.cpp
 
 geometry/seg.cpp
 geometry/shape.cpp
diff --git a/common/tool/bright_box.cpp b/common/tool/bright_box.cpp
new file mode 100644
index 000..d5f0fcd
--- /dev/null
+++ b/common/tool/bright_box.cpp
@@ -0,0 +1,64 @@
+/*
+ * This program source code file is part of KiCad, a free EDA CAD application.
+ *
+ * Copyright (C) 2013 CERN
+ * @author Maciej Suminski 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, you may find one here:
+ * http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
+ * or you may search the http://www.gnu.org website for the version 2 license,
+ * or you may write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA
+ */
+
+#include 
+#include 
+#include 
+
+using namespace KIGFX;
+
+const double BRIGHT_BOX::LINE_WIDTH = 1.0;
+const COLOR4D BRIGHT_BOX::BOX_COLOR = KIGFX::COLOR4D( 0.0, 1.0, 0.0, 1.0 );
+
+BRIGHT_BOX::BRIGHT_BOX() :
+EDA_ITEM( NOT_USED ),// this item is never added to a BOARD so it needs no type
+m_item( nullptr ),
+m_lineWidth( LINE_WIDTH ),
+m_color( BOX_COLOR )
+{
+}
+
+
+void BRIGHT_BOX::ViewDraw( int aLayer, KIGFX::VIEW* aView ) const
+{
+if( !m_item )
+return;
+
+auto gal = aView->GetGAL();
+
+gal->SetIsStroke( true );
+gal->SetIsFill( false );
+gal->SetLineWidth( m_lineWidth );
+gal->SetStrokeColor( m_color );
+
+BOX2I box = m_item->ViewBBox();
+
+gal->DrawRectangle( box.GetOrigin(), box.GetOrigin() + box.GetSize() );
+}
+
+
+void BRIGHT_BOX::SetItem( EDA_ITEM* aItem )
+{
+m_item = aItem;
+}
diff --git a/include/tool/bright_box.h b/include/tool/bright_box.h
new file mode 100644
index 000..9e177cf
--- /dev/null
+++ b/include/tool/bright_box.h
@@ -0,0 +1,99 @@
+/*
+ * This program source code file is part of KiCad, a free EDA CAD application.
+ *
+ * Copyright (C) 2013 CERN
+ * @author Maciej Suminski 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, you may find one here:
+ * http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
+ * or you may search the http://www.gnu.org website for the version 2 license,
+ * or you may write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA
+ */
+
+#ifndef __BRIGHT_BOX_H
+#define __BRIGHT_BOX_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**

Re: [Kicad-developers] [PATCH] refactor BRIGHT_BOX to common

[Jon Evans]

Hi John, you are right!  It was late and I didn't remember about your new
directory but it's totally the right place.  Updated patch attached.

Thanks,
Jon

On Sat, Mar 11, 2017 at 7:09 AM, John Beard  wrote:

> Hi Jon,
>
> This looks like something that could live in common/preview_items,
> which is where I put  "transient" EDA_ITEMs (i.e. constructed with
> NOT_USED) that are theoretically useful for any GAL canvas. So far,
> the ruler overlay, and SELECTION_AREA are living there, but I have a
> couple more in the pipeline.
>
> Not critical, just a thought while the file is being moved anyway.
>
> Cheers,
>
> John
>
> On Sat, Mar 11, 2017 at 1:47 PM, Jon Evans  wrote:
> > Hi,
> >
> > Quick refactor to allow use of BRIGHT_BOX from GerbView
> >
> > Best,
> > Jon
> >
> > ___
> > 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
> >
>
From a86f4bbe5db1153f9a5a09ebdb60e1604b2b1cb3 Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Sat, 11 Mar 2017 00:46:03 -0500
Subject: [PATCH 1/2] Refactor BRIGHT_BOX to common so it can be used by other
 programs

---
 common/CMakeLists.txt   |  1 +
 common/preview_items/bright_box.cpp | 64 
 include/tool/bright_box.h   | 99 +
 pcbnew/CMakeLists.txt   |  2 +-
 pcbnew/tools/bright_box.cpp | 72 ---
 pcbnew/tools/bright_box.h   | 87 
 pcbnew/tools/pcb_bright_box.cpp | 63 +++
 pcbnew/tools/pcb_bright_box.h   | 48 ++
 pcbnew/tools/selection_tool.cpp |  4 +-
 9 files changed, 278 insertions(+), 162 deletions(-)
 create mode 100644 common/preview_items/bright_box.cpp
 create mode 100644 include/tool/bright_box.h
 delete mode 100644 pcbnew/tools/bright_box.cpp
 delete mode 100644 pcbnew/tools/bright_box.h
 create mode 100644 pcbnew/tools/pcb_bright_box.cpp
 create mode 100644 pcbnew/tools/pcb_bright_box.h

diff --git a/common/CMakeLists.txt b/common/CMakeLists.txt
index ce319cd..373ee33 100644
--- a/common/CMakeLists.txt
+++ b/common/CMakeLists.txt
@@ -188,6 +188,7 @@ set( COMMON_PREVIEW_ITEMS_SRCS
 preview_items/ruler_item.cpp
 preview_items/simple_overlay_item.cpp
 preview_items/selection_area.cpp
+preview_items/bright_box.cpp
 )
 
 set( COMMON_SRCS
diff --git a/common/preview_items/bright_box.cpp b/common/preview_items/bright_box.cpp
new file mode 100644
index 000..d5f0fcd
--- /dev/null
+++ b/common/preview_items/bright_box.cpp
@@ -0,0 +1,64 @@
+/*
+ * This program source code file is part of KiCad, a free EDA CAD application.
+ *
+ * Copyright (C) 2013 CERN
+ * @author Maciej Suminski 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, you may find one here:
+ * http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
+ * or you may search the http://www.gnu.org website for the version 2 license,
+ * or you may write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA
+ */
+
+#include 
+#include 
+#include 
+
+using namespace KIGFX;
+
+const double BRIGHT_BOX::LINE_WIDTH = 1.0;
+const COLOR4D BRIGHT_BOX::BOX_COLOR = KIGFX::COLOR4D( 0.0, 1.0, 0.0, 1.0 );
+
+BRIGHT_BOX::BRIGHT_BOX() :
+EDA_ITEM( NOT_USED ),// this item is never added to a BOARD so it needs no type
+m_item( nullptr ),
+m_lineWidth( LINE_WIDTH ),
+m_color( BOX_COLOR )
+{
+}
+
+
+void BRIGHT_BOX::ViewDraw( int aLayer, KIGFX::VIEW* aView ) const
+{
+if( !m_item )
+return;
+
+auto gal = aView->GetGAL();
+
+gal->SetIsStroke( true );
+gal->SetIsFill( false );
+gal->SetLineWidth( m_lineWidth );
+gal->SetStrokeColor( m_color );
+
+BOX2I box = m_item->ViewBBox();
+
+gal->DrawRectangle( box.GetOrigin(), box.GetOrigin() + box.GetSize() );
+}
+
+
+void BRIGHT_BOX::SetItem( EDA_ITEM* aItem )
+{
+m_item = aItem;
+}
diff --git a/include/tool/bright_box.h b/include/tool/bright_box.h
new file mode 100644
index 000..9e177cf
--- /dev/nu

Re: [Kicad-developers] [PATCH] refactor BRIGHT_BOX to common

[Jon Evans]

Oops! Yes, thanks.

On Sat, Mar 11, 2017 at 12:35 PM, Chris Pavlina 
wrote:

> I assume you want the header in include/preview_items as well, right?
>
> On Sat, Mar 11, 2017 at 08:54:11AM -0500, Jon Evans wrote:
> > Hi John, you are right!  It was late and I didn't remember about your new
> > directory but it's totally the right place.  Updated patch attached.
> >
> > Thanks,
> > Jon
> >
> > On Sat, Mar 11, 2017 at 7:09 AM, John Beard 
> wrote:
> >
> > > Hi Jon,
> > >
> > > This looks like something that could live in common/preview_items,
> > > which is where I put  "transient" EDA_ITEMs (i.e. constructed with
> > > NOT_USED) that are theoretically useful for any GAL canvas. So far,
> > > the ruler overlay, and SELECTION_AREA are living there, but I have a
> > > couple more in the pipeline.
> > >
> > > Not critical, just a thought while the file is being moved anyway.
> > >
> > > Cheers,
> > >
> > > John
> > >
> > > On Sat, Mar 11, 2017 at 1:47 PM, Jon Evans  wrote:
> > > > Hi,
> > > >
> > > > Quick refactor to allow use of BRIGHT_BOX from GerbView
> > > >
> > > > Best,
> > > > Jon
> > > >
> > > > ___
> > > > 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
> > > >
> > >
>
>
From 01800b7e78bb872629e6cd43ae4366ebe89006df Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Sat, 11 Mar 2017 00:46:03 -0500
Subject: [PATCH 1/5] Refactor BRIGHT_BOX to common so it can be used by other
 programs

---
 common/CMakeLists.txt   |  1 +
 common/preview_items/bright_box.cpp | 64 
 include/preview_items/bright_box.h  | 99 +
 pcbnew/CMakeLists.txt   |  2 +-
 pcbnew/tools/bright_box.cpp | 72 ---
 pcbnew/tools/bright_box.h   | 87 
 pcbnew/tools/pcb_bright_box.cpp | 63 +++
 pcbnew/tools/pcb_bright_box.h   | 48 ++
 pcbnew/tools/selection_tool.cpp |  4 +-
 9 files changed, 278 insertions(+), 162 deletions(-)
 create mode 100644 common/preview_items/bright_box.cpp
 create mode 100644 include/preview_items/bright_box.h
 delete mode 100644 pcbnew/tools/bright_box.cpp
 delete mode 100644 pcbnew/tools/bright_box.h
 create mode 100644 pcbnew/tools/pcb_bright_box.cpp
 create mode 100644 pcbnew/tools/pcb_bright_box.h

diff --git a/common/CMakeLists.txt b/common/CMakeLists.txt
index ce319cd..373ee33 100644
--- a/common/CMakeLists.txt
+++ b/common/CMakeLists.txt
@@ -188,6 +188,7 @@ set( COMMON_PREVIEW_ITEMS_SRCS
 preview_items/ruler_item.cpp
 preview_items/simple_overlay_item.cpp
 preview_items/selection_area.cpp
+preview_items/bright_box.cpp
 )
 
 set( COMMON_SRCS
diff --git a/common/preview_items/bright_box.cpp b/common/preview_items/bright_box.cpp
new file mode 100644
index 000..cc55dfa
--- /dev/null
+++ b/common/preview_items/bright_box.cpp
@@ -0,0 +1,64 @@
+/*
+ * This program source code file is part of KiCad, a free EDA CAD application.
+ *
+ * Copyright (C) 2013 CERN
+ * @author Maciej Suminski 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, you may find one here:
+ * http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
+ * or you may search the http://www.gnu.org website for the version 2 license,
+ * or you may write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA
+ */
+
+#include 
+#include 
+#include 
+
+using namespace KIGFX;
+
+const double BRIGHT_BOX::LINE_WIDTH = 1.0;
+const COLOR4D BRIGHT_BOX::BOX_COLOR = KIGFX::COLOR4D( 0.0, 1.0, 0.0, 1.0 );
+
+BRIGHT_BOX::BRIGHT_BOX() :
+EDA_ITEM( NOT_USED ),// this item is never added to a BOARD so it needs no type
+m_item( nullptr ),
+m_lineWidth( LINE_WIDTH ),
+m_color( BOX_COLOR )
+{
+}
+
+
+void 

Re: [Kicad-developers] [PATCH] refactor BRIGHT_BOX to common

[Jon Evans]

Hi Orson, I kept it as you as I basically just cut your code in half and
put part in another file. But feel free to change it to me or kicad
developers if you wish!

Thanks,
Jon


On Mar 11, 2017 15:33, "Maciej Suminski"  wrote:

Hi Jon,

There are new files (pcb_bright_box.*) that say I am the author, but it
would be unfair of me to take credit for someone else's work. Shall I
change it to 'KiCad Developers' or what would be your preference?

Once it is changed, I am going to merge the patches. Thank you for your
efforts.

Regards,
Orson

On 03/11/2017 09:06 PM, Jon Evans wrote:
> Oops! Yes, thanks.
>
> On Sat, Mar 11, 2017 at 12:35 PM, Chris Pavlina 
> wrote:
>
>> I assume you want the header in include/preview_items as well, right?
>>
>> On Sat, Mar 11, 2017 at 08:54:11AM -0500, Jon Evans wrote:
>>> Hi John, you are right!  It was late and I didn't remember about your
new
>>> directory but it's totally the right place.  Updated patch attached.
>>>
>>> Thanks,
>>> Jon
>>>
>>> On Sat, Mar 11, 2017 at 7:09 AM, John Beard 
>> wrote:
>>>
>>>> Hi Jon,
>>>>
>>>> This looks like something that could live in common/preview_items,
>>>> which is where I put  "transient" EDA_ITEMs (i.e. constructed with
>>>> NOT_USED) that are theoretically useful for any GAL canvas. So far,
>>>> the ruler overlay, and SELECTION_AREA are living there, but I have a
>>>> couple more in the pipeline.
>>>>
>>>> Not critical, just a thought while the file is being moved anyway.
>>>>
>>>> Cheers,
>>>>
>>>> John
>>>>
>>>> On Sat, Mar 11, 2017 at 1:47 PM, Jon Evans  wrote:
>>>>> Hi,
>>>>>
>>>>> Quick refactor to allow use of BRIGHT_BOX from GerbView
>>>>>
>>>>> Best,
>>>>> Jon
>>>>>
>>>>> ___
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to : kicad-developers@lists.launchpad.net
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>
>>
>>
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

[Kicad-developers] Question about VIEW_GROUP drawing

[Jon Evans]

Hi, I guess this is mostly a question for Orson but maybe others could
answer also...

I'm chasing a bug that I can't figure out.  I have implemented selection of
items in GerbView, in a similar mechanism to Pcbnew where selected objects
are added to a VIEW_GROUP so they are drawn together.  The problem is, the
VIEW_GROUP is not drawn at all unless I zoom out very far!  I am curious
what could cause this.  The BBox for VIEW_GROUP is set to the maximum size,
so it shouldn't ever get culled from the draw list.  So, my other thought
was that this has something to do with caching, and when I zoom out far
enough, sure enough, I can see in the debugger that the VIEW_GROUP is now
drawn in Immediate mode, not cached mode.

I have not yet wrapped my head around the caching systems in GAL.  Anyone
know what could be wrong? I guess I'm likely just not configuring something
properly because this works fine in Pcbnew.

Thanks,
Jon
___
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] GerbView GAL: Ready for alpha testing; need more sample Gerber files

[Jon Evans]

Hi all,

I want to bump this thread and ask developers who use GerbView a lot to
take a look at my branch again.
Most things are working now, so I'm almost ready to submit it as patches so
that more people can play with it and/or work on it.

Things that definitely don't work yet:
- Negative images (in either canvas)
- Negative items aren't transparent in Cairo canvas - I may need to
implement some kind of image compositing mode in Cairo to fix this.
- OpenGL caching has to be disabled otherwise settings changes take a long
time to update; not sure why yet.
- Selected items disappear unless you are zoomed out (see my other thread
asking about this issue)

g...@github.com:craftyjon/kicad.git branch gerbview_gal

Please let me know if you find bugs, files that don't look like they
should, or have suggestions!

Best,
Jon

On Tue, Mar 7, 2017 at 9:07 AM, Jon Evans  wrote:

> In aperture-circle-flash-with_hole.gbr, one of the holes should be
> square.  They are all drawn as circular in 4.x as well as in master, but
> now correctly drawn with square hole in my branch.
>
> In apertures_rotated_and_arcs_in_tracks.gbr, some weird artifacts show up
> in 4.x in Linux, but I can't reproduce them in Windows. No artifacts in my
> branch on GAL canvas.  This one I want to investigate some more.
>
> As far as I can tell, negative objects work properly in legacy master
> branch (not sure about 4.0), but they don't work properly in my branch
> yet.  For negative images, I guess I will need to create a "backdrop"
> object that the image objects can cut into, since in legacy it just uses
> the wxDC background to cut away from.
>
> Best,
> Jon
>
> On Tue, Mar 7, 2017 at 2:15 AM, Nick Østergaard  wrote:
>
>> Which things?
>>
>> 2017-03-07 4:40 GMT+01:00 Jon Evans :
>> > Hi JP,
>> > Thanks for the tip, I hadn't noticed the test files.
>> >
>> > I now get all tests passing except for the ones related to negative
>> images
>> > and objects... there are still problems there to solve (working on
>> it).  In
>> > fact, it looks to me like we now can draw a few things properly that
>> were
>> > not drawn properly in 4.x!
>> >
>> > Best,
>> > Jon
>> >
>> > On Mon, Mar 6, 2017 at 10:55 AM, jp charras 
>> wrote:
>> >>
>> >> Le 04/03/2017 à 20:35, Jon Evans a écrit :
>> >> > Hi all,
>> >> >
>> >> > My implementation of GAL into GerbView is far enough along that I
>> would
>> >> > like people who use GerbView
>> >> > a lot (and have some time) to try building it and running it.
>> >> >
>> >> > http://i.imgur.com/W6afbRu.jpg
>> >> >
>> >> > You can get the code here:
>> >> > https://github.com/craftyjon/kicad.git branch: gerbview_gal
>> >> >
>> >> > The following things are still missing and will be implemented
>> before I
>> >> > consider it ready to merge:
>> >> >
>> >> > - Selection of items
>> >> > - Highlighting of items (nets, etc)
>> >> > - A few edge case painting branches (need your help here with test
>> >> > material!)
>> >> > - Some improvements to transparency and a new "diff" display mode
>> that
>> >> > I'm working on
>> >> > - DCODE display is currently not done in a good way
>> >> > - A number of code refactorings should happen under the hood before
>> >> > merge.
>> >> >
>> >> > I need help now in looking for rendering issues with certain Gerber
>> >> > files.  So far, the files I've
>> >> > tried work fine.  If you have a Gerber file that throws an ASSERT or
>> >> > displays differently in GAL
>> >> > than it does in legacy, please let me know, and send me the file if
>> >> > possible!
>> >> >
>> >> > Thanks,
>> >> > Jon
>> >>
>> >> Thanks Jon, for this important work.
>> >>
>> >> You have  many test files in /gerbview/gerber_test_
>> files
>> >>
>> >> Each file is a test for a given Gerber feature.
>> >>
>> >> Currently, apertures from aperture macros are not displayed in GAL
>> mode.
>> >>
>> >> --
>> >> 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] Layer ID enums

[Jon Evans]

Hi,

Can anyone explain if there is a reason why the layer definition enums are
done in the way they are?

Using multiple enums for the "normal" layers and the GAL extra layers is
complicating the code, especially now that I am using the GAL layers for
GerbView, and also working on a color theme manager that will be shared
across applications.

It would make more sense to me if there was a single large enum that
contained all possible layers, with some offset somewhere to separate the
"drawing" layers from the "GAL item" layers. This would simplify code that
needs to refer to layer IDs across multiple applications.

Would anyone be opposed to this?

-Jon
___
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] GerbView GAL: Ready for alpha testing; need more sample Gerber files

[Jon Evans]

Hi Kevin, thanks for your valuable feedback.

Are you using opengl or Cairo canvas, or have you tried both?
By default for now, transparency is turned off in GAL. I will switch it to
default to on, but you can hit the button on the left toolbar.

I will fix the default grid preference to be dots.

I also want to switch the default canvas to OpenGL once everything is
supported, but for now there are some things that only render in legacy.

Regarding the file loading, this is the same behavior as in the stable
release. I actually don't like it, but haven't figured out what to propose
to change it to. The reason it works this way is that opening a file with a
layer selected that already has data will replace the existing data. I
could change it to set the last loaded layer as the active one, and then
jump to the next available one when loading another file, but then there
would need to be another option somewhere to clear an existing layer. Maybe
this is worth looking into.

Show Source works for me in Linux, but I haven't touched that feature. It
should prompt you to select an editor. I haven't tried it in Windows.

I will take a look at your other UI bugs, thanks for pointing them out.

Best,
Jon


On Mar 12, 2017 12:16, "Kevin Cozens"  wrote:

On 2017-03-11 09:48 PM, Jon Evans wrote:

> I want to bump this thread and ask developers who use GerbView a lot to
> take
> a look at my branch again.
>

Jon, I have not done an extensive testing of the gerbview branch. I have
only tested it with the gerbers from a current project of mine. The
following are just some observations from a short time trying it out. Most
of the points are minor things. It looks good enough for my needs and makes
me think I don't need to use the external gerber viewer I have previously
been using.

I like that I can select multiple gerber files to be loaded so I don't have
to load them one at a time.

In legacy mode I can see through the layers. When I switch to GAL mode I
can't see through the layers like I can when using GAL mode in pcbnew.

I like it that gerbview can show oval slots. Some other (third party)
gerber viewers, and the one used by some FAB houses, only show a slot as a
round hole.

The rendering of D codes looks better (less confusing) vs. the git master
version of Kicad.

I notice that the default layer after I load a set of gerber files is the
next one (ie. an empty layer). If you try select Miscellaneous->Show after
loading it will tell you it can't show an empty layer. Is this a feature in
case more gerbers are going to be loaded next? Should it default to
pointing to the first layer after a load?

The gerbview program defaults to Legacy mode and shows the grid as dots.
When I switch to GAL it uses lines for the grid. The setting under
Preferences->Options is set for Lines. Legacy mode isn't using that setting.
When I select dots I do see dots in both legacy and GAL modes.

One minor point is about the Visibles columns on the right. When gerbview
first starts the text in the Layer tab shows "Graphic laye". It isn't
opened wide enough to see the full text. When I load a set of gerbers the
width adjusts to almost show the full text of the filename from which it
had read the data. It just truncates the "Bot)" from a layer whose full
text is "Interface Board-B.Mask.gbr (Soldermask, Bot)".

The Layer tab shows the full name of the file which contains enough
information for me to know what part of the board design is being shown so
it doesn't matter to me if I can't read the part that is appended inside
the ().

Selecting a layer then Miscellaneous -> Show Source doesn't appear to do
anything. When running Kicad from a Linux console it seems to invoke vi. If
I was running the branch of Kicad from a menu or icon I wouldn't have been
aware of it doing anything.

I will pass along any additional thoughts if I notice anything else once I
have more time to experiment with the program and using it to look at the
gerbers from some of the other PCBs I have made.

-- 
Cheers!

Kevin.

http://www.ve3syb.ca/   |"Nerds make the shiny things that distract
Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
| powerful!"
#include  | --Chris Hardwick


___
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 ID enums

[Jon Evans]

I would keep the enum values the same for the board layers. The GAL layer
enum values would have to change. I would just move them all to be in one
enum, and set a high starting value for the GAL layers. That way, there is
only one structure and its easy to add layers that are needed for specific
applications, and there are guaranteed to be no conflicts between layer
enum values.

-Jon

On Mar 12, 2017 14:06, "Wayne Stambaugh"  wrote:

> I cannot speak about the GAL enums but I can tell you that if you muck
> up the legacy layer enums, you will almost surely break loading really
> old board files.  I would proceed with extreme caution here.
>
> On 3/12/2017 12:25 PM, Jon Evans wrote:
> > Hi,
> >
> > Can anyone explain if there is a reason why the layer definition enums
> > are done in the way they are?
> >
> > Using multiple enums for the "normal" layers and the GAL extra layers is
> > complicating the code, especially now that I am using the GAL layers for
> > GerbView, and also working on a color theme manager that will be shared
> > across applications.
> >
> > It would make more sense to me if there was a single large enum that
> > contained all possible layers, with some offset somewhere to separate
> > the "drawing" layers from the "GAL item" layers. This would simplify
> > code that needs to refer to layer IDs across multiple applications.
> >
> > Would anyone be opposed to this?
> >
> > -Jon
> >
> >
> > ___
> > 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] [PATCH] Refactor LAYER_ID to be the one and only layer definition

[Jon Evans]

Hi Wayne,

I understand this might seem like too big a change.
Here is what I was thinking when I thought that combining everything would
be a good solution.

- If there is more than one enum, then functions that consume data from
more than one app (i.e. things in common/GAL) have to cast to int, so you
lose type checking that the enum gives you for free (or your type checking
gets more complicated, because the range of valid values is different for
each application)

- If there is more than one enum, it's easier to duplicate layers for no
good reason (i.e. GerbView and Pcbnew have different layer ids for "grid"
right now)

- I want to combine the color settings for all applications under the hood
(users will still be able to configure different colors for each
application).  This change will let color settings take LAYER_ID instead of
int, and there will only be one key/value mapping of colors -- no more
difference between "GetLayerColor" and "GetItemColor".  There will be no
clashes between the meaning of a layer id (int type) between different
applications.

- Bringing Eeschema into this now is just early groundwork for Eeschema GAL
port (as well as unified color settings)

If you will not accept this change, I have to think about a different
proposal that will make the different layer types in different applications
a bit more manageable than they are today.  I understand how having one
giant enum for LAYER_ID seems more complicated, I'm just worried that
having several different enums will make the code that consumes LAYER_ID
more complicated, especially if the applications become more integrated
with each other and start sharing more code.

Best,
Jon

On Mon, Mar 13, 2017 at 8:21 AM, Wayne Stambaugh 
wrote:

> Jon,
>
> I misunderstood your original intent.  I don't think cluttering the
> board layer enums with all of the virtual layer and schematic layer
> enums is a good idea.  It just seems like overkill to me.  I thought you
> were going to create a separate enum for virtual board layers.  You
> could always start the virtual board layer enums from the last board
> layer enum if you need unique enums.  I would also prefer the schematic
> layer enums be separate from the board layer enums for clarity.  Anyone
> else have any thoughts on this?
>
> Cheers,
>
> Wayne
>
> On 3/12/2017 11:24 PM, Jon Evans wrote:
> > Hi all,
> >
> > Per the other thread, this patch unifies the layer definitions between
> > Pcbnew, GerbView, and Eeschema.  It removes the need for ITEM_GAL_LAYER
> > and some other macros, and it will simplify the implementation of
> > cross-application color themes and using GAL in multiple applications.
> >
> > Note that this patch introduces some temporary weirdness in a few
> > places, such as in COLORS_DESIGN_SETTINGS (there is now a single array
> > for color storage, but it's still referred to by two sets of
> > getters/setters).  This is because I wanted to keep this refactor as
> > simple as possible, as I plan to follow it up with an overhaul of color
> > settings when I share my color themes work.  I didn't want to do work
> > that I would soon end up getting rid of anyway.
> >
> > Best,
> > Jon
> >
> >
> > ___
> > 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] [PATCH] Refactor LAYER_ID to be the one and only layer definition

[Jon Evans]

Hi Orson,

It's an interesting idea, I will have to look at it more.  But, doesn't
this still allow the programmer to accidentally overlap two enum values?  I
can add checks to prevent this from happening elsewhere in the code, but it
seems less clean to me.

Best,
-Jon

On Mon, Mar 13, 2017 at 1:52 PM, Maciej Suminski 
wrote:

> Hi,
>
> How about emulating enum inheritance [1]? I suppose it would be the
> cleanest solution allowing us to clearly specify what kind of layer is
> expected for certain methods. This is even better kind of type checking.
>
> Cheers,
> Orson
>
> 1. https://www.codeproject.com/kb/cpp/inheritenum.aspx
>
> On 03/13/2017 02:50 PM, Jon Evans wrote:
> > Hi Wayne,
> >
> > I understand this might seem like too big a change.
> > Here is what I was thinking when I thought that combining everything
> would
> > be a good solution.
> >
> > - If there is more than one enum, then functions that consume data from
> > more than one app (i.e. things in common/GAL) have to cast to int, so you
> > lose type checking that the enum gives you for free (or your type
> checking
> > gets more complicated, because the range of valid values is different for
> > each application)
> >
> > - If there is more than one enum, it's easier to duplicate layers for no
> > good reason (i.e. GerbView and Pcbnew have different layer ids for "grid"
> > right now)
> >
> > - I want to combine the color settings for all applications under the
> hood
> > (users will still be able to configure different colors for each
> > application).  This change will let color settings take LAYER_ID instead
> of
> > int, and there will only be one key/value mapping of colors -- no more
> > difference between "GetLayerColor" and "GetItemColor".  There will be no
> > clashes between the meaning of a layer id (int type) between different
> > applications.
> >
> > - Bringing Eeschema into this now is just early groundwork for Eeschema
> GAL
> > port (as well as unified color settings)
> >
> > If you will not accept this change, I have to think about a different
> > proposal that will make the different layer types in different
> applications
> > a bit more manageable than they are today.  I understand how having one
> > giant enum for LAYER_ID seems more complicated, I'm just worried that
> > having several different enums will make the code that consumes LAYER_ID
> > more complicated, especially if the applications become more integrated
> > with each other and start sharing more code.
> >
> > Best,
> > Jon
> >
> > On Mon, Mar 13, 2017 at 8:21 AM, Wayne Stambaugh 
> > wrote:
> >
> >> Jon,
> >>
> >> I misunderstood your original intent.  I don't think cluttering the
> >> board layer enums with all of the virtual layer and schematic layer
> >> enums is a good idea.  It just seems like overkill to me.  I thought you
> >> were going to create a separate enum for virtual board layers.  You
> >> could always start the virtual board layer enums from the last board
> >> layer enum if you need unique enums.  I would also prefer the schematic
> >> layer enums be separate from the board layer enums for clarity.  Anyone
> >> else have any thoughts on this?
> >>
> >> Cheers,
> >>
> >> Wayne
> >>
> >> On 3/12/2017 11:24 PM, Jon Evans wrote:
> >>> Hi all,
> >>>
> >>> Per the other thread, this patch unifies the layer definitions between
> >>> Pcbnew, GerbView, and Eeschema.  It removes the need for ITEM_GAL_LAYER
> >>> and some other macros, and it will simplify the implementation of
> >>> cross-application color themes and using GAL in multiple applications.
> >>>
> >>> Note that this patch introduces some temporary weirdness in a few
> >>> places, such as in COLORS_DESIGN_SETTINGS (there is now a single array
> >>> for color storage, but it's still referred to by two sets of
> >>> getters/setters).  This is because I wanted to keep this refactor as
> >>> simple as possible, as I plan to follow it up with an overhaul of color
> >>> settings when I share my color themes work.  I didn't want to do work
> >>> that I would soon end up getting rid of anyway.
> >>>
> >>> Best,
> >>> Jon
> >>>
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developer

Re: [Kicad-developers] [PATCH] Refactor LAYER_ID to be the one and only layer definition

[Jon Evans]

Hi Orson, Wayne,

I looked at the "enum inheritance" thing some more and I don't think it
would be a good solution for our case.

This technique lets you extend enum A with enum B, and have functions f(A)
and f(A or B), and you could continue making larger enums that contained
smaller ones.
But, if we maintain multiple enums (one for each application, plus one for
GAL layers) I don't see how it would make anything simpler, because we
would not be able to treat them as "sibling classes"

Before I spend more time coding things I want to get an idea of what your
requirements are / what you would and would not accept as a change in this
area.  I misunderstood Wayne's earlier reply to me and thought that a
single enum would be accepted, but if not, I don't currently have a good
understanding of what the concerns are with that approach.

Questions for Wayne, Orson, and others who care about this:

1) Is there any opposition to moving the layer definitions from GerbView
and Eeschema into layers_id_colors_and_visibility.h? (ignoring whether they
are merged into one enum for now)

2) Is there any opposition to ensuring that no layer IDs overlap across all
applications?  To be clear, what I mean now is that currently GerbView draw
layers occupy the same layer IDs as Pcbnew board layers.  I want to change
it so that a layer ID (cast to integer) is always unique across all
applications, unless it truly is the same layer (i.e can use the same color
settings, visibility settings, etc. as GP_OVERLAY can across
GerbView/Pcbnew).

3) If the answers to both 1 and 2 are "no", can you give some more details
on why it's a bad idea to put all the layers in the same enum, and based on
that I will come back with a proposal on a different way of doing it?

Thanks,
Jon

On Mon, Mar 13, 2017 at 3:07 PM, Jon Evans  wrote:

> Hi Orson,
>
> It's an interesting idea, I will have to look at it more.  But, doesn't
> this still allow the programmer to accidentally overlap two enum values?  I
> can add checks to prevent this from happening elsewhere in the code, but it
> seems less clean to me.
>
> Best,
> -Jon
>
> On Mon, Mar 13, 2017 at 1:52 PM, Maciej Suminski 
> wrote:
>
>> Hi,
>>
>> How about emulating enum inheritance [1]? I suppose it would be the
>> cleanest solution allowing us to clearly specify what kind of layer is
>> expected for certain methods. This is even better kind of type checking.
>>
>> Cheers,
>> Orson
>>
>> 1. https://www.codeproject.com/kb/cpp/inheritenum.aspx
>>
>> On 03/13/2017 02:50 PM, Jon Evans wrote:
>> > Hi Wayne,
>> >
>> > I understand this might seem like too big a change.
>> > Here is what I was thinking when I thought that combining everything
>> would
>> > be a good solution.
>> >
>> > - If there is more than one enum, then functions that consume data from
>> > more than one app (i.e. things in common/GAL) have to cast to int, so
>> you
>> > lose type checking that the enum gives you for free (or your type
>> checking
>> > gets more complicated, because the range of valid values is different
>> for
>> > each application)
>> >
>> > - If there is more than one enum, it's easier to duplicate layers for no
>> > good reason (i.e. GerbView and Pcbnew have different layer ids for
>> "grid"
>> > right now)
>> >
>> > - I want to combine the color settings for all applications under the
>> hood
>> > (users will still be able to configure different colors for each
>> > application).  This change will let color settings take LAYER_ID
>> instead of
>> > int, and there will only be one key/value mapping of colors -- no more
>> > difference between "GetLayerColor" and "GetItemColor".  There will be no
>> > clashes between the meaning of a layer id (int type) between different
>> > applications.
>> >
>> > - Bringing Eeschema into this now is just early groundwork for Eeschema
>> GAL
>> > port (as well as unified color settings)
>> >
>> > If you will not accept this change, I have to think about a different
>> > proposal that will make the different layer types in different
>> applications
>> > a bit more manageable than they are today.  I understand how having one
>> > giant enum for LAYER_ID seems more complicated, I'm just worried that
>> > having several different enums will make the code that consumes LAYER_ID
>> > more complicated, especially if the applications become more integrated
>> > with each other and start sharing more code.
>> &g

Re: [Kicad-developers] [PATCH] Refactor LAYER_ID to be the one and only layer definition

[Jon Evans]

Hi John, that's basically what my first patch did, but inside one enum.

Hi Wayne, thanks for elaborating more, I see your point.

I am still not sure there is benefit to adding some class to handle enum
inheritance.
I think it would work fine to just chain multiple enums together, as was
done before, but with some tweaks.

enum PCB_LAYER_ID
{
F_Cu = 0,
//...
PCB_LAYER_ID_COUNT
};

enum NETNAME_LAYER_ID
{
NETNAME_LAYER_ID_START = PCB_LAYER_ID_COUNT,
NETNAME_LAYER_ID_COUNT = NETNAME_LAYER_ID_START + PCB_LAYER_ID_COUNT
};

enum GAL_LAYER_ID
{
GAL_LAYER_ID_START = NETNAME_LAYER_ID_COUNT,
//
};

And so on for gerbview, eeschema, etc

That way the IDs will be unique and cover a contiguous range, so functions
that want to take any layer ID can just check that the ID is >= 0 and < the
end sentinel of the last enum.

Any concerns with this approach?


Best,
Jon

On Tue, Mar 14, 2017 at 10:29 AM, John Beard  wrote:

> Hi Jon,
>
> Protocol Buffers has the same problem. Messages have a unique number
> for each field, but extensions to messages don't know about
> "siblings". A common thing [1] to so is reserve IDs up to 1000 for the
> base message, and then messages start at offsets 1000, 2000, etc,
> based on some in-house scheme.
>
> It probably won't just "drop in" to KiCad due to fixed arrays (I
> think?), but this is certainly one way it has been "solved" in the
> real world, by Google, no less! It's a bit crusty to manually reserve
> space, but the "enum inheritance" problem isn't limited to C++.
>
> There's plenty of space in enums and I sincerely doubt there is a
> measurable benefit to forcing the compiler to use shorter integral
> types anyway, so we could just say "0-" is "common GAL",
> "1-1" is Pcbnew, etc. Some work might be needed to handle
> non-contiguous enums here. "1 layers should be enough for anyone",
> right?
>
> Just a thought, without any real consideration of the consequences for
> things like formats and so on.
>
> Cheers,
>
> John
>
> [1] https://developers.google.com/protocol-buffers/docs/proto#
> choosing-extension-numbers
>
> On Tue, Mar 14, 2017 at 10:08 PM, Jon Evans  wrote:
> > Hi Orson, Wayne,
> >
> > I looked at the "enum inheritance" thing some more and I don't think it
> > would be a good solution for our case.
> >
> > This technique lets you extend enum A with enum B, and have functions
> f(A)
> > and f(A or B), and you could continue making larger enums that contained
> > smaller ones.
> > But, if we maintain multiple enums (one for each application, plus one
> for
> > GAL layers) I don't see how it would make anything simpler, because we
> would
> > not be able to treat them as "sibling classes"
> >
> > Before I spend more time coding things I want to get an idea of what your
> > requirements are / what you would and would not accept as a change in
> this
> > area.  I misunderstood Wayne's earlier reply to me and thought that a
> single
> > enum would be accepted, but if not, I don't currently have a good
> > understanding of what the concerns are with that approach.
> >
> > Questions for Wayne, Orson, and others who care about this:
> >
> > 1) Is there any opposition to moving the layer definitions from GerbView
> and
> > Eeschema into layers_id_colors_and_visibility.h? (ignoring whether they
> are
> > merged into one enum for now)
> >
> > 2) Is there any opposition to ensuring that no layer IDs overlap across
> all
> > applications?  To be clear, what I mean now is that currently GerbView
> draw
> > layers occupy the same layer IDs as Pcbnew board layers.  I want to
> change
> > it so that a layer ID (cast to integer) is always unique across all
> > applications, unless it truly is the same layer (i.e can use the same
> color
> > settings, visibility settings, etc. as GP_OVERLAY can across
> > GerbView/Pcbnew).
> >
> > 3) If the answers to both 1 and 2 are "no", can you give some more
> details
> > on why it's a bad idea to put all the layers in the same enum, and based
> on
> > that I will come back with a proposal on a different way of doing it?
> >
> > Thanks,
> > Jon
> >
> > On Mon, Mar 13, 2017 at 3:07 PM, Jon Evans  wrote:
> >>
> >> Hi Orson,
> >>
> >> It's an interesting idea, I will have to look at it more.  But, doesn't
> >> this still allow the programmer to accidentally overlap two enum
> values?  I
> >> can add ch

Re: [Kicad-developers] [PATCH] Refactor LAYER_ID to be the one and only layer definition

[Jon Evans]

Hi Wayne,

Please keep in mind that anywhere there is currently int casting and bounds
checking that deals with colors, will be replaced with type-safe methods in
an upcoming patch from me.  For those places not dealing with colors, I
will see if it can be improved in a future patch.

Thanks,
Jon

On Mar 14, 2017 19:06, "Wayne Stambaugh"  wrote:

Hey Jon,

This is better than the giant enum concept and I'm willing to accept
this.  It still lacks the type safety of the enum inheritance solution.
I still see ints being cast to enums and enum bounds checking so this is
less than ideal.  I would prefer to see some additional testing so if
any one has time, please test this patch before we commit it.

Thanks,

Wayne

On 3/14/2017 3:09 PM, Jon Evans wrote:
> Hi Wayne,
>
> New patch attached.  Let me know what you think of this approach.
>
> Thanks,
> Jon
>
> On Tue, Mar 14, 2017 at 10:40 AM, Jon Evans  <mailto:j...@craftyjon.com>> wrote:
>
> Hi John, that's basically what my first patch did, but inside one
enum.
>
> Hi Wayne, thanks for elaborating more, I see your point.
>
> I am still not sure there is benefit to adding some class to handle
> enum inheritance.
> I think it would work fine to just chain multiple enums together, as
> was done before, but with some tweaks.
>
> enum PCB_LAYER_ID
> {
> F_Cu = 0,
> //...
> PCB_LAYER_ID_COUNT
> };
>
> enum NETNAME_LAYER_ID
> {
> NETNAME_LAYER_ID_START = PCB_LAYER_ID_COUNT,
> NETNAME_LAYER_ID_COUNT = NETNAME_LAYER_ID_START +
PCB_LAYER_ID_COUNT
> };
>
> enum GAL_LAYER_ID
> {
> GAL_LAYER_ID_START = NETNAME_LAYER_ID_COUNT,
> //
> };
>
> And so on for gerbview, eeschema, etc
>
> That way the IDs will be unique and cover a contiguous range, so
> functions that want to take any layer ID can just check that the ID
> is >= 0 and < the end sentinel of the last enum.
>
> Any concerns with this approach?
>
>
> Best,
> Jon
>
> On Tue, Mar 14, 2017 at 10:29 AM, John Beard  <mailto:john.j.be...@gmail.com>> wrote:
>
> Hi Jon,
>
> Protocol Buffers has the same problem. Messages have a unique
number
> for each field, but extensions to messages don't know about
> "siblings". A common thing [1] to so is reserve IDs up to 1000
> for the
> base message, and then messages start at offsets 1000, 2000, etc,
> based on some in-house scheme.
>
> It probably won't just "drop in" to KiCad due to fixed arrays (I
> think?), but this is certainly one way it has been "solved" in the
> real world, by Google, no less! It's a bit crusty to manually
> reserve
> space, but the "enum inheritance" problem isn't limited to C++.
>
> There's plenty of space in enums and I sincerely doubt there is a
> measurable benefit to forcing the compiler to use shorter integral
> types anyway, so we could just say "0-" is "common GAL",
> "1-1" is Pcbnew, etc. Some work might be needed to handle
> non-contiguous enums here. "1 layers should be enough for
> anyone",
> right?
>
> Just a thought, without any real consideration of the
> consequences for
> things like formats and so on.
>
> Cheers,
>
> John
>
> [1]
> https://developers.google.com/protocol-buffers/docs/proto#
choosing-extension-numbers
> <https://developers.google.com/protocol-buffers/docs/
proto#choosing-extension-numbers>
>
> On Tue, Mar 14, 2017 at 10:08 PM, Jon Evans  <mailto:j...@craftyjon.com>> wrote:
> > Hi Orson, Wayne,
> >
> > I looked at the "enum inheritance" thing some more and I don't
> think it
> > would be a good solution for our case.
> >
> > This technique lets you extend enum A with enum B, and have
> functions f(A)
> > and f(A or B), and you could continue making larger enums that
> contained
> > smaller ones.
> > But, if we maintain multiple enums (one for each application,
> plus one for
> > GAL layers) I don't see how it would make anything simpler,
> because we would
> > not be able to treat them as "sibling classes"
> >
> > Before I spend more time coding thi

Re: [Kicad-developers] [PATCH] Refactor LAYER_ID to be the one and only layer definition

[Jon Evans]

Hi Lorenzo,

I think this is possible.  I will look in to it.

-Jon

On Wed, Mar 15, 2017 at 3:05 AM, Lorenzo Marcantonio 
wrote:

> On Tue, Mar 14, 2017 at 07:09:30PM -0400, Jon Evans wrote:
> > Hi Wayne,
> >
> > Please keep in mind that anywhere there is currently int casting and
> bounds
> > checking that deals with colors, will be replaced with type-safe methods
> in
> > an upcoming patch from me.  For those places not dealing with colors, I
> > will see if it can be improved in a future patch.
>
> Thank you thank you thank you
>
> I always had... troubles with the color codes, this would be a great
> improvement.
>
> Also, it is possible to 'prime' the color chooser palette with the old
> colors or is it an OS/platform dependant feature? I'm used to switch
> quickly layer color (to see better things and such) and the RGB chooser
> while more versatile is a little inconvenient. How I am doing it now:
> keep in a corner a bitmap with the old colors and use the dialog color
> picker :D
>
> --
> 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] Indication of modifier buttons to tools and dialogs

[Jon Evans]

Hi Kristoffer, John,

I agree this is an important problem to solve.

I am not convinced that this is the perfect solution, but I wanted to share
a way a commercial tool does it.
Here's a screenshot from Mentor Graphics Xpedition showing what I mean:
http://i.imgur.com/H0wDK0F.png

At the bottom of the screen is a list of keyboard shortcuts, that change
based on what you are doing.  So, when you are in "place components" mode
the list is different than if you are routing a track, for example.  The
developers chose the most common things to do for each "tool" that can be
active, and assigned them to function-keys.

Note that in Xpedition, the hotkeys themselves change, i.e. the icons on
the bottom of the screen always correspond to the function keys F1-F12.
But, even without adopting that scheme (which would conflict with some of
our existing hotkeys), we could use the UI concept of a larger "quick
reference" to hotkeys (I'm including mouse actions in the definition of
hotkeys here) at the bottom of the screen, for example a quick mockup:
http://i.imgur.com/wB0Yecy.png

Then we would just need to define up to N hotkeys for each tool / tool mode
that should be hinted to the user. (Where N is some number that looks not
too cramped)

-Jon


On Wed, Mar 15, 2017 at 7:11 AM, Kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> Yes, the status line is way to small it. However it could maybe be used to
> show which modifiers are in use. Not what they do.
>
> I believe that knowing which modifiers are in use would be enough, because
> many modifiers would probably be very self explanatory once activated, for
> example the angle-snap, having a grid snap etc.
>
> Then the idea of having an explanatory panel available somehow on-demand
> would probably be best.
>
> Attached is an idea mockup for putting on the left side in the status line.
>
> It shows when the arc tool is active and has ctrl and shift modifers where
> ctrl is currently held and angle snap-active.
>
>
>
> On 03/15/2017 12:11 PM, John Beard wrote:
>
>> Hi Kristoffer,
>>
>> I agree that the "secrecy" of KiCad shortcuts is a pretty major issue.
>> It serves to make people good at KiCad think it's great, while new
>> users struggle (probably in silence) because they don't know there's a
>> better way.
>>
>> Expanding documentation is important here (he says, not having
>> documented his new features yet) but it's unreasonable to expect users
>> to wade through hundreds of screens of prose to be told incidentally
>> that the arc tool snaps angles when you hold control.
>>
>> I certainly think some sort of easily accessible (at minimum hotkey +
>> some sort of obvious visual affordance) method for a user to get
>> contextual help is very important. Ideally something that doesn't
>> break the user's flow. Popping a dialog that you have to dismiss is a
>> little clunky, I feel. Perhaps some sort of panel that appears only
>> while you're holding a key down?
>>
>> I'm not a huge fan of the Inkscape-style status line, though it's
>> certainly better than nothing. It feels squeezed to me, since the
>> information is really more like a list of possible modifiers than a
>> one-liner. We do have a little area of the status bar that tells you
>> what tool you're in, but that's nowhere near big enough to naively
>> plonk screeds of text.
>>
>> tl;dr agree but no ideas yet!
>>
>> Cheers,
>>
>> John
>>
>> On Wed, Mar 15, 2017 at 6:34 PM, Kristoffer Ödmark
>>  wrote:
>>
>>> Hello all!
>>>
>>> I just wanted to highlight an emerging problem to catch it in its cradle.
>>>
>>> The new tool and dialog patches that has been merged are great. But they
>>> also introduce secret functionaly, examples:
>>>
>>> Ctrl + click:   highlights net ( modifier to select tool )
>>> ctrl + drag:snap angles in arc tool
>>> shift + click:  adds/removes to selection in select mode
>>> shift + scroll: changes increment values in 3d-previewer
>>>
>>> These are the few examples I found right now, what I would like to see
>>> is a
>>> standardized way of informing the users to this before more tools get
>>> these
>>> hidden functionality.
>>>
>>> The way that current shortcuts are indicated I think are great ( the grey
>>> text next to their selection in menus Maybe we could expand on this to
>>> create tooltips to the menus with a list of modifier keys for the hovered
>>> tool in the menu.
>>>
>>> Another way that Gimp uses is to put this information at the bottom
>>> information bar, Maybe we could do that as well by modifying the current
>>> position information bar
>>>
>>> Yet another way would be to have tool specific settings given screen
>>> real-estate, much in the way of gimp and inkscape.
>>>
>>> At least I think this issue should be addressed and agreed upon before
>>> tools
>>> specify their different modifiers willy-nilly all over the place and you
>>> need a kicad-phd to remember them all. Just having an idea on how to do
>>> it
>>> can enable a good team-effort of support

Re: [Kicad-developers] Indication of modifier buttons to tools and dialogs

[Jon Evans]

Hi Kristoffer,

I didn't show in my mockup, but you could easily use a UI like this to show
modifier keys info as well.

-Jon

On Wed, Mar 15, 2017 at 8:36 AM, Kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> Hello Jon,
>
> I do not think that the hotkeys are a problem. The right-click menu shows
> how they are bound already and the right click menu is adaptable. I
> personally like the way that works a lot.
>
> It is more a problem regarding the modifiers, Ie buttons that must be held
> while doing something, they are not selecting stuff, but modifiying already
> existing functionality, usually slightly.
>
> - Kristoffer
>
> On 03/15/2017 02:29 PM, Jon Evans wrote:
>
>> Hi Kristoffer, John,
>>
>> I agree this is an important problem to solve.
>>
>> I am not convinced that this is the perfect solution, but I wanted to
>> share a way a commercial tool does it.
>> Here's a screenshot from Mentor Graphics Xpedition showing what I mean:
>> http://i.imgur.com/H0wDK0F.png
>>
>> At the bottom of the screen is a list of keyboard shortcuts, that change
>> based on what you are doing.  So, when you are in "place components"
>> mode the list is different than if you are routing a track, for
>> example.  The developers chose the most common things to do for each
>> "tool" that can be active, and assigned them to function-keys.
>>
>> Note that in Xpedition, the hotkeys themselves change, i.e. the icons on
>> the bottom of the screen always correspond to the function keys F1-F12.
>> But, even without adopting that scheme (which would conflict with some
>> of our existing hotkeys), we could use the UI concept of a larger "quick
>> reference" to hotkeys (I'm including mouse actions in the definition of
>> hotkeys here) at the bottom of the screen, for example a quick mockup:
>> http://i.imgur.com/wB0Yecy.png
>>
>> Then we would just need to define up to N hotkeys for each tool / tool
>> mode that should be hinted to the user. (Where N is some number that
>> looks not too cramped)
>>
>> -Jon
>>
>>
>> On Wed, Mar 15, 2017 at 7:11 AM, Kristoffer Ödmark
>> mailto:kristofferodmar...@gmail.com>>
>> wrote:
>>
>> Yes, the status line is way to small it. However it could maybe be
>> used to show which modifiers are in use. Not what they do.
>>
>> I believe that knowing which modifiers are in use would be enough,
>> because many modifiers would probably be very self explanatory once
>> activated, for example the angle-snap, having a grid snap etc.
>>
>> Then the idea of having an explanatory panel available somehow
>> on-demand would probably be best.
>>
>> Attached is an idea mockup for putting on the left side in the
>> status line.
>>
>> It shows when the arc tool is active and has ctrl and shift modifers
>> where ctrl is currently held and angle snap-active.
>>
>>
>>
>> On 03/15/2017 12:11 PM, John Beard wrote:
>>
>> Hi Kristoffer,
>>
>> I agree that the "secrecy" of KiCad shortcuts is a pretty major
>> issue.
>> It serves to make people good at KiCad think it's great, while new
>> users struggle (probably in silence) because they don't know
>> there's a
>> better way.
>>
>> Expanding documentation is important here (he says, not having
>> documented his new features yet) but it's unreasonable to expect
>> users
>> to wade through hundreds of screens of prose to be told
>> incidentally
>> that the arc tool snaps angles when you hold control.
>>
>> I certainly think some sort of easily accessible (at minimum
>> hotkey +
>> some sort of obvious visual affordance) method for a user to get
>> contextual help is very important. Ideally something that doesn't
>> break the user's flow. Popping a dialog that you have to dismiss
>> is a
>> little clunky, I feel. Perhaps some sort of panel that appears
>> only
>> while you're holding a key down?
>>
>> I'm not a huge fan of the Inkscape-style status line, though it's
>> certainly better than nothing. It feels squeezed to me, since the
>> information is really more like a list of possible modifiers than
>> a
>> one-liner. We do have a little area of the status bar that tells
>

Re: [Kicad-developers] Indication of modifier buttons to tools and dialogs

[Jon Evans]

Yes, that's what I meant, it would be for the current mode, and would
change based on what you are doing.  It would also be hide-able so that
advanced users get the screen real estate back.

There are no problems with combined modifiers, you just list each action in
a different box.  In fact, you could even have the modifiers change the
box, so when you hold down the Ctrl key, it shows you exactly what will
happen when you do various things with it held down

Maybe once I have some more things done off my to-do list I will spend some
more time making a mockup of this.

Best,
Jon

On Wed, Mar 15, 2017 at 9:02 AM, Kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> Yes, you are correct, but putting the buttons and their function in the
> same box would get problems with combined modifiers shift+ctrl options etc.
>
> But I was thinking of only showing current mode and not all possible modes
> at the same time. Mostly you would learn them anyway kinda quick, you would
> only need to know they can be learned. by indicating which buttons are
> available as modifiers in this tool.
>
> On 03/15/2017 02:54 PM, Jon Evans wrote:
>
>> Hi Kristoffer,
>>
>> I didn't show in my mockup, but you could easily use a UI like this to
>> show modifier keys info as well.
>>
>> -Jon
>>
>> On Wed, Mar 15, 2017 at 8:36 AM, Kristoffer Ödmark
>> mailto:kristofferodmar...@gmail.com>>
>> wrote:
>>
>> Hello Jon,
>>
>> I do not think that the hotkeys are a problem. The right-click menu
>> shows how they are bound already and the right click menu is
>> adaptable. I personally like the way that works a lot.
>>
>> It is more a problem regarding the modifiers, Ie buttons that must
>> be held while doing something, they are not selecting stuff, but
>> modifiying already existing functionality, usually slightly.
>>
>> - Kristoffer
>>
>> On 03/15/2017 02:29 PM, Jon Evans wrote:
>>
>> Hi Kristoffer, John,
>>
>> I agree this is an important problem to solve.
>>
>> I am not convinced that this is the perfect solution, but I
>> wanted to
>> share a way a commercial tool does it.
>> Here's a screenshot from Mentor Graphics Xpedition showing what
>> I mean:
>> http://i.imgur.com/H0wDK0F.png
>>
>> At the bottom of the screen is a list of keyboard shortcuts,
>> that change
>> based on what you are doing.  So, when you are in "place
>> components"
>> mode the list is different than if you are routing a track, for
>> example.  The developers chose the most common things to do for
>> each
>> "tool" that can be active, and assigned them to function-keys.
>>
>> Note that in Xpedition, the hotkeys themselves change, i.e. the
>> icons on
>> the bottom of the screen always correspond to the function keys
>> F1-F12.
>> But, even without adopting that scheme (which would conflict
>> with some
>> of our existing hotkeys), we could use the UI concept of a
>> larger "quick
>> reference" to hotkeys (I'm including mouse actions in the
>> definition of
>> hotkeys here) at the bottom of the screen, for example a quick
>> mockup:
>> http://i.imgur.com/wB0Yecy.png
>>
>> Then we would just need to define up to N hotkeys for each tool
>> / tool
>> mode that should be hinted to the user. (Where N is some number
>> that
>> looks not too cramped)
>>
>> -Jon
>>
>>
>> On Wed, Mar 15, 2017 at 7:11 AM, Kristoffer Ödmark
>> > <mailto:kristofferodmar...@gmail.com>
>> <mailto:kristofferodmar...@gmail.com
>>
>> <mailto:kristofferodmar...@gmail.com>>> wrote:
>>
>> Yes, the status line is way to small it. However it could
>> maybe be
>> used to show which modifiers are in use. Not what they do.
>>
>> I believe that knowing which modifiers are in use would be
>> enough,
>> because many modifiers would probably be very self
>> explanatory once
>> activated, for example the angle-snap, having a grid snap etc.
>>
>> Then the idea of having an explanatory panel available somehow
>> on-demand would probably be best.
>>
&g

Re: [Kicad-developers] Indication of modifier buttons to tools and dialogs

[Jon Evans]

It's a thought, I will play with it to see.  I think there might be some
situations where the suggested help we would want to show is different when
no objects are selected vs. when one or more objects are selected, so it
would conflict in that case.

But, I know there is an object properties system on the roadmap... I assume
that will also involve some new GUI, since the message panel is not really
the right way to display editable properties.  Maybe once that comes to
exist, the former message panel can be a (hide-able) contextual help panel?

-Jon

On Wed, Mar 15, 2017 at 9:22 AM, Wayne Stambaugh 
wrote:

> Why not just use the current message panel?  You could show the modifier
> keys and hotkeys for the current tool immediately after the tool is
> selected before any object action takes place.  Once an object is
> selected by the current tool, it will just replace the tool help with
> the object properties as it currently does. This gives the user a chance
> to see the modifier keys before performing any actions.  When the user
> learns the tool immediate hotkey, the tool help would no longer be seen
> because it would be replaced by the object properties immediately.  I
> would think that once a user was comfortable enough to use the hotkey,
> they would already be aware of the modifier keys.  Just food for
> thought.  I'm not a be fan of using valuable screen area to display help
> information.
>
> On 3/15/2017 10:06 AM, Jon Evans wrote:
> > Yes, that's what I meant, it would be for the current mode, and would
> > change based on what you are doing.  It would also be hide-able so that
> > advanced users get the screen real estate back.
> >
> > There are no problems with combined modifiers, you just list each action
> > in a different box.  In fact, you could even have the modifiers change
> > the box, so when you hold down the Ctrl key, it shows you exactly what
> > will happen when you do various things with it held down
> >
> > Maybe once I have some more things done off my to-do list I will spend
> > some more time making a mockup of this.
> >
> > Best,
> > Jon
> >
> > On Wed, Mar 15, 2017 at 9:02 AM, Kristoffer Ödmark
> > mailto:kristofferodmar...@gmail.com>>
> wrote:
> >
> > Yes, you are correct, but putting the buttons and their function in
> > the same box would get problems with combined modifiers shift+ctrl
> > options etc.
> >
> > But I was thinking of only showing current mode and not all possible
> > modes at the same time. Mostly you would learn them anyway kinda
> > quick, you would only need to know they can be learned. by
> > indicating which buttons are available as modifiers in this tool.
> >
> > On 03/15/2017 02:54 PM, Jon Evans wrote:
> >
> > Hi Kristoffer,
> >
> > I didn't show in my mockup, but you could easily use a UI like
> > this to
> > show modifier keys info as well.
> >
> > -Jon
> >
> > On Wed, Mar 15, 2017 at 8:36 AM, Kristoffer Ödmark
> >  > <mailto:kristofferodmar...@gmail.com>
> > <mailto:kristofferodmar...@gmail.com
> > <mailto:kristofferodmar...@gmail.com>>> wrote:
> >
> > Hello Jon,
> >
> > I do not think that the hotkeys are a problem. The
> > right-click menu
> > shows how they are bound already and the right click menu is
> > adaptable. I personally like the way that works a lot.
> >
> > It is more a problem regarding the modifiers, Ie buttons
> > that must
> > be held while doing something, they are not selecting stuff,
> but
> > modifiying already existing functionality, usually slightly.
> >
> > - Kristoffer
> >
> > On 03/15/2017 02:29 PM, Jon Evans wrote:
> >
> > Hi Kristoffer, John,
> >
> > I agree this is an important problem to solve.
> >
> > I am not convinced that this is the perfect solution,
> but I
> > wanted to
> > share a way a commercial tool does it.
> > Here's a screenshot from Mentor Graphics Xpedition
> > showing what
> > I mean:
> > http://i.imgur.com/H0wDK0F.png
> >
> > At the bottom of the screen is a list of keyboard
> shortcuts,
> > that change
> > based on what you are do

Re: [Kicad-developers] [PATCH] Refactor LAYER_ID to be the one and only layer definition

[Jon Evans]

Bump -- does anyone have time to look at this and report back if there are
any issues?  I'd like to get it merged so that I can feel confident about
doing more work on top of these changes.

Thanks,
Jon

On Tue, Mar 14, 2017 at 6:05 PM, Wayne Stambaugh 
wrote:

> Hey Jon,
>
> This is better than the giant enum concept and I'm willing to accept
> this.  It still lacks the type safety of the enum inheritance solution.
> I still see ints being cast to enums and enum bounds checking so this is
> less than ideal.  I would prefer to see some additional testing so if
> any one has time, please test this patch before we commit it.
>
> Thanks,
>
> Wayne
>
> On 3/14/2017 3:09 PM, Jon Evans wrote:
> > Hi Wayne,
> >
> > New patch attached.  Let me know what you think of this approach.
> >
> > Thanks,
> > Jon
> >
> > On Tue, Mar 14, 2017 at 10:40 AM, Jon Evans  > <mailto:j...@craftyjon.com>> wrote:
> >
> > Hi John, that's basically what my first patch did, but inside one
> enum.
> >
> > Hi Wayne, thanks for elaborating more, I see your point.
> >
> > I am still not sure there is benefit to adding some class to handle
> > enum inheritance.
> > I think it would work fine to just chain multiple enums together, as
> > was done before, but with some tweaks.
> >
> > enum PCB_LAYER_ID
> > {
> > F_Cu = 0,
> > //...
> > PCB_LAYER_ID_COUNT
> > };
> >
> > enum NETNAME_LAYER_ID
> > {
> > NETNAME_LAYER_ID_START = PCB_LAYER_ID_COUNT,
> > NETNAME_LAYER_ID_COUNT = NETNAME_LAYER_ID_START +
> PCB_LAYER_ID_COUNT
> > };
> >
> > enum GAL_LAYER_ID
> > {
> > GAL_LAYER_ID_START = NETNAME_LAYER_ID_COUNT,
> > //
> > };
> >
> > And so on for gerbview, eeschema, etc
> >
> > That way the IDs will be unique and cover a contiguous range, so
> > functions that want to take any layer ID can just check that the ID
> > is >= 0 and < the end sentinel of the last enum.
> >
> > Any concerns with this approach?
> >
> >
> > Best,
> > Jon
> >
> > On Tue, Mar 14, 2017 at 10:29 AM, John Beard  > <mailto:john.j.be...@gmail.com>> wrote:
> >
> > Hi Jon,
> >
> > Protocol Buffers has the same problem. Messages have a unique
> number
> > for each field, but extensions to messages don't know about
> > "siblings". A common thing [1] to so is reserve IDs up to 1000
> > for the
> > base message, and then messages start at offsets 1000, 2000, etc,
> > based on some in-house scheme.
> >
> > It probably won't just "drop in" to KiCad due to fixed arrays (I
> > think?), but this is certainly one way it has been "solved" in
> the
> > real world, by Google, no less! It's a bit crusty to manually
> > reserve
> > space, but the "enum inheritance" problem isn't limited to C++.
> >
> > There's plenty of space in enums and I sincerely doubt there is a
> > measurable benefit to forcing the compiler to use shorter
> integral
> > types anyway, so we could just say "0-" is "common GAL",
> > "1-1" is Pcbnew, etc. Some work might be needed to handle
> > non-contiguous enums here. "1 layers should be enough for
> > anyone",
> > right?
> >
> > Just a thought, without any real consideration of the
> > consequences for
> > things like formats and so on.
> >
> > Cheers,
> >
> > John
> >
> > [1]
> > https://developers.google.com/protocol-buffers/docs/proto#
> choosing-extension-numbers
> > <https://developers.google.com/protocol-buffers/docs/
> proto#choosing-extension-numbers>
> >
> > On Tue, Mar 14, 2017 at 10:08 PM, Jon Evans  > <mailto:j...@craftyjon.com>> wrote:
> > > Hi Orson, Wayne,
> > >
> > > I looked at the "enum inheritance" thing some more and I don't
> > think it
> > > would be a good solution for our case.
> > >
> > > This technique lets you extend enum A with enum B, and have
> > functions f(A)
> >

Re: [Kicad-developers] [PATCH] Zoom to fit on empty canvas

[Jon Evans]

Hi John, JP,

I will take a look at how this would work with GerbView, hopefully later
today.
There is no worksheet item in GerbView, so we might want a more abstract
idea of what the "default view" should be.

For the units question, for sure this needs to be resolved, I don't have
suggestions yet until I look at the code some more.  But, I would think it
makes sense for GAL to work on one units system across all applications,
and code in common to use that units system also, and then it is up to
applications to scale things when they insert them into GAL views.

-Jon

On Thu, Mar 16, 2017 at 2:03 PM, jp charras  wrote:

> Le 16/03/2017 à 11:21, John Beard a écrit :
> > Hi JP,
> >
> > Thank for checking this. Internal units always confuse me, since
> > they're always different and nothing in common can ever use anything
> > to do with IUs, as they're only defined in some end executables.
> >
> > How should this be done correctly?
> >
> > Cheers,
> >
> > John
> >
>
> IUs are not very easy to handle, and currently I am not very happy by the
> way they are handled.
>
> About the GAL layer, sorry, but I am not a GAL specialist.
> However I just know this issue is serious and must be solved.
>
> Until now, GAL was used only by Pcbnew.
> Unfortunately, in a few places, I saw a conversion to nanometers using
> fixed scaling factor.
> (A golden advice I learned when writing Kicad code: do not use a fixed
> scaling factor in code)
>
> Now GAL is very near to be used by other applications.
> Conversion to nanometers just by using a fixed scaling factor is therefore
> a bug, and from my point
> of view, even in Pcbnew.
> Who know: we could change one day the internal unit value. It already
> happened.
>
> I just leave guys who have a good knowledge of the GAL code taking the
> best decision.
>
> Thanks, John.
>
> --
> 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] pcbnew.py: How to set plot color?

[Jon Evans]

JP, is this desired behavior? (I.e. should plot functions draw in layer
color, or draw in plotter color?)

I need to fix the plot functions depending on global function
GetLayerColor() in eeschema, and so since I'll have to modify schematic
plotting functions anyway, I could change the behavior at the same time.

-Jon

On Sat, Mar 18, 2017 at 12:35 PM, jp charras  wrote:

> Le 18/03/2017 à 15:59, Martin Schreiber a écrit :
> > On Friday 03 February 2017 08:25:12 Martin Schreiber wrote:
> >> Hi,
> >> How can the plot color been set while using pcbnew.py?
> >> "
> >> [...]
> >>  board = LoadBoard(apcbfilename)
> >>  pctl = PLOT_CONTROLLER(board)
> >>  popt = pctl.GetPlotOptions()
> >>  popt.SetOutputDirectory(aoutputdir)
> >>  popt.SetPlotFrameRef(False)
> >>  popt.SetLineWidth(FromMM(0.35))
> >>
> >>  popt.SetAutoScale(False)
> >>  popt.SetScale(1)
> >>  popt.SetMirror(False)
> >>  popt.SetUseGerberAttributes(True)
> >>  popt.SetExcludeEdgeLayer(True);
> >>  popt.SetUseAuxOrigin(True)
> >>  popt.SetSubtractMaskFromSilk(False)
> >>
> >>  pctl.OpenPlotfile(lnames[0],PLOT_FORMAT_POST,'')
> >>  pctl.SetColorMode(False)
> >>  popt.SetColor(YELLOW)
> >>  pctl.SetLayer(F_SilkS)
> >>  pctl.PlotLayer()
> >>  pctl.ClosePlot()
> >> [...]
> >> "
> >> shows black,
> >> "
> >>  pctl.SetColorMode(True)
> >> "
>
> Currently, plot functions overwrite the initial setting made by
> popt.SetColor(color).
>
> --
> 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] Redundancy in doc comments

[Jon Evans]

Hi Chris,

I agree with this and would also suggest that there are more Doxygen tags
we can use if desired.
In fact, I use a plugin for my editor that generates Doxygen templates
automatically if I type "/**" above a line of code:

/**
 * @brief [brief description]
 * @details [long description]
 *
 * @param aColor [description]
 * @return [description]
 */

There is also the "@see" tag which is quite useful

-Jon

On Wed, Mar 22, 2017 at 10:41 AM, Chris Pavlina 
wrote:

> Hi all and mostly Wayne,
>
> I notice that a lot of our older documentation comments redundantly list
> the name of the function they document:
>
> /**
>  * Function IsVoid
>  * @return true if the field value is void (no text in this field)
>  */
> bool IsVoid() const
>
> I don't see any purpose for this redundancy - Doxygen doesn't use it,
> the formatted documentation actually looks better without it. It seems
> unnecessary to me, and a bit ugly: https://misc.c4757p.com/isvoid.png
>
> (Not to mention that this is a method, not a function ;)
>
> I'd document this method thus:
>
> /**
>  * @return true iff the field value is void (i.e. has no text)
>  */
> bool IsVoid() const
>
> Is there any reason to keep these?
>
> --
> Chris
>
> ___
> 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] Redundancy in doc comments

[Jon Evans]

Yes I agree with you here, I need to figure out how to update my template
because I always end up deleting those.

On Wed, Mar 22, 2017 at 11:14 AM, Chris Pavlina 
wrote:

> I really hate @brief and @details. Doxygen can do that automatically,
> making the brief docstring the first sentence and the details one the
> whole text. It makes for a doc comment that is much more readable in the
> header itself, which is honestly how I read them most of the time.
>
> On Wed, Mar 22, 2017 at 11:11:35AM -0500, Jon Evans wrote:
> > Hi Chris,
> >
> > I agree with this and would also suggest that there are more Doxygen tags
> > we can use if desired.
> > In fact, I use a plugin for my editor that generates Doxygen templates
> > automatically if I type "/**" above a line of code:
> >
> > /**
> >  * @brief [brief description]
> >  * @details [long description]
> >  *
> >  * @param aColor [description]
> >  * @return [description]
> >  */
> >
> > There is also the "@see" tag which is quite useful
> >
> > -Jon
> >
> > On Wed, Mar 22, 2017 at 10:41 AM, Chris Pavlina  >
> > wrote:
> >
> > > Hi all and mostly Wayne,
> > >
> > > I notice that a lot of our older documentation comments redundantly
> list
> > > the name of the function they document:
> > >
> > > /**
> > >  * Function IsVoid
> > >  * @return true if the field value is void (no text in this field)
> > >  */
> > > bool IsVoid() const
> > >
> > > I don't see any purpose for this redundancy - Doxygen doesn't use it,
> > > the formatted documentation actually looks better without it. It seems
> > > unnecessary to me, and a bit ugly: https://misc.c4757p.com/isvoid.png
> > >
> > > (Not to mention that this is a method, not a function ;)
> > >
> > > I'd document this method thus:
> > >
> > > /**
> > >  * @return true iff the field value is void (i.e. has no text)
> > >  */
> > > bool IsVoid() const
> > >
> > > Is there any reason to keep these?
> > >
> > > --
> > > Chris
> > >
> > > ___
> > > 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] UI improvements

[Jon Evans]

I agree with Simon.  I have plans to propose something like this in the
future (i.e. an integrated part library that manages symbols/footprints/etc
together) and it would be best to reserve the term "component" for this
future use, since in my experience that's what "component" means in the big
tools (I have not used Altium, but it is more of a "medium" tool than a
"big" tool FWIW)

I don't have time to detail my proposal now, but basically I think a
"component" should map to one or more footprints, one or more symbols, one
or more vendor part numbers, one or more 3D models, etc.

-Jon

On Thu, Mar 23, 2017 at 8:33 AM, Simon Wells  wrote:

> one of the things that irks me about component is even though its
> meant to only be schematic being component libs a lot of the questions
> asked in irc will state component when they use that as either a
> generic term for symbols AND footprints or sometimes footprints only,
> as to some i guess thats still part of a "component definition".
>
> If at some point down the line we did introduce some sort of package
> that was symbol/footprint/model/spice/... i think that would be a
> much better thing to call a component.
>
> On 24 March 2017 at 02:30, Chris Pavlina  wrote:
> > Ah, interesting. This is a ... fiddly distinction, I don't like it. This
> > is one case where I think we really should _not_ follow.
> >
> > I'm still not flipping from component back to symbol myself though -
> > this is just Altium. The rest of them still mostly use "component",
> > right?
> >
> > On Thu, Mar 23, 2017 at 09:19:45AM -0400, Wayne Stambaugh wrote:
> >> Here is the Altium library documentation:
> >>
> >> http://www.altium.com/documentation/17.0/display/
> ADES/((More+about+Components+and+Libraries))_AD
> >>
> >> Interestingly the terms component, part, symbol, model, and footprint
> >> are all mentioned.
> >>
> >> It appears that the folks at Altium have answered the is it a symbol or
> >> component question:
> >>
> >> http://www.altium.com/documentation/17.0/display/
> ADES/((Understanding+Models,+Components+and+Libraries))_AD#!
> UnderstandingModelsComponentsandLibraries-IsitaSymboloraComponent
> >>
> >> I was looking at the top level documentation where I saw the term
> >> component.  Maybe symbol would be an acceptable term.  In our case it
> >> certainly would be more accurate.  The only real difference is in the
> >> level of detail added to the the schematic symbol that determines the
> >> symbol/component difference and it's pretty grey definition at best.  I
> >> retract my original statement and go with my preference of symbol.
> >>
> >> On 3/23/2017 9:05 AM, Chris Pavlina wrote:
> >> > Many of them actually don't have that notion. Surprisingly enough,
> >> > Altium of all things has a system that is remarkably similar to our
> own,
> >> > just with a different library management discipline applied in their
> >> > standard library.
> >> >
> >> > On Fri, Mar 24, 2017 at 01:50:08AM +1300, Simon Wells wrote:
> >> >> Do most of the other EDA packages not refer to a component as
> >> >> something that combines a symbol AND a footprint though?
> >> >>
> >> >> On 24 March 2017 at 01:34, Wayne Stambaugh 
> wrote:
> >> >>> I'm going to weigh in on this because this has been on my radar
> with the
> >> >>> symbol library table work I've been doing.  I do agree that we need
> to
> >> >>> pick one term and use it consistently.  My preference is the term
> symbol
> >> >>> because in my mind this is a component[1] and this is symbolic
> >> >>> representation[2] of a component ergo symbol.  However, I spent some
> >> >>> time this week checking out the documentation for all of the major
> and
> >> >>> quite a few minor EDA applications and they *all* use the term
> component
> >> >>> when talking about libraries.  This makes me think that for the
> sake of
> >> >>> uniformity with other EDA applications, we should use the term
> >> >>> component.  While I'm not a proponent of doing something just
> because
> >> >>> that's what everyone else is doing, in this case using the term
> >> >>> component may make users coming from other EDA apps a bit more
> >> >>> comfortable.  Personally, I'm comfortable with either term but
> maybe we
> >> >>> should not stray to far from the norm here.
> >> >>>
> >> >>> [1]:
> >> >>> http://www.digikey.com/product-detail/en/stackpole-
> electronics-inc/CF14JT10K0/CF14JT10K0TR-ND/1741265
> >> >>> [2]: https://commons.wikimedia.org/wiki/File:Resistor_symbol_
> America.svg
> >> >>>
> >> >>> On 3/23/2017 7:52 AM, Thor-Arne Hovland wrote:
> >>  Symbol has been used as long as I can remember.
> >> 
> >>  The proper names should probably be defined to avoid confusion.
> >> 
> >>  In my book:
> >>  A "symbol" is a generic repesentation for drawing a schematic,
> >>  and that is whats used in eeschema right now.
> >> 
> >>  A "footprint" is the pads and silkscreen ++ used in pcbnew.
> >> 
> >>  A "housing" is the phys

Re: [Kicad-developers] OpenGL fallback and video compat test

[Jon Evans]

That sounds like a reasonable approach if the lag time of running the test
is low enough to not be a nuisance.  Are these crashes you speak of ones
that appear when the user first tries to switch to OpenGL, or later?

One alternative approach (that might actually work well alongside yours) is
a crash sentinel.
Basically if you save some value somewhere that indicates a clean exit of
the program, then if you start the program and the value isn't as expected,
you can assume that the program crashed, and take some action (for example,
falling back to Cairo canvas as a "safe mode" and alerting the user)

-Jon

On Thu, Mar 23, 2017 at 8:11 PM, Chris Pavlina 
wrote:

> Hi,
>
> I've been thinking about my intent to make KiCad fall back cleanly to
> Cairo when OpenGL isn't available. From what I can see, there are
> certain situations where trying to use OpenGL causes crashes that appear
> very hard to prevent.
>
> I really want to do something about this - they're hard to prevent, but
> I still don't think it's acceptable to crash out on the user. What if we
> compiled a small test binary that just tried to load an OpenGL canvas?
> We should be able to test for functionality pretty easily by starting
> that executable, and any crash would be confined to its own process. Is
> anyone opposed to this? I know it's not the cleanest solution, but I
> can't think of much better.
>
> --
> Chris
>
> ___
> 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] OpenGL fallback and video compat test

[Jon Evans]

On Thu, Mar 23, 2017 at 8:30 PM, Chris Pavlina 
wrote:

> Remember, once a crash has actually
> occurred in the main program you're already past the point of no return
> for possible data loss.
>
>
One alternative approach which can work quite well (Mentor Graphics does
this) is to get a really good auto-save system going.  The better the
auto-save system, the less likely it is that any crash could cause data
loss.  Of course, crashes in general are a bad user experience, but if you
open the program back up and your work is right there, it feels a bit
better :-)

-J
___
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] Refactor LAYER_ID to be the one and only layer definition

[Jon Evans]

Hi Wayne,

Any feedback on this?

Thanks,
Jon

On Wed, Mar 22, 2017 at 6:15 AM, Maciej Sumiński 
wrote:

> I have briefly tested the patch, no issues found. I have no objections
> to the changes, but I will leave the final decision to Wayne.
>
> Regards,
> Orson
>
> On 03/22/2017 03:51 AM, Jon Evans wrote:
> > Hi Wayne, new patch attached.
> >
> > Thanks,
> > Jon
> >
> > On Tue, Mar 21, 2017 at 9:28 AM, Wayne Stambaugh 
> > wrote:
> >
> >> Jon,
> >>
> >> I just attempted to apply your patch and it no longer applies cleanly.
> >> Please rebase it when you get a chance.
> >>
> >> Thanks,
> >>
> >> Wayne
> >>
> >> On 3/16/2017 10:14 AM, Jon Evans wrote:
> >>> Bump -- does anyone have time to look at this and report back if there
> >>> are any issues?  I'd like to get it merged so that I can feel confident
> >>> about doing more work on top of these changes.
> >>>
> >>> Thanks,
> >>> Jon
> >>>
> >>> On Tue, Mar 14, 2017 at 6:05 PM, Wayne Stambaugh  >>> <mailto:stambau...@gmail.com>> wrote:
> >>>
> >>> Hey Jon,
> >>>
> >>> This is better than the giant enum concept and I'm willing to
> accept
> >>> this.  It still lacks the type safety of the enum inheritance
> >> solution.
> >>> I still see ints being cast to enums and enum bounds checking so
> >> this is
> >>> less than ideal.  I would prefer to see some additional testing so
> if
> >>> any one has time, please test this patch before we commit it.
> >>>
> >>> Thanks,
> >>>
> >>> Wayne
> >>>
> >>> On 3/14/2017 3:09 PM, Jon Evans wrote:
> >>> > Hi Wayne,
> >>> >
> >>> > New patch attached.  Let me know what you think of this approach.
> >>> >
> >>> > Thanks,
> >>> > Jon
> >>> >
> >>> > On Tue, Mar 14, 2017 at 10:40 AM, Jon Evans  >> <mailto:j...@craftyjon.com>
> >>> > <mailto:j...@craftyjon.com <mailto:j...@craftyjon.com>>> wrote:
> >>> >
> >>> > Hi John, that's basically what my first patch did, but inside
> >>> one enum.
> >>> >
> >>> > Hi Wayne, thanks for elaborating more, I see your point.
> >>> >
> >>> > I am still not sure there is benefit to adding some class to
> >>> handle
> >>> > enum inheritance.
> >>> > I think it would work fine to just chain multiple enums
> >>> together, as
> >>> > was done before, but with some tweaks.
> >>> >
> >>> > enum PCB_LAYER_ID
> >>> > {
> >>> > F_Cu = 0,
> >>> > //...
> >>> > PCB_LAYER_ID_COUNT
> >>> > };
> >>> >
> >>> > enum NETNAME_LAYER_ID
> >>> > {
> >>> > NETNAME_LAYER_ID_START = PCB_LAYER_ID_COUNT,
> >>> > NETNAME_LAYER_ID_COUNT = NETNAME_LAYER_ID_START +
> >>> PCB_LAYER_ID_COUNT
> >>> > };
> >>> >
> >>> > enum GAL_LAYER_ID
> >>> > {
> >>> > GAL_LAYER_ID_START = NETNAME_LAYER_ID_COUNT,
> >>> > //
> >>> > };
> >>> >
> >>> > And so on for gerbview, eeschema, etc
> >>> >
> >>> > That way the IDs will be unique and cover a contiguous range,
> >> so
> >>> > functions that want to take any layer ID can just check that
> >>> the ID
> >>> > is >= 0 and < the end sentinel of the last enum.
> >>> >
> >>> > Any concerns with this approach?
> >>> >
> >>> >
> >>> > Best,
> >>> > Jon
> >>> >
> >>> > On Tue, Mar 14, 2017 at 10:29 AM, John Beard
> >>> mailto:john.j.be...@gmail.com>
> >>> > <mailto:john.j.be...@gmail.com
> >>> <mailto:john.

Re: [Kicad-developers] Bug 1677282 fix feedback.

[Jon Evans]

Just thinking about the impact between #3 and #4 (I don't think #1 or #2
are good options)

#3 - impacts everyone who has used both the old and new versions,
regardless of whether they use a VCS.  Impact is a minor annoyance (weird
dialog box, pops up once per schematic, that they probably don't care about)

#4 - impacts everyone from #3 who uses a VCS (fewer people than #3 I would
think).  Impact is a minor annoyance (file changed even if they open/close
it without trying to change it, once per schematic).  Some VCS users might
care, others might not.  For users that do care, we could publish a notice
(on the website, in the docs, etc) explaining what is going on.  Once they
look this up, they will know what is going on, and will likely not be
annoyed for each additional schematic, because they will understand that
their schematic files had invalid data that is now fixed (i.e. it's not a
*meaningless* change to the data requiring a VCS commit).

In both cases, the VCS users have to do a commit.  But in #3, they also
have to click "OK" on an extra dialog box for every schematic.

So, based on this, I would vote #4.

-Jon

On Thu, Mar 30, 2017 at 12:33 PM, Wayne Stambaugh 
wrote:

> I have found and fixed the bug in this bug report:
>
> https://bugs.launchpad.net/kicad/+bug/1677282
>
> This bug creates invalid schematic files which sets the component unit
> flag to 0 and breaks the netlist generator.  The fix itself is simple.
> What is not simple is what to do about the invalid schematic files that
> have already been created.  I added code to schematic parser to fix this
> but this creates a dilemma.  Technically the schematic is modified which
> begs the question, what to do next.  None of the following choices are
> particularly appealing:
>
> 1) Do nothing and leave the file in an invalid status until the next
> time the user saves the schematic.  This is probably the most convenient
> but what about broken schematics being used by versions of kicad prior
> to this fix?
>
> 2) Set the schematic modified status which will trigger a save warning
> when eeschema is closed even if the user hasn't made any changes.  We
> already do this with SCH_SCREEN::SchematicCleanUp() that gets called
> lots of places outside of schematic editing.  The problem with this is
> that the user has no idea why they are getting a save warning when they
> didn't actually change anything.
>
> 3) Set the schematic modified status and inform the user that there was
> an error in their schematic file that was repaired on load and requires
> saving.  This is the most informative for the user but reeks of nagware.
>
> 4) Silently save the corrected schematic with no user interaction.  This
> will undoubtedly make VCS users unhappy.
>
> As much as I hate nagware, I like unexpected save warnings when I
> haven't changed anything even less so I'm leaning towards option 3.  Any
> feedback would be appreciated.
>
> Thanks,
>
> Wayne
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] Add output stream operator for COLOR4D

[Jon Evans]

Hi all,

Quick patch attached to add output stream operator for COLOR4D, useful for
debugging and for some future things I am working on.

-Jon
From 05ff315a03084a27cb69645c4b3dd1aeb9124217 Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Thu, 30 Mar 2017 22:09:19 -0400
Subject: [PATCH] Add output stream operator for COLOR4D

---
 common/gal/color4d.cpp | 7 ++-
 include/gal/color4d.h  | 5 -
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/common/gal/color4d.cpp b/common/gal/color4d.cpp
index 35000d347..b0cbe0354 100644
--- a/common/gal/color4d.cpp
+++ b/common/gal/color4d.cpp
@@ -73,7 +73,7 @@ COLOR4D::COLOR4D( EDA_COLOR_T aColor )
 }
 
 
-wxString COLOR4D::ToWxString( long flags )
+wxString COLOR4D::ToWxString( long flags ) const
 {
 wxColour c = ToColour();
 return c.GetAsString( flags );
@@ -256,6 +256,11 @@ const bool operator!=( const COLOR4D& lhs, const COLOR4D& rhs )
 return !( lhs == rhs );
 }
 
+std::ostream &operator<<( std::ostream &aStream, COLOR4D const &aColor )
+{
+return aStream << aColor.ToWxString( wxC2S_CSS_SYNTAX );
+}
+
 }
 
 
diff --git a/include/gal/color4d.h b/include/gal/color4d.h
index ebcf333bc..eb5300c32 100644
--- a/include/gal/color4d.h
+++ b/include/gal/color4d.h
@@ -87,7 +87,7 @@ public:
  */
 bool SetFromWxString( const wxString& aColorString );
 
-wxString ToWxString( long flags );
+wxString ToWxString( long flags ) const;
 
 wxColour ToColour() const
 {
@@ -297,6 +297,9 @@ const bool operator==( const COLOR4D& lhs, const COLOR4D& rhs );
 /// @brief Not equality operator, are two colors not equal
 const bool operator!=( const COLOR4D& lhs, const COLOR4D& rhs );
 
+/// Syntactic sugar for outputting colors to strings
+std::ostream &operator<<( std::ostream &aStream, COLOR4D const &aColor );
+
 } // namespace KIGFX
 
 #endif /* COLOR4D_H_ */
-- 
2.11.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

[Kicad-developers] Undo/Redo behavior across schematic

[Jon Evans]

(branched from the component table viewer thread)

In my opinion, a schematic with multiple sheets is not like a text editor
with multiple documents.  The schematic editor is working on a single
project, and it should be way more common to apply operations (that might
want to be undone) to all schematic sheets, than it is to apply operations
across all files you happen to have open in a text editor (other than "find
in files", of course).

In my experience, other EDA tools work around the "undoing global changes"
issue that JP mentioned in the same way that text editors do when you
replace in multiple files -- they warn the user that the change cannot be
undone, and sometimes leave the files/sheets in an "unsaved" state so there
is actually a way to undo it for certain files (i.e. by closing them
without saving)

-Jon

On Tue, Apr 18, 2017 at 7:46 AM, Nox  wrote:

> I agree with you about the multi file editor behaviour. There it is
> natural that the undo/redo works per file. But is this behaviour also
> reasonable for a schematic? I just checked the behaviour of visual studio.
> There global replacement will be reverted if the stack is in sync. Else
> only the active document is affected. So I guess you are right. We have to
> first agree which way redo/undo should work. Personally I would perfere to
> move to a "mixed" or global redo/undo.
>
> What do you think: how hard will it be to implement a "container"
> undo/redo item which batchs multiple changes (e.g. for component changes,
> annotation, etc) and has an ID to check with all open sheets if the top
> most change matches. Of course it is questionable if a "silent" partial
> undo/redo is the best way to handle desynced stacks. Or might a global
> redo/undo will be easier to maintain? Or should global operations simply
> always "break" the local undo/redo stacks (so our "state of the
> art"-handling)?
>
> P.S: should we branch the discussion here maybe?
>
>
>
> Am 18.04.2017 um 09:12 schrieb jp charras:
>
>> Le 17/04/2017 à 22:51, Nox a écrit :
>>
>>> I know that I already suggested that in another context but what about
>>> changing the undo/redo
>>> semantic to the more common approach to maintain an global undo/redo
>>> stack and switch the view
>>> accordingly? I know that the "per screen" is the established way in
>>> kicad and that it is very
>>> dangerous to break existing workflows. But the undo/redo behaviour is
>>> currently hardly
>>> "understandable" for beginners. E.g. why does the undo not follow my
>>> actions but stays on one view?
>>> Why does exporting the netlist break the undo? Why can automatic
>>> annotation not be reverted? The
>>> undo list wiped on a frequently basis that personally i hardly trust
>>> into the undo functionality at
>>> all.
>>>
>>> Would it be an option to introduce a "test version" of a global
>>> undo/redo to get some feedback from
>>> the crowed which way would be preferred?
>>>
>>> For me, the problem is not to have a global or per screen undo/redo
>> list, but what an user is
>> expecting when undoing/redoing a change.
>>
>> We *always* expect to undo the last change.
>> Any undo/redo system has this behavior.
>>
>> Now consider an editor (the schematic editor with 3 sheets for instance,
>> but this is also the case
>> of text editors with 3 files opened and currently edited).
>>
>> 1 - in sheet1 you call a tool (component table editor, automatic
>> annotation) which modify all sheets.
>>
>> 2 - after  that you enter sheet2 and make new changes then sheet3 and
>> also make new changes.
>>
>> 3 - back to sheet1 and try to undelete the latest change in this sheet:
>> this is the global change
>> (i.e. annotation). This is possible in sheet1.
>> But how can you undo this annotation in others sheets: this is not the
>> latest change and cannot be
>> undone safely (you can have deleted/replaced/edited a symbol in other
>> sheets, or deleted a sheet):
>> what is the actual meaning of "undo the annotation" in other sheets).
>>
>> And ultimately:
>> What a undo (and therefore redo) command must undo:
>> 1 - the latest change in the full schematic (global undo/redo)
>>   or
>> 2 - the latest change in the currently edited (active) sheet (local
>> undo/redo)
>>
>> This is a choice, and the answer is for me not trivial.
>>
>> It could be worth to know what is the option for global/local changes in
>> a schematic hierarchy in
>> other schematic editors.
>>
>> Multi-file text editors can undo the latest change only in the active
>> file, not in all opened 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
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.

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

[Jon Evans]

Hi David,

This is why other EDA tools have a clear differentiation between
hierarchical blocks (what you are talking about) and multi-sheet schematics
(what I am talking about).  The fact that KiCad mixes the two makes it
difficult to implement some features in a way similar to commercial EDA
tools.

-Jon

On Tue, Apr 18, 2017 at 2:32 PM, David Godfrey  wrote:

> Hi Jon
>
> On 18/04/17 21:27, Wayne Stambaugh wrote:
>
> On 4/18/2017 9:03 AM, Tomasz Wlostowski wrote:
>
> On 18.04.2017 14:55, Jon Evans wrote:
>
> (branched from the component table viewer thread)
>
> In my opinion, a schematic with multiple sheets is not like a text
> editor with multiple documents.  The schematic editor is working on a
> single project, and it should be way more common to apply operations
> (that might want to be undone) to all schematic sheets, than it is to
> apply operations across all files you happen to have open in a text
> editor (other than "find in files", of course).
>
> In my experience, other EDA tools work around the "undoing global
> changes" issue that JP mentioned in the same way that text editors do
> when you replace in multiple files -- they warn the user that the change
> cannot be undone, and sometimes leave the files/sheets in an "unsaved"
> state so there is actually a way to undo it for certain files (i.e. by
> closing them without saving)
>
>
> Hi Jon,
>
> I would suggest having one schematic file per schematic sheet. This
> would greatly simplify the undo/view model, while we could still have
> multiple documents open in tabs. Moreover, each sheet in a separate file
> would make design reuse much easier...
>
> This would break complex hierarchies where a file is referenced in more
> than one sheet.  Using separate files for each sheet actually makes
> designs less reusable in complex hierarchies.  It doesn't make sense to
> save the same file multiple times just for the reference designator
> differences.
>
> It would also break re-usability. I I have a schematic file that
> represents an instrument amp, and use it as a sheet multiple times, I'd
> then expect to modify the schematic once and have the change propagate
> across all instances of that sheet. (eg: adding an additional filter cap)
>
> Cheers,
> Tom
>
>
> -Jon
>
> On Tue, Apr 18, 2017 at 7:46 AM, Nox 
> mailto:noxfiregal...@gmail.com> 
> > wrote:
>
> I agree with you about the multi file editor behaviour. There it is
> natural that the undo/redo works per file. But is this behaviour
> also reasonable for a schematic? I just checked the behaviour of
> visual studio. There global replacement will be reverted if the
> stack is in sync. Else only the active document is affected. So I
> guess you are right. We have to first agree which way redo/undo
> should work. Personally I would perfere to move to a "mixed" or
> global redo/undo.
>
> What do you think: how hard will it be to implement a "container"
> undo/redo item which batchs multiple changes (e.g. for component
> changes, annotation, etc) and has an ID to check with all open
> sheets if the top most change matches. Of course it is questionable
> if a "silent" partial undo/redo is the best way to handle desynced
> stacks. Or might a global redo/undo will be easier to maintain? Or
> should global operations simply always "break" the local undo/redo
> stacks (so our "state of the art"-handling)?
>
> P.S: should we branch the discussion here maybe?
>
>
>
> Am 18.04.2017 um 09:12 schrieb jp charras:
>
> Le 17/04/2017 à 22:51, Nox a écrit :
>
> I know that I already suggested that in another context but
> what about changing the undo/redo
> semantic to the more common approach to maintain an global
> undo/redo stack and switch the view
> accordingly? I know that the "per screen" is the established
> way in kicad and that it is very
> dangerous to break existing workflows. But the undo/redo
> behaviour is currently hardly
> "understandable" for beginners. E.g. why does the undo not
> follow my actions but stays on one view?
> Why does exporting the netlist break the undo? Why can
> automatic annotation not be reverted? The
> undo list wiped on a frequently basis that personally i
> hardly trust into the undo functionality at
> all.
>
> Would it be an option to introduce a "test version" of a
> global und

Re: [Kicad-developers] [FEATURE] Partial selection in pcbnew

[Jon Evans]

The "drag one way to do selection of completely enclosed objects, drag
another way to select any objects that touch the selection area" is
definitely a common pattern in other programs.  I have seen it in various
graphics editing and CAD tools.

re. Kristoffer's point, I think it would be cool to have some kind of
interactive help.

-Jon

On Thu, May 4, 2017 at 7:16 AM, Konrad Beckmann 
wrote:

> SketchUp implements this behaviour as well
> (https://help.sketchup.com/it/article/385). I'm not sure but it
> might be a common pattern in other programs as well. Maybe a helpful
> tooltip-text on the selection tool would be enough?
>
> //Konrad
>
> On Thu, May 4, 2017 at 1:39 PM, Kristoffer Ödmark
>  wrote:
> > Hello!
> >
> > I like the functionality a lot! Selection is probably the one thing that
> is
> > used most of all functions in kicad, so I clearly like that it can be
> done
> > in multiple ways! I do however wonder how one would find and discover
> this
> > functionality?
> >
> > - Kristoffer
> >
> >
> > On 05/02/2017 09:25 AM, Oliver Walters wrote:
> >>
> >> I have attached a patch-set that implements "partial selection" of
> objects
> >> when the selection box is dragged right-to-left.
> >>
> >> L -> R = Objects must be completely enclosed to be selected
> >> R -> L = Objects that intersect the selection rectangle will be
> selected.
> >>
> >> To achieve this I had to fix a lot of the HitTest implementations as
> this
> >> was broken for most shapes, under a variety of edge cases (some HitTest
> code
> >> did not work at all).
> >>
> >> There are two issues I see as outstanding, and am unsure how to proceed:
> >>
> >> 1. When editing a PCB, selecting part of a footprint (e.g. a line of the
> >> courtyard) selects both that line and the entire footprint. This causes
> some
> >> issues when the footprint is dragged around the PCB. I believe that the
> line
> >> should not be selected separately, but the entire footprint should.
> >>
> >> 2. The inverse of 1. In the footprint editor, selecting a single
> graphical
> >> item selects the entire footprint. Somehow I would like to filter the
> >> selection such that individual items are selected but NOT the entire
> >> footprint.
> >>
> >> Feedback please! :)
> >>
> >> I have fixed hit testing (both for wxPoint and EDA_RECT comparison) for:
> >>
> >> - Pads (all shapes)
> >> - Lines
> >> - Circles
> >> - Arcs
> >> - Text items
> >> - Zones
> >> - Footprints
> >>
> >> Cheers,
> >> Oliver
> >>
> >>
> >>
> >>
> >> ___
> >> 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
> >>
> >
> > --
> >  -Kristoffer
> >
> >
> > ___
> > 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] latest news on v5?

[Jon Evans]

I am still hoping to land the following features in 5.0 if the schedule
allows:

- GerbView GAL
- Color themes

I have been away from the project for the past few months due to life stuff
getting in the way, but starting to get back in to it.  My first priority
is getting my GerbView GAL branch to the point where I can submit patches
(my goalpost for this is that nothing crashes, performance is good and no
regressions, and 90% of features supported in GAL mode)

-Jon

On Wed, May 31, 2017 at 6:01 PM, Nick Østergaard  wrote:

> Hi Cirilo,
>
> Since no one have replied I would like to summarize very briefly.
>
> It seems that many people have been busy with other things, so the
> list have been at bit silent recently.
>
> The macos and windows nightlies have been down for a few weeks, but
> are now sort of running again.
>
> I have not had much time to watch the bug tracker too much recently,
> but I know there are quite some reports about segfaults/crashes that
> needs to be evaluated for an upcomming release.
>
> I have less track of what features are supposed to og into v5.0. To me
> this is still unclear, but I guess the biggest blocker is the stuff
> that Wayne is working on. But I lost track of whether or not he needs
> some feedback on something or not.
>
> Nick
>
> 2017-05-29 8:34 GMT+02:00 Cirilo Bernardo :
> > I've been out of action for many months; what's the latest
> > news on efforts/blockers for the v5 release?
> >
> > - Cirilo
> >
> > ___
> > 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] Preferences Editor

[Jon Evans]

For reference, here's the preferences dialog from Eclipse, which is one of
the apps that uses fuzzy search for preferences
(after you start typing, any tree item that doesn't match or have matching
children is hidden, and ones that do match are bolded)


-Jon


On Sun, Jun 4, 2017 at 6:04 PM, Chris Pavlina 
wrote:

> I've been daydreaming of doing this for a while, sounds good to me.
>
> On Sun, Jun 04, 2017 at 10:27:49AM -0400, Jon Evans wrote:
> > I agree with this approach! Switching to a tree lister for preferences
> was
> > on my list of things to propose one day. Complicated creation software
> like
> > KiCad inevitably needs lots of options, and in my opinion this is the
> > nicest way to display them all in one place.
> >
> > Some applications also have a search box right above the tree lister on
> the
> > top left. If you type in something, it performs a fuzzy search and only
> > shows the preference pages that have some text matching your search.
> >
> > In terms of global vs project being separate windows, I don't have a
> strong
> > opinion, but wanted to note that I've used applications with tree view
> > preferences that mix them together (that is, project preferences are just
> > another section of the tree) and think that approach works fine. The
> > advantage is that everything you would possibly want to change is in one
> > window; the disadvantage is possible confusion or overwhelming the user
> > with options.
> >
> > -jon
> >
> >
> > On Jun 4, 2017 10:22, "Oliver Walters" 
> > wrote:
> >
> > Hi all,
> >
> > The "Preferences" menu varies wildly between the different window views.
> >
> > I have been playing around with a new way of displaying and viewing
> > preferences.
> >
> > Here's an early mockup (mostly aesthetic only, although a few of the
> > preference items do work)
> >
> > [image: Inline image 1][image: Inline image 2]
> >
> > My idea is to have three of these dialog windows:
> >
> > a) Global preferences
> > b) Project-specific options (e.g. DRC)
> > c) Library manager
> >
> > I won't go too far down this road before getting feedback, in case this
> is
> > not going to be something that is appreciated or likely to be merged.
> >
> > So... thoughts?
> >
> > Cheers,
> > Oliver
> >
> >
> > ___
> > 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