Re: [Kicad-developers] KiCad Janitor moves

[Maciej Sumiński]

On 12/12/18 12:25 AM, Seth Hillbrand wrote:
> Am 2018-12-11 12:16, schrieb Maciej Sumiński:
>> Recently KiCad Janitor had been rather unreliable, mostly due to my
>> capricious Internet connection, so a few minutes ago he has got a new
>> home at one of CERN servers. It used to work as a webhook, but in order
>> to improve robustness I have switched it to polling (updates every 2
>> minutes). I expect the setup to be rock-solid, so please ping me anytime
>> KiCad Janitor misbehaves.
> 
> Hi Orson-
> 
> Thanks for keeping Janitor happy!  Once it's settled into its new home,
> can we run the 5.0.2 "Fix Committed"->"Fix Released" script to clear out
> the old reports that were tagged 5.0.2?
> 
> Best-
> Seth

Hi Seth,

Of course, thank you for the reminder. I have just run the script, so
the bug reports are already updated.

Cheers,
Orson



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

[Kicad-developers] KiCad Janitor moves

[Maciej Sumiński]

Recently KiCad Janitor had been rather unreliable, mostly due to my
capricious Internet connection, so a few minutes ago he has got a new
home at one of CERN servers. It used to work as a webhook, but in order
to improve robustness I have switched it to polling (updates every 2
minutes). I expect the setup to be rock-solid, so please ping me anytime
KiCad Janitor misbehaves.

Cheers,
Orson



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

Re: [Kicad-developers] [PATCH] Numeric evaluator tests + unary "+"

[Maciej Sumiński]

Hi John,

Thank you for the patches, I have just merged them. I particularly
appreciate the unit tests, well done!

Cheers,
Orson

On 11/28/18 5:03 PM, John Beard wrote:
> Hi,
> 
> Here are some patches for the numeric evaluator.
> 
> There are three parts:
> * Add tests and test current behaviour of the numeric evaluator.
> Remove broken and unused/unbuildable old tests.
> * Add a CMake target (libeval_grammar) to allow to rebuild the grammar
> * Modify and rebuild the grammar to allow unary + in expressions. Not
> a major change, but consistent with most other numeric evaluations,
> and symmetric with the minus notation.
> 
> The CMake target is run manually and, as currently, the generated C
> source checked in. The target will only be available when lemon is
> installed.
> 
> Having this available as a CMake target makes it much more accessible
> to other developers to maintain the grammar. Tests allow to ensure
> behaviour is not changed when not expected.
> 
> Cheers,
> 
> John
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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] Dialog field validation on KillFocus

[Maciej Sumiński]

On 11/29/18 2:36 PM, Jeff Young wrote:
> While most UI guidelines suggest validating on field exit, it’s not without 
> cost.  In particular, on GTK we can’t tell the difference between a KillFocus 
> from clicking the OK button (when validation should be run) and a KillFocus 
> from clicking Cancel (when it should not).  
> 
> Needless to say, KillFocus-validation also plays very poorly when GTK’s 
> focus-follows-mouse is turned on.
> 
> So I plan to do two things:
> 
> 1) Remove automatic validation on KillFocus from UNIT_BINDER.  Clients which 
> need validation will be modified to call Validate() themselves from their 
> TransferDataFromWindow() methods.
> 
> 2) Remove UNIT_BINDER validation which isn’t needed.  We have a lot of 
> validation which just checks for “reasonable” values.  However, our 
> definition of “reasonable” doesn’t always match our users’ definitions.  
> “Needed” validation (which will remain) is that which prevents un-supported 
> situations, or that which makes recovery hard (for instance, PCB text with a 
> zero width is hard to select).
> 
> Any comments before I go ahead?

Hi Jeff,

John Beard had a good idea of replacing an error pop-up dialog with an
error indicator (red frame around text or red background for text input
widget). It will notify the user about potential problems without being
too disruptive, and such check might be done by KillFocus event handler.

I would still keep a pop-up dialog showing up if the user wants to
accept invalid settings (call Validate() in TransferDataFromWindow()).
If we want to provide ammo to shoot their feet, then 'Ignore' button
sounds like an appropriate caliber.

Cheers,
Orson



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

Re: [Kicad-developers] Adding global mouse shortcuts in GAL tool framework

[Maciej Sumiński]

Hi John,

One possible way of solving the problem is to change the m_defaultHotkey
in TOOL_ACTION class to a TOOL_EVENT field which says what triggers the
action. Then ACTION_MANAGER instead of comparing hotkeys should run
TOOL_EVENT::Matches() to check whether a processed TOOL_EVENT is
supposed to fire an action.

Cheers,
Orson

On 11/21/18 11:15 AM, John Beard wrote:
> Hi,
> 
> A little technical query provoked by someone else's question, which I
> was unable to answer.
> 
> Say one wanted to add a global mouse shortcut, for example, double
> middle-click to do "zoom-to-fit" [1].
> 
> The current mouse events are handled on a contextual basis in the
> event loops for each tool. Thus, each tool handles its own clicks,
> drags, etc, which generally makes sense for the basic left/right
> clicks as what that does is usually highly tool-dependent. Global key
> shortcuts for ACTIONs are handled at a higher level and and either
> trigger a transition set by setTransitions(), or translated to an
> event and caught by the current tool's event loop as their own event
> (checked with evt->IsAction())
> 
> However, there appears to be no way to add a mouse click pattern to an
> ACTION, thus you can't have a global double-middle-click, unless you
> add an "if( evt->IsDblClick( BTN_MIDDLE))" to every event loop.
> 
> What would be the right way (if any) to approach this? I'm ignoring
> for now the UI implications of presenting such a shortcut in the
> hotkey dialog, implementing the "set hotkey" action, and any problems
> that might arise in having it co-exist with legacy hotkeys.
> 
> Cheers,
> 
> John
> 
> [1]: https://bugs.launchpad.net/kicad/+bug/1480868



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] warning: enum constant in boolean context in dialog_print_generic.cpp

[Maciej Sumiński]

Hi Andrew,

Good catch, thank you! I have just pushed your patch to the master branch.

Regards,
Orson

On 11/7/18 6:16 AM, Andrew Lutsenko wrote:
> Hi Orson and KiCad devs,
> 
> During rebuilding current nightly I noticed this warning and decided to
> look into it.
> 
> /usr/local/google/home/alutsenko/src/kicad/common/dialogs/dialog_print_generic.cpp:
> In member function ‘virtual void
> DIALOG_PRINT_GENERIC::onCloseButton(wxCommandEvent&)’:
> /usr/local/google/home/alutsenko/src/kicad/common/dialogs/dialog_print_generic.cpp:246:24:
> warning: enum constant in boolean context [-Wint-in-bool-context]
>  Close( wxID_CANCEL );
> ^
> wxWindow::Close takes a boolean as an argument and wxID_CANCEL being not
> zero means this will be interpreted as force close. I don't think this was
> the intended behavior here.
> 
> Please take a look at my simple patch that fixes this warning and (I think)
> a latent bug.
> 
> Regards,
> Andrew Lutsenko
> 




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] Verify wxPython.h exists.

[Maciej Sumiński]

Hi Wayne,

I have eventually checked the patch on Linux and Windows 7 as well and
it works as advertised, so I pushed it. Thank you for your contribution
to KiCad;)

Cheers,
Orson

On 10/29/18 1:33 PM, Maciej Sumiński wrote:
> Hi Wayne,
> 
> KiCad with your patch applied builds fine on macOS 10.13.6, so it looks
> like you got the paths right.
> 
> Cheers,
> Orson
> 
> On 10/22/18 11:11 PM, Wayne Stambaugh wrote:
>> I created a patch to fix bug report 1785663.  It works on linux and
>> windows msys2 builds.  On these platforms wxPython.h is located in the
>> same path as the wx headers so it's straight forward fix.  I'm not sure
>> where wxPython.h is installed on other build platforms.  I would like
>> our macos and msvc devs to test it to make sure it doesn't break those
>> platform builds.
>>
>> Thanks,
>>
>> Wayne
>>
>> [1]: https://bugs.launchpad.net/kicad/+bug/1785663



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 depends on libngspice.so instead of libngspice.so.0?

[Maciej Sumiński]

On 10/30/18 6:57 AM, Carsten Schoenert wrote:
> Hello Orson,
> 
> Am 29.10.18 um 21:06 schrieb Maciej Suminski:
>>> works for me with current HEAD from today within Debian testing.
>>>
>> I should have said it earlier: one of the goals is to make dh_shlibdeps
>> happy, but I do not use Debian so I have no way of verifying it.
> 
> to check this I'd need to do a complete packaging with importing
> tarballs etc.
> For now I've "just" tested your patch against the current HEAD so the
> build will work and also simulation task later if eeschema is opened.
> dh_shlibdeps is going through the list of listed *.so.* files for a
> binary and collecting the belonging packages.
> 
> If ldd on eeschema is showing libngspice.so.0 then also sh_shlibdeps
> will add the package libngspice0. This is something I haven't tested
> yesterday (due a lack of time).

Alright, then I think the new patch should be sufficient. Also, the
shared library name is no longer hard-coded, but detected in CMake
configuration step. I have just pushed the patch to the master and 5.0
branches.

Cheers,
Orson



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

Re: [Kicad-developers] [PATCH] Verify wxPython.h exists.

[Maciej Sumiński]

Hi Wayne,

KiCad with your patch applied builds fine on macOS 10.13.6, so it looks
like you got the paths right.

Cheers,
Orson

On 10/22/18 11:11 PM, Wayne Stambaugh wrote:
> I created a patch to fix bug report 1785663.  It works on linux and
> windows msys2 builds.  On these platforms wxPython.h is located in the
> same path as the wx headers so it's straight forward fix.  I'm not sure
> where wxPython.h is installed on other build platforms.  I would like
> our macos and msvc devs to test it to make sure it doesn't break those
> platform builds.
> 
> Thanks,
> 
> Wayne
> 
> [1]: https://bugs.launchpad.net/kicad/+bug/1785663





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 depends on libngspice.so instead of libngspice.so.0?

[Maciej Sumiński]

Hi Carsten,

On 10/27/18 11:50 AM, Carsten Schoenert wrote:
[snip]
> I'd really appreciate if the situation could be improved here somewhere
> in the future!

Can you check if the attached patch solves the problem? It still does
not recognize the right libngspice file under Windows, but I need to
know if it is a step in the right direction.

Cheers,
Orson
diff --git a/eeschema/CMakeLists.txt b/eeschema/CMakeLists.txt
index e56f3c849..cd4d0d78e 100644
--- a/eeschema/CMakeLists.txt
+++ b/eeschema/CMakeLists.txt
@@ -7,6 +7,15 @@ add_definitions( -DEESCHEMA )
 
 if( KICAD_SPICE )
 set( INC_AFTER ${INC_AFTER} ${NGSPICE_INCLUDE_DIR} )
+
+# Find out the exact libngspice file name
+get_filename_component( NGSPICE_REAL_PATH "${NGSPICE_LIBRARY}" REALPATH )
+get_filename_component( NGSPICE_LIB_FILE "${NGSPICE_REAL_PATH}" NAME )
+
+set_property( SOURCE sim/ngspice.cpp
+APPEND PROPERTY COMPILE_DEFINITIONS
+NGSPICE_LIB_FILE="${NGSPICE_LIB_FILE}"
+)
 endif()
 
 include_directories( BEFORE ${INC_BEFORE} )
@@ -359,7 +368,15 @@ target_link_libraries( eeschema_kiface
 legacy_gal
 ${wxWidgets_LIBRARIES}
 ${GDI_PLUS_LIBRARIES}
+${NGSPICE_LIBRARY}
 )
+
+if( KICAD_SPICE )
+target_link_libraries( eeschema_kiface
+${NGSPICE_LIBRARY}
+)
+endif()
+
 set_target_properties( eeschema_kiface PROPERTIES
 # Decorate OUTPUT_NAME with PREFIX and SUFFIX, creating something like
 # _eeschema.so, _eeschema.dll, or _eeschema.kiface
diff --git a/eeschema/sim/ngspice.cpp b/eeschema/sim/ngspice.cpp
index 3b6e4dd74..3cfbf8b1f 100644
--- a/eeschema/sim/ngspice.cpp
+++ b/eeschema/sim/ngspice.cpp
@@ -293,7 +293,7 @@ void NGSPICE::init_dll()
 const vector dllPaths = { "", "/mingw64/bin", "/mingw32/bin" };
 #endif /* __WINDOWS__ */
 #ifdef __WXMAC__
-wxFileName dllFile( "", "libngspice.0.dylib" );
+wxFileName dllFile( "", NGSPICE_LIB_FILE );
 const vector dllPaths = {
 GetOSXKicadUserDataDir() + "/PlugIns/ngspice",
 GetOSXKicadMachineDataDir() + "/PlugIns/ngspice",
@@ -320,7 +320,7 @@ void NGSPICE::init_dll()
 if( !m_dll.IsLoaded() ) // try also the system libraries
 m_dll.Load( wxDynamicLibrary::CanonicalizeName( "ngspice" ) );
 #else
-m_dll.Load("libngspice.so.0");
+m_dll.Load( NGSPICE_LIB_FILE );
 #endif /* __WINDOWS || __WXMAC__ */
 
 if( !m_dll.IsLoaded() )


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 depends on libngspice.so instead of libngspice.so.0?

[Maciej Sumiński]

Hi Wayne,

On 10/27/18 11:08 PM, Wayne Stambaugh wrote:
[snip]
> Me too.  This is why I had reservations about Stefan's patch.  It is a
> temporary fix at best.  As soon as the libngspice so version number
> changes, we will be in trouble.  Even worse when one disto is still
> using 0 and another distro uses 1.  Pulling in the correct library
> version at config/build time is the way to go.

I considered Stefan's patch is a step in the right direction. Until now,
we called for any libngspice.so, and that would be satisfied even if the
API changes in libngspice.so.1. Anyway, I agree it is a temporary fix.

Cheers,
Orson



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

Re: [Kicad-developers] [PATCH] Print stacktrace when SIGSEGV or SIGABRT appears

[Maciej Sumiński]

On 10/26/18 2:29 AM, Tomasz Wlostowski wrote:
[snip]
> I made a variant of the dialog that (hopefully) is easier to understand.
> This raises another question: do we have any means of reporting bugs
> without forcing the users to register on launchpad, for example a public
> Kicad bug email (e.g. b...@kicad-pcb.org?). @Wayne, what do you think
> about such solution?

I think this might be easily arranged via https requests and KiCad
Janitor help. The only thing I am afraid of is potential spam we are
going to receive, but then we can simply shut down the service.

Cheers,
Orson



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

Re: [Kicad-developers] 5.1

[Maciej Sumiński]

On 10/25/18 2:23 AM, Seth Hillbrand wrote:
> Am 2018-10-24 17:20, schrieb Maciej Suminski:
>> Actually I was pretty sure that my approach is bullet-proof, but perhaps
>> I do not get where the trap is hidden. As far as I understand, Seth
>> experienced problems when pcbnew (wxWidgets/gtk2) loaded wxPython shared
>> libraries (wxWidgets/gtk3), which end up in symbol conflicts.
>>
>> This issue is eliminated in my branch by ensuring KiCad requests the
>> same wxWidgets flavor as is used by wxPython. I might be lacking
>> explanation skills, but code is unambiguous - have a look at [1], lines
>> 746 and 775.
> 
> Hi Orson-
> 
> It looks like this overwrites the user's preference for GTK toolkit. 
> I'd like to keep the ability to specify which toolkit I compile against
> if possible.
> 
> Best-
> Seth

I will add such option, but keep in mind that pcbnew will be broken if
wxWidgets and wxPython use different toolkits. Note that the toolkit
version is enforced only on Linux and when KICAD_SCRIPTING_WXPYTHON is
enabled.

Cheers,
Orson



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

Re: [Kicad-developers] [RFC] wxPhoenix support

[Maciej Sumiński]

I have briefly tested the branch with Phoenix/Python3/GTK3 and
wxPython/Python2/GTK3 on Linux - no problems observed so far. Well done,
thank you Thomas!

Cheers,
Orson

On 10/23/18 3:56 PM, Thomas Pointhuber wrote:
> Hi Wayne,
> 
> The console crash is already fixed in the merge request:
> https://code.launchpad.net/~pointhi/kicad/+git/kicad/+merge/357605
> 
> Regards,
> Thomas
> 
> Am 22.10.18 um 18:36 schrieb Wayne Stambaugh:
>> Hey Thomas,
>>
>> I looked over you merge request and it changes seem fine.  I still need
>> to test it but until the console crash issue is resolved, I will not
>> approve the patch.  Hopefully someone can help you out with the mutex
>> locking issue.
>>
>> Cheers,
>>
>> Wayne



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

[Maciej Sumiński]

On 10/23/18 3:00 PM, Seth Hillbrand wrote:
> The issues were asserts, missing icons and a crash on exit.  I tracked
> it down to a wx module that was loaded by pip in my user cache from when
> I was testing gtk3 builds.  Yay, python.  Removing it cleared all issues.

Indeed it sounds like gtk2/gtk3 conflict, but I have good news: I fixed
the mirrored title block printing. I have also changed CMakeLists.txt,
so now it selects the same toolkit for wxWidgets and wxPython. When
scripting is disabled and only wxWidgets is linked then the default
toolkit is used. Now the problems caused by gtk2/gtk3 conflicts should
be gone. I think there is only one GTK3-specific issue left [1].

I have not pushed my changes yet, as there are two patches hanging in
the air that touch the same area that I have modified: one from Wayne to
verify wxPython.h, second one from Thomas Pointhuber to support Phoenix.
I came last to the party, so I am willing to rebase my changes once the
other changes are applied.

> We can currently choose the wx version we link against using
> -DwxWidgets_CONFIG_OPTIONS="--toolkit=gtk2".  I'd prefer to retain that
> ability rather than having Cmake try to figure it out.  Maybe we make
> that option more user-friendly?

Do you mean a CMake flag? I have nothing against it.

Cheers,
Orson

1. https://bugs.launchpad.net/kicad/+bug/1786515



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

[Maciej Sumiński]

Hi Seth,

On 10/22/18 11:50 PM, Seth Hillbrand wrote:
> Hi Orson-
> 
> This looks very nice.  It works well for me with scripting off on Debian
> Stretch.  I had some issues with scripting on that I haven't encountered
> with the master branch but I suspect that this is a gtk2/3 issue because
> I can't see any scripting-related changes in the branch.

What are the issues? I agree that most likely culprit is gtk2/3 mix, but
I would rather be sure that I have not broken anything else. Since now
we are not bound to gtk2 anymore, I will add a patch to link KiCad
against wxWidgets version delivered with wxPython.

> BTW, the WorldUnitLength fix is a good bug find!  Does that need
> updating in Eeschema GAL as well?

You are right, I will update the constant as now bitmaps in eeschema are
not scaled correctly. IMHO the bug was not that serious, it has been
there since the GAL origin and I am sure we still would not have noticed
if GAL::DrawBitmap() had not referred to GAL canvas DPI.

Cheers,
Orson

> -S




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] ideas to improve patch and CI integration

[Maciej Sumiński]

Hi Thomas,

I like Gitlab, but it is a matter of taste and obviously the final word
belongs to Wayne. I think the main problem would be to transfer the bug
tracker and decide what to do regarding the mailing list.

Another point is a plan for a case when Gitlab turns evil. Currently
they offer Gold version to open source projects for free [1], but you
never know what will happen in a few years. Either we pay or host a
limited version (Community Edition) privately. I realize the same thing
may happen with Launchpad, the point is to decide whether we would be
satisfied with Gitlab Community Edition features.

You may also find insightful a discussion we head about moving KiCad
from Bazaar to Git [2].

Cheers,
Orson

1. https://about.gitlab.com/pricing/#gitlab-com
2. https://lists.launchpad.net/kicad-developers/msg25668.html


On 10/21/18 7:11 PM, Thomas Pointhuber wrote:
> Hi,
> 
> I think this topic will have many different point of views, but I think
> it is important to discuss it anyway.
> 
> I'm now about 5 years on the project, started as library maintainer and
> now sometimes with code contributions as well. I experienced at least a
> few different types of how software projects can be design of a
> management perspective to get work done.
> 
> Currently, there is the time where many big organizations (GNOME and
> freedesktop.org for example) moved their development to custom GitLab
> instances. And I would like to propose to think about that for KiCad as
> well. Not because everyone does it, but because it would benefit the
> project itself. There are various reasons I can think of right now:
> 
> * patches are sometimes simply forgotten on the mailing list
> * it is pretty hard to find old patches on the mailing list unless you
> have the e-mails stored on your account. You cannot search on launchpad
> * CI integration of patches is missing. People need to run them explicit
> before merging, or the automated build will fail at some point
> * getting CI runs for various systems requires explicit request due to
> missing automatization
> * no automated linter checks (would require us to reformat the project)
> * it's hard to track changes of patches, especially when modified,
> squashed,...
> * way better possibilities to view/edit/show history online
> * review tools on Launchpad are cumbersome and rarely used. This should
> be the standard in point of fact.
>   * easier to handle a proper review than with e-mail
> * easier to keep track how discussions evolved
> * the project is currently split between Launchpad and GitHub, this
> would allow us to combine all parts on one platform
> * GitLab would theoretically allow us add custom differs for library review
> * new contributors likely know GitHub/Gitlab workflow and can join more
> easily
> 
> I know this is quite some heavy proposal due to change of workflow and
> bug-migration. Nevertheless, we should at least discuss it.
> 
> PS: A college built a working GitLab CI script with export of build
> artifacts. GitLab integration of Jenkins would be possible as well.
> 
> Regards,
> Thomas



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

[Maciej Sumiński]

On 10/17/18 8:30 PM, Wayne Stambaugh wrote:
> Now that the Eeschema gal code has been merged into the development
> branch and things seem reasonably stable, we need to start thinking
> about the 5.1 release.  I would like to merge Thomas' python 3 code and
> Orson's cairo print code as soon as they are ready to go so we can get
> some additional testing.  Hopefully this will happen within the next
> week or so.  After about a month of bug fixing and polishing, I would
> like to tag rc1 around the Thanksgiving holiday.  The goal is to get 5.1
> released before FOSDEM 2019.  It will give me more good news to talk
> about during my presentation.
> 
> Cheers,
> 
> Wayne

To keep you updated: there is still one thing to be fixed in the
printing branch (bitmap scaling). I have already found the cause and I
am working on a proper fix. I think it should be ready to merge next
week, eeschema printing can come later.

I am also tempted to merge a recent Zoltant's patch adding an option to
control drill mark size. Let me know if that should wait for 6.0.

Cheers,
Orson



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

Re: [Kicad-developers] 5.1

[Maciej Sumiński]

On 10/18/18 9:48 PM, s...@hillbrand.org wrote:
> Hi Wayne-
> 
> We should probably start moving the default build on some Linuxes over
> to gtk3 as the gtk2/3 conflicts were one of the prime drivers to the
> GAL-legacy switch in eeschema.  This requires turning on
> -DUSE_WX_GRAPHICS_CONTEXT as well for these linuxes.
> 
> Unfortunately, this is an either/or in that Debian9 (and derivatives in
> Ubuntu) doesn't provide a python-wxgtk built against gtk2 and Debian
> 10/Ubuntu 18.04 don't provide python-wxgtk built against gtk3.
> 
> If we are keeping the Legacy canvas for 5.1, we'll need to iron out GTK3
> bugs.  This is potentially a not insubstantial amount of work as right
> now, GTK3 legacy view in pcbnew and gerbview does not display anything
> and a very garbled display in footprint editor.
> 
> How much effort do we want to expend on keeping legacy running in new
> systems?  Should we consider disabling legacy canvas if we enable GTK3
> in the build?  FWIW, GTK3 works fine for page layout editor and the
> various buttons and menus as far as I have found so far.  Also, GAL
> works as I expect
> 
> -Seth

Hi Seth,

As far as I remember there are two problems related to GTK versions:
- Having KiCad and wxPython build againt different toolkits results in
wxWidgets symbol conflicts when wxPython is loaded.

This issue should be resolved by linking KiCad against the same library
as is used for building wxPython.

- Rendering/printing problems in eeschema and pcbnew.

This one is already fixed by providing GAL renderer for eeschema and
pcbnew. As you have correctly noticed, legacy renderer is broken with
GTK3 in pcbnew and eeschema, so I think it is reasonable to disable it
there in the initial stage. Later, as Wayne says, we can remove the
legacy renderer in pcbnew to simplify significant parts of the code. The
one day eeschema will get the Tool Framework and can follow the pcbnew
example.

These steps should make KiCad GTK version agnostic and keep our users happy.

Cheers,
Orson



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

Re: [Kicad-developers] Janitor cleanup

[Maciej Sumiński]

Hi Seth,

I have just executed the script. FYI: 81 bugs fixed in 5.0.1, well done!

Cheers,
Orson

On 10/9/18 8:29 PM, Seth Hillbrand wrote:
> Hi Orson-
> 
> Do you have the janitor script that you used to bulk-mark the fixed bugs
> for 5.0?  If so, would it be possible to re-run that for 5.0.1?
> 
> Thanks-
> Seth



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] Cairo printing

[Maciej Sumiński]

Hi Jean-Pierre,

On 10/9/18 12:04 PM, jp charras wrote:
[snip]
> Hi Orson,
> 
> The transparency issue (specific to Cairo render) is a minor issue (see
> attached picture, especially the oval pad) on screen, but could be more
> annoying on printed documents.

Agreed, colors in printouts need to be opaque. I think the problem of
different colors in overlapping areas could be solved, but Cairo
documentation [1] says translucent colors are not supported on
PostScript surfaces and will result in rasterized images. It is bizarre
that I am not seeing this problem on Linux.

I have already patched my branch to use opaque colors for printouts.

> I forgot an other issue: bitmaps (added with the page layout editor) are
> incorrectly scaled (something like 10 times smaller) in the print preview.

Thank you for the report, I will check it.

Cheers,
Orson

1. https://www.cairographics.org/documentation/using_the_postscript_surface/



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] Cairo printing

[Maciej Sumiński]

Hi Simon,

On 10/8/18 3:19 PM, Simon Richter wrote:
> Hi,
> 
> On 10/08/2018 08:59 AM, Maciej Sumiński wrote:
> 
>> The only reasonable way to make wxDC and Cairo compatible is via
>> wxGraphicsContext, as it uses Cairo underneath.
> 
> wxDC also uses Cairo internally when wx is linked against GTK3. :P

True, but I am trying solve a GTK version compatibility problem, not add
one ;)

> Windows binaries for the cairo_printing branch can be found at
> 
> 
> http://downloads.kicad-pcb.org/windows/testing/patched/kicad-patched-142-3024ded91-x86_64.exe
> 
> in case anyone wants to help testing.

Many thanks, I really appreciate it!

Cheers,
Orson



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

Re: [Kicad-developers] Cairo printing

[Maciej Sumiński]

Hi Jean-Pierre,

On 10/8/18 3:08 PM, jp charras wrote:
[snip]
> Hi Orson,
> Very good job.
> 
> I tested the Cairo printing both on Windows and Linux.
> 
> No problem on Linux.
> On Windows, I have strange artifacts (see attached picture) in print
> preview.
> (more strange, if a zone outline includes the full board items, there
> are no, or very few, artifacts)

I will check it, but I am afraid it might be beyond my control. Do you
see it in actual printouts/PDFs as well?

> It happens only when the opacity of any printed item is not set to 1.0
> 
> Moreover, when the opacity of any printed item is not set to 1.0, the
> resulting printed picture is a bitmap (tested both using Cutepdf and a
> printer using a postscript driver), not really usable.
> (When all objects use a 1.0 opacity, the drawings are vectored, as expected)
> 
> Due to the fact transparency is not working very well on Cairo, and
> useless when printing a board with one sheet by layer, I suggest to
> force the opacity to 1.0 in any case.

That is surprising, I will need a closer look then. I would like to
preserve transparency, but I agree that getting bitmaps instead of
vector graphics is not acceptable.

Regards,
Orson



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

Re: [Kicad-developers] Cairo printing

[Maciej Sumiński]

Hi Zoltan,

Good catch, I have just fixed the problem in cairo_printing branch.

Regards,
Orson

On 10/8/18 10:49 AM, zgyarm...@zgyarmati.de wrote:
> Dear Maciej,
> 
> i checked out and compiled your branch, it builds properly (Ubuntu 18.04, 
> x86_64), but when i tested the print functionality, i noted that the marker 
> for the zone fill perimeter is visible on the printed layout, see attached 
> pdf 
> (printed into file via the normal print dialog) and a screenshot of the 
> fairly 
> simple board.
> 
> 
> Regards
> Zoltan Gyarmati
> https://zgyarmati.de



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] Cairo printing

[Maciej Sumiński]

On 10/7/18 10:05 PM, Wayne Stambaugh wrote:
[snip]
> This makes me nervous.  The gdiplus library brings wxGraphicsContext
> into play on windows.  Something from wxGraphicsContext is being pulled
> into the kicad build which can be enabled by configuring builds with
> -DUSE_WX_GRAPHICS_CONTEXT=ON.  I would have thought with cairo being
> both the display and print context that gdiplus would not be required
> for linking kicad.

Hi Wayne, Jean-Pierre,

Thank you for testing the code. I have already followed Tom's suggestion
and added gdiplus to linked libraries in my branch.

I wanted to take advantage of wxWidgets as much as I could, so I was
forced to work with wxDC. Otherwise I would have to go much deeper and
deal directly with CUPS and GDI+ to invoke a printing dialog and
actually start printing.

The only reasonable way to make wxDC and Cairo compatible is via
wxGraphicsContext, as it uses Cairo underneath. Have a look at
cairo_print.cpp [1] to see ugly details, but it is the only place where
I refer to gdiplus. I have not enabled USE_WX_GRAPHICS_CONTEXT on
purpose, as it seems to affect legacy canvases which is not needed here.

Cheers,
Orson

1.
https://git.launchpad.net/~orsonmmz/kicad/tree/common/gal/cairo/cairo_print.cpp?h=cairo_printing#n70



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

[Kicad-developers] Cairo printing

[Maciej Sumiński]

I have finished printing code refactor to take advantage of GAL in
pcbnew and gerbview [1]. This branch together with GALified
eeschema should cure GTK3-related headaches and lead us straight to 5.1.
In the meantime I will also try to port eeschema to the
new printing system for the sake of completeness, though it is not
critical for 5.1.

I have tested the code on Linux x86_64, Windows 7 x86_64 and macOS
10.13.4, but additional testing is welcome.

Cheers,
Orson

1. https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+ref/cairo_printing

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

Re: [Kicad-developers] [PATCH] Fix focus bug and possible race-condition for path deletion

[Maciej Sumiński]

Thank you Thomas, I have just pushed your patch to the master branch.

Cheers,
Orson

On 09/02/2018 08:59 PM, Thomas Pointhuber wrote:
> Ping: please review and merge this little patch
> 
> On 30.08.18 14:23, Thomas Pointhuber wrote:
>> Hi,
>>
>> a small follow-up patch for
>> https://bugs.launchpad.net/kicad/+bug/1788873 which fixes some remaining
>> issues
>>
>> Regards, Thomas
>>
>>
>> ___
>> Mailing list: https://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] SPICE models and library symbols

[Maciej Sumiński]

Hi Nhat,

There are fields dedicated to Spice model definitions, try to set a
model with the Spice Model editor dialog (in the Component Properties
dialog [1]) and notice that new fields will appear.

Cheers,
Orson

1. http://docs.kicad-pcb.org/5.0.0/en/eeschema.html#_assigning_models

On 08/13/2018 10:31 PM, Nhat Khai wrote:
> Sorry to a long email and my english. But here is my though. I can be
> wrong, so please don't be angry.
> Here is my case of use:
>   I have a lot of SUBCKT models (100+), and modified/customized SUBCKT
> models with parameters. In KiCad4, I using the default value of
> symbol/component to refer to default model. Later on in project, I can
> change that value point to my own SUBCKT model with some parameter
> specified for special case of simulation. It doable in KiCad4, but text in
> component's value some time look long and ugly. So it would be nice to have
> keep it compatible and following:
>   a. KiCad understand SUBCKT parameter and allow user to set these values
> -- Give KiCad a gateway to support ~90% of most simulation needed without
> understand resistor, voltage, current model ... etc.
>   b. KiCad give user option to stick with value (backward compatible) or
> use alternative field (one or more) for specifications the spice model.
>   c. These alternative field can be hide or visible just like any other
> normal field.
>   d. Using fields, all the model parameters can be just be export as BOM.
> Allow user to ensure they don't make mistake. Great visibility over 100+
> model all at one.
>   e. The .cir file allow user option to how to managing their spice library
> that fit there own workflow. (Using normal editor, look at 100+ model all
> at one in one file, source control in the spice language, no need to learn
> another KiCad language to look at the git diff,...etc).
> 
> I think, embedding spice model into symbol is nice but is have issues:
> 1. Visibility of the model is hard to access (one by one). It is trouble
> some to verify 100 spice model all at once.
> 2. User tent to not trust spice model where I don't know about it, or where
> it comes from. (they will refer to download directly form manufacture, or
> their customized version.
> 
> Also, embedding spice model into the component is nice in eeschema, but is
> have similar issue:
> 1. Visibility of the model have is one by one.
> 2. Here is one of my resistor value for simulation: "{2k*0.9026} tc1=4.21m
> tc2=4.427u dtemp=27". Current KiCad5 don't understand this. However, I
> don't expect it understand it like KiCad4 did. But if it understand the
> simple SUBCKT then I can use it and pass in parameters, and help it more
> readable, and my life easier :-).
> 
> KiCad simulation seem to missing a generic mode for the unexpected
> simulation types. Which again, in my case is temperature sweep or can be
> multi-parameter sweeps. It think the effort to have it recognize are
> beautiful. But generic simulation should be the most importance one to
> cover first. Meaning, it don't event need to understand the simulation type
> and still able to plot the result. My case, I use spice directive to
> specify my unusual simulation, and no matter how I specify it, current
> simulation tool should able to plot result after simulation finished (is
> the best I can dream of). Current it is not, if it don't understand what
> type of simulation I'm doing (witch again I think it don't have to).
> 
> 
> 
> ___
> Mailing list: https://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] MacOS build issue with new geometry tests

[Maciej Sumiński]

Hi John,

Thanks for the patch. I have had the same problem compiling KiCad with
clang and I confirm that the proposed fix solves the problem, so I
merged it.

Cheers,
Orson

On 07/29/2018 05:34 PM, John Beard wrote:
> Hi Adam,
> 
> Sorry, this in my stuff - I though that was a way to get PI without
> having to guess the setting of _USE_MATH_DEFINES or do #ifdefs like at
> the top of dl_codes.h, but obviously not.
> 
> The attached patch might work, but I can't test on a Mac, so all I can
> say is "it builds for me and the tests pass". Specifically,
> _USE_MATH_DEFINES may need to be set for qa_geometry if not already.
> 
> Cheers,
> 
> John
> 
> 
> On Sun, Jul 29, 2018 at 1:38 PM, Adam Wolf
>  wrote:
>> Hi folks!
>>
>> There's a build failure on the new geometry test stuff with MacOS.
>>
>> qa/geometry/geom_test_utils.h:33:18: error: constexpr variable 'PI'
>> must be initialized by a constant expression
>> constexpr double PI = atan(1.0) * 4.0;
>> ^ ~~~
>> qa/geometry/geom_test_utils.h:33:23: note: non-constexpr function
>> 'atan' cannot be used in a constant expression
>> constexpr double PI = atan(1.0) * 4.0;
>>
>> There are a few others, all which look about the same.  I am on my way
>> out of town today so I don't have time to look for a solution, but a
>> user actually reported it to me due to using the new MacOS build
>> scripts! :D
>>
>> Adam Wolf
>>
>> ___
>> Mailing list: https://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] Fix CMakeLists.txt

[Maciej Sumiński]

Hi Marcus,

Actually my memory has let my down this time. I have just checked the
patch on msys2 and it worked as expected, so I recommitted the original
version. Sorry for the noise.

Cheers,
Orson

On 07/26/2018 11:36 PM, Aimylios wrote:
> Hi Orson,
> 
> thank you for taking the time to review and merge my patches!
> 
>> Thank you for the patches, I have just merged them. I have slightly
>> modified the last patch - I realize that you used the correct convention
>> for calling execute_process(), but IIRC it did not work with msys2.
>> Therefore I simply added the suggested ${wxWidgets_CONFIG_OPTIONS} to
>> the command line and preserved "sh -c".
> 
> Unfortunately, your modified version of my third patch does not work for
> me. The reason is that wxWidgets_CONFIG_OPTIONS is of type LIST (not
> STRING).
> 
> This is the command I use to configure KiCad:
> cmake \
>     -DKICAD_SCRIPTING_WXPYTHON=OFF \
>     -DKICAD_SPICE=OFF \
>     -DCMAKE_BUILD_TYPE=Release \
>     -DwxWidgets_CONFIG_EXECUTABLE=/usr/bin/wx-config \
>     -DwxWidgets_CONFIG_OPTIONS=--toolkit=gtk2 \
>     .
> 
> With this, the expression:
> sh -c "${wxWidgets_CONFIG_EXECUTABLE} ${wxWidgets_CONFIG_OPTIONS}
> --query-toolkit"
> 
> evaluates to:
> sh -c "/usr/bin/wx-config --toolkit=gtk2;--static=no --query-toolkit"
> 
> and the semicolon (which separates the elements of the list) terminates
> the command line. Consequently, both --static=no and --query-toolkit are
> dropped. Instead, you get an error message like "sh: --static=no:
> command not found." and the build script incorrectly assumes that GTK2
> is used, even if we added --toolkit=gtk3 before.
> 
> I don't have an msys2 build environment, but maybe someone who has can
> try to check if your memory serves you right and the "correct
> convention" does not work.
> We might then have to find an alternative solution. But I am not a CMake
> guru, so any help is appreciated.
> 
> Best regards,
> Marcus




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

[Maciej Sumiński]

On 07/25/2018 11:23 AM, Carsten Schoenert wrote:
> Hello Orson,
> 
> Am 25.07.18 um 15:53 schrieb Maciej Sumiński:
> ...
>> It has been discussed in this thread already, but I will repeat: the
>> main problem now is that we need to apply patches to both master and
>> 5.1.
> 
> thanks for clarifying (probably again).
> The question will come again and again, unless it's written down to a
> road map where it can be referenced to. I haven't found anything related
> to this on the website and I also haven't time to follow any thread in
> deep here on the ml which is more technical, but it's also interesting
> for me as the person who is doing the Debian packaging where the
> developing will move to and what are the plans for which release.
> 
> Why not discuss the goals which are targeted for 5.1.x (now mostly
> already happen) and make this public (as a blog post on the website
> e.g.)? This can be used later while developing to see how far the next
> release is. I think the current development isn't that transparent
> that's for sure not intended.

A blog post sounds like a good idea, I have noticed the current plan is
not very clear for everyone.

>> This is fairly easy now, as there are no new features in the master
>> branch yet, but if we merged all the feature branches then I think we
>> would spend too much time resolving conflicts. There is no point nor
>> manpower to develop two branches in parallel.
> 
> Sorry, I don't get this or I don't understand this really. If you say
> this you will also constrain the development to only work in serial mode
> like happen a decade ago while Subversion was a modern VCS and all needs
> mostly done in just one branch. I don't think this is wanted as this
> would mean you bothersome people who want to work on features for 6.x to
> delay their work. And this is normally the last thing you wanna do.
> That's part of the development projects needs to handle and deal with.
> Git gives the possibility to get this managed, the only thing you need
> to be clear is to know which branch needs to be merged into another.
> And, yes this needs manpower to handle releases, but this needs to be
> done anyway. To say there is no manpower would be a wrong thing to me,
> as this has will have a huge impact just later. As I tried to express in
> one of my previous emails I think it's important KiCad will get a better
> policy for development and also for release planning.
> 
> All above is just my personal view and I don't want to enforce the
> "real" developers to do something exactly in this way. The developers
> are deciding what to do and how, so I don't want to bother any of you.

Nobody forbids working on new features in separate branches that we will
start merging once 5.1 is released and 6.0 development cycle starts. I
have already started a few branches for v6 features, but they need to
wait now. I simply rebase them from time to time, but it is not a big
deal so far. I anticipate GTK3 fixes to be ready in 1-2 months from now,
I am not sure if the delay is significant enough to keep this discussion
going on.

We have already experienced a significant overhead in late v5 cycle due
to porting certain v4 fixes to v5 branch or vice versa. Imagine that we
keep working on 5.1 and 6.0 at the same time. I am sure we could right
now dump enough code onto the 6.0 branch to diverge it from 5.1 so much
that porting fixes between them becomes non trivial. Keep in mind that
there is 5.0 branch that may need to share some patches with the
remaining branches too. Please notice that *every* patch that we applied
to 5.1 had to be applied to the master branch as well via
cherry-picking. What are the benefits of maintaining 3 branches?

Cheers,
Orson



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

Re: [Kicad-developers] Branches

[Maciej Sumiński]

On 07/25/2018 04:28 AM, Carsten Schoenert wrote:
> Am 24.07.18 um 15:01 schrieb Maciej Sumiński:
>> At the moment the master branch contains all commits from 5.1 and a few
>> more. It might be the right moment to drop 5.1 branch.
> 
> This depends on the achievements which are desired or wanted in my eyes.
> 
> The branch 5.1 was created to work on the planned releases 5.1.x, right?
> Dropping this branch would mean all further work would done only in the
> master branch. I'm not sure this is really wanted as it's need to be
> ensured that all releases are backwards compatible to the current 5.0.0
> release without breaking potential work done from people targeted post
> 5.x. KiCad will need some kine of release managing in the near future I
> guess.
> 
> It seem to me that there are at least some potential confusion exists
> about the intention of feature branches, nothing more are the existing
> branches 5.1 and master.
> 
> But as long there is no agreement what should happen to which release it
> will be messy all the time. Is this somewhere documented what will
> happen to 5.1 especially?

There is no document regarding 5.1 goals, as I think it is too brief to
make it formal: wxGTK3 fix is the main goal, minor UI improvements and
bugfixes are acceptable, no new features in 5.1. We want to push it out
as soon as possible so we can move on with 6.x.

It has been discussed in this thread already, but I will repeat: the
main problem now is that we need to apply patches to both master and
5.1. This is fairly easy now, as there are no new features in the master
branch yet, but if we merged all the feature branches then I think we
would spend too much time resolving conflicts. There is no point nor
manpower to develop two branches in parallel.

Cheers,
Orson



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

Re: [Kicad-developers] Hotkeys in GAL

[Maciej Sumiński]

Hi John,

On 07/24/2018 07:21 PM, John Beard wrote:
> Hi,
> 
> I have a few questions about hotkeys in GAL tools:
> 
> 1) Is there are reason so many GAL tools don't get hotkeys?
> 
> Very many TOOL_ACTIONS have a hotkey set to '0'. Most others that do
> have a hotkey have a LegacyHotkey definition. Only a very few have the
> GAL-style keys (e.g. rotate CW).
> 
> I think nearly all GAL tools should have a hotkey assignable, even if
> they default to unassigned. It's quite limiting to not be able to
> access some tools except by the menu. (This may mean some tools need
> defences against being called even when the menu item is disabled.)

I would not mind adding more hotkeys, I think the primary reason is that
not every action is executed often enough to justify a hotkey. Even with
the current configuration it might be challenging to find a free hotkey
for an action.

The initial idea was to list all TOOL_ACTIONs in the hotkey editor, so
the user may decide for himself which actions should have a hotkey
assigned. It might be somewhat tricky to implement with legacy canvas
still in place, so perhaps the right moment will come when legacy canvas
is out.

> 2) Is it/will it be supported to have the same hotkey for multiple
> contexts? For example, say there's an AS_GLOBAL action using "G".
> However, when you're in a tool mode, that could be overridden by a
> AS_CONTEXT action that only makes sense in that tool.
> 
> This already sort of works, *but* the hotkey dialog does not like
> duplicate keys, even when one is global and one is contextual. Can
> this be changed, or is it pending removal of the legacy canvas and
> hotkey system first?

As I said, it might be difficult to make the hotkey editor handle two
sets of hotkey configurations. I imagine we could have subsections in
the editor that are specific to tools and these would be acceptable
duplicates with global and other contexts hotkeys. I am open to other
ideas too.

Cheers,
Orson

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




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] Adding "Apply" to the 3D viewer display options dialog

[Maciej Sumiński]

Select the Apply button you want to handle, and in the Object Properties
panel, Events tab - add an event handler. It will be added to the
generated *_BASE class and all you need to do is override it.

Cheers,
Orson

On 07/24/2018 09:10 AM, David Griffith wrote:
> 
> I'm at a loss to figure out what to edit to get the display options
> dialog for the 3D viewer to do the right thing when an "Apply" button is
> pressed. I got the new button added by way of wxFormBuilder.  But
> looking at 3d-viewer/3d_viewer/dialogs/dialog_3D_view_option.cpp, I
> can't figure out how to get it working.  I don't see how OK or Cancel
> are processed, so I can't use them as a model.
> 
> 




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

[Maciej Sumiński]

...and also rename it to 5.1-dev (no rc yet).

On 07/24/2018 09:47 AM, Jeff Young wrote:
> +1
> 
>> On 24 Jul 2018, at 08:01, Maciej Sumiński  wrote:
>>
>> At the moment the master branch contains all commits from 5.1 and a few
>> more. It might be the right moment to drop 5.1 branch.
>>
>> Cheers,
>> Orson



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

Re: [Kicad-developers] Branches

[Maciej Sumiński]

At the moment the master branch contains all commits from 5.1 and a few
more. It might be the right moment to drop 5.1 branch.

Cheers,
Orson

On 07/20/2018 11:14 AM, Maciej Sumiński wrote:
> We already have slightly diverged the branches, I think it shows that it
> is hard to maintain two branches with cherry-picking. Details below:
> 
> Commits present in master, but not in 5.1:
> commit c585964da98269db2cabf06daafb0b11cae3a4ec
> fix coding style issues.
> 
> commit 840ad7f68053d000dc6d46661d05d9d4be074704
> Add SH_ARC collisions
> 
> commit 01c5bdfb8f49a84f2e5fae5c7fc5729a47c8ef0f
> Fix bug with duplicate columns in Edit Symbol Fields.
> 
> 
> Commits present in 5.1, but not in master:
> commit 42deb68575a5a415b0970be4a89676f1986fa196
> Eeschema: minor fix in edit label dialog (incorrect unit value )
> 
> On 07/19/2018 07:08 PM, Wayne Stambaugh wrote:
>> This was pretty much how I saw the development working which is why I
>> created a separate 5.1 branch.  However, if we are not going to allow
>> new features to be merged into the master branch (6.0-dev) (and it seems
>> that is the consensus) then I propose that we do all of the 5.1
>> development in the master branch.  I would rather not delete the 5.1
>> branch because the tags and version strings are already in place and
>> reverting all the changes thus far would be painful.  Assuming 5.1 and
>> master are currently the same, we can either merge from master to 5.1 as
>> we go or one big merge when we are ready to start creating 5.1 release
>> candidates.  I would prefer that we merge as we go which will keep the
>> two branches synced an minimize issues.  Is this acceptable to everyone?
>>
>> On 7/19/2018 12:15 PM, Carsten Schoenert wrote:
>>> Hi,
>>>
>>> for me as a person which doesn't do any active source code development
>>> on KiCad it looks like there is some confusion in the wild what will or
>>> should happen in which branch.
>>>
>>> Sorry if I haven't get it until now, what are the goals of the branch
>>> 5.1 the project wanted to archive?
>>>
>>> And what is 6.0, master or $(what else) are for?
>>>
>>> If these questions can be answered it will be much more clear what
>>> development should happen in which branch and what should be merged into
>>> which other branch.
>>>
>>> KiCad has now more active developers than ever I think, but I can't
>>> really see a branch model that is fitting the current and future
>>> situations. Out there are various branching models and the KiCad project
>>> needs to decide which will work best for the project. The classical
>>> master plus release branches isn't working great anymore if you want to
>>> work on multiple parts in parallel.
>>>
>>> I suggest to have a look at the following website.
>>>
>>> https://nvie.com/posts/a-successful-git-branching-model/
>>>
>>> It describes what options are count and how a workflow would look like,
>>> I think it would be also usable for KiCad (not in a full blown version).
>>>
>>> In the long term you wont do cherry-picking for the plain development as
>>> this wont work smoothly at one point anymore (as Wayne already
>>> mentioned). Single cherry-picking is fine, but in the end you will come
>>> to merge commits as you mostly want to have all the new code in a later
>>> release. Every upstream project I know is working this way.
>>>
>>> Backporting security or hot fixes are slightly different and require
>>> often cherry-picking with small or much modifications as you wont
>>> introduce new features into old code by merges. But also this can be
>>> done in a local feature branch which gets merged then into the stable
>>> release branch. Depends mostly on the amount of the needed backport.
>>>
>>> So to call it again, what is the branch 5.1 intended for? Only for the
>>> GTK+3 fixes? If yes it's fine to do it here and merged these changes
>>> (which will be needed also in the current ongoing nightly development)
>>> into master, develop, 6.0 or what ever named branch. Just renaming
>>> master into something different without a common and required workflow
>>> is nothing, then it's really just another name.
>>>
>>> So I would propose the following as there are already some branches out
>>> there which we all need to know and to handle.
>>>
>>> 5.0 will get all the fixes which will reflect in versions 5.0.x, commits
>>> will mostly get cherry-pic

Re: [Kicad-developers] KIDIALOG broken

[Maciej Sumiński]

Hi Wayne,

On 07/23/2018 05:40 PM, Wayne Stambaugh wrote:
> In the process of fixing this bug
> https://bugs.launchpad.net/kicad/+bug/1782708 I discovered that the
> KIDIALOG object called when editing an externally defined environment
> variable will completely lock up kicad on windows.  Clicking the dialog
> OK button or hitting the escape keep does not close the dialog and I
> have to manually kill the running kicad process.  When I convert this
> code over to use wxRichMessageDialog directly, it works as expected.
> It's possible that wxRichMessageDialog::ShowModal() does not like being
> overridden.  Will someone check to see if this issue occurs on macos or
> linux?

I have just tried to recreate the mentioned bug report on Linux, but it
works fine here. I have successfully changed the path, got the dialog
displayed and confirmed everything by clicking OK.

> Also, what is the purpose of the "Do not show this message again"
> checkbox when it's only for the current session?  Generally speaking
> checking this option would not show the message forever.  This seems
> like it would be confusing to the user.

It is the same kind of relief you get with wxWidgets asserts. If there
is a window that will keep nagging you because you have done something
wonky on purpose, then you have a choice to ignore a warning dialog
instead of straining your finger. I have added this option to handle
warnings about malformed polygons, as without do-not-show-again checkbox
you can spend a lot of time closing warnings before you even get a
chance to fix polygons.

Cheers,
Orson

> Cheers,
> 
> Wayne



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

[Maciej Sumiński]

We already have slightly diverged the branches, I think it shows that it
is hard to maintain two branches with cherry-picking. Details below:

Commits present in master, but not in 5.1:
commit c585964da98269db2cabf06daafb0b11cae3a4ec
fix coding style issues.

commit 840ad7f68053d000dc6d46661d05d9d4be074704
Add SH_ARC collisions

commit 01c5bdfb8f49a84f2e5fae5c7fc5729a47c8ef0f
Fix bug with duplicate columns in Edit Symbol Fields.


Commits present in 5.1, but not in master:
commit 42deb68575a5a415b0970be4a89676f1986fa196
Eeschema: minor fix in edit label dialog (incorrect unit value )

On 07/19/2018 07:08 PM, Wayne Stambaugh wrote:
> This was pretty much how I saw the development working which is why I
> created a separate 5.1 branch.  However, if we are not going to allow
> new features to be merged into the master branch (6.0-dev) (and it seems
> that is the consensus) then I propose that we do all of the 5.1
> development in the master branch.  I would rather not delete the 5.1
> branch because the tags and version strings are already in place and
> reverting all the changes thus far would be painful.  Assuming 5.1 and
> master are currently the same, we can either merge from master to 5.1 as
> we go or one big merge when we are ready to start creating 5.1 release
> candidates.  I would prefer that we merge as we go which will keep the
> two branches synced an minimize issues.  Is this acceptable to everyone?
> 
> On 7/19/2018 12:15 PM, Carsten Schoenert wrote:
>> Hi,
>>
>> for me as a person which doesn't do any active source code development
>> on KiCad it looks like there is some confusion in the wild what will or
>> should happen in which branch.
>>
>> Sorry if I haven't get it until now, what are the goals of the branch
>> 5.1 the project wanted to archive?
>>
>> And what is 6.0, master or $(what else) are for?
>>
>> If these questions can be answered it will be much more clear what
>> development should happen in which branch and what should be merged into
>> which other branch.
>>
>> KiCad has now more active developers than ever I think, but I can't
>> really see a branch model that is fitting the current and future
>> situations. Out there are various branching models and the KiCad project
>> needs to decide which will work best for the project. The classical
>> master plus release branches isn't working great anymore if you want to
>> work on multiple parts in parallel.
>>
>> I suggest to have a look at the following website.
>>
>> https://nvie.com/posts/a-successful-git-branching-model/
>>
>> It describes what options are count and how a workflow would look like,
>> I think it would be also usable for KiCad (not in a full blown version).
>>
>> In the long term you wont do cherry-picking for the plain development as
>> this wont work smoothly at one point anymore (as Wayne already
>> mentioned). Single cherry-picking is fine, but in the end you will come
>> to merge commits as you mostly want to have all the new code in a later
>> release. Every upstream project I know is working this way.
>>
>> Backporting security or hot fixes are slightly different and require
>> often cherry-picking with small or much modifications as you wont
>> introduce new features into old code by merges. But also this can be
>> done in a local feature branch which gets merged then into the stable
>> release branch. Depends mostly on the amount of the needed backport.
>>
>> So to call it again, what is the branch 5.1 intended for? Only for the
>> GTK+3 fixes? If yes it's fine to do it here and merged these changes
>> (which will be needed also in the current ongoing nightly development)
>> into master, develop, 6.0 or what ever named branch. Just renaming
>> master into something different without a common and required workflow
>> is nothing, then it's really just another name.
>>
>> So I would propose the following as there are already some branches out
>> there which we all need to know and to handle.
>>
>> 5.0 will get all the fixes which will reflect in versions 5.0.x, commits
>> will mostly get cherry-picked from master. Hopefully not that much.
>>
>> 5.1 will get at least the GTK+3 adjustments and will finally cover all
>> versions 5.1.x (like 5.0 for 5.0.x). The GTK stuff is developed in this
>> branch and will be merged into master. Any other changes than GTK+3
>> which should be released with versions 5.1.x are also made here and get
>> merged into master.
>>
>> master is and will be the main nightly development channel. All changes
>> here are mainly for any releases greater than 5.x.x.
>>
>> This all are just my thoughts as I would like to see it, the above
>> suggestion is based on some experiences I have made with other projects
>> and work. Please remember that also the l10n and documentation trees are
>> related to this! The base for all future work for all side needs to be
>> clear early as possible.
>>
>> Anyhow ...
>>
>> (Hmm, I don't wanted to a top posting but my answer wasn't 

Re: [Kicad-developers] Janitor commits missing

[Maciej Sumiński]

Some new issues popped up when I added support for multiple branches in
the Janitor script. I hope the problems are fixed now, sorry for the
inconvenience.

Cheers,
Orson

On 07/17/2018 07:10 PM, Seth Hillbrand wrote:
> ​Hi Orson-
> 
> I'm seeing Jeff's cherry-picked commits being processed by Janitor but they
> seem to be missing the reference to the commit that previous Janitor log
> messages had.
> 
> Is this intentional in how Janitor handles cherry-picks?
> 
> -S​
> 
> 
> 
> ___
> Mailing list: https://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] Branches

[Maciej Sumiński]

It will be a huge motivation for us to fix GTK3 problems as soon as
possible. I assume you mean to drop the current master branch (or rename
to 6.0?) and make 5.1 the new master branch?

On 07/19/2018 05:19 PM, Wayne Stambaugh wrote:
> You are preaching to the choir.  I did most of the maintenance on the
> 4.0 branch.  Initially it was easy but it didn't take long for it to
> become a PITA.  If no one else objects, I would be more than happy to
> make that the policy.  If that is indeed what we want to do, I would
> delete the 5.1 branch.  It will push v6 development back significantly.
> 
> On 7/19/2018 11:10 AM, Jon Evans wrote:
>> FWIW, as someone who is also maintaining parallel feature branches, I
>> agree with Orson and John.  Now that we have committed to this 5.1 idea,
>> we should just make it happen in master.  I think if we keep both master
>> and 5.1 branch running in parallel, inevitably one or the other of them
>> will be less tested / more broken unless people spend a bunch of time
>> doing the work of keeping them synchronized manually.  The cost of this
>> doesn't seem to outweigh the benefit of being able to merge some 6.0
>> features into master sooner.
>>
>> On Thu, Jul 19, 2018 at 11:03 AM John Beard > > wrote:
>>
>> On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh
>> mailto:stambau...@gmail.com>> wrote:
>> > Unless we are going to prohibit new features (new file formats,
>> new tool
>> > framework for eeschema, etc.) from being merged into the dev branch
>> > until 5.1 is released, I disagree.  If we want to only work on 5.1 in
>> > the dev branch, then I'm OK with this proposal.
>>
>> This is essentially my proposal - limit dev branch changes to 5.1
>> features, uncontroversial maintenance and bugfixes.
>>
>> If people want to work on features for 6 now, that can be done in
>> separate branches, and the onus for keeping it rebased onto the 5.1
>> changes is on them, rather than forcing the 5.1 workers to deal with
>> conflicts. Otherwise, whoever is working on 5.1 features like the
>> GTK3/GAL stuff and printing, will have to continually port their work
>> between the two branches.
>>
>> If 5.1 changes are unlikely to be substantially affected by 6.0-facing
>> changes, then perhaps this limitation is not useful.
>>
>> > There should be nothing in the 5.1 branch that is not also in the dev
>> > branch so everything in the 5.1 branch should be tested in the dev
>> > branch builds.
>>
>> In theory, yes, but if fixes need to be manually ported as the
>> branches diverge, it's possible to fail to fix, or break in new ways,
>> one branch or the other. If a 5.1 branch exists in parallel to 6.0,
>> someone will have to take responsibility to ensure the appropriate
>> fixes are identified, ported and tested as needed. In the Linux world,
>> this is the unglamorous, arduous (and vital) job of the stable branch
>> maintainers.
>>
>> I'm not against parallel branches if someone is willing to step up to
>> be a stable branch maintainer for 5.1. In fact, I'd be thrilled to get
>> nice new stuff dropping into the dev branch. However, changes that
>> need to be in both branches are not trivially rebasable, that job will
>> soon become decidedly not-fun.
>>
>> Cheers,
>>
>> John
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> 
>> Post to     : kicad-developers@lists.launchpad.net
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> 
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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] 5.1 branch

[Maciej Sumiński]

Hi Jeff,

Yes, for the moment we work to replace wxDC only in places that really
need it. So far it was necessary in pcbnew to boost performance, now
eeschema suffers the same problem with GTK3.

Cheers,
Orson

On 07/18/2018 01:06 PM, Jeff Young wrote:
> Hi Tom, et al,
> 
> I assume we just need to drop wxDC for the canvas, but that UI constructs 
> (such as colour swatches, etc.) would continue to use wxDC?
> 
> Thanks,
> Jeff.
> 
> 
>> On 17 Jul 2018, at 15:44, Tomasz Wlostowski  
>> wrote:
>>
>> On 16/07/18 17:54, Wayne Stambaugh wrote:
>>> I was really hoping just to fix the wxDC issues with GTK3 rather than
>>> implement GAL unless Tom implemented a wxDC GAL and that is all we
>>> expose for 5.1.  The primary goal here is to fix the GTK3 rendering
>>> issues so we can enable wxPython support again.  We need to limit our
>>> risk exposure for 5.1.
>>>
>> Hi Wayne,
>>
>> The sooner we drop wxDC, the better for Kicad. I wouldn't do it because
>> of the GTK3/Python issues (since it's a neverending Linux problem of
>> changing APIs and libraries), but for performance reasons - on OSX for
>> instance, eeschema is sometimes barely usable because of slow drawing.
>>
>> I hope I'll be able to devote some time to cleaning up the eeschema-gal
>> code in the coming weeks. So far, the main canvas and the library editor
>> are implemented, with the symbol preview widgets & library browser
>> remaining.
>>
>>
>>> I'm assuming the printing is a v6 goal.
>>
>> Orson made quite a lot of progress with Cairo printing. IIRC it can make
>> it to the 5.1.
>>
>> Cheers,
>> Tom
>>
>>>
>>> On 7/16/2018 11:15 AM, Maciej Sumiński wrote:
>>>> Tom has already prepared a proof-of-concept eeschema with GAL rendering,
>>>> which still uses the legacy tools. I have some promising results
>>>> switching the printing system to Cairo GAL. Obviously we will face some
>>>> unexpected obstacles, but I have high hopes.
>>>>
>>>> Cheers,
>>>> Orson
>>>>
>>>> On 07/16/2018 03:40 PM, Wayne Stambaugh wrote:
>>>>> Yes, assuming we can get that to work without dragging in Phoenix.
>>>>>
>>>>> On 7/16/2018 9:27 AM, Jeff Young wrote:
>>>>>> 5.1 is also for the GTK3 fixes, right?
>>>>>>
>>>>>>> On 16 Jul 2018, at 14:23, Wayne Stambaugh  wrote:
>>>>>>>
>>>>>>> On 7/16/2018 9:19 AM, Simon Richter wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 15.07.2018 13:39, Jeff Young wrote:
>>>>>>>>
>>>>>>>>> I renamed my 6.0 branch to 5.1, since most of what it contains goes 
>>>>>>>>> there.
>>>>>>>>
>>>>>>>> What is the difference between 5.1 and 6.0? What goes into which 
>>>>>>>> branch?
>>>>>>>>
>>>>>>>>  Simon
>>>>>>>>
>>>>>>>
>>>>>>> 5.1 is only for the UI refactoring Jeff is working on along with any bug
>>>>>>> fixes that get merged into the 5.0 branch.  Any new features such as the
>>>>>>> new schematic file formats or GALification of eeschema are v6 only.
>>>>>>>
>>>>>>> ___
>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>> Post to : kicad-developers@lists.launchpad.net
>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>
>>>>> ___
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to : kicad-developers@lists.launchpad.net
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to : kicad-developers@lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://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

[Kicad-developers] Branches

[Maciej Sumiński]

I wonder if there is a point in keeping 5.1 and master branches
separated. In 5.1 there is a lot of new code that will need patches, and
they need to be applied to both branches now. If we keep adding more
features to the master branch, then at one point the branch may diverge
significantly enough to make patch porting non trivial.

What do you think about replacing the current master branch with 5.1?
This way we can focus on the wxGTK3 problem, fix issues that we discover
and once 5.1 is out - keep adding new features to 6.0-dev? For the time
being new features might be developed in private branches.

BTW. I really like 5.1 UI improvements, good job Jeff!

Cheers,
Orson



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

Re: [Kicad-developers] Signed Installers

[Maciej Sumiński]

Hi Simon,

The installer works well, no warnings observed here. Do you think you
could create one for 5.0.0 stable and upload it to windows/stable directory?

Cheers,
Orson

On 07/19/2018 01:17 AM, Simon Richter wrote:
> Hi,
> 
> I've just rebuilt the latest MSYS2 nightly and the rc3 package in
> /windows/testing with signing enabled, so these should now install with
> fewer complaints.
> 
>Simon
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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] Stable 5 release.

[Maciej Sumiński]

Tell me if I am wrong, but I start to believe we are going to publish v5
this Friday. Is there anything missing I could help with? Do we have the
website updates ready?

Cheers,
Orson

On 07/11/2018 08:49 PM, Wayne Stambaugh wrote:
> Are there any critical bugs remaining to be fixed for the stable 5
> release?  I didn't see any thing outstanding but I may have missed
> something while I was on vacation.  I'm going to create a 5.0.0
> milestone for the last few remaining bugs and shoot for a 7/20 tag date
> unless there are any more critical bugs lurking about.  I will also
> create 5.0 and 5.1 branches.  If I tag on 7/20, I would like to make the
> release announcement on 7/27.  Does anyone see any issues with these dates
> 
> How do stand with our installers?  I saw the macos installer was making
> some nice progress.
> 
> Are the doc devs, library devs, and translators (except for the recent
> minor string changes) ready?
> 
> Is there anything else I'm missing?  I really would like to make these
> dates.  I have an Olimex TERES laptop kit that I've been dying to play
> around with but I know once I start on that, everything else will get
> pushed to the back burner so I'm not going to start until version 5 is
> released. :)
> 
> Cheers,
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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] Janitor commits missing

[Maciej Sumiński]

It should work fine now. After I had ran the clean-up script, the
credentials file was overwritten by another user, depriving the web
server access rights. Fortunately there is no ban for massive bug status
update.

Cheers,
Orson

On 07/18/2018 08:51 AM, Maciej Sumiński wrote:
> Hi Seth,
> 
> I have noticed it too. There is no special treatment for cherry-pick
> commits, the only thing Janitor cares about is 'Fixes' line.
> 
> I checked the logs and apparently Janitor is unable to log in to
> Launchpad. I hope that the recent bug statuses clean up has not granted
> him a ban for sending too many requests. I will investigate it.
> 
> Cheers,
> Orson
> 
> On 07/17/2018 07:10 PM, Seth Hillbrand wrote:
>> ​Hi Orson-
>>
>> I'm seeing Jeff's cherry-picked commits being processed by Janitor but they
>> seem to be missing the reference to the commit that previous Janitor log
>> messages had.
>>
>> Is this intentional in how Janitor handles cherry-picks?
>>
>> -S​
>>
>>
>>
>> ___
>> Mailing list: https://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] Janitor commits missing

[Maciej Sumiński]

Hi Seth,

I have noticed it too. There is no special treatment for cherry-pick
commits, the only thing Janitor cares about is 'Fixes' line.

I checked the logs and apparently Janitor is unable to log in to
Launchpad. I hope that the recent bug statuses clean up has not granted
him a ban for sending too many requests. I will investigate it.

Cheers,
Orson

On 07/17/2018 07:10 PM, Seth Hillbrand wrote:
> ​Hi Orson-
> 
> I'm seeing Jeff's cherry-picked commits being processed by Janitor but they
> seem to be missing the reference to the commit that previous Janitor log
> messages had.
> 
> Is this intentional in how Janitor handles cherry-picks?
> 
> -S​
> 
> 
> 
> ___
> Mailing list: https://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] 5.1 branch

[Maciej Sumiński]

On 07/16/2018 05:54 PM, Wayne Stambaugh wrote:
> I was really hoping just to fix the wxDC issues with GTK3 rather than
> implement GAL unless Tom implemented a wxDC GAL and that is all we
> expose for 5.1.  The primary goal here is to fix the GTK3 rendering
> issues so we can enable wxPython support again.  We need to limit our
> risk exposure for 5.1.

There is no new wxDC GAL backend implemented, which IMHO reduces the
risk as Cairo backend has been already tested a bit. Staying with two
rendering engines also reduces the amount of code to maintain.

I have already spent some time trying to fix GTK3 problems, both in
eeschema and in pcbnew. GTK3 fixes in eeschema resulted in a slight
performance drop, whereas for pcbnew I was unable to come up with a
solution.

> I'm assuming the printing is a v6 goal.

Broken legacy canvas in pcbnew means layout printing is also broken. A
simple workaround is to remove printing completely and request users to
use PDF plotting.

Cheers,
Orson

> On 7/16/2018 11:15 AM, Maciej Sumiński wrote:
>> Tom has already prepared a proof-of-concept eeschema with GAL rendering,
>> which still uses the legacy tools. I have some promising results
>> switching the printing system to Cairo GAL. Obviously we will face some
>> unexpected obstacles, but I have high hopes.
>>
>> Cheers,
>> Orson
>>
>> On 07/16/2018 03:40 PM, Wayne Stambaugh wrote:
>>> Yes, assuming we can get that to work without dragging in Phoenix.
>>>
>>> On 7/16/2018 9:27 AM, Jeff Young wrote:
>>>> 5.1 is also for the GTK3 fixes, right?
>>>>
>>>>> On 16 Jul 2018, at 14:23, Wayne Stambaugh  wrote:
>>>>>
>>>>> On 7/16/2018 9:19 AM, Simon Richter wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 15.07.2018 13:39, Jeff Young wrote:
>>>>>>
>>>>>>> I renamed my 6.0 branch to 5.1, since most of what it contains goes 
>>>>>>> there.
>>>>>>
>>>>>> What is the difference between 5.1 and 6.0? What goes into which branch?
>>>>>>
>>>>>>   Simon
>>>>>>
>>>>>
>>>>> 5.1 is only for the UI refactoring Jeff is working on along with any bug
>>>>> fixes that get merged into the 5.0 branch.  Any new features such as the
>>>>> new schematic file formats or GALification of eeschema are v6 only.
>>>>>
>>>>> ___
>>>>> Mailing list: https://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
> 




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

[Kicad-developers] How sophisticated is the bug closure script?

[Maciej Sumiński]

On 07/15/2018 11:20 PM, Jeff Young wrote:
> Hi Orson,
> 
> I was asking about the Fix Committed -> Fix Released script (assuming it is a 
> script), rather than the *** -> Fix Committed script.

Frankly, I could not recall how we have updated the bug statuses after
the previous release. This time we used a script, and it should not be
very hard to modify it to filter bugs targeted at a particular release.
It will require some discipline in setting appropriate targets in bug
reports though.

> Although your answer does bring up the question, do we want to setup the 
> Janitor script to handle the 5.1 branch as well, or just do them by hand?

I guess 5.1 will become the master branch soon, so KiCad Janitor will
cope with updating bug statuses when it happens. As far as I understand
we will only have 5.0 and master (aka 5.1) branches in the near future.

Cheers,
Orson

> Cheers,
> Jeff.
> 
>> On 15 Jul 2018, at 22:11, Maciej Suminski  wrote:
>>
>> Hi Jeff,
>>
>> KiCad Janitor follows only the master branch and does not take tags or
>> target milestones into account. The rules are very simple: whenever
>> there is a "fixes" line, change the correlated bug status to "Fixed".
>> Have a look at the script [1], I will be happy to improve it.
>>
>> Cheers,
>> Orson
>>
>> 1. https://git.launchpad.net/kicad-git-hook/tree/hook.py
>>
>> On 07/15/2018 05:43 PM, Jeff Young wrote:
>>> In particular, can I go ahead and make commits that have “fixes” lines (as 
>>> long as the bugs are tagged 5.1), or do I need to wait till be auto-close 
>>> the 5.0 bugs?
>>> ___
>>> Mailing list: https://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] 5.1 branch

[Maciej Sumiński]

I have the script ready to run. It will just change all KiCad bug
statuses from 'Fix Committed' to 'Fix Release'. I assume there are no
bugs that are marked as 'Fix Committed', but not actually in the master
branch, right? Are you ready for an infinite stream of bug tracker
notifications? :>

Cheers,
Orson

On 07/16/2018 05:13 PM, Wayne Stambaugh wrote:
> That would probably be the easiest solution with the least amount of
> risk.  Although you could not run it for point releases because bugs
> that are only valid for the development branch would get set to fix
> released which would not be correct.
> 
> On 7/16/2018 11:08 AM, Maciej Sumiński wrote:
>> It is terribly tedious to go through the bug list and change statuses
>> one by one, so I offer to help with the bug report status fiddling. We
>> may employ Janitor, but I guess it would be better to execute a simple
>> script to change Fix Committed->Fix Released whenever we release a new
>> version.
>>
>> Cheers,
>> Orson
>>
>> On 07/16/2018 03:30 PM, Wayne Stambaugh wrote:
>>> Hey Jeff,
>>>
>>> We have been manually changing the bug status from fix committed to fix
>>> released after a new stable release.  AFAIK, the janitor does not handle
>>> this.  I suppose the janitor could be modified to test for a new release
>>> and change the tag for all bugs associated with that release.  That
>>> would not be 100% accurate because there are bugs that have not been
>>> associated with a branch but that would probably be easier than changing
>>> them all manually.  I don't have a strong preference one way or the other.
>>>
>>> Wayne
>>>
>>> On 7/16/2018 9:20 AM, Jeff Young wrote:
>>>> Hi Wayne,
>>>>
>>>> The other issue is that the Janitor is going to mark my fixes as Fix 
>>>> Committed, and I don’t know if the auto-bug-release facility is smart 
>>>> enough to check the milestone before converting Fix Committed to Fix 
>>>> Released.  So we may need to do that first too.
>>>>
>>>> Cheers,
>>>> Jeff.
>>>>
>>>>> On 16 Jul 2018, at 14:15, Wayne Stambaugh  wrote:
>>>>>
>>>>> Jeff,
>>>>>
>>>>> As a general rule, we merge changes into the development branch and then
>>>>> merge them into the stable release branch after they have been tested.
>>>>> In the past this has only been bug fixes so your case is slightly
>>>>> different.  The problem I see with merging your changes into the 5.1
>>>>> branch first is that they will not get as much testing as they would if
>>>>> you merged your changes into the development branch.  I would prefer
>>>>> that we merge changes into the development branch so that nightly builds
>>>>> can be used to get some good testing.  Any bug fixes to your changes can
>>>>> then be merged into the 5.1 branch.  Does anyone see any reason not to
>>>>> do it this way?
>>>>>
>>>>> Please do not merge your changes into the development branch just yet.
>>>>> Orson just fixed a bug and I'm considering retagging v5 to include this 
>>>>> fix.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Wayne
>>>>>
>>>>> On 7/16/2018 5:05 AM, Jeff Young wrote:
>>>>>> Thanks, JP!  I’ll make the fix.
>>>>>>
>>>>>>> On 16 Jul 2018, at 09:24, jp charras  wrote:
>>>>>>>
>>>>>>> Le 16/07/2018 à 10:10, Jeff Young a écrit :
>>>>>>>> Well, rats.  I couldn’t figure out why "git rebase —interactive" 
>>>>>>>> wasn’t showing me any of my
>>>>>>>> commits, and it turns out that I somehow accidentally merged them all 
>>>>>>>> to origin/5.1 sometime last
>>>>>>>> night.  Anyway, you don’t have to fetch my private branch to test it 
>>>>>>>> anymore; the kicad 5.1 branch
>>>>>>>> will do nicely.
>>>>>>>>
>>>>>>>> Let me know if the paged dialog issues are keeping anyone from getting 
>>>>>>>> work done and I’ll try to
>>>>>>>> figure out how to revert those commits.
>>>>>>>
>>>>>>> Hi, Jeff
>>>>>>> The paged dialog issue is due to the fact the panels (pages) have an 
>>>>

Re: [Kicad-developers] 5.1 branch

[Maciej Sumiński]

Tom has already prepared a proof-of-concept eeschema with GAL rendering,
which still uses the legacy tools. I have some promising results
switching the printing system to Cairo GAL. Obviously we will face some
unexpected obstacles, but I have high hopes.

Cheers,
Orson

On 07/16/2018 03:40 PM, Wayne Stambaugh wrote:
> Yes, assuming we can get that to work without dragging in Phoenix.
> 
> On 7/16/2018 9:27 AM, Jeff Young wrote:
>> 5.1 is also for the GTK3 fixes, right?
>>
>>> On 16 Jul 2018, at 14:23, Wayne Stambaugh  wrote:
>>>
>>> On 7/16/2018 9:19 AM, Simon Richter wrote:
 Hi,

 On 15.07.2018 13:39, Jeff Young wrote:

> I renamed my 6.0 branch to 5.1, since most of what it contains goes there.

 What is the difference between 5.1 and 6.0? What goes into which branch?

   Simon

>>>
>>> 5.1 is only for the UI refactoring Jeff is working on along with any bug
>>> fixes that get merged into the 5.0 branch.  Any new features such as the
>>> new schematic file formats or GALification of eeschema are v6 only.
>>>
>>> ___
>>> Mailing list: https://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] 5.1 branch

[Maciej Sumiński]

It is terribly tedious to go through the bug list and change statuses
one by one, so I offer to help with the bug report status fiddling. We
may employ Janitor, but I guess it would be better to execute a simple
script to change Fix Committed->Fix Released whenever we release a new
version.

Cheers,
Orson

On 07/16/2018 03:30 PM, Wayne Stambaugh wrote:
> Hey Jeff,
> 
> We have been manually changing the bug status from fix committed to fix
> released after a new stable release.  AFAIK, the janitor does not handle
> this.  I suppose the janitor could be modified to test for a new release
> and change the tag for all bugs associated with that release.  That
> would not be 100% accurate because there are bugs that have not been
> associated with a branch but that would probably be easier than changing
> them all manually.  I don't have a strong preference one way or the other.
> 
> Wayne
> 
> On 7/16/2018 9:20 AM, Jeff Young wrote:
>> Hi Wayne,
>>
>> The other issue is that the Janitor is going to mark my fixes as Fix 
>> Committed, and I don’t know if the auto-bug-release facility is smart enough 
>> to check the milestone before converting Fix Committed to Fix Released.  So 
>> we may need to do that first too.
>>
>> Cheers,
>> Jeff.
>>
>>> On 16 Jul 2018, at 14:15, Wayne Stambaugh  wrote:
>>>
>>> Jeff,
>>>
>>> As a general rule, we merge changes into the development branch and then
>>> merge them into the stable release branch after they have been tested.
>>> In the past this has only been bug fixes so your case is slightly
>>> different.  The problem I see with merging your changes into the 5.1
>>> branch first is that they will not get as much testing as they would if
>>> you merged your changes into the development branch.  I would prefer
>>> that we merge changes into the development branch so that nightly builds
>>> can be used to get some good testing.  Any bug fixes to your changes can
>>> then be merged into the 5.1 branch.  Does anyone see any reason not to
>>> do it this way?
>>>
>>> Please do not merge your changes into the development branch just yet.
>>> Orson just fixed a bug and I'm considering retagging v5 to include this fix.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 7/16/2018 5:05 AM, Jeff Young wrote:
 Thanks, JP!  I’ll make the fix.

> On 16 Jul 2018, at 09:24, jp charras  wrote:
>
> Le 16/07/2018 à 10:10, Jeff Young a écrit :
>> Well, rats.  I couldn’t figure out why "git rebase —interactive" wasn’t 
>> showing me any of my
>> commits, and it turns out that I somehow accidentally merged them all to 
>> origin/5.1 sometime last
>> night.  Anyway, you don’t have to fetch my private branch to test it 
>> anymore; the kicad 5.1 branch
>> will do nicely.
>>
>> Let me know if the paged dialog issues are keeping anyone from getting 
>> work done and I’ll try to
>> figure out how to revert those commits.
>
> Hi, Jeff
> The paged dialog issue is due to the fact the panels (pages) have an 
> incorrect parent.
> Currently, these panels have the dialog itself as parent.
> They should have m_treebook (the wxTreeBook similar to a wxNotebook) as 
> parent.
>
> (This change fixes the issue on W7)
>
>>
>> Cheers,
>> Jeff.
>
> -- 
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


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

>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> ___
> Mailing list: https://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] New Kicad Features

[Maciej Sumiński]

Hi Tom,

You can see our plan in the v6 roadmap [1], but the only related topic
is the board stack up editor, which appears to be a prerequisite for the
mentioned features. Obviously, it does not mean we are limited by the
roadmap, but we need additional contributors for that to happen.

We are glad to see new developers joining the project, so do not
hesitate to ask questions. It might be also a wise idea to consult
proposed changes to see if there is no clash with the on-going work or
discover better ideas.

Regards,
Orson

1. http://docs.kicad-pcb.org/doxygen/v6_road_map.html

On 07/15/2018 02:40 PM, Tom Kulaga wrote:
> Hi All,
> 
> I wanted to find out if any of the following features are in the Kicad
> pipeline
> 
> -Multi Board projects  with consolidated BOM and panelisation features
> -Also having multi board assemblies for system visualisation
> -Multiple stacks-up per board for rigid flex work
> 
> I'd be happy to contribute with some guidance.
> 
> 
> 
> ___
> Mailing list: https://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] Build failed in Jenkins: kicad-qa #4256

[Maciej Sumiński]

For the record: the issue has been already fixed by Jean-Pierre and was
not really related to the documentation fixes. Thank you!

Cheers,
Orson

On 06/12/2018 04:28 PM, Miguel Angel Ajo wrote:
> See 
> 
> Changes:
> 
> [Wayne Stambaugh] Minor Python scripting documentation fixes.
> 
> --
> Started by an SCM change
> Building remotely on debian8 (clang gcc linux) in workspace 
> 
>  > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url 
> https://github.com/KiCad/kicad-source-mirror.git # timeout=10
> Fetching upstream changes from 
> https://github.com/KiCad/kicad-source-mirror.git
>  > git --version # timeout=10
>  > git fetch --tags --progress 
> https://github.com/KiCad/kicad-source-mirror.git 
> +refs/heads/*:refs/remotes/origin/*
>  > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
>  > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
> Checking out Revision ade3c2b12921a01360c75ad7e5a77371ae6d4f0e 
> (refs/remotes/origin/master)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f ade3c2b12921a01360c75ad7e5a77371ae6d4f0e
> Commit message: "Minor Python scripting documentation fixes."
>  > git rev-list --no-walk 660aed71b4e21c7e3052c665accf1d36ad612a13 # 
> timeout=10
> [kicad-qa] $ /bin/sh -xe /tmp/jenkins1165005224288930315.sh
> + cmake --version
> cmake version 3.0.2
> 
> CMake suite maintained and supported by Kitware (kitware.com/cmake).
> + gcc --version
> gcc (Debian 4.9.2-10+deb8u1) 4.9.2
> Copyright (C) 2014 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> + git --version
> git version 2.1.4
> + OPTS= -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
> -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON 
> -DKICAD_SCRIPTING_WXPYTHON=ON
> + [ -d passed-qa ]
> + [ -d build ]
> + cd build
> + /usr/bin/cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
> -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON 
> -DKICAD_SCRIPTING_WXPYTHON=ON
> -- Kicad install dir: 
> -- Check for installed GLEW -- found
> -- Boost version: 1.55.0
> -- Check for installed Python Interpreter -- found
> -- Python module install path: lib/python2.7/dist-packages
> -- wxPython version 3.0 found.
> -- S3DSG version: 2.0.0
> -- Boost version: 1.55.0
> -- Found the following Boost libraries:
> --   unit_test_framework
> -- Boost version: 1.55.0
> -- Found the following Boost libraries:
> --   unit_test_framework
> -- Boost version: 1.55.0
> -- Found the following Boost libraries:
> --   unit_test_framework
> -- Configuring done
> -- Generating done
> -- Build files have been written to: 
> 
> + echo CMAKE exit code is 0
> CMAKE exit code is 0
> + rm -f pcbnew/pcbnewPYTHON_wrap.cxx
> + env
> + grep -q ^MAKEJOBS=
> + echo The MAKEJOBS variable is empty
> The MAKEJOBS variable is empty
> + JOBS=4
> + make -j4 pcbnew_python_module
> [  1%] Built target pcb_plot_lexer_source_files
> [  1%] [  1%] Built target lib_table_lexer_source_files
> Built target pcb_lexer_source_files
> [  1%] Built target netlist_lexer_source_files
> [  1%] Built target idf3
> [  1%] [  1%] Built target page_layout_lexer_source_files
> Generating version string header
> -- Using Git to determine build version string.
> -- Found Git: /usr/bin/git (found version "2.1.4") 
> [  4%] Built target gal
> [  7%] Built target kicad_3dsg
> -- Writing 
>  file 
> with version: (5.0.0-rc2-127-gade3c2b)
> [  7%] [  7%] Built target lib_dxf
> Built target version_header
> [  7%] Built target polygon
> [ 49%] Built target bitmaps
> [ 49%] Built target specctra_lexer_source_files
> [ 53%] Built target pcbcommon
> [ 54%] Built target pcad2kicadpcb
> [ 60%] Built target 3d-viewer
> Scanning dependencies of target common
> [ 61%] Building CXX object common/CMakeFiles/common.dir/build_version.cpp.o
> [ 83%] Built target pcbnew_kiface_objects
> Linking CXX static library libcommon.a
> [ 97%] Built target common
> [ 97%] Built target github_plugin
> [100%] Built target pnsrouter
> Linking CXX shared module _pcbnew.kiface
> [100%] Built target pcbnew_kiface
> [100%] Creating python's pcbnew native module _pcbnew.so for command line use.
> [100%] Built target pcbnew_python_module
> + pwd
> + export PYTHONPATH=
> + cd ../qa
> + /usr/bin/python2 test.py
> test_pcb_bounding_box (test_002_board_class.TestBoardClass) ... FAIL
> test_pcb_find_module (test_002_board_class.TestBoardClass) ... ok
> test_pcb_get_pad (test_002_board_class.TestBoardClass) ... ok
> test_pcb_get_track_count 

Re: [Kicad-developers] Janitor needs a kick

[Maciej Sumiński]

Whoops! Apparently trying to change status of a non-existent bug report
drove him insane. He has already taken his pills, everything should be
back to normal soon. Sorry for the mess.

Cheers,
Orson

On 06/13/2018 02:48 AM, Seth Hillbrand wrote:
> I don't think it was my formatting but the last two patches to master seem
> to have stuck the Janitor in a loop.
> 
> Anyone have time to reset it?
> 
> 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
> 




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] Fix -Wparentheses warning in track_cleaner.cpp

[Maciej Sumiński]

Hi John,

Thank you for the patch, I have just pushed it to the master branch.

Cheers,
Orson

On 06/12/2018 12:16 PM, John Beard wrote:
> Hi,
> 
> This is a very simple patch to address a -Wparentheses warning in
> pcbnew/track_cleaner.cpp.
> 
> It was "wxBusyCursor( dummy );", it is now "wxBusyCursor dummy;"
> 
> Cheers,
> 
> John
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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] Help finding routing option

[Maciej Sumiński]

Hi Seth,

Your head is fine, do not worry. You will find the option in the PnS
right click context menu: Select Track/Via Width->Use Netclass Value (I
have just realized that the former should be called "Select Track/Via
Size). Grepping for ID_POPUP_PCB_SELECT_USE_NETCLASS_VALUES will get you
the interesting bits.

Cheers,
Orson

On 06/07/2018 05:19 AM, Seth Hillbrand wrote:
> ​Hi All-
> 
> Could someone let me know if I'm mistaken here?  Some years ago, I recall
> being able to set an option while routing that allowed new tracks to pick
> up their netclass values rather than the ​global track width setting.  I've
> searched (I think) the options as well as had a look through the code and I
> can't find this option anywhere.
> 
> It is certainly possible that I'm just loosing that last marble and
> remembering an option from zuken.  But I could have sworn it was somewhere
> in our code.
> 
> Thanks for any pointers!
> -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
> 




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] Fix 'catching polymorphic type by value' warnings

[Maciej Sumiński]

Thank you John, I have just pushed your patch.

Cheers,
Orson

On 06/05/2018 10:02 AM, John Beard wrote:
> Hi,
> 
> Sorry, I missed one out in kicad/import_project.cpp
> 
> Cheers,
> 
> John
> 
> On Tue, Jun 5, 2018 at 8:43 AM, John Beard  wrote:
> 
>> Hi,
>>
>> Small patch to fix some warnings (GCC 8.1.0) like this:
>>
>> warning: catching polymorphic type ‘class std::out_of_range’ by value
>> [-Wcatch-value=]
>>  catch( std::out_of_range )
>>  ^~~~
>>
>> Fixed by changing to catch-by-reference: "catch( const std:::out_of_range&
>> )"
>>
>> C.f. recent commit ff1802d7a "Fix Coverity "Big parameter passed by value"
>> warnings".
>>
>> As one of these fixes is in view.h, the warning came up a fair bit.
>>
>> Cheers,
>>
>> John
>>
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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] Proposal to remove Default Pad Properties in 6.0

[Maciej Sumiński]

Hi Jeff,

I think this is yet another problem where Object Inspector comes to
rescue. There are more dialogs to execute massive object modification
that could be easily handled with OI, so hopefully we can get rid of
them in the future.

Cheers,
Orson

On 05/31/2018 02:35 PM, Jeff Young wrote:
> We currently expose this in both Kicad and Modedit, but it’s not really what 
> it says it is as newly created pads use the last set properties, not the 
> default properties.
> 
> It is used by Copy / Apply Pad Settings, but that’s a bit odd too as one 
> would expect those to go through the clipboard.
> 
> When editing boards I’ve used Push Pad Settings a lot, and Copy / Apply Pad 
> Settings some.  But I’ve never done a Copy, then edited the copy through the 
> Default Pad Properties dialog, and then done an Apply.  And I don’t think 
> anyone else would ever think to do that either.
> 
> So I don’t think it actually serves a purpose.
> 
> Background:
> I’m looking at implementing a tree-controlled Board Setup (similar to the new 
> preferences) which would replace Layers Setup, Design Rules, Text and 
> Drawings, and if required, Default Pad Properties.
> 
> This change would also likely include moving Text and Drawings from a 
> type-specific model (footprint item vs PCB item) to a layer-specific model 
> (silk vs fab vs copper vs other).
> 
> Comments welcome on that too….
> 
> 
> 
> ___
> Mailing list: https://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] Symbol Library Editor: syncing state of search tree tool button with search tree panel

[Maciej Sumiński]

Well spotted! Thank you for the patch, I have just pushed it to the
master branch.

Regards,
Orson

On 05/30/2018 04:04 PM, Константин Барановский wrote:
> Button "Toggle the search tree" from left toolbar of Symbol Library
> Editor does not show actual state of visibility of the search tree
> panel. State of this button (checked or unchecked) changes on clicking
> only. Toggling panel visibility from menu does not make effect on tool
> state.
> 
> Attached patch makes tool state (checkd/unchecked) synced with panel
> state (shown/hidden).
> 
> 
> 
> ___
> Mailing list: https://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] partially untranslated strings in simulation dialog

[Maciej Sumiński]

Thank you Marco, I have just pushed your patch.

Regards,
Orson

On 05/28/2018 11:37 AM, Marco Ciampa wrote:
> On Mon, May 28, 2018 at 07:55:16AM +0200, Carsten Schoenert wrote:
>> Hello Marco,
>>
>> Am 27.05.2018 um 12:10 schrieb Marco Ciampa:
 No apologies needed at all, Maciej!
 But I am sorry to say that it will not suffice, there are also some error
 message strings left out untranslated...
>> ...
 eeschema/dialogs/dialog_sim_settings.cpp
 109:DisplayError( this, wxT( "You need to select DC source 
 (sweep 1)" ) );
 139:DisplayError( this, wxT( "You need to select DC source 
 (sweep 2)" ) );

 ^
 Not translated
>>
>> this is for sure just a oversight by the developers and not a intended
>> behavior. 
> 
> Of course I know it. That was my point in saying that there is no need to
> apoligise!
> 
>> I'd hereby suggesting you prepare a patch about such strings.
>> I've seen this also from time to time but didn't get backed out a patch
>> yet due time limitations.
> 
> Here we go: see attach. I do not know if it is complete though, you know,
> I am a mere translator, not a programmer!
> 
> TIA
> 
> Best regards,
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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] partially untranslated strings in simulation dialog

[Maciej Sumiński]

Hi Marco,

It should be fixed now, apologies for missing these strings until now.

Cheers,
Orson

On 05/25/2018 11:15 AM, Marco Ciampa wrote:
> Hi dev,
> I am sorry for boring you all (as usual) with trivial (i18n) things.
> Launching the Spice Simulator dialog I just noted a few untranslated
> strings, see attached screenshot...
> 
> Some of these may be left untranslated, especially if they are produced
> by ngspice, so hardly translatable but, some of these seem to be just
> omissions like the ones on the right of the screenshot.
> 
> What do you think about it?
> 
> 
> 
> ___
> Mailing list: https://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] Footprint Library Wizard removal

[Maciej Sumiński]

Thank you for the feedback. I have fixed the reported issues (disabled
"Show Hidden", made the dialog resizable and ${KIRPRJMOD} substitution)
and pushed the changes.

Cheers,
Orson

On 05/25/2018 09:20 AM, jp charras wrote:
> Le 24/05/2018 à 19:49, jp charras a écrit :
>> Le 24/05/2018 à 10:19, Maciej Sumiński a écrit :
>>> Attached a revised patch set, as the previous one looked ugly on Windows
>>> (and fine on Linux).
>>
>> Thanks Orson.
>>
>> The look of this dialog is much better now.
>>
>> Just two remarks about the dialog itself: the dialog is not re-sizable, and 
>> should be derived from
>> our DIALOG_SHIM base class.
>>
> 
> Hi Orson,
> 
> I noticed an other issue (a regression):
> 
> When a library is added, if it is in the project folder, its path is stored 
> as an absolute path, and
> the ${KIPRJMOD} env var is not used to build the path.
> 
>>
>>>
>>> Cheers,
>>> Orson
>>>
>>> On 05/23/2018 12:17 PM, Maciej Sumiński wrote:
>>>> As it has been reported [1], the Footprint Library Wizard is restricted
>>>> to the old Github repositories (one repo per library vs current single
>>>> repo for all libraries). I propose to replace it with a common file
>>>> browser, similar to the one in the Symbol Library Table dialog. In the
>>>> future we may develop a separate dialog to update the local libraries,
>>>> using a genuine git client letting us any repository (not only Github),
>>>> perhaps traverse through commits and display logs.
>>>>
>>>> I could not use the standard file dialog, as wxWidgets does not provide
>>>> one to select both files *and* directories, but it is necessary to
>>>> handle both .pretty libraries (directories) and foreign formats (e.g.
>>>> Eagle .lbr files) with a single dialog.
>>>>
>>>> Github plugin is still available, but has to be selected manually in the
>>>> Footprint Library Table dialog. I think it is reasonable not to expose
>>>> it, as it brings troubles to inexperienced users.
>>>>
>>>> AFAICT, the attached patch introduces one new string ("Show Hidden" in
>>>> the selector dialog), breaking the string freeze rule. The string is not
>>>> crucial, so it might be removed for the time being.
>>>>
>>>> Cheers,
>>>> Orson
>>
>>
> 
> 




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

Re: [Kicad-developers] More default fields in schematic

[Maciej Sumiński]

One more field that could become predefined and receive a special
meaning is 'Mounted' or similar. This will come handy when we decide to
support assembly variants and will let us add a visual distinction
between mounted and not mounted components if we want it.

The remaining fields is a matter of configuration, particularly that
there is a way to specify the default fields in eeschema. I am quite
sure that there are existing libraries using other field names than the
ones we would hard-code, so such change would make users upset. I do not
see there is a reason to enforce field naming for everyone, unless the
field needs to be treated in a special way:

- "Reference" as the unique component identifier and a link between
schematics and board
- "Footprint" to pick the physical representation with the footprint browser
- "Datasheet" lets open corresponding documentation for a component
- "Value" is the only field that serves the description purpose only,
but it seems a sensible exception to the rule

Cheers,
Orson

On 05/20/2018 10:00 PM, kristoffer Ödmark wrote:
> Hello!
> 
> I will open this can of worms again, I feel that I have to. So from what
> I gather we have proffessionals as the main aim in Kicad.
> The reason I will open this issue again is that I feel we have a
> collaboration issue, maybe not a mayor one. But one nonetheless.
> 
> We really need more default fields for our schematic symbols. Im not
> proposing required fields, I am *ONLY* proposing that
> there should be default fields added into the default fields settings
> tab. I am not proposing they need to be filled in the
> libraries, nor that people need to use them. only that they need to
> exist with a fresh install of kicad so that easy problems
> such as theese do not happen:
> 
>     - Collaborators working on the same project will not create
> duplicate fields in libs/projects describing the same thing by mistake
>     - Projects that aim to interact or add to Kicad can assume that the
> Fields will exist, and will know what name/tag to look for
>   (bom exporters, price checkers, MacroFab, etc)
>     - Open source projects will be easier to collaborate, read and order
> 
> The reason I think it is better to have the fields by default than the
> current solution to add them is that the majority will use
> what exists, and tools can support it from the very beginning, people
> with inhouse tools seems to dislike this, since they map their
> parts with an inhouse number - and then handle the information about the
> part there. From what I gather, this is not the majority, and
> these persons still modify the default fields settings.
> 
> I spent maybe 30-40 mins checking the "made with kicad" projects, I
> found that the most common addition to libs and schematics are:
>     - Manufacturers part number, these were named widely different in
> projects, (BOM, MP, MPN, #mfg, or different syntaxes in the Value field )
>         I even saw a mix of these in the same project once, along with
> some people having the vendor id only.
>     - Manufacturer ( found some different languages though )
> 
> more uncommon things was, Tolerance( 10%, 20pps), Ratings ( 1/4W, 85C,
> 16V ), Vendor information and different Descriptions. They were named
> and abbreviated
> very differently accross projects.
> 
> What I would like to see is these additional fields by default, but
> hidden from the schematic unless changed by user.
>     Tolerance ( used for setting tolerances of resistors, capacitors,
> oscillators, etc )
>     MaxRating ( field were one can specify max Voltage, Ampere,
> Frequency, or whatever the component needs )
>     Manufacturer ( For inhouse numbers, they could either just remove
> it, or use the company/group name )
>     MPN ( Maybe PartNumber could be used here, and people who use
> inhouse numbers use it aswell, I dont really care what its called, as
> long as its called something )
>     Vendor
>     Notes
> 
> I would be all up for extra additions/removals, but I would prefer if
> the naming is not discussed, but rather just decided/agreed upon by
> someone in the lead team.
> The very least I think should be added in case the previous is to much are:
>     Tolerance
>     Manufacturer
>     MPN
> 
> I attach a patch for the minimal set, tested on linux by removing the
> .config/kicad/eeschema file.
> 
> - Kristoffer
> 
> 
> ps
> Some github files i reviewed, not all:
> https://github.com/AnaviTechnology/anavi-gardening/blob/master/MCP3002-I_SN.lib
> 
> https://github.com/jonpe960/blixten/blob/master/Blixten%20LED%20Device/Blixten.sch
> 
> https://github.com/paltatech/half-bridge/blob/master/pcb%20design/IGBT_board-cache.lib
> 
> https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_smd.lib
> https://github.com/jim17/memtype/blob/master/schematic_pcb/electronic_design_kicad/electronic_design_kicad.sch
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 

Re: [Kicad-developers] Indeterministic netlist export for multiunit components

[Maciej Sumiński]

How about my patch? I do not dare to go for the ultimate solution right
now, but is it acceptable as a stop gap measure for v5?

Cheers,
Orson

On 05/18/2018 03:28 PM, Wayne Stambaugh wrote:
> The suggestions made are all good and valid but I think to some extent
> there will always be some ambiguity.  Users being users will make
> mistakes filling in field data which will cause issues when annotating
> and generating the netlist.  In complex designs with lots of multiple
> units symbols it's not always possible to know which units should be
> grouped together by reference.  More often that not, this cannot be
> known until board layout time.  This is something that I am all to
> familiar with because I do lots of designs with several dual and quad
> op-amps.  I don't think we will ever be able to completely do this
> without some ambiguity until some type of human brain interface is
> created to allow us to know what the user wants versus what the user
> specified.
> 
> That being said, I suggest we define the behavior we want before we
> start coding so there is no ambiguity it what we hope to accomplish.  A
> simple bulleted list would be fine.  Once we define the desired
> behavior, we should get some user input so that we don't create
> something that doesn't work well for users.
> 
> Cheers,
> 
> Wayne
> 
> On 05/18/2018 08:44 AM, Jeff Young wrote:
>> Hi Orson,
>>
>> The problem should become less prevalent over time: for 6.0 I plan on fixing 
>> the multi-sheet undo issues so that we can update all units in unison.  (Of 
>> course that still fails if you edit before annotating as we then don’t know 
>> which units go with which.)
>>
>> But I agree that anytime we have a non-matching field across units it looks 
>> like a bug to the user.  Your proposal is certainly an improvement in that 
>> regard.
>>
>> I think the one thing that would be left would be to flag unit field 
>> mismatches when annotating (or perhaps even try and group units by matching 
>> their fields).  But that carries enough risk to relegate it to 6.0 along 
>> with the undo stuff.
>>
>> Cheers,
>> Jeff.
>>
>>
>>> On 18 May 2018, at 12:16, Sergey A. Borshch <sb...@users.sourceforge.net> 
>>> wrote:
>>>
>>> On 18.05.2018 11:14, Maciej Sumiński wrote:
>>>> Hi,
>>>> Recently I have found out that the netlist exporter uses an algorithm
>>>> that for multiunit components uses non empty field values from the last
>>>> processed unit [1]. The problem is that the processing order depends on
>>>> the order of the units in the item list, so completely random.
>>> I want to remind that there is another bug in netlist generator related to 
>>> units processing order: https://bugs.launchpad.net/bugs/1704083
>>>
>>>> Instead, I propose we try to get all field values from the first
>>>> available unit (e.g. unit A), and resort to other units only if there
>>>> are any fields left empty.
>>>>
>>>> To give an example of what can go wrong with such approach: recently I
>>>> generated BOM and assembly documentation, where unit A had 'Mounted'
>>>> field set to 'No'. I was surprised to find out that in the generated
>>>> output it has been marked as mounted, as the unit B had 'Yes' set for
>>>> the field. I would qualify it as a bug, but I seek your input before I
>>>> proceed with pushing my changes. See my proposal in the attached patch.
>>> I think there no need in Artificial Intelligence while generating netlist 
>>> from incorrect schematics, but all fields in component units must be 
>>> consistent instead. I mean that changing in schematics editor any field in 
>>> one unit must also change same field in other units with same RefDes. 
>>> Automatic annotation must take into account all fields values and assign 
>>> different RefDes to units which differs with fields values.
>>> One more proposal - manual RefDes change shoud not be allowed with 
>>> appropriate warning if unit(s) with new RefDes already exist in schematics 
>>> and belongs to another component type or has different fields value(s). It 
>>> would be best helpful if warning message will show that units belongs to 
>>> different component types or which field value differs if component type is 
>>> the same.
>>>
>>>
>>> -- 
>>> Regards,
>>>  Sergey A. Borshchmailto: sb...@sourceforge.net
>>>SB ELDI ltd. Riga, Latvia
>>>
>>>
>>> __

Re: [Kicad-developers] 5.0 RC2 / release status

[Maciej Sumiński]

Hi Jon,

Welcome back! There was one very serious issue [1] blocking RC2, but
fortunately it was fixed yesterday. Looking at the to-do list for v5
[2], there are three minor issues and two more serious bugs that may
need some extra data from the reporters. It would be great to have the
former two bugs closed for the final release, but I suppose we are ok
for RC2. At least it would get us some extra testing eyes.

Regards,
Orson

1. https://bugs.launchpad.net/kicad/+bug/1767826
2. https://launchpad.net/kicad/+milestone/5.0.0-rc2

On 05/18/2018 04:29 PM, Jon Evans wrote:
> Hi all,
> 
> I've been mostly away from KiCad recently due to other things going on in
> life, but I have been trying to follow the mailing list at least.  Seems
> like progress towards a RC2 release may have stalled, but it's not clear
> why.  Meanwhile lots of small changes continue to go in to master (I don't
> think that's necessarily a bad thing but I wonder whether or not we know
> what the critical path is to RC2)
> 
> Where do we stand / if someone like me has a few hours somewhere to push on
> something, what is the most valuable area to look at?
> 
> -Jon
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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

[Kicad-developers] Indeterministic netlist export for multiunit components

[Maciej Sumiński]

Hi,

Recently I have found out that the netlist exporter uses an algorithm
that for multiunit components uses non empty field values from the last
processed unit [1]. The problem is that the processing order depends on
the order of the units in the item list, so completely random.

Instead, I propose we try to get all field values from the first
available unit (e.g. unit A), and resort to other units only if there
are any fields left empty.

To give an example of what can go wrong with such approach: recently I
generated BOM and assembly documentation, where unit A had 'Mounted'
field set to 'No'. I was surprised to find out that in the generated
output it has been marked as mounted, as the unit B had 'Yes' set for
the field. I would qualify it as a bug, but I seek your input before I
proceed with pushing my changes. See my proposal in the attached patch.

There is a discussion regarding sharing the field values among all units
[2], but I see there is a technical problem preventing such solution
right now.

Cheers,
Orson

1.
https://github.com/KiCad/kicad-source-mirror/blob/master/eeschema/netlist_exporters/netlist_exporter_generic.cpp#L94
2. https://bugs.launchpad.net/bugs/1765771
From 6ee2a072853de33ab72e5874998bb2b49f22c981 Mon Sep 17 00:00:00 2001
From: Maciej Suminski 
Date: Thu, 17 May 2018 17:10:26 +0200
Subject: [PATCH] Deterministic algorithm for picking field values in multiunit
 components

The original algorithm picked the value from the last component having
non empty value for a given field, but the processing order was
dependent on the layout of the components in the memory. It means that
for each component, the field values could have been taken from any
unit, randomly.

The patch improves the algorithm, trying to get all values from the unit
with the lowest number and resorts to other units only when there are
field values left empty.
---
 .../netlist_exporters/netlist_exporter_generic.cpp | 31 ++
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/eeschema/netlist_exporters/netlist_exporter_generic.cpp b/eeschema/netlist_exporters/netlist_exporter_generic.cpp
index 9556b2a22..2cf4cbc06 100644
--- a/eeschema/netlist_exporters/netlist_exporter_generic.cpp
+++ b/eeschema/netlist_exporters/netlist_exporter_generic.cpp
@@ -91,17 +91,18 @@ void NETLIST_EXPORTER_GENERIC::addComponentFields( XNODE* xcomp, SCH_COMPONENT*
 {
 if( comp->GetUnitCount() > 1 )
 {
-// Sadly, each unit of a component can have its own unique fields.  This block
-// finds the last non blank field and records it.  Last guy wins and the order
-// of units occuring in a schematic hierarchy is variable.  Therefore user
-// is best off setting fields into only one unit.  But this scavenger algorithm
-// will find any non blank fields in all units and use the last non-blank field
+// Sadly, each unit of a component can have its own unique fields. This
+// block finds the unit with the lowest number having a non blank field
+// value and records it.  Therefore user is best off setting fields
+// into only the first unit.  But this scavenger algorithm will find
+// any non blank fields in all units and use the first non-blank field
 // for each unique field name.
 
 COMP_FIELDS fields;
 wxStringref = comp->GetRef( aSheet );
 
 SCH_SHEET_LIST sheetList( g_RootSheet );
+int minUnit = comp->GetUnit();
 
 for( unsigned i = 0;  i < sheetList.size();  i++ )
 {
@@ -117,26 +118,34 @@ void NETLIST_EXPORTER_GENERIC::addComponentFields( XNODE* xcomp, SCH_COMPONENT*
 if( ref2.CmpNoCase( ref ) != 0 )
 continue;
 
-// The last guy wins.  User should only set fields in any one unit.
+int unit = comp2->GetUnit();
+
+// The lowest unit number wins.  User should only set fields in any one unit.
 // remark: IsVoid() returns true for empty strings or the "~" string (empty field value)
-if( !comp2->GetField( VALUE )->IsVoid() )
+if( !comp2->GetField( VALUE )->IsVoid()
+&& ( unit < minUnit || fields.value.IsEmpty() ) )
 fields.value = comp2->GetField( VALUE )->GetText();
 
-if( !comp2->GetField( FOOTPRINT )->IsVoid() )
+if( !comp2->GetField( FOOTPRINT )->IsVoid()
+&& ( unit < minUnit || fields.footprint.IsEmpty() ) )
 fields.footprint = comp2->GetField( FOOTPRINT )->GetText();
 
-if( !comp2->GetField( DATASHEET )->IsVoid() )
+if( !comp2->GetField( DATASHEET )->IsVoid()
+&& ( unit < minUnit || fields.datasheet.IsEmpty() ) )
 fields.datasheet = comp2->GetField( DATASHEET )->GetText();
 
 for( int fldNdx = 

Re: [Kicad-developers] Another dialog preview

[Maciej Sumiński]

Nice, this is how a modern settings dialog should look like!

Cheers,
Orson

On 05/17/2018 04:41 PM, Jeff Young wrote:
> Just thought I’d share something from my 6.0 tree:
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> Mailing list: https://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] Track & via clearances only in Legacy...

[Maciej Sumiński]

You are right, apparently my morning coffee had not yet kicked in when I
was reading your message. Indeed, it does not work and deserves a bug
report.

Cheers,
Orson

On 04/25/2018 11:02 AM, Jeff Young wrote:
> @Orson & @Nick,
> 
> Do you see the clearances /while/ routing?  The “always” setting does work on 
> Mac, it’s just the 3 middle ones for “during routing” and “during routing and 
> editing” that don’t on a Mac GAL canvas.
> 
> 
>> On 25 Apr 2018, at 07:43, Nick Østergaard <oe.n...@gmail.com> wrote:
>>
>> Just a wild guess here; maybe it has something to do with a hidpi screen 
>> which I assume Jeff is using and the line thickness used for the drawing?
>>
>> 2018-04-25 8:32 GMT+02:00 Maciej Sumiński <maciej.sumin...@cern.ch 
>> <mailto:maciej.sumin...@cern.ch>>:
>> Hi Jeff,
>>
>> Are these options broken on macOS? I see clearance lines displayed for
>> all items (pads, tracks, vias) in GAL.
>>
>> example: https://imgur.com/a/LtFtWgR <https://imgur.com/a/LtFtWgR>
>>
>> Cheers,
>> Orson
>>
>> On 04/24/2018 08:50 PM, Jeff Young wrote:
>>> I just discovered that “Show track clearances” and “Show track clearances 
>>> with via area” settings only work in the Legacy router.  We have a Legacy 
>>> Router Options area in the general preferences dialog where the options 
>>> could be moved to (they’re currently in Display Options).
>>>
>>> Personally, I’d let this sleeping dog lie for 5.0, but I thought I’d bring 
>>> it to peoples' attention.  (I’m happy to make the changes if people think 
>>> we should for 5.0.)
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> Post to : kicad-developers@lists.launchpad.net 
>>> <mailto:kicad-developers@lists.launchpad.net>
>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> More help   : https://help.launchpad.net/ListHelp 
>>> <https://help.launchpad.net/ListHelp>
>>>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp 
>> <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] Track & via clearances only in Legacy...

[Maciej Sumiński]

Hi Jeff,

Are these options broken on macOS? I see clearance lines displayed for
all items (pads, tracks, vias) in GAL.

example: https://imgur.com/a/LtFtWgR

Cheers,
Orson

On 04/24/2018 08:50 PM, Jeff Young wrote:
> I just discovered that “Show track clearances” and “Show track clearances 
> with via area” settings only work in the Legacy router.  We have a Legacy 
> Router Options area in the general preferences dialog where the options could 
> be moved to (they’re currently in Display Options).
> 
> Personally, I’d let this sleeping dog lie for 5.0, but I thought I’d bring it 
> to peoples' attention.  (I’m happy to make the changes if people think we 
> should for 5.0.)
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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] Windows builds broken?

[Maciej Sumiński]

Sincere apologies. As far as I can see, Jean-Pierre has already pushed a
fix.

Orson

On 04/24/2018 03:22 PM, Wayne Stambaugh wrote:
> Is anyone else have issues with broken windows builds?  I'm getting this
> error after pulling the latest changes:
> 
> C:/msys64/home/wstambaugh/src/kicad-trunk/common/tool/tool_manager.cpp:838:20:
> error: prototype for 'KIGFX::VC_SETTINGS
> TOOL_MANAGER::GetCurrentToolVC() const' does not match any in class
> 'TOOL_MANAGER'
>  KIGFX::VC_SETTINGS TOOL_MANAGER::GetCurrentToolVC() const
> ^~~~
> In file included from
> C:/msys64/home/wstambaugh/src/kicad-trunk/common/tool/tool_manager.cpp:39:0:
> C:/msys64/home/wstambaugh/src/kicad-trunk/include/tool/tool_manager.h:373:25:
> error: candidate is: KIGFX::VC_SETTINGS&
> TOOL_MANAGER::GetCurrentToolVC() const
>  KIGFX::VC_SETTINGS& GetCurrentToolVC() const;
>  ^~~~
> make[2]: *** [common/CMakeFiles/common.dir/build.make:3936:
> common/CMakeFiles/common.dir/tool/tool_manager.cpp.obj] Error 1
> make[1]: *** [CMakeFiles/Makefile2:623:
> common/CMakeFiles/common.dir/all] Error 2
> m
> 
> ___
> Mailing list: https://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] [RFC] Remove bus joining behavior from KiCad after 5.0 release

[Maciej Sumiński]

Hi Reece,

Have a look at an earlier message regarding bus upgrades [1].

Cheers,
Orson

1. https://lists.launchpad.net/kicad-developers/msg32423.html

On 04/20/2018 05:15 PM, Reece R. Pollack wrote:
> Let's not forget the pending wishlist item Bug #1419146
>  to support buses of
> named members.
> 
> You shouldn't have to remember that I2C_DATA is better known as I2C_0
> and I2C_CLOCK is I2C_1. Or was I2C_CLOCK = I2C_0 and I2C_DATA = I2C_1?
> 
> Extending this idea so a bus can contain another bus makes sense. Let's
> take an LCD display. In addition to the 4 or 8 data lines, there are
> several control lines that should be part of the bus. I want an LCD bus
> that contains LCD_E, LCD_RS, and LCD_RW as well as LCD_D[0..7]. And
> while I'm fantasizing, I want the bus name to be "LCD"; I do NOT want it
> named "LCD_E,LCD_RS,LCD_RW,LCD_D[0..7]" the way it is in Eagle.
> 
> -Reece
> 
> On 04/15/18 22:39, Seth Hillbrand wrote:
>> Hi Jon-
>>
>> The major issue I think we would need to address is migration.  I
>> don't think that only an ERC warning is sufficient in this case. 
>> Users will rightfully expect that their old schematics will generate
>> valid netlists when opened in a newer KiCad.
>>
>> One option here would be to translate the implicit net connections
>> into explicit ones when bus junctions are encountered.  Unfortunately,
>> I think that this feature is lightly used, so we might not get much
>> user feedback until they encounter problems and then the problems will
>> be very bad
>>
>> An alternative might be to increase the functionality of the bus
>> junction. Spitballing here but we might add a "mapping table" dialog
>> that allowed the user to specify the winning name and mapping order. 
>> That should address your points 2-3 although point 4 might be the
>> issue.  I think we could have a default mapping that follows the
>> expected convention but allow users to change it by double-clicking on
>> the junction and editing the mapping table.  Then previous users could
>> keep their functionality while still allowing the arbitrary member
>> arrays you are building.
>>
>> Thoughts?
>> -S
>>
>>
>> 2018-04-15 16:40 GMT-07:00 Jon Evans > >:
>>
>>     Hi all,
>>
>>     I am proposing to remove some behavior from KiCad as part of my
>>     bus connections changes.  I know we generally don't remove
>>     features in new releases without good reason, but I think this is
>>     an exceptional case.
>>
>>     The user manual describes a way in which you can connect multiple
>>     different buses together with junctions.  If you aren't already
>>     familiar with this behavior, please check out the manual:
>>    
>> http://docs.kicad-pcb.org/stable/en/eeschema.html#wires-buses-labels-power-ports
>>
>>    
>> 
>>
>>
>>     The section in question is called "Global connections between
>>     buses" and comes with the following image and describes how these
>>     bus wires with different labels are connected together:
>>
>>     Allowing this kind of behavior is problematic for a number of
>> reasons:
>>
>>     1. It means that net wires and bus wires behave differently, since
>>     net wires can't have more than one label.  This is potentially
>>     confusing for users.
>>
>>     2. It means that junctions need a lot of special logic in order to
>>     resolve which "branch" of a bus is called what name (for example,
>>     what if one of those three branches in the above image didn't have
>>     a label? What would its nets be called?)
>>
>>     3. Maybe most importantly, it breaks the label->netlist paradigm,
>>     since an electrical net will only have one label in the eventual
>>     netlist, and there is no way to determine which label should "win"
>>
>>     4. I don't think there's a way to map this behavior onto the new
>>     bus system I have built that allows arbitrary bus members (instead
>>     of just a sequential vector) in a way that would make any sense to
>>     the user.
>>
>>     My proposed changes in this area are as follows:
>>
>>     1. Remove this section from the user manual.
>>
>>     2. In my new connectivity algorithm, treat all connected bus wire
>>     segments as being part of the same bus (meaning they all will have
>>     the same "name")
>>
>>     3. Add an ERC warning about having more than one label attached to
>>     a bus (the warning would appear in the case of the example picture
>>     above)
>>
>>     4. Add a note to the user manual stating that this warning is new
>>     for 6.0
>>
>>     The only downside that I can see in this approach is that any
>>     users who relied on this feature will suddenly get new ERC
>>     warnings.  But I think that this is an "anti-feature" in that it
>>     creates confusion instead of adding value, so we should nudge
>>     anyone who uses it 

Re: [Kicad-developers] [RFC] Remove bus joining behavior from KiCad after 5.0 release

[Maciej Sumiński]

I agree this a slightly confusing feature, which requires reading the
user manual to discover. I vote for removal, but we need a clever
migration plan to do so.

I am not sure how easy would it be to implement it, but how about the
following automatic fix:
- determine the superset of connected buses (PCA[0..15] in the user
manual example)
- determine the other bus names (ADR[0..7] and BUS[5..10])
- rename the other buses to match the superset bus (ADR->PCA, BUS->PCA)

I believe such method keeps the connectivity data intact. Obviously it
would have to be approved by the user, no silent changes.

Cheers,
Orson

On 04/16/2018 05:05 AM, Jon Evans wrote:
> I thought about various ways that we could actually make this feature work,
> but the more I thought about it, the more I thought that we would be
> bending over backwards to support something that shouldn't exist in the
> first place (in my opinion).
> 
> Does anyone have a justification for this feature existing?  I'm not trying
> to sound negative here, but if there is no benefit to it, and eliminating
> it makes the rest of the behavior simpler to code and more logical and
> consistent, we should choose that path.
> If an ERC is not enough of a migration, we could also give a more specific
> one-time nag dialog telling the user in detail what they are going to have
> to do to fix their buses.
> 
> 
> -Jon
> 
> On Sun, Apr 15, 2018 at 10:39 PM, Seth Hillbrand 
> wrote:
> 
>> Hi Jon-
>>
>> The major issue I think we would need to address is migration.  I don't
>> think that only an ERC warning is sufficient in this case.  Users will
>> rightfully expect that their old schematics will generate valid netlists
>> when opened in a newer KiCad.
>>
>> One option here would be to translate the implicit net connections into
>> explicit ones when bus junctions are encountered.   Unfortunately, I think
>> that this feature is lightly used, so we might not get much user feedback
>> until they encounter problems and then the problems will be very bad
>>
>> An alternative might be to increase the functionality of the bus
>> junction.  Spitballing here but we might add a "mapping table" dialog that
>> allowed the user to specify the winning name and mapping order.  That
>> should address your points 2-3 although point 4 might be the issue.  I
>> think we could have a default mapping that follows the expected convention
>> but allow users to change it by double-clicking on the junction and editing
>> the mapping table.  Then previous users could keep their functionality
>> while still allowing the arbitrary member arrays you are building.
>>
>> Thoughts?
>> -S
>>
>>
>> 2018-04-15 16:40 GMT-07:00 Jon Evans :
>>
>>> Hi all,
>>>
>>> I am proposing to remove some behavior from KiCad as part of my bus
>>> connections changes.  I know we generally don't remove features in new
>>> releases without good reason, but I think this is an exceptional case.
>>>
>>> The user manual describes a way in which you can connect multiple
>>> different buses together with junctions.  If you aren't already familiar
>>> with this behavior, please check out the manual:
>>> http://docs.kicad-pcb.org/stable/en/eeschema.html#wires-buse
>>> s-labels-power-ports
>>>
>>> The section in question is called "Global connections between buses" and
>>> comes with the following image and describes how these bus wires with
>>> different labels are connected together:
>>>
>>> Allowing this kind of behavior is problematic for a number of reasons:
>>>
>>> 1. It means that net wires and bus wires behave differently, since net
>>> wires can't have more than one label.  This is potentially confusing for
>>> users.
>>>
>>> 2. It means that junctions need a lot of special logic in order to
>>> resolve which "branch" of a bus is called what name (for example, what if
>>> one of those three branches in the above image didn't have a label? What
>>> would its nets be called?)
>>>
>>> 3. Maybe most importantly, it breaks the label->netlist paradigm, since
>>> an electrical net will only have one label in the eventual netlist, and
>>> there is no way to determine which label should "win"
>>>
>>> 4. I don't think there's a way to map this behavior onto the new bus
>>> system I have built that allows arbitrary bus members (instead of just a
>>> sequential vector) in a way that would make any sense to the user.
>>>
>>> My proposed changes in this area are as follows:
>>>
>>> 1. Remove this section from the user manual.
>>>
>>> 2. In my new connectivity algorithm, treat all connected bus wire
>>> segments as being part of the same bus (meaning they all will have the same
>>> "name")
>>>
>>> 3. Add an ERC warning about having more than one label attached to a bus
>>> (the warning would appear in the case of the example picture above)
>>>
>>> 4. Add a note to the user manual stating that this warning is new for 6.0
>>>
>>> The only downside that I can see in this approach is that any 

Re: [Kicad-developers] Serious Lib cache issue, and fix in commit 2974a2c10

[Maciej Sumiński]

Hi Wayne,

I see, but I wonder if there is any benefit in making the colon
exception just for rescue/cache libraries? I suppose it makes them
special in the sense they cannot be used as regular libraries due to
illegal character in symbol names.

As I said, I am not familiar with caching/rescue code, but I imagine
that once eeschema finds "LibraryName:SymbolName" missing, it could
search for "LibraryName_SymbolName" in rescue/cache libraries. I do not
insist on a change, just taking an opportunity to learn about caching
mechanism.

Cheers,
Orson

On 04/16/2018 03:08 PM, Wayne Stambaugh wrote:
> Hey Orson,
> 
> The colons are required to prevent symbol name clashes in the cache
> library.  I had to prefix the library nickname to the symbol name to
> prevent symbols from being overwritten when they exist in more than on
> library.  In other words, cache library symbol names look just like
> LIB_IDs using the LIB_NICKNAME:SYMBOL_NAME format.
> 
> Cheers,
> 
> Wayne
> 
> On 4/16/2018 9:03 AM, Maciej Sumiński wrote:
>> Hi Jean-Pierre,
>>
>> I understand the patch and thank you for the fix, but apparently I do
>> not have enough knowledge about caching in eeschema to comment on the
>> approach. Frankly, I was a bit surprised to find out that colons are
>> permitted in symbol names stored in a cache library.
>>
>> Regards,
>> Orson
>>
>> On 04/16/2018 11:06 AM, jp charras wrote:
>>> Hi Wayne and Orson,
>>>
>>> Could you have a look into the fix I committed in rev 2974a2c10.
>>> Before this fix, the library cache was broken (all symbol names incorrectly 
>>> saved).
>>> This is specific to the cache, but really annoying...
>>>
>>> Please, see comments in commit 2974a2c10.
>>>
>>> But I am not sure this is the best way to fix this issue.
>>>
>>> Thanks.
>>>
>>
>>
>>
>>
>> ___
>> Mailing list: https://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] Spate of bugs in global fields editor (aka BOM editor)

[Maciej Sumiński]

Hi Jeff,

Are you referring to lp:#1761378 [1] and lp:#1763223 [2] or there are
more bugs? If you have the commits already published somewhere, would
you give links to them? It is easier to evaluate an approach while
looking at related code.

Cheers,
Orson

1. https://bugs.launchpad.net/kicad/+bug/1761378
2. https://bugs.launchpad.net/kicad/+bug/1763223

On 04/16/2018 12:02 PM, Jeff Young wrote:
> Given the spate of bug reports recently on the global fields editor (the 
> spreadsheet icon in eeschema), I’m thinking perhaps I should back-port my 6.0 
> rewrite which moves it to wxGrid.
> 
> The implementation itself seems pretty sound, but does drag one other change 
> list along with it (for dialog consistency and beautification) that adjusts 
> the layouts and icons of a bunch of dialogs to be more consistent.
> 
> Thoughts?
> ___
> Mailing list: https://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] Serious Lib cache issue, and fix in commit 2974a2c10

[Maciej Sumiński]

Hi Jean-Pierre,

I understand the patch and thank you for the fix, but apparently I do
not have enough knowledge about caching in eeschema to comment on the
approach. Frankly, I was a bit surprised to find out that colons are
permitted in symbol names stored in a cache library.

Regards,
Orson

On 04/16/2018 11:06 AM, jp charras wrote:
> Hi Wayne and Orson,
> 
> Could you have a look into the fix I committed in rev 2974a2c10.
> Before this fix, the library cache was broken (all symbol names incorrectly 
> saved).
> This is specific to the cache, but really annoying...
> 
> Please, see comments in commit 2974a2c10.
> 
> But I am not sure this is the best way to fix this issue.
> 
> Thanks.
> 




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] Spaces in library nicknames

[Maciej Sumiński]

Ok, thank you both for clarification. In such case, I suppose we keep
spaces enabled for footprint library and entry names and disable for
symbol related names. I have found a few places that use different rules
for name validation and I wanted to unify them.

Cheers,
Orson

On 04/13/2018 01:30 PM, Wayne Stambaugh wrote:
> Orson,
> 
> You must have missed the original conversation.  We cannot have spaces
> in symbol library nicknames until the schematic and symbol library file
> formats are implemented.  I didn't want to make a change to the current
> schematic file format.  Once they are in place, I will remove the spaces
> restriction.
> 
> Cheers,
> 
> Wayne
> 
> On 04/13/2018 05:45 AM, Maciej Sumiński wrote:
>> Another question is whether spaces are considered valid in library item
>> names (symbols/footprints). Should both logical library names and
>> library items permit the same character set? Seems reasonable to me, but
>> I need to be sure.
>>
>> Cheers,
>> Orson
>>
>> On 04/13/2018 11:36 AM, Maciej Sumiński wrote:
>>> I have just noticed that one cannot use spaces in symbol library
>>> nicknames [1], whereas they are valid for footprint library nicknames
>>> [2]. I suppose it should be unified and moved to a function (static
>>> method in LIB_ID?) to avoid valid characters sets diversion. I will fix
>>> it, but I need to know what is the decision about spaces.
>>>
>>> Cheers,
>>> Orson
>>>
>>> 1.
>>> https://github.com/KiCad/kicad-source-mirror/blob/master/eeschema/dialogs/dialog_sym_lib_table.cpp#L269
>>> 2.
>>> https://github.com/KiCad/kicad-source-mirror/blob/master/pcbnew/dialogs/dialog_fp_lib_table.cpp#L302
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://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] Spaces in library nicknames

[Maciej Sumiński]

Another question is whether spaces are considered valid in library item
names (symbols/footprints). Should both logical library names and
library items permit the same character set? Seems reasonable to me, but
I need to be sure.

Cheers,
Orson

On 04/13/2018 11:36 AM, Maciej Sumiński wrote:
> I have just noticed that one cannot use spaces in symbol library
> nicknames [1], whereas they are valid for footprint library nicknames
> [2]. I suppose it should be unified and moved to a function (static
> method in LIB_ID?) to avoid valid characters sets diversion. I will fix
> it, but I need to know what is the decision about spaces.
> 
> Cheers,
> Orson
> 
> 1.
> https://github.com/KiCad/kicad-source-mirror/blob/master/eeschema/dialogs/dialog_sym_lib_table.cpp#L269
> 2.
> https://github.com/KiCad/kicad-source-mirror/blob/master/pcbnew/dialogs/dialog_fp_lib_table.cpp#L302
> 
> 
> 
> ___
> Mailing list: https://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

[Kicad-developers] Spaces in library nicknames

[Maciej Sumiński]

I have just noticed that one cannot use spaces in symbol library
nicknames [1], whereas they are valid for footprint library nicknames
[2]. I suppose it should be unified and moved to a function (static
method in LIB_ID?) to avoid valid characters sets diversion. I will fix
it, but I need to know what is the decision about spaces.

Cheers,
Orson

1.
https://github.com/KiCad/kicad-source-mirror/blob/master/eeschema/dialogs/dialog_sym_lib_table.cpp#L269
2.
https://github.com/KiCad/kicad-source-mirror/blob/master/pcbnew/dialogs/dialog_fp_lib_table.cpp#L302



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] wxPython-gtk3 woes

[Maciej Sumiński]

It seems the easy solution to me too. I just wonder how many people rely
on the Python shell or GUIs done with wxPython.

On 04/10/2018 01:32 PM, Jeff Young wrote:
> I never got KICAD_SCRIPTING_WXPYTHON to work on my Mac, and I can’t say I’ve 
> missed it.
> 
>> On 10 Apr 2018, at 12:26, Maciej Sumiński <maciej.sumin...@cern.ch> wrote:
>>
>> Apparently mixing wxWidgets-gtk2 and wxPython-gtk3 [1] is not only an
>> Arch issue anymore, as the upcoming Ubuntu release (bionic) also
>> provides wxPython package built against gtk3 [package: 2, bug report: 3].
>>
>> There are two things we can do to fix the problem for v5:
>> - Backport python-wxgtk3.0 package built against gtk2. This way
>> everything works as it used to be, but only for the nightlies. For the
>> official release the users would be forced to add a PPA providing the
>> backported package and it sounds troublesome.
>>
>> - Disable KICAD_SCRIPTING_WXPYTHON, as there is still available
>> libwxgtk3.0 package [4] build against gtk2. The drawbacks are that the
>> Python shell in pcbnew and scripts taking advantage of wxPython to
>> display a GUI will not work anymore.
>>
>> In other news: Ubuntu bionic also ships wxPhoenix [5].
>>
>> Cheers,
>> Orson
>>
>> 1. https://bugs.launchpad.net/kicad/+bug/1747677
>> 2. https://packages.ubuntu.com/bionic/python-wxgtk3.0
>> 3. https://bugs.launchpad.net/kicad/+bug/1762432
>> 4. https://packages.ubuntu.com/bionic/libwxgtk3.0-0v5
>> 5. https://packages.ubuntu.com/bionic/python3-wxgtk4.0
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 




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

[Kicad-developers] wxPython-gtk3 woes

[Maciej Sumiński]

Apparently mixing wxWidgets-gtk2 and wxPython-gtk3 [1] is not only an
Arch issue anymore, as the upcoming Ubuntu release (bionic) also
provides wxPython package built against gtk3 [package: 2, bug report: 3].

There are two things we can do to fix the problem for v5:
- Backport python-wxgtk3.0 package built against gtk2. This way
everything works as it used to be, but only for the nightlies. For the
official release the users would be forced to add a PPA providing the
backported package and it sounds troublesome.

- Disable KICAD_SCRIPTING_WXPYTHON, as there is still available
libwxgtk3.0 package [4] build against gtk2. The drawbacks are that the
Python shell in pcbnew and scripts taking advantage of wxPython to
display a GUI will not work anymore.

In other news: Ubuntu bionic also ships wxPhoenix [5].

Cheers,
Orson

1. https://bugs.launchpad.net/kicad/+bug/1747677
2. https://packages.ubuntu.com/bionic/python-wxgtk3.0
3. https://bugs.launchpad.net/kicad/+bug/1762432
4. https://packages.ubuntu.com/bionic/libwxgtk3.0-0v5
5. https://packages.ubuntu.com/bionic/python3-wxgtk4.0





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] [RFC] Able to install KiCad stable and "daily build" in same computer

[Maciej Sumiński]

Hi Jean-Samuel,

I suppose most people on the dev mailing list compile KiCad themselves,
but I am pretty sure the users would appreciate the possibility of
having two KiCad versions installed.

If you think the package is ready to be tested by a wider group, how
about announcing it on the kicad.info forum [1]? If you do not have an
account there, I can post a notice there for you.

Regards,
Orson

1. https://forum.kicad.info/

On 04/04/2018 12:52 PM, Jean-Samuel Reynaud wrote:
> Dear All,
> 
> 
> Since I provide PPA (daily build for Ubuntu) for KiCad, I receive some
> requests about installing daily build packages in parallel with stable
> version.
> With next version (V5) I think it can be useful...
> FreeCad provide this kind of feature and you are able to run both
> version in parallel.
> 
> For testing that I had created a dedicated PPA:
> ppa:js-reynaud/kicad-dev-daily
> (to add with sudo add-apt-repository ppa:js-reynaud/kicad-dev-daily)
> 
> Once added, you are able to install a new package "kicad-daily" that
> won't conflict with existing "kicad" packages.
> All files are installed on a separate folder and commands became
> "something-daily". For example kicad-daily or pcbnew-daily...
> 
> So my questions are:
> - Is it usefull ?
> - Is it a bad idea/stupid :( ?
> - If you test it, are you able to find some limitations/bugs ?
> - Perhaps to have is plainly functional some modifications are needed.
> What modifications ?
> 
> 
> For the moment, you can't run in same time two versions (or there are
> some error messages...) anyway both are installed and easily "runnable"...
> 
> 
> Please give your comments, feedbacks...
> 
> ___
> Mailing list: https://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] rc2

[Maciej Sumiński]

On 04/03/2018 01:20 PM, Tomasz Wlostowski wrote:
> On 03/04/18 13:17, Nick Østergaard wrote:
>> I think we should not disable the github plugin, but we may need to
>> remove it from the wizard in a way that does not emphasize that this is
>> the way to go. Maybe it is ok to remove it completely from the wizard,
>> but just let the plugin in the fp-lib-table still work.
> 
> I would rather disable it (with the possibility to re-enable in some
> config file for "hardcore" users). Over the last 3 years it brought us
> mostly troubles and no big advantage.

I second that, the only potential issue we need to deal with is the
current plugin users. Once we remove the plugin, they will be stuck with
footprint libraries full of broken entries.

For v6 we should simply provide a simple library updater taking
advantage of generic git interface (e.g. libgit), instead of tying
ourselves to Github.

Cheers,
Orson



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

Re: [Kicad-developers] Spice simulation on macOS

[Maciej Sumiński]

This is fine, thank you for quick response Jeff! I am looking at a bug
report describing problems with ngspice initialization on macOS [1], but
then it must be occurring only in KiCad installed from a package.

Cheers,
Orson

1. https://bugs.launchpad.net/kicad/+bug/1630675

On 03/26/2018 01:37 PM, Jeff Young wrote:
> Testing on my build gives a warning, but not an “unknown model” one:
> 
> Circuit: KiCad schematic
> Reducing trtol to 1 for xspice 'A' devices
> Doing analysis at TEMP = 27.00 and TNOM = 27.00
> Warning: vv1: has no value, DC 0 assumed
>  Reference value :  1.0e+00
> 
> No. of Data Rows : 61
> 
> I get nice plots when adding a signal.
> 
> Cheers,
> Jeff.
> 
> 
>> On 26 Mar 2018, at 12:30, Maciej Sumiński <maciej.sumin...@cern.ch> wrote:
>>
>> Would someone running nightlies on macOS test the Spice simulator? In
>> particular, please simulate demos/simulation/sallen_key from our bundled
>> demos and see if you get warnings "Unknown model type spice2poly -
>> ignored". Testing both a self-built nightly and our official package [1]
>> would be greatly appreciated.
>>
>> Regards,
>> Orson
>>
>> 1. http://downloads.kicad-pcb.org/osx/nightly/
>>
>> ___
>> Mailing list: https://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

[Kicad-developers] Spice simulation on macOS

[Maciej Sumiński]

Would someone running nightlies on macOS test the Spice simulator? In
particular, please simulate demos/simulation/sallen_key from our bundled
demos and see if you get warnings "Unknown model type spice2poly -
ignored". Testing both a self-built nightly and our official package [1]
would be greatly appreciated.

Regards,
Orson

1. http://downloads.kicad-pcb.org/osx/nightly/



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] Don't create an extra segment at the end of closed SHAPE_LINE_CHAIN

[Maciej Sumiński]

Hi Jon,

If we decide to handle this special case, then we need to account for
the point count as well. Otherwise it may lead to situations when the
number of points is higher than the number of segments.

Please see the attached patch (particularly 0002). I think these changes
might be committed after a short test period. If we want to go the safe,
but not so elegant way, then perhaps a simple condition could be added
to POLYGON_GEOM_MANAGER::IsSelfIntersecting().

Cheers,
Orson

On 03/25/2018 04:07 AM, Jon Evans wrote:
> Hi all (but especially Orson),
> 
> I wanted to fix the issue Bernhard raised here:
> https://bugs.launchpad.net/kicad/+bug/1751654/comments/7
> 
> I dug in to it a bit and found out
> that SHAPE_LINE_CHAIN::SelfIntersecting() doesn't work right when polygons
> are actually closed (i.e. the last point is the same as the first) and when
> m_closed is set to true.
> 
> The attached patch fixes this by only generating a closing segment when the
> last point isn't the same as the first point.  It fixes the issue with the
> self-intersection warning showing up even when you aren't yet intersecting
> (i.e. when the last point is the same as the first), and I didn't notice
> any obvious other issues, but maybe you can double-check that changing the
> behavior of SegmentCount() won't have any strange side-effects.
> 
> Thanks,
> -Jon
> 

From c90eefc472ff31999a2273d87b4967b3a9518e2e Mon Sep 17 00:00:00 2001
From: Maciej Suminski 
Date: Mon, 26 Mar 2018 11:23:43 +0200
Subject: [PATCH 1/2] Code formatting

---
 common/geometry/shape_line_chain.cpp | 12 
 include/geometry/shape_line_chain.h  |  1 +
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/common/geometry/shape_line_chain.cpp b/common/geometry/shape_line_chain.cpp
index 5f11b376c..2e0e12f10 100644
--- a/common/geometry/shape_line_chain.cpp
+++ b/common/geometry/shape_line_chain.cpp
@@ -397,7 +397,7 @@ const OPT SHAPE_LINE_CHAIN::SelfIntersecting() c
  // for closed polylines, the ending point of the
  // last segment == starting point of the first segment
  // this is a normal case, not self intersecting case
- !( IsClosed() && s1 == 0 && s2 == SegmentCount()-1 ) )
+ !( IsClosed() && s1 == 0 && s2 == SegmentCount() - 1 ) )
 {
 INTERSECTION is;
 is.our = CSegment( s1 );
@@ -547,18 +547,21 @@ const std::string SHAPE_LINE_CHAIN::Format() const
 }
 
 
-bool SHAPE_LINE_CHAIN::CompareGeometry ( const SHAPE_LINE_CHAIN & aOther ) const
+bool SHAPE_LINE_CHAIN::CompareGeometry( const SHAPE_LINE_CHAIN& aOther ) const
 {
-SHAPE_LINE_CHAIN a(*this), b( aOther );
+SHAPE_LINE_CHAIN a( *this ), b( aOther );
 a.Simplify();
 b.Simplify();
 
 if( a.m_points.size() != b.m_points.size() )
 return false;
 
-for( int i = 0; i < a.PointCount(); i++)
+for( int i = 0; i < a.PointCount(); i++ )
+{
 if( a.CPoint( i ) != b.CPoint( i ) )
 return false;
+}
+
 return true;
 }
 
@@ -624,6 +627,7 @@ const VECTOR2I SHAPE_LINE_CHAIN::PointAlong( int aPathLength ) const
 return CPoint( -1 );
 }
 
+
 double SHAPE_LINE_CHAIN::Area() const
 {
 // see https://www.mathopenref.com/coordpolygonarea2.html
diff --git a/include/geometry/shape_line_chain.h b/include/geometry/shape_line_chain.h
index 135ea8b18..fad136fce 100644
--- a/include/geometry/shape_line_chain.h
+++ b/include/geometry/shape_line_chain.h
@@ -171,6 +171,7 @@ public:
 int SegmentCount() const
 {
 int c = m_points.size() - 1;
+
 if( m_closed && ( m_points[0] != m_points[c] ) )
 c++;
 
-- 
2.16.2

From 31903b03e22a831f3878bc32f61de19241133845 Mon Sep 17 00:00:00 2001
From: Maciej Suminski 
Date: Mon, 26 Mar 2018 12:49:16 +0200
Subject: [PATCH 2/2] Handle correctly closed SHAPE_LINE_CHAINs with equal
 first and last points

SHAPE_LINE_CHAIN by default do not repeat the first point in the point
list, even when it is set to 'closed'. In case the first point is
duplicated as the last point, the returned number of points/segments
needs to be adjusted to match the default behavior (ignore the duplicated
point).
---
 common/geometry/shape_line_chain.cpp |  6 +++---
 include/geometry/shape_line_chain.h  | 19 ---
 2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/common/geometry/shape_line_chain.cpp b/common/geometry/shape_line_chain.cpp
index 2e0e12f10..5e3a6fea1 100644
--- a/common/geometry/shape_line_chain.cpp
+++ b/common/geometry/shape_line_chain.cpp
@@ -538,7 +538,7 @@ const std::string SHAPE_LINE_CHAIN::Format() const
 {
 std::stringstream ss;
 
-ss << m_points.size() << " " << ( m_closed ? 1 : 0 ) << " ";
+ss << PointCount() << " " << ( m_closed ? 1 : 0 ) << " ";
 
 for( int i = 0; i < PointCount(); i++ )
 ss << m_points[i].x << " " << 

Re: [Kicad-developers] compil warning in eagle plugin.

[Maciej Sumiński]

Hi Jean-Pierre,

I have just fixed it. Fortunately, 'radius' is used in a while loop that
requires the preceding if clause to be true. 'Radius' is initialized in
the mentioned if clause body, so it should never run with an
uninitialized value.

Regards,
Orson

On 03/14/2018 03:21 PM, jp charras wrote:
> Could a Eagle guru have a look into the code creating this compil warning:
> 
> F:/kicad-launchpad/zone_on_grid/pcbnew/eagle_plugin.cpp:1811:50: warning: 
> 'radius' may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>  wxPoint end( int( radius * cos( end_angle + angle ) 
> + center.x ),
>~~~^~
> F:/kicad-launchpad/zone_on_grid/pcbnew/eagle_plugin.cpp:1812:55: warning: 
> 'end_angle' may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>   int( radius * sin( end_angle + angle ) 
> + center.y ) );
> 
> It looks to me these variables are really used without initialization is some 
> cases.
> 
> Thanks.
> 




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] Need guidance/hints on accessing list of available pcbnew footprints from python

[Maciej Sumiński]

Hi Miles,

Have you seen FOOTPRINT_VIEWER_FRAME::ReCreateFootprintList()
(pcbnew/footprint_viewer_frame.cpp)? It might be the easiest way to go.
Perhaps it could be wrapped in a function provided by the scripting
interface.

I could not find 'includefallback' option you have mentioned, would you
point me to the relevant source code?

Regards,
Orson

On 03/13/2018 10:49 AM, miles mccoo wrote:
> In one of my python plugins, I want to know the list of available
> footprints (mounting holes, in this case)
> 
> Digging through the code, I can't make heads or tails of how to get this
> information. There are a bunch of abstract class involved. impls
> 
> There are a couple possibilities, none of which seem clean.
> 
> *Stuff from FOOTPRINT plugin*
> looking in footprint.i, I see some APIs that are close.
> If I have a directory path to a fp library, I can
> call pcbnew.FootprintEnumerate for a nice list.
> 
> but for that, I first have to have a list of fp library paths. *How do I
> get such a list? *This seems like the closest answer. I see my config dir
> has a fp-lib-table file which would be easy to parse. But that's a hack.
> 
> 
> 
> *FOOTPRINT_LIST_IMPL possibility*
> looking in load_select_footprint, I see it has a static FOOTPRINT_LIST_IMPL
> which does have the APIs I'd need to get to a nice list of footprint_infos.
> But it's static to that file. I could copy the relevant code to
> python_scripting_helpers. but that feels messy.
> 
> PCB_BASE_FRAME does have a method for popping up a table for a user to
> choose a footprint, which is nice for UI. It could even be useful for
> python plugins with some GUI stuff. But many python scripts will just want
> a list of libraries and modules.
> 
> 
> 
> *PROJECT possibility*
> I tried exposing PROJECT to python as it has a number of useful sounding
> API including PcbFootprintLibs which returns a FP_LIB_TABLE. By poking
> around in gdb, I see that FP_LIB_TABLE has GetCount and IsEmpty. IsEmpty
> returns false if I set includefallback to true. and the fallback list does
> indeed have stuff in it. But it's protected and I don't see how to get to
> it.
> 
> Can I expose the fallback table via a public get method?
> 
> 
> Is that a path that has any hope?
> 
> 
> 
> 
>  *So what's the most straight forward way to get to the list of libraries
> and modules within them?*
> 
> Thanks
> Miles
> 
> 
> 
> ___
> Mailing list: https://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] Deletion in plugins causing trouble

[Maciej Sumiński]

Thank you Miles, I have just pushed your patch. I agree with Wayne, one
day we will need to revise the Python scripting interface.

Regards,
Orson

On 03/06/2018 10:02 AM, miles mccoo wrote:
> Thanks all for your replies.
> 
> I like the plugin mechanism. It does some nice things for python folks.
> Refresh, undo, garbage collection (I think). I want to see it succeed.
> 
> From reading Orson's mail, I think I wasn't entirely clear, so let me try
> to fix that first.
> 
> 
> The plugin mechanism tries to track the changes of a python plugin. In the
> c++ world, developers are expected to inform BOARD_COMMIT that something
> has changed. The plugin infrastructure does this for you. One could compare
> it to garbage collection. My interpretation of how this is done is simple:
> before a plugin runs, make a list of all design objects. zones, tracks,
> modules, nets... after the plugin completes, do a "diff".
> 
> This is mostly fine with the exception of removed items.
> 
> The problem with removed items is how do you do a diff on a deleted, memory
> managed, cleaned up object? Perhaps that memory now contains a different
> kind of object. Perhaps it's been reallocated to a similar object as before.
> 
> 
> 
> *as it stands now, any plugin that removes items from a board item
> container will likely fail*. It's not quite a crash, but it has a similar
> feel to the user.
> 
> 
> 
> Solutions. I can think of four.
> 
> solution 1. Why is the plugin mechanism in the business of tracking
> changes? Shouldn't BOARD_COMMIT just magically happen whenever a c++
> instance is modified. I brought this up in a previous thread[1] and various
> reasons were given why this isn't desirable.
> 
> solution 2. Same as #1 except BC magic only happens on python API calls.
> The plugin mechanism would no longer do diffs. Just add BC checkpoints.
> This is probably a lot of work. I might be willing to do this work but it
> would take time. [2]
> 
> solution 3. easy to implement. turn off deletion on calls to remove if
> currently running a plugin
> 
>- plugin gets a boolean: isPluginActive. set/unset around the call to
>actual python run code.
>- add pcbnew.isPluginActive() to python api. (I could imagine this could
>have other uses)
>- the remove code looks at isPluginActive to decide whether to set
>isown. (that code is actually python, not swig)
> 
> I have #3 implemented and my plugins no longer crash. *See attached patch
> for if folks agree it is an acceptable stopgap.*
> 
> solution 4. probably not the direction I would go but a way to enable
> python memory management and do the plugin diff thing. Basically, give each
> object some sort of unique id. (could be useful for other things). In
> addition to holding a list of object pointers, plugin infrastructure would
> hold a list of object ids.
> 
> 
> *Given the ease with which a plugin can hit this issue and given how long
> it would take to get #2 right, I guess I'm recommending the changes of that
> attached patch for #3.*
> 
> Miles
> 
> [1] https://lists.launchpad.net/kicad-developers/msg32063.html
> [2] I think my personal opinion is that #1 is superior over #2. Python
> people shouldn't have to care but why is it that c++ should or want to?
> Yes, I read the arguments from the previous thread but I'm not convinced.
> I'm also just a kicad spectator, so there's a lot I don't know.
> 
> 
> 
> 
> 
> On Fri, Mar 2, 2018 at 2:47 PM, Wayne Stambaugh <stambau...@gmail.com>
> wrote:
> 
>> LOL, I just replied to Miles.  Thanks Orson for helping out!
>>
>> On 3/2/2018 8:36 AM, Maciej Sumiński wrote:
>>> Hi Miles,
>>>
>>> I suppose the silence in the thread indicates there are not many
>>> developers knowing the Python scripting interface inside out. Since you
>>> are both studying the scripting interface and developing own scripts, it
>>> is quite possible you are the most competent person to give us an advice
>>> on how to proceed. See some comments below, but I am neither a Python
>>> script developer nor a scripting interface maintainer, so I might be
>>> lacking some basic knowledge here.
>>>
>>> On 02/28/2018 05:12 PM, miles mccoo wrote:
>>>> So I'm plugin-ifying my python scripts (the mechanism is awesome). One
>> of
>>>> the plugins deletes some stuff and that is causing trouble.
>>>>
>>>>
>>>>
>>>> I'm not sure how to fix the root cause. Hence this mail.
>>>>
>>>>
>>>>
>>>> The plugin just deletes Edge.Cuts[1]:
>>>> for d in board.GetD

Re: [Kicad-developers] Deletion in plugins causing trouble

[Maciej Sumiński]

In my opinion #3 is acceptable. It does not require any extra changes in
the existing scripts and it fixes the problem until we come up with a
better scripting interface. If nobody has objections, I am going to
commit the patch.

Regards,
Orson

On 03/06/2018 10:02 AM, miles mccoo wrote:
> Thanks all for your replies.
> 
> I like the plugin mechanism. It does some nice things for python folks.
> Refresh, undo, garbage collection (I think). I want to see it succeed.
> 
> From reading Orson's mail, I think I wasn't entirely clear, so let me try
> to fix that first.
> 
> 
> The plugin mechanism tries to track the changes of a python plugin. In the
> c++ world, developers are expected to inform BOARD_COMMIT that something
> has changed. The plugin infrastructure does this for you. One could compare
> it to garbage collection. My interpretation of how this is done is simple:
> before a plugin runs, make a list of all design objects. zones, tracks,
> modules, nets... after the plugin completes, do a "diff".
> 
> This is mostly fine with the exception of removed items.
> 
> The problem with removed items is how do you do a diff on a deleted, memory
> managed, cleaned up object? Perhaps that memory now contains a different
> kind of object. Perhaps it's been reallocated to a similar object as before.
> 
> 
> 
> *as it stands now, any plugin that removes items from a board item
> container will likely fail*. It's not quite a crash, but it has a similar
> feel to the user.
> 
> 
> 
> Solutions. I can think of four.
> 
> solution 1. Why is the plugin mechanism in the business of tracking
> changes? Shouldn't BOARD_COMMIT just magically happen whenever a c++
> instance is modified. I brought this up in a previous thread[1] and various
> reasons were given why this isn't desirable.
> 
> solution 2. Same as #1 except BC magic only happens on python API calls.
> The plugin mechanism would no longer do diffs. Just add BC checkpoints.
> This is probably a lot of work. I might be willing to do this work but it
> would take time. [2]
> 
> solution 3. easy to implement. turn off deletion on calls to remove if
> currently running a plugin
> 
>- plugin gets a boolean: isPluginActive. set/unset around the call to
>actual python run code.
>- add pcbnew.isPluginActive() to python api. (I could imagine this could
>have other uses)
>- the remove code looks at isPluginActive to decide whether to set
>isown. (that code is actually python, not swig)
> 
> I have #3 implemented and my plugins no longer crash. *See attached patch
> for if folks agree it is an acceptable stopgap.*
> 
> solution 4. probably not the direction I would go but a way to enable
> python memory management and do the plugin diff thing. Basically, give each
> object some sort of unique id. (could be useful for other things). In
> addition to holding a list of object pointers, plugin infrastructure would
> hold a list of object ids.
> 
> 
> *Given the ease with which a plugin can hit this issue and given how long
> it would take to get #2 right, I guess I'm recommending the changes of that
> attached patch for #3.*
> 
> Miles
> 
> [1] https://lists.launchpad.net/kicad-developers/msg32063.html
> [2] I think my personal opinion is that #1 is superior over #2. Python
> people shouldn't have to care but why is it that c++ should or want to?
> Yes, I read the arguments from the previous thread but I'm not convinced.
> I'm also just a kicad spectator, so there's a lot I don't know.
> 
> 
> 
> 
> 
> On Fri, Mar 2, 2018 at 2:47 PM, Wayne Stambaugh <stambau...@gmail.com>
> wrote:
> 
>> LOL, I just replied to Miles.  Thanks Orson for helping out!
>>
>> On 3/2/2018 8:36 AM, Maciej Sumiński wrote:
>>> Hi Miles,
>>>
>>> I suppose the silence in the thread indicates there are not many
>>> developers knowing the Python scripting interface inside out. Since you
>>> are both studying the scripting interface and developing own scripts, it
>>> is quite possible you are the most competent person to give us an advice
>>> on how to proceed. See some comments below, but I am neither a Python
>>> script developer nor a scripting interface maintainer, so I might be
>>> lacking some basic knowledge here.
>>>
>>> On 02/28/2018 05:12 PM, miles mccoo wrote:
>>>> So I'm plugin-ifying my python scripts (the mechanism is awesome). One
>> of
>>>> the plugins deletes some stuff and that is causing trouble.
>>>>
>>>>
>>>>
>>>> I'm not sure how to fix the root cause. Hence this mail.
>>>>
>>>>
>>>&g

Re: [Kicad-developers] Handling invalid characters in symbol/component LIB_IDs

[Maciej Sumiński]

On 03/06/2018 07:34 PM, Wayne Stambaugh wrote:
> Orson,
> 
> On 3/6/2018 8:55 AM, Maciej Sumiński wrote:
>> I am trying to find a reasonable way to handle symbol and components
>> with invalid characters in their LIB_IDs (see bug report #1752419 [1]).
>> While now it is impossible to create such LIB_IDs, we need to handle
>> documents that had been created before the restriction was introduced.
>>
>> LIB_IDs in SCH_COMPONENTS will have illegal characters replaced on load,
>> but it is not the case for LIB_{PART,ALIAS} classes. Due to that:
>>
>> - Symbol-component links are broken (e.g. component with LIB_ID
>> 'Test/Name' will change to 'Test_Name', but the corresponding LIB_PART
>> will remain 'Test/Name'.
>>
>> - It is impossible to place/edit such symbols.
>>
>> The simplest solution is to process LIB_{PART,ALIAS} LIB_IDs in the same
>> way as id done for SCH_COMPONENTs, so they become valid names that match
>> SCH_COMPONENTs using them (see the attached patches). There are two
>> drawbacks:
> 
> I would prefer to keep the behavior consistent with what is done with
> the SCH_COMPONENT LIB_ID renaming.  I know it's less than elegant but we
> are going to just have to take our medicine until we transition over to
> the new file format.

That is what I am thinking as well, so I have coded it this way in the
patches.

>> - Changing names that user had previously assigned, which might be
>> annoying if LIB_IDs are used e.g. to create BOMs. Personally I would use
>> the value field that accepts all characters for this purpose.
> 
> Can LIB_IDs be used in BOMs?  That would be an odd way to do it but I
> suppose you could.  Typically the contents of the value field is used
> for BOM output not the symbol name.
> 
>>
>> - Naming conflicts may occur (e.g. both 'Test/Name' and 'Test:Name' will
>> be changed to 'Test_Name', but I believe it is a rare case.
> 
> I just used a simple counter to append digits to the end of the name in
> the case of name conflicts in the remapping code so a similar approach
> here would not be out of line.

Good point, implemented and pushed to the master branch.

Cheers,
Orson

>> Any thoughts? I believe a more elegant solution will be implemented once
>> the new schematic file format is ready.
> 
> The current behavior is just going to last during v5.  Once the new
> schematic file format is done and the LIB_ID parser and formatter
> support escaping the / and : characters, we should be able to use any
> character (except for control characters) in LIB_IDs.
> 
>>
>> Cheers,
>> Orson
>>
>> 1. https://bugs.launchpad.net/kicad/+bug/1752419
>>
>>
>>
>> ___
>> Mailing list: https://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] Zone filling problems

[Maciej Sumiński]

Hi Steven,

Good catch, thank you for the report. It should be already fixed
(a3562b35 and later).

Regards,
Orson

On 03/07/2018 06:28 AM, Strontium wrote:
> Sorry for posting this, AND also posting a bug report, but i know you
> guys are close to releasing a V5 and i have been testing RC2 from
> nightly PPA and have hit two bugs which would be show stoppers for me,
> and make me want to go back to V4.
> 
> First one is a problem with Zone refills using DRC.
> 
> If I have a zone, and place a via or track over it from another net. 
> And then do a DRC, but select "Refill all zones..." then the DRC
> proceeds without error, and says it refilled the Zone.
> 
> However, a visual inspection of the board shows, no the zone did not
> refill and the via and zone now clash because they are not the same net,
> but there is no DRC violation.
> 
> Thats what it looks like. But what is really happening is the zone is
> being recalculated, and the DRC is passing because the Zone does now
> actually flow properly around the net overlapping it. BUT what happens
> is the board is not redrawn to show the new zone outline.  Zooming
> around the board, etc, does not cause it to redraw either.  The only
> ways i have found to make it redraw is to manually select the zone for
> editing, or to press "B"
> 
> Its a highly disconcerting problem, because the board that kicad
> "understands" and the one it "displays" are out of sync.
> 
> The effect is obvious when one does a 3d render of the board, because
> that shows the board that kicad understands, even though in the pcb
> editor its shown as not that.  as shown here:
> http://i.imgur.com/hKfPJ22.png
> 
> the other problem i will post separately.
> 
> Steven
> 
> 
> ___
> Mailing list: https://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] Handling invalid characters in symbol/component LIB_IDs

[Maciej Sumiński]

Attached a small project to observe the problem/test the patches. There
are two libraries inside:
- slash.lib contains one symbol with '/' in its LIB_ID
- slash_conflict.lib contains two symbols that result in a LIB_ID clash
(RELAY_Hongfa_HF115F/012-1H3T and RELAY_Hongfa_HF115F_012-1H3T).

Normally you can use slash.lib, but if you want to check what happens in
case of a conflict, then use the other one.

On 03/06/2018 02:55 PM, Maciej Sumiński wrote:
> I am trying to find a reasonable way to handle symbol and components
> with invalid characters in their LIB_IDs (see bug report #1752419 [1]).
> While now it is impossible to create such LIB_IDs, we need to handle
> documents that had been created before the restriction was introduced.
> 
> LIB_IDs in SCH_COMPONENTS will have illegal characters replaced on load,
> but it is not the case for LIB_{PART,ALIAS} classes. Due to that:
> 
> - Symbol-component links are broken (e.g. component with LIB_ID
> 'Test/Name' will change to 'Test_Name', but the corresponding LIB_PART
> will remain 'Test/Name'.
> 
> - It is impossible to place/edit such symbols.
> 
> The simplest solution is to process LIB_{PART,ALIAS} LIB_IDs in the same
> way as id done for SCH_COMPONENTs, so they become valid names that match
> SCH_COMPONENTs using them (see the attached patches). There are two
> drawbacks:
> 
> - Changing names that user had previously assigned, which might be
> annoying if LIB_IDs are used e.g. to create BOMs. Personally I would use
> the value field that accepts all characters for this purpose.
> 
> - Naming conflicts may occur (e.g. both 'Test/Name' and 'Test:Name' will
> be changed to 'Test_Name', but I believe it is a rare case.
> 
> Any thoughts? I believe a more elegant solution will be implemented once
> the new schematic file format is ready.
> 
> Cheers,
> Orson
> 
> 1. https://bugs.launchpad.net/kicad/+bug/1752419
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 



slash_test.tar.bz2
Description: BZip2 compressed data


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

[Kicad-developers] Handling invalid characters in symbol/component LIB_IDs

[Maciej Sumiński]

I am trying to find a reasonable way to handle symbol and components
with invalid characters in their LIB_IDs (see bug report #1752419 [1]).
While now it is impossible to create such LIB_IDs, we need to handle
documents that had been created before the restriction was introduced.

LIB_IDs in SCH_COMPONENTS will have illegal characters replaced on load,
but it is not the case for LIB_{PART,ALIAS} classes. Due to that:

- Symbol-component links are broken (e.g. component with LIB_ID
'Test/Name' will change to 'Test_Name', but the corresponding LIB_PART
will remain 'Test/Name'.

- It is impossible to place/edit such symbols.

The simplest solution is to process LIB_{PART,ALIAS} LIB_IDs in the same
way as id done for SCH_COMPONENTs, so they become valid names that match
SCH_COMPONENTs using them (see the attached patches). There are two
drawbacks:

- Changing names that user had previously assigned, which might be
annoying if LIB_IDs are used e.g. to create BOMs. Personally I would use
the value field that accepts all characters for this purpose.

- Naming conflicts may occur (e.g. both 'Test/Name' and 'Test:Name' will
be changed to 'Test_Name', but I believe it is a rare case.

Any thoughts? I believe a more elegant solution will be implemented once
the new schematic file format is ready.

Cheers,
Orson

1. https://bugs.launchpad.net/kicad/+bug/1752419
From b3061c2f8c4ec2723b93e58c7a6c0d09ef15298b Mon Sep 17 00:00:00 2001
From: Maciej Suminski 
Date: Tue, 6 Mar 2018 10:11:54 +0100
Subject: [PATCH 1/4] Added ReplaceIllegalFileNameChars() for wxString&

---
 common/string.cpp  | 37 ++---
 include/kicad_string.h |  1 +
 2 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/common/string.cpp b/common/string.cpp
index 8f35b83d6..8932fbc18 100644
--- a/common/string.cpp
+++ b/common/string.cpp
@@ -482,8 +482,9 @@ wxString GetIllegalFileNameWxChars()
 
 bool ReplaceIllegalFileNameChars( std::string* aName, int aReplaceChar )
 {
-bool  changed = false;
-std::string   result;
+bool changed = false;
+std::string result;
+result.reserve( aName->length() );
 
 for( std::string::iterator it = aName->begin();  it != aName->end();  ++it )
 {
@@ -503,7 +504,37 @@ bool ReplaceIllegalFileNameChars( std::string* aName, int aReplaceChar )
 }
 
 if( changed )
-*aName =  result;
+*aName = result;
+
+return changed;
+}
+
+
+bool ReplaceIllegalFileNameChars( wxString& aName, int aReplaceChar )
+{
+bool changed = false;
+wxString result;
+result.reserve( aName.Length() );
+
+for( wxString::iterator it = aName.begin();  it != aName.end();  ++it )
+{
+if( strchr( illegalFileNameChars, *it ) )
+{
+if( aReplaceChar )
+result += aReplaceChar;
+else
+result += wxString::Format( "%%%02x", *it );
+
+changed = true;
+}
+else
+{
+result += *it;
+}
+}
+
+if( changed )
+aName = result;
 
 return changed;
 }
diff --git a/include/kicad_string.h b/include/kicad_string.h
index abf6a8200..3a4f45fbe 100644
--- a/include/kicad_string.h
+++ b/include/kicad_string.h
@@ -172,6 +172,7 @@ wxString GetIllegalFileNameWxChars();
  * @return true if any characters have been replaced in \a aName.
  */
 bool ReplaceIllegalFileNameChars( std::string* aName, int aReplaceChar = 0 );
+bool ReplaceIllegalFileNameChars( wxString& aName, int aReplaceChar = 0 );
 
 #ifndef HAVE_STRTOKR
 // common/strtok_r.c optionally:
-- 
2.13.3

From f7a0ee82a6ea32d0c68c97c26079feed2ada61d3 Mon Sep 17 00:00:00 2001
From: Maciej Suminski 
Date: Tue, 6 Mar 2018 11:09:11 +0100
Subject: [PATCH 2/4] Replace illegal characters in LIB_{ALIAS,PART} LIB_IDs

Schematic components have illegal characters replaced during load,
leading to broken component-symbol links. To avoid this, library symbols
should have their names fixed in the same way.
---
 eeschema/class_libentry.cpp | 23 ---
 eeschema/class_libentry.h   |  2 +-
 eeschema/lib_field.cpp  | 16 ++--
 3 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/eeschema/class_libentry.cpp b/eeschema/class_libentry.cpp
index 4f7f8807b..09bab9467 100644
--- a/eeschema/class_libentry.cpp
+++ b/eeschema/class_libentry.cpp
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -67,7 +68,7 @@ LIB_ALIAS::LIB_ALIAS( const wxString& aName, LIB_PART* aRootPart ):
 EDA_ITEM( LIB_ALIAS_T ),
 shared( aRootPart )
 {
-name = aName;
+SetName( aName );
 }
 
 
@@ -118,6 +119,13 @@ PART_LIB* LIB_ALIAS::GetLib()
 }
 
 
+void LIB_ALIAS::SetName( const wxString& aName )
+{
+name = aName;
+ReplaceIllegalFileNameChars( name, '_' );
+}
+
+
 bool LIB_ALIAS::operator==( const wxChar* aName ) const
 {
 return name == aName;
@@ -275,21 

Re: [Kicad-developers] Mac HighDPI performance

[Maciej Sumiński]

Wayne,

According to our plan, eeschema GALification is one of the major points
of v6 roadmap. We plan to start it early, but I think it is better to
begin with the schematic model refactor, as GAL and Tool Framework
heavily rely on that. Doing things in reverse order means we will have
more code to fix once the model changes.

Cheers,
Orson

On 03/04/2018 08:46 PM, Wayne Stambaugh wrote:
> I agree.  If it's not an easy straight forward fix, I would prefer to
> spend our precious manpower resources on the GAL port as well.  I don't
> know when in the v6 cycle any of this will happen but I'm guessing it
> will happen fairly early.  Tom or Orson, do either of you have any idea
> when this will happen?
> 
> Wayne
> 
> On 03/04/2018 02:40 PM, Jon Evans wrote:
>> FWIW, I don't find the existing performance to be unusable, it's just
>> not up to the standards of PcbNew/GAL.  I don't think it's worth any
>> effort beyond easy fixes, we should put that energy into the GAL port. 
>>
>> -Jon
>>
>> On Sun, Mar 4, 2018, 14:34 Bernhard Stegmaier > > wrote:
>>
>> I would judge it wrt eeschema GAL conversion.
>> If that starts with v6, I don’t know if it is worth the effort.
>> If it is unsure when this will happen, it might be worth it.
>>
>>
>>> On 4. Mar 2018, at 20:30, Wayne Stambaugh >> > wrote:
>>>
>>> Ughh!  I don't have a good answer for this one.  My best guess is
>>> to fix
>>> the wx macos code first and see what performance issues are left.  The
>>> problem with messing with any of this is that if you break
>>> something it
>>> will break all of the legacy canvas rendering not just the schematic
>>> editor.  I would move extremely carefully here.  I would prefer
>>> that we
>>> don't go too crazy this late in the v5 release cycle.  If the
>>> performance is truly not usable on macos, then we may have no choice.
>>>
>>> On 03/04/2018 02:07 PM, Jeff Young wrote:
 It turns out the fonts aren’t really the problem.

 It starts with this gem in wxWidgets:

    voidwxWidgetCocoaImpl::ScrollRect(constwxRect*rect,intdx,intdy)

    {

    #if1

    SetNeedsDisplay();

    #else

    //Weshoulddosomethinglikethis,butitwasn'tworkingin10.4.

    if(GetNeedsDisplay())

    {

    SetNeedsDisplay() ;

    }

    NSRectr=wxToNSRect([m_osxViewsuperview],*rect);

    NSSizeoffset=NSMakeSize((float)dx,(float)dy);

    [m_osxViewscrollRect:rby:offset];

    #endif

    }


 SetNeedsDisplay() with no rectangle argument invalidates the
 entire window.

 Even if you fix that (to scroll most of the window and only
 invalidate
 the newly-exposed parts), you run into this:

    
 voidwxWidgetCocoaImpl::drawRect(void*rect,WXWidgetslf,void*WXUNUSED(_cmd))

    {

    //preparingtheupdateregion

    wxRegionupdateRgn;


    
 //sinceaddingmanyrectstoaregionisacostlyprocess,bydefaultusetheboundingrect

    #if0

    constNSRect*rects;

    NSIntegercount;

    [slfgetRectsBeingDrawn::];

    for(inti=0;iCLOCKS_PER_SEC/30)

    {

    s_lastFlush=clock();

    m_nowpeer->Update();

    }

    }


 But even Kicad isn’t blameless.  Once you fix all those there’s
 still no
 checking in SCH_SCREEN::Draw() to see if the individual draw items
 intersect the update region.  (Sure, the actually drawing is
 clipped in
 the end, but you still go through a /lot/ of code to get there.)

 All of these are fixable, and we’ve already crossed the Rubicon of
 having our own OSX wxWidgets branch.  

 But it’s still a reasonable amount of work, with a non-trivial risk
 profile.  Should I continue?

 Cheers,
 Jeff.



> On 4 Mar 2018, at 01:30, Bernhard Stegmaier
> 

Re: [Kicad-developers] Deletion in plugins causing trouble

[Maciej Sumiński]

Hi Miles,

I suppose the silence in the thread indicates there are not many
developers knowing the Python scripting interface inside out. Since you
are both studying the scripting interface and developing own scripts, it
is quite possible you are the most competent person to give us an advice
on how to proceed. See some comments below, but I am neither a Python
script developer nor a scripting interface maintainer, so I might be
lacking some basic knowledge here.

On 02/28/2018 05:12 PM, miles mccoo wrote:
> So I'm plugin-ifying my python scripts (the mechanism is awesome). One of
> the plugins deletes some stuff and that is causing trouble.
> 
> 
> 
> I'm not sure how to fix the root cause. Hence this mail.
> 
> 
> 
> The plugin just deletes Edge.Cuts[1]:
> for d in board.GetDrawings():
> if (d.GetLayerName() == 'Edge.Cuts'):
> board.Remove(d)
> 
> 
> 
> in board_item_container.i, I see this (with stuff deleted):
> %rename(RemoveNative)BOARD_ITEM_CONTAINER::Remove;
> def Remove(self,item):
> self.RemoveNative(item)
> item.thisown=1
> 
> 
> Setting thisown tells, python "you own it". Delete it when you're done.
> Which it does.
> 
> 
> The problem this causes is that the plugin mechanism saves a list of all
> objects before running the plugin and then checks if any of them has a null
> list after (ie is it still in the design).

Is this mechanism implemented to handle memory leaks? If so, would not
it be sufficient to stick to 'thisown' flag on Remove() calls or is
there another way objects might be destroyed using Python scripts?

> Since the object has been deleted by python, the plugin stuff gets confused.
> 
> 
> *So, the question is how to fix this?*
> 
> 
> It appears that the plugin infrastructure will delete for you (that's what
> I'm guessing), so the thisown setting shouldn't be done.
> 
> 
> On the other hand, if running code from within a standalone script (ie from
> regular python shell), now thisown'ing it would yield a memory leak.
> 
> 
> 
> Perhaps the plugin stuff should have some sort of flag indicating "you're
> in a plugin". Then the thisown setting could be conditional.

If the object listing mechanism is required for other reasons, then I
suppose it is second best idea. Generally speaking, I would like to make
the scripting interface convenient for the users, so they do not need to
worry about whether their scripts are run standalone or as a plugin.
Let's hide the dirty magic from them and make the coding process enjoyable.

Regards,
Orson

> But I'm just a spectator. *I'm happy to put in the time to fix this but
> need guidance on what approach to take.*
> 
> 
> Miles
> 
> 
> 
> [1] full plugin text
> import pcbnew
> 
> class RemoveBoundaryPlugin(pcbnew.ActionPlugin):
> def defaults(self):
> self.name = "Remove boundary"
> self.category = "A descriptive category name"
> self.description = "This plugin reads a dxf file and converts it to
> a zone"
> 
> def Run(self):
> board = pcbnew.GetBoard()
> 
> for d in board.GetDrawings():
> print("{}".format(str(d)))
> #print("on layer {} {} {}".format(d.GetLayerName(),
> # str(d.GetStart()),
> # str(d.GetEnd(
> if (d.GetLayerName() == 'Edge.Cuts'):
> board.Remove(d)
> 
> RemoveBoundaryPlugin().register()
> 
> 
> 
> ___
> Mailing list: https://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] Restore some missing visibility items from board file

[Maciej Sumiński]

Thank you Andrzej, I have just merged your patch.

Cheers,
Orson

On 03/02/2018 01:52 AM, Andrzej Wolski wrote:
> I'm resending a patch from this thread:
> https://lists.launchpad.net/kicad-developers/msg34285.html
> 
> I believe it should go into rc2?
> 
> State of some recently added checkboxes to Render panel was not restored
> on file open. This patch fixes that.
> 
> Andrzej
> 
> 
> 
> ___
> Mailing list: https://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] New lead developers

[Maciej Sumiński]

Congratulations fellow developers! You have received well deserved
promotions, and I am glad to see your names in the
kicad-product-committers group. Keep on rocking!

Cheers,
Orson

On 03/01/2018 08:15 PM, Wayne Stambaugh wrote:
> I am pleased to announce the promotion of three developers to the KiCad
> lead development team.  Their efforts since joining the project have
> really helped move KiCad forward.  They have shown excellent technical
> skills and a willingness to cooperate with the development team.  Please
> congratulate Jon Evans, Seth Hillbrand, and Jeff Young for their
> promotion to the lead developers team.  Thank you gentlemen for all of
> you hard work.
> 
> Cheers,
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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] Avoid shadowed variable

[Maciej Sumiński]

Thank you Simon, I have just merged your patch.

Cheers,
Orson

On 02/28/2018 09:50 AM, Simon Richter wrote:
> ---
>  pcbnew/dialogs/dialog_plot.cpp | 1 -
>  1 file changed, 1 deletion(-)
> 
> 
> 
> ___
> Mailing list: https://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] Various GerbView fixes

[Maciej Sumiński]

For the record: merged.

On 02/28/2018 03:33 AM, Jon Evans wrote:
> Hi all,
> 
> Attached are three patches to fix a few issues noted by JP and Clemens.
> These need to be applied after my patches from yesterday which are not yet
> merged.
> 
> Best,
> Jon
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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] GerbView performance: in-place layer reordering for X2 sorting

[Maciej Sumiński]

For the record: merged.

On 02/27/2018 03:15 AM, Jon Evans wrote:
> Hi all,
> 
> A few more GerbView patches for tonight.
> 
> The larger one should get some testing if possible before merging -- last
> time I tried something like this, JP said it killed performance on Windows.
> On my Linux machine, this fixes some issues with X2 sorting behavior, and
> is quite fast.
> 
> The smaller one is just a fix to redraw negative items when their
> visibility is toggled.
> 
> -Jon
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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