Re: [Kicad-developers] Eeschema selection

[Jeff Young]

Hi Nhat,

The colours of the “shadows” are the same as the elements themselves — so they 
can be configured the normal way.

And yes, the shadow width scales with the zoom factor.  It’s not 100% the same 
across all zoom sizes as it looks more consistent if it’s bumped up a little a 
larger zooms.

Cheers,
Jeff.


> On 29 Jul 2019, at 12:06, Nhat Khai  wrote:
> 
> It would be nice if they are later can be configurable so hope event blinked 
> color people as see them too. 
> I it would me more sensible (but may be hard to implement) that highlight 
> should not got with zooming like the other items. It should go with the 
> physical screen size. So the highlight may become a big dot for all the 
> elements when the zoom out too far - instead of sink with items. Just like 
> the way mouse selection work - It do not work with zoom since 1 mouse pixel 
> can be many items under.
> 
> On Mon, Jul 29, 2019 at 2:01 AM Jeff Young  > wrote:
> OK, I tried a bunch of things out.  None of them were terribly satisfactory.
> 
> Bolding sounded good, but turned out to be even less noticeable than the 
> brightening.
> 
> The yellow "drop-shadow" looked good on unfilled symbols, but was completely 
> unnoticeable on symbols with a background fill (which defaults to yellow).  
> It also doesn’t scale well, being hard to see when zoomed out.
> 
> I also tried red (cross-probe colour) and magenta (brightening colour) 
> drop-shadows, but they tend to blend with the different item foreground 
> colours giving inconsistent effects.
> 
> The best I could come up with (and it’s not great) is a “drop shadow” made 
> with the item’s hue and a fixed saturation and lightness.
> 
> Cheers,
> Jeff.
> 
> 
> > On 25 Jul 2019, at 23:11, Jeff Young  > > wrote:
> > 
> > Oh, hey, I like the bold idea.  Did you try it out?  (I can if not….)
> > 
> >> On 25 Jul 2019, at 21:02, Seth Hillbrand  >> > wrote:
> >> 
> >> On 2019-07-19 19:03, Jeff Young wrote:
> >> 
> >>> I’ve been thinking of using the magenta colour for both net
> >>> highlighting and cross-probing, and then using the bright red we use
> >>> today for cross-probing for selection.  This does mean that selections
> >>> would no longer have differentiated colours within (between
> >>> components, wires, etc.), but I think might work better than the
> >>> not-very-noticeable state we have today.
> >> 
> >> I toyed with this a bit and I'm not a huge fan.  Turns out I actually use 
> >> the color differences for context when working.
> >> 
> >> What do you think about darkening + bold (say width * 1.2)?
> >> 
> >> -Seth
> > 
> > 
> > ___
> > Mailing list: https://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 
> 
> 
> 
> -- 
> Nhat Khai Nguyen

___
Mailing list: https://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] Board statistics dialog

[Diego Herranz]

>> About the weight estimation of the pcb, considering that in the
(probably near) future a board stackup definition with copper thickness and
dielectric properties will be a part of pcbnew, the weight calculation as
another data of the statistics window will become possible, once the
density of the materials is one of the columns that define the stackup.

Sounds nice. Not sure whether it may be too complex, though.

>> By the way, a statistics report like the one of pcbnew,  with number of
nets and number of components would be useful also in eeschema. Its typical
usage would be to estimate he complexity (and cost) of pcb routing. I'm
asking myself if Alexander's code can be extended to be used also in
eeschema, so that we can have an almost identical "statistics" window there
with minimal effort and consistent interface.

+1

Thanks,
Diego



On Mon, 29 Jul 2019, 21:19 Dino Ghilardi,  wrote:

> Hi,
>
> About the weight estimation of the pcb, considering that in the (probably
> near) future a board stackup definition with copper thickness and
> dielectric properties will be a part of pcbnew, the weight calculation as
> another data of the statistics window will become possible, once the
> density of the materials is one of the columns that define the stackup.
>
> By the way, a statistics report like the one of pcbnew,  with number of
> nets and number of components would be useful also in eeschema. Its typical
> usage would be to estimate he complexity (and cost) of pcb routing. I'm
> asking myself if Alexander's code can be extended to be used also in
> eeschema, so that we can have an almost identical "statistics" window there
> with minimal effort and consistent interface.
>
> Cheers,
> Dino.
>
> Il Lun 29 Lug 2019 20:24 Diego Herranz  ha
> scritto:
>
>> I agree both are useful.
>> (Max width x Max height) area is useful as a worst case scenario for
>> manufacturing: it may end up being better depending on the shape of the
>> board and panel design.
>> Regarding actual area, I'm working on a project right now where I need to
>> provide an estimation of the weight of the board. Knowing the actual area
>> of FR4 is useful.
>>
>> Thanks!
>>
>>
>>
>>
>> On Mon, 29 Jul 2019 at 14:33, Wayne Stambaugh 
>> wrote:
>>
>>> I agree.  There is utility in both the actual area of a board and the
>>> manufacturing area.  The latter should be fairly trivial to implement.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 7/29/19 9:30 AM, Clemens Koller wrote:
>>> > Hi!
>>> > I think it could be good to see both:
>>> > - The actual PCB area of the outline (well, without drills).
>>> > - The max-width * max-height which is usually what you have to pay for
>>> when you get it manufactured.
>>> > The second one could be also an interesting task to calculate if you
>>> have an odd shaped polygonal outline.
>>> >
>>> > Regards,
>>> > Clemens
>>> >
>>> >
>>> > On 29/07/2019 14.43, Alexander Shuklin wrote:
>>> >>   Hi! I've been asked to do actually PCB area calculation. Since
>>> English is not my first language, maybe I just miss-understood. Do you
>>> mean, that area has to be just max width * max height? I never seen that,
>>> but there's a message in thread about sometimes you need proper area.
>>> >> I utilized kicad outline functions for that.
>>> >>
>>> >>
>>> >> Понедельник, 29 июля 2019, 15:35 +03:00 от Mark Roszko <
>>> mark.ros...@gmail.com>:
>>> >>
>>> >> Huh, looking at the statistics code, it actually tries and find
>>> the more "detailed area" of a board based on any polygonal outline.
>>> >> Is there any value in it this way? PCB manufacturing charges are
>>> generally per-square area  because ultimately the price is on panel space
>>> you are using.
>>> >>
>>> >> On Sat, Jul 27, 2019 at 5:07 AM Diego Herranz <
>>> diegoherr...@diegoherranz.com >> e.mail.ru/compose/?mailto=mailto%3adiegoherr...@diegoherranz.com>>
>>> wrote:
>>> >>
>>> >> I've been testing this dialog and I think it is a nice
>>> addition. Thanks!
>>> >>
>>> >> There seems to be something wrong with the area calculation,
>>> though. See image below:
>>> >> area.png
>>> >>
>>> >> Thanks,
>>> >> Diego
>>> >>
>>> >> On Tue, 23 Jul 2019 at 11:18, Ian McInerney <
>>> ian.s.mciner...@ieee.org >> e.mail.ru/compose/?mailto=mailto%3aian.s.mciner...@ieee.org>> wrote:
>>> >>
>>> >> Alexander,
>>> >>
>>> >> Instead of declaring the 2 static variables separately, I
>>> would suggest creating a struct for the settings then store that as the
>>> static variable. For an example of this see the dialog_create_array.cpp
>>> file. This way if any new options must be added in the future, they can
>>> just be added to the struct very easily.
>>> >>
>>> >> -Ian
>>> >>
>>> >> On Mon, Jul 22, 2019 at 9:39 PM Alexander Shuklin <
>>> jasura...@mail.ru >> e.mail.ru/compose/?mailto=mailto%3ajasura...@mail.ru>> wrote:
>>> >>
>>> >> Damn ><,
>>> >>   

Re: [Kicad-developers] [PATCH] Board statistics dialog

[Dino Ghilardi]

Hi,

About the weight estimation of the pcb, considering that in the (probably
near) future a board stackup definition with copper thickness and
dielectric properties will be a part of pcbnew, the weight calculation as
another data of the statistics window will become possible, once the
density of the materials is one of the columns that define the stackup.

By the way, a statistics report like the one of pcbnew,  with number of
nets and number of components would be useful also in eeschema. Its typical
usage would be to estimate he complexity (and cost) of pcb routing. I'm
asking myself if Alexander's code can be extended to be used also in
eeschema, so that we can have an almost identical "statistics" window there
with minimal effort and consistent interface.

Cheers,
Dino.

Il Lun 29 Lug 2019 20:24 Diego Herranz  ha
scritto:

> I agree both are useful.
> (Max width x Max height) area is useful as a worst case scenario for
> manufacturing: it may end up being better depending on the shape of the
> board and panel design.
> Regarding actual area, I'm working on a project right now where I need to
> provide an estimation of the weight of the board. Knowing the actual area
> of FR4 is useful.
>
> Thanks!
>
>
>
>
> On Mon, 29 Jul 2019 at 14:33, Wayne Stambaugh 
> wrote:
>
>> I agree.  There is utility in both the actual area of a board and the
>> manufacturing area.  The latter should be fairly trivial to implement.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 7/29/19 9:30 AM, Clemens Koller wrote:
>> > Hi!
>> > I think it could be good to see both:
>> > - The actual PCB area of the outline (well, without drills).
>> > - The max-width * max-height which is usually what you have to pay for
>> when you get it manufactured.
>> > The second one could be also an interesting task to calculate if you
>> have an odd shaped polygonal outline.
>> >
>> > Regards,
>> > Clemens
>> >
>> >
>> > On 29/07/2019 14.43, Alexander Shuklin wrote:
>> >>   Hi! I've been asked to do actually PCB area calculation. Since
>> English is not my first language, maybe I just miss-understood. Do you
>> mean, that area has to be just max width * max height? I never seen that,
>> but there's a message in thread about sometimes you need proper area.
>> >> I utilized kicad outline functions for that.
>> >>
>> >>
>> >> Понедельник, 29 июля 2019, 15:35 +03:00 от Mark Roszko <
>> mark.ros...@gmail.com>:
>> >>
>> >> Huh, looking at the statistics code, it actually tries and find
>> the more "detailed area" of a board based on any polygonal outline.
>> >> Is there any value in it this way? PCB manufacturing charges are
>> generally per-square area  because ultimately the price is on panel space
>> you are using.
>> >>
>> >> On Sat, Jul 27, 2019 at 5:07 AM Diego Herranz <
>> diegoherr...@diegoherranz.com > e.mail.ru/compose/?mailto=mailto%3adiegoherr...@diegoherranz.com>> wrote:
>> >>
>> >> I've been testing this dialog and I think it is a nice
>> addition. Thanks!
>> >>
>> >> There seems to be something wrong with the area calculation,
>> though. See image below:
>> >> area.png
>> >>
>> >> Thanks,
>> >> Diego
>> >>
>> >> On Tue, 23 Jul 2019 at 11:18, Ian McInerney <
>> ian.s.mciner...@ieee.org > e.mail.ru/compose/?mailto=mailto%3aian.s.mciner...@ieee.org>> wrote:
>> >>
>> >> Alexander,
>> >>
>> >> Instead of declaring the 2 static variables separately, I
>> would suggest creating a struct for the settings then store that as the
>> static variable. For an example of this see the dialog_create_array.cpp
>> file. This way if any new options must be added in the future, they can
>> just be added to the struct very easily.
>> >>
>> >> -Ian
>> >>
>> >> On Mon, Jul 22, 2019 at 9:39 PM Alexander Shuklin <
>> jasura...@mail.ru >
>> wrote:
>> >>
>> >> Damn ><,
>> >> don't use last patch, please.
>> >> It doesn't count total vias amount. Use this one.
>> >>
>> >>
>> >> Понедельник, 22 июля 2019, 22:14 +03:00 от
>> Alexander Shuklin > e.mail.ru/compose/?mailto=mailto%3ajasura...@mail.ru>>:
>> >>
>> >> Hi,
>> >> thanks for sharing experience, as I never used
>> that translations or wxWidgets before. And I have no idea where else could
>> I get that information. ))
>> >> So, there's the patch with vias information and
>> some tiny improvements.
>> >>
>> >>
>> >> Понедельник, 22 июля 2019, 13:34 +03:00 от Ian
>> McInerney > e.mail.ru/compose/?mailto=mailto%3aian.s.mciner...@ieee.org>>:
>> >>
>> >>
>> >>
>> >> On Mon, Jul 22, 2019 at 11:03 AM Dino Ghilardi
>> > http://e.mail.ru/compose/?mailto=mailto%3adino.ghila...@ieee.org>> wrote:
>> >>
>> >> Hi Alexander,
>> >>
>> >> One possible solution for the translation
>> could be put the ":" i

Re: [Kicad-developers] [PATCH] Board statistics dialog

[Diego Herranz]

I agree both are useful.
(Max width x Max height) area is useful as a worst case scenario for
manufacturing: it may end up being better depending on the shape of the
board and panel design.
Regarding actual area, I'm working on a project right now where I need to
provide an estimation of the weight of the board. Knowing the actual area
of FR4 is useful.

Thanks!




On Mon, 29 Jul 2019 at 14:33, Wayne Stambaugh  wrote:

> I agree.  There is utility in both the actual area of a board and the
> manufacturing area.  The latter should be fairly trivial to implement.
>
> Cheers,
>
> Wayne
>
> On 7/29/19 9:30 AM, Clemens Koller wrote:
> > Hi!
> > I think it could be good to see both:
> > - The actual PCB area of the outline (well, without drills).
> > - The max-width * max-height which is usually what you have to pay for
> when you get it manufactured.
> > The second one could be also an interesting task to calculate if you
> have an odd shaped polygonal outline.
> >
> > Regards,
> > Clemens
> >
> >
> > On 29/07/2019 14.43, Alexander Shuklin wrote:
> >>   Hi! I've been asked to do actually PCB area calculation. Since
> English is not my first language, maybe I just miss-understood. Do you
> mean, that area has to be just max width * max height? I never seen that,
> but there's a message in thread about sometimes you need proper area.
> >> I utilized kicad outline functions for that.
> >>
> >>
> >> Понедельник, 29 июля 2019, 15:35 +03:00 от Mark Roszko <
> mark.ros...@gmail.com>:
> >>
> >> Huh, looking at the statistics code, it actually tries and find the
> more "detailed area" of a board based on any polygonal outline.
> >> Is there any value in it this way? PCB manufacturing charges are
> generally per-square area  because ultimately the price is on panel space
> you are using.
> >>
> >> On Sat, Jul 27, 2019 at 5:07 AM Diego Herranz <
> diegoherr...@diegoherranz.com  e.mail.ru/compose/?mailto=mailto%3adiegoherr...@diegoherranz.com>> wrote:
> >>
> >> I've been testing this dialog and I think it is a nice
> addition. Thanks!
> >>
> >> There seems to be something wrong with the area calculation,
> though. See image below:
> >> area.png
> >>
> >> Thanks,
> >> Diego
> >>
> >> On Tue, 23 Jul 2019 at 11:18, Ian McInerney <
> ian.s.mciner...@ieee.org  e.mail.ru/compose/?mailto=mailto%3aian.s.mciner...@ieee.org>> wrote:
> >>
> >> Alexander,
> >>
> >> Instead of declaring the 2 static variables separately, I
> would suggest creating a struct for the settings then store that as the
> static variable. For an example of this see the dialog_create_array.cpp
> file. This way if any new options must be added in the future, they can
> just be added to the struct very easily.
> >>
> >> -Ian
> >>
> >> On Mon, Jul 22, 2019 at 9:39 PM Alexander Shuklin <
> jasura...@mail.ru >
> wrote:
> >>
> >> Damn ><,
> >> don't use last patch, please.
> >> It doesn't count total vias amount. Use this one.
> >>
> >>
> >> Понедельник, 22 июля 2019, 22:14 +03:00 от
> Alexander Shuklin  e.mail.ru/compose/?mailto=mailto%3ajasura...@mail.ru>>:
> >>
> >> Hi,
> >> thanks for sharing experience, as I never used that
> translations or wxWidgets before. And I have no idea where else could I get
> that information. ))
> >> So, there's the patch with vias information and
> some tiny improvements.
> >>
> >>
> >> Понедельник, 22 июля 2019, 13:34 +03:00 от Ian
> McInerney  e.mail.ru/compose/?mailto=mailto%3aian.s.mciner...@ieee.org>>:
> >>
> >>
> >>
> >> On Mon, Jul 22, 2019 at 11:03 AM Dino Ghilardi <
> dino.ghila...@ieee.org <
> http://e.mail.ru/compose/?mailto=mailto%3adino.ghila...@ieee.org>> wrote:
> >>
> >> Hi Alexander,
> >>
> >> One possible solution for the translation
> could be put the ":" in a
> >> different column of the table and
> right-align the field description text
> >> (so all the colons will be aligned). A
> rapid google search shown that in
> >> French and Vietnamese there should be a
> space before the colon, while in
> >> the rest of the world there is not, so
> having the translation for the
> >> ":" word seems to make sense. Also another
> question arises: Is there
> >> some language in which the colon should be
> another character before the
> >> word? (I'm thinking about spanish where the
> question mark upside-down
> >> appears before a question...)?
> ...conclusion: keeping "Height:" and
> >> "Height" as two different words seem to be
> the solut

Re: [Kicad-developers] [PATCH] Board statistics dialog

[Diego Herranz]

Done: https://bugs.launchpad.net/kicad/+bug/1838325

Thanks!

On Sun, 28 Jul 2019 at 15:04, Wayne Stambaugh  wrote:

> Diego,
>
> Please file a bug report for this and include the board file that causes
> this so it's easier for us to figure out what is going on.
>
> Thanks,
>
> Wayne
>
> On 7/27/19 5:06 AM, Diego Herranz wrote:
> > I've been testing this dialog and I think it is a nice addition. Thanks!
> >
> > There seems to be something wrong with the area calculation, though. See
> > image below:
> > area.png
> >
> > Thanks,
> > Diego
> >
> > On Tue, 23 Jul 2019 at 11:18, Ian McInerney  > > wrote:
> >
> > Alexander,
> >
> > Instead of declaring the 2 static variables separately, I would
> > suggest creating a struct for the settings then store that as the
> > static variable. For an example of this see the
> > dialog_create_array.cpp file. This way if any new options must be
> > added in the future, they can just be added to the struct very
> easily.
> >
> > -Ian
> >
> > On Mon, Jul 22, 2019 at 9:39 PM Alexander Shuklin  > > wrote:
> >
> > Damn ><,
> > don't use last patch, please.
> > It doesn't count total vias amount. Use this one.
> >
> >
> > Понедельник, 22 июля 2019, 22:14 +03:00 от Alexander Shuklin
> > mailto:jasura...@mail.ru>>:
> >
> > Hi,
> > thanks for sharing experience, as I never used that
> > translations or wxWidgets before. And I have no idea where
> > else could I get that information. ))
> > So, there's the patch with vias information and some tiny
> > improvements.
> >
> >
> > Понедельник, 22 июля 2019, 13:34 +03:00 от Ian McInerney
> >  > >:
> >
> >
> >
> > On Mon, Jul 22, 2019 at 11:03 AM Dino Ghilardi
> >  > <
> http://e.mail.ru/compose/?mailto=mailto%3adino.ghila...@ieee.org>>
> > wrote:
> >
> > Hi Alexander,
> >
> > One possible solution for the translation could be
> > put the ":" in a
> > different column of the table and right-align the
> > field description text
> > (so all the colons will be aligned). A rapid google
> > search shown that in
> > French and Vietnamese there should be a space before
> > the colon, while in
> > the rest of the world there is not, so having the
> > translation for the
> > ":" word seems to make sense. Also another question
> > arises: Is there
> > some language in which the colon should be another
> > character before the
> > word? (I'm thinking about spanish where the question
> > mark upside-down
> > appears before a question...)? ...conclusion:
> > keeping "Height:" and
> > "Height" as two different words seem to be the
> > solution that gives
> > maximum flexibility to translators.
> >
> >
> > This actually doesn't give them as much flexibility.
> > When translations are done, they need to examine the
> > entire string that needs translating, so the ":"
> > character should be included in the string. Separating
> > out the two portions is the equivalent of saying that
> > every lanugage will follow the same compositional rules.
> >
> >
> > Another possible solution (probably better then the
> > one above since it
> > just removes the problem) is to remove the ":" and
> > have the cell borders
> > in a different color, just like the tables in the
> > "board setup" dialog
> > (so that you can also take a look at that code to
> > solve also the color
> > problem seeing how it was solved there). The
> > advantage of this approach
> > is also having a more consistent "look" through all
> > the dialogs.
> >
> >
> >
> > P.S. (a little bit off-topic):
> > If you move the statistic window and check/uncheck
> > one of the checkboxes
> > ("subctract holes" or "Exclude components...")
> > the window "jumps" to
> > the center of the screen (its default position on
> > open): do you have
> >   

Re: [Kicad-developers] [PATCH] Crash Reporter

[Nick Østergaard]

I rebased this for todays master and pushed it to:
https://github.com/nickoe/kicad-source-mirror/tree/tom-crash-reporter-may27_rebased20190729

Diff view of changes:
https://github.com/nickoe/kicad-source-mirror/compare/7b5b807...nickoe:tom-crash-reporter-may27_rebased20190729?expand=1

I don't think I let it follow the recent style in mater about the menu:
https://github.com/nickoe/kicad-source-mirror/compare/7b5b807...nickoe:tom-crash-reporter-may27_rebased20190729?expand=1#diff-512ddae11b132baba0403a7df0fc215bR376

I did see it build on archlinux and it did report to launchpad with
the menu entry to test the crash reporter.

I still need to test it on windows.

On Tue, 16 Jul 2019 at 13:01, Nick Østergaard  wrote:
>
> It looks like some of the errors are related to the lexer stuff. Can
> you try to rebase your branch to latest master?
>
> On Tue, 16 Jul 2019 at 13:00, Nick Østergaard  wrote:
> >
> > @Tomasz Wlostowski  I am trying to build against wx3.1, but I get
> > build errors, please review the build log:
> >
> > https://jenkins.simonrichter.eu/job/windows-kicad-msys2-patch/465/console
> >
> > On Tue, 16 Jul 2019 at 12:37, Nick Østergaard  wrote:
> > >
> > > Hmm, ok, I guess you mean the -may27 one.. it seem to have never commits.
> > >
> > > https://github.com/twlostow/kicad-dev/tree/tom-crash-reporter-may27
> > >
> > > On Tue, 16 Jul 2019 at 11:08, Tomasz Wlostowski
> > >  wrote:
> > > >
> > > > On 15/07/2019 14:43, Nick Østergaard wrote:
> > > > > Remind me, is this feature still in a seperate branch to master, or
> > > > > how is it enabled?
> > > >
> > > > IIRC it's still tom-crash-reporter on my github and it's enabled in
> > > > CMake config (KICAD_CRASH_REPORTER=yes).
> > > >
> > > > T.
> > > >
> > > > >
> > > > > On Thu, 11 Jul 2019 at 21:08, Nick Østergaard  
> > > > > wrote:
> > > > >>
> > > > >> @Tomasz Wlostowski  I just found that it looks like someone has
> > > > >> uploaded a wxwidgets 3.1 pkgbuild for the mingw-packages for msys2, I
> > > > >> could try to build and and rebuild your branch for windows.
> > > > >>
> > > > >> https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-wxWidgets3.1/PKGBUILD
> > > > >>
> > > > >> On Tue, 9 Jul 2019 at 14:09, Wayne Stambaugh  
> > > > >> wrote:
> > > > >>>
> > > > >>> Tom,
> > > > >>>
> > > > >>> On 7/9/19 2:41 AM, Tomasz Wlostowski wrote:
> > > >  On 06/07/2019 21:10, Ian McInerney wrote:
> > > > > Tom,
> > > > >
> > > > > Not to pile on the questions, but does the linux stack trace 
> > > > > support
> > > > > exist in the entire 3.0.x line, or how far back does it go? 
> > > > > Currently,
> > > > > the minimum version searched by cmake is 3.0.0, and some major 
> > > > > linux
> > > > > distros only have 3.0.2 (Debian Stable, EPEL6/7, and Ubuntu 16.04 
> > > > > to
> > > > > name a few).
> > > > 
> > > >  Hi,
> > > > 
> > > >  Under liunx stack trace works fine in 3.0.2. Under Windows it's not
> > > >  implemented at all (unless using a crazy hack 
> > > >  self-exception-raising
> > > >  hack that works only under MSVC).
> > > > 
> > > >  I can work this around by having our own Windows stack walker - 
> > > >  after
> > > >  all the whole purpose  of the crash reporter was easy debug 
> > > >  reports for
> > > >  Windows users. Under Linux everyone knows how to use a debugger,
> > > >  otherwise it's impossible to work ;-)
> > > > >>> I'm assuming that you mean that you are going to pull the
> > > > >>> wxDebugReporter code from the 3.1 branch of wxWidgets which can be
> > > > >>> removed once wxWidgets 3.2 becomes the default.  If it's any more 
> > > > >>> than
> > > > >>> that, I would rather wait until 3.2 is available.
> > > > >>>
> > > > 
> > > >  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

Re: [Kicad-developers] [PATCH] Board statistics dialog

[Wayne Stambaugh]

I agree.  There is utility in both the actual area of a board and the
manufacturing area.  The latter should be fairly trivial to implement.

Cheers,

Wayne

On 7/29/19 9:30 AM, Clemens Koller wrote:
> Hi!
> I think it could be good to see both:
> - The actual PCB area of the outline (well, without drills).
> - The max-width * max-height which is usually what you have to pay for when 
> you get it manufactured.
> The second one could be also an interesting task to calculate if you have an 
> odd shaped polygonal outline.
> 
> Regards,
> Clemens
> 
> 
> On 29/07/2019 14.43, Alexander Shuklin wrote:
>>   Hi! I've been asked to do actually PCB area calculation. Since English is 
>> not my first language, maybe I just miss-understood. Do you mean, that area 
>> has to be just max width * max height? I never seen that, but there's a 
>> message in thread about sometimes you need proper area.
>> I utilized kicad outline functions for that.
>>
>>
>> Понедельник, 29 июля 2019, 15:35 +03:00 от Mark Roszko 
>> :
>>
>> Huh, looking at the statistics code, it actually tries and find the more 
>> "detailed area" of a board based on any polygonal outline.
>> Is there any value in it this way? PCB manufacturing charges are 
>> generally per-square area  because ultimately the price is on panel space 
>> you are using. 
>>
>> On Sat, Jul 27, 2019 at 5:07 AM Diego Herranz 
>> > > wrote:
>>
>> I've been testing this dialog and I think it is a nice addition. 
>> Thanks!
>>
>> There seems to be something wrong with the area calculation, though. 
>> See image below:
>> area.png
>>
>> Thanks,
>> Diego
>>
>> On Tue, 23 Jul 2019 at 11:18, Ian McInerney 
>> > > wrote:
>>
>> Alexander,
>>
>> Instead of declaring the 2 static variables separately, I would 
>> suggest creating a struct for the settings then store that as the static 
>> variable. For an example of this see the dialog_create_array.cpp file. This 
>> way if any new options must be added in the future, they can just be added 
>> to the struct very easily.
>>
>> -Ian
>>
>> On Mon, Jul 22, 2019 at 9:39 PM Alexander Shuklin 
>> > 
>> wrote:
>>
>> Damn ><,
>> don't use last patch, please.
>> It doesn't count total vias amount. Use this one.
>>
>>
>> Понедельник, 22 июля 2019, 22:14 +03:00 от Alexander 
>> Shuklin > >:
>>
>> Hi,
>> thanks for sharing experience, as I never used that 
>> translations or wxWidgets before. And I have no idea where else could I get 
>> that information. ))
>> So, there's the patch with vias information and some 
>> tiny improvements.
>>
>>
>> Понедельник, 22 июля 2019, 13:34 +03:00 от Ian 
>> McInerney > >:
>>
>>
>>
>> On Mon, Jul 22, 2019 at 11:03 AM Dino Ghilardi 
>> > > wrote:
>>
>> Hi Alexander,
>>
>> One possible solution for the translation could 
>> be put the ":" in a
>> different column of the table and right-align 
>> the field description text
>> (so all the colons will be aligned). A rapid 
>> google search shown that in
>> French and Vietnamese there should be a space 
>> before the colon, while in
>> the rest of the world there is not, so having 
>> the translation for the
>> ":" word seems to make sense. Also another 
>> question arises: Is there
>> some language in which the colon should be 
>> another character before the
>> word? (I'm thinking about spanish where the 
>> question mark upside-down
>> appears before a question...)? ...conclusion: 
>> keeping "Height:" and
>> "Height" as two different words seem to be the 
>> solution that gives
>> maximum flexibility to translators.
>>
>>
>> This actually doesn't give them as much flexibility. 
>> When translations are done, they need to examine the entire string that 
>> needs translating, so the ":" character should be included in the string. 
>> Separating out the two portions is the equivalent of saying that every 
>> lanugage will follow the same compositional rules.
>>  
>>
>> Another possible solution (probably better then 
>> the one above since it
>> just removes the problem) is to remove the ":" 
>> and have the cell borders
>> in a different color, just like the tables in 
>> the "board setup" dialog
>> (so that you can also take a look

Re: [Kicad-developers] [PATCH] Board statistics dialog

[Clemens Koller]

Hi!
I think it could be good to see both:
- The actual PCB area of the outline (well, without drills).
- The max-width * max-height which is usually what you have to pay for when you 
get it manufactured.
The second one could be also an interesting task to calculate if you have an 
odd shaped polygonal outline.

Regards,
Clemens


On 29/07/2019 14.43, Alexander Shuklin wrote:
>   Hi! I've been asked to do actually PCB area calculation. Since English is 
> not my first language, maybe I just miss-understood. Do you mean, that area 
> has to be just max width * max height? I never seen that, but there's a 
> message in thread about sometimes you need proper area.
> I utilized kicad outline functions for that.
> 
> 
> Понедельник, 29 июля 2019, 15:35 +03:00 от Mark Roszko 
> :
> 
> Huh, looking at the statistics code, it actually tries and find the more 
> "detailed area" of a board based on any polygonal outline.
> Is there any value in it this way? PCB manufacturing charges are 
> generally per-square area  because ultimately the price is on panel space you 
> are using. 
> 
> On Sat, Jul 27, 2019 at 5:07 AM Diego Herranz 
>  > wrote:
> 
> I've been testing this dialog and I think it is a nice addition. 
> Thanks!
> 
> There seems to be something wrong with the area calculation, though. 
> See image below:
> area.png
> 
> Thanks,
> Diego
> 
> On Tue, 23 Jul 2019 at 11:18, Ian McInerney  > wrote:
> 
> Alexander,
> 
> Instead of declaring the 2 static variables separately, I would 
> suggest creating a struct for the settings then store that as the static 
> variable. For an example of this see the dialog_create_array.cpp file. This 
> way if any new options must be added in the future, they can just be added to 
> the struct very easily.
> 
> -Ian
> 
> On Mon, Jul 22, 2019 at 9:39 PM Alexander Shuklin 
> > 
> wrote:
> 
> Damn ><,
> don't use last patch, please.
> It doesn't count total vias amount. Use this one.
> 
> 
> Понедельник, 22 июля 2019, 22:14 +03:00 от Alexander 
> Shuklin  >:
> 
> Hi,
> thanks for sharing experience, as I never used that 
> translations or wxWidgets before. And I have no idea where else could I get 
> that information. ))
> So, there's the patch with vias information and some tiny 
> improvements.
> 
> 
> Понедельник, 22 июля 2019, 13:34 +03:00 от Ian 
> McInerney  >:
> 
> 
> 
> On Mon, Jul 22, 2019 at 11:03 AM Dino Ghilardi 
>  > wrote:
> 
> Hi Alexander,
> 
> One possible solution for the translation could 
> be put the ":" in a
> different column of the table and right-align the 
> field description text
> (so all the colons will be aligned). A rapid 
> google search shown that in
> French and Vietnamese there should be a space 
> before the colon, while in
> the rest of the world there is not, so having the 
> translation for the
> ":" word seems to make sense. Also another 
> question arises: Is there
> some language in which the colon should be 
> another character before the
> word? (I'm thinking about spanish where the 
> question mark upside-down
> appears before a question...)? ...conclusion: 
> keeping "Height:" and
> "Height" as two different words seem to be the 
> solution that gives
> maximum flexibility to translators.
> 
> 
> This actually doesn't give them as much flexibility. 
> When translations are done, they need to examine the entire string that needs 
> translating, so the ":" character should be included in the string. 
> Separating out the two portions is the equivalent of saying that every 
> lanugage will follow the same compositional rules.
>  
> 
> Another possible solution (probably better then 
> the one above since it
> just removes the problem) is to remove the ":" 
> and have the cell borders
> in a different color, just like the tables in the 
> "board setup" dialog
> (so that you can also take a look at that code to 
> solve also the color
> problem seeing how it was solved there). The 
> advantage of this approach
> is also having a more consistent "look" through 
> all the dialogs.
> 
> 
> 
> P.S. (a little bit off-topic):
>  

Re: [Kicad-developers] [PATCH] Board statistics dialog

[Alexander Shuklin]

  Hi! I've been asked to do actually PCB area calculation. Since English is not 
my first language, maybe I just miss-understood. Do you mean, that area has to 
be just max width * max height? I never seen that, but there's a message in 
thread about sometimes you need proper area. 
I utilized kicad outline functions for that.


>Понедельник, 29 июля 2019, 15:35 +03:00 от Mark Roszko :
>
>Huh, looking at the statistics code, it actually tries and find the more 
>"detailed area" of a board based on any polygonal outline.
>Is there any value in it this way? PCB manufacturing charges are generally 
>per-square area  because ultimately the price is on panel space you are using. 
>On Sat, Jul 27, 2019 at 5:07 AM Diego Herranz < diegoherr...@diegoherranz.com 
>> wrote:
>>I've been testing this dialog and I think it is a nice addition. Thanks!
>>
>>There seems to be something wrong with the area calculation, though. See 
>>image below:
>>
>>
>>Thanks,
>>Diego
>>On Tue, 23 Jul 2019 at 11:18, Ian McInerney < ian.s.mciner...@ieee.org > 
>>wrote:
>>>Alexander,
>>>
>>>Instead of declaring the 2 static variables separately, I would suggest 
>>>creating a struct for the settings then store that as the static variable. 
>>>For an example of this see the dialog_create_array.cpp file. This way if any 
>>>new options must be added in the future, they can just be added to the 
>>>struct very easily.
>>>
>>>-Ian
>>>On Mon, Jul 22, 2019 at 9:39 PM Alexander Shuklin < jasura...@mail.ru > 
>>>wrote:
Damn ><,
don't use last patch, please.
It doesn't count total vias amount. Use this one.


>Понедельник, 22 июля 2019, 22:14 +03:00 от Alexander Shuklin < 
>jasura...@mail.ru >:
>
>Hi,
>thanks for sharing experience, as I never used that translations or 
>wxWidgets before. And I have no idea where else could I get that 
>information. ))
>So, there's the patch with vias information and some tiny improvements. 
>
>
>>Понедельник, 22 июля 2019, 13:34 +03:00 от Ian McInerney < 
>>ian.s.mciner...@ieee.org >:
>>
>>
>>
>>On Mon, Jul 22, 2019 at 11:03 AM Dino Ghilardi < dino.ghila...@ieee.org > 
>>wrote:
>>>Hi Alexander,
>>>
>>>One possible solution for the translation could be put the ":" in a 
>>>different column of the table and right-align the field description text 
>>>(so all the colons will be aligned). A rapid google search shown that in 
>>>French and Vietnamese there should be a space before the colon, while in 
>>>the rest of the world there is not, so having the translation for the 
>>>":" word seems to make sense. Also another question arises: Is there 
>>>some language in which the colon should be another character before the 
>>>word? (I'm thinking about spanish where the question mark upside-down 
>>>appears before a question...)? ...conclusion: keeping "Height:" and 
>>>"Height" as two different words seem to be the solution that gives 
>>>maximum flexibility to translators.
>>>
>>
>>This actually doesn't give them as much flexibility. When translations 
>>are done, they need to examine the entire string that needs translating, 
>>so the ":" character should be included in the string. Separating out the 
>>two portions is the equivalent of saying that every lanugage will follow 
>>the same compositional rules.
>>  
>>>Another possible solution (probably better then the one above since it 
>>>just removes the problem) is to remove the ":" and have the cell borders 
>>>in a different color, just like the tables in the "board setup" dialog 
>>>(so that you can also take a look at that code to solve also the color 
>>>problem seeing how it was solved there). The advantage of this approach 
>>>is also having a more consistent "look" through all the dialogs.
>>>
>>>
>>>
>>>P.S. (a little bit off-topic):
>>>If you move the statistic window and check/uncheck one of the checkboxes 
>>>("subctract holes" or "Exclude components...") the window "jumps" to 
>>>the center of the screen (its default position on open): do you have 
>>>also this behaviour or it is just on my debian-linux with gtk3?
>>>
>>>
>>>Cheers,
>>>Dino.
>>>
>>>On 22/07/19 10:13, Alexander Shuklin wrote:
 Hi!
 I'll have a look to add vias count to dialog.
 There's some questions:
 
 1)I don't have too much experience with wxdialogs. There was commit on 
 master, which says:
  >> remove settings for fg/bg color: the result is unpredictable: was 
 black texts on black background on my computer.
 And now I have all tables with data just in white boxes. Is it how it 
 meant to be, or just some misbehavior on different systems? I use 
 archlinux x64 OS.
 there's screenshot in attachment
 
 2) Can we use something 

Re: [Kicad-developers] [PATCH] Board statistics dialog

[Alexander Shuklin]

Hi,
I was without internet for few days, I will look for problem. Anyway, 
information about that bug will be very helpful.

>Воскресенье, 28 июля 2019, 17:04 +03:00 от Wayne Stambaugh 
>:
>
>Diego,
>
>Please file a bug report for this and include the board file that causes
>this so it's easier for us to figure out what is going on.
>
>Thanks,
>
>Wayne
>
>On 7/27/19 5:06 AM, Diego Herranz wrote:
>> I've been testing this dialog and I think it is a nice addition. Thanks!
>> 
>> There seems to be something wrong with the area calculation, though. See
>> image below:
>> area.png
>> 
>> Thanks,
>> Diego
>> 
>> On Tue, 23 Jul 2019 at 11:18, Ian McInerney < ian.s.mciner...@ieee.org
>> > wrote:
>> 
>> Alexander,
>> 
>> Instead of declaring the 2 static variables separately, I would
>> suggest creating a struct for the settings then store that as the
>> static variable. For an example of this see the
>> dialog_create_array.cpp file. This way if any new options must be
>> added in the future, they can just be added to the struct very easily.
>> 
>> -Ian
>> 
>> On Mon, Jul 22, 2019 at 9:39 PM Alexander Shuklin < jasura...@mail.ru
>> > wrote:
>> 
>> Damn ><,
>> don't use last patch, please.
>> It doesn't count total vias amount. Use this one.
>> 
>> 
>> Понедельник, 22 июля 2019, 22:14 +03:00 от Alexander Shuklin
>> < jasura...@mail.ru >:
>> 
>> Hi,
>> thanks for sharing experience, as I never used that
>> translations or wxWidgets before. And I have no idea where
>> else could I get that information. ))
>> So, there's the patch with vias information and some tiny
>> improvements.
>> 
>> 
>> Понедельник, 22 июля 2019, 13:34 +03:00 от Ian McInerney
>> < ian.s.mciner...@ieee.org
>> >:
>> 
>> 
>> 
>> On Mon, Jul 22, 2019 at 11:03 AM Dino Ghilardi
>> < dino.ghila...@ieee.org
>> < 
>> http://e.mail.ru/compose/?mailto=mailto%3adino.ghila...@ieee.org >>
>> wrote:
>> 
>> Hi Alexander,
>> 
>> One possible solution for the translation could be
>> put the ":" in a
>> different column of the table and right-align the
>> field description text
>> (so all the colons will be aligned). A rapid google
>> search shown that in
>> French and Vietnamese there should be a space before
>> the colon, while in
>> the rest of the world there is not, so having the
>> translation for the
>> ":" word seems to make sense. Also another question
>> arises: Is there
>> some language in which the colon should be another
>> character before the
>> word? (I'm thinking about spanish where the question
>> mark upside-down
>> appears before a question...)? ...conclusion:
>> keeping "Height:" and
>> "Height" as two different words seem to be the
>> solution that gives
>> maximum flexibility to translators.
>> 
>> 
>> This actually doesn't give them as much flexibility.
>> When translations are done, they need to examine the
>> entire string that needs translating, so the ":"
>> character should be included in the string. Separating
>> out the two portions is the equivalent of saying that
>> every lanugage will follow the same compositional rules.
>>  
>> 
>> Another possible solution (probably better then the
>> one above since it
>> just removes the problem) is to remove the ":" and
>> have the cell borders
>> in a different color, just like the tables in the
>> "board setup" dialog
>> (so that you can also take a look at that code to
>> solve also the color
>> problem seeing how it was solved there). The
>> advantage of this approach
>> is also having a more consistent "look" through all
>> the dialogs.
>> 
>> 
>> 
>> P.S. (a little bit off-topic):
>> If you move the statistic window and check/uncheck
>> one of the checkboxes
>> ("subctract holes" or "Exclude components...")
>> the window "jumps"

Re: [Kicad-developers] [PATCH] Board statistics dialog

[Mark Roszko]

Huh, looking at the statistics code, it actually tries and find the more
"detailed area" of a board based on any polygonal outline.
Is there any value in it this way? PCB manufacturing charges are generally
per-square area  because ultimately the price is on panel space you are
using.

On Sat, Jul 27, 2019 at 5:07 AM Diego Herranz 
wrote:

> I've been testing this dialog and I think it is a nice addition. Thanks!
>
> There seems to be something wrong with the area calculation, though. See
> image below:
> [image: area.png]
>
> Thanks,
> Diego
>
> On Tue, 23 Jul 2019 at 11:18, Ian McInerney 
> wrote:
>
>> Alexander,
>>
>> Instead of declaring the 2 static variables separately, I would suggest
>> creating a struct for the settings then store that as the static variable.
>> For an example of this see the dialog_create_array.cpp file. This way if
>> any new options must be added in the future, they can just be added to the
>> struct very easily.
>>
>> -Ian
>>
>> On Mon, Jul 22, 2019 at 9:39 PM Alexander Shuklin 
>> wrote:
>>
>>> Damn ><,
>>> don't use last patch, please.
>>> It doesn't count total vias amount. Use this one.
>>>
>>>
>>> Понедельник, 22 июля 2019, 22:14 +03:00 от Alexander Shuklin <
>>> jasura...@mail.ru>:
>>>
>>> Hi,
>>> thanks for sharing experience, as I never used that translations or
>>> wxWidgets before. And I have no idea where else could I get that
>>> information. ))
>>> So, there's the patch with vias information and some tiny improvements.
>>>
>>>
>>> Понедельник, 22 июля 2019, 13:34 +03:00 от Ian McInerney <
>>> ian.s.mciner...@ieee.org>:
>>>
>>>
>>>
>>> On Mon, Jul 22, 2019 at 11:03 AM Dino Ghilardi >> >
>>> wrote:
>>>
>>> Hi Alexander,
>>>
>>> One possible solution for the translation could be put the ":" in a
>>> different column of the table and right-align the field description text
>>> (so all the colons will be aligned). A rapid google search shown that in
>>> French and Vietnamese there should be a space before the colon, while in
>>> the rest of the world there is not, so having the translation for the
>>> ":" word seems to make sense. Also another question arises: Is there
>>> some language in which the colon should be another character before the
>>> word? (I'm thinking about spanish where the question mark upside-down
>>> appears before a question...)? ...conclusion: keeping "Height:" and
>>> "Height" as two different words seem to be the solution that gives
>>> maximum flexibility to translators.
>>>
>>>
>>> This actually doesn't give them as much flexibility. When translations
>>> are done, they need to examine the entire string that needs translating, so
>>> the ":" character should be included in the string. Separating out the two
>>> portions is the equivalent of saying that every lanugage will follow the
>>> same compositional rules.
>>>
>>>
>>> Another possible solution (probably better then the one above since it
>>> just removes the problem) is to remove the ":" and have the cell borders
>>> in a different color, just like the tables in the "board setup" dialog
>>> (so that you can also take a look at that code to solve also the color
>>> problem seeing how it was solved there). The advantage of this approach
>>> is also having a more consistent "look" through all the dialogs.
>>>
>>>
>>>
>>> P.S. (a little bit off-topic):
>>> If you move the statistic window and check/uncheck one of the checkboxes
>>> ("subctract holes" or "Exclude components...") the window "jumps" to
>>> the center of the screen (its default position on open): do you have
>>> also this behaviour or it is just on my debian-linux with gtk3?
>>>
>>>
>>> Cheers,
>>> Dino.
>>>
>>> On 22/07/19 10:13, Alexander Shuklin wrote:
>>> > Hi!
>>> > I'll have a look to add vias count to dialog.
>>> > There's some questions:
>>> >
>>> > 1)I don't have too much experience with wxdialogs. There was commit on
>>> > master, which says:
>>> >  >> remove settings for fg/bg color: the result is unpredictable: was
>>> > black texts on black background on my computer.
>>> > And now I have all tables with data just in white boxes. Is it how it
>>> > meant to be, or just some misbehavior on different systems? I use
>>> > archlinux x64 OS.
>>> > there's screenshot in attachment
>>> >
>>> > 2) Can we use something like _( "Height" ) + ":" for translation, not
>>> _(
>>> > "Height:" )? As far as I understand, now we will need to have 2
>>> > translations, first for "Height" and second for "Height:" but that's
>>> > basically same word.
>>> >
>>> > Воскресенье, 21 июля 2019, 23:42 +03:00 от Dino Ghilardi
>>> > >> >:
>>> >
>>> > Makes sense.
>>> > Instead of a generic "via count" a more complete table similar to
>>> the
>>> > one generated in the drill report file could be useful, but may be
>>> it
>>> > can became quite long if a lot of different drill sizes are used

Re: [Kicad-developers] [PATCH] Board statistics dialog

[Alexander Shuklin]

Here you are)

>Воскресенье, 28 июля 2019, 19:28 +03:00 от jp charras :
>
>Le 24/07/2019 à 14:52, Alexander Shuklin a écrit :
>> Hi Ian,
>> Sorry for delay, also I added feature to save statistics in txt file, as
>> Dino suggested.
>> 
>> -- 
>> Alexander Shuklin
>> 
>
>Hi Alexander,
>
>I just committed your patch.
>Thanks.
>
>
>-- 
>Jean-Pierre CHARRAS
>
>___
>Mailing list:  https://launchpad.net/~kicad-developers
>Post to :  kicad-developers@lists.launchpad.net
>Unsubscribe :  https://launchpad.net/~kicad-developers
>More help   :  https://help.launchpad.net/ListHelp


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