Re: [Kicad-developers] UI changes for 5.0?

[Maciej Sumiński]

On 02/09/2018 08:00 AM, Marco Ciampa wrote:
> On Fri, Feb 09, 2018 at 07:34:41AM +0100, Carsten Schoenert wrote:
>> Am 09.02.2018 um 01:54 schrieb Wayne Stambaugh:
>>> For the libs, docs, and translations, I'm ok if we hold off tagging 
>>> until the stable release if that works for you.
>>
>> Correct as this needs to be done by the respective sub parts like the
>> documentation or library team(s).
> 
> I agree.
> 
> Please consider that there are documenters that have just updated some
> screenshots and so they probably will have to update some more because
> of these UI changes.

The changes proposed by Jeff are not that disruptive. It is just adding
'...' or changing Cancel->Close, so I guess it is not a big deal for the
users. Obviously it is better to have pictures showing dialogs and menus
exactly as you find them in the software, but I suppose nobody will even
notice that a button is labeled 'Close' instead of 'Cancel'.

Regards,
Orson

> Normally at some point (usually at an -rc stage) the developer(s)
> (Wayne?) declare a "string freeze" to signal translators and documenters
> to "dig in", giving a couple of weeks or more to let them finish before
> the ufficial release.
> 
> TIA
> 
> Best regards,
> 
> --
> 
> 
> Marco Ciampa
> 
> I know a joke about UDP, but you might not get it.
> 
> 
> 
>  GNU/Linux User #78271
>  FSFE fellow #364
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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

Re: [Kicad-developers] UI changes for 5.0?

[Marco Ciampa]

On Fri, Feb 09, 2018 at 07:34:41AM +0100, Carsten Schoenert wrote:
> Am 09.02.2018 um 01:54 schrieb Wayne Stambaugh:
> > For the libs, docs, and translations, I'm ok if we hold off tagging 
> > until the stable release if that works for you.
> 
> Correct as this needs to be done by the respective sub parts like the
> documentation or library team(s).

I agree.

Please consider that there are documenters that have just updated some
screenshots and so they probably will have to update some more because
of these UI changes.

Normally at some point (usually at an -rc stage) the developer(s)
(Wayne?) declare a "string freeze" to signal translators and documenters
to "dig in", giving a couple of weeks or more to let them finish before
the ufficial release.

TIA

Best regards,

--


Marco Ciampa

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



 GNU/Linux User #78271
 FSFE fellow #364




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

Re: [Kicad-developers] Another performance patch....

[Carsten Schoenert]

Am 09.02.2018 um 01:35 schrieb Jeff Young:
> Ping.
> 
> Any thoughts on patching wxWidgets for other platforms?

If you are talking about other Linux platforms then please do this in a
way the user hasn't to deal with changes to system folders, this isn't
really possible nor usable on systems which using package managers for
dealing with installed software. And I know only LFS (Linux from
Scratch) which hasn't a package manager.

And, please upstream any changes, if upstream don't want to accept your
changes they probably have strong and good reasons to not apply your
changes (at least for this specific released version).

-- 
Regards
Carsten Schoenert

___
Mailing list: https://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 changes for 5.0?

[Carsten Schoenert]

Am 09.02.2018 um 01:54 schrieb Wayne Stambaugh:
>> If you want to tag rc1 this weekend, should we tag the libs as well?

Absolutely! Don't make the life of distributions and packagers more
complicated than needed.

There was a interesting talk on FOSDEM about how to make releases right
(in terms of "No, please don't do it this way."), the content isn't new
but sometimes it's good to look at this all from a sarcastic view.

https://fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/

>> Should we limit changes to the lib from that point on until the final 
>> stable release or can we still make larger improvements in that 
>> timeframe? (For example there is the idea to add pin numbers for the 
>> mechanical mounting pins of connectors which would require renaming of 
>> footprints to allow better footprint filters.)
> 
> For the libs, docs, and translations, I'm ok if we hold off tagging 
> until the stable release if that works for you.

Correct as this needs to be done by the respective sub parts like the
documentation or library team(s).

> For rc releases, we can just package these items as they stand at the
> moment.
Also correct, 'rc' means nothing other then this is a release candidate,
not to be considered as a final and stable release. But build tools an
chains need to be tested and improved, workflows needs to be adopted to
new versions or used tools ...

> I would not let this drag on too long.  KiCad is in pretty good shape
> so I'm hoping for a shorter rc period before the stable release than
> we typically have. Of course this all depends on how quickly we can
> fix any critical bugs that show up during the rc period.
It's no shame to build more than one RC candidate and gives
distributions also the chance to get better in touch with the new
version and also increases the chance to get more feedback from people
how are impossible or don't want to build the software by themselves.

-- 
Regards
Carsten Schoenert

___
Mailing list: https://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 changes for 5.0?

[Wayne Stambaugh]

On 02/08/2018 07:47 PM, Rene Pöschl wrote:

On 09/02/18 01:28, Wayne Stambaugh wrote:

Assuming this can be completed in a reasonable amount of time and it is
consistent then I'm fine with this going into v5.  This is just cosmetic
and isn't going to break anything.  I've got a few more patches to
review and some work of my own to finish up over the weekend so I would
like to create the v5 branch and tag rc1 over the weekend unless there
are any outstanding crash bugs that I missed.  We can do cosmetic stuff
right up to the stable release.



If you want to tag rc1 this weekend, should we tag the libs as well?

Should we limit changes to the lib from that point on until the final 
stable release or can we still make larger improvements in that 
timeframe? (For example there is the idea to add pin numbers for the 
mechanical mounting pins of connectors which would require renaming of 
footprints to allow better footprint filters.)


For the libs, docs, and translations, I'm ok if we hold off tagging 
until the stable release if that works for you.  For rc releases, we can 
just package these items as they stand at the moment.  I would not let 
this drag on too long.  KiCad is in pretty good shape so I'm hoping for 
a shorter rc period before the stable release than we typically have. 
Of course this all depends on how quickly we can fix any critical bugs 
that show up during the rc period.


___
Mailing list: https://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 changes for 5.0?

[Rene Pöschl]

On 09/02/18 01:28, Wayne Stambaugh wrote:

Assuming this can be completed in a reasonable amount of time and it is
consistent then I'm fine with this going into v5.  This is just cosmetic
and isn't going to break anything.  I've got a few more patches to
review and some work of my own to finish up over the weekend so I would
like to create the v5 branch and tag rc1 over the weekend unless there
are any outstanding crash bugs that I missed.  We can do cosmetic stuff
right up to the stable release.



If you want to tag rc1 this weekend, should we tag the libs as well?

Should we limit changes to the lib from that point on until the final 
stable release or can we still make larger improvements in that 
timeframe? (For example there is the idea to add pin numbers for the 
mechanical mounting pins of connectors which would require renaming of 
footprints to allow better footprint filters.)




___
Mailing list: https://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] Another performance patch....

[Jeff Young]

Ping.Any thoughts on patching wxWidgets for other platforms?On 6 Feb 2018, at 14:08, Jeff Young  wrote:I accidentally dropped the dev list off the last few replies.  They included an update which fixed the issue Seth hypothesised.But I’m updating it one more time because, well, I made it faster again.There are two patches this time: the updated Kicad patch which knocks yet another 1/4 second off both first- and subsequent-times, and a wxWidgets patch which when combined with the Kicad patch brings the subsequent-time to near-instantaneous.Since we maintain our own Mac wxWidgets there’s no reason not to get the full benefit there.  I’ll leave it up to others to decide whether to include the wxWidgets patch for other platforms.(Note: while the two patches are dependent on each other for the final performance gain, they are not dependent on each other for compiling/linking/running.)Cheers,Jeff.

0004-Performance-fixes-for-the-place-footprint-list-all-d.patch
Description: Binary data
  

0005-Block-add-mode-for-lists.patch
Description: Binary data
On 5 Feb 2018, at 22:48, Jeff Young  wrote:I think I must be having a thick moment, because I’m still not following you.If I create a new library in the Footprint Editor and save it to a new location, then those components won’t be immediately available in Place Footprint until the library location is added to the Footprint Library Table, right?Or am I completely missing something?Cheers,Jeff.On 5 Feb 2018, at 22:17, Wayne Stambaugh  wrote:On 02/05/2018 05:08 PM, Jeff Young wrote:Hi Wayne,Do you mean if I use a text editor to modify a module file while KiCad is running, will KiCad notice and reload it?  The answer is yes.  The checksum is generated as a hash of the disk directory last-modified dates; the lib-table only tells it what the current libraries are.A text editor is one use case but the footprint library editor can also save an entire library file without going through the fp-lib-table so it's important that we don't break this behavior.  I may have missed this as I am sitting in Montreal airport after missing my connection with no sleep, a nasty case of jet lag, and an inbox that is sprialing out of control so I may have just overlooked it.Nice talk at FOSDEM, by the way.  Do we all get t-shirts? ;)Maybe one of these days I'll get around to some KiCad apparel of some type to give out to the dev team.  Although I don't think you should depend on my lack of graphics skills to design anything. :)Cheers,WayneCheers,Jeff.PS: updated patch attached to fix the issue Seth discovered (hypothesised?).On 5 Feb 2018, at 21:59, Wayne Stambaugh  wrote:What happens when footprint library file is modified outside the fp-lib-table?  At one point you could change the footprint library file without performing the file write through the fp-lib-table and the next time you accessed the library, it would recognize the file was modified and reload the cache.  Please make sure this behavior is not broken.On 02/05/2018 04:51 PM, Jeff Young wrote:wxWidgets should return Now() which will make the checksums not match and trigger a reload.Of course what actually happens is that wxWidgets asserts. ;)New patch on the way….Cheers,Jeff.On 5 Feb 2018, at 21:42, Seth Hillbrand > wrote:Jeff-Will removing a footprint library trigger a refresh?  Or will that mess up the checksum calculation?-S2018-02-05 13:04 GMT-08:00 Jeff Young >:   This one for Place Footprint (specifically the List All dialog   found therein).   On my machine it knocks the first-use time from 4s to 3s and the   subsequent-use time from 2.5s to 1s.   Cheers,   Jeff.   ___   Mailing list: https://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-developersPost to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developersMore help   : https://help.launchpad.net/ListHelp___Mailing list: https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.netUnsubscribe : https://launchpad.net/~kicad-developersMore help   : https://help.launchpad.net/ListHelp___Mailing list: https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.netUnsubscribe : https://launchpad.net/~kicad-developersMore help   : 

Re: [Kicad-developers] UI changes for 5.0?

[Wayne Stambaugh]

Assuming this can be completed in a reasonable amount of time and it is 
consistent then I'm fine with this going into v5.  This is just cosmetic 
and isn't going to break anything.  I've got a few more patches to 
review and some work of my own to finish up over the weekend so I would 
like to create the v5 branch and tag rc1 over the weekend unless there 
are any outstanding crash bugs that I missed.  We can do cosmetic stuff 
right up to the stable release.


On 02/08/2018 07:15 PM, Jeff Young wrote:

We discussed doing two widespread UI changes:

1) Changing Cancel buttons to Close when they don’t really cancel.
2) Uniformly using ellipses in menus/buttons when a dialog will be brought up 
to collect more info.

I’m happy to do the legwork on either of these.  Do we want to do them for 5.0, 
or push them to 6.0?

Cheers,
Jeff.
___
Mailing list: https://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] Zone fill hangup - more info

[Tomasz Wlostowski]

On 08/02/18 22:47, Steven A. Falco wrote:
> On 02/08/2018 04:28 PM, Tomasz Wlostowski wrote:
>> On 08/02/18 21:15, Steven A. Falco wrote:
>>> I continue to have problems performing a zone fill with the latest kicad 5 
>>> builds.  A copy of the project that is causing me trouble is here:

Thanks. Do you have (by any chance) a vanilla image of this VM?

Tom
>>>
>>> https://www.dropbox.com/sh/lw7lhg7jyigvyi7/AAB0ALAWmYS2LmOlw7-spqP6a?dl=0
>>
>> Steve,
>>
>> 3 quick questions:
>> - does your system support OpenMP?
>> - are the VMs running single core CPUs?
>> - could you post a stack trace of the hanged pcbnew process?
>>
>> Cheers,
>> Tom
>>
> 
> For the fedora VM, I think OpenMP is supported.  Here is a little part of the 
> log file from when I built the image.  Apparently, it finds OpenMP version 
> 4.5:
> 
> -- Performing Test COMPILER_SUPPORTS_WSHADOW - Success
> -- Found OpenMP_C: -fopenmp (found version "4.5") 
> -- Found OpenMP_CXX: -fopenmp (found version "4.5") 
> -- Found OpenMP: TRUE (found version "4.5")  
> -- Found wxWidgets: 
> -pthread;;;-lwx_gtk2u_gl-3.0-gtk2;-lwx_gtk2u_aui-3.0-gtk2;-lwx_gtk2u_adv-3.0-gtk2;-lwx_gtk2u_html-3.0-gtk2;-lwx_gtk2u_core-3.0-gtk2;-lwx_baseu_net-3.0-gtk2;-lwx_baseu-3.0-gtk2;-lwx_baseu_xml-3.0-gtk2;-lwx_gtk2u_stc-3.0-gtk2
>  (found suitable version "3.0.2", minimum required is "3.0.0") 
> -- Found OpenGL: /usr/lib64/libOpenGL.so
> 
> I don't know how to test Windows to see if it supports OpenMP.
> 
> The VMs are running with a single core allocated.  I could try the experiment 
> of allocating a second core, if it will give you more information.
> 
> Below is a stack trace.  I tried continuing and stopping a few times.  Each 
> time it seems to land in the same area.  ZONE_FILLER calls PROGRESS_REPORTER 
> calls wxMicroSleep.
> 
>   Thanks for looking at this,
>   Steve
> 
> fedora27$ gdb pcbnew
> GNU gdb (GDB) Fedora 8.0.1-35.fc27
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from pcbnew...Reading symbols from /home/sfalco/pcbnew...(no 
> debugging symbols found)...done.
> (no debugging symbols found)...done.
> Missing separate debuginfos, use: dnf debuginfo-install 
> kicad-r11969.7ad436c7-nightlies.fc27.x86_64
> (gdb) run
> Starting program: /usr/bin/pcbnew 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Detaching after fork from child process 2005.
> Detaching after fork from child process 2007.
> Detaching after fork from child process 2009.
> Detaching after fork from child process 2011.
> Detaching after fork from child process 2013.
> 04:38:41 PM: Debug: kiface SEARCH_STACK:
> 04:38:41 PM: Debug:   [ 0]:/usr/share/kicad/modules
> 04:38:41 PM: Debug:   [ 1]:/usr/share/kicad/modules/packages3d
> 04:38:41 PM: Debug:   [ 2]:/usr/share/kicad/template
> 04:38:41 PM: Debug:   [ 3]:/home/sfalco/kicad/template
> 04:38:41 PM: Debug:   [ 4]:/usr/local/share
> [New Thread 0x7fffd75cb700 (LWP 2015)]
> [New Thread 0x7fffcd272700 (LWP 2016)]
> [New Thread 0x7fffcca71700 (LWP 2017)]
> [Thread 0x7fffcd272700 (LWP 2016) exited]
> [New Thread 0x7fffcd272700 (LWP 2018)]
> [Thread 0x7fffcca71700 (LWP 2017) exited]
> [New Thread 0x7fffcca71700 (LWP 2019)]
> [Thread 0x7fffcd272700 (LWP 2018) exited]
> [New Thread 0x7fffcd272700 (LWP 2020)]
> [Thread 0x7fffcca71700 (LWP 2019) exited]
> ElemsClear: clearing all _ELEMS for project 
> SetProjectFullName: old:'' new:'/home/sfalco/kicad/new_weather/main/main.pro'
> 04:39:01 PM: Debug: Loading project 
> '/home/sfalco/kicad/new_weather/main/main.pro' settings.
> wxFrame 14PCB_EDIT_FRAME: disabled
> [Thread 0x7fffcd272700 (LWP 2020) exited]
> ^C
> Thread 1 "pcbnew" received signal SIGINT, Interrupt.
> 0x73931f50 in nanosleep () from /lib64/libpthread.so.0
> (gdb) bt
> #0  0x73931f50 in nanosleep () from /lib64/libpthread.so.0
> #1  0x76531cbc in wxMicroSleep(unsigned long) ()
>from /lib64/libwx_baseu-3.0-gtk2.so.0
> #2  0x7fffdfeff452 in PROGRESS_REPORTER::KeepRefreshing() ()
>from /usr/bin/_pcbnew.kiface
> #3  0x7fffdfbeef39 in ZONE_FILLER::Fill(std::vector std::allocator >) [clone ._omp_fn.0] () from 
> /usr/bin/_pcbnew.kiface
> #4  0x73d63cdf in GOMP_parallel () from /lib64/libgomp.so.1

Re: [Kicad-developers] Zone fill hangup - more info

[Steven A. Falco]

On 02/08/2018 04:28 PM, Tomasz Wlostowski wrote:
> On 08/02/18 21:15, Steven A. Falco wrote:
>> I continue to have problems performing a zone fill with the latest kicad 5 
>> builds.  A copy of the project that is causing me trouble is here:
>>
>> https://www.dropbox.com/sh/lw7lhg7jyigvyi7/AAB0ALAWmYS2LmOlw7-spqP6a?dl=0
> 
> Steve,
> 
> 3 quick questions:
> - does your system support OpenMP?
> - are the VMs running single core CPUs?
> - could you post a stack trace of the hanged pcbnew process?
> 
> Cheers,
> Tom
> 

For the fedora VM, I think OpenMP is supported.  Here is a little part of the 
log file from when I built the image.  Apparently, it finds OpenMP version 4.5:

-- Performing Test COMPILER_SUPPORTS_WSHADOW - Success
-- Found OpenMP_C: -fopenmp (found version "4.5") 
-- Found OpenMP_CXX: -fopenmp (found version "4.5") 
-- Found OpenMP: TRUE (found version "4.5")  
-- Found wxWidgets: 
-pthread;;;-lwx_gtk2u_gl-3.0-gtk2;-lwx_gtk2u_aui-3.0-gtk2;-lwx_gtk2u_adv-3.0-gtk2;-lwx_gtk2u_html-3.0-gtk2;-lwx_gtk2u_core-3.0-gtk2;-lwx_baseu_net-3.0-gtk2;-lwx_baseu-3.0-gtk2;-lwx_baseu_xml-3.0-gtk2;-lwx_gtk2u_stc-3.0-gtk2
 (found suitable version "3.0.2", minimum required is "3.0.0") 
-- Found OpenGL: /usr/lib64/libOpenGL.so

I don't know how to test Windows to see if it supports OpenMP.

The VMs are running with a single core allocated.  I could try the experiment 
of allocating a second core, if it will give you more information.

Below is a stack trace.  I tried continuing and stopping a few times.  Each 
time it seems to land in the same area.  ZONE_FILLER calls PROGRESS_REPORTER 
calls wxMicroSleep.

Thanks for looking at this,
Steve

fedora27$ gdb pcbnew
GNU gdb (GDB) Fedora 8.0.1-35.fc27
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from pcbnew...Reading symbols from /home/sfalco/pcbnew...(no 
debugging symbols found)...done.
(no debugging symbols found)...done.
Missing separate debuginfos, use: dnf debuginfo-install 
kicad-r11969.7ad436c7-nightlies.fc27.x86_64
(gdb) run
Starting program: /usr/bin/pcbnew 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Detaching after fork from child process 2005.
Detaching after fork from child process 2007.
Detaching after fork from child process 2009.
Detaching after fork from child process 2011.
Detaching after fork from child process 2013.
04:38:41 PM: Debug: kiface SEARCH_STACK:
04:38:41 PM: Debug:   [ 0]:/usr/share/kicad/modules
04:38:41 PM: Debug:   [ 1]:/usr/share/kicad/modules/packages3d
04:38:41 PM: Debug:   [ 2]:/usr/share/kicad/template
04:38:41 PM: Debug:   [ 3]:/home/sfalco/kicad/template
04:38:41 PM: Debug:   [ 4]:/usr/local/share
[New Thread 0x7fffd75cb700 (LWP 2015)]
[New Thread 0x7fffcd272700 (LWP 2016)]
[New Thread 0x7fffcca71700 (LWP 2017)]
[Thread 0x7fffcd272700 (LWP 2016) exited]
[New Thread 0x7fffcd272700 (LWP 2018)]
[Thread 0x7fffcca71700 (LWP 2017) exited]
[New Thread 0x7fffcca71700 (LWP 2019)]
[Thread 0x7fffcd272700 (LWP 2018) exited]
[New Thread 0x7fffcd272700 (LWP 2020)]
[Thread 0x7fffcca71700 (LWP 2019) exited]
ElemsClear: clearing all _ELEMS for project 
SetProjectFullName: old:'' new:'/home/sfalco/kicad/new_weather/main/main.pro'
04:39:01 PM: Debug: Loading project 
'/home/sfalco/kicad/new_weather/main/main.pro' settings.
wxFrame 14PCB_EDIT_FRAME: disabled
[Thread 0x7fffcd272700 (LWP 2020) exited]
^C
Thread 1 "pcbnew" received signal SIGINT, Interrupt.
0x73931f50 in nanosleep () from /lib64/libpthread.so.0
(gdb) bt
#0  0x73931f50 in nanosleep () from /lib64/libpthread.so.0
#1  0x76531cbc in wxMicroSleep(unsigned long) ()
   from /lib64/libwx_baseu-3.0-gtk2.so.0
#2  0x7fffdfeff452 in PROGRESS_REPORTER::KeepRefreshing() ()
   from /usr/bin/_pcbnew.kiface
#3  0x7fffdfbeef39 in ZONE_FILLER::Fill(std::vector >) [clone ._omp_fn.0] () from 
/usr/bin/_pcbnew.kiface
#4  0x73d63cdf in GOMP_parallel () from /lib64/libgomp.so.1
#5  0x7fffdfbecbac in ZONE_FILLER::Fill(std::vector >) () from /usr/bin/_pcbnew.kiface
#6  0x7fffdfc52174 in ZONE_FILLER_TOOL::ZoneFillAll(TOOL_EVENT const&) ()
   from /usr/bin/_pcbnew.kiface
#7  0x7fffdffc9b80 in COROUTINE

Re: [Kicad-developers] Zone fill hangup - more info

[Tomasz Wlostowski]

On 08/02/18 21:15, Steven A. Falco wrote:
> I continue to have problems performing a zone fill with the latest kicad 5 
> builds.  A copy of the project that is causing me trouble is here:
> 
> https://www.dropbox.com/sh/lw7lhg7jyigvyi7/AAB0ALAWmYS2LmOlw7-spqP6a?dl=0

Steve,

3 quick questions:
- does your system support OpenMP?
- are the VMs running single core CPUs?
- could you post a stack trace of the hanged pcbnew process?

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] Pads front and F.Cu visibility, possible bugs?

[Kevin Cozens]

On 2018-02-08 07:02 AM, kristoffer Ödmark wrote:
for example, disbling rendering of front footprints disables all the F.Silk, 
F.Fab, adhesive and many more.


Disabling the rendering of Text on the front only disables text belonging to 
a footprint, no other. Basically the Render tab does not do what it says at 
all.


A lot of this seems to because of what is set in pcb_draw_panel_gal.cpp:417

There is a lot of SetRequired-> (layer, layer)

And that implementation seems broken, could someone shed some light on the 
purpose there?
Is turning layers on and off being done partly through some automatic 
feature of GAL? If so, and it appears it can't handle all the situations 
possible when turning on/off layers in the right-hand side options extra 
code could be added to turn on/off appropriate layers or features based 
after a change is made to the layer/feature visibility options.


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

Re: [Kicad-developers] Pads front and F.Cu visibility, possible bugs?

[Wayne Stambaugh]

I think it has been mentioned before about potentially creating user
defined visibility settings that could be added to the layer manager
context menu.  I'm guessing that we would have to rework some of the
underlying code to make this possible.  It's definitely something to
keep in mind for future versions but I don't think this is going to
happen in time for v5.

Cheers,

Wayne

On 2/8/2018 9:53 AM, Maciej Sumiński wrote:
> As you noticed, one can only define simple layer visibility dependencies
> in GAL using SetRequired() method. Effectively, you can quickly disable
> a whole layer when another is invisible, but it does not handle well
> cases of e.g. texts whose visibility should depend both on the layer and
> the parent object visibility.
> 
> Perhaps we should define visibility rules per class and not per layer,
> so we can check additional conditions.
> 
> Regards,
> Orson
> 
> On 02/08/2018 01:02 PM, kristoffer Ödmark wrote:
>> I started investigating this some more, there is much more rendering
>> problems here.
>>
>> for example, disbling rendering of front footprints disables all the
>> F.Silk, F.Fab, adhesive and many more.
>>
>> Disabling the rendering of Text on the front only disables text
>> belonging to a footprint, no other. Basically the Render tab does not do
>> what it says at all.
>>
>> A lot of this seems to because of what is set in pcb_draw_panel_gal.cpp:417
>>
>> There is a lot of SetRequired-> (layer, layer)
>>
>> And that implementation seems broken, could someone shed some light on
>> the purpose there?
>>
>>
>> On 2018-02-07 22:32, Kevin Cozens wrote:
>>> On 2018-02-07 04:25 PM, Wayne Stambaugh wrote:
> If you use legacy renderer then turn off Pads Front and Pads Back under
> the Render tab on the right the pads disappear. If you are in GAL mode
> they remain visible.
>

 Given that the legacy canvas will hopefully be removed in the v6
 development cycle, I guess this issue will go away.
>>>
>>> True, but I wanted to point out that as far as I was concerned it
>>> hasn't always been this way. I would still expect the pads to
>>> disappear if I turn off display of front and back pads.
>>>
>>> [Oops. Sending again as I meant to send it to the list.]
>>>
>>
>>
>> ___
>> Mailing list: https://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] Zone fill hangup - more info

[Steven A. Falco]

I continue to have problems performing a zone fill with the latest kicad 5 
builds.  A copy of the project that is causing me trouble is here:

https://www.dropbox.com/sh/lw7lhg7jyigvyi7/AAB0ALAWmYS2LmOlw7-spqP6a?dl=0

I can reproduce the problem on both a Windows 10 VM, running 
kicad-r9376.be70ce7d4-x86_64.exe (the latest nightly from Feb 8), and on a 
Linux Fedora rawhide VM, running kicad-r11994.17ce87a-nightlies.fc28.x86_64.rpm 
(the latest from Copr, dated Feb 7).  Both VMs are hosted on the same server, 
which runs Fedora 27.

On both virtual machines, I get the "Fill All Zones" dialog, with the message 
"Calculating zone fills...".  The progress bar does nothing, and the elapsed 
time counter is stuck at 0:00:00.  When this happens, all I can do is kill 
kicad.  The "cancel" button doesn't work (although it does turn gray when I 
click it).

Since others have not seen this problem, I guess it is peculiar to my 
environment, but I was able to run an earlier kicad 5 build (4bf90f97171) on a 
Fedora 27 VM.  Any build newer than 4bf90f97171 shows the same zone hangup bug. 
 In particular, 7ad436c7aae, the very next commit after 4bf90f97171, shows the 
bug, and is apparently the commit that causes the problem.

Please let me know if there is any additional information I can provide.

Steve



___
Mailing list: https://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] Driving the pcbnew UI from python

[Wayne Stambaugh]

Tom,

Did answering your question resolve the questions you asked below?  I
apologize for being brief but I'm really busy trying to get a new stable
release of KiCad out so please be patient.

Wayne

On 2/4/2018 11:48 AM, Tom Cook wrote:
> Hello,
> 
> I'm developing a small Python application for tracking component
> inventory & to help when assembling boards.  I'd like to be able to
> display a portion of the board layout with a particular component
> centred.  This could either be in my application window or in a separate
> window, I'm not too worried which.  The display doesn't necessarily need
> to be interactive, though the ability to pan & zoom would be nice to have.
> 
> What's the most straightforward way to do this in pcbnew currently?
> 
> I can see three possibilities:
> 
> 1.  I think it's possible to launch pcbnew as a separate process and
> send it messages to focus a particular component through KiWay.  Could
> someone confirm that this is possible in a separate process and perhaps
> point me towards some documentation or example code for how to do this
> in python.
> 
> 2.  I think it's possible for a python process to be the 'top' for
> pcbnew - so I should be able to load pcbnew in my python process and
> display the UI and send it in-process KiWay messages.  Could someone
> confirm that this is possible and again perhaps point me towards
> documentation or examples?
> 
> 3.  I'm not sure if it's possible to load a board using the python
> pcbnew.LoadBoard() and then render a portion of it in-memory, which I
> could then display in my application.  Is this possible?
> 
> Thanks for any help,
> Tom Cook
> 
> 
> ___
> Mailing list: https://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] [Kicad-doc-devs] string change proposal

[Wayne Stambaugh]

KiCad uses the system default association when opening a text or pdf
file from within KiCad unless you explicitly change it.  I would think
most users are aware that the system already has a default app
associated with text and pdf files.  The KiCad option is to use
something other than the system default so the wording should say
something to that affect.

On 2/8/2018 12:51 PM, Jeff Young wrote:
> Do all our platforms have an OS default?  If so, I agree: nuke the
> setting entirely.
> 
>> On 8 Feb 2018, at 17:42, Andrey Kuznetsov > > wrote:
>>
>> We agree, good job, 24->0 words!
>> No need to specify something that's already been set system wide.
>>
>> On Thu, Feb 8, 2018 at 8:06 AM, Andy Peters > > wrote:
>>
>>
>>> On Feb 8, 2018, at 3:42 AM, Jeff Young >> > wrote:
>>>
>>> > … or "Set default text editor and PDF viewer programs to open files 
>>> from KiCad”
>>>
>>> +1
>>
>> One could interpret “open files from KiCad” as being “Open files
>> created by KiCad.”
>>
>> The point I was trying to make, and perhaps wasn’t clear on, is
>> that applications should never modify operating-system defaults
>> that affect other applications. Thus saying “open files from
>> (within) KiCad” is unnecessary, as it is understood that this
>> setting affects performing this operation from within Kicad only.
>>
>> I suppose, further, that this whole thing about choosing which PDF
>> viewer and which text editor to use is completely unnecessary. Why
>> _wouldn’t_ KiCad open text files in the OS default text editor?
>> Why _wouldn’t_ you want it to open PDF files in the OS default PDF
>> viewer? I set those defaults in the OS for a reason, and I expect
>> applications to uses those defaults.
>>
>> -a
>>
>>
>>
>>
>>>
>>>
 On 8 Feb 2018, at 10:15, Andrey Kuznetsov > wrote:

 Wow, that sentence is unnecessarily long.

 By rephrasing, you can cut that text in half. Also, why is text
 editor and PDF viewer in the same context? Default text editor
 and default PDF viewer do not open the same files, is this a
 context for a Group where those 2 are defined, weird...

 Telling the user that he "may define" a"Default Text Editor" is
 redundant, same for favorite, default is better, that's what is
 seen across many programs, you define a default program to open
 files, you don't define a favorite program. "These settings"
 redundant because you are in a settings editor window, duhh. 

 How about "Set default text editor and PDF viewer programs"?

 If you want to be more explicit: "Set default text editor and
 PDF viewer programs for use by KiCad" or "Set default text
 editor and PDF viewer programs to open files from KiCad"

 On Wed, Feb 7, 2018 at 8:23 AM, Andy Peters > wrote:



 > On Feb 7, 2018, at 5:09 AM, Marco Ciampa
 > wrote:
 >
 > Hello,
 > I am not a native english,

 Your English is better than my Italian!

 > so I think it is better to ask even for small phrases:
 >
 > Here:
 >
 > #. type: Plain text
 > #: kicad.adoc:246
 > msgid ""
 > "You may define your favorite text editor and PDF viewer.
 These settings are "
 > "used whenever you want to open a text or PDF file."
 >
 > I would have written it in a more esplicit way like:
 >
 > "You may define your favorite text editor and PDF viewer.
 These settings are "
 > "used by KiCad whenever you want to open a text or PDF
 file from the inside "
 > "of any of the KiCad tools."
 >
 > Comments?

 In general, I’m a fan of being as explicit and clear as
 possible. But, in this case, I think the user should be
 aware that s/he’s setting something from within Kicad, and
 as such that setting is only relevant when interacting with
 a Kicad tool.

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

Re: [Kicad-developers] [Kicad-doc-devs] string change proposal

[Jeff Young]

Do all our platforms have an OS default?  If so, I agree: nuke the setting 
entirely.

> On 8 Feb 2018, at 17:42, Andrey Kuznetsov  wrote:
> 
> We agree, good job, 24->0 words!
> No need to specify something that's already been set system wide.
> 
> On Thu, Feb 8, 2018 at 8:06 AM, Andy Peters  > wrote:
> 
>> On Feb 8, 2018, at 3:42 AM, Jeff Young > > wrote:
>> 
>> > … or "Set default text editor and PDF viewer programs to open files from 
>> > KiCad”
>> 
>> +1
> 
> One could interpret “open files from KiCad” as being “Open files created by 
> KiCad.”
> 
> The point I was trying to make, and perhaps wasn’t clear on, is that 
> applications should never modify operating-system defaults that affect other 
> applications. Thus saying “open files from (within) KiCad” is unnecessary, as 
> it is understood that this setting affects performing this operation from 
> within Kicad only.
> 
> I suppose, further, that this whole thing about choosing which PDF viewer and 
> which text editor to use is completely unnecessary. Why _wouldn’t_ KiCad open 
> text files in the OS default text editor? Why _wouldn’t_ you want it to open 
> PDF files in the OS default PDF viewer? I set those defaults in the OS for a 
> reason, and I expect applications to uses those defaults.
> 
> -a
> 
> 
> 
> 
>> 
>> 
>>> On 8 Feb 2018, at 10:15, Andrey Kuznetsov >> > wrote:
>>> 
>>> Wow, that sentence is unnecessarily long.
>>> 
>>> By rephrasing, you can cut that text in half. Also, why is text editor and 
>>> PDF viewer in the same context? Default text editor and default PDF viewer 
>>> do not open the same files, is this a context for a Group where those 2 are 
>>> defined, weird...
>>> 
>>> Telling the user that he "may define" a"Default Text Editor" is redundant, 
>>> same for favorite, default is better, that's what is seen across many 
>>> programs, you define a default program to open files, you don't define a 
>>> favorite program. "These settings" redundant because you are in a settings 
>>> editor window, duhh. 
>>> 
>>> How about "Set default text editor and PDF viewer programs"?
>>> 
>>> If you want to be more explicit: "Set default text editor and PDF viewer 
>>> programs for use by KiCad" or "Set default text editor and PDF viewer 
>>> programs to open files from KiCad"
>>> 
>>> On Wed, Feb 7, 2018 at 8:23 AM, Andy Peters >> > wrote:
>>> 
>>> 
>>> > On Feb 7, 2018, at 5:09 AM, Marco Ciampa >> > > wrote:
>>> >
>>> > Hello,
>>> > I am not a native english,
>>> 
>>> Your English is better than my Italian!
>>> 
>>> > so I think it is better to ask even for small phrases:
>>> >
>>> > Here:
>>> >
>>> > #. type: Plain text
>>> > #: kicad.adoc:246
>>> > msgid ""
>>> > "You may define your favorite text editor and PDF viewer. These settings 
>>> > are "
>>> > "used whenever you want to open a text or PDF file."
>>> >
>>> > I would have written it in a more esplicit way like:
>>> >
>>> > "You may define your favorite text editor and PDF viewer. These settings 
>>> > are "
>>> > "used by KiCad whenever you want to open a text or PDF file from the 
>>> > inside "
>>> > "of any of the KiCad tools."
>>> >
>>> > Comments?
>>> 
>>> In general, I’m a fan of being as explicit and clear as possible. But, in 
>>> this case, I think the user should be aware that s/he’s setting something 
>>> from within Kicad, and as such that setting is only relevant when 
>>> interacting with a Kicad tool.
>>> 
>>> -a
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 
> 
> 
> 
> -- 
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss the future 
> [JFK]
> 
> kandre...@gmail.com 
> Live Long and Prosper,
> Andrey
> ___
> Mailing list: https://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] [Kicad-doc-devs] string change proposal

[Andrey Kuznetsov]

We agree, good job, 24->0 words!
No need to specify something that's already been set system wide.

On Thu, Feb 8, 2018 at 8:06 AM, Andy Peters  wrote:

>
> On Feb 8, 2018, at 3:42 AM, Jeff Young  wrote:
>
> > … or "Set default text editor and PDF viewer programs to open files from
> KiCad”
>
> +1
>
>
> One could interpret “open files from KiCad” as being “Open files created
> by KiCad.”
>
> The point I was trying to make, and perhaps wasn’t clear on, is that
> applications should never modify operating-system defaults that affect
> other applications. Thus saying “open files from (within) KiCad” is
> unnecessary, as it is understood that this setting affects performing this
> operation from within Kicad only.
>
> I suppose, further, that this whole thing about choosing which PDF viewer
> and which text editor to use is completely unnecessary. Why _wouldn’t_
> KiCad open text files in the OS default text editor? Why _wouldn’t_ you
> want it to open PDF files in the OS default PDF viewer? I set those
> defaults in the OS for a reason, and I expect applications to uses those
> defaults.
>
> -a
>
>
>
>
>
>
> On 8 Feb 2018, at 10:15, Andrey Kuznetsov  wrote:
>
> Wow, that sentence is unnecessarily long.
>
> By rephrasing, you can cut that text in half. Also, why is text editor and
> PDF viewer in the same context? Default text editor and default PDF viewer
> do not open the same files, is this a context for a Group where those 2 are
> defined, weird...
>
> Telling the user that he "may define" a"Default Text Editor" is redundant,
> same for favorite, default is better, that's what is seen across many
> programs, you define a default program to open files, you don't define a
> favorite program. "These settings" redundant because you are in a settings
> editor window, duhh.
>
> How about "Set default text editor and PDF viewer programs"?
>
> If you want to be more explicit: "Set default text editor and PDF viewer
> programs for use by KiCad" or "Set default text editor and PDF viewer
> programs to open files from KiCad"
>
> On Wed, Feb 7, 2018 at 8:23 AM, Andy Peters  wrote:
>
>>
>>
>> > On Feb 7, 2018, at 5:09 AM, Marco Ciampa  wrote:
>> >
>> > Hello,
>> > I am not a native english,
>>
>> Your English is better than my Italian!
>>
>> > so I think it is better to ask even for small phrases:
>> >
>> > Here:
>> >
>> > #. type: Plain text
>> > #: kicad.adoc:246
>> > msgid ""
>> > "You may define your favorite text editor and PDF viewer. These
>> settings are "
>> > "used whenever you want to open a text or PDF file."
>> >
>> > I would have written it in a more esplicit way like:
>> >
>> > "You may define your favorite text editor and PDF viewer. These
>> settings are "
>> > "used by KiCad whenever you want to open a text or PDF file from the
>> inside "
>> > "of any of the KiCad tools."
>> >
>> > Comments?
>>
>> In general, I’m a fan of being as explicit and clear as possible. But, in
>> this case, I think the user should be aware that s/he’s setting something
>> from within Kicad, and as such that setting is only relevant when
>> interacting with a Kicad tool.
>>
>> -a
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
Mailing list: https://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] Allow OpenCASCADE standard edition

[Seth Hillbrand]

Hi Thomas-

That makes sense.  The REGEX fails because you haven't installed
OpenCascade.  You've only built it.  When you install it,
Standard_Version.hxx will be correct and the REGEX will match.  In the
build directory, it only includes the header from the source directory.

I suspect (but haven't tested yet) that the library linking issue will also
be resolved by a full install.

-S

2018-02-08 9:10 GMT-08:00 Thomas Figueroa :

> I’ve attached the output from when I try to configure with the original
> file.
>
> The version checking didn’t work for 7.1 for me either. It should be
> noted, that
>
> I built OpenCascade from source, and I’ve tried to manually change it to
> point
>
> to the Standard_Version header, but it still doesn’t parse it correctly
> with the same
>
> error outputted.
>
>
>
> -Thomas
>
>
>
> *From:* Seth Hillbrand 
> *Sent:* Thursday, February 08, 2018 10:49 AM
> *To:* Thomas Figueroa 
>
> *Cc:* kicad-developers@lists.launchpad.net
> *Subject:* Re: [Kicad-developers] [PATCH] Allow OpenCASCADE standard
> edition
>
>
>
> Hi Thomas-
>
>
>
> I will add this library to the include.  Odd that it wasn't required on
> Linux.  Can you send me your CMakeOutput.log?  The version checking is
> pretty important and those files don't change, so I'd like to track down
> why it would work for 7.1 but not for 7.2.
>
>
>
> -S
>
>
>
> 2018-02-08 7:29 GMT-08:00 Thomas Figueroa :
>
> Hey Seth,
>
>
>
> Working great with OpenCascade 7.2! I had to modify the Cmake file, though,
>
> to include TKV3d in the library list. I get unresolved external link
> errors when compiling
>
> s3d_plugin_oce otherwise (unresolved symbols SelectMgr_Selection,
> PrsMgr_PresentableObject, and AIS_InteractiveObject respectively).
>
> I also had to remove the version checking, as it was unable to get the
> version via regex matching for some reason.
>
>
>
> -Thomas
>
>
>
>
>
> *From: *Seth Hillbrand 
> *Sent: *Tuesday, February 6, 2018 2:34 PM
> *To: *kicad-developers@lists.launchpad.net
>
>
> *Subject: *Re: [Kicad-developers] [PATCH] Allow OpenCASCADE standard
> edition
>
>
>
> I've updated this to allow use of OpenCascade 7.2 as well.
>
>
>
> Nick, I added a few more helpful error messages to CMake file.  Let me
> know if you are still seeing the configure error with a clean cmake.
>
>
>
> -Seth
>
>
>
> 2018-02-02 12:47 GMT-08:00 Thomas Figueroa :
>
> Hey Seth,
>
>
>
> I was able to successfully use OpenCascade 7.1 and export using kicad2step!
>
>
>
> Now to find out why…
>
>
>
> -Thomas
>
>
>
> *From: *Seth Hillbrand 
> *Sent: *Friday, February 2, 2018 11:10 AM
> *To: *Thomas Figueroa 
> *Cc: *kicad-developers@lists.launchpad.net
> *Subject: *Re: [Kicad-developers] [PATCH] Allow OpenCASCADE standard
> edition
>
>
>
> Hi Thomas-
>
>
>
> I located a windows machine to try this.  I suspect that this is an
> artifact of OpenCascade 7.2.  Can you test with OpenCascade 7.1?  I haven't
> tracked down exactly what changed in 7.2 but it appears that 7.0 and 7.1
> work but 7.2 will require additional work in kicad2step.
>
>
>
> Of note, OCCT 6.8 also works but 6.9 (and OCE 0.18, which is based on 6.9)
> do not work either.  This is due to a compiler optimization but appears to
> be a different issue than the 7.2 one.
>
>
>
> -Seth
>
>
>
>
>
>
>
> 2018-01-31 19:04 GMT-08:00 Thomas Figueroa :
>
> Hello Seth,
>
>
>
> I’ve had the opportunity to test this on Windows (MSVC, but I’ve had the
> same issue with MSYS2).
>
> STEP models work great in the 3D viewer, and in the footprint module
> editor, just as in OCE.
>
> Unfortunately, I cannot get the STEP export to work. I’ve had a run at
> using OpenCascade before
>
> and encountered this exact same issue. As an example, I’ve attached an
> outputted file.
>
> The following output is from the command line kicad2step:
>
>
>
> 20:31:07: C:\dev\kicad-personal\utils\kicad2step\pcb\oce_utils.cpp:
> fileType: 163
>
>   * no such file: ''
>
>
>
> 20:31:07: C:\dev\kicad-personal\utils\kicad2step\pcb\oce_utils.cpp:
> PCBMODEL::AddComponent: 574
>
>   * no model for filename for ‘’
>
>
>
> This repeats for every model. If you have any ideas, I’d be very willing
> to try them out.
>
>
>
> - Thomas
>
>
>
> *From:* Kicad-developers  hotmail@lists.launchpad.net> *On Behalf Of *Seth Hillbrand
> *Sent:* Monday, January 29, 2018 12:55 PM
> *To:* KiCad Developers 
> *Subject:* [Kicad-developers] [PATCH] Allow OpenCASCADE standard edition
>
>
>
> ​Hi All-
>
>
>
> Currently, the build requires the opencascade community edition.  For
> various reasons, I need to have the current non-community edition of
> OpenCASCADE installed on my work machine.
>
>
>
> The attached patch allows compiling KiCad 

Re: [Kicad-developers] [PATCH] Allow OpenCASCADE standard edition

[Thomas Figueroa]

I’ve attached the output from when I try to configure with the original file.
The version checking didn’t work for 7.1 for me either. It should be noted, that
I built OpenCascade from source, and I’ve tried to manually change it to point
to the Standard_Version header, but it still doesn’t parse it correctly with 
the same
error outputted.

-Thomas

From: Seth Hillbrand 
Sent: Thursday, February 08, 2018 10:49 AM
To: Thomas Figueroa 
Cc: kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] [PATCH] Allow OpenCASCADE standard edition

Hi Thomas-

I will add this library to the include.  Odd that it wasn't required on Linux.  
Can you send me your CMakeOutput.log?  The version checking is pretty important 
and those files don't change, so I'd like to track down why it would work for 
7.1 but not for 7.2.

-S

2018-02-08 7:29 GMT-08:00 Thomas Figueroa 
>:
Hey Seth,

Working great with OpenCascade 7.2! I had to modify the Cmake file, though,
to include TKV3d in the library list. I get unresolved external link errors 
when compiling
s3d_plugin_oce otherwise (unresolved symbols SelectMgr_Selection, 
PrsMgr_PresentableObject, and AIS_InteractiveObject respectively).
I also had to remove the version checking, as it was unable to get the version 
via regex matching for some reason.

-Thomas


From: Seth Hillbrand
Sent: Tuesday, February 6, 2018 2:34 PM
To: 
kicad-developers@lists.launchpad.net

Subject: Re: [Kicad-developers] [PATCH] Allow OpenCASCADE standard edition

I've updated this to allow use of OpenCascade 7.2 as well.

Nick, I added a few more helpful error messages to CMake file.  Let me know if 
you are still seeing the configure error with a clean cmake.

-Seth

2018-02-02 12:47 GMT-08:00 Thomas Figueroa 
>:
Hey Seth,

I was able to successfully use OpenCascade 7.1 and export using kicad2step!

Now to find out why…

-Thomas

From: Seth Hillbrand
Sent: Friday, February 2, 2018 11:10 AM
To: Thomas Figueroa
Cc: 
kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] [PATCH] Allow OpenCASCADE standard edition

Hi Thomas-

I located a windows machine to try this.  I suspect that this is an artifact of 
OpenCascade 7.2.  Can you test with OpenCascade 7.1?  I haven't tracked down 
exactly what changed in 7.2 but it appears that 7.0 and 7.1 work but 7.2 will 
require additional work in kicad2step.

Of note, OCCT 6.8 also works but 6.9 (and OCE 0.18, which is based on 6.9) do 
not work either.  This is due to a compiler optimization but appears to be a 
different issue than the 7.2 one.

-Seth



2018-01-31 19:04 GMT-08:00 Thomas Figueroa 
>:
Hello Seth,

I’ve had the opportunity to test this on Windows (MSVC, but I’ve had the same 
issue with MSYS2).
STEP models work great in the 3D viewer, and in the footprint module editor, 
just as in OCE.
Unfortunately, I cannot get the STEP export to work. I’ve had a run at using 
OpenCascade before
and encountered this exact same issue. As an example, I’ve attached an 
outputted file.
The following output is from the command line kicad2step:

20:31:07: C:\dev\kicad-personal\utils\kicad2step\pcb\oce_utils.cpp: fileType: 
163
  * no such file: ''

20:31:07: C:\dev\kicad-personal\utils\kicad2step\pcb\oce_utils.cpp: 
PCBMODEL::AddComponent: 574
  * no model for filename for ‘’

This repeats for every model. If you have any ideas, I’d be very willing to try 
them out.

- Thomas

From: Kicad-developers 
>
 On Behalf Of Seth Hillbrand
Sent: Monday, January 29, 2018 12:55 PM
To: KiCad Developers 
>
Subject: [Kicad-developers] [PATCH] Allow OpenCASCADE standard edition

​Hi All-

Currently, the build requires the opencascade community edition.  For various 
reasons, I need to have the current non-community edition of OpenCASCADE 
installed on my work machine.

The attached patch allows compiling KiCad with either the OpenCASCADE community 
edition or standard edition.

I've tested on a homebrew-based Mac install as well as Linux but haven't 
verified MSW, if someone would be willing to test it there, that would be 
great!  The basic search routines are lightly modified from FreeCAD's logic and 
keep their LGPL copyright on the CMake file.

-Seth​








cmake-error.log
Description: cmake-error.log
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net

Re: [Kicad-developers] [PATCH] Allow OpenCASCADE standard edition

[Seth Hillbrand]

Hi Thomas-

I will add this library to the include.  Odd that it wasn't required on
Linux.  Can you send me your CMakeOutput.log?  The version checking is
pretty important and those files don't change, so I'd like to track down
why it would work for 7.1 but not for 7.2.

-S

2018-02-08 7:29 GMT-08:00 Thomas Figueroa :

> Hey Seth,
>
>
>
> Working great with OpenCascade 7.2! I had to modify the Cmake file, though,
>
> to include TKV3d in the library list. I get unresolved external link
> errors when compiling
>
> s3d_plugin_oce otherwise (unresolved symbols SelectMgr_Selection,
> PrsMgr_PresentableObject, and AIS_InteractiveObject respectively).
>
> I also had to remove the version checking, as it was unable to get the
> version via regex matching for some reason.
>
>
>
> -Thomas
>
>
>
>
>
> *From: *Seth Hillbrand 
> *Sent: *Tuesday, February 6, 2018 2:34 PM
> *To: *kicad-developers@lists.launchpad.net
>
> *Subject: *Re: [Kicad-developers] [PATCH] Allow OpenCASCADE standard
> edition
>
>
>
> I've updated this to allow use of OpenCascade 7.2 as well.
>
>
>
> Nick, I added a few more helpful error messages to CMake file.  Let me
> know if you are still seeing the configure error with a clean cmake.
>
>
>
> -Seth
>
>
>
> 2018-02-02 12:47 GMT-08:00 Thomas Figueroa :
>
> Hey Seth,
>
>
>
> I was able to successfully use OpenCascade 7.1 and export using kicad2step!
>
>
>
> Now to find out why…
>
>
>
> -Thomas
>
>
>
> *From: *Seth Hillbrand 
> *Sent: *Friday, February 2, 2018 11:10 AM
> *To: *Thomas Figueroa 
> *Cc: *kicad-developers@lists.launchpad.net
> *Subject: *Re: [Kicad-developers] [PATCH] Allow OpenCASCADE standard
> edition
>
>
>
> Hi Thomas-
>
>
>
> I located a windows machine to try this.  I suspect that this is an
> artifact of OpenCascade 7.2.  Can you test with OpenCascade 7.1?  I haven't
> tracked down exactly what changed in 7.2 but it appears that 7.0 and 7.1
> work but 7.2 will require additional work in kicad2step.
>
>
>
> Of note, OCCT 6.8 also works but 6.9 (and OCE 0.18, which is based on 6.9)
> do not work either.  This is due to a compiler optimization but appears to
> be a different issue than the 7.2 one.
>
>
>
> -Seth
>
>
>
>
>
>
>
> 2018-01-31 19:04 GMT-08:00 Thomas Figueroa :
>
> Hello Seth,
>
>
>
> I’ve had the opportunity to test this on Windows (MSVC, but I’ve had the
> same issue with MSYS2).
>
> STEP models work great in the 3D viewer, and in the footprint module
> editor, just as in OCE.
>
> Unfortunately, I cannot get the STEP export to work. I’ve had a run at
> using OpenCascade before
>
> and encountered this exact same issue. As an example, I’ve attached an
> outputted file.
>
> The following output is from the command line kicad2step:
>
>
>
> 20:31:07: C:\dev\kicad-personal\utils\kicad2step\pcb\oce_utils.cpp:
> fileType: 163
>
>   * no such file: ''
>
>
>
> 20:31:07: C:\dev\kicad-personal\utils\kicad2step\pcb\oce_utils.cpp:
> PCBMODEL::AddComponent: 574
>
>   * no model for filename for ‘’
>
>
>
> This repeats for every model. If you have any ideas, I’d be very willing
> to try them out.
>
>
>
> - Thomas
>
>
>
> *From:* Kicad-developers  hotmail@lists.launchpad.net> *On Behalf Of *Seth Hillbrand
> *Sent:* Monday, January 29, 2018 12:55 PM
> *To:* KiCad Developers 
> *Subject:* [Kicad-developers] [PATCH] Allow OpenCASCADE standard edition
>
>
>
> ​Hi All-
>
>
>
> Currently, the build requires the opencascade community edition.  For
> various reasons, I need to have the current non-community edition of
> OpenCASCADE installed on my work machine.
>
>
>
> The attached patch allows compiling KiCad with either the OpenCASCADE
> community edition or standard edition.
>
>
>
> I've tested on a homebrew-based Mac install as well as Linux but haven't
> verified MSW, if someone would be willing to test it there, that would be
> great!  The basic search routines are lightly modified from FreeCAD's logic
> and keep their LGPL copyright on the CMake file.
>
>
>
> -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

Re: [Kicad-developers] [Kicad-doc-devs] string change proposal

[Andy Peters]

> On Feb 8, 2018, at 3:15 AM, Andrey Kuznetsov  wrote:
> 
> Wow, that sentence is unnecessarily long.
> 
> By rephrasing, you can cut that text in half. Also, why is text editor and 
> PDF viewer in the same context? Default text editor and default PDF viewer do 
> not open the same files, is this a context for a Group where those 2 are 
> defined, weird…

Why in the same context? My guess is because they are both “preferences,” and 
putting them under the “preferences” menu item makes sense.

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

Re: [Kicad-developers] [Kicad-doc-devs] string change proposal

[Andy Peters]

> On Feb 8, 2018, at 3:42 AM, Jeff Young  wrote:
> 
> > … or "Set default text editor and PDF viewer programs to open files from 
> > KiCad”
> 
> +1

One could interpret “open files from KiCad” as being “Open files created by 
KiCad.”

The point I was trying to make, and perhaps wasn’t clear on, is that 
applications should never modify operating-system defaults that affect other 
applications. Thus saying “open files from (within) KiCad” is unnecessary, as 
it is understood that this setting affects performing this operation from 
within Kicad only.

I suppose, further, that this whole thing about choosing which PDF viewer and 
which text editor to use is completely unnecessary. Why _wouldn’t_ KiCad open 
text files in the OS default text editor? Why _wouldn’t_ you want it to open 
PDF files in the OS default PDF viewer? I set those defaults in the OS for a 
reason, and I expect applications to uses those defaults.

-a




> 
> 
>> On 8 Feb 2018, at 10:15, Andrey Kuznetsov > > wrote:
>> 
>> Wow, that sentence is unnecessarily long.
>> 
>> By rephrasing, you can cut that text in half. Also, why is text editor and 
>> PDF viewer in the same context? Default text editor and default PDF viewer 
>> do not open the same files, is this a context for a Group where those 2 are 
>> defined, weird...
>> 
>> Telling the user that he "may define" a"Default Text Editor" is redundant, 
>> same for favorite, default is better, that's what is seen across many 
>> programs, you define a default program to open files, you don't define a 
>> favorite program. "These settings" redundant because you are in a settings 
>> editor window, duhh. 
>> 
>> How about "Set default text editor and PDF viewer programs"?
>> 
>> If you want to be more explicit: "Set default text editor and PDF viewer 
>> programs for use by KiCad" or "Set default text editor and PDF viewer 
>> programs to open files from KiCad"
>> 
>> On Wed, Feb 7, 2018 at 8:23 AM, Andy Peters > > wrote:
>> 
>> 
>> > On Feb 7, 2018, at 5:09 AM, Marco Ciampa > > > wrote:
>> >
>> > Hello,
>> > I am not a native english,
>> 
>> Your English is better than my Italian!
>> 
>> > so I think it is better to ask even for small phrases:
>> >
>> > Here:
>> >
>> > #. type: Plain text
>> > #: kicad.adoc:246
>> > msgid ""
>> > "You may define your favorite text editor and PDF viewer. These settings 
>> > are "
>> > "used whenever you want to open a text or PDF file."
>> >
>> > I would have written it in a more esplicit way like:
>> >
>> > "You may define your favorite text editor and PDF viewer. These settings 
>> > are "
>> > "used by KiCad whenever you want to open a text or PDF file from the 
>> > inside "
>> > "of any of the KiCad tools."
>> >
>> > Comments?
>> 
>> In general, I’m a fan of being as explicit and clear as possible. But, in 
>> this case, I think the user should be aware that s/he’s setting something 
>> from within Kicad, and as such that setting is only relevant when 
>> interacting with a Kicad tool.
>> 
>> -a
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Pads front and F.Cu visibility, possible bugs?

[Maciej Sumiński]

As you noticed, one can only define simple layer visibility dependencies
in GAL using SetRequired() method. Effectively, you can quickly disable
a whole layer when another is invisible, but it does not handle well
cases of e.g. texts whose visibility should depend both on the layer and
the parent object visibility.

Perhaps we should define visibility rules per class and not per layer,
so we can check additional conditions.

Regards,
Orson

On 02/08/2018 01:02 PM, kristoffer Ödmark wrote:
> I started investigating this some more, there is much more rendering
> problems here.
> 
> for example, disbling rendering of front footprints disables all the
> F.Silk, F.Fab, adhesive and many more.
> 
> Disabling the rendering of Text on the front only disables text
> belonging to a footprint, no other. Basically the Render tab does not do
> what it says at all.
> 
> A lot of this seems to because of what is set in pcb_draw_panel_gal.cpp:417
> 
> There is a lot of SetRequired-> (layer, layer)
> 
> And that implementation seems broken, could someone shed some light on
> the purpose there?
> 
> 
> On 2018-02-07 22:32, Kevin Cozens wrote:
>> On 2018-02-07 04:25 PM, Wayne Stambaugh wrote:
 If you use legacy renderer then turn off Pads Front and Pads Back under
 the Render tab on the right the pads disappear. If you are in GAL mode
 they remain visible.

>>>
>>> Given that the legacy canvas will hopefully be removed in the v6
>>> development cycle, I guess this issue will go away.
>>
>> True, but I wanted to point out that as far as I was concerned it
>> hasn't always been this way. I would still expect the pads to
>> disappear if I turn off display of front and back pads.
>>
>> [Oops. Sending again as I meant to send it to the list.]
>>
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp




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

Re: [Kicad-developers] [PATCH] Initialize color of vias netnames text

[Wayne Stambaugh]

Andrzej,

I merged your patch into the development branch.  Thank you for your
contribution to KiCad.

Cheers,

Wayne

On 1/15/2018 9:09 AM, Andrzej Wolski wrote:
> LAYER_VIAS_NETNAMES color was not initialized which resulted in black
> text, not visible in outline mode.
> 
> This patch sets color to gray, similar to that on tracks when they have
> bright color.
> 
> 
> 
> ___
> Mailing list: https://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] Pads front and F.Cu visibility, possible bugs?

[kristoffer Ödmark]

I started investigating this some more, there is much more rendering 
problems here.


for example, disbling rendering of front footprints disables all the 
F.Silk, F.Fab, adhesive and many more.


Disabling the rendering of Text on the front only disables text 
belonging to a footprint, no other. Basically the Render tab does not do 
what it says at all.


A lot of this seems to because of what is set in pcb_draw_panel_gal.cpp:417

There is a lot of SetRequired-> (layer, layer)

And that implementation seems broken, could someone shed some light on 
the purpose there?



On 2018-02-07 22:32, Kevin Cozens wrote:

On 2018-02-07 04:25 PM, Wayne Stambaugh wrote:

If you use legacy renderer then turn off Pads Front and Pads Back under
the Render tab on the right the pads disappear. If you are in GAL mode
they remain visible.



Given that the legacy canvas will hopefully be removed in the v6
development cycle, I guess this issue will go away.


True, but I wanted to point out that as far as I was concerned it 
hasn't always been this way. I would still expect the pads to 
disappear if I turn off display of front and back pads.


[Oops. Sending again as I meant to send it to the list.]




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

Re: [Kicad-developers] [PATCH] Add empty eeschema page layout for Eagle schematic import. Bug #1729722

[Maciej Sumiński]

There is still one problem to be solved here: worksheet layout is not
saved in schematic file, so the default worksheet is restored when an
imported project is saved and reloaded.

I have nothing against the patch, it gives a nicer first impression.

Cheers,
Orson

On 02/07/2018 04:44 PM, Wayne Stambaugh wrote:
> Thanks for testing this.  I know I'm being paranoid but we've been bit
> by this before.  Maybe someday our unit testing will actually get
> implemented.
> 
> Wayne
> 
> On 2/7/2018 8:21 AM, Russell Oliver wrote:
>> I just tested printing then and it worked fine. plus one person's
>> unhandled edge case is another's unit test. 
>>
>>
>>
>> On Thu, Feb 8, 2018 at 12:05 AM Wayne Stambaugh > > wrote:
>>
>> Be careful with zero length line segments.  They have been known to
>> cause issues in the past.  We recently fixed a print bug where a zero
>> diameter circle was causing pages not to print.
>>
>> On 2/7/2018 7:45 AM, Russell Oliver wrote:
>> > Hi Orson, 
>> >
>> > I'm completely fine with any simplifications and style changes. 
>> >
>> > With regards to the zero length line, it appears on line 110 of your
>> > patch file. 
>> > 110: +    "(line (name segm1:Line) (start 0 0) (end 0 0))\n" 
>> >
>> > JP mentions in a comment to the bug report that there is a legacy
>> > compatibility requirement to have at least one item in the page
>> layout,
>> > otherwise the default layout it used. This was for old schematics that
>> > do not have a page layout specified. 
>> >
>> > Kind Regards
>> > Russell
>> >
>> >
>> > On Wed, Feb 7, 2018 at 12:13 AM Maciej Sumiński
>> 
>> > >>
>> wrote:
>> >
>> >     Hi Russell,
>> >
>> >     Thank you very much for the patch. It works as expected and I
>> would like
>> >     to merge it, but there are two things.
>> >
>> >     I have simplified the patch a bit (moved the empty layout to
>> an existing
>> >     file, minor code formatting fixes), so please confirm you are
>> ok with
>> >     committing it under your name.
>> >
>> >     Another question is about "there is a 0 length line to fool
>> something
>> >     somewhere." comment for const char emptyLayout[]. Could you say
>> >     something more about it? I could not spot a 0 length line in
>> the layout
>> >     description, so perhaps we can remove it to avoid confusion.
>> >
>> >     Regards,
>> >     Orson
>> >
>> >     On 02/03/2018 01:27 AM, Russell Oliver wrote:
>> >     > Attached is a patch that adds an empty layout using the same
>> >     method as the
>> >     > SetDefaultLayout function, which is then called by the Eagle
>> schematic
>> >     > plugin to leave only the imported frame visible.
>> >     >
>> >     > https://bugs.launchpad.net/kicad/+bug/1729722
>> >     >
>> >     > Kind Regards
>> >     > Russell
>> >     >
>> >     >
>> >     >
>> >     > ___
>> >     > Mailing list: https://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] [Kicad-doc-devs] string change proposal

[Andrey Kuznetsov]

Thanks Jeff,

That's 35->13 (2.7x) word reduction or 24->8 (3x) reduction for the less
explicit sentence.

Description text shouldn't be longer than 12-18 words, if it is it needs
rephrasing and/or help reference tag.

On Thu, Feb 8, 2018 at 2:42 AM, Jeff Young  wrote:

> > … or "Set default text editor and PDF viewer programs to open files from
> KiCad”
>
> +1
>
>
> On 8 Feb 2018, at 10:15, Andrey Kuznetsov  wrote:
>
> Wow, that sentence is unnecessarily long.
>
> By rephrasing, you can cut that text in half. Also, why is text editor and
> PDF viewer in the same context? Default text editor and default PDF viewer
> do not open the same files, is this a context for a Group where those 2 are
> defined, weird...
>
> Telling the user that he "may define" a"Default Text Editor" is redundant,
> same for favorite, default is better, that's what is seen across many
> programs, you define a default program to open files, you don't define a
> favorite program. "These settings" redundant because you are in a settings
> editor window, duhh.
>
> How about "Set default text editor and PDF viewer programs"?
>
> If you want to be more explicit: "Set default text editor and PDF viewer
> programs for use by KiCad" or "Set default text editor and PDF viewer
> programs to open files from KiCad"
>
> On Wed, Feb 7, 2018 at 8:23 AM, Andy Peters  wrote:
>
>>
>>
>> > On Feb 7, 2018, at 5:09 AM, Marco Ciampa  wrote:
>> >
>> > Hello,
>> > I am not a native english,
>>
>> Your English is better than my Italian!
>>
>> > so I think it is better to ask even for small phrases:
>> >
>> > Here:
>> >
>> > #. type: Plain text
>> > #: kicad.adoc:246
>> > msgid ""
>> > "You may define your favorite text editor and PDF viewer. These
>> settings are "
>> > "used whenever you want to open a text or PDF file."
>> >
>> > I would have written it in a more esplicit way like:
>> >
>> > "You may define your favorite text editor and PDF viewer. These
>> settings are "
>> > "used by KiCad whenever you want to open a text or PDF file from the
>> inside "
>> > "of any of the KiCad tools."
>> >
>> > Comments?
>>
>> In general, I’m a fan of being as explicit and clear as possible. But, in
>> this case, I think the user should be aware that s/he’s setting something
>> from within Kicad, and as such that setting is only relevant when
>> interacting with a Kicad tool.
>>
>> -a
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> --
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss the
> future [JFK]
>
> kandre...@gmail.com
> Live Long and Prosper,
> Andrey
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [Kicad-doc-devs] string change proposal

[Jeff Young]

> … or "Set default text editor and PDF viewer programs to open files from 
> KiCad”

+1


> On 8 Feb 2018, at 10:15, Andrey Kuznetsov  wrote:
> 
> Wow, that sentence is unnecessarily long.
> 
> By rephrasing, you can cut that text in half. Also, why is text editor and 
> PDF viewer in the same context? Default text editor and default PDF viewer do 
> not open the same files, is this a context for a Group where those 2 are 
> defined, weird...
> 
> Telling the user that he "may define" a"Default Text Editor" is redundant, 
> same for favorite, default is better, that's what is seen across many 
> programs, you define a default program to open files, you don't define a 
> favorite program. "These settings" redundant because you are in a settings 
> editor window, duhh. 
> 
> How about "Set default text editor and PDF viewer programs"?
> 
> If you want to be more explicit: "Set default text editor and PDF viewer 
> programs for use by KiCad" or "Set default text editor and PDF viewer 
> programs to open files from KiCad"
> 
> On Wed, Feb 7, 2018 at 8:23 AM, Andy Peters  > wrote:
> 
> 
> > On Feb 7, 2018, at 5:09 AM, Marco Ciampa  > > wrote:
> >
> > Hello,
> > I am not a native english,
> 
> Your English is better than my Italian!
> 
> > so I think it is better to ask even for small phrases:
> >
> > Here:
> >
> > #. type: Plain text
> > #: kicad.adoc:246
> > msgid ""
> > "You may define your favorite text editor and PDF viewer. These settings 
> > are "
> > "used whenever you want to open a text or PDF file."
> >
> > I would have written it in a more esplicit way like:
> >
> > "You may define your favorite text editor and PDF viewer. These settings 
> > are "
> > "used by KiCad whenever you want to open a text or PDF file from the inside 
> > "
> > "of any of the KiCad tools."
> >
> > Comments?
> 
> In general, I’m a fan of being as explicit and clear as possible. But, in 
> this case, I think the user should be aware that s/he’s setting something 
> from within Kicad, and as such that setting is only relevant when interacting 
> with a Kicad tool.
> 
> -a
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 
> 
> 
> -- 
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss the future 
> [JFK]
> 
> kandre...@gmail.com 
> Live Long and Prosper,
> Andrey
> ___
> Mailing list: https://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] eeschema ngspice simulation improvment

[Maciej Sumiński]

Apparently you got it to work, cool! What was the actual problem? Do you
use ngspice v26 or v27? Would you share the patch?

Regards,
Orson

On 02/08/2018 11:19 AM, ludovic léau-mercier wrote:
> I work on. First result in attachment.
> 
> 
> On 08/02/2018 10:07, Maciej Sumiński wrote:
>> Hi Ludovic,
>>
>> If I recall correctly, when you run an analysis different than
>> transient, ngspice will not return any data when you ask for currents.
>> There is also another related line:
>>
>> void NETLIST_EXPORTER_PSPICE_SIM::writeDirectives( OUTPUTFORMATTER*
>> aFormatter, unsigned aCtl ) const
>> {
>>  // Add a directive to obtain currents
>>  //aFormatter->Print( 0, ".options savecurrents\n" );    // does
>> not work :(
>>
>> The directive is described in ngspice manual [1, 15.7.1]. Perhaps it is
>> fixed in ngspice-27, I have no idea. Try commenting out the condition
>> that prevents listing current signals for analysis other than transient
>> and see if you succeed.
>>
>> Regards,
>> Orson
>>
>> 1. http://ngspice.sourceforge.net/docs/ngspice-manual.pdf
>>
>> On 02/08/2018 09:45 AM, ludovic léau-mercier wrote:
>>> Hi all,
>>>
>>> i try to create a patch to adding several improvment of eeshema
>>> simulation.
>>>
>>> My first goal is to draw BJT caracteristics (like
>>> https://www.st-andrews.ac.uk/~www_pa/Scots_Guide/info/comp/active/BiPolar/IcVce.gif)
>>>
>>> with a simplest circuit in attachment.
>>>
>>> I had beginning to work on this improvment but in the file :
>>>
>>>   /kicad/eeschema/dialogs/dialog_signal_list.cpp
>>>
>>> in method :
>>>
>>> bool DIALOG_SIGNAL_LIST::TransferDataToWindow()
>>>
>>> there is a strnage comment :
>>>
>>> // For some reason, it is not possible to plot currents in any but
>>> transient analysis
>>>
>>> If someone can give me some informations ?
>>>
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://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
> 




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

Re: [Kicad-developers] eeschema ngspice simulation improvment

[ludovic léau-mercier]

I work on. First result in attachment.


On 08/02/2018 10:07, Maciej Sumiński wrote:

Hi Ludovic,

If I recall correctly, when you run an analysis different than
transient, ngspice will not return any data when you ask for currents.
There is also another related line:

void NETLIST_EXPORTER_PSPICE_SIM::writeDirectives( OUTPUTFORMATTER*
aFormatter, unsigned aCtl ) const
{
 // Add a directive to obtain currents
 //aFormatter->Print( 0, ".options savecurrents\n" );// does
not work :(

The directive is described in ngspice manual [1, 15.7.1]. Perhaps it is
fixed in ngspice-27, I have no idea. Try commenting out the condition
that prevents listing current signals for analysis other than transient
and see if you succeed.

Regards,
Orson

1. http://ngspice.sourceforge.net/docs/ngspice-manual.pdf

On 02/08/2018 09:45 AM, ludovic léau-mercier wrote:

Hi all,

i try to create a patch to adding several improvment of eeshema simulation.

My first goal is to draw BJT caracteristics (like
https://www.st-andrews.ac.uk/~www_pa/Scots_Guide/info/comp/active/BiPolar/IcVce.gif)
with a simplest circuit in attachment.

I had beginning to work on this improvment but in the file :

  /kicad/eeschema/dialogs/dialog_signal_list.cpp

in method :

bool DIALOG_SIGNAL_LIST::TransferDataToWindow()

there is a strnage comment :

// For some reason, it is not possible to plot currents in any but
transient analysis

If someone can give me some informations ?




___
Mailing list: https://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


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

Re: [Kicad-developers] [Kicad-doc-devs] string change proposal

[Andrey Kuznetsov]

Wow, that sentence is unnecessarily long.

By rephrasing, you can cut that text in half. Also, why is text editor and
PDF viewer in the same context? Default text editor and default PDF viewer
do not open the same files, is this a context for a Group where those 2 are
defined, weird...

Telling the user that he "may define" a"Default Text Editor" is redundant,
same for favorite, default is better, that's what is seen across many
programs, you define a default program to open files, you don't define a
favorite program. "These settings" redundant because you are in a settings
editor window, duhh.

How about "Set default text editor and PDF viewer programs"?

If you want to be more explicit: "Set default text editor and PDF viewer
programs for use by KiCad" or "Set default text editor and PDF viewer
programs to open files from KiCad"

On Wed, Feb 7, 2018 at 8:23 AM, Andy Peters  wrote:

>
>
> > On Feb 7, 2018, at 5:09 AM, Marco Ciampa  wrote:
> >
> > Hello,
> > I am not a native english,
>
> Your English is better than my Italian!
>
> > so I think it is better to ask even for small phrases:
> >
> > Here:
> >
> > #. type: Plain text
> > #: kicad.adoc:246
> > msgid ""
> > "You may define your favorite text editor and PDF viewer. These settings
> are "
> > "used whenever you want to open a text or PDF file."
> >
> > I would have written it in a more esplicit way like:
> >
> > "You may define your favorite text editor and PDF viewer. These settings
> are "
> > "used by KiCad whenever you want to open a text or PDF file from the
> inside "
> > "of any of the KiCad tools."
> >
> > Comments?
>
> In general, I’m a fan of being as explicit and clear as possible. But, in
> this case, I think the user should be aware that s/he’s setting something
> from within Kicad, and as such that setting is only relevant when
> interacting with a Kicad tool.
>
> -a
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
Mailing list: https://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] Schematic symbol chooser clarification

[kristoffer Ödmark]

Attached is a minimal patch that differs the dialog title.

- Kristoffer

On 2018-02-05 13:25, Marco Ciampa wrote:

On Mon, Feb 05, 2018 at 01:10:08PM +0100, kristoffer Ödmark wrote:

Hey!

I just spent some time trying to "debug" a library non-issue with a EE
switching from Altium for a test. He had added the libraries correctly, and
they showed up. But everytime he tried adding a symbol to the schematic, no
symbols was there. We sent pictures back and forth, and indeed the libraries
added, but did not show up.

To make a long hassle short, turns out the shortcut "P" is used to place
symbols in Altium, but to place Power symbols in kicad.
This is not an issue, however, there is no indication at all that the symbol
chooser is actually filtered or limited when using the shortcut key.

I think there could be benefits of adding some kind of visualization to the
symbol chooser that the list is limited to only power symbols, maybe just
changing the window title to something like "Choose Power Symbol" or the
more general term of adding the filter to the window name. Let me know what
you think

Also when you place a power symbol, the dialog shows normal symbols in
the history list, and it also permits to insert these symbols even if
they are not power symbols... that to me seems incoherent...



>From 0c0fe309e3ee9cc2286847f330d9310eefacb810 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kristoffer=20=C3=96dmark?= 
Date: Thu, 8 Feb 2018 10:58:22 +0100
Subject: [PATCH] Differ the dialog text for when choosing power-symbols and
 all symbols

---
 eeschema/getpart.cpp | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/eeschema/getpart.cpp b/eeschema/getpart.cpp
index 4f54bb588..46dc53b58 100644
--- a/eeschema/getpart.cpp
+++ b/eeschema/getpart.cpp
@@ -159,7 +159,11 @@ SCH_BASE_FRAME::COMPONENT_SELECTION SCH_BASE_FRAME::SelectComponentFromLibrary(
 if( aHighlight && aHighlight->IsValid() )
 adapter->SetPreselectNode( *aHighlight, /* aUnit */ 0 );
 
-dialogTitle.Printf( _( "Choose Symbol (%d items loaded)" ), adapter->GetComponentsCount() );
+if( adapter->GetFilter() == CMP_TREE_MODEL_ADAPTER::CMP_FILTER_POWER )
+dialogTitle.Printf( _( "Choose Power Symbol (%d items loaded)" ), adapter->GetComponentsCount() );
+else
+dialogTitle.Printf( _( "Choose Symbol (%d items loaded)" ), adapter->GetComponentsCount() );
+
 DIALOG_CHOOSE_COMPONENT dlg( this, dialogTitle, adapter, aConvert, aAllowFields, aShowFootprints );
 
 if( dlg.ShowQuasiModal() == wxID_CANCEL )
-- 
2.16.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] eeschema ngspice simulation improvment

[Maciej Sumiński]

Hi Ludovic,

If I recall correctly, when you run an analysis different than
transient, ngspice will not return any data when you ask for currents.
There is also another related line:

void NETLIST_EXPORTER_PSPICE_SIM::writeDirectives( OUTPUTFORMATTER*
aFormatter, unsigned aCtl ) const
{
// Add a directive to obtain currents
//aFormatter->Print( 0, ".options savecurrents\n" );// does
not work :(

The directive is described in ngspice manual [1, 15.7.1]. Perhaps it is
fixed in ngspice-27, I have no idea. Try commenting out the condition
that prevents listing current signals for analysis other than transient
and see if you succeed.

Regards,
Orson

1. http://ngspice.sourceforge.net/docs/ngspice-manual.pdf

On 02/08/2018 09:45 AM, ludovic léau-mercier wrote:
> Hi all,
> 
> i try to create a patch to adding several improvment of eeshema simulation.
> 
> My first goal is to draw BJT caracteristics (like
> https://www.st-andrews.ac.uk/~www_pa/Scots_Guide/info/comp/active/BiPolar/IcVce.gif)
> with a simplest circuit in attachment.
> 
> I had beginning to work on this improvment but in the file :
> 
>  /kicad/eeschema/dialogs/dialog_signal_list.cpp
> 
> in method :
> 
> bool DIALOG_SIGNAL_LIST::TransferDataToWindow()
> 
> there is a strnage comment :
> 
> // For some reason, it is not possible to plot currents in any but
> transient analysis
> 
> If someone can give me some informations ?
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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

Re: [Kicad-developers] [Kicad-doc-devs] string change proposal

[Carsten Schoenert]

Am 08.02.2018 um 09:29 schrieb Nick Østergaard:
> Please keep in mind that experienced users probably don't really read
> the full text of the various information strings as they have seen this
> for several times already.
> But the not well experienced or new users have problems on these not
> specific information or hints. I've meet people who asked me things that
> are not explained well enough. Even me it happens that I need to look
> sometimes into the code to see and understand whats going on here.
> 
> 
> But this is also because you probably don't have the rest of the GUI
> context when you are translating.

I really meant this from a using perspective not from a POV while doing
translations.

And what will or can do a normal user here? And again, what matters
really in the end?

-- 
Regards
Carsten Schoenert

___
Mailing list: https://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] eeschema ngspice simulation improvment

[ludovic léau-mercier]

Hi all,

i try to create a patch to adding several improvment of eeshema simulation.

My first goal is to draw BJT caracteristics (like 
https://www.st-andrews.ac.uk/~www_pa/Scots_Guide/info/comp/active/BiPolar/IcVce.gif) 
with a simplest circuit in attachment.


I had beginning to work on this improvment but in the file :

 /kicad/eeschema/dialogs/dialog_signal_list.cpp

in method :

bool DIALOG_SIGNAL_LIST::TransferDataToWindow()

there is a strnage comment :

// For some reason, it is not possible to plot currents in any but 
transient analysis


If someone can give me some informations ?


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

Re: [Kicad-developers] [Kicad-doc-devs] string change proposal

[Nick Østergaard]

2018-02-08 <20%2018%2002%2008> 6:53 GMT+01:00 Carsten Schoenert <
c.schoen...@t-online.de>:

> Hi,
>
> Am 08.02.2018 um 01:06 schrieb Nick Østergaard:
> > I also thinks that adding "by Kicad" does not add any information. It
> > only complicates the already long description.
>
> I disagree here and think the attempt of Marco is correct. Slightly
> modifications of translated strings I've done several times in the past
> for German exact for that reason Marco is mentioning.
>
> Please keep in mind that experienced users probably don't really read
> the full text of the various information strings as they have seen this
> for several times already.
> But the not well experienced or new users have problems on these not
> specific information or hints. I've meet people who asked me things that
> are not explained well enough. Even me it happens that I need to look
> sometimes into the code to see and understand whats going on here.
>

But this is also because you probably don't have the rest of the GUI
context when you are translating.


> There is always a main question for doing things, which one is using
> this in the end. GUI parts are made for users, algorithms are for coders
> and programmers.
>
> The Python folks have there own Zen of Python [1], one of there rule is
>
> "Explicit is better than implicit."
>
> that was coming directly to my mind while I've read Marcos question.
>
>
> [1] https://www.python.org/dev/peps/pep-0020/
>
> --
> Regards
> Carsten Schoenert
>
> ___
> Mailing list: https://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] wxGTK3 patches

[Maciej Sumiński]

...and for some reason antialiasing stays enabled anyway. I retract the
question.

Cheers,
Orson

On 02/08/2018 09:01 AM, Maciej Sumiński wrote:
> One more question, I have just realized that I disabled antialiasing
> when USE_WX_GRAPHICS_CONTEXT is enabled. Is that fine for macOS or
> eeschema runs fast enough, so antialiasing is preferred?
> 
> Cheers,
> Orson
> 
> On 02/07/2018 06:36 PM, Bernhard Stegmaier wrote:
>> … yes, no good.
>> It seems to be OK when just panning around.
>> But, it gets very laggy while e.g. dragging/moving symbols around (even on a 
>> not so big schematic I had at hand).
>>
>> It is fine if you take out the Refresh() quoted below on macOS.
>> I didn’t see any obvious things on a quick check with the remaining changes 
>> (might be due to the fact that crosshair is still disabled on macOS?).
>>
>>
>> Regards,
>> Bernhard
>>
>>> On 7. Feb 2018, at 17:32, Bernhard Stegmaier  
>>> wrote:
>>>
>>> … USE_WX_GRAPHICS_CONTEXT is on per default on macOS.
>>>
>>> I will check tonight, but I guess/fear that the part
>>> <<<
>>> +#ifdef USE_WX_GRAPHICS_CONTEXT
>>> +// Screen has to be updated on every operation, otherwise the cursor 
>>> leaves a trail (when xor
>>> +// operation is changed to copy) or is not updated at all.
>>> +Refresh();
>>> +#endif
>>
>>> will make it slow (might cause double painting every time because of how it 
>>> is already handled right now without the extra refresh).
>>>
>>> I’ll report (if no other macOS guy is faster than me… :) )
>>>
>>>
>>> Bernhard
>>>
 On 7. Feb 2018, at 15:38, Maciej Sumiński  wrote:

 Two patches to fix some troubles occurring on wxGTK3. The first one
 displays a warning when it detects that KiCad is being built against
 wxGTK3. The second one makes eeschema functional, just a bit slower when
 compared to wxGTK2. The only thing that is really broken is pcbnew
 printing, but there are also some other glitches (e.g. black background
 in eeschema printing preview, though the actual printouts are ok).

 I have tested the patch under Linux and Windows and noticed no influence
 on wxMSW/wxGTK2, as expected. I would love to hear from OSX users that
 there are no new issues introduced in the patch.

 Unfortunately, it does not resolve the recent wxpython-gtk3 issue on
 Arch Linux. The problem occurs when KiCad is linked against wxGTK2, but
 wxPython uses wxGTK3. In such case KiCad loads wxGTK2 libraries on start
 and when wxPython is initialized - it tries to load wxGTK3 causing
 symbol conflicts. I guess there is not much we can do about it, apart
 from detecting such situation and informing the user about the problem
 cause. Any other ideas?

 Cheers,
 Orson
 <0001-GTK3-Display-a-warning-and-enable-wxGraphicsContext.patch><0002-wxWidgets-GTK3-compatibility-fixes-for-eeschema.patch>___
 Mailing list: https://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
> 




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

Re: [Kicad-developers] wxGTK3 patches

[Maciej Sumiński]

One more question, I have just realized that I disabled antialiasing
when USE_WX_GRAPHICS_CONTEXT is enabled. Is that fine for macOS or
eeschema runs fast enough, so antialiasing is preferred?

Cheers,
Orson

On 02/07/2018 06:36 PM, Bernhard Stegmaier wrote:
> … yes, no good.
> It seems to be OK when just panning around.
> But, it gets very laggy while e.g. dragging/moving symbols around (even on a 
> not so big schematic I had at hand).
> 
> It is fine if you take out the Refresh() quoted below on macOS.
> I didn’t see any obvious things on a quick check with the remaining changes 
> (might be due to the fact that crosshair is still disabled on macOS?).
> 
> 
> Regards,
> Bernhard
> 
>> On 7. Feb 2018, at 17:32, Bernhard Stegmaier  wrote:
>>
>> … USE_WX_GRAPHICS_CONTEXT is on per default on macOS.
>>
>> I will check tonight, but I guess/fear that the part
>> <<<
>> +#ifdef USE_WX_GRAPHICS_CONTEXT
>> +// Screen has to be updated on every operation, otherwise the cursor 
>> leaves a trail (when xor
>> +// operation is changed to copy) or is not updated at all.
>> +Refresh();
>> +#endif
>
>> will make it slow (might cause double painting every time because of how it 
>> is already handled right now without the extra refresh).
>>
>> I’ll report (if no other macOS guy is faster than me… :) )
>>
>>
>> Bernhard
>>
>>> On 7. Feb 2018, at 15:38, Maciej Sumiński  wrote:
>>>
>>> Two patches to fix some troubles occurring on wxGTK3. The first one
>>> displays a warning when it detects that KiCad is being built against
>>> wxGTK3. The second one makes eeschema functional, just a bit slower when
>>> compared to wxGTK2. The only thing that is really broken is pcbnew
>>> printing, but there are also some other glitches (e.g. black background
>>> in eeschema printing preview, though the actual printouts are ok).
>>>
>>> I have tested the patch under Linux and Windows and noticed no influence
>>> on wxMSW/wxGTK2, as expected. I would love to hear from OSX users that
>>> there are no new issues introduced in the patch.
>>>
>>> Unfortunately, it does not resolve the recent wxpython-gtk3 issue on
>>> Arch Linux. The problem occurs when KiCad is linked against wxGTK2, but
>>> wxPython uses wxGTK3. In such case KiCad loads wxGTK2 libraries on start
>>> and when wxPython is initialized - it tries to load wxGTK3 causing
>>> symbol conflicts. I guess there is not much we can do about it, apart
>>> from detecting such situation and informing the user about the problem
>>> cause. Any other ideas?
>>>
>>> Cheers,
>>> Orson
>>> <0001-GTK3-Display-a-warning-and-enable-wxGraphicsContext.patch><0002-wxWidgets-GTK3-compatibility-fixes-for-eeschema.patch>___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 




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