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

[Chris Pavlina]

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
> > &g

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

[Chris Pavlina]

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 use

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

[Chris Pavlina]

Yup. I'd probably consider moving the elements around a bit so that
"Select working layer" isn't broken into two sections.

On Tue, Feb 21, 2017 at 12:54:51PM -0500, 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 
> 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,

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

[Chris Pavlina]

Maybe. I kinda like how it looks now though.

Though I /would/ like the color squares to be made flat - mainly just
because the little buttons clash with some gtk themes and look butt
ugly.

On Wed, Feb 22, 2017 at 07:02:37AM +1300, Simon Wells wrote:
> could just turn it into a real table and use a highlight for selected row
> 
> On 22 February 2017 at 06:56, Chris Pavlina  wrote:
> > Yup. I'd probably consider moving the elements around a bit so that
> > "Select working layer" isn't broken into two sections.
> >
> > On Tue, Feb 21, 2017 at 12:54:51PM -0500, 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 
> >> 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

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

[Chris Pavlina]

On Tue, Feb 21, 2017 at 01:18:51PM -0500, 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.

Pfft, you always hear users howling. :P

Did you see the suggestion in the thread to move the color boxes to the
other side to avoid accidental clicks?

FWIW I don't think I've ever accidentally clicked one of them.

> 
> 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.
> > > >
> > > > >
> > > > > 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 m

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

[Chris Pavlina]

On Tue, Feb 21, 2017 at 01:26:17PM -0500, Jon Evans wrote:
> 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)

A part of me really wants to fork KiCad, spend a year or so removing ALL
these silly KiCadisms that "users will howl about", and release it as a
new de-crustified project with the understanding that everything will be
different because everything was stupid before. I bet *checks sofa*
$3.24 that users would flock to it.

Sadly, that part of me lives in a fantasy world where days have 48 hours
and I get paid megabucks to sit on my butt.

> 
> 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 l

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

[Chris Pavlina]

This is why I work on KiCad, I figure if I spend enough time on this
I'll never make it to old age >:)

On Tue, Feb 21, 2017 at 06:45:10PM -0500, Wayne Stambaugh wrote:
> It's hell getting old! :)
> 
> On 2/21/2017 6:43 PM, Simon Wells wrote:
> > haha your advanced life experience must be getting to you you even
> > commented on it when it was last bought up on the list
> > https://lists.launchpad.net/kicad-developers/msg23387.html
> > 
> > On 22 February 2017 at 12:39, Wayne Stambaugh  wrote:
> >> Why don't I remember that?  It must not have been that way for very
> >> long.  In any event, I'm actually fine with changing it to a single left
> >> click.  We could always undo it if user's absolutely hate it.
> >>
> >> On 2/21/2017 1:43 PM, Simon Wells wrote:
> >>> there was a time where it was single click changes colour and there
> >>> were no complaints that i saw. JP changed it without consultation or
> >>> comment on the list
> >>>
> >>> On 22 February 2017 at 07:30, Chris Pavlina  
> >>> wrote:
> >>>> On Tue, Feb 21, 2017 at 01:26:17PM -0500, Jon Evans wrote:
> >>>>> 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)
> >>>>
> >>>> A part of me really wants to fork KiCad, spend a year or so removing ALL
> >>>> these silly KiCadisms that "users will howl about", and release it as a
> >>>> new de-crustified project with the understanding that everything will be
> >>>> different because everything was stupid before. I bet *checks sofa*
> >>>> $3.24 that users would flock to it.
> >>>>
> >>>> Sadly, that part of me lives in a fantasy world where days have 48 hours
> >>>> and I get paid megabucks to sit on my butt.
> >>>>
> >>>>>
> >>>>> 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.
> >&

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

[Chris Pavlina]

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 > > 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
>>> > 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
>>> 
>>> 
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> _

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

[Chris Pavlina]

Thank you, Diogo - I've got this patch and am currently looking over the
other MacOS build errors related to this. I'll push both this and
anything else I come up with when I'm done.

On Wed, Feb 22, 2017 at 07:11:03PM +, Diogo Condeço wrote:
> Hi Jon,
> 
> Thanks that was the issue...
> 
> Attached is a patch for this issue... Please credit Jon with it...
> 
> Thanks,
> Diogo
> 
> On Wed, Feb 22, 2017 at 7:01 PM, Jon Evans  wrote:
> 
> > 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 pa

[Kicad-developers] [PATCH] Fix MacOS coroutine segfault

[Chris Pavlina]

Hi,

pcbnew is segfaulting on launch on my MacOS Sierra build, due to a null
dereference in the coroutine code:

coroutine.h
408static CONTEXT_T callerStub( CONTEXT_T caller, INVOCATION_ARGS* aArgsPtr 
)
409{
410const auto& args = *aArgsPtr;
411auto* cor = args.destination;

aArgsPtr is null and I don't understand WHY. However, I was able to make
things appear to work by short-circuiting this function if the argument
is null.

Patch attached. It Works For Me™, but I'd like someone who knows the
coroutine code to look and make sure I haven't made a mess of things.

-- 
Chris
>From 872d6aa16cb027dfc04da18daab85168da40fa71 Mon Sep 17 00:00:00 2001
From: Chris Pavlina 
Date: Wed, 22 Feb 2017 20:09:22 -0500
Subject: [PATCH] Fix MacOS coroutine segfault

---
 include/tool/coroutine.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/tool/coroutine.h b/include/tool/coroutine.h
index 36171a757..231e47a2a 100644
--- a/include/tool/coroutine.h
+++ b/include/tool/coroutine.h
@@ -407,6 +407,9 @@ private:
 /* real entry point of the coroutine */
 static CONTEXT_T callerStub( CONTEXT_T caller, INVOCATION_ARGS* aArgsPtr )
 {
+if( !aArgsPtr )
+return std::move( caller );
+
 const auto& args = *aArgsPtr;
 auto* cor = args.destination;
 
-- 
2.11.1

___
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] Fix MacOS coroutine segfault

[Chris Pavlina]

Backtrace attached. Boost is 1.63.0.

On Thu, Feb 23, 2017 at 11:36:02AM +0100, Maciej Sumiński wrote:
> Hi Chris,
> 
> Would you give more details about the problem? Boost version, backtrace?
> 
> Regards,
> Orson
> 
> On 02/23/2017 02:23 AM, Chris Pavlina wrote:
> > Hi,
> > 
> > pcbnew is segfaulting on launch on my MacOS Sierra build, due to a null
> > dereference in the coroutine code:
> > 
> > coroutine.h
> > 408static CONTEXT_T callerStub( CONTEXT_T caller, INVOCATION_ARGS* 
> > aArgsPtr )
> > 409{
> > 410const auto& args = *aArgsPtr;
> > 411auto* cor = args.destination;
> > 
> > aArgsPtr is null and I don't understand WHY. However, I was able to make
> > things appear to work by short-circuiting this function if the argument
> > is null.
> > 
> > Patch attached. It Works For Me™, but I'd like someone who knows the
> > coroutine code to look and make sure I haven't made a mess of things.
> > 
> > 
> > 
> > ___
> > 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
> > 
> 
> 



(lldb) bt
* thread #1: tid = 0x4fa9, 0x00010ea6aaf1 _pcbnew.kiface`COROUTINE::callerStub(caller=(fctx_ = 0x7fff5fbfc3d0), 
aArgsPtr=0x) + 17 at coroutine.h:411, queue = 
'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8)
  * frame #0: 0x00010ea6aaf1 _pcbnew.kiface`COROUTINE::callerStub(caller=(fctx_ = 0x7fff5fbfc3d0), 
aArgsPtr=0x) + 17 at coroutine.h:411 [opt]
frame #1: 0x00010ea6ae13 
_pcbnew.kiface`std::__1::enable_if::INVOCATION_ARGS*> 
(*)(boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*)>::type>::value), 
std::__1::result_of::INVOCATION_ARGS*> (*&& 
(boost::context::execution_context::INVOCATION_ARGS*>&&, COROUTINE::INVOCATION_ARGS*&&))(boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*)>::type>::type 
boost::context::detail::invoke::INVOCATION_ARGS*> (fn=, args=, 
args=)(boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*), boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*>(boost::context::execution_context::INVOCATION_ARGS*> 
(*&&)(boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*), boost::context::execution_context::INVOCATION_ARGS*>&&, COROUTINE::INVOCATION_ARGS*&&) + 35 at invoke.hpp:41 [opt]
frame #2: 0x00010ea6ad4d 
_pcbnew.kiface`boost::context::detail::record::INVOCATION_ARGS*>, 
boost::context::basic_protected_fixedsize_stack, 
boost::context::execution_context::INVOCATION_ARGS*> (*)(boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*)>::run(boost::context::detail::transfer_t) [inlined] 
decltype(fn=)(boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*)>(fp)std::get<0ul, 
1ul>(std::forward::INVOCATION_ARGS*>&&, COROUTINE::INVOCATION_ARGS*> >(fp0 
boost::context::detail::apply_impl::INVOCATION_ARGS*> 
(*)(boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*), 
std::__1::tuple::INVOCATION_ARGS*>&&, COROUTINE::INVOCATION_ARGS*>, 0ul, 
1ul>(boost::context::execution_context::INVOCATION_ARGS*> 
(*&&)(boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*), 
std::__1::tuple::INVOCATION_ARGS*>&&, COROUTINE::INVOCATION_ARGS*>&&, boost::context::detail::index_sequence<0ul, 1ul>) 
+ 45 at apply.hpp:46 [opt]
frame #3: 0x00010ea6ad44 
_pcbnew.kiface`boost::context::detail::record::INVOCATION_ARGS*>, 
boost::context::basic_protected_fixedsize_stack, 
boost::context::execution_context::INVOCATION_ARGS*> (*)(boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*)>::run(boost::context::detail::transfer_t) [inlined] 
_ZN5boost7context6detail5applyIPFNS0_17execution_contextIJPN9COROUTINEIiRK10TOOL_EVENTE15INVOCATION_ARGSSB_SA_ENSt3__15tupleIJOSB_SA_EDTcl10apply_implclsr3stdE7forwardIT_Efp_Eclsr3stdE7forwardIT0_Efp0_EcvNS1_19make_index_sequenceIXsr3std10tuple_sizeINSE_5decayISJ_E4typeEEE5valueEEEilEEEOSI_OSJ_(fn=)
 at apply.hpp:59 [opt]
frame #4: 0x00010ea6ad44 
_pcbnew.kiface`boost::context::detail::record::INVOCATION_ARGS*>, 
boost::context::basic_protected_fixedsize_stack, 
boost::context::execution_context::INVOCATION_ARGS*> (*)(boost::context::ex

Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

[Chris Pavlina]

Heh, okay, I should have tested more. Seems GAL is quite completely
broken after this patch, do not apply :P


On Thu, Feb 23, 2017 at 06:38:39AM -0500, Chris Pavlina wrote:
> Backtrace attached. Boost is 1.63.0.
> 
> On Thu, Feb 23, 2017 at 11:36:02AM +0100, Maciej Sumiński wrote:
> > Hi Chris,
> > 
> > Would you give more details about the problem? Boost version, backtrace?
> > 
> > Regards,
> > Orson
> > 
> > On 02/23/2017 02:23 AM, Chris Pavlina wrote:
> > > Hi,
> > > 
> > > pcbnew is segfaulting on launch on my MacOS Sierra build, due to a null
> > > dereference in the coroutine code:
> > > 
> > > coroutine.h
> > > 408static CONTEXT_T callerStub( CONTEXT_T caller, INVOCATION_ARGS* 
> > > aArgsPtr )
> > > 409{
> > > 410const auto& args = *aArgsPtr;
> > > 411auto* cor = args.destination;
> > > 
> > > aArgsPtr is null and I don't understand WHY. However, I was able to make
> > > things appear to work by short-circuiting this function if the argument
> > > is null.
> > > 
> > > Patch attached. It Works For Me™, but I'd like someone who knows the
> > > coroutine code to look and make sure I haven't made a mess of things.
> > > 
> > > 
> > > 
> > > ___
> > > 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] Coroutines, in general

[Chris Pavlina]

Hi,

Just out of curiosity, I'm not sure what the reasoning is here and
nobody on IRC really knew last night  ---  can anyone explain why we use
boost::context with our own coroutine implementation on top, rather than
using boost::coroutine? Seems the latter has a much more stable API, is
it missing something we require?

-- 
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

Re: [Kicad-developers] Stable release 4.0.6

[Chris Pavlina]

In the future we should probably look into making our releases a bit
more coordinated.

https://forum.kicad.info/t/4-0-6-for-ubuntu-is-out/5441

On Tue, Feb 14, 2017 at 09:26:21AM -0500, Wayne Stambaugh wrote:
> Are there any outstanding issues to prevent rolling out a 4.0.6 stable
> release?  If not, I will set the version string and tag that commit as
> 4.0.6.  How much time do our source translators, doc devs, and library
> devs need to have everything ready?
> 
> Thanks,
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Coroutines, in general

[Chris Pavlina]

Fair enough. Has coroutine really been as bad as context though? Seems
we've had to resort to using some internal API functions in context,
which really seems to be screwing us over.. :P

On Thu, Feb 23, 2017 at 02:27:59PM +0100, Tomasz Wlostowski wrote:
> On 23.02.2017 14:17, Chris Pavlina wrote:
> > boost::coroutine? Seems the latter has a much more stable API, is
> > it missing something we require?
> 
> Hi Chris,
> 
> I can't agree that either boost::context or boost::coroutine have stable
> APIs, that's why have our own wrapper on top...
> 
> 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

Re: [Kicad-developers] Torrents for KiCad distribution

[Chris Pavlina]

No plans currently. Do you think enough people would use them for it to
really work?

On Feb 23, 2017 9:06 AM, "Ingo Kletti"  wrote:

> Hello,
>
> currently the stable releases are distributed as direct downloads from
> kicad-
> pcb.org. Are there any plans for distributing the stable releases as
> torrents?
>
> Regards,
>
> Ingo
>
> --
> ---
> 
> HTWG Konstanz
> Hochschule Technik, Wirtschaft und Gestaltung
>
> Fakultät Elektrotechnik und Informationstechnik
> Dipl.-Ing. (FH) Ingo Kletti
>
> Alfred-Wachtel-Strasse 8
> 78462 Konstanz
> Germany
>
> Telefon: +49 (0)7531/206-263
> Fax: +49 (0)7531/206-87263
> E-Mail:  ikle...@htwg-konstanz.de
> URL: http://www.htwg-konstanz.de
> 
>
> ___
> 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] Optimization flags in 3d-viewer

[Chris Pavlina]

On Thu, Feb 23, 2017 at 11:45:40AM -0500, Mark Roszko wrote:
> Does -O3 really have that much of an improvement though? I assume the
> only thing cpu bound thing in the 3d viewer is the raytracing.

Even on CPU-bound things -O3 tends not to be too much of an improvement
on both gcc and clang. -O2 is already very good.

> 
> 
> If you really want speed you would throw in PGO :P.
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Torrents for KiCad distribution

[Chris Pavlina]

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

Re: [Kicad-developers] Optimization flags in 3d-viewer

[Chris Pavlina]

On Thu, Feb 23, 2017 at 03:48:39PM +, Mário Luzeiro wrote:
> Yes I added it, because for 3D we need *speed* :P

Things like this are speed holes. https://youtu.be/whnms4CLJys?t=42

*Please* do not add speed holes. If your code is not faster, add
optimizations you understand, and remove them after testing if they do
not show a marked improvement. This just makes the build messy...

> 
> What kind of warnings it is causing? O_o
> 
> Mario
> 
> From: Kicad-developers 
> [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of 
> Simon Richter [simon.rich...@hogyros.de]
> Sent: 23 February 2017 15:25
> To: KiCad Developers
> Subject: [Kicad-developers] Optimization flags in 3d-viewer
> 
> Hi,
> 
> in 3d-viewer/CMakeLists.txt we have
> 
> set( CMAKE_C_FLAGS_RELEASE   "-O3" )
> set( CMAKE_CXX_FLAGS_RELEASE "-O3" )
> 
> Is that intentional?
> 
>  - it seems to be unused in the Make based builds
>  - it overwrites any existing flags in these variables
>  - it causes warnings on MSVC
> 
>Simon
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Optimization flags in 3d-viewer

[Chris Pavlina]

It's okay if you paint the code red though. That really does make it go
faster. Stripes are dope too.

On Thu, Feb 23, 2017 at 10:27:36PM +, Mário Luzeiro wrote:
> I am *sorry*
> 
> Mario
> 
> ____
> From: Chris Pavlina [pavlina.ch...@gmail.com]
> Sent: 23 February 2017 22:06
> To: Mário Luzeiro
> Cc: Simon Richter; KiCad Developers
> Subject: Re: [Kicad-developers] Optimization flags in 3d-viewer
> 
> On Thu, Feb 23, 2017 at 03:48:39PM +, Mário Luzeiro wrote:
> > Yes I added it, because for 3D we need *speed* :P
> 
> Things like this are speed holes. https://youtu.be/whnms4CLJys?t=42
> 
> *Please* do not add speed holes. If your code is not faster, add
> optimizations you understand, and remove them after testing if they do
> not show a marked improvement. This just makes the build messy...
> 
> >
> > What kind of warnings it is causing? O_o
> >
> > Mario
> > 
> > From: Kicad-developers 
> > [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of 
> > Simon Richter [simon.rich...@hogyros.de]
> > Sent: 23 February 2017 15:25
> > To: KiCad Developers
> > Subject: [Kicad-developers] Optimization flags in 3d-viewer
> >
> > Hi,
> >
> > in 3d-viewer/CMakeLists.txt we have
> >
> > set( CMAKE_C_FLAGS_RELEASE   "-O3" )
> > set( CMAKE_CXX_FLAGS_RELEASE "-O3" )
> >
> > Is that intentional?
> >
> >  - it seems to be unused in the Make based builds
> >  - it overwrites any existing flags in these variables
> >  - it causes warnings on MSVC
> >
> >Simon
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Optimization flags in 3d-viewer

[Chris Pavlina]

Keep it up, your eye candy is excellent :D

On Thu, Feb 23, 2017 at 10:43:54PM +, Mário Luzeiro wrote:
> I will! That's my style... That's why I bring the "eye candy wow! factor" to 
> the KiCad's 3D viewer!
> ________
> From: Chris Pavlina [pavlina.ch...@gmail.com]
> Sent: 23 February 2017 22:31
> To: Mário Luzeiro
> Cc: Simon Richter; KiCad Developers
> Subject: Re: [Kicad-developers] Optimization flags in 3d-viewer
> 
> It's okay if you paint the code red though. That really does make it go
> faster. Stripes are dope too.
> 
> On Thu, Feb 23, 2017 at 10:27:36PM +, Mário Luzeiro wrote:
> > I am *sorry*
> >
> > Mario
> >
> > 
> > From: Chris Pavlina [pavlina.ch...@gmail.com]
> > Sent: 23 February 2017 22:06
> > To: Mário Luzeiro
> > Cc: Simon Richter; KiCad Developers
> > Subject: Re: [Kicad-developers] Optimization flags in 3d-viewer
> >
> > On Thu, Feb 23, 2017 at 03:48:39PM +, Mário Luzeiro wrote:
> > > Yes I added it, because for 3D we need *speed* :P
> >
> > Things like this are speed holes. https://youtu.be/whnms4CLJys?t=42
> >
> > *Please* do not add speed holes. If your code is not faster, add
> > optimizations you understand, and remove them after testing if they do
> > not show a marked improvement. This just makes the build messy...
> >
> > >
> > > What kind of warnings it is causing? O_o
> > >
> > > Mario
> > > 
> > > From: Kicad-developers 
> > > [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf 
> > > of Simon Richter [simon.rich...@hogyros.de]
> > > Sent: 23 February 2017 15:25
> > > To: KiCad Developers
> > > Subject: [Kicad-developers] Optimization flags in 3d-viewer
> > >
> > > Hi,
> > >
> > > in 3d-viewer/CMakeLists.txt we have
> > >
> > > set( CMAKE_C_FLAGS_RELEASE   "-O3" )
> > > set( CMAKE_CXX_FLAGS_RELEASE "-O3" )
> > >
> > > Is that intentional?
> > >
> > >  - it seems to be unused in the Make based builds
> > >  - it overwrites any existing flags in these variables
> > >  - it causes warnings on MSVC
> > >
> > >Simon
> > >
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to : kicad-developers@lists.launchpad.net
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help   : https://help.launchpad.net/ListHelp

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

[Kicad-developers] Attn Wayne: Optimizing SCH_PLUGIN for component selection

[Chris Pavlina]

Hi all and Wayne,

Since the addition of SCH_PLUGIN, enumerating all symbols (done by the
component selector) has become dog slow on Windows and macOS. I've
tracked this down to the excursion from an alias list to a list of
strings and back to an alias list, because the only functions SCH_PLUGIN
provides to access the aliases are by name.

This is why the component selector now takes literally five seconds to
appear on Windows.

I have a patch in progress that adds parallels to these API functions
that directly populate a list of LIB_ALIASes rather than their names.
I'm in the process of testing it on all three platforms. It is a fairly
minor addition, but I don't want to touch SCH_PLUGIN without permission
since Wayne is working on it.

Wayne, are you okay with a patch that adds SCH_LEGACY_PLUGIN::
EnumerateSymbolLib( std::vector&, ... )? This is the only
place it touches the plugin API, plus a couple places in PART_LIB and
several in the component chooser.

-- 
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

Re: [Kicad-developers] Attn Wayne: Optimizing SCH_PLUGIN for component selection

[Chris Pavlina]

On Fri, Feb 24, 2017 at 11:38:26AM -0500, Wayne Stambaugh wrote:
> On 2/24/2017 11:29 AM, Chris Pavlina wrote:
> > Hi all and Wayne,
> > 
> > Since the addition of SCH_PLUGIN, enumerating all symbols (done by the
> > component selector) has become dog slow on Windows and macOS. I've
> > tracked this down to the excursion from an alias list to a list of
> > strings and back to an alias list, because the only functions SCH_PLUGIN
> > provides to access the aliases are by name.
> > 
> > This is why the component selector now takes literally five seconds to
> > appear on Windows.
> > 
> > I have a patch in progress that adds parallels to these API functions
> > that directly populate a list of LIB_ALIASes rather than their names.
> > I'm in the process of testing it on all three platforms. It is a fairly
> > minor addition, but I don't want to touch SCH_PLUGIN without permission
> > since Wayne is working on it.
> > 
> > Wayne, are you okay with a patch that adds SCH_LEGACY_PLUGIN::
> > EnumerateSymbolLib( std::vector&, ... )? This is the only
> > place it touches the plugin API, plus a couple places in PART_LIB and
> > several in the component chooser.
> > 
> 
> If it temporarily resolves this issue, then I'm OK with it.  It would be
> nice to be able to limit the exposure of this plugin call for just the
> current PART_LIBS implementation which will have to remain forever to
> support legacy symbol lookup.  Once symbol lookup by path goes away with
> the symbol library table (in progress), this will not be necessary since
> there will always be a one to one mapping of the symbol to a given
> library.  In other words there will be no symbol lookup.  All symbol
> access will be done by a full qualified LIB_ID.

I'm not sure if I understand what you mean, but okay thanks, I'll push
it soon :)

How does symbol access "by a fully qualified LIB_ID" help for
enumerating an entire library, such as what a component selector has to
do in order to filter and sort and search through the library? Is there
some sort of wildcard LIB_ID that returns a collection of symbols?

> 
> 
> ___
> 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] Stable release 4.0.6

[Chris Pavlina]

Yeah - my general impression from a number of inconsistencies in the
file format vs. the spec is that KiCad's file format really should be
considered implementation-defined.

In order to have a _proper_ file format spec, it seems to be that two
things need to be done:

1. Put the format spec _in the repository_
2. Version it, and require anybody changing the format in the code to:
a. Update the MMDD version that gets written to the file
   (technically we already require this, but I've seen a couple
   changes go in without doing this...)
b. Make a new format spec version and document the change

Until we do that, it's implementation-defined with a wannabe spec :P

On Fri, Feb 24, 2017 at 11:23:42PM +0100, Nick Østergaard wrote:
> Normally when we speak of "the docs" we are not talking about the
> fileformat specs, but the stuff in https://github.com/KiCad/kicad-doc
> 
> 2017-02-24 23:22 GMT+01:00 Kevin Cozens :
> > On 2017-02-23 01:29 AM, Nick Østergaard wrote:
> >>
> >> The docs are not quite ready yet,
> >
> >
> > Documentation is (almost) always the last thing to get written or updated. I
> > was making use of the file formats document while working on a project of
> > mine to convert schematics from another program in to one that can be read
> > by Kicad. I found a lot of issues with the docs.
> >
> > I was told Wayne maintains that document. I'll be emailing him to find out
> > what the procedure is for providing information about the changes needed.
> >
> > --
> > 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

___
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] Stable release 4.0.6

[Chris Pavlina]

On Sat, Feb 25, 2017 at 11:04:46AM -0500, Wayne Stambaugh wrote:
> On 2/24/2017 5:22 PM, Kevin Cozens wrote:
> > On 2017-02-23 01:29 AM, Nick Østergaard wrote:
> >> The docs are not quite ready yet,
> > 
> > Documentation is (almost) always the last thing to get written or
> > updated. I was making use of the file formats document while working on
> > a project of mine to convert schematics from another program in to one
> > that can be read by Kicad. I found a lot of issues with the docs.
> > 
> > I was told Wayne maintains that document. I'll be emailing him to find
> > out what the procedure is for providing information about the changes
> > needed.
> > 
> 
> I do not maintain nor did I write any of the file format documents.  I
> believe JP wrote them and maintains them.  I will try to do a better job
> when I implement the new schematic and symbol library file formats but I
> cannot promise anything.  I fully intended on writing the new board and
> footprint library file formats but I just couldn't find the time so JP
> graciously stepped up and wrote them for me.  Now that I am project
> leader, I have even less time for such endeavors.

I still think you should just put them in the repo with the code, and
start requiring people to edit them when they change anything about the
format. Much easier for you than having to maintain them yourself. Just
require proper versioning so that there is a format document version
corresponding to every format version.

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

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

Re: [Kicad-developers] Stable release 4.0.6

[Chris Pavlina]

On Sat, Feb 25, 2017 at 11:52:28AM -0500, Wayne Stambaugh wrote:
> On 2/25/2017 11:28 AM, Chris Pavlina wrote:
> > On Sat, Feb 25, 2017 at 11:04:46AM -0500, Wayne Stambaugh wrote:
> >> On 2/24/2017 5:22 PM, Kevin Cozens wrote:
> >>> On 2017-02-23 01:29 AM, Nick Østergaard wrote:
> >>>> The docs are not quite ready yet,
> >>>
> >>> Documentation is (almost) always the last thing to get written or
> >>> updated. I was making use of the file formats document while working on
> >>> a project of mine to convert schematics from another program in to one
> >>> that can be read by Kicad. I found a lot of issues with the docs.
> >>>
> >>> I was told Wayne maintains that document. I'll be emailing him to find
> >>> out what the procedure is for providing information about the changes
> >>> needed.
> >>>
> >>
> >> I do not maintain nor did I write any of the file format documents.  I
> >> believe JP wrote them and maintains them.  I will try to do a better job
> >> when I implement the new schematic and symbol library file formats but I
> >> cannot promise anything.  I fully intended on writing the new board and
> >> footprint library file formats but I just couldn't find the time so JP
> >> graciously stepped up and wrote them for me.  Now that I am project
> >> leader, I have even less time for such endeavors.
> > 
> > I still think you should just put them in the repo with the code, and
> > start requiring people to edit them when they change anything about the
> > format. Much easier for you than having to maintain them yourself. Just
> > require proper versioning so that there is a format document version
> > corresponding to every format version.
> 
> I'm OK with that as long as we can reformat them to markdown to match
> our current developer documentation.  This way it gets automatically
> generated and uploaded to the website.

I'll happily convert them to Markdown. Send me the most recent versions
just to make sure I've got the right documents.

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

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

Re: [Kicad-developers] Ubuntu build commit IDs

[Chris Pavlina]

*Please*. I'm tired of people asking for support and making me figure
out what "7735" is. We left bzr a long time ago now.

On Sun, Feb 26, 2017 at 11:46:09PM +0800, John Beard wrote:
> Hi,
> 
> Would it be possible to get the ubuntu builds tagged with a commit
> hash? Version strings like  201702251416+7735~57~ubuntu16.10.1 are not
> very useful if you want to know exactly which commit a build relates
> to.
> 
> The exact commit is very useful when looking at a bug report from a
> nightly. If a regression arises between one nightly and the next, the
> date only approximately tells you where to start bisecting.
> 
> The Bzr-style rev number is almost entirely useless especially when
> the build is also tagged with a date, and Bzr is dead and gone.
> Date+git rev give you both an incrementing number for quick
> comparisons of age of build, and the git commit is an unambiguous
> pointer to the exact commit.
> 
> Nearly all "nightly" and "git tracker" pacakges (PPA, AUR, etc) put
> the git hash in the build number, pretty much for this exact reason.
> 
> 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

___
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] Standalone mode.

[Chris Pavlina]

Hi,

There are a few problems with "standalone mode" that I see. One of the
biggest is demonstrated [1] - kiway services aren't available. In my
opinion this really is detrimental to the function of the software -
e.g. eeschema shouldn't be missing features just because it was started
in standalone.

Another problem is the awkwardness of packaging/install on systems that
expect applications to be discrete units, like macOS. There's some
foreshadowing on the bug tracker of trouble wrt. signed packages, which
I couldn't immediately dig up.

I'd really like if we could change this. I don't think standalone mode
the way we implement it is necessary. It is necessary that one can open
a pure schematic file, or a pure PCB file, outside of the context of a
project -- but I do NOT think this should require starting the
individual application separately from the project manager.

What if the project manager simply understood the concept of single
files as well as projects?

[1] https://bugs.launchpad.net/kicad/+bug/1668157

-- 
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

Re: [Kicad-developers] New addition to the lead developer team.

[Chris Pavlina]

Congrats, Tomasz! 

Here, you earned it: 
https://qph.ec.quoracdn.net/main-qimg-513ddac3314cb35edf042fc728e850d1-c

On Mon, Feb 27, 2017 at 04:52:06PM -0500, Wayne Stambaugh wrote:
> I have just given product and stable branch commit privileges to Tomasz
> Wlostowski.  Please join me in congratulating him for his promotion to
> the lead development team.  For those who don't know, Tom is responsible
> for the P&S router, tool framework, and other significant pieces of
> KiCad.  Thank you Tom for all of your contributions to KiCad and welcome
> aboard.
> 
> Cheers,
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

[Chris Pavlina]

I am in favor of this.

On Wed, Mar 01, 2017 at 02:03:37PM +0100, Maciej Sumiński wrote:
> I will do my best, but I really cannot promise any time slot for looking
> into the issue. Perhaps it is the time to revisit Tom's libcontext [1]?
> The number of #ifdefs in tge current coroutine code makes eyes pop out,
> and I am afraid with the new issue we would be forced to add "#ifdef
> __APPLE__" to this horrible mess.
> 
> This way we should be immune to future boost::context changes. The
> drawback is, we are on our own if there is a new architecture to
> support. On the other hand, how often a new architecture becomes popular
> enough to care about it?
> 
> To sum up: I would switch to libcontext and stop worrying.
> 
> Regards,
> Orson
> 
> 1. https://github.com/twlostow/libcontext
> 
> On 02/23/2017 02:07 PM, Wayne Stambaugh wrote:
> > This is a known issue.  I believe the last valid version of boost that
> > doesn't cause a crash is 1.61.  Anything after that causes this issue on
> > all platforms not just osx.  @Orson or @Tom, any chance you could take a
> > look at this to see what boost changed in the context library?
> > 
> > Cheers,
> > 
> > Wayne
> > 
> > On 2/23/2017 6:49 AM, Simon Wells wrote:
> >> just fyi
> >>
> >> https://bugs.launchpad.net/kicad/+bug/1658249
> >>
> >> On 24 February 2017 at 00:38, Chris Pavlina  
> >> wrote:
> >>> Backtrace attached. Boost is 1.63.0.
> >>>
> >>> On Thu, Feb 23, 2017 at 11:36:02AM +0100, Maciej Sumiński wrote:
> >>>> Hi Chris,
> >>>>
> >>>> Would you give more details about the problem? Boost version, backtrace?
> >>>>
> >>>> Regards,
> >>>> Orson
> >>>>
> >>>> On 02/23/2017 02:23 AM, Chris Pavlina wrote:
> >>>>> Hi,
> >>>>>
> >>>>> pcbnew is segfaulting on launch on my MacOS Sierra build, due to a null
> >>>>> dereference in the coroutine code:
> >>>>>
> >>>>> coroutine.h
> >>>>> 408static CONTEXT_T callerStub( CONTEXT_T caller, INVOCATION_ARGS* 
> >>>>> aArgsPtr )
> >>>>> 409{
> >>>>> 410const auto& args = *aArgsPtr;
> >>>>> 411auto* cor = args.destination;
> >>>>>
> >>>>> aArgsPtr is null and I don't understand WHY. However, I was able to make
> >>>>> things appear to work by short-circuiting this function if the argument
> >>>>> is null.
> >>>>>
> >>>>> Patch attached. It Works For Me™, but I'd like someone who knows the
> >>>>> coroutine code to look and make sure I haven't made a mess of things.
> >>>>>
> >>>>>
> >>>>>
> >>>>> ___
> >>>>> 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] Fix MacOS coroutine segfault

[Chris Pavlina]

Wayne *please* tell me you won't block something that fixes macOS
support and eliminates future boost API problems (which we've had
SEVERAL problems with in the past) because of a lack of support for
bloody *SPARC and PPC*. If there is a single user using KiCad on these
platforms I would like to see them.

Now, the lack of support for aarch64 is a disappointment, but it looks
like boost currently doesn't support that either.

On Wed, Mar 01, 2017 at 04:06:51PM +0100, Tomasz Wlostowski wrote:
> On 01.03.2017 15:58, Wayne Stambaugh wrote:
> > I am in favor of this if and only if we have equivalent or better
> > architecture coverage compared to the boost context library.  If not,
> > than I am opposed to it.
> > 
> Hi Wayne,
> 
> Libcontext currently supports x86/x86_64/ARM32 on all OSes. I could not
> test the sparc/PPC ports for obvious reasons. I could  add linux
> sparc/PPC support but without testing, since I don't have a suitable
> machine.
> 
> For the moment, libcontext works on every OS/CPU we officially support.
> 
> Cheers,
> Tom
> 
> 
> > On 3/1/2017 9:32 AM, Chris Pavlina wrote:
> >> I am in favor of this.
> >>
> >> On Wed, Mar 01, 2017 at 02:03:37PM +0100, Maciej Sumiński wrote:
> >>> I will do my best, but I really cannot promise any time slot for looking
> >>> into the issue. Perhaps it is the time to revisit Tom's libcontext [1]?
> >>> The number of #ifdefs in tge current coroutine code makes eyes pop out,
> >>> and I am afraid with the new issue we would be forced to add "#ifdef
> >>> __APPLE__" to this horrible mess.
> > 
> > This probably could have been hidden using cmake.  It typically takes
> > more effort to do it this way but it results in cleaner source code.
> > 
> >>>
> >>> This way we should be immune to future boost::context changes. The
> >>> drawback is, we are on our own if there is a new architecture to
> >>> support. On the other hand, how often a new architecture becomes popular
> >>> enough to care about it?
> >>>
> >>> To sum up: I would switch to libcontext and stop worrying.
> >>>
> >>> Regards,
> >>> Orson
> >>>
> >>> 1. https://github.com/twlostow/libcontext
> >>>
> >>> On 02/23/2017 02:07 PM, Wayne Stambaugh wrote:
> >>>> This is a known issue.  I believe the last valid version of boost that
> >>>> doesn't cause a crash is 1.61.  Anything after that causes this issue on
> >>>> all platforms not just osx.  @Orson or @Tom, any chance you could take a
> >>>> look at this to see what boost changed in the context library?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Wayne
> >>>>
> >>>> On 2/23/2017 6:49 AM, Simon Wells wrote:
> >>>>> just fyi
> >>>>>
> >>>>> https://bugs.launchpad.net/kicad/+bug/1658249
> >>>>>
> >>>>> On 24 February 2017 at 00:38, Chris Pavlina  
> >>>>> wrote:
> >>>>>> Backtrace attached. Boost is 1.63.0.
> >>>>>>
> >>>>>> On Thu, Feb 23, 2017 at 11:36:02AM +0100, Maciej Sumiński wrote:
> >>>>>>> Hi Chris,
> >>>>>>>
> >>>>>>> Would you give more details about the problem? Boost version, 
> >>>>>>> backtrace?
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Orson
> >>>>>>>
> >>>>>>> On 02/23/2017 02:23 AM, Chris Pavlina wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> pcbnew is segfaulting on launch on my MacOS Sierra build, due to a 
> >>>>>>>> null
> >>>>>>>> dereference in the coroutine code:
> >>>>>>>>
> >>>>>>>> coroutine.h
> >>>>>>>> 408static CONTEXT_T callerStub( CONTEXT_T caller, 
> >>>>>>>> INVOCATION_ARGS* aArgsPtr )
> >>>>>>>> 409{
> >>>>>>>> 410const auto& args = *aArgsPtr;
> >>>>>>>> 411auto* cor = args.destination;
> >>>>>>>>
> >>>>>>>> aArgsPtr is null and I don't understand WHY. However, I was able to 
> >>&g

Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

[Chris Pavlina]

Ah, crap. Missed that. Don't think I have one lying about anymore to
volunteer... :(

On Wed, Mar 01, 2017 at 04:21:56PM +0100, Tomasz Wlostowski wrote:
> On 01.03.2017 16:19, Chris Pavlina wrote:
> > Wayne *please* tell me you won't block something that fixes macOS
> > support and eliminates future boost API problems (which we've had
> > SEVERAL problems with in the past) because of a lack of support for
> > bloody *SPARC and PPC*. If there is a single user using KiCad on these
> > platforms I would like to see them.
> > 
> Hi Chris,
> 
> Boost does support aarch64, I just lack a compiler/machine to test that...
> 
> Cheers,
> T.
> > Now, the lack of support for aarch64 is a disappointment, but it looks
> > like boost currently doesn't support that either.
> > 
> > On Wed, Mar 01, 2017 at 04:06:51PM +0100, Tomasz Wlostowski wrote:
> >> On 01.03.2017 15:58, Wayne Stambaugh wrote:
> >>> I am in favor of this if and only if we have equivalent or better
> >>> architecture coverage compared to the boost context library.  If not,
> >>> than I am opposed to it.
> >>>
> >> Hi Wayne,
> >>
> >> Libcontext currently supports x86/x86_64/ARM32 on all OSes. I could not
> >> test the sparc/PPC ports for obvious reasons. I could  add linux
> >> sparc/PPC support but without testing, since I don't have a suitable
> >> machine.
> >>
> >> For the moment, libcontext works on every OS/CPU we officially support.
> >>
> >> Cheers,
> >> Tom
> >>
> >>
> >>> On 3/1/2017 9:32 AM, Chris Pavlina wrote:
> >>>> I am in favor of this.
> >>>>
> >>>> On Wed, Mar 01, 2017 at 02:03:37PM +0100, Maciej Sumiński wrote:
> >>>>> I will do my best, but I really cannot promise any time slot for looking
> >>>>> into the issue. Perhaps it is the time to revisit Tom's libcontext [1]?
> >>>>> The number of #ifdefs in tge current coroutine code makes eyes pop out,
> >>>>> and I am afraid with the new issue we would be forced to add "#ifdef
> >>>>> __APPLE__" to this horrible mess.
> >>>
> >>> This probably could have been hidden using cmake.  It typically takes
> >>> more effort to do it this way but it results in cleaner source code.
> >>>
> >>>>>
> >>>>> This way we should be immune to future boost::context changes. The
> >>>>> drawback is, we are on our own if there is a new architecture to
> >>>>> support. On the other hand, how often a new architecture becomes popular
> >>>>> enough to care about it?
> >>>>>
> >>>>> To sum up: I would switch to libcontext and stop worrying.
> >>>>>
> >>>>> Regards,
> >>>>> Orson
> >>>>>
> >>>>> 1. https://github.com/twlostow/libcontext
> >>>>>
> >>>>> On 02/23/2017 02:07 PM, Wayne Stambaugh wrote:
> >>>>>> This is a known issue.  I believe the last valid version of boost that
> >>>>>> doesn't cause a crash is 1.61.  Anything after that causes this issue 
> >>>>>> on
> >>>>>> all platforms not just osx.  @Orson or @Tom, any chance you could take 
> >>>>>> a
> >>>>>> look at this to see what boost changed in the context library?
> >>>>>>
> >>>>>> Cheers,
> >>>>>>
> >>>>>> Wayne
> >>>>>>
> >>>>>> On 2/23/2017 6:49 AM, Simon Wells wrote:
> >>>>>>> just fyi
> >>>>>>>
> >>>>>>> https://bugs.launchpad.net/kicad/+bug/1658249
> >>>>>>>
> >>>>>>> On 24 February 2017 at 00:38, Chris Pavlina  
> >>>>>>> wrote:
> >>>>>>>> Backtrace attached. Boost is 1.63.0.
> >>>>>>>>
> >>>>>>>> On Thu, Feb 23, 2017 at 11:36:02AM +0100, Maciej Sumiński wrote:
> >>>>>>>>> Hi Chris,
> >>>>>>>>>
> >>>>>>>>> Would you give more details about the problem? Boost version, 
> >>>>>>>>> backtrace?
> >>>>>>&

Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

[Chris Pavlina]

I know I've suggested this before and been shot down, but I'm still
pretty convinced a coroutine library could be made that makes use of
native threading support. This would be totally portable to all
platforms!

I don't have the time to POC it myself, I already have a kicad todo list
miles long. But it seems to me that if we were to spawn a thread for
each coroutine, lock them all to the same core via CPU affinity to avoid
any caching issues, and use a global lock and simple scheduler to
interleave the coroutines (i.e.  when a coroutine yields, it really sets
a lock and waits for it to unlock), it should work just fine..

On Wed, Mar 01, 2017 at 11:16:10AM -0500, Wayne Stambaugh wrote:
> That's the one is was thinking about!  AArch64 is coming fast so we only
> do ourselves a disservice by not supporting it.  In fact, there is now a
> aarch64 device available designed with KiCad.  It would be ironic if
> KiCad couldn't run on it due to lack of support.  SPARC and PPC may not
> be main stream but if we can support them by using an already vetted
> library, than that is my preference.
> 
> On 3/1/2017 10:25 AM, Chris Pavlina wrote:
> > Ah, crap. Missed that. Don't think I have one lying about anymore to
> > volunteer... :(
> > 
> > On Wed, Mar 01, 2017 at 04:21:56PM +0100, Tomasz Wlostowski wrote:
> >> On 01.03.2017 16:19, Chris Pavlina wrote:
> >>> Wayne *please* tell me you won't block something that fixes macOS
> >>> support and eliminates future boost API problems (which we've had
> >>> SEVERAL problems with in the past) because of a lack of support for
> >>> bloody *SPARC and PPC*. If there is a single user using KiCad on these
> >>> platforms I would like to see them.
> >>>
> >> Hi Chris,
> >>
> >> Boost does support aarch64, I just lack a compiler/machine to test that...
> >>
> >> Cheers,
> >> T.
> >>> Now, the lack of support for aarch64 is a disappointment, but it looks
> >>> like boost currently doesn't support that either.
> >>>
> >>> On Wed, Mar 01, 2017 at 04:06:51PM +0100, Tomasz Wlostowski wrote:
> >>>> On 01.03.2017 15:58, Wayne Stambaugh wrote:
> >>>>> I am in favor of this if and only if we have equivalent or better
> >>>>> architecture coverage compared to the boost context library.  If not,
> >>>>> than I am opposed to it.
> >>>>>
> >>>> Hi Wayne,
> >>>>
> >>>> Libcontext currently supports x86/x86_64/ARM32 on all OSes. I could not
> >>>> test the sparc/PPC ports for obvious reasons. I could  add linux
> >>>> sparc/PPC support but without testing, since I don't have a suitable
> >>>> machine.
> >>>>
> >>>> For the moment, libcontext works on every OS/CPU we officially support.
> >>>>
> >>>> Cheers,
> >>>> Tom
> >>>>
> >>>>
> >>>>> On 3/1/2017 9:32 AM, Chris Pavlina wrote:
> >>>>>> I am in favor of this.
> >>>>>>
> >>>>>> On Wed, Mar 01, 2017 at 02:03:37PM +0100, Maciej Sumiński wrote:
> >>>>>>> I will do my best, but I really cannot promise any time slot for 
> >>>>>>> looking
> >>>>>>> into the issue. Perhaps it is the time to revisit Tom's libcontext 
> >>>>>>> [1]?
> >>>>>>> The number of #ifdefs in tge current coroutine code makes eyes pop 
> >>>>>>> out,
> >>>>>>> and I am afraid with the new issue we would be forced to add "#ifdef
> >>>>>>> __APPLE__" to this horrible mess.
> >>>>>
> >>>>> This probably could have been hidden using cmake.  It typically takes
> >>>>> more effort to do it this way but it results in cleaner source code.
> >>>>>
> >>>>>>>
> >>>>>>> This way we should be immune to future boost::context changes. The
> >>>>>>> drawback is, we are on our own if there is a new architecture to
> >>>>>>> support. On the other hand, how often a new architecture becomes 
> >>>>>>> popular
> >>>>>>> enough to care about it?
> >>>>>>>
> >>>>>>> To sum up: I would switch to libcontext and stop worrying.
> >>>>>>>
> >>>>&g

Re: [Kicad-developers] [PATCH] Add missing header

[Chris Pavlina]

C++ standard library headers have no extension.

On Wed, Mar 01, 2017 at 12:26:51PM -0500, Kevin Cozens wrote:
> On 2017-03-01 10:40 AM, Simon Richter wrote:
> 
> On the attached patch it says:
> +#include 
> +
> 
> That looks like a typo. I think that should be 
> 
> -- 
> 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] [PATCH] Fix MacOS coroutine segfault

[Chris Pavlina]

My point is that threading could be used to implement a *drop-in
replacement*...not that the tool framework should be structured around
them, but that it continues to use coroutines, and we make a coroutine
library that is implemented using threads... :P

On Wed, Mar 01, 2017 at 04:32:39PM -0500, Wayne Stambaugh wrote:
> We all have our preferred solutions the problem at hand.  I personally
> didn't see any reason to not use events.  I have a sneaking suspicion
> that the context switching was done to isolate the coder from having to
> deal with events directly which on the surfaces seems like a good idea
> but causes it's own set of design issues when executed within an event
> driven application.  My preference would have been to have the tool
> objects be derived from wxEventHandler (or abstracted out to work with
> different event systems) and inserted between the canvas and the main
> window event handler on the wxWidgets event handler stack.  Since no one
> else stepped up to resolve the issues, the person who resolved them wins. ;)
> 
> On 3/1/2017 12:01 PM, Chris Pavlina wrote:
> > I know I've suggested this before and been shot down, but I'm still
> > pretty convinced a coroutine library could be made that makes use of
> > native threading support. This would be totally portable to all
> > platforms!
> > 
> > I don't have the time to POC it myself, I already have a kicad todo list
> > miles long. But it seems to me that if we were to spawn a thread for
> > each coroutine, lock them all to the same core via CPU affinity to avoid
> > any caching issues, and use a global lock and simple scheduler to
> > interleave the coroutines (i.e.  when a coroutine yields, it really sets
> > a lock and waits for it to unlock), it should work just fine..
> > 
> > On Wed, Mar 01, 2017 at 11:16:10AM -0500, Wayne Stambaugh wrote:
> >> That's the one is was thinking about!  AArch64 is coming fast so we only
> >> do ourselves a disservice by not supporting it.  In fact, there is now a
> >> aarch64 device available designed with KiCad.  It would be ironic if
> >> KiCad couldn't run on it due to lack of support.  SPARC and PPC may not
> >> be main stream but if we can support them by using an already vetted
> >> library, than that is my preference.
> >>
> >> On 3/1/2017 10:25 AM, Chris Pavlina wrote:
> >>> Ah, crap. Missed that. Don't think I have one lying about anymore to
> >>> volunteer... :(
> >>>
> >>> On Wed, Mar 01, 2017 at 04:21:56PM +0100, Tomasz Wlostowski wrote:
> >>>> On 01.03.2017 16:19, Chris Pavlina wrote:
> >>>>> Wayne *please* tell me you won't block something that fixes macOS
> >>>>> support and eliminates future boost API problems (which we've had
> >>>>> SEVERAL problems with in the past) because of a lack of support for
> >>>>> bloody *SPARC and PPC*. If there is a single user using KiCad on these
> >>>>> platforms I would like to see them.
> >>>>>
> >>>> Hi Chris,
> >>>>
> >>>> Boost does support aarch64, I just lack a compiler/machine to test 
> >>>> that...
> >>>>
> >>>> Cheers,
> >>>> T.
> >>>>> Now, the lack of support for aarch64 is a disappointment, but it looks
> >>>>> like boost currently doesn't support that either.
> >>>>>
> >>>>> On Wed, Mar 01, 2017 at 04:06:51PM +0100, Tomasz Wlostowski wrote:
> >>>>>> On 01.03.2017 15:58, Wayne Stambaugh wrote:
> >>>>>>> I am in favor of this if and only if we have equivalent or better
> >>>>>>> architecture coverage compared to the boost context library.  If not,
> >>>>>>> than I am opposed to it.
> >>>>>>>
> >>>>>> Hi Wayne,
> >>>>>>
> >>>>>> Libcontext currently supports x86/x86_64/ARM32 on all OSes. I could not
> >>>>>> test the sparc/PPC ports for obvious reasons. I could  add linux
> >>>>>> sparc/PPC support but without testing, since I don't have a suitable
> >>>>>> machine.
> >>>>>>
> >>>>>> For the moment, libcontext works on every OS/CPU we officially support.
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Tom
> >>>>>>
> >>>>>>
> >>>>>>> On 3/1/2017 9:32 A

Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

[Chris Pavlina]

On Thu, Mar 02, 2017 at 10:15:36AM +0100, "Torsten Hüter" wrote:
> Hi Chris,
>  
> please read the mail archive (Jan 2016), I've already tried this and 
> experimented with different coroutine implementations. I've tested of course 
> a variant based on pthreads too.
>  
> The major showstopper was, that's not recommended to use threads for GUI 
> work, please read:
> http://docs.wxwidgets.org/3.1/overview_thread.html
>  
> "[..] When writing a multi-threaded application, it is strongly recommended 
> that no secondary threads call GUI functions. [..]"
>  
> This would be very restrictive and can't be guaranteed.

With a proper implementation this should be indistinguishable from
coroutines, including to wx.

>  
> If you're still interested, I could upload this implementation on launchpad 
> again. I've stopped working on this, because Tom proposed his libcontext and 
> with the bugfixes it was working so far well on Windows.
>  
> --
>  
> In my opinion I'd drop coroutines entirely - they are nice if they're a 
> build-in language concept (like Modula-2 coroutines), but C++ has not yet the 
> best support for that. Alternatives are simple FSMs, sure that makes the code 
> a bit bulkier, but would work on every machine without having to maintain 
> assembler code.  The disadvantage is the work that you have to invest there 
> (I have not much time to develop KiCad code anymore).
>  
> Thanks,
> Torsten
> 
> Sorry for the double post, forgotten to switch to plain text.
>  
> >> My point is that threading could be used to implement a *drop-in
> >> replacement*...not that the tool framework should be structured around
> >> them, but that it continues to use coroutines, and we make a coroutine
> >> library that is implemented using threads... :P
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

[Chris Pavlina]

Good point about GDI, I wasn't aware about that restriction. Windows
does have fibers which are basically coroutines - I wonder if a separate
Windows implementation could use those. I don't see any such restriction
for fibers.

On Thu, Mar 02, 2017 at 03:58:01PM +0100, "Torsten Hüter" wrote:
> Chris:
> >> With a proper implementation this should be indistinguishable from
> >> coroutines, including to wx.
> 
> This is your opinion not mine, I'm not sure. Again, read the paragraph about 
> secondary threads:
> http://docs.wxwidgets.org/3.1/overview_thread.html
> 
> "[..] under Win32 a thread can only access GDI objects such as pens, brushes, 
> device contexts created by itself and not by the other threads [..]"
> 
> One of the reasons why they strongly recommend "no secondary threads call GUI 
> functions".
> 
> --
> 
> However, if you can ensure that the coroutines never call GUI functions, 
> threads should be a nice alternative. I remember Orson has written, that this 
> should be possible. Maybe he can answer the question if this restriction is 
> still acceptable. Then I could rescue my implementation from my backups.
> 
> Thanks,
> Torsten
> 
> ___
> 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] Selection tool that selects components and local connections

[Chris Pavlina]

Nice! Looks good, and works perfectly here. Merged, thank you :)

On Fri, Mar 03, 2017 at 09:14:33AM +0100, Kristoffer Ödmark wrote:
> Found some coding style errors that were fixed in this.
> 
> And in accordance with previous patches/features ive sent a youtube vid is
> now attached.
> 
> https://youtu.be/fISB7S5YFvo
> 
> - Kristoffer
> 
> On 2017-03-03 00:52, Kristoffer Ödmark wrote:
> >Hello
> >
> >These two patches adds crossprobing to the schematic sheet in the same
> >way that crossprobing behaves when selecting components in eeschema. Ie
> >it selects all items that are only present on a specific sheet.
> >
> >I have only tested on linux for now.
> >
> >-Kristoffer
> >
> >On 2017-02-11 13:36, Chris Pavlina wrote:
> >>Merged. This looks very useful. Thank you for your contribution!
> >>
> >>On Sat, Feb 11, 2017 at 01:25:24PM +0100, Kristoffer Ödmark wrote:
> >>>Sure! here comes!
> >>>
> >>>- Kristoffer
> >>>
> >>>On 2017-02-11 03:02, Chris Pavlina wrote:
> >>>>Can you update this again?
> >>>>
> >>>>On Fri, Feb 10, 2017 at 01:45:10PM +0100, Kristoffer Ödmark wrote:
> >>>>>Updated the patch to fit on current master.
> >>>>>
> >>>>>
> >>>>>On 2017-02-08 21:14, Kristoffer Ödmark wrote:
> >>>>>>I tried reverting back to master and found the same strange bugs on
> >>>>>>windows, so i do not think my patch causes them.
> >>>>>>
> >>>>>>example of bug:
> >>>>>>https://snag.gy/EesP2n.jpg
> >>>>>>
> >>>>>>On 2017-02-08 19:17, Kristoffer Ödmark wrote:
> >>>>>>>Hello again!
> >>>>>>>
> >>>>>>>Since my groupselection required changes to the file format to be
> >>>>>>>useful. I have now created a selection tool that selects all
> >>>>>>>footprints
> >>>>>>>belonging on the same sheet or "deeper".
> >>>>>>>
> >>>>>>>It also finds all nets that only have connections between
> >>>>>>>components on
> >>>>>>>the same or deeper sheet and selects them.
> >>>>>>>
> >>>>>>>It gives some functionality of the group selection idea and does not
> >>>>>>>break file format or any previous workflow.
> >>>>>>>
> >>>>>>>Tested on linux, saw some strange right-click meny errors on
> >>>>>>>windows,
> >>>>>>>but the functionality works there as well when using the shortcut
> >>>>>>>key 'P'
> >>>>>>>
> >>>>>>>Attaching patch
> >>>>>>>
> >>>>>>>Video:
> >>>>>>>https://www.youtube.com/watch?v=DUskyc7t_HA&feature=youtu.be
> >>>>>>>
> >>>>>>>- 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

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

[Chris Pavlina]

I mostly like this. I'm really not keen on the white outline around the
letters though, and it really needs to be adjusted so that the "Ki" and
the "CAD" share a baseline - it feels rough to read otherwise.

On Sat, Mar 04, 2017 at 01:48:44AM +1100, Oliver Walters 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

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

[Chris Pavlina]

Honestly, I need to reply again here - the more I look at this, the less
I like it. I really don't want to be too negative about this, but there
is a lot about this logo that just doesn't work.

- Really bad typography makes it slow to read:
  - Inconsistent tracking -   K  iC A D
  - Inconsistent letter baseline

- The K looks crooked - upper diagonal arm shorter than lower, and the
  lower one dips under the baseline

- Capitalization is wrong, "CAD" might be the correct acronym but we've
  pretty consistently spelled our name "KiCad" for a long time

- An anonymous IRCer points out that the lower diagonal arm on the K
  looks a bit...rude. He's not the only one who sees this.


I quite like the original logo, to be entirely honest. Maybe it could be
improved slightly by changing to a fully sans serif font, but I really
don't think anything else on it needs to be changed.


On Fri, Mar 03, 2017 at 10:01:05AM -0500, Chris Pavlina wrote:
> I mostly like this. I'm really not keen on the white outline around the
> letters though, and it really needs to be adjusted so that the "Ki" and
> the "CAD" share a baseline - it feels rough to read otherwise.
> 
> On Sat, Mar 04, 2017 at 01:48:44AM +1100, Oliver Walters 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

[Kicad-developers] Update on component chooser

[Chris Pavlina]

Hi,

Just thought I'd provide a quick update on what's going on with the
component chooser. Things have been pretty delayed - I've had more
issues than expected, and I'm trying to work around my school schedule
too - but I'm still moving along (and I have almost a full week off now,
most of which will be spent on this).

Currently, I'm working on resolving a macOS performance issue that
causes updates to cost about 0.5s per keystroke for large library sets.
I'm looking at two possible solutions:

 - Implement my own wxDataViewModel, reimplementing most or all of
   COMPONENT_TREE_SEARCH_CONTAINER in the process and making the
   component tree a model/view architecture. This is very much
   preferable, but I'm not 100% sure if this will give the desired
   performance boost. I'll do this first as it's a useful refactoring
   anyway.

 - Implement an optimizing adapter that wraps TWO_COLUMN_TREE_LIST. This
   would populate the underlying list only with visible items,
   intercepting "expand" events and populating the parents with their
   children on demand. This is an ugly hack and I'd like not to resort
   to this.

When I'm done with this, I want to make a couple more changes before
proceeding, based on user feedback:

 - Make the component info box collapsible.
 - Also display component info in a rich tooltip
 - Add a resizable splitter between footprint and symbol display

Once all of this is done, the next steps are:

 - Add footprint filtering and selection
 - Add 3D preview

Please, feel free to file bug reports even on minor UI quirks - I don't
always notice or remember them.

-- 
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

Re: [Kicad-developers] [PATCH/RFC] Pcbnew initial startup user experience

[Chris Pavlina]

Only read through this quickly as I'm pretty busy, but it looks good to
me. There's another issue I've had in mind with the pcbnew OOBE: now
that I'm adding footprint preview to eeschema, the pcbnew init routines
happen on the first run of the eeschema component selector...

I was thinking about consolidating the whole thing into one big KiCad
init routine. Thoughts?

On Sun, Mar 05, 2017 at 07:01:03AM +0800, John Beard wrote:
> Hi,
> 
> Here is a (proposed) patchset to modify the "user experience" (to use
> a buzzword) of Pcbnew and cvPcb when the user loads it for the first
> time with no fp-library-table.
> 
> The current behaviour is quite unfriendly, as it doesn't get the user
> to consent to an action when initialising the library, it does one of
> two actions (cpopy default table, or create empty table - which one
> depends on various conditions) which means that users click the OK
> button not fully knowing what just happened.
> 
> Furthermore, if they click though that dialog without reading it, they
> will then be frustrated by the lack of libraries later, which
> manifests as an error or an empty footprint chooser. Bear in mind, as
> far as users are concerned, the libraries are installed (e.g.
> /usr/share/kicad has content), but as far as KiCad is concerned, they
> are not necessarily configured (empty or default fp-lib-table in
> user's home).
> 
> This has caused several people to struggle with getting started with
> KiCad, and people asking how to proceed is a semi-regular occurence on
> IRC.
> 
> This patch changes to the following process:
> 
> * If user fp-lib-table is found and it has at least one library,
> everything is normal
>   and the user isn't disturbed.
> * If fp-lib-table is missing:
> * On Pcbnew/Cvpcb start, pop up a dialog saying this and giving
> these options:
> * Quit - exit Pcbnew/cvPcb witohut attempting to create
> fp-lib-table. Users can then make their own arrangements.
> * Copy default table - attempt to copy the default table. If
> this fails, return to the choice dialog.
> * Create empty table - if this fails return to the dialog.
> * In no case did the user get an fp-lib-table they didn't ask for.
> * If a blank or default table is created, a second dialog appears,
> informing the user that the library table might need configuration.
> This provides three options:
> * Cancel - user doesn't want to configure the table now, table
> is unchanged
> * Open Manual - the manual referenced in the dialog message is
> opened so the user can read about library configuration
> * Open FP Library Manager - go directly to the library
> manager, rather than expecting the user to cancel the dialog and find
> it themselves. The wizard is accessible from the manager dialog.
> * If fp-lib-table is found, but it's empty when the user goes to use
> it (e.g. on a keyword search for footprints), the
> Cancel/Manual/Manager dialog is shown again, but it's a warning rather
> than informational, as it was before.
> 
> The aim here is to ensure that the configuration is "management by
> consent" and that the user is:
> 
> * Not surprised by "secret" configuration behind the scenes
> * Informed of and consenting to specific actions
> * Guided though configuration with dialogs that give access to
> mentioned tools, rather than a block of text and an OK/Cancel button,
> after which they are on their own.
> 
> Technically speaking, this is done by moving the global fp-lib-table
> loading into common, and invoking it only when the frame is shown
> (rather than prior to the kiface load). The reason for this is so that
> the followup dialog can access the manager. Also, it reduces special
> casing before kiface load.
> 
> The on-show invocation is done by a small class subscribed to the
> frame's wx "Show" event, and once the event is received, the class
> unsubscribes itself (so it's a one-shot), and executes a lits of
> startup actions. The class is such that you can add multiple startup
> actions, any of which can "veto" startup if needed.
> 
> Sorry for the long email: the change is not really that complex, but
> the configuration process has several paths. As the first thing a new
> user to Pcbnew sees, I think this is a fairly important thing to get
> right.
> 
> 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] Update on component chooser

[Chris Pavlina]

Thanks. Could I have a bit more information so I can reproduce these? And
it would be nice if they were in the bug tracker, for... tracking.

On Mar 5, 2017 02:17, "Eldar Khayrullin"  wrote:

> Hello. You do good work.
> I see UI issues:
> - the window struct breaks on resize the window
> - some components doesn't show symbol
> - some components doesn't show fields
>
> kicad@24a9003
> Daily PPA.
> OS: Ubuntu 16.10
>
> В Суббота, 4 мар. 2017 в 9:38 , Chris Pavlina 
> написал:
>
> Hi, Just thought I'd provide a quick update on what's going on with the
> component chooser. Things have been pretty delayed - I've had more issues
> than expected, and I'm trying to work around my school schedule too - but
> I'm still moving along (and I have almost a full week off now, most of
> which will be spent on this). Currently, I'm working on resolving a macOS
> performance issue that causes updates to cost about 0.5s per keystroke for
> large library sets. I'm looking at two possible solutions: - Implement my
> own wxDataViewModel, reimplementing most or all of 
> COMPONENT_TREE_SEARCH_CONTAINER
> in the process and making the component tree a model/view architecture.
> This is very much preferable, but I'm not 100% sure if this will give the
> desired performance boost. I'll do this first as it's a useful refactoring
> anyway. - Implement an optimizing adapter that wraps TWO_COLUMN_TREE_LIST.
> This would populate the underlying list only with visible items,
> intercepting "expand" events and populating the parents with their children
> on demand. This is an ugly hack and I'd like not to resort to this. When
> I'm done with this, I want to make a couple more changes before proceeding,
> based on user feedback: - Make the component info box collapsible. - Also
> display component info in a rich tooltip - Add a resizable splitter between
> footprint and symbol display Once all of this is done, the next steps are:
> - Add footprint filtering and selection - Add 3D preview Please, feel free
> to file bug reports even on minor UI quirks - I don't always notice or
> remember them.
> --
> 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] Update on component chooser

[Chris Pavlina]

Ongoing refactor of COMPONENT_TREE_SEARCH_CONTAINER into a
model-view-adapter architecture is at [1] (componentchooser branch of my
dev repo). The code is seriously cleaner now and significantly faster.
Should be done later today.

[1] https://github.com/cpavlina/kicad/tree/componentchooser


On Sat, Mar 04, 2017 at 01:38:37PM -0500, Chris Pavlina wrote:
> Hi,
> 
> Just thought I'd provide a quick update on what's going on with the
> component chooser. Things have been pretty delayed - I've had more
> issues than expected, and I'm trying to work around my school schedule
> too - but I'm still moving along (and I have almost a full week off now,
> most of which will be spent on this).
> 
> Currently, I'm working on resolving a macOS performance issue that
> causes updates to cost about 0.5s per keystroke for large library sets.
> I'm looking at two possible solutions:
> 
>  - Implement my own wxDataViewModel, reimplementing most or all of
>COMPONENT_TREE_SEARCH_CONTAINER in the process and making the
>component tree a model/view architecture. This is very much
>preferable, but I'm not 100% sure if this will give the desired
>performance boost. I'll do this first as it's a useful refactoring
>anyway.
> 
>  - Implement an optimizing adapter that wraps TWO_COLUMN_TREE_LIST. This
>would populate the underlying list only with visible items,
>intercepting "expand" events and populating the parents with their
>children on demand. This is an ugly hack and I'd like not to resort
>to this.
> 
> When I'm done with this, I want to make a couple more changes before
> proceeding, based on user feedback:
> 
>  - Make the component info box collapsible.
>  - Also display component info in a rich tooltip
>  - Add a resizable splitter between footprint and symbol display
> 
> Once all of this is done, the next steps are:
> 
>  - Add footprint filtering and selection
>  - Add 3D preview
> 
> Please, feel free to file bug reports even on minor UI quirks - I don't
> always notice or remember them.
> 
> -- 
> 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

Re: [Kicad-developers] Standalone mode.

[Chris Pavlina]

On Sun, Mar 05, 2017 at 12:36:20PM -0500, Wayne Stambaugh wrote:
> On 3/4/2017 8:11 PM, Cirilo Bernardo wrote:
> > On Sun, Mar 5, 2017 at 10:29 AM, Wayne Stambaugh  
> > wrote:
> >> On 2/27/2017 11:28 AM, Chris Pavlina wrote:
> >>> Hi,
> >>>
> >>> There are a few problems with "standalone mode" that I see. One of the
> >>> biggest is demonstrated [1] - kiway services aren't available. In my
> >>> opinion this really is detrimental to the function of the software -
> >>> e.g. eeschema shouldn't be missing features just because it was started
> >>> in standalone.
> >>>
> >>> Another problem is the awkwardness of packaging/install on systems that
> >>> expect applications to be discrete units, like macOS. There's some
> >>> foreshadowing on the bug tracker of trouble wrt. signed packages, which
> >>> I couldn't immediately dig up.
> >>>
> >>> I'd really like if we could change this. I don't think standalone mode
> >>> the way we implement it is necessary. It is necessary that one can open
> >>> a pure schematic file, or a pure PCB file, outside of the context of a
> >>> project -- but I do NOT think this should require starting the
> >>> individual application separately from the project manager.
> >>>
> >>> What if the project manager simply understood the concept of single
> >>> files as well as projects?
> >>
> >> I honestly don't know how this will work out.  Regardless of how the
> >> editors are launched, the project configuration is very much in play and
> >> there is currently no support for multiple projects open simultaneously.
> >>  I don't know how you will open a single schematic in a manner which
> >> will wreak havoc on the symbol library lists.  Boards are a different
> >> story since their footprints are embedded so it's probably less of an
> >> issue.  Once the new schematic file format is in play than the symbol
> >> library issue is no longer in play.  I'm not opposed to you trying but I
> >> don't think we are any where near ready to attempt to head down that
> >> path any time soon.
> >>
> > 
> > I think the idea is to have a single executable which can act as the
> > standalone launcher for all the kiway blobs rather than have N
> > installed versions of what is essentially the same launcher. Kicad
> > should still work as expected: if it opens a *.pro file then eeschema
> > and pcbnew can talk to eachother and if it opens a *.sch/*.kicad_pcb
> > file or what not then the program invoked acts like the standalone.
> > 
> > Although it would be nice to have standalone instances of eeschema,
> > pcbnew and so on magically talk to eachother, we all know that would
> > require a well-planned IPC based mechanism and that's not what's
> > being proposed here.
> 
> This should be transparent unless someone changed it.  When launched in
> stand alone mode, the kiway messaging falls back to the legacy sockets
> implementation for message passing.  The problem becomes how to handle
> the IPC when you open the schematic from one project and the board from
> a different project in stand alone mode.

You don't.

What's wrong with just not having IPC between standalone instances? They
shouldn't need to pass anything amongst themselves.

At some point it would be nice to be able to pass clipboard items
between instances, but this can be handled by wxClipboard.

> 
> > 
> > - Cirilo
> > 
> >>>
> >>> [1] https://bugs.launchpad.net/kicad/+bug/1668157
> >>>
> >>
> >>
> >> ___
> >> 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] Standalone mode.

[Chris Pavlina]

On Sun, Mar 05, 2017 at 01:03:34PM -0500, Wayne Stambaugh wrote:
> On 3/5/2017 12:39 PM, Chris Pavlina wrote:
> > On Sun, Mar 05, 2017 at 12:36:20PM -0500, Wayne Stambaugh wrote:
> >> On 3/4/2017 8:11 PM, Cirilo Bernardo wrote:
> >>> On Sun, Mar 5, 2017 at 10:29 AM, Wayne Stambaugh  
> >>> wrote:
> >>>> On 2/27/2017 11:28 AM, Chris Pavlina wrote:
> >>>>> Hi,
> >>>>>
> >>>>> There are a few problems with "standalone mode" that I see. One of the
> >>>>> biggest is demonstrated [1] - kiway services aren't available. In my
> >>>>> opinion this really is detrimental to the function of the software -
> >>>>> e.g. eeschema shouldn't be missing features just because it was started
> >>>>> in standalone.
> >>>>>
> >>>>> Another problem is the awkwardness of packaging/install on systems that
> >>>>> expect applications to be discrete units, like macOS. There's some
> >>>>> foreshadowing on the bug tracker of trouble wrt. signed packages, which
> >>>>> I couldn't immediately dig up.
> >>>>>
> >>>>> I'd really like if we could change this. I don't think standalone mode
> >>>>> the way we implement it is necessary. It is necessary that one can open
> >>>>> a pure schematic file, or a pure PCB file, outside of the context of a
> >>>>> project -- but I do NOT think this should require starting the
> >>>>> individual application separately from the project manager.
> >>>>>
> >>>>> What if the project manager simply understood the concept of single
> >>>>> files as well as projects?
> >>>>
> >>>> I honestly don't know how this will work out.  Regardless of how the
> >>>> editors are launched, the project configuration is very much in play and
> >>>> there is currently no support for multiple projects open simultaneously.
> >>>>  I don't know how you will open a single schematic in a manner which
> >>>> will wreak havoc on the symbol library lists.  Boards are a different
> >>>> story since their footprints are embedded so it's probably less of an
> >>>> issue.  Once the new schematic file format is in play than the symbol
> >>>> library issue is no longer in play.  I'm not opposed to you trying but I
> >>>> don't think we are any where near ready to attempt to head down that
> >>>> path any time soon.
> >>>>
> >>>
> >>> I think the idea is to have a single executable which can act as the
> >>> standalone launcher for all the kiway blobs rather than have N
> >>> installed versions of what is essentially the same launcher. Kicad
> >>> should still work as expected: if it opens a *.pro file then eeschema
> >>> and pcbnew can talk to eachother and if it opens a *.sch/*.kicad_pcb
> >>> file or what not then the program invoked acts like the standalone.
> >>>
> >>> Although it would be nice to have standalone instances of eeschema,
> >>> pcbnew and so on magically talk to eachother, we all know that would
> >>> require a well-planned IPC based mechanism and that's not what's
> >>> being proposed here.
> >>
> >> This should be transparent unless someone changed it.  When launched in
> >> stand alone mode, the kiway messaging falls back to the legacy sockets
> >> implementation for message passing.  The problem becomes how to handle
> >> the IPC when you open the schematic from one project and the board from
> >> a different project in stand alone mode.
> > 
> > You don't.
> > 
> > What's wrong with just not having IPC between standalone instances? They
> > shouldn't need to pass anything amongst themselves.
> 
> This is the legacy behavior which was preserved.  There are still users
> who prefer stand alone mode and expect the IPC to continue to work as it
> did before the kiway work was done.  This somewhat drove the kiway
> design decisions.  We can always decide to do away with the stand alone
> mode and go fully single app but I'm sure there will be a fairly large
> group of users who will not be happy about that decision.  I have no
> idea how large this group will be but given passed responses to such
> suggestions I would guess this is a larger group than you would expect.

Re: [Kicad-developers] Update on component chooser

[Chris Pavlina]

Ready for testing, I'll merge tomorrow since it mostly only touches my
parts. This is a pretty significant improvement, and solves some
wxTreeListCtrl quirks as well.


On Sun, Mar 05, 2017 at 05:02:10PM +0100, Nick Østergaard wrote:
> Please report back when it is ready for testing...
> 
> 2017-03-05 15:04 GMT+01:00 Chris Pavlina :
> > Ongoing refactor of COMPONENT_TREE_SEARCH_CONTAINER into a
> > model-view-adapter architecture is at [1] (componentchooser branch of my
> > dev repo). The code is seriously cleaner now and significantly faster.
> > Should be done later today.
> >
> > [1] https://github.com/cpavlina/kicad/tree/componentchooser
> >
> >
> > On Sat, Mar 04, 2017 at 01:38:37PM -0500, Chris Pavlina wrote:
> >> Hi,
> >>
> >> Just thought I'd provide a quick update on what's going on with the
> >> component chooser. Things have been pretty delayed - I've had more
> >> issues than expected, and I'm trying to work around my school schedule
> >> too - but I'm still moving along (and I have almost a full week off now,
> >> most of which will be spent on this).
> >>
> >> Currently, I'm working on resolving a macOS performance issue that
> >> causes updates to cost about 0.5s per keystroke for large library sets.
> >> I'm looking at two possible solutions:
> >>
> >>  - Implement my own wxDataViewModel, reimplementing most or all of
> >>COMPONENT_TREE_SEARCH_CONTAINER in the process and making the
> >>component tree a model/view architecture. This is very much
> >>preferable, but I'm not 100% sure if this will give the desired
> >>performance boost. I'll do this first as it's a useful refactoring
> >>anyway.
> >>
> >>  - Implement an optimizing adapter that wraps TWO_COLUMN_TREE_LIST. This
> >>would populate the underlying list only with visible items,
> >>intercepting "expand" events and populating the parents with their
> >>children on demand. This is an ugly hack and I'd like not to resort
> >>to this.
> >>
> >> When I'm done with this, I want to make a couple more changes before
> >> proceeding, based on user feedback:
> >>
> >>  - Make the component info box collapsible.
> >>  - Also display component info in a rich tooltip
> >>  - Add a resizable splitter between footprint and symbol display
> >>
> >> Once all of this is done, the next steps are:
> >>
> >>  - Add footprint filtering and selection
> >>  - Add 3D preview
> >>
> >> Please, feel free to file bug reports even on minor UI quirks - I don't
> >> always notice or remember them.
> >>
> >> --
> >> 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] Update on component chooser

[Chris Pavlina]

On Tue, Mar 07, 2017 at 11:58:27AM +1300, Simon Wells wrote:
> I wonder whether it is worth making this a policy that no new
> components can use wxTreeListCtrl as the performance on OSX is abysmal
> and there are alternatives, granted they are slightly more complicated
> but a much better long term solution (not only in osx performance) but
> in code structure as well.

I agree. wxTreeCtrl is fine, but if you need more sophisticated data or
display you should go straight to wxDataViewCtrl. I'm 100% in favor of
making it policy.

> 
> On 6 March 2017 at 17:00, Chris Pavlina  wrote:
> > Ready for testing, I'll merge tomorrow since it mostly only touches my
> > parts. This is a pretty significant improvement, and solves some
> > wxTreeListCtrl quirks as well.
> >
> >
> > On Sun, Mar 05, 2017 at 05:02:10PM +0100, Nick Østergaard wrote:
> >> Please report back when it is ready for testing...
> >>
> >> 2017-03-05 15:04 GMT+01:00 Chris Pavlina :
> >> > Ongoing refactor of COMPONENT_TREE_SEARCH_CONTAINER into a
> >> > model-view-adapter architecture is at [1] (componentchooser branch of my
> >> > dev repo). The code is seriously cleaner now and significantly faster.
> >> > Should be done later today.
> >> >
> >> > [1] https://github.com/cpavlina/kicad/tree/componentchooser
> >> >
> >> >
> >> > On Sat, Mar 04, 2017 at 01:38:37PM -0500, Chris Pavlina wrote:
> >> >> Hi,
> >> >>
> >> >> Just thought I'd provide a quick update on what's going on with the
> >> >> component chooser. Things have been pretty delayed - I've had more
> >> >> issues than expected, and I'm trying to work around my school schedule
> >> >> too - but I'm still moving along (and I have almost a full week off now,
> >> >> most of which will be spent on this).
> >> >>
> >> >> Currently, I'm working on resolving a macOS performance issue that
> >> >> causes updates to cost about 0.5s per keystroke for large library sets.
> >> >> I'm looking at two possible solutions:
> >> >>
> >> >>  - Implement my own wxDataViewModel, reimplementing most or all of
> >> >>COMPONENT_TREE_SEARCH_CONTAINER in the process and making the
> >> >>component tree a model/view architecture. This is very much
> >> >>preferable, but I'm not 100% sure if this will give the desired
> >> >>performance boost. I'll do this first as it's a useful refactoring
> >> >>anyway.
> >> >>
> >> >>  - Implement an optimizing adapter that wraps TWO_COLUMN_TREE_LIST. This
> >> >>would populate the underlying list only with visible items,
> >> >>intercepting "expand" events and populating the parents with their
> >> >>children on demand. This is an ugly hack and I'd like not to resort
> >> >>to this.
> >> >>
> >> >> When I'm done with this, I want to make a couple more changes before
> >> >> proceeding, based on user feedback:
> >> >>
> >> >>  - Make the component info box collapsible.
> >> >>  - Also display component info in a rich tooltip
> >> >>  - Add a resizable splitter between footprint and symbol display
> >> >>
> >> >> Once all of this is done, the next steps are:
> >> >>
> >> >>  - Add footprint filtering and selection
> >> >>  - Add 3D preview
> >> >>
> >> >> Please, feel free to file bug reports even on minor UI quirks - I don't
> >> >> always notice or remember them.
> >> >>
> >> >> --
> >> >> 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

___
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] [RFC] Get rid of boost::context

[Chris Pavlina]

Looks good! Wish I had time to test it on OSX or Windows. I'm sure you
know already but it seems to work perfectly on Linux/x86_64 :)

On Tue, Mar 07, 2017 at 02:36:03PM +0100, Tomasz Wlostowski wrote:
> Hi,
> 
> The attached patch removes boost::context dependency by introducing a
> single-file libcontext that automatically detects the compiler &
> platform and provides a stable API, contrary to the Boost libs. If you
> have some spare time, please test it, in particular on Windows and OSX.
> 
> I verified the library (outside Kicad) on
> Win32/Win64/Linux-i386/Linux-x86/64, OSX/x86_64, Linux/ARM and
> Linux/Aarch64. Compared to boost, there is no support for Sparc and PPC
> platforms. If anyone here pops up willing to test the Sparc/PPC support,
> I can add it.
> 
> I hope this will sort out the boost issues for good.
> 
> 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

Re: [Kicad-developers] [PATCH] [RFC] Get rid of boost::context

[Chris Pavlina]

How thoroughly? I can build it on macOS and poke around a bit, but I
don't have time to spend a day doing layout with it right now.


On Tue, Mar 07, 2017 at 09:23:30AM -0500, Wayne Stambaugh wrote:
> It needs to be tested on osx before we commit the patch.
> 
> On 3/7/2017 9:24 AM, Maciej Sumiński wrote:
> > Brief testing with Win7 x86_64 gives positive results. I really hope
> > this is the end of the boost::context nightmare.
> > 
> > Cheers,
> > Orson
> > 
> > On 03/07/2017 02:36 PM, Tomasz Wlostowski wrote:
> >> Hi,
> >>
> >> The attached patch removes boost::context dependency by introducing a
> >> single-file libcontext that automatically detects the compiler &
> >> platform and provides a stable API, contrary to the Boost libs. If you
> >> have some spare time, please test it, in particular on Windows and OSX.
> >>
> >> I verified the library (outside Kicad) on
> >> Win32/Win64/Linux-i386/Linux-x86/64, OSX/x86_64, Linux/ARM and
> >> Linux/Aarch64. Compared to boost, there is no support for Sparc and PPC
> >> platforms. If anyone here pops up willing to test the Sparc/PPC support,
> >> I can add it.
> >>
> >> I hope this will sort out the boost issues for good.
> >>
> >> 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
> >>
> > 
> > 
> > 
> > 
> > ___
> > 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] [RFC] Get rid of boost::context

[Chris Pavlina]

Tested, works fine.

By the way, the following commit breaks the build on macOS, and probably
also Linux+clang. I had to revert it to get a successful build:

commit d1550b0cdb990ba1f4f32220e110f8ff6331a5f1
Author: Maciej Suminski 
Date:   Mon Mar 6 11:41:06 2017 +0100

Renamed VIEW_CONTROLS::SETTINGS to VC_SETTINGS.

Because nested types cannot be forwarded.



On Tue, Mar 07, 2017 at 09:40:04AM -0500, Wayne Stambaugh wrote:
> I'm thinking a valid build and a quick check that the P&S router doesn't
> crash should be adequate.
> 
> On 3/7/2017 9:32 AM, Chris Pavlina wrote:
> > How thoroughly? I can build it on macOS and poke around a bit, but I
> > don't have time to spend a day doing layout with it right now.
> > 
> > 
> > On Tue, Mar 07, 2017 at 09:23:30AM -0500, Wayne Stambaugh wrote:
> >> It needs to be tested on osx before we commit the patch.
> >>
> >> On 3/7/2017 9:24 AM, Maciej Sumiński wrote:
> >>> Brief testing with Win7 x86_64 gives positive results. I really hope
> >>> this is the end of the boost::context nightmare.
> >>>
> >>> Cheers,
> >>> Orson
> >>>
> >>> On 03/07/2017 02:36 PM, Tomasz Wlostowski wrote:
> >>>> Hi,
> >>>>
> >>>> The attached patch removes boost::context dependency by introducing a
> >>>> single-file libcontext that automatically detects the compiler &
> >>>> platform and provides a stable API, contrary to the Boost libs. If you
> >>>> have some spare time, please test it, in particular on Windows and OSX.
> >>>>
> >>>> I verified the library (outside Kicad) on
> >>>> Win32/Win64/Linux-i386/Linux-x86/64, OSX/x86_64, Linux/ARM and
> >>>> Linux/Aarch64. Compared to boost, there is no support for Sparc and PPC
> >>>> platforms. If anyone here pops up willing to test the Sparc/PPC support,
> >>>> I can add it.
> >>>>
> >>>> I hope this will sort out the boost issues for good.
> >>>>
> >>>> 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
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>> ___
> >>> 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] [RFC] Get rid of boost::context

[Chris Pavlina]

On Tue, Mar 07, 2017 at 04:35:44PM +0100, Maciej Sumiński wrote:
> I use Linux+clang (3.9) and here the compiler does not complain. What is
> the error message?

Error dump attached.

> Does it really build if you revert only this
> particular commit?

I also reverted the one directly after it because they looked connected.
The build on macOS takes long enough that I didn't want to have to try
twice.

> 
> Cheers,
> Orson
> 
> On 03/07/2017 04:15 PM, Chris Pavlina wrote:
> > Tested, works fine.
> > 
> > By the way, the following commit breaks the build on macOS, and probably
> > also Linux+clang. I had to revert it to get a successful build:
> > 
> > commit d1550b0cdb990ba1f4f32220e110f8ff6331a5f1
> > Author: Maciej Suminski 
> > Date:   Mon Mar 6 11:41:06 2017 +0100
> > 
> > Renamed VIEW_CONTROLS::SETTINGS to VC_SETTINGS.
> > 
> > Because nested types cannot be forwarded.
> > 
> > 
> > 
> > On Tue, Mar 07, 2017 at 09:40:04AM -0500, Wayne Stambaugh wrote:
> >> I'm thinking a valid build and a quick check that the P&S router doesn't
> >> crash should be adequate.
> >>
> >> On 3/7/2017 9:32 AM, Chris Pavlina wrote:
> >>> How thoroughly? I can build it on macOS and poke around a bit, but I
> >>> don't have time to spend a day doing layout with it right now.
> >>>
> >>>
> >>> On Tue, Mar 07, 2017 at 09:23:30AM -0500, Wayne Stambaugh wrote:
> >>>> It needs to be tested on osx before we commit the patch.
> >>>>
> >>>> On 3/7/2017 9:24 AM, Maciej Sumiński wrote:
> >>>>> Brief testing with Win7 x86_64 gives positive results. I really hope
> >>>>> this is the end of the boost::context nightmare.
> >>>>>
> >>>>> Cheers,
> >>>>> Orson
> >>>>>
> >>>>> On 03/07/2017 02:36 PM, Tomasz Wlostowski wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> The attached patch removes boost::context dependency by introducing a
> >>>>>> single-file libcontext that automatically detects the compiler &
> >>>>>> platform and provides a stable API, contrary to the Boost libs. If you
> >>>>>> have some spare time, please test it, in particular on Windows and OSX.
> >>>>>>
> >>>>>> I verified the library (outside Kicad) on
> >>>>>> Win32/Win64/Linux-i386/Linux-x86/64, OSX/x86_64, Linux/ARM and
> >>>>>> Linux/Aarch64. Compared to boost, there is no support for Sparc and PPC
> >>>>>> platforms. If anyone here pops up willing to test the Sparc/PPC 
> >>>>>> support,
> >>>>>> I can add it.
> >>>>>>
> >>>>>> I hope this will sort out the boost issues for good.
> >>>>>>
> >>>>>> 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
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> ___
> >>>>> 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
> >

Re: [Kicad-developers] [PATCH] [RFC] Get rid of boost::context

[Chris Pavlina]

Lol, it's a pretty major thing if you look at what std::deque was trying
to do...I don't see any way for the compiler to resolve this with the
implementation of std::deque it was using ;)

Thanks for the quick fix.

On Tue, Mar 07, 2017 at 05:24:14PM +0100, Maciej Sumiński wrote:
> Thank you Chris, now it should build fine on OSX as well. I really love
> compilers screaming so much about such minor things.
> 
> Regards,
> Orson
> 
> On 03/07/2017 04:51 PM, Chris Pavlina wrote:
> > On Tue, Mar 07, 2017 at 04:35:44PM +0100, Maciej Sumiński wrote:
> >> I use Linux+clang (3.9) and here the compiler does not complain. What is
> >> the error message?
> > 
> > Error dump attached.
> > 
> >> Does it really build if you revert only this
> >> particular commit?
> > 
> > I also reverted the one directly after it because they looked connected.
> > The build on macOS takes long enough that I didn't want to have to try
> > twice.
> > 
> >>
> >> Cheers,
> >> Orson
> >>
> >> On 03/07/2017 04:15 PM, Chris Pavlina wrote:
> >>> Tested, works fine.
> >>>
> >>> By the way, the following commit breaks the build on macOS, and probably
> >>> also Linux+clang. I had to revert it to get a successful build:
> >>>
> >>> commit d1550b0cdb990ba1f4f32220e110f8ff6331a5f1
> >>> Author: Maciej Suminski 
> >>> Date:   Mon Mar 6 11:41:06 2017 +0100
> >>>
> >>> Renamed VIEW_CONTROLS::SETTINGS to VC_SETTINGS.
> >>>
> >>> Because nested types cannot be forwarded.
> >>>
> >>>
> >>>
> >>> On Tue, Mar 07, 2017 at 09:40:04AM -0500, Wayne Stambaugh wrote:
> >>>> I'm thinking a valid build and a quick check that the P&S router doesn't
> >>>> crash should be adequate.
> >>>>
> >>>> On 3/7/2017 9:32 AM, Chris Pavlina wrote:
> >>>>> How thoroughly? I can build it on macOS and poke around a bit, but I
> >>>>> don't have time to spend a day doing layout with it right now.
> >>>>>
> >>>>>
> >>>>> On Tue, Mar 07, 2017 at 09:23:30AM -0500, Wayne Stambaugh wrote:
> >>>>>> It needs to be tested on osx before we commit the patch.
> >>>>>>
> >>>>>> On 3/7/2017 9:24 AM, Maciej Sumiński wrote:
> >>>>>>> Brief testing with Win7 x86_64 gives positive results. I really hope
> >>>>>>> this is the end of the boost::context nightmare.
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Orson
> >>>>>>>
> >>>>>>> On 03/07/2017 02:36 PM, Tomasz Wlostowski wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> The attached patch removes boost::context dependency by introducing a
> >>>>>>>> single-file libcontext that automatically detects the compiler &
> >>>>>>>> platform and provides a stable API, contrary to the Boost libs. If 
> >>>>>>>> you
> >>>>>>>> have some spare time, please test it, in particular on Windows and 
> >>>>>>>> OSX.
> >>>>>>>>
> >>>>>>>> I verified the library (outside Kicad) on
> >>>>>>>> Win32/Win64/Linux-i386/Linux-x86/64, OSX/x86_64, Linux/ARM and
> >>>>>>>> Linux/Aarch64. Compared to boost, there is no support for Sparc and 
> >>>>>>>> PPC
> >>>>>>>> platforms. If anyone here pops up willing to test the Sparc/PPC 
> >>>>>>>> support,
> >>>>>>>> I can add it.
> >>>>>>>>
> >>>>>>>> I hope this will sort out the boost issues for good.
> >>>>>>>>
> >>>>>>>> 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
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ___
> >>>>>>> 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] [RFC] Get rid of boost::context

[Chris Pavlina]

C++ error messages are _awful_, really.

OT: I wish the language/compiler had a mode to declare certain classes
and templates "opaque", where the compiler would only provide error
messages up to the point where you interact with an object and not
messages from inside it.

Alternatively I'd love a way to restrict types more. The Rust language
has a way to specify all sorts of restrictions on template parameters
via its "trait" system. For example, if you are making a container
class, you can explicitly declare that its contained type must bear the
"Sized" trait, and if you try to use a non-sized type the compiler will
very clearly complain that you passed a non-sized type to a container
requiring Sized. Hell, you could even provide an alternative
implementation of the container for non-sized types that looks up the
size dynamically at runtime and allocates storage on the heap.

C++ needs this.

On Tue, Mar 07, 2017 at 05:31:48PM +0100, Maciej Sumiński wrote:
> I realize what was the problem. What I meant is the verbosity of the
> error message that could be shortened to 'incomplete type information',
> but perhaps a lengthy explanation is sometimes necessary.
> 
> On 03/07/2017 05:26 PM, Chris Pavlina wrote:
> > Lol, it's a pretty major thing if you look at what std::deque was trying
> > to do...I don't see any way for the compiler to resolve this with the
> > implementation of std::deque it was using ;)
> > 
> > Thanks for the quick fix.
> > 
> > On Tue, Mar 07, 2017 at 05:24:14PM +0100, Maciej Sumiński wrote:
> >> Thank you Chris, now it should build fine on OSX as well. I really love
> >> compilers screaming so much about such minor things.
> >>
> >> Regards,
> >> Orson
> >>
> >> On 03/07/2017 04:51 PM, Chris Pavlina wrote:
> >>> On Tue, Mar 07, 2017 at 04:35:44PM +0100, Maciej Sumiński wrote:
> >>>> I use Linux+clang (3.9) and here the compiler does not complain. What is
> >>>> the error message?
> >>>
> >>> Error dump attached.
> >>>
> >>>> Does it really build if you revert only this
> >>>> particular commit?
> >>>
> >>> I also reverted the one directly after it because they looked connected.
> >>> The build on macOS takes long enough that I didn't want to have to try
> >>> twice.
> >>>
> >>>>
> >>>> Cheers,
> >>>> Orson
> >>>>
> >>>> On 03/07/2017 04:15 PM, Chris Pavlina wrote:
> >>>>> Tested, works fine.
> >>>>>
> >>>>> By the way, the following commit breaks the build on macOS, and probably
> >>>>> also Linux+clang. I had to revert it to get a successful build:
> >>>>>
> >>>>> commit d1550b0cdb990ba1f4f32220e110f8ff6331a5f1
> >>>>> Author: Maciej Suminski 
> >>>>> Date:   Mon Mar 6 11:41:06 2017 +0100
> >>>>>
> >>>>> Renamed VIEW_CONTROLS::SETTINGS to VC_SETTINGS.
> >>>>>
> >>>>> Because nested types cannot be forwarded.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Mar 07, 2017 at 09:40:04AM -0500, Wayne Stambaugh wrote:
> >>>>>> I'm thinking a valid build and a quick check that the P&S router 
> >>>>>> doesn't
> >>>>>> crash should be adequate.
> >>>>>>
> >>>>>> On 3/7/2017 9:32 AM, Chris Pavlina wrote:
> >>>>>>> How thoroughly? I can build it on macOS and poke around a bit, but I
> >>>>>>> don't have time to spend a day doing layout with it right now.
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Mar 07, 2017 at 09:23:30AM -0500, Wayne Stambaugh wrote:
> >>>>>>>> It needs to be tested on osx before we commit the patch.
> >>>>>>>>
> >>>>>>>> On 3/7/2017 9:24 AM, Maciej Sumiński wrote:
> >>>>>>>>> Brief testing with Win7 x86_64 gives positive results. I really hope
> >>>>>>>>> this is the end of the boost::context nightmare.
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>> Orson
> >>>>>>>>>
> >>>>>>>>> On 03/07/2017 02:36 PM, Tomasz Wlostowski wrote:
> >>>

[Kicad-developers] Ubuntu Unity repaint issues - anyone seen this?

[Chris Pavlina]

I'm currently dealing with this bug:
https://bugs.launchpad.net/kicad/+bug/1670705

Under certain conditions (which I really have not been able to
identify), wx stops firing paint events for certain widgets, only under
Ubuntu Unity. The same exact system switched to GNOME does not have the
issue.

Has anyone seen an issue like this? I'm totally stumped.

-- 
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

Re: [Kicad-developers] [PATCH] [RFC] Get rid of boost::context

[Chris Pavlina]

On Tue, Mar 07, 2017 at 08:04:17PM +0100, Simon Richter wrote:
> Hi,
> 
> Am 07.03.2017 um 14:36 schrieb Tomasz Wlostowski:
> 
> > The attached patch removes boost::context dependency by introducing a
> > single-file libcontext that automatically detects the compiler &
> > platform and provides a stable API, contrary to the Boost libs. If you
> > have some spare time, please test it, in particular on Windows and OSX.
> 
> Queued as
> 
> http://ci.kicad-pcb.org/job/windows-kicad-msys2-patch/665/
> 
> http://ci.kicad-pcb.org/job/windows-kicad-msvc-patch/10/
> 
> > I verified the library (outside Kicad) on
> > Win32/Win64/Linux-i386/Linux-x86/64, OSX/x86_64, Linux/ARM and
> > Linux/Aarch64. Compared to boost, there is no support for Sparc and PPC
> > platforms. If anyone here pops up willing to test the Sparc/PPC support,
> > I can add it.
> 
> Debian is definitely unhappy when packages drop release architectures,
> so it should be possible to rouse someone there.

Honestly, as far as I'm concerned, Debian can sit and spin if they're
displeased that we've dropped PPC. They're welcome to step up and
provide the testing and support themselves.

> 
>Simon
> 




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

Re: [Kicad-developers] Ubuntu Unity repaint issues - anyone seen this?

[Chris Pavlina]

Bleh, found it. Misuse of Freeze()/Thaw().

On Tue, Mar 07, 2017 at 12:39:24PM -0500, Chris Pavlina wrote:
> I'm currently dealing with this bug:
> https://bugs.launchpad.net/kicad/+bug/1670705
> 
> Under certain conditions (which I really have not been able to
> identify), wx stops firing paint events for certain widgets, only under
> Ubuntu Unity. The same exact system switched to GNOME does not have the
> issue.
> 
> Has anyone seen an issue like this? I'm totally stumped.
> 
> -- 
> 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

[Kicad-developers] [PATCH] Show the busy cursor while loading libraries

[Chris Pavlina]

Hi,

This patch enables display of the "busy" cursor while schematic
libraries are being loaded. Tested on Linux, Windows 10, and macOS
10.12.

-- 
Chris
>From 4003d34cccfea0b88def73169038fa192a94f85f Mon Sep 17 00:00:00 2001
From: Chris Pavlina 
Date: Wed, 8 Mar 2017 15:10:35 -0500
Subject: [PATCH] Show the busy cursor while loading libraries

---
 eeschema/class_library.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/eeschema/class_library.cpp b/eeschema/class_library.cpp
index 22b4a6fbe..0a35a6123 100644
--- a/eeschema/class_library.cpp
+++ b/eeschema/class_library.cpp
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DUPLICATE_NAME_MSG  \
 _(  "Library '%s' has duplicate entry name '%s'.\n" \
@@ -554,6 +555,7 @@ void PART_LIBS::LoadAllLibraries( PROJECT* aProject, bool aShowProgress )
 wxStringfilename;
 wxStringlibs_not_found;
 SEARCH_STACK*   lib_search = aProject->SchSearchS();
+wxBusyCursorbusy_while_loading;
 
 #if defined(DEBUG) && 0
 lib_search->Show( __func__ );
-- 
2.12.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

Re: [Kicad-developers] [PATCH] Show the busy cursor while loading libraries

[Chris Pavlina]

That's why I submitted such a trivial patch to the list first, I figured
someone would say something ;)

It does make sense to me, because the GUI is blocked. The busy cursor
says to me "yes, the GUI is supposed to be blocked right now, it's not
frozen". Even with a progress bar, it can seem unresponsive -
particularly if 1) the progress bar ends up obscured, as can happen with
'weird' window managers sometimes, or 2) if a single library takes a
particularly long time to load, which I'm sure will only get worse if we
eventually allow loading them over the internet like for footprint libs.


On Wed, Mar 08, 2017 at 03:55:10PM -0500, Wayne Stambaugh wrote:
> Does showing a progress dialog and a busy cursor at the same time make
> sense?
> 
> On 3/8/2017 3:36 PM, Chris Pavlina wrote:
> > Hi,
> > 
> > This patch enables display of the "busy" cursor while schematic
> > libraries are being loaded. Tested on Linux, Windows 10, and macOS
> > 10.12.
> > 
> > 
> > 
> > ___
> > 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] Show the busy cursor while loading libraries

[Chris Pavlina]

On Wed, Mar 08, 2017 at 04:33:06PM -0500, Wayne Stambaugh wrote:
> On 3/8/2017 4:08 PM, Chris Pavlina wrote:
> > That's why I submitted such a trivial patch to the list first, I figured
> > someone would say something ;)
> > 
> > It does make sense to me, because the GUI is blocked. The busy cursor
> > says to me "yes, the GUI is supposed to be blocked right now, it's not
> > frozen". Even with a progress bar, it can seem unresponsive -
> > particularly if 1) the progress bar ends up obscured, as can happen with
> > 'weird' window managers sometimes, or 2) if a single library takes a
> > particularly long time to load, which I'm sure will only get worse if we
> > eventually allow loading them over the internet like for footprint libs.
> 
> It's the old belt and suspender method.  Users have got to quit using
> those 'weird' window managers.  It causes way too much grief.

I'm not sure displaying a busy cursor while the GUI is frozen is grief.
I've always considered it correct behavior, to be honest, regardless of
the presence or absence of a weird window manager. The busy cursor has
been used for _years_ to indicate a GUI that cannot be interacted with,
so users expect it - not displaying it sends conflicting messages; you
are saying by the absence of such a standard item that the GUI is ready
to use.

> I'm
> surprised that a single library load takes long enough to need a busy
> cursor but I'm not opposed to the patch.  Does the progress bar in
> wxWidgets have a continuous mode?  That doesn't solve the hidden
> progress window issue though.

There is a continuous mode, though I'm not sure what the benefit of
using it would be, and it's a bit strange (you have to "poke" it pretty
continuously or it freezes). I wouldn't use it.

I'm not sure why library loading got so slow suddenly. I'd profile it
but I don't have time.

> 
> > 
> > 
> > On Wed, Mar 08, 2017 at 03:55:10PM -0500, Wayne Stambaugh wrote:
> >> Does showing a progress dialog and a busy cursor at the same time make
> >> sense?
> >>
> >> On 3/8/2017 3:36 PM, Chris Pavlina wrote:
> >>> Hi,
> >>>
> >>> This patch enables display of the "busy" cursor while schematic
> >>> libraries are being loaded. Tested on Linux, Windows 10, and macOS
> >>> 10.12.
> >>>
> >>>
> >>>
> >>> ___
> >>> 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] Show the busy cursor while loading libraries

[Chris Pavlina]

On Thu, Mar 09, 2017 at 09:46:54AM +1100, Oliver Walters wrote:
> >
> > Slow?  I have noticed that the library loading slowness appeared with
> > the new IO manager thing. Although I don't have any proff to quanify
> > that.
> 
> 
> I can also attest that (at least on Windows) the more recently nightlies
> (corresponding to the new IO plugin, approximately) take ~10s to load a
> library set that was previously < 1s.
> 
> Once the libraries are loaded, eeschema takes an additional length of time
> (~10s) to open, whereas previously it opened "instantly"

I've noticed this too. Funny enough it doesn't seem to happen for all
projects for me. I wonder if it's something only being done sometimes,
or a polynomial time explosion.

Either way someone needs to point the business end of a profiler at the
library loader.

> 
> On Thu, Mar 9, 2017 at 8:54 AM, Nick Østergaard  wrote:
> 
> > 2017-03-08 22:33 GMT+01:00 Wayne Stambaugh :
> > > On 3/8/2017 4:08 PM, Chris Pavlina wrote:
> > >> That's why I submitted such a trivial patch to the list first, I figured
> > >> someone would say something ;)
> > >>
> > >> It does make sense to me, because the GUI is blocked. The busy cursor
> > >> says to me "yes, the GUI is supposed to be blocked right now, it's not
> > >> frozen". Even with a progress bar, it can seem unresponsive -
> > >> particularly if 1) the progress bar ends up obscured, as can happen with
> > >> 'weird' window managers sometimes, or 2) if a single library takes a
> > >> particularly long time to load, which I'm sure will only get worse if we
> > >> eventually allow loading them over the internet like for footprint libs.
> > >
> > > It's the old belt and suspender method.  Users have got to quit using
> > > those 'weird' window managers.  It causes way too much grief.  I'm
> > > surprised that a single library load takes long enough to need a busy
> > > cursor but I'm not opposed to the patch.  Does the progress bar in
> > > wxWidgets have a continuous mode?  That doesn't solve the hidden
> > > progress window issue though.
> > >
> >
> > I like the non-continous mode.
> >
> > Slow?  I have noticed that the library loading slowness appeared with
> > the new IO manager thing. Although I don't have any proff to quanify
> > that.
> >
> > >>
> > >>
> > >> On Wed, Mar 08, 2017 at 03:55:10PM -0500, Wayne Stambaugh wrote:
> > >>> Does showing a progress dialog and a busy cursor at the same time make
> > >>> sense?
> > >>>
> > >>> On 3/8/2017 3:36 PM, Chris Pavlina wrote:
> > >>>> Hi,
> > >>>>
> > >>>> This patch enables display of the "busy" cursor while schematic
> > >>>> libraries are being loaded. Tested on Linux, Windows 10, and macOS
> > >>>> 10.12.
> > >>>>
> > >>>>
> > >>>>
> > >>>> ___
> > >>>> 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] Show the busy cursor while loading libraries

[Chris Pavlina]

The RescueProject() optimization looks good to me.

On Thu, Mar 09, 2017 at 08:59:33AM +0100, jp charras wrote:
> Le 08/03/2017 à 22:50, Chris Pavlina a écrit :
> > On Wed, Mar 08, 2017 at 04:33:06PM -0500, Wayne Stambaugh wrote:
> >> On 3/8/2017 4:08 PM, Chris Pavlina wrote:
> >>> That's why I submitted such a trivial patch to the list first, I figured
> >>> someone would say something ;)
> >>>
> >>> It does make sense to me, because the GUI is blocked. The busy cursor
> >>> says to me "yes, the GUI is supposed to be blocked right now, it's not
> >>> frozen". Even with a progress bar, it can seem unresponsive -
> >>> particularly if 1) the progress bar ends up obscured, as can happen with
> >>> 'weird' window managers sometimes, or 2) if a single library takes a
> >>> particularly long time to load, which I'm sure will only get worse if we
> >>> eventually allow loading them over the internet like for footprint libs.
> >>
> >> It's the old belt and suspender method.  Users have got to quit using
> >> those 'weird' window managers.  It causes way too much grief.
> > 
> > I'm not sure displaying a busy cursor while the GUI is frozen is grief.
> > I've always considered it correct behavior, to be honest, regardless of
> > the presence or absence of a weird window manager. The busy cursor has
> > been used for _years_ to indicate a GUI that cannot be interacted with,
> > so users expect it - not displaying it sends conflicting messages; you
> > are saying by the absence of such a standard item that the GUI is ready
> > to use.
> > 
> >> I'm
> >> surprised that a single library load takes long enough to need a busy
> >> cursor but I'm not opposed to the patch.  Does the progress bar in
> >> wxWidgets have a continuous mode?  That doesn't solve the hidden
> >> progress window issue though.
> > 
> > There is a continuous mode, though I'm not sure what the benefit of
> > using it would be, and it's a bit strange (you have to "poke" it pretty
> > continuously or it freezes). I wouldn't use it.
> > 
> > I'm not sure why library loading got so slow suddenly. I'd profile it
> > but I don't have time.
> 
> I had a look at this.
> I am not sure the library loading itself is really slower.
> 
> the loading time is mainly due to the call to SCH_EDIT_FRAME::RescueProject().
> (previously: 0.5 seconds, now 14 seconds with my large schematic test, but 
> with not a lot of libraries)
> 
> I am thinking the root problem is SCH_COMPONENT::Resolve(), now much more 
> time consuming.
> 
> One other time consuming is SCH_COMPONENT::ResolveAll (previously: a few ms, 
> now 1,4 s with this
> schematic) due to the same reason.
> 
> Both methods are not optimized, and the call to Resolve() is made many times 
> for the same lib id.
> 
> I optimized SCH_COMPONENT::ResolveAll to call Resolve() only once by lib id 
> (see the attached patch.
> (previously: 1.4 s and 0.14 s with fast_sch_component-ResolveAll attached 
> patch)
> 
> I don't know why Resolve() is now so time consuming.
> (A fast search algo could be interesting, but I don't think the previous 
> method was optimized)
> 
> SCH_EDIT_FRAME::RescueProject() could be also optimized to minimize the 
> calculations: there are a
> lot of redundant calculations.
> This is the more time consuming, due to intensive and not optimized use of 
> SCH_COMPONENT::Resolve().
> 
> As a proof, I attached a basic patch (fast_sch_project_rescue_stub) with 
> optimized search.
> However this patch is only a proof, and cannot be used as this, because it 
> searches for modified
> symbols, but does not modify all corresponding components in schematic, only 
> one (but the missing
> feature is not time consuming).
> The calculation time was 13 s and 0.5s with this patch.
> (You also can disable the call to RescueProject() in Eeschema: this is an 
> option)
> 
> 
> I can commit fast_sch_component-ResolveAll patch (If Wayne agrees) because it 
> works fine for me.
> The other patch needs more work.
> 
> -- 
> 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

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

[Chris Pavlina]

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

Re: [Kicad-developers] [PATCH] Show the busy cursor while loading libraries

[Chris Pavlina]

It's faster for me now - about five seconds to load an empty schematic
project with all the official libs, which is bearable, and about the
same time to load a large multipage schematic with a smaller library
set.

Can we declare a verdict on whether the busy cursor is welcome still? I
feel like five seconds is still long enough to warrant one.

On Thu, Mar 09, 2017 at 08:13:20PM +0100, jp charras wrote:
> Le 09/03/2017 à 14:05, Wayne Stambaugh a écrit :
> > JP,
> > 
> > If Chris is OK with these changes, please commit them.  I'm sure users
> > will appreciate the speed up.
> > 
> > Thanks,
> > 
> > Wayne
> 
> OK.
> I committed my fixes.
> I hope I did not break something.
> 
> Loading a large schematic project is really faster now.
> 
> -- 
> 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] Footprint preview panel - faster initialization (Tom?)

[Chris Pavlina]

Thanks, I'll give that a try tonight.

What would _really_ be nice is if GAL could render directly to a pure
in-memory bitmap, and if that were threadsafe ^_^

On Thu, Mar 09, 2017 at 02:34:06PM -0500, Jon Evans wrote:
> 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

Re: [Kicad-developers] [PATCH] Show the busy cursor while loading libraries

[Chris Pavlina]

On Thu, Mar 09, 2017 at 09:01:44PM +0100, jp charras wrote:
> Le 09/03/2017 à 20:31, Chris Pavlina a écrit :
> > It's faster for me now - about five seconds to load an empty schematic
> > project with all the official libs, which is bearable, and about the
> > same time to load a large multipage schematic with a smaller library
> > set.
> > 
> > Can we declare a verdict on whether the busy cursor is welcome still? I
> > feel like five seconds is still long enough to warrant one.
> 
> How many time to load the same things with the stable release?
> The busy cursor is one thing, too many time is an other thing.
> 
> I am thinking the stable release is faster.
> Therefore there is room for more optimizations.

Slightly under one second for both projects on stable.

> 
> > 
> > On Thu, Mar 09, 2017 at 08:13:20PM +0100, jp charras wrote:
> >> Le 09/03/2017 à 14:05, Wayne Stambaugh a écrit :
> >>> JP,
> >>>
> >>> If Chris is OK with these changes, please commit them.  I'm sure users
> >>> will appreciate the speed up.
> >>>
> >>> Thanks,
> >>>
> >>> Wayne
> >>
> >> OK.
> >> I committed my fixes.
> >> I hope I did not break something.
> >>
> >> Loading a large schematic project is really faster now.
> >>
> >> -- 
> >> Jean-Pierre CHARRAS
> 
> 
> -- 
> 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] Footprint preview panel - faster initialization (Tom?)

[Chris Pavlina]

On Thu, Mar 09, 2017 at 09:47:38PM +0100, Maciej Suminski wrote:
> Hi Chris,
> 
> Are you sure this is really needed? GAL is also used in other dialogs,
> such as footprint browser or pad properties editor, and they do not seem
> to take a lot of time to load. What is the initialization time we are
> speaking about?

The load time is acceptable in other dialogs because they're used less.
When you're putting together a schematic and quickly slapping together
symbols, even a fraction of a second feels like a lot. It's currently at
~0.5s on Linux and ~1s on Windows and still just feels *laggy* when I
try to use it in a real project. It's not horrible, it's just one of
those things that slowly drive you insane. :P

> 
> Anyway, if you are determined to optimize it, it is only a win for
> everyone. I do not think we have ever tried keeping a GAL instance
> without showing it, but IMHO it should be possible. OpenGL GAL/Linux
> combination might be whining if you start rendering when the window is
> not visible, but you may simply call DRAW_PANEL_GAL::StopDrawing() and
> DRAW_PANEL_GAL::StartDrawing() as necessary.
> 
> Regarding rendering to memory, it actually happens behind the scenes.
> For Cairo the memory is easily accesible (CAIRO_GAL::wxOutput,
> CAIRO_GAL::bitmapBuffer). OpenGL renders most of the objects (grid is an
> exception) to a framebuffer. Admitted, this is GPU memory, but it might
> be read using glReadPixels().
> 
> Regards,
> Orson
> 
> On 03/09/2017 08: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).
> > 
> 
> ___
> 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] Build failed in Jenkins: linux-kicad-full-gcc-head #1925

[Chris Pavlina]

Fix seems simple, just make LIB_EDIT_FRAME::refreshSchematic()
non-const. It probably shouldn't be const anyway since it edits state.
I'd do it myself but don't want to step on Wayne's toes.

The addition of LIB_EDIT_FRAME::refreshSchematic() allows me to fix an
old bug finally too, so I have a fix waiting in my tree now for the
constness issue to be corrected :)


On Fri, Mar 10, 2017 at 03:16:54PM +0100, Miguel Angel Ajo wrote:
> See 
> 
> 
> Changes:
> 
> [Wayne Stambaugh] Fix broken symbol link in schematic after editing.
> 
> --
> [...truncated 101.04 KB...]
> [ 64%] Building CXX object 
> gerbview/CMakeFiles/gerbview_kiface.dir/onrightclick.cpp.o
> [ 64%] Building CXX object 
> pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/pcb_calculator_frame.cpp.o
> [ 64%] Building CXX object 
> eeschema/CMakeFiles/eeschema_kiface.dir/dialogs/dialog_edit_one_field.cpp.o
> [ 64%] Building CXX object 
> pagelayout_editor/CMakeFiles/pl_editor_kiface.dir/__/common/dialogs/dialog_page_settings.cpp.o
> [ 64%] Building CXX object 
> pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/datafile_read_write.cpp.o
> [ 64%] Building CXX object 
> gerbview/CMakeFiles/gerbview_kiface.dir/printout_control.cpp.o
> [ 64%] Building CXX object 
> eeschema/CMakeFiles/eeschema_kiface.dir/dialogs/dialog_eeschema_config.cpp.o
> [ 64%] Linking CXX shared module _pl_editor.kiface
> [ 64%] Building CXX object 
> pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/regulators_funct.cpp.o
> [ 64%] Building CXX object 
> gerbview/CMakeFiles/gerbview_kiface.dir/readgerb.cpp.o
> [ 64%] Building CXX object 
> eeschema/CMakeFiles/eeschema_kiface.dir/dialogs/dialog_eeschema_config_fbp.cpp.o
> [ 64%] Built target pl_editor_kiface
> [ 65%] Building CXX object 
> gerbview/CMakeFiles/gerbview_kiface.dir/rs274_read_XY_and_IJ_coordinates.cpp.o
> [ 65%] Building CXX object 
> pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/tracks_width_versus_current.cpp.o
> [ 65%] Building CXX object 
> gerbview/CMakeFiles/gerbview_kiface.dir/rs274d.cpp.o
> [ 65%] Building CXX object 
> pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/transline_ident.cpp.o
> [ 65%] Building CXX object 
> eeschema/CMakeFiles/eeschema_kiface.dir/dialogs/dialog_eeschema_options_base.cpp.o
> Scanning dependencies of target kicad
> [ 65%] Building CXX object 
> kicad/CMakeFiles/kicad.dir/class_treeprojectfiles.cpp.o
> [ 65%] Building CXX object 
> pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/UnitSelector.cpp.o
> [ 65%] Building CXX object 
> gerbview/CMakeFiles/gerbview_kiface.dir/rs274x.cpp.o
> [ 65%] Building CXX object 
> pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/pcb_calculator_datafile_keywords.cpp.o
> [ 65%] Building CXX object 
> kicad/CMakeFiles/kicad.dir/class_treeproject_item.cpp.o
> [ 65%] Building CXX object 
> eeschema/CMakeFiles/eeschema_kiface.dir/dialogs/dialog_eeschema_options.cpp.o
> [ 65%] Building CXX object 
> gerbview/CMakeFiles/gerbview_kiface.dir/select_layers_to_pcb.cpp.o
> [ 65%] Building CXX object 
> pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/transline/transline.cpp.o
> [ 65%] Building CXX object kicad/CMakeFiles/kicad.dir/commandframe.cpp.o
> [ 66%] Building CXX object 
> pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/transline/c_microstrip.cpp.o
> [ 66%] Building CXX object 
> pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/transline/microstrip.cpp.o
> [ 66%] Building CXX object 
> pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/transline/coplanar.cpp.o
> [ 66%] Building CXX object 
> pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/transline/coax.cpp.o
> [ 66%] Building CXX object 
> pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/transline/rectwaveguide.cpp.o
> [ 66%] Building CXX object 
> pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/transline/stripline.cpp.o
> [ 66%] Building CXX object 
> pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/transline/twistedpair.cpp.o
> [ 66%] Building CXX object 
> pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/transline_dlg_funct.cpp.o
> [ 66%] Building CXX object 
> eeschema/CMakeFiles/eeschema_kiface.dir/dialogs/dialog_erc.cpp.o
> [ 66%] Building CXX object 
> kicad/CMakeFiles/kicad.dir/dialogs/dialog_template_selector_base.cpp.o
> [ 66%] Building CXX object 
> gerbview/CMakeFiles/gerbview_kiface.dir/toolbars_gerber.cpp.o
> [ 66%] Building CXX object 
> pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/attenuators/attenuator_classes.cpp.o
> [ 66%] Building CXX object 
> pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/dialogs/pcb_calculator_frame_base.cpp.o
> [ 66%] Building CXX object 
> kicad/CMakeFiles/kicad.dir/dialogs/dialog_template_selector.cpp.o
> [ 67%] Building CXX object 
> eeschema/CMakeFiles/eeschema_kiface.dir/dialogs/dialog_erc_base.cpp.o
> [ 67%] Building CXX object 
> gerbview/CMakeFiles/gerbview_kiface.di

Re: [Kicad-developers] Build failed in Jenkins: linux-kicad-full-gcc-head #1925

[Chris Pavlina]

Oh, sure. It just feels a bit non-kosher for a const method to modify a
non-const parent object, even though it's not really a constness violation.

On Mar 10, 2017 09:52, "Wayne Stambaugh"  wrote:

> Technically, the state of the library edit is not changed in any way.
> This function informs the schematic editor (if open) to refresh it's
> view which has always been broken.  Prior to this change, you had to
> perform some action to update edited symbols.  I'll drop the const in a
> couple of minutes.
>
> On 03/10/2017 09:40 AM, Chris Pavlina wrote:
> > Fix seems simple, just make LIB_EDIT_FRAME::refreshSchematic()
> > non-const. It probably shouldn't be const anyway since it edits state.
> > I'd do it myself but don't want to step on Wayne's toes.
> >
> > The addition of LIB_EDIT_FRAME::refreshSchematic() allows me to fix an
> > old bug finally too, so I have a fix waiting in my tree now for the
> > constness issue to be corrected :)
> >
> >
> > On Fri, Mar 10, 2017 at 03:16:54PM +0100, Miguel Angel Ajo wrote:
> >> See <http://ci.kicad-pcb.org/job/linux-kicad-full-gcc-head/
> 1925/display/redirect?page=changes>
> >>
> >> Changes:
> >>
> >> [Wayne Stambaugh] Fix broken symbol link in schematic after editing.
> >>
> >> --
> >> [...truncated 101.04 KB...]
> >> [ 64%] Building CXX object gerbview/CMakeFiles/gerbview_
> kiface.dir/onrightclick.cpp.o
> >> [ 64%] Building CXX object pcb_calculator/CMakeFiles/pcb_
> calculator_kiface.dir/pcb_calculator_frame.cpp.o
> >> [ 64%] Building CXX object eeschema/CMakeFiles/eeschema_
> kiface.dir/dialogs/dialog_edit_one_field.cpp.o
> >> [ 64%] Building CXX object pagelayout_editor/CMakeFiles/
> pl_editor_kiface.dir/__/common/dialogs/dialog_page_settings.cpp.o
> >> [ 64%] Building CXX object pcb_calculator/CMakeFiles/pcb_
> calculator_kiface.dir/datafile_read_write.cpp.o
> >> [ 64%] Building CXX object gerbview/CMakeFiles/gerbview_
> kiface.dir/printout_control.cpp.o
> >> [ 64%] Building CXX object eeschema/CMakeFiles/eeschema_
> kiface.dir/dialogs/dialog_eeschema_config.cpp.o
> >> [ 64%] Linking CXX shared module _pl_editor.kiface
> >> [ 64%] Building CXX object pcb_calculator/CMakeFiles/pcb_
> calculator_kiface.dir/regulators_funct.cpp.o
> >> [ 64%] Building CXX object gerbview/CMakeFiles/gerbview_
> kiface.dir/readgerb.cpp.o
> >> [ 64%] Building CXX object eeschema/CMakeFiles/eeschema_
> kiface.dir/dialogs/dialog_eeschema_config_fbp.cpp.o
> >> [ 64%] Built target pl_editor_kiface
> >> [ 65%] Building CXX object gerbview/CMakeFiles/gerbview_
> kiface.dir/rs274_read_XY_and_IJ_coordinates.cpp.o
> >> [ 65%] Building CXX object pcb_calculator/CMakeFiles/pcb_
> calculator_kiface.dir/tracks_width_versus_current.cpp.o
> >> [ 65%] Building CXX object gerbview/CMakeFiles/gerbview_
> kiface.dir/rs274d.cpp.o
> >> [ 65%] Building CXX object pcb_calculator/CMakeFiles/pcb_
> calculator_kiface.dir/transline_ident.cpp.o
> >> [ 65%] Building CXX object eeschema/CMakeFiles/eeschema_
> kiface.dir/dialogs/dialog_eeschema_options_base.cpp.o
> >> Scanning dependencies of target kicad
> >> [ 65%] Building CXX object kicad/CMakeFiles/kicad.dir/
> class_treeprojectfiles.cpp.o
> >> [ 65%] Building CXX object pcb_calculator/CMakeFiles/pcb_
> calculator_kiface.dir/UnitSelector.cpp.o
> >> [ 65%] Building CXX object gerbview/CMakeFiles/gerbview_
> kiface.dir/rs274x.cpp.o
> >> [ 65%] Building CXX object pcb_calculator/CMakeFiles/pcb_
> calculator_kiface.dir/pcb_calculator_datafile_keywords.cpp.o
> >> [ 65%] Building CXX object kicad/CMakeFiles/kicad.dir/
> class_treeproject_item.cpp.o
> >> [ 65%] Building CXX object eeschema/CMakeFiles/eeschema_
> kiface.dir/dialogs/dialog_eeschema_options.cpp.o
> >> [ 65%] Building CXX object gerbview/CMakeFiles/gerbview_
> kiface.dir/select_layers_to_pcb.cpp.o
> >> [ 65%] Building CXX object pcb_calculator/CMakeFiles/pcb_
> calculator_kiface.dir/transline/transline.cpp.o
> >> [ 65%] Building CXX object kicad/CMakeFiles/kicad.dir/
> commandframe.cpp.o
> >> [ 66%] Building CXX object pcb_calculator/CMakeFiles/pcb_
> calculator_kiface.dir/transline/c_microstrip.cpp.o
> >> [ 66%] Building CXX object pcb_calculator/CMakeFiles/pcb_
> calculator_kiface.dir/transline/microstrip.cpp.o
> >> [ 66%] Building CXX object pcb_calculator/CMakeFiles/pcb_
> calculator_kiface.dir/transline/coplanar.cpp.o
> >> [ 66%] Building CXX object pcb_calculator/CMakeFiles/pcb_
> calculator_ki

Re: [Kicad-developers] [PATCH] Show the busy cursor while loading libraries

[Chris Pavlina]

Definitely faster - tolerably so, I'd say, maybe 1.5 seconds or so to
load all the libraries in my largest projects.

Not faster than stable though :(

Thank you.

On Fri, Mar 10, 2017 at 09:31:08PM +0100, jp charras wrote:
> Le 09/03/2017 à 21:11, Chris Pavlina a écrit :
> > On Thu, Mar 09, 2017 at 09:01:44PM +0100, jp charras wrote:
> >> Le 09/03/2017 à 20:31, Chris Pavlina a écrit :
> >>> It's faster for me now - about five seconds to load an empty schematic
> >>> project with all the official libs, which is bearable, and about the
> >>> same time to load a large multipage schematic with a smaller library
> >>> set.
> >>>
> >>> Can we declare a verdict on whether the busy cursor is welcome still? I
> >>> feel like five seconds is still long enough to warrant one.
> 
> Should be faster now (commit de30dc9f5df92d6d7ce3743883551f64aecc989e
> speed up libraries loading).
> 
> Due to a few optimizations, large multipage schematics loading should be now 
> perhaps faster than
> stable release.
> 
> I am not sure the busy cursor is now still needed.
> 
> 
> -- 
> 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] Footprint features - stable vs nightly

[Chris Pavlina]

This doesn't directly address your question - but couldn't the automated
library checker actually load the footprints into KiCad, via the Python
API, to truly verify that they parse in KiCad proper?

On Sat, Mar 11, 2017 at 10:39:37AM +1100, Oliver Walters wrote:
> Hi all,
> 
> Can someone tell me a complete list of the differences between footprint
> "features" in nightly and stable? There is a recent issue where someone
> added a footprint using roundrect pads and broke a library for someone
> using stable.
> 
> I can easily add a search for "roundrect" to the automated library checker
> but what else should I be looking for?
> 
> As an aside, I think it would be **very** helpful if the footprint library
> loader was able to skip over "bad" footprints and continue to load.
> Currently a single bad footprint prevents any subsequent footprints from
> loading. If we had the ability to skip bad ones, then we could add "future"
> footprints and these would simply be ignored by stable version.
> 
> 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

[Kicad-developers] VTBL_ENTRY

[Chris Pavlina]

Does anyone know why we have "#define VTBL_ENTRY virtual" in kiway.h and
then use that in several kiway-related places? Would anyone object to
just using "virtual"?

-- 
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

[Kicad-developers] [PATCH] Refactor: split footprint filter data model out of cvpcb

[Chris Pavlina]

Hi,

The attached patch pulls the footprint filtering logic out of cvpcb's
GUI code. It adds a FOOTPRINT_FILTER class in common/ that provides an
iterable filtered view onto a collection of footprints. This refactor is
necessary to enable footprint selection within eeschema.

-- 
Chris
>From 76a8578dc2b4b0fae3f5243e40f262f0ddfc5ef2 Mon Sep 17 00:00:00 2001
From: Chris Pavlina 
Date: Sat, 11 Mar 2017 12:28:51 -0500
Subject: [PATCH] Refactor: split footprint filter data model out of cvpcb

---
 common/CMakeLists.txt  |   1 +
 common/footprint_filter.cpp| 162 +
 cvpcb/class_footprints_listbox.cpp |  59 ++
 cvpcb/cvpcb_mainframe.cpp  |  34 
 cvpcb/listview_classes.h   |  13 +--
 include/footprint_filter.h | 118 +++
 include/footprint_info.h   |   3 +-
 7 files changed, 310 insertions(+), 80 deletions(-)
 create mode 100644 common/footprint_filter.cpp
 create mode 100644 include/footprint_filter.h

diff --git a/common/CMakeLists.txt b/common/CMakeLists.txt
index b0b3b66ff..d7f38222e 100644
--- a/common/CMakeLists.txt
+++ b/common/CMakeLists.txt
@@ -344,6 +344,7 @@ set( PCB_COMMON_SRCS
 class_page_info.cpp
 lset.cpp
 footprint_info.cpp
+footprint_filter.cpp
 ../pcbnew/basepcbframe.cpp
 ../pcbnew/class_board.cpp
 ../pcbnew/class_board_connected_item.cpp
diff --git a/common/footprint_filter.cpp b/common/footprint_filter.cpp
new file mode 100644
index 0..9ea19d0e3
--- /dev/null
+++ b/common/footprint_filter.cpp
@@ -0,0 +1,162 @@
+/*
+ * This program source code file is part of KiCad, a free EDA CAD application.
+ *
+ * Copyright (C) 2017 Chris Pavlina 
+ * Copyright (C) 2016 Jean-Pierre Charras, jp.charras at wanadoo.fr
+ * Copyright (C) 1992-2017 KiCad Developers, see AUTHORS.txt for contributors.
+ *
+ * This program is free software: you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation, either version 3 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, see <http://www.gnu.org/licenses/>.
+ */
+
+#include 
+#include 
+#include 
+
+using FOOTPRINT_FILTER_IT = FOOTPRINT_FILTER::ITERATOR;
+
+
+FOOTPRINT_FILTER::ITERATOR::ITERATOR():
+m_pos( 0 ),
+m_filter( nullptr )
+{}
+
+
+FOOTPRINT_FILTER::ITERATOR::ITERATOR( FOOTPRINT_FILTER_IT const& aOther ):
+m_pos( aOther.m_pos ),
+m_filter( aOther.m_filter )
+{}
+
+
+FOOTPRINT_FILTER::ITERATOR::ITERATOR( FOOTPRINT_FILTER& aFilter ):
+m_pos( (size_t) -1 ),
+m_filter( &aFilter )
+{
+increment();
+}
+
+
+FOOTPRINT_FILTER::FOOTPRINT_FILTER(
+FOOTPRINT_LIST& aList,
+const wxString& aLibName, COMPONENT* aComponent, const wxString& aPattern,
+int aFilterType ):
+m_list( &aList ),
+m_lib_name( aLibName ),
+m_filter_pattern( aPattern ),
+m_component( aComponent ),
+m_filter_type( aFilterType )
+{
+m_filter.SetPattern( aPattern.Lower() );
+}
+
+
+void FOOTPRINT_FILTER_IT::increment()
+{
+bool found = false;
+
+if( !m_filter || !m_filter->m_list || m_filter->m_list->GetCount() == 0 )
+{
+m_pos = 0;
+return;
+}
+
+auto filter_type= m_filter->m_filter_type;
+auto list   = m_filter->m_list;
+auto& lib_name  = m_filter->m_lib_name;
+auto& filter_pattern= m_filter->m_filter_pattern;
+auto component  = m_filter->m_component;
+auto &filter= m_filter->m_filter;
+
+for( ++m_pos; m_pos < list->GetCount() && !found; ++m_pos )
+{
+found = true;
+
+if( ( filter_type & FOOTPRINT_FILTER::FILTERING_BY_LIBRARY ) &&
+!lib_name.IsEmpty() &&
+!list->GetItem( m_pos ).InLibrary( lib_name ) )
+found = false;
+
+if( ( filter_type & FOOTPRINT_FILTER::FILTERING_BY_COMPONENT_KEYWORD ) &&
+component &&
+!component->MatchesFootprintFilters(
+list->GetItem( m_pos ).GetNickname(),
+list->GetItem( m_pos ).GetFootprintName() ) )
+found = false;
+
+if( ( filter_type & FOOTPRINT_FILTER::FILTERING_BY_PIN_COUNT ) &&
+component &&
+component->GetNetCount() != list->GetItem( m_pos ).GetUniquePadCount() )
+found = false;
+
+if( ( f

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

[Chris Pavlina]

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

Re: [Kicad-developers] Layer ID enums

[Chris Pavlina]

It would be very nice if we could have a totally standalone (in terms of
constants used, etc) legacy loader that translates everything to the
constants used in the new code, so we didn't always have to tread so
carefully...

On Sun, Mar 12, 2017 at 02:06:01PM -0400, 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

[Kicad-developers] [PATCH] Add clang-format configuration

[Chris Pavlina]

Hi,

Currently, our preferred code formatting tool is Uncrustify. Uncrustify
is bad. It does things like this:

wxString m_choiceAntialiasingChoices[] =
{
_( "No Antialiasing" ),
_( "Subpixel Antialiasing (High Quality)" ),  _(
"Subpixel Antialiasing (Ultra Quality)" ),_( "Supersampling 
(2x)" ), _(
"Supersampling (4x)" )
};

Yes, that's an actual Uncrustify output with our configuration, posted
on IRC this morning.

Per metacollin's suggestion I looked into clang-format, which does a
MUCH nicer job because it uses clang's parser to actually understand the
code it's formatting. I wrote up a clang-format config following the
KiCad coding style. Here is the output of clang-format on the same code:

wxString m_choiceAntialiasingChoices[] = { _( "No Antialiasing" ),
_( "Subpixel Antialiasing (High Quality)" ),
_( "Subpixel Antialiasing (Ultra Quality)" ),
_( "Supersampling (2x)" ),
_( "Supersampling (4x)" ) };

It's not perfect, but it's way better than Uncrustify.

The attached patch adds a _clang-format configuration file to the root
of the repository.

-- 
Chris
>From bd6355238dc9fd2c1c193f082ca1dbd2fb875bb7 Mon Sep 17 00:00:00 2001
From: Chris Pavlina 
Date: Mon, 13 Mar 2017 09:28:22 -0400
Subject: [PATCH] Add clang-format configuration

---
 _clang-format | 53 +
 1 file changed, 53 insertions(+)
 create mode 100644 _clang-format

diff --git a/_clang-format b/_clang-format
new file mode 100644
index 0..6e890e478
--- /dev/null
+++ b/_clang-format
@@ -0,0 +1,53 @@
+BasedOnStyle: LLVM
+AccessModifierOffset: -4
+AlignAfterOpenBracket: DontAlign
+AlignConsecutiveDeclarations: true
+AlignEscapedNewlinesLeft: true
+AlignOperands: true
+AlignTrailingComments: true
+AllowAllParametersOfDeclarationOnNextLine: true
+AllowShortBlocksOnASingleLine: false
+AllowShortCaseLabelsOnASingleLine: true
+AllowShortFunctionsOnASingleLine: false
+AllowShortIfStatementsOnASingleLine: false
+AllowShortLoopsOnASingleLine: false
+AlwaysBreakAfterReturnType: None
+AlwaysBreakBeforeMultilineStrings: true
+AlwaysBreakTemplateDeclarations: false
+BinPackArguments: false
+BinPackParameters: true
+BreakBeforeBinaryOperators: NonAssignment
+BreakBeforeBraces: Allman
+BreakBeforeTernaryOperators: false
+BreakConstructorInitializersBeforeComma: false
+BreakStringLiterals: false
+ColumnLimit: 100
+ConstructorInitializerAllOnOneLineOrOnePerLine: true
+ConstructorInitializerIndentWidth: 8
+ContinuationIndentWidth: 4
+Cpp11BracedListStyle: false
+DerivePointerAlignment: false
+DisableFormat: false
+ForEachMacros: [ BOOST_FOREACH ]
+IndentCaseLabels: false
+IndentWidth: 4
+IndentWrappedFunctionNames: false
+KeepEmptyLinesAtTheStartOfBlocks: true
+Language: Cpp
+MaxEmptyLinesToKeep: 2
+NamespaceIndentation: Inner
+PointerAlignment: Left
+ReflowComments: false
+SortIncludes: true
+SpaceAfterCStyleCast: true
+SpaceBeforeAssignmentOperators: true
+SpaceBeforeParens: Never
+SpaceInEmptyParentheses: false
+SpacesBeforeTrailingComments: 1
+SpacesInAngles: false
+SpacesInCStyleCastParentheses: false
+SpacesInParentheses: true
+SpacesInSquareBrackets: false
+Standard: Cpp11
+TabWidth: 4
+UseTab: Never
-- 
2.12.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

Re: [Kicad-developers] [PATCH] Refactor: split footprint filter data model out of cvpcb

[Chris Pavlina]

I'm trying not to merge my own patches without review unless they
directly fix up areas I've already been working on, and I haven't yet
pushed any code for footprint selection so I can't say I've been working
on it yet ;)


On Mon, Mar 13, 2017 at 09:24:29AM -0400, Wayne Stambaugh wrote:
> Chris,
> 
> I'm assuming you're asking for comment on this since you posted it as a
> patch.  It makes sense to me to factor this out if you need to use in
> the symbol selection dialog.
> 
> Cheers,
> 
> Wayne
> 
> On 3/11/2017 12:31 PM, Chris Pavlina wrote:
> > Hi,
> > 
> > The attached patch pulls the footprint filtering logic out of cvpcb's
> > GUI code. It adds a FOOTPRINT_FILTER class in common/ that provides an
> > iterable filtered view onto a collection of footprints. This refactor is
> > necessary to enable footprint selection within eeschema.
> > 
> > 
> > 
> > ___
> > 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] FreeBSD

[Chris Pavlina]

Hi,

Would there be serious objection to merging a very minor patch to make
KiCad build properly on FreeBSD? This isn't anything big, it's basically
just adding __FreeBSD__ to the list of defines to test for alongside
__linux__ in a couple places:

https://forum.kicad.info/t/boost-lib-problem-on-64-bit-machines-linux/5619/10

I'm not suggesting any official support for FreeBSD, just making a minor
change to avoid losing the ability to build on something we apparently
could build on before.

-- 
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

Re: [Kicad-developers] FreeBSD

[Chris Pavlina]

Isn't this the same as what I linked to?

On Mon, Mar 13, 2017 at 10:11:54PM +0100, Michael wrote:
> Hi,
> currently I'm using the following patch for the FreeBSD Port.
> (I'm not entirely shure if clang sets __x86_64__ too or only __amd64__)
> 
> --- include/system/libcontext.h.orig 2017-03-13 11:47:23.495919000 +0100
> +++ include/system/libcontext.h 2017-03-13 11:51:12.678651000 +0100
> @@ -23,13 +23,15 @@
> 
> -#if defined(__GNUC__) || defined(__APPLE__)
> +#if defined(__GNUC__) || defined(__APPLE__) || defined(__FreeBSD__)
> 
>  #define LIBCONTEXT_COMPILER_gcc
> 
> - #if defined(__linux__)
> + #if defined(__linux__) || defined(__FreeBSD__)
> #ifdef __x86_64__
> #define LIBCONTEXT_PLATFORM_linux_x86_64
> #define LIBCONTEXT_CALL_CONVENTION
> -
> + #elif __amd64__
> + #define LIBCONTEXT_PLATFORM_linux_x86_64
> + #define LIBCONTEXT_CALL_CONVENTION
> #elif __i386__
> #define LIBCONTEXT_PLATFORM_linux_i386
> 
> 
> Am 13. März 2017 21:53:17 MEZ schrieb Tomasz Wlostowski 
> :
> >On 13.03.2017 18:56, Wayne Stambaugh wrote:
> >> Is this Tom's context library code?  If so, Tom would you please
> >comment
> >> on the patch.  I'm OK with assuming it doesn't break anything.
> >> 
> >Hi Wayne,
> >
> >It's OK. I'll merge it soon.
> >
> >Cheers,
> >Tom
> >> On 3/13/2017 1:50 PM, Chris Pavlina wrote:
> >>> Hi,
> >>>
> >>> Would there be serious objection to merging a very minor patch to
> >make
> >>> KiCad build properly on FreeBSD? This isn't anything big, it's
> >basically
> >>> just adding __FreeBSD__ to the list of defines to test for alongside
> >>> __linux__ in a couple places:
> >>>
> >>>
> >https://forum.kicad.info/t/boost-lib-problem-on-64-bit-machines-linux/5619/10
> >>>
> >>> I'm not suggesting any official support for FreeBSD, just making a
> >minor
> >>> change to avoid losing the ability to build on something we
> >apparently
> >>> could build on before.
> >>>
> >> 
> >> ___
> >> 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
> 
> greetings
> -- 
> Mike


___
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] Footprint filter match behavior

[Chris Pavlina]

Hi,

Currently, the footprint filter strings in a component match a footprint
if they occur *anywhere* in the footprint's name. This leads to some
possibly unintentional matches - for example, "R" has a filter "R_*",
which matches literally every footprint with R_ somewhere in its name.
This is quite a lot of footprints that are NOT resistors.

What if I changed this to require matching at the beginning of the
string? A filter meant to match anywhere in the string could be written
"*R_*" instead. This should significantly reduce the number of false
positive matches.

-- 
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

Re: [Kicad-developers] Footprint filter match behavior

[Chris Pavlina]

On Tue, Mar 14, 2017 at 05:24:07PM +0100, Simon Richter wrote:
> Hi,
> 
> On 14.03.2017 16:57, Chris Pavlina wrote:
> 
> > What if I changed this to require matching at the beginning of the
> > string? A filter meant to match anywhere in the string could be written
> > "*R_*" instead. This should significantly reduce the number of false
> > positive matches.
> 
> The regex matcher should give you good results for "^R".

I think people would be opposed to using regexes in the footprint
filters. I like having them in some places as an option, but they're
complicated for people who aren't programmers, and I don't want to use
the combined matcher for footprint filters because I'd like to reduce
false positives here (as a long match list is unwieldy).

> 
>Simon
> 




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

Re: [Kicad-developers] Footprint filter match behavior

[Chris Pavlina]

Agreed, they do look like standard globbing patterns and should probably
behave that way. In fact globs have to line up at _both_ ends... but I
think a lot of people set the filters assuming left-aligned matching, so
I don't think I want to go that far.

On Wed, Mar 15, 2017 at 12:16:20AM +0800, John Beard wrote:
> HI Chris,
> 
> That sounds reasonable. A match pattern like "R_*" looks like a
> globbing pattern, and I'd expect globbing patterns to act like that in
> general. It's how most bash works, for a start, as well as things like
> find(1).
> 
> I imagine that most footprints with a pattern like "R_*" intended it
> to be match-at-front anyway.
> 
> Cheers,
> 
> John
> 
> On Tue, Mar 14, 2017 at 11:57 PM, Chris Pavlina  
> wrote:
> > Hi,
> >
> > Currently, the footprint filter strings in a component match a footprint
> > if they occur *anywhere* in the footprint's name. This leads to some
> > possibly unintentional matches - for example, "R" has a filter "R_*",
> > which matches literally every footprint with R_ somewhere in its name.
> > This is quite a lot of footprints that are NOT resistors.
> >
> > What if I changed this to require matching at the beginning of the
> > string? A filter meant to match anywhere in the string could be written
> > "*R_*" instead. This should significantly reduce the number of false
> > positive matches.
> >
> > --
> > 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] Footprint filter match behavior

[Chris Pavlina]

On Tue, Mar 14, 2017 at 05:49:28PM +0100, Simon Richter wrote:
> Hi,
> 
> On 14.03.2017 17:30, Chris Pavlina wrote:
> 
> >> The regex matcher should give you good results for "^R".
> 
> > I think people would be opposed to using regexes in the footprint
> > filters. I like having them in some places as an option, but they're
> > complicated for people who aren't programmers, and I don't want to use
> > the combined matcher for footprint filters because I'd like to reduce
> > false positives here (as a long match list is unwieldy).
> 
> Ideally we'd have the same search behaviour in all search boxes,
> although I see that part selection is different from footprint selection
> because the use case "same part number, different vendor prefix" doesn't
> come up. Same behaviour is less surprising though.

To be fair...the footprint filter list isn't really a search box.

> 
> We could give priority to results anchored on the left side, as well as
> based on the left of the match in any case.

This does work. In fact the component selector already does this -
earlier matches score higher, and matches are sorted by score.

Maybe I'll try that out and see how it works for footprints.

> 
>Simon
> 



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

Re: [Kicad-developers] Differential pair skew matching fails with certain dimensions

[Chris Pavlina]

I can repro this as well. Latest master, also Linux.

On Tue, Mar 14, 2017 at 11:20:52AM -0700, Andrew Zonenberg wrote:
> This one is probably for Orson or Tom...
> 
> 
> Tested with latest code from git (on Debian Jessie), but I also had the
> issue with my old version (a few weeks old, forgot to write down the
> exact hash).
> 
> Steps to reproduce:
> * Create schematic that has a differential pair in it
> * Set differential pair design rules to 0.21mm trace, 0.15mm space
> * Route differential pair in such a way that there's skew between the halves
> * Try to skew-match
> 
> Expected result: overlay appears, says "too short", mouse motion adds
> meanders
> 
> Actual result: Overlay appears, says "too short", no meanders are created
> 
> I've had the issue with other dimensions as well, it appears that having
> trace width greater than space is necessary but not sufficient to cause
> the problem.
> 




___
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 to compile _pcbnew.kiface only once

[Chris Pavlina]

I'm of two minds on this. On one hand, I'd like to disable scripting on
the macOS nightlies until it's fixed, so macOS users still *have*
nightlies. On the other hand, I worry that doing so will remove
motivation to actually fix it.

Is anyone actually _actively working on a fix_? I keep seeing chatter
about this, but no actual attempts to fix it.

Honestly I think the patch that broke the build should be reverted until
a fix can be prepared, but considering who submitted it, I doubt I'll
have any say there.


On Thu, Mar 16, 2017 at 04:56:14PM -0400, Jean-Paul Louis wrote:
> I agree 150% with Bernhard.
> 
> A disabled Python is 150% better than no new build at all.
> 
> I do not understand why OS X users are considered second class citizens.
> 
> Just my $0.02,
> Jean-Paul
> N1JPL
> 
> 
> 
> > On Mar 16, 2017, at 2:06 PM, Bernhard Stegmaier  
> > wrote:
> > 
> > I have just seen people on the forum complaining that OSX nightlies still 
> > don’t build.
> > 
> > @Simon:
> > Do you intend to push your changes, no matter how hackish? 
> > Might at least be a start to work with.
> > 
> > Or, just disable python scripting at all until the whole python bundling 
> > has been sorted out?
> > Having no python scripting is better than having no build or a build where 
> > it doesn’t work right...
> > 
> > 
> > Regards,
> > Bernhard
> > 
> >> On 21 Feb 2017, at 18:56, Simon Wells  wrote:
> >> 
> >> I have previously sent a patch to adam for testing that bundled
> >> python. but it was a bit hackish as since python is a system lib
> >> bundleutilies doesn't copy it.
> >> 
> >> On 21 February 2017 at 21:28, Bernhard Stegmaier
> >>  wrote:
> >>> 
> >>> On 21 Feb 2017, at 00:31, Wayne Stambaugh  wrote:
> >>> 
> >>> On 2/20/2017 6:27 PM, Nick Østergaard wrote:
> >>> 
> >>> 2017-02-20 23:48 GMT+01:00 Bernhard Stegmaier :
> >>> 
> >>> How is this done on Windows?
> >>> You also don’t have a global filesystem with one Python there where you 
> >>> just
> >>> copy it into the right place… where does the Windows installer put those
> >>> files and how do you use them from some installed Python? Are there issues
> >>> with library paths of the library dependencies that come with KiCAD when
> >>> used from an external Python?
> >>> 
> >>> 
> >>> I am not aware of any issues with it on windows, but I don't really use
> >>> windows.
> >>> 
> >>> People have requested to include pip with the windows install, and
> >>> that is done now, so I assume that at least something works.
> >>> 
> >>> I am not sure if the user uses the shell inside pcbnew or calls the
> >>> python bundled with the installer. The file system layout is basically
> >>> as on linux, just inside the install destination folder.
> >>> 
> >>> 
> >>> Would something like this work on osx rather than trying to fit into an
> >>> existing python install?  It might prove to be more reliable.  At least
> >>> you would always have a known python build.
> >>> 
> >>> 
> >>> Yes, that’s probably the only way to do it in a safe way for the bundle
> >>> (and, as Adam said how Apple requires it).
> >>> Currently only wxPython packages and the pcbnew .so are copied into the
> >>> bundle.
> >>> There is no (matching) python installation contained/copied.
> >>> 
> >>> This seems to be sufficient to at least run the python console from inside
> >>> pcbnew with some external python installation - if the python version used
> >>> to build the bundle and the one on the target system are compatible.
> >>> However, the last time I tried it the python console was really unusable 
> >>> for
> >>> me, because you couldn’t even type some keys (menu hotkeys always trigger
> >>> the menu action).
> >>> Don’t know if that has been fixed meanwhile.
> >>> 
> >>> So, I think this whole python stuff needs a big overhaul on macOS for both
> >>> types of scripting.
> >>> I will work on it when I have some spare time.
> >>> If someone else is going to work on that please drop me a note, so that we
> >>> don’t do it twice…
> >>> 
> >>> 
> >>> Regards,
> >>> Bernhard
> >>> 
> >>> 
> >>> 
> >>> ___
> >>> 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://launchp

Re: [Kicad-developers] Patch to compile _pcbnew.kiface only once

[Chris Pavlina]

On Fri, Mar 17, 2017 at 08:08:28AM -0400, Wayne Stambaugh wrote:
> Would someone please disable python scripting on OSX builds so we can
> provide nightly builds until we can find a solution for the python issue.
> 
> On 3/16/2017 4:56 PM, Jean-Paul Louis wrote:
> > I agree 150% with Bernhard.
> > 
> > A disabled Python is 150% better than no new build at all.
> > 
> > I do not understand why OS X users are considered second class citizens.
> 
> I'm sorry you feel this way but this has nothing to do with OSX being
> second class and every thing to do with the simple fact that there are
> far more windows and linux devs so things tend to get fixed faster on
> those platforms.

In his defense, that's kinda the definition of a second class citizen.
Not that it's our _fault_, we don't have many developers for macOS. But
that doesn't make it not true. :\

Wayne, would you be okay with disabling scripting on the macOS builds
until scripting is fixed for them?

> Your comments doe nothing to encourage the few OSX
> devs that we do have.  Perhaps a better way to motivate them would be to
> thank them for their efforts.
> 
> > 
> > Just my $0.02,
> > Jean-Paul
> > N1JPL
> > 
> > 
> > 
> >> On Mar 16, 2017, at 2:06 PM, Bernhard Stegmaier  
> >> wrote:
> >>
> >> I have just seen people on the forum complaining that OSX nightlies still 
> >> don’t build.
> >>
> >> @Simon:
> >> Do you intend to push your changes, no matter how hackish? 
> >> Might at least be a start to work with.
> >>
> >> Or, just disable python scripting at all until the whole python bundling 
> >> has been sorted out?
> >> Having no python scripting is better than having no build or a build where 
> >> it doesn’t work right...
> >>
> >>
> >> Regards,
> >> Bernhard
> >>
> >>> On 21 Feb 2017, at 18:56, Simon Wells  wrote:
> >>>
> >>> I have previously sent a patch to adam for testing that bundled
> >>> python. but it was a bit hackish as since python is a system lib
> >>> bundleutilies doesn't copy it.
> >>>
> >>> On 21 February 2017 at 21:28, Bernhard Stegmaier
> >>>  wrote:
> 
>  On 21 Feb 2017, at 00:31, Wayne Stambaugh  wrote:
> 
>  On 2/20/2017 6:27 PM, Nick Østergaard wrote:
> 
>  2017-02-20 23:48 GMT+01:00 Bernhard Stegmaier :
> 
>  How is this done on Windows?
>  You also don’t have a global filesystem with one Python there where you 
>  just
>  copy it into the right place… where does the Windows installer put those
>  files and how do you use them from some installed Python? Are there 
>  issues
>  with library paths of the library dependencies that come with KiCAD when
>  used from an external Python?
> 
> 
>  I am not aware of any issues with it on windows, but I don't really use
>  windows.
> 
>  People have requested to include pip with the windows install, and
>  that is done now, so I assume that at least something works.
> 
>  I am not sure if the user uses the shell inside pcbnew or calls the
>  python bundled with the installer. The file system layout is basically
>  as on linux, just inside the install destination folder.
> 
> 
>  Would something like this work on osx rather than trying to fit into an
>  existing python install?  It might prove to be more reliable.  At least
>  you would always have a known python build.
> 
> 
>  Yes, that’s probably the only way to do it in a safe way for the bundle
>  (and, as Adam said how Apple requires it).
>  Currently only wxPython packages and the pcbnew .so are copied into the
>  bundle.
>  There is no (matching) python installation contained/copied.
> 
>  This seems to be sufficient to at least run the python console from 
>  inside
>  pcbnew with some external python installation - if the python version 
>  used
>  to build the bundle and the one on the target system are compatible.
>  However, the last time I tried it the python console was really unusable 
>  for
>  me, because you couldn’t even type some keys (menu hotkeys always trigger
>  the menu action).
>  Don’t know if that has been fixed meanwhile.
> 
>  So, I think this whole python stuff needs a big overhaul on macOS for 
>  both
>  types of scripting.
>  I will work on it when I have some spare time.
>  If someone else is going to work on that please drop me a note, so that 
>  we
>  don’t do it twice…
> 
> 
>  Regards,
>  Bernhard
> 
> 
> 
>  ___
>  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 : 

Re: [Kicad-developers] Patch to compile _pcbnew.kiface only once

[Chris Pavlina]

On Fri, Mar 17, 2017 at 09:56:14AM -0400, Chris Pavlina wrote:
> On Fri, Mar 17, 2017 at 08:08:28AM -0400, Wayne Stambaugh wrote:
> > Would someone please disable python scripting on OSX builds so we can
> > provide nightly builds until we can find a solution for the python issue.
> > 
> > On 3/16/2017 4:56 PM, Jean-Paul Louis wrote:
> > > I agree 150% with Bernhard.
> > > 
> > > A disabled Python is 150% better than no new build at all.
> > > 
> > > I do not understand why OS X users are considered second class citizens.
> > 
> > I'm sorry you feel this way but this has nothing to do with OSX being
> > second class and every thing to do with the simple fact that there are
> > far more windows and linux devs so things tend to get fixed faster on
> > those platforms.
> 
> In his defense, that's kinda the definition of a second class citizen.
> Not that it's our _fault_, we don't have many developers for macOS. But
> that doesn't make it not true. :\
> 
> Wayne, would you be okay with disabling scripting on the macOS builds
> until scripting is fixed for them?

...and I hear you've already addressed that. Never mind :)

> 
> > Your comments doe nothing to encourage the few OSX
> > devs that we do have.  Perhaps a better way to motivate them would be to
> > thank them for their efforts.
> > 
> > > 
> > > Just my $0.02,
> > > Jean-Paul
> > > N1JPL
> > > 
> > > 
> > > 
> > >> On Mar 16, 2017, at 2:06 PM, Bernhard Stegmaier 
> > >>  wrote:
> > >>
> > >> I have just seen people on the forum complaining that OSX nightlies 
> > >> still don’t build.
> > >>
> > >> @Simon:
> > >> Do you intend to push your changes, no matter how hackish? 
> > >> Might at least be a start to work with.
> > >>
> > >> Or, just disable python scripting at all until the whole python bundling 
> > >> has been sorted out?
> > >> Having no python scripting is better than having no build or a build 
> > >> where it doesn’t work right...
> > >>
> > >>
> > >> Regards,
> > >> Bernhard
> > >>
> > >>> On 21 Feb 2017, at 18:56, Simon Wells  wrote:
> > >>>
> > >>> I have previously sent a patch to adam for testing that bundled
> > >>> python. but it was a bit hackish as since python is a system lib
> > >>> bundleutilies doesn't copy it.
> > >>>
> > >>> On 21 February 2017 at 21:28, Bernhard Stegmaier
> > >>>  wrote:
> > >>>>
> > >>>> On 21 Feb 2017, at 00:31, Wayne Stambaugh  wrote:
> > >>>>
> > >>>> On 2/20/2017 6:27 PM, Nick Østergaard wrote:
> > >>>>
> > >>>> 2017-02-20 23:48 GMT+01:00 Bernhard Stegmaier 
> > >>>> :
> > >>>>
> > >>>> How is this done on Windows?
> > >>>> You also don’t have a global filesystem with one Python there where 
> > >>>> you just
> > >>>> copy it into the right place… where does the Windows installer put 
> > >>>> those
> > >>>> files and how do you use them from some installed Python? Are there 
> > >>>> issues
> > >>>> with library paths of the library dependencies that come with KiCAD 
> > >>>> when
> > >>>> used from an external Python?
> > >>>>
> > >>>>
> > >>>> I am not aware of any issues with it on windows, but I don't really use
> > >>>> windows.
> > >>>>
> > >>>> People have requested to include pip with the windows install, and
> > >>>> that is done now, so I assume that at least something works.
> > >>>>
> > >>>> I am not sure if the user uses the shell inside pcbnew or calls the
> > >>>> python bundled with the installer. The file system layout is basically
> > >>>> as on linux, just inside the install destination folder.
> > >>>>
> > >>>>
> > >>>> Would something like this work on osx rather than trying to fit into an
> > >>>> existing python install?  It might prove to be more reliable.  At least
> > >>>> you would always have a known python build.
> > >

Re: [Kicad-developers] Patch to compile _pcbnew.kiface only once

[Chris Pavlina]

On Fri, Mar 17, 2017 at 10:01:20AM -0400, Wayne Stambaugh wrote:
> On 3/17/2017 9:56 AM, Chris Pavlina wrote:
> > On Fri, Mar 17, 2017 at 08:08:28AM -0400, Wayne Stambaugh wrote:
> >> Would someone please disable python scripting on OSX builds so we can
> >> provide nightly builds until we can find a solution for the python issue.
> >>
> >> On 3/16/2017 4:56 PM, Jean-Paul Louis wrote:
> >>> I agree 150% with Bernhard.
> >>>
> >>> A disabled Python is 150% better than no new build at all.
> >>>
> >>> I do not understand why OS X users are considered second class citizens.
> >>
> >> I'm sorry you feel this way but this has nothing to do with OSX being
> >> second class and every thing to do with the simple fact that there are
> >> far more windows and linux devs so things tend to get fixed faster on
> >> those platforms.
> > 
> > In his defense, that's kinda the definition of a second class citizen.
> > Not that it's our _fault_, we don't have many developers for macOS. But
> > that doesn't make it not true. :\
> 
> I wish I had a better answer to this issue but I don't.

Same here. In fact I have the hardware/software resources to do macOS
development but not the time. Hell, my own *main* kicad work has been
delayed for weeks, and it'd take me ages just to get to the bottom of
what's going on here and understand it all, let alone find a fix :(

> 
> > 
> > Wayne, would you be okay with disabling scripting on the macOS builds
> > until scripting is fixed for them?
> 
> I replied to an email earlier to request that we disable python
> scripting on osx until the python build issues are a resolved.  Did it
> not make it through?

Nah, there's just been enough discussion on this issue that I've managed
to miss and/or forget some.

> 
> > 
> >> Your comments doe nothing to encourage the few OSX
> >> devs that we do have.  Perhaps a better way to motivate them would be to
> >> thank them for their efforts.
> >>
> >>>
> >>> Just my $0.02,
> >>> Jean-Paul
> >>> N1JPL
> >>>
> >>>
> >>>
> >>>> On Mar 16, 2017, at 2:06 PM, Bernhard Stegmaier 
> >>>>  wrote:
> >>>>
> >>>> I have just seen people on the forum complaining that OSX nightlies 
> >>>> still don’t build.
> >>>>
> >>>> @Simon:
> >>>> Do you intend to push your changes, no matter how hackish? 
> >>>> Might at least be a start to work with.
> >>>>
> >>>> Or, just disable python scripting at all until the whole python bundling 
> >>>> has been sorted out?
> >>>> Having no python scripting is better than having no build or a build 
> >>>> where it doesn’t work right...
> >>>>
> >>>>
> >>>> Regards,
> >>>> Bernhard
> >>>>
> >>>>> On 21 Feb 2017, at 18:56, Simon Wells  wrote:
> >>>>>
> >>>>> I have previously sent a patch to adam for testing that bundled
> >>>>> python. but it was a bit hackish as since python is a system lib
> >>>>> bundleutilies doesn't copy it.
> >>>>>
> >>>>> On 21 February 2017 at 21:28, Bernhard Stegmaier
> >>>>>  wrote:
> >>>>>>
> >>>>>> On 21 Feb 2017, at 00:31, Wayne Stambaugh  wrote:
> >>>>>>
> >>>>>> On 2/20/2017 6:27 PM, Nick Østergaard wrote:
> >>>>>>
> >>>>>> 2017-02-20 23:48 GMT+01:00 Bernhard Stegmaier 
> >>>>>> :
> >>>>>>
> >>>>>> How is this done on Windows?
> >>>>>> You also don’t have a global filesystem with one Python there where 
> >>>>>> you just
> >>>>>> copy it into the right place… where does the Windows installer put 
> >>>>>> those
> >>>>>> files and how do you use them from some installed Python? Are there 
> >>>>>> issues
> >>>>>> with library paths of the library dependencies that come with KiCAD 
> >>>>>> when
> >>>>>> used from an external Python?
> >>>>>>
> >>>>>>
> >>>>>> I am not aware of any issues with it on windows, but I don't really use
> >>>>

[Kicad-developers] FP_LIB_TABLE::FootprintLoad assert on windows; encoding issue

[Chris Pavlina]

Hi,

When running a debug build on Windows, I get an assertion failure here:

common/fp_lib_table.cpp:250
FP_LIB_TABLE::FootprintLoad
wxASSERT( aFootprintName == (wxString) fpid.GetLibItemName() );

This is clearly related to the character encoding of the footprint name.
The footprint in question is "Würth_36103205_20x20mm"; according to gdb
the correct name is in fpid.GetLibItemName(), but the version in
aFootprintName contains garbage in place of the "ü".

Can we just remove this assert and use the correct name read out of the
footprint file? Or is there something here that actually needs to be
fixed? Will KiCad catch fire if the filename doesn't match the footprint
name?

-- 
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

Re: [Kicad-developers] FP_LIB_TABLE::FootprintLoad assert on windows; encoding issue

[Chris Pavlina]

Oops. I lost a LOCALE_IO during a refactor. Never mind this.

On Sat, Mar 18, 2017 at 04:05:28PM -0400, Chris Pavlina wrote:
> Hi,
> 
> When running a debug build on Windows, I get an assertion failure here:
> 
> common/fp_lib_table.cpp:250
> FP_LIB_TABLE::FootprintLoad
> wxASSERT( aFootprintName == (wxString) fpid.GetLibItemName() );
> 
> This is clearly related to the character encoding of the footprint name.
> The footprint in question is "Würth_36103205_20x20mm"; according to gdb
> the correct name is in fpid.GetLibItemName(), but the version in
> aFootprintName contains garbage in place of the "ü".
> 
> Can we just remove this assert and use the correct name read out of the
> footprint file? Or is there something here that actually needs to be
> fixed? Will KiCad catch fire if the filename doesn't match the footprint
> name?
> 
> -- 
> 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

Re: [Kicad-developers] UI improvements

[Chris Pavlina]

On Wed, Mar 22, 2017 at 09:06:33AM -0400, Wayne Stambaugh wrote:
> On 3/22/2017 5:32 AM, Fabrizio Tappero wrote:
> > hi guys,
> > I am looking at some new icons that were introduced in kicad by the
> > people who made the related functionalities and at the user experience
> > in general. If any of you guys has any feedback about possible
> > (aesthetic) UI improvements I would love to know. 
> > 
> > Specifically I am looking at this menu.
> > 
> > Inline image 1
> > 
> > the section "Chip Name" is a part that I use a lot and I find a little
> > "mysterious". Before going further with a possible patch to improve a
> > little the usability of it I would like to know if there is any of you
> > interesting in giving an opinion. I would love to know from the person
> > who made it what exactly is the Chip Name section for. I feel it is not
> > so evident to the user.
> 
> I didn't design this but "Chip Name" is the component library name
> associated with the schematic component using the current component
> library search path.  It really should read something like "Component
> Library Name".  In the not too distant future it should read "Component
> Library Identifier" once the symbol library table code is complete.

Minor nitpick, but "library component name". One is a library of
components, one is a component in such a library :)

> 
> > 
> > cheers
> > Fabrizio
> > 
> > 
> > 
> > 
> > ___
> > 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] UI improvements

[Chris Pavlina]

On Wed, Mar 22, 2017 at 09:19:21AM -0400, Wayne Stambaugh wrote:
> On 3/22/2017 9:20 AM, Chris Pavlina wrote:
> > On Wed, Mar 22, 2017 at 09:06:33AM -0400, Wayne Stambaugh wrote:
> >> On 3/22/2017 5:32 AM, Fabrizio Tappero wrote:
> >>> hi guys,
> >>> I am looking at some new icons that were introduced in kicad by the
> >>> people who made the related functionalities and at the user experience
> >>> in general. If any of you guys has any feedback about possible
> >>> (aesthetic) UI improvements I would love to know. 
> >>>
> >>> Specifically I am looking at this menu.
> >>>
> >>> Inline image 1
> >>>
> >>> the section "Chip Name" is a part that I use a lot and I find a little
> >>> "mysterious". Before going further with a possible patch to improve a
> >>> little the usability of it I would like to know if there is any of you
> >>> interesting in giving an opinion. I would love to know from the person
> >>> who made it what exactly is the Chip Name section for. I feel it is not
> >>> so evident to the user.
> >>
> >> I didn't design this but "Chip Name" is the component library name
> >> associated with the schematic component using the current component
> >> library search path.  It really should read something like "Component
> >> Library Name".  In the not too distant future it should read "Component
> >> Library Identifier" once the symbol library table code is complete.
> > 
> > Minor nitpick, but "library component name". One is a library of
> > components, one is a component in such a library :)
> 
> "Name of Component in Library"?

Sure :)

> 
> > 
> >>
> >>>
> >>> cheers
> >>> Fabrizio
> >>>
> >>>
> >>>
> >>>
> >>> ___
> >>> 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] Icon policy

[Chris Pavlina]

"[PATCH] 3 better icons" made me think of this:

Every once in a while we get patches from people redesigning a bunch of
icons. I think we should probably have some clear policy on icons so we
can have some consistency - it makes a bit of a mess when someone
redesigns half the icons every once in a while.

Wayne? Any thoughts on this? We should probably try to coordinate icon
edits.

PS. Fabrizio, I'm not saying your patch shouldn't be merged, I haven't
actually had a chance to look at it yet. It just made me think of a
problem we've had for a while.

-- 
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

[Kicad-developers] Redundancy in doc comments

[Chris Pavlina]

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

Re: [Kicad-developers] Redundancy in doc comments

[Chris Pavlina]

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] Redundancy in doc comments

[Chris Pavlina]

On Wed, Mar 22, 2017 at 01:05:48PM -0400, Wayne Stambaugh wrote:
> A lot of this is a product of habit and copy & paste.  It's not uncommon
> for derived classes to have the same header doc comments as the base
> class even though this is not necessary either.  I'm OK with changing
> this as we update headers.  I would rather avoid the one giant commit
> with all of the doc comments modified.

May I ask why? IMO one giant commit would be the least noisy, cleanest
option.  It's a single item in the history that only has to be looked at
once.  Also it ensures some sort of consistency - my experience is that
when we do things "as we go" we just end up forgetting to and end up
with an ugly mix.

> 
> On 3/22/2017 11: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
> 
> What's the difference in the doxygen output when the method name isn't
> in the doc comment?  I've never really looked at it that closely.
> 
> > 
> > (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?
> > 
> 
> ___
> 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

[Chris Pavlina]

On Wed, Mar 22, 2017 at 04:08:40PM -0400, Wayne Stambaugh wrote:
> On 3/22/2017 1:14 PM, Chris Pavlina wrote:
> > On Wed, Mar 22, 2017 at 01:05:48PM -0400, Wayne Stambaugh wrote:
> >> A lot of this is a product of habit and copy & paste.  It's not uncommon
> >> for derived classes to have the same header doc comments as the base
> >> class even though this is not necessary either.  I'm OK with changing
> >> this as we update headers.  I would rather avoid the one giant commit
> >> with all of the doc comments modified.
> > 
> > May I ask why? IMO one giant commit would be the least noisy, cleanest
> > option.  It's a single item in the history that only has to be looked at
> > once.  Also it ensures some sort of consistency - my experience is that
> > when we do things "as we go" we just end up forgetting to and end up
> > with an ugly mix.
> 
> Give me a chance to take a look at the difference in the doxygen output
> just so I have a better understanding of why we should do this.  My
> primary concern is merge conflicts.  If you change every or nearly every
> header file to remove the redundant function declarations, us poor
> hapless developers who have commits queued up will most likely get bit
> pretty hard.

Nah, git usually handles simple merges like that very well. I doubt
it'll be an issue. At best you'll have to help it by dropping changes
for any functions you've deleted in private branches.

Very routine merge, honestly.

> 
> > 
> >>
> >> On 3/22/2017 11: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
> >>
> >> What's the difference in the doxygen output when the method name isn't
> >> in the doc comment?  I've never really looked at it that closely.
> >>
> >>>
> >>> (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?
> >>>
> >>
> >> ___
> >> 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

[Chris Pavlina]

On Wed, Mar 22, 2017 at 11:53:40PM +0100, Clemens Koller wrote:
> Hello, Fabrizio!
> 
> The horizontal + vertical justify radio buttons could possibly be improved by 
> showing the alignment visually as it's done in [1] by using a 3 x 3 radio 
> button matrix. It can also reduce the number of clicks to 1 to adjust hor + 
> vert simultaneously.
> 
> The timestamp is not human readable. It seems strange to me to dump it as 
> hex-number on the UI. (WTF!?)

I'm struggling to think of a use for this. Maybe for power users, to
jump quickly to the component in the raw sch file by searching for it -
but why not just search for the reference?

I wonder how many people would complain if I took that out.

> 
> The Component/Chip Name thingy seems to be lost a bit on the lower left. 
> Maybe some sorting of the elements based on the usage/setup procedure as well 
> as logic dependency could do some good.
> 
> Regards,
> 
> Clemens
> 
> [1] https://wiki.openoffice.org/wiki/File:WG9-9.png
> 
> 
> 
> 
> On 2017-03-22 10:32, Fabrizio Tappero wrote:
> > hi guys,
> > I am looking at some new icons that were introduced in kicad by the people 
> > who made the related functionalities and at the user experience in general. 
> > If any of you guys has any feedback about possible (aesthetic) UI 
> > improvements I would love to know. 
> > 
> > Specifically I am looking at this menu.
> > 
> > Inline image 1
> > 
> > the section "Chip Name" is a part that I use a lot and I find a little 
> > "mysterious". Before going further with a possible patch to improve a 
> > little the usability of it I would like to know if there is any of you 
> > interesting in giving an opinion. I would love to know from the person who 
> > made it what exactly is the Chip Name section for. I feel it is not so 
> > evident to the user.
> > 
> > cheers
> > Fabrizio
> > 
> > 
> > 
> > 
> > ___
> > 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] UI improvements

[Chris Pavlina]

Are we calling them "symbols" now? Internally they are called with
"components" or "parts" depending on whether they are on a schematic...

On Thu, Mar 23, 2017 at 03:25:03PM +1300, Simon Wells wrote:
> just a slight segue is it not better to refer to symbols rather
> than components? as with the footprints being seperated from the
> symbols i don't see the justification for calling it a component (will
> also require renaming other stuff)
> 
> On 23 March 2017 at 12:12, Chris Pavlina  wrote:
> > On Wed, Mar 22, 2017 at 11:53:40PM +0100, Clemens Koller wrote:
> >> Hello, Fabrizio!
> >>
> >> The horizontal + vertical justify radio buttons could possibly be improved 
> >> by showing the alignment visually as it's done in [1] by using a 3 x 3 
> >> radio button matrix. It can also reduce the number of clicks to 1 to 
> >> adjust hor + vert simultaneously.
> >>
> >> The timestamp is not human readable. It seems strange to me to dump it as 
> >> hex-number on the UI. (WTF!?)
> >
> > I'm struggling to think of a use for this. Maybe for power users, to
> > jump quickly to the component in the raw sch file by searching for it -
> > but why not just search for the reference?
> >
> > I wonder how many people would complain if I took that out.
> >
> >>
> >> The Component/Chip Name thingy seems to be lost a bit on the lower left. 
> >> Maybe some sorting of the elements based on the usage/setup procedure as 
> >> well as logic dependency could do some good.
> >>
> >> Regards,
> >>
> >> Clemens
> >>
> >> [1] https://wiki.openoffice.org/wiki/File:WG9-9.png
> >>
> >>
> >>
> >>
> >> On 2017-03-22 10:32, Fabrizio Tappero wrote:
> >> > hi guys,
> >> > I am looking at some new icons that were introduced in kicad by the 
> >> > people who made the related functionalities and at the user experience 
> >> > in general. If any of you guys has any feedback about possible 
> >> > (aesthetic) UI improvements I would love to know.
> >> >
> >> > Specifically I am looking at this menu.
> >> >
> >> > Inline image 1
> >> >
> >> > the section "Chip Name" is a part that I use a lot and I find a little 
> >> > "mysterious". Before going further with a possible patch to improve a 
> >> > little the usability of it I would like to know if there is any of you 
> >> > interesting in giving an opinion. I would love to know from the person 
> >> > who made it what exactly is the Chip Name section for. I feel it is not 
> >> > so evident to the user.
> >> >
> >> > cheers
> >> > Fabrizio
> >> >
> >> >
> >> >
> >> >
> >> > ___
> >> > 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] UI improvements

[Chris Pavlina]

On Thu, Mar 23, 2017 at 10:27:55AM +0100, Clemens Koller wrote:
> Hello, Chris!
> 
> On 2017-03-23 00:12, Chris Pavlina wrote:
> > On Wed, Mar 22, 2017 at 11:53:40PM +0100, Clemens Koller wrote:
> >> The timestamp is not human readable. It seems strange to me to dump it as 
> >> hex-number on the UI. (WTF!?)
> > 
> > I'm struggling to think of a use for this. Maybe for power users, to
> > jump quickly to the component in the raw sch file by searching for it -
> > but why not just search for the reference?
> > 
> > I wonder how many people would complain if I took that out.
> 
> I'd complain. 8-)
> Because the timestamp is a valuable information (until we have proper version 
> control in situ).
> But: NOT in hex form. 

Really? How do you use it?

> 
> 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