Re: [Kicad-developers] [PATCH] Re: SHAPE_LINE_CHAIN in swig?
Hi Andrew, Many of the folks on this list may be taking a break after this past weekend's release. Please do not take a few day's silence right now as any sort of sign. :) Adam On Tue, Jul 24, 2018, 10:29 PM Andrew Lutsenko wrote: > Hello, > > Can someone take a look at my patch please? > It's my first so if I didn't submit it correctly please bear with me, I > believe I did everything according to developers documentation. > > It would be great to see this in next release. Patch applies cleanly to > both 5.0 branch and master. > > Regards, > Andrew > > On Sun, Jul 22, 2018 at 6:05 PM Andrew Lutsenko > wrote: > >> I figured it out, please see attached patch for the fix. >> >> On Sun, Jul 22, 2018 at 3:46 AM Andrew Lutsenko >> wrote: >> >>> I tried adding this in kicad.i >>> >>> #include >>> %include >>> >>> It compiles and SHAPE_LINE_CHAIN type shows up in pcbnew.py >>> >>> But I need VECTOR2I as well to get the actual coordinates. However >>> adding math/vector2d.h header in a similar way leads to following >>> linking >>> error that I am not sure how to fix: >>> >>> D:/devtools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: >>> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$.refptr._ZN7VECTOR2IiE10ECOORD_MINE[.refptr._ZN7VECTOR2IiE10ECOORD_MINE]+0x0): >>> undefined reference to `VECTOR2::ECOORD_MIN' >>> D:/devtools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: >>> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$.refptr._ZN7VECTOR2IiE10ECOORD_MAXE[.refptr._ZN7VECTOR2IiE10ECOORD_MAXE]+0x0): >>> undefined reference to `VECTOR2::ECOORD_MAX' >>> >>> Can someone who understands swig help me figure this out? >>> >>> On Sat, Jul 21, 2018 at 12:36 PM Andrew Lutsenko >>> wrote: >>> Hello Kicad team, I'm writing a pcbnew action plugin that needs to read footprint pad coordinates and shape. I had no trouble figuring out all shapes except for custom one. It is represented by SHAPE_POLY_SET which has a corresponding python type but to get actual vertex coordinates you have to either call one of Iterate() variants or get polygon outlines with Outline(). They both return objects (ITERATOR and SHAPE_LINE_CHAIN) that are pointers and have no useful attributes. As far as I understand they just don't have corresponding swig bindings so they are not exposed properly in python. Am I missing some obvious way to read custom pad polygon data in python? If not, what would it take to add that? I don't understand much about how swig configuration works but cursory glance at Kicad source suggests that there needs to be an import for shape_line_chain.h in common/swig/kicad.i, similar to shape_poly_set import. If you are curious about what the plugin does, here are some of it's results, generated from Kicad demos: http://plugindemo.bitballoon.com/1/ http://plugindemo.bitballoon.com/2/ http://plugindemo.bitballoon.com/3/ #2 above has a solder bridge with custom shape pads that are not rendered. Links are short lived. Regards, Andrew >>> ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Re: SHAPE_LINE_CHAIN in swig?
Hello, Can someone take a look at my patch please? It's my first so if I didn't submit it correctly please bear with me, I believe I did everything according to developers documentation. It would be great to see this in next release. Patch applies cleanly to both 5.0 branch and master. Regards, Andrew On Sun, Jul 22, 2018 at 6:05 PM Andrew Lutsenko wrote: > I figured it out, please see attached patch for the fix. > > On Sun, Jul 22, 2018 at 3:46 AM Andrew Lutsenko > wrote: > >> I tried adding this in kicad.i >> >> #include >> %include >> >> It compiles and SHAPE_LINE_CHAIN type shows up in pcbnew.py >> >> But I need VECTOR2I as well to get the actual coordinates. However >> adding math/vector2d.h header in a similar way leads to following linking >> error that I am not sure how to fix: >> >> D:/devtools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: >> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$.refptr._ZN7VECTOR2IiE10ECOORD_MINE[.refptr._ZN7VECTOR2IiE10ECOORD_MINE]+0x0): >> undefined reference to `VECTOR2::ECOORD_MIN' >> D:/devtools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: >> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$.refptr._ZN7VECTOR2IiE10ECOORD_MAXE[.refptr._ZN7VECTOR2IiE10ECOORD_MAXE]+0x0): >> undefined reference to `VECTOR2::ECOORD_MAX' >> >> Can someone who understands swig help me figure this out? >> >> On Sat, Jul 21, 2018 at 12:36 PM Andrew Lutsenko >> wrote: >> >>> Hello Kicad team, >>> >>> I'm writing a pcbnew action plugin that needs to read footprint pad >>> coordinates and shape. >>> I had no trouble figuring out all shapes except for custom one. It is >>> represented by SHAPE_POLY_SET which has a corresponding python type but >>> to >>> get actual vertex coordinates you have to either call one of Iterate() >>> variants or get polygon outlines with Outline(). They both return objects >>> (ITERATOR and SHAPE_LINE_CHAIN) that are pointers and have no useful >>> attributes. As far as I understand they just don't have corresponding >>> swig >>> bindings so they are not exposed properly in python. >>> >>> Am I missing some obvious way to read custom pad polygon data in python? >>> >>> If not, what would it take to add that? >>> >>> I don't understand much about how swig configuration works but cursory >>> glance at Kicad source suggests that there needs to be an import for >>> shape_line_chain.h in common/swig/kicad.i, similar to shape_poly_set >>> import. >>> >>> If you are curious about what the plugin does, here are some of it's >>> results, generated from Kicad demos: >>> http://plugindemo.bitballoon.com/1/ >>> http://plugindemo.bitballoon.com/2/ >>> http://plugindemo.bitballoon.com/3/ >>> >>> #2 above has a solder bridge with custom shape pads that are not >>> rendered. >>> Links are short lived. >>> >>> Regards, >>> Andrew >>> >> ___ Mailing list: https://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
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? -- Regards Carsten Schoenert ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] The version string in the master branch
ti 24. heinäk. 2018 klo 22.59 Wayne Stambaugh (stambau...@gmail.com) kirjoitti: > 5.1-dev will confuse the package version > sorting when 5.1.0 is released. Why do development packages (nightly builds or self-compiled) need to be sorted with release builds? The most misleading strings are in the window bar and in the About KiCad dialog, and those texts aren't sorted anyways. Can't they be different than package file names? Windows nightly build package names don't have the version, nor do the ubuntu nightly packages. > I'm fine with Simon's proposal but > users will be no less confused by 5.0.0-452-g23849572 than by > 6.0.0-rc1-xxx-commithash. Based on my experience with linux distros and applications for about 20 years and as a former open source developer I would like to disagree. But I know it doesn't count... I just want this sorted out because people will be confused for the next couple of years, and we who answer questions in the user forum have to clarify the situation every time. Eeli Kaikkonen ___ Mailing list: https://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] The version string in the master branch
On 7/24/2018 11:11 AM, Simon Richter wrote: > Hi, > > On 24.07.2018 09:40, Eeli Kaikkonen wrote: > >> The version string which is the visible version information seems to be >> 6.0 something. It has already caused confusion for those who use >> nightlies. I hope this will be fixed permanently. Is there any hope to >> get it changed to something unambiguous, like "post5.0-gitXX"? > > I wonder what is wrong with standard git-describe with no special tag? A > version like "5.0.0-452-g23849572" is recognizable as being 452 commits > newer than 5.0.0, which gives me an immediate impression how different I > can expect it to be, and still sorts before 5.1 or 6.0. > >Simon > This is why I used 6.0.0-rc1. 5.1-dev will confuse the package version sorting when 5.1.0 is released. I'm fine with Simon's proposal but users will be no less confused by 5.0.0-452-g23849572 than by 6.0.0-rc1-xxx-commithash. If someone has a better idea that doesn't break package version sorting schemes, doesn't confuse users, and conveys the current development version, I'm open to suggestion. 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
Re: [Kicad-developers] Board setup icon
Hi John, When you get a chance could you also edit the part_properties_xpm icon to be the op-amp with a gear over it? Oh, and a new icon with the op-amp with a little ’T’ in the bottom right corner would be great. (Both are for the symbol editor. They’re currently just a generic gear and a generic ’T’.) Thanks, Jeff. > On 24 Jul 2018, at 16:56, Jeff Young wrote: > > I’ve merged your icon, John. Thanks for your contribution! > >> On 24 Jul 2018, at 12:35, John Beard wrote: >> >> Hi, >> >> Here is a new icon for the board setup toolbar and menu item. The >> generic gear icon is no clear, as it looks like "Preferences" rather >> than board setup. >> >> PNG included for reference only. >> >> Cheers, >> >> John >> <0001-Pcbnew-add-new-icon-for-board-setup.patch>___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Aim macOS users at kicad-mac-builder and make building on macOS seem less scary
"make it easier for macOS developers to work on KiCad" is something I am 100% open to feedback on, so please let me know how it goes. I've done some playing around with it and CLion and it seems to work fine, but that was a 15 minute test. On Tue, Jul 24, 2018 at 12:24 PM Andy Peters wrote: > > On Jul 23, 2018, at 6:18 AM, Adam Wolf wrote: > > > > Hi folks! > > > > Attached is a docs patch. Please let me know if it needs any tweaks > > or if you have any questions. > > <0001-Aim-macOS-users-at-kicad-mac-builder-and-make-buildi.patch> > > I will try the kicad-mac-builder tonight. > > -a > > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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] Aim macOS users at kicad-mac-builder and make building on macOS seem less scary
On Jul 23, 2018, at 6:18 AM, Adam Wolf wrote: > > Hi folks! > > Attached is a docs patch. Please let me know if it needs any tweaks > or if you have any questions. > <0001-Aim-macOS-users-at-kicad-mac-builder-and-make-buildi.patch> I will try the kicad-mac-builder tonight. -a ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Hotkeys in GAL
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.) 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? 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
[Kicad-developers] [PATCH] Add Insert hotkey to add a zone/segment corner
This patch adds a hotkey for adding a corner to a zone or segment.
This is an action I have really struggled without a hotkey for! I have
used Insert, as:
1) it's available and
2) it's what Inkscape uses (but Inkscape adds the point at the
midpoint of the segment, this adds at the cursor).
It doesn't work on polygons, as that is still unimplemented in the
underlying action.
Cheers,
John
From 9a4da96b7df9941e6dcbb61201adfeaed70bea95 Mon Sep 17 00:00:00 2001
From: John Beard
Date: Tue, 24 Jul 2018 16:15:05 +0100
Subject: [PATCH 1/2] Add hotkey (Insert) for zone create corner
Adds a hotkey to the TOOL_ACTION, and also checks for
action validity prior to running the actions (previously
implicitly gated by the enablement of the menu item).
---
pcbnew/hotkeys.cpp| 6 ++
pcbnew/hotkeys.h | 3 ++-
pcbnew/tools/point_editor.cpp | 23 +--
pcbnew/tools/point_editor.h | 3 +++
4 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/pcbnew/hotkeys.cpp b/pcbnew/hotkeys.cpp
index 25a93e694..32fcc3192 100644
--- a/pcbnew/hotkeys.cpp
+++ b/pcbnew/hotkeys.cpp
@@ -310,6 +310,9 @@ static EDA_HOTKEY HkToggleCursor( _HKI( "Toggle Cursor Display (Modern Toolset o
static EDA_HOTKEY HkMeasureTool( _HKI( "Measure Distance (Modern Toolset only)" ),
HK_MEASURE_TOOL, 'M' + GR_KB_SHIFTCTRL );
+static EDA_HOTKEY HkInsertCorner( _HKI( "Insert Corner (Modern Toolset only)" ),
+ HK_INSERT_CORNER, WXK_INSERT );
+
// List of common hotkey descriptors
EDA_HOTKEY* common_Hotkey_List[] =
{
@@ -384,6 +387,9 @@ EDA_HOTKEY* board_edit_Hotkey_List[] =
,
,
+// Point editor (zones and segments)
+,
+
// Highlight and display
,
,
diff --git a/pcbnew/hotkeys.h b/pcbnew/hotkeys.h
index f4e6fa446..b22817675 100644
--- a/pcbnew/hotkeys.h
+++ b/pcbnew/hotkeys.h
@@ -133,7 +133,8 @@ enum hotkey_id_commnand {
HK_DP_DIMENSIONS,
HK_VIA_SIZE_INC,
HK_VIA_SIZE_DEC,
-HK_HIGHLIGHT_NET_SELECTION
+HK_HIGHLIGHT_NET_SELECTION,
+HK_INSERT_CORNER
};
// Full list of hotkey descriptors for board editor and footprint editor
diff --git a/pcbnew/tools/point_editor.cpp b/pcbnew/tools/point_editor.cpp
index 9d994479e..a63bdb944 100644
--- a/pcbnew/tools/point_editor.cpp
+++ b/pcbnew/tools/point_editor.cpp
@@ -50,7 +50,7 @@ using namespace std::placeholders;
// Point editor
TOOL_ACTION PCB_ACTIONS::pointEditorAddCorner( "pcbnew.PointEditor.addCorner",
-AS_GLOBAL, 0,
+AS_GLOBAL, WXK_INSERT,
_( "Create Corner" ), _( "Create a corner" ), add_corner_xpm );
TOOL_ACTION PCB_ACTIONS::pointEditorRemoveCorner( "pcbnew.PointEditor.removeCorner",
@@ -850,17 +850,25 @@ void POINT_EDITOR::setTransitions()
}
+bool POINT_EDITOR::canAddCorner( const EDA_ITEM& aItem )
+{
+const auto type = aItem.Type();
+
+// Works only for zones and line segments
+return type == PCB_ZONE_AREA_T ||
+ ( ( type == PCB_LINE_T || type == PCB_MODULE_EDGE_T ) &&
+ static_cast( aItem ).GetShape() == S_SEGMENT );
+}
+
+
bool POINT_EDITOR::addCornerCondition( const SELECTION& aSelection )
{
if( aSelection.Size() != 1 )
return false;
-auto item = aSelection.Front();
+const EDA_ITEM* item = aSelection.Front();
-// Works only for zones and line segments
-return item->Type() == PCB_ZONE_AREA_T ||
- ( ( item->Type() == PCB_LINE_T || item->Type() == PCB_MODULE_EDGE_T ) &&
- static_cast( item )->GetShape() == S_SEGMENT );
+return ( item != nullptr ) && canAddCorner( *item );
}
@@ -921,6 +929,9 @@ int POINT_EDITOR::addCorner( const TOOL_EVENT& aEvent )
const VECTOR2I& cursorPos = getViewControls()->GetCursorPosition();
BOARD_COMMIT commit( frame );
+if( !canAddCorner( *item ) )
+return 0;
+
if( item->Type() == PCB_ZONE_AREA_T )
{
ZONE_CONTAINER* zone = static_cast( item );
diff --git a/pcbnew/tools/point_editor.h b/pcbnew/tools/point_editor.h
index 230a6f5c7..6ebcb1787 100644
--- a/pcbnew/tools/point_editor.h
+++ b/pcbnew/tools/point_editor.h
@@ -129,6 +129,9 @@ private:
///> Condition to display "Create corner" context menu entry.
static bool addCornerCondition( const SELECTION& aSelection );
+///> Determine if the tool can currently add a corner to the given item
+static bool canAddCorner( const EDA_ITEM& aItem );
+
///> Condition to display "Remove corner" context menu entry.
bool removeCornerCondition( const SELECTION& aSelection );
--
2.17.1
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Board setup icon
I’ve merged your icon, John. Thanks for your contribution! > On 24 Jul 2018, at 12:35, John Beard wrote: > > Hi, > > Here is a new icon for the board setup toolbar and menu item. The > generic gear icon is no clear, as it looks like "Preferences" rather > than board setup. > > PNG included for reference only. > > Cheers, > > John > <0001-Pcbnew-add-new-icon-for-board-setup.patch>___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] The version string in the master branch
Hi, On 24.07.2018 09:40, Eeli Kaikkonen wrote: > The version string which is the visible version information seems to be > 6.0 something. It has already caused confusion for those who use > nightlies. I hope this will be fixed permanently. Is there any hope to > get it changed to something unambiguous, like "post5.0-gitXX"? I wonder what is wrong with standard git-describe with no special tag? A version like "5.0.0-452-g23849572" is recognizable as being 452 commits newer than 5.0.0, which gives me an immediate impression how different I can expect it to be, and still sorts before 5.1 or 6.0. Simon 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] The version string in the master branch
If we are fine with 5.1-dev (it is my preference as well), then I'll set the tag to 5.1-dev and update KiCadVersion.cmake before the end of the day. The reason I used 6.0.0-rc1 is that there were complaints that the #.#-dev format was confusing. Let's agree on a tagging scheme and stick with it to avoid this in the future. There is nothing I'm willing to do to fix source builds (no git) because that would require blowing away a who lot of changes since the v5 commit tag, setting KiCadVersion.cmake to "5.1-dev", and remerging all of the changes. If someone else wants to take on that responsibility, by all means. Cheers, Wayne On 7/24/2018 8:12 AM, Maciej Sumiński wrote: > I think 5.1-dev is simple and informative enough. > > Cheers, > Orson > > On 07/24/2018 02:09 PM, Adam Wolf wrote: >> Hmm. When would it be the right time to change from post5 to pre6? >> >> Adam >> >> On Tue, Jul 24, 2018, 2:41 AM Eeli Kaikkonen >> wrote: >> >>> The version string which is the visible version information seems to be >>> 6.0 something. It has already caused confusion for those who use nightlies. >>> I hope this will be fixed permanently. Is there any hope to get it changed >>> to something unambiguous, like "post5.0-gitXX"? >>> >>> Eeli Kaikkonen >>> ___ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> >> >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] qa_geometry tests
John, I didn't forget about your qa test patches. They are on my todo list. I've just been busy with life. I will have some free time over the weekend to test them and get them merged. Cheers, Wayne On 7/24/2018 6:31 AM, John Beard wrote: > I think the first three of these patches are still worth committing > now. That will allow "make test" to be used to collect all our > (working) tests and give us somewhere to hang new tests so that they > can used. > > We can discuss whether or not we want "make test" to also rebuild the > tests separately, as well as thoughts on the fillet tests. > > Cheers, > > John > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] The version string in the master branch
Hmm. When would it be the right time to change from post5 to pre6? Adam On Tue, Jul 24, 2018, 2:41 AM Eeli Kaikkonen wrote: > The version string which is the visible version information seems to be > 6.0 something. It has already caused confusion for those who use nightlies. > I hope this will be fixed permanently. Is there any hope to get it changed > to something unambiguous, like "post5.0-gitXX"? > > Eeli Kaikkonen > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Aim macOS users at kicad-mac-builder and make building on macOS seem less scary
Thanks Wayne! Please apply to both whenever it's convenient. It's a new world for macOS building and packaging for KiCad! Adam On Tue, Jul 24, 2018, 12:04 AM Wayne Stambaugh wrote: > Adam, > > I merged your patch into the development branch. I'm assuming these > changes apply to the 5.0 branch as well but I want to confirm before > merging into the 5.0 branch. > > Thanks, > > Wayne > > On 7/23/2018 9:18 AM, Adam Wolf wrote: > > Hi folks! > > > > Attached is a docs patch. Please let me know if it needs any tweaks > > or if you have any questions. > > > > > > > > ___ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : kicad-developers@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad V4 update chances?
Thanks Wayne! I'll format that machine today, and work on adding it to speed up V5 builds. The chances of getting another working V4 macOS build will be just about zero now anyway :) Adam On Tue, Jul 24, 2018, 12:18 AM Wayne Stambaugh wrote: > As long as I am the project leader the chances are zero. I cannot speak > on behalf of my successor. ;) Unless someone volunteers to maintain the > 4 branch, I think it's pretty safe to assume there will not be another 4 > branch. I have no intention of spending valuable developer resources > maintaining the 4 branch. That's why there has been no 4.0.8 release > even though there are bugs in it that need fixed. The dev branch code > base has deviated so far from the 4.0 branch that even the most trivial > bug fixes are painful. > > Wayne > > On 7/23/2018 1:34 PM, Adam Wolf wrote: > > Hi folks! > > The macOS build process for V4 was somewhat made of shoe strings and > > bubble gum and crossed fingers, and I am not confident that my > > hand-tweaked dependencies were reproducible, so the V4 build machine > > does literally nothing else but wait for me to tell it to make another > > release. > > > > At what point is it guaranteed that we will not need to make another > > V4 release? Now? I'd love to reuse that machine to do parallel V5 > > builds, but I don't want to touch it until we *know* we won't make any > > V4 releases. > > > > Adam > > > > ___ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : kicad-developers@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Board setup icon
Hi,
Here is a new icon for the board setup toolbar and menu item. The
generic gear icon is no clear, as it looks like "Preferences" rather
than board setup.
PNG included for reference only.
Cheers,
John
From 329eda7c68c0ca56f1d8095342000fdc72868955 Mon Sep 17 00:00:00 2001
From: John Beard
Date: Tue, 24 Jul 2018 11:57:07 +0100
Subject: [PATCH] Pcbnew: add new icon for board setup
Previously, the generic "options" gear was used, which was
confusing.
This commit add a new icon, options_board, specifically for
board-wide options.
---
bitmaps_png/CMakeLists.txt| 1 +
bitmaps_png/cpp_26/options_board.cpp | 93 +++
bitmaps_png/sources/options_board.svg | 226 ++
include/bitmaps.h | 1 +
pcbnew/menubar_pcb_editor.cpp | 2 +-
pcbnew/tool_pcb_editor.cpp| 2 +-
6 files changed, 323 insertions(+), 2 deletions(-)
create mode 100644 bitmaps_png/cpp_26/options_board.cpp
create mode 100644 bitmaps_png/sources/options_board.svg
diff --git a/bitmaps_png/CMakeLists.txt b/bitmaps_png/CMakeLists.txt
index 320df94c5..09c7b6b88 100644
--- a/bitmaps_png/CMakeLists.txt
+++ b/bitmaps_png/CMakeLists.txt
@@ -420,6 +420,7 @@ set( BMAPS_MID
options_all_tracks
options_all_vias
options_arc
+options_board
options_circle
options_generic
options_module
diff --git a/bitmaps_png/cpp_26/options_board.cpp b/bitmaps_png/cpp_26/options_board.cpp
new file mode 100644
index 0..7e02513fa
--- /dev/null
+++ b/bitmaps_png/cpp_26/options_board.cpp
@@ -0,0 +1,93 @@
+
+/* Do not modify this file, it was automatically generated by the
+ * PNG2cpp CMake script, using a *.png file as input.
+ */
+
+#include
+
+static const unsigned char png[] = {
+ 0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d, 0x49, 0x48, 0x44, 0x52,
+ 0x00, 0x00, 0x00, 0x1a, 0x00, 0x00, 0x00, 0x1a, 0x08, 0x06, 0x00, 0x00, 0x00, 0xa9, 0x4a, 0x4c,
+ 0xce, 0x00, 0x00, 0x04, 0xbf, 0x49, 0x44, 0x41, 0x54, 0x48, 0xc7, 0xed, 0x56, 0x7b, 0x4c, 0xdb,
+ 0x55, 0x14, 0x66, 0x6a, 0x5c, 0xd4, 0x39, 0xe7, 0xb2, 0x04, 0x8d, 0xdb, 0x12, 0x43, 0x42, 0x16,
+ 0x13, 0x27, 0x7f, 0xd8, 0x31, 0x67, 0x44, 0x09, 0x96, 0x57, 0x61, 0xf2, 0x0c, 0xaf, 0x66, 0x29,
+ 0xc4, 0x81, 0xc2, 0xb6, 0x32, 0xcb, 0x43, 0x87, 0x7b, 0xf1, 0x1a, 0x20, 0xb0, 0x31, 0x60, 0x2d,
+ 0xac, 0x40, 0x69, 0x69, 0xb3, 0x09, 0x61, 0x29, 0x2f, 0xd9, 0x60, 0x2b, 0x0d, 0x14, 0xac, 0x64,
+ 0x9a, 0x98, 0x4d, 0xf4, 0x0f, 0xd4, 0x84, 0x01, 0x15, 0xe8, 0x5c, 0xcb, 0x0a, 0xcb, 0x18, 0x7c,
+ 0xfe, 0xce, 0x95, 0x16, 0x2a, 0x4c, 0xc1, 0xc4, 0xff, 0x6c, 0x72, 0xfa, 0xeb, 0xf9, 0x7a, 0xef,
+ 0xfd, 0xee, 0x39, 0xe7, 0x3b, 0xbf, 0x7b, 0x5d, 0x44, 0x45, 0xef, 0x88, 0x82, 0x72, 0x3c, 0xda,
+ 0xbb, 0xae, 0xa4, 0x9d, 0xfa, 0xf9, 0x46, 0x61, 0x7a, 0x6a, 0x19, 0x5f, 0x41, 0x7e, 0x9e, 0x3c,
+ 0xac, 0x92, 0xfc, 0x5a, 0x55, 0xfc, 0x17, 0xe4, 0x0b, 0x0b, 0xf7, 0x35, 0x92, 0x4f, 0x46, 0xfe,
+ 0x6a, 0x73, 0x1e, 0x67, 0xc4, 0xe1, 0xb2, 0x3f, 0xd7, 0xa3, 0xcd, 0xe5, 0x43, 0x17, 0x5c, 0x6d,
+ 0x96, 0xe0, 0x97, 0xeb, 0x45, 0x10, 0x64, 0xbf, 0x01, 0xf2, 0xc5, 0xe7, 0xf8, 0xcc, 0xaf, 0xac,
+ 0x13, 0x32, 0xdf, 0x5d, 0xe2, 0xca, 0x7c, 0x32, 0xf2, 0xc9, 0xae, 0x2d, 0xce, 0x09, 0xcc, 0xde,
+ 0xed, 0xc0, 0x56, 0x33, 0xc6, 0xf1, 0x3f, 0xd1, 0x6a, 0x44, 0x41, 0x8b, 0x73, 0xfe, 0x73, 0x22,
+ 0x9d, 0x36, 0x03, 0xae, 0x87, 0x37, 0x33, 0x8c, 0x9e, 0x39, 0xb2, 0x50, 0xe4, 0x57, 0x85, 0x3b,
+ 0xac, 0x52, 0x21, 0x2c, 0xfd, 0x57, 0x44, 0x4f, 0x27, 0x3e, 0xc5, 0xb0, 0xa8, 0x33, 0x7b, 0x30,
+ 0x7c, 0xbd, 0xd0, 0x41, 0xf6, 0x51, 0xc9, 0x7b, 0xec, 0x69, 0x1f, 0x67, 0x37, 0x52, 0xe6, 0x9a,
+ 0x89, 0x76, 0xa6, 0x6e, 0x75, 0x2c, 0x7a, 0xfc, 0x42, 0xb0, 0x23, 0xaa, 0xe5, 0x64, 0xcb, 0xed,
+ 0xca, 0x97, 0x87, 0x70, 0xb6, 0x26, 0x1a, 0x37, 0xdb, 0x4f, 0xae, 0x8d, 0x48, 0xdb, 0x78, 0x18,
+ 0x1b, 0x0e, 0x6e, 0x60, 0xd8, 0x81, 0xc2, 0x7d, 0x8e, 0x85, 0xf2, 0xb9, 0x0d, 0x98, 0x2c, 0x26,
+ 0x3c, 0x7c, 0xf4, 0x10, 0x16, 0xdb, 0xef, 0x50, 0x35, 0x1e, 0x65, 0x9b, 0x22, 0x8b, 0x3a, 0xe3,
+ 0x89, 0xad, 0x47, 0xb6, 0xc0, 0xab, 0xe0, 0x6d, 0xb8, 0x1e, 0x79, 0x11, 0x9d, 0xcd, 0x47, 0x4f,
+ 0xaf, 0x20, 0xb2, 0x17, 0xf6, 0xad, 0x2c, 0x37, 0x0c, 0x5d, 0xcb, 0x63, 0xd8, 0x29, 0xe9, 0x07,
+ 0x0c, 0x73, 0xfb, 0xcc, 0x0d, 0x9f, 0x72, 0x39, 0x27, 0xcc, 0x32, 0xf2, 0x2d, 0x54, 0x2a, 0x15,
+ 0xf8, 0x7c, 0x3e, 0x64, 0x32, 0x19, 0x94, 0xfd, 0x4a, 0x36, 0x66, 0x5b, 0xea, 0x36, 0x78, 0x9c,
+ 0xf6, 0x40, 0xfb, 0xf7, 0xed, 0xa0, 0x8f, 0x7f, 0xc9, 0xfb, 0x10, 0x16, 0xed, 0x6d, 0x5a, 0x41,
+ 0x24, 0xab, 0x3f, 0x80, 0x27, 0x0f, 0x3e, 0xc1, 0x26, 0xed, 0x3d, 0xe6, 0x86, 0x5b, 0x9d, 0x39,
+ 0x0c, 0xef, 0x34, 0xaa, 0x61, 0x36, 0x9b, 0x61, 0xb3, 0xd9, 0x60, 0xbc, 0xf5, 0x15, 0xe6, 0x66,
+ 0x2d, 0x48, 0x48, 0x48, 0x40, 0x6f, 0x6f, 0x2f, 0x84, 0x42, 0x21, 0x26, 0xb8, 0xe8, 0x34, 0x86,
+ 0x3a, 0xcc, 0xcc, 0xce, 0x60, 0x72, 0x72, 0x12, 0x5d, 0xb7, 0xbb, 0xa0, 0xfb, 0x51, 0x87, 0x57,
+ 0x24, 0x2f, 0x51, 0xaa, 0xab, 0x56, 0x10, 0x91, 0x5d, 0x54, 0x8a, 0xb0, 0x31, 0xe9, 0xcf,
Re: [Kicad-developers] [PATCH] qa_geometry tests
I think the first three of these patches are still worth committing now. That will allow "make test" to be used to collect all our (working) tests and give us somewhere to hang new tests so that they can used. We can discuss whether or not we want "make test" to also rebuild the tests separately, as well as thoughts on the fillet tests. Cheers, John ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Adding "Apply" to the 3D viewer display options dialog
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
...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
+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 > > 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-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.
Re: [Kicad-developers] Adding "Apply" to the 3D viewer display options dialog
Hi David, The wxWidgets framework will process OK and Cancel for us (assuming we don’t need anything special). They call TransferDataFromWindow to do the dirty work in the case of an OK. Other Kicad dialogs do have to do something more special, though, and so implement their own processing. You’d also need to implement your own for an Apply button. Cheers, Jeff. > On 24 Jul 2018, at 08:10, 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. > > > -- > David Griffith > d...@661.org > > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] The version string in the master branch
The version string which is the visible version information seems to be 6.0 something. It has already caused confusion for those who use nightlies. I hope this will be fixed permanently. Is there any hope to get it changed to something unambiguous, like "post5.0-gitXX"? Eeli Kaikkonen ___ Mailing list: https://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] Adding "Apply" to the 3D viewer display options dialog
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. -- David Griffith d...@661.org A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ Mailing list: https://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
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-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
