[Kicad-developers] [proposal] pcbnew/eeschema save/copy/duplicate consistency and customary definitions
Relatively simple proposals: 1. Rename 'copy' to 'duplicate' in eeschema to match pcbnew. 2. Rename 'save' to 'copy' in eeschema to match traditional usage. 3. Add default Ctrl-V keybinding to eeschema for 'paste' to match traditional usage. 4. Add 'cut' to eeschema, on Ctrl-X: - This differs from save/copy-delete in that it should keep reference designators, since you're just moving parts. - This differs from block-move in that it would work across sheets, which I think is a significant plus. Possible drawbacks: 1. Existing tutorials/unofficial docs will not match. Not such a big deal in this case as 'duplicate' is quite obvious. 2. Existing tutorials/unofficial docs will not match. Bit more important for save vs. copy. 3. Keybinding conflict with pcbnew's Add MicroVia, so pcbnew couldn't be amended to add this keybinding to *it* for consistency. There's always the possibility that Add MicroVia could be given a different binding, as I don't think it's a very often used function. 4. None that I can think of. Any thoughts on this? These are all things I can easily implement if desired. Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Option in eeschema to annotate keeping multi-unit parts grouped
Ah, thank you for having a look. Yes, I clearly missed this use case. D'oh... I'll submit a new patch in a couple days that handles this. Any interest in including it if I get it working properly? Chris On Sat, Mar 21, 2015 at 04:44:43PM +0100, jp charras wrote: Thank for your contribution. This is a very interesting feature. I tested it on different schematic projects. It works fine only for simple hierarchies. Unfortunately, it does not work on complex hierarchies. These hierarchies uses more than once a given sheet: there is one file, one schematic, and several instances. the sheet which is used more than once stores only one drawing, but n different references when it is used n times. For instance demos/complex_hierarchy project. Be *extremely careful with complex hierarchies. Complex hierarchies are always a very tricky case, and are never easy to handle. -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Option in eeschema to annotate keeping multi-unit parts grouped
Here is a fixed version of the patch. It handled perfectly any complex
hierarchies I could throw at it. Got anything worse to torture it with?
Chris
On Sat, Mar 21, 2015 at 04:44:43PM +0100, jp charras wrote:
Le 14/03/2015 00:11, Chris Pavlina a écrit :
Hello,
Here is a patch for eeschema that adds Reset existing annotation, but
do not swap any units to eeschema. This first compiles a list of
multi-unit parts and all of the components that comprise them, and then
on annotation, annotates all of them as a group. For example, if
components were originally R3B and R3C, they can be annotated to R5B and
R5C, but never R5B and R6C, or R5A and R5D.
I wanted this feature so that I could re-annotate a project to tidy up
the references, while not losing symbol-footprint mappings that already
exist in a routed PCB.
Perhaps, I'll follow up in a few days with a patch to follow through the
annotations to the other files in the project. (Currently I'm using a
hacked-together Python script for this...)
Chris
Thank for your contribution.
This is a very interesting feature.
I tested it on different schematic projects.
It works fine only for simple hierarchies.
Unfortunately, it does not work on complex hierarchies.
These hierarchies uses more than once a given sheet: there is one file,
one schematic, and several instances.
the sheet which is used more than once stores only one drawing, but n
different references when it is used n times.
For instance demos/complex_hierarchy project.
Be *extremely careful with complex hierarchies.
Complex hierarchies are always a very tricky case, and are never easy to
handle.
--
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
diff --git a/eeschema/annotate.cpp b/eeschema/annotate.cpp
index 3fccb8e..f041fe3 100644
--- a/eeschema/annotate.cpp
+++ b/eeschema/annotate.cpp
@@ -38,6 +38,7 @@
#include sch_component.h
#include lib_pin.h
+#include boost/foreach.hpp
void SCH_EDIT_FRAME::DeleteAnnotation( bool aCurrentSheetOnly )
{
@@ -62,7 +63,8 @@ void SCH_EDIT_FRAME::AnnotateComponents( bool aAnnotateSchematic,
ANNOTATE_ORDER_T aSortOption,
ANNOTATE_OPTION_T aAlgoOption,
bool aResetAnnotation,
- bool aRepairTimestamps )
+ bool aRepairTimestamps,
+ bool aLockUnits )
{
SCH_REFERENCE_LIST references;
@@ -73,6 +75,9 @@ void SCH_EDIT_FRAME::AnnotateComponents( bool aAnnotateSchematic,
// Build the sheet list.
SCH_SHEET_LIST sheets;
+// Map of locked components
+SCH_MULTI_UNIT_REFERENCE_MAP lockedComponents;
+
// Test for and replace duplicate time stamps in components and sheets. Duplicate
// time stamps can happen with old schematics, schematic conversions, or manual
// editing of files.
@@ -88,6 +93,19 @@ void SCH_EDIT_FRAME::AnnotateComponents( bool aAnnotateSchematic,
}
}
+// If units must be locked, collect all the sets that must be annotated together.
+if( aLockUnits )
+{
+if( aAnnotateSchematic )
+{
+sheets.GetMultiUnitComponents( Prj().SchLibs(), lockedComponents );
+}
+else
+{
+m_CurrentSheet-GetMultiUnitComponents( Prj().SchLibs(), lockedComponents );
+}
+}
+
// If it is an annotation for all the components, reset previous annotation.
if( aResetAnnotation )
DeleteAnnotation( !aAnnotateSchematic );
@@ -141,7 +159,7 @@ void SCH_EDIT_FRAME::AnnotateComponents( bool aAnnotateSchematic,
}
// Recalculate and update reference numbers in schematic
-references.Annotate( useSheetNum, idStep );
+references.Annotate( useSheetNum, idStep, lockedComponents );
references.UpdateAnnotation();
wxArrayString errors;
diff --git a/eeschema/component_references_lister.cpp b/eeschema/component_references_lister.cpp
index 15eb9e6..6796ef3 100644
--- a/eeschema/component_references_lister.cpp
+++ b/eeschema/component_references_lister.cpp
@@ -39,6 +39,8 @@
#include sch_reference_list.h
#include sch_component.h
+#include boost/foreach.hpp
+
//#define USE_OLD_ALGO
@@ -283,7 +285,8 @@ int SCH_REFERENCE_LIST::CreateFirstFreeRefId( std::vectorint aIdList, int aFi
}
-void SCH_REFERENCE_LIST::Annotate( bool aUseSheetNum, int aSheetIntervalId )
+void SCH_REFERENCE_LIST::Annotate( bool aUseSheetNum, int aSheetIntervalId,
+ SCH_MULTI_UNIT_REFERENCE_MAP aLockedUnitMap )
{
if ( componentFlatList.size() == 0
[Kicad-developers] [PATCH] Incorrect save-on-quit in pcbnew with unsaved board
In pcbnew, if you exit with a new (totally unsaved, but not empty) board
open, and click 'yes' in the save-on-exit box, an error is raised due to
passing an empty filename string to the save routine. Correct behavior
is to execute a 'save as' if the filename is still blank.
Attached is a patch that does this.
Chris
diff --git a/include/wxPcbStruct.h b/include/wxPcbStruct.h
index ecdf62f..7444f6d 100644
--- a/include/wxPcbStruct.h
+++ b/include/wxPcbStruct.h
@@ -848,6 +848,12 @@ public:
void OnFileHistory( wxCommandEvent event );
/**
+ * Function Files_io_from_id
+ * command handler for read and write file commands; operates directly from event ID.
+ */
+void Files_io_from_id( int id );
+
+/**
* Function Files_io
* is the command event handler for read and write file commands.
*/
diff --git a/pcbnew/files.cpp b/pcbnew/files.cpp
index 5796d8f..939b58e 100644
--- a/pcbnew/files.cpp
+++ b/pcbnew/files.cpp
@@ -222,6 +222,11 @@ void PCB_EDIT_FRAME::OnFileHistory( wxCommandEvent event )
void PCB_EDIT_FRAME::Files_io( wxCommandEvent event )
{
intid = event.GetId();
+Files_io_from_id( id );
+}
+
+void PCB_EDIT_FRAME::Files_io_from_id( int id )
+{
wxString msg;
// If an edition is in progress, stop it.
diff --git a/pcbnew/pcbframe.cpp b/pcbnew/pcbframe.cpp
index 50af8f0..386972a 100644
--- a/pcbnew/pcbframe.cpp
+++ b/pcbnew/pcbframe.cpp
@@ -595,7 +595,14 @@ void PCB_EDIT_FRAME::OnCloseWindow( wxCloseEvent Event )
break;
case wxID_YES:
-SavePcbFile( GetBoard()-GetFileName() );
+if( GetBoard()-GetFileName() == )
+{
+Files_io_from_id( ID_SAVE_BOARD_AS );
+}
+else
+{
+SavePcbFile( GetBoard()-GetFileName() );
+}
break;
}
}
___
Mailing list: https://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] Option in eeschema to annotate keeping multi-unit parts grouped
Hello,
Here is a patch for eeschema that adds Reset existing annotation, but do not swap
any units to eeschema. This first compiles a list of multi-unit parts and all of
the components that comprise them, and then on annotation, annotates all of them as a
group. For example, if components were originally R3B and R3C, they can be annotated to
R5B and R5C, but never R5B and R6C, or R5A and R5D.
I wanted this feature so that I could re-annotate a project to tidy up the
references, while not losing symbol-footprint mappings that already exist in a
routed PCB.
Perhaps, I'll follow up in a few days with a patch to follow through the
annotations to the other files in the project. (Currently I'm using a
hacked-together Python script for this...)
Chris
diff --git a/eeschema/annotate.cpp b/eeschema/annotate.cpp
index 3fccb8e..f041fe3 100644
--- a/eeschema/annotate.cpp
+++ b/eeschema/annotate.cpp
@@ -38,6 +38,7 @@
#include sch_component.h
#include lib_pin.h
+#include boost/foreach.hpp
void SCH_EDIT_FRAME::DeleteAnnotation( bool aCurrentSheetOnly )
{
@@ -62,7 +63,8 @@ void SCH_EDIT_FRAME::AnnotateComponents( bool aAnnotateSchematic,
ANNOTATE_ORDER_T aSortOption,
ANNOTATE_OPTION_T aAlgoOption,
bool aResetAnnotation,
- bool aRepairTimestamps )
+ bool aRepairTimestamps,
+ bool aLockUnits )
{
SCH_REFERENCE_LIST references;
@@ -73,6 +75,9 @@ void SCH_EDIT_FRAME::AnnotateComponents( bool aAnnotateSchematic,
// Build the sheet list.
SCH_SHEET_LIST sheets;
+// Map of locked components
+SCH_MULTI_UNIT_REFERENCE_MAP lockedComponents;
+
// Test for and replace duplicate time stamps in components and sheets. Duplicate
// time stamps can happen with old schematics, schematic conversions, or manual
// editing of files.
@@ -88,6 +93,19 @@ void SCH_EDIT_FRAME::AnnotateComponents( bool aAnnotateSchematic,
}
}
+// If units must be locked, collect all the sets that must be annotated together.
+if( aLockUnits )
+{
+if( aAnnotateSchematic )
+{
+sheets.GetMultiUnitComponents( Prj().SchLibs(), lockedComponents );
+}
+else
+{
+m_CurrentSheet-GetMultiUnitComponents( Prj().SchLibs(), lockedComponents );
+}
+}
+
// If it is an annotation for all the components, reset previous annotation.
if( aResetAnnotation )
DeleteAnnotation( !aAnnotateSchematic );
@@ -141,7 +159,7 @@ void SCH_EDIT_FRAME::AnnotateComponents( bool aAnnotateSchematic,
}
// Recalculate and update reference numbers in schematic
-references.Annotate( useSheetNum, idStep );
+references.Annotate( useSheetNum, idStep, lockedComponents );
references.UpdateAnnotation();
wxArrayString errors;
diff --git a/eeschema/component_references_lister.cpp b/eeschema/component_references_lister.cpp
index 15eb9e6..12ab18b 100644
--- a/eeschema/component_references_lister.cpp
+++ b/eeschema/component_references_lister.cpp
@@ -39,6 +39,8 @@
#include sch_reference_list.h
#include sch_component.h
+#include boost/foreach.hpp
+
//#define USE_OLD_ALGO
@@ -283,7 +285,8 @@ int SCH_REFERENCE_LIST::CreateFirstFreeRefId( std::vectorint aIdList, int aFi
}
-void SCH_REFERENCE_LIST::Annotate( bool aUseSheetNum, int aSheetIntervalId )
+void SCH_REFERENCE_LIST::Annotate( bool aUseSheetNum, int aSheetIntervalId,
+ SCH_MULTI_UNIT_REFERENCE_MAP aLockedUnitMap )
{
if ( componentFlatList.size() == 0 )
return;
@@ -327,6 +330,24 @@ void SCH_REFERENCE_LIST::Annotate( bool aUseSheetNum, int aSheetIntervalId )
if( componentFlatList[ii].m_Flag )
continue;
+// Check whether this component is in aLockedUnitMap.
+SCH_REFERENCE_LIST* lockedList = NULL;
+BOOST_FOREACH( SCH_MULTI_UNIT_REFERENCE_MAP::value_type pair, aLockedUnitMap )
+{
+unsigned n_refs = pair.second.GetCount();
+for( unsigned thisRefI = 0; thisRefI n_refs; ++thisRefI )
+{
+SCH_REFERENCE thisRef = pair.second[thisRefI];
+SCH_COMPONENT *thisComp = thisRef.GetComp();
+if( thisComp == componentFlatList[ii].GetComp() )
+{
+lockedList = pair.second;
+break;
+}
+}
+if( lockedList != NULL ) break;
+}
+
if( ( componentFlatList[first].CompareRef( componentFlatList[ii] ) != 0 )
|| ( aUseSheetNum ( componentFlatList[first].m_SheetNum != componentFlatList[ii].m_SheetNum ) ) )
{
@@ -388,47 +409,87 @@ void
Re: [Kicad-developers] [proposal] Handling conflict between projname-cache.lib and an updated library
Any more thoughts on this from any other devs? If nobody objects, I think I'll get started coding this up in the next day or so. -- Chris On Mon, Mar 23, 2015 at 01:27:35PM -0400, Wayne Stambaugh wrote: On 3/23/2015 1:16 PM, Chris Pavlina wrote: On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote: On 3/23/2015 12:12 PM, Chris Pavlina wrote: I like your idea - I proposed it myself, but it was not well received ;) [[snip]] Please see the discussion here on why this will not work. https://bugs.launchpad.net/kicad/+bug/1435338 I see no point in replacing one bug with another bug that doesn't fix the underlying problem. Haha, just kidding, I know :) Rather than just copy the cache file, rename all of the footprints in the copied library with a prefix or suffix, i.e. 74LS00 in the cache becomes 74LS00_SCH in the new library. Then rename all the components in the schematic accordingly if the user chooses the new library option. This way there will be little chance of conflicting component names and the library search order is less likely to be an issue. This gives you the best of both worlds. You keep your existing components in the schematic and you can still use the updated components from the your libraries if you so choose. Obviously this still wont fix the library search ordering issue but it would be a more robust solution. Actually, I quite like this idea. I know it's more work but it solves the component name clash issues and the user will still be able to use their normal libraries. ___ Mailing list: https://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?] Handling conflict between projname-cache.lib and an updated library
Well, that was kind of the point - a stopgap for now, to keep the current way the symbols were handled from confusing people too much. I planned for it to become obsolete :D On Mon, Mar 30, 2015 at 05:55:34PM +0200, Tomasz Wlostowski wrote: On 30.03.2015 17:43, Chris Pavlina wrote: [snip] Hi Chris, Nice patch, although with its current purpose, it will become obsolete in the future, as the new schematic file format Wayne's working on will add the possibility to cache the schematic symbols within .kicad_sch files (just like the footprint copies are stored in .kicad_pcb files now). Nonetheless, your tool (after some minor refactoring) could make a nice library to SCH symbol updater (or sch-library symbol extractor), a feature present in most good EDA tools ;) Tom -- Chris On Mon, Mar 23, 2015 at 01:27:35PM -0400, Wayne Stambaugh wrote: On 3/23/2015 1:16 PM, Chris Pavlina wrote: On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote: On 3/23/2015 12:12 PM, Chris Pavlina wrote: I like your idea - I proposed it myself, but it was not well received ;) [[snip]] Please see the discussion here on why this will not work. https://bugs.launchpad.net/kicad/+bug/1435338 I see no point in replacing one bug with another bug that doesn't fix the underlying problem. Haha, just kidding, I know :) Rather than just copy the cache file, rename all of the footprints in the copied library with a prefix or suffix, i.e. 74LS00 in the cache becomes 74LS00_SCH in the new library. Then rename all the components in the schematic accordingly if the user chooses the new library option. This way there will be little chance of conflicting component names and the library search order is less likely to be an issue. This gives you the best of both worlds. You keep your existing components in the schematic and you can still use the updated components from the your libraries if you so choose. Obviously this still wont fix the library search ordering issue but it would be a more robust solution. Actually, I quite like this idea. I know it's more work but it solves the component name clash issues and the user will still be able to use their normal libraries. ___ Mailing list: https://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
[Kicad-developers] Question on kicad-install.sh
Does anyone know why kicad-install.sh does this?
for p in ${prerequisite_list}
do
sudo apt-get install $p || exit 1
done
Rather than something along the lines of this:
echo ${prerequisite_list} | xargs -d\n sudo apt-get install
The long prompts for permission to install each package have, erm,
aggravated some users, and adding -y isn't quite the right choice IMHO
as it removes the user's ability to veto the package list.
Any chance of changing it?
Chris
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH] Friendlier warning for modifying power values
Currently, if you try to edit the value of a power component in
eeschema, you get a ... is a power component and it's [sic] value
cannot be modified! message. That message isn't completely accurate,
though. The edit box also allows you to change the *formatting*, which
is perfectly valid to do for power texts. Unfortunately, that means that
if you want to change formatting, you have to go through the
whole-component edit dialog.
This patch removes that error message. Instead, when editing a power
component's value, the text field in the edit box is greyed out, and a
message Power component value text cannot be modified! is displayed
underneath it. All formatting options remain active.
Chris
diff --git a/eeschema/dialogs/dialog_edit_one_field.cpp b/eeschema/dialogs/dialog_edit_one_field.cpp
index 60ef3a6..13bd957 100644
--- a/eeschema/dialogs/dialog_edit_one_field.cpp
+++ b/eeschema/dialogs/dialog_edit_one_field.cpp
@@ -62,6 +62,7 @@ void DIALOG_EDIT_ONE_FIELD::initDlg_base()
m_Invisible-SetValue( m_text_invisible );
m_TextShapeOpt-SetSelection( m_textshape );
+SetPowerWarning( false );
switch ( m_textHjustify )
{
@@ -97,8 +98,15 @@ void DIALOG_EDIT_ONE_FIELD::initDlg_base()
m_TextSizeText-SetLabel( msg );
m_sdbSizerButtonsOK-SetDefault();
+
}
+void DIALOG_EDIT_ONE_FIELD::SetPowerWarning( bool aWarn )
+{
+m_PowerComponentValues-Show( aWarn );
+m_TextValue-Enable( ! aWarn );
+Fit();
+}
void DIALOG_EDIT_ONE_FIELD::OnTextValueSelectButtonClick( wxCommandEvent aEvent )
{
@@ -159,8 +167,11 @@ wxString DIALOG_LIB_EDIT_ONE_FIELD::GetTextField()
}
-void DIALOG_EDIT_ONE_FIELD::TransfertDataToField()
+void DIALOG_EDIT_ONE_FIELD::TransfertDataToField( bool aIncludeText )
{
+// This method doesn't transfer text anyway.
+(void) aIncludeText;
+
m_textorient = m_Orient-GetValue() ? TEXT_ORIENT_VERT : TEXT_ORIENT_HORIZ;
wxString msg = m_TextSize-GetValue();
m_textsize = ValueFromString( g_UserUnit, msg );
@@ -197,11 +208,12 @@ void DIALOG_EDIT_ONE_FIELD::TransfertDataToField()
}
-void DIALOG_LIB_EDIT_ONE_FIELD::TransfertDataToField()
+void DIALOG_LIB_EDIT_ONE_FIELD::TransfertDataToField( bool aIncludeText )
{
-DIALOG_EDIT_ONE_FIELD::TransfertDataToField();
+DIALOG_EDIT_ONE_FIELD::TransfertDataToField( aIncludeText );
-m_field-SetText( GetTextField() );
+if( aIncludeText )
+m_field-SetText( GetTextField() );
m_field-SetSize( wxSize( m_textsize, m_textsize ) );
m_field-SetOrientation( m_textorient );
@@ -255,11 +267,12 @@ wxString DIALOG_SCH_EDIT_ONE_FIELD::GetTextField()
};
-void DIALOG_SCH_EDIT_ONE_FIELD::TransfertDataToField()
+void DIALOG_SCH_EDIT_ONE_FIELD::TransfertDataToField( bool aIncludeText )
{
-DIALOG_EDIT_ONE_FIELD::TransfertDataToField();
+DIALOG_EDIT_ONE_FIELD::TransfertDataToField( aIncludeText );
-m_field-SetText( GetTextField() );
+if( aIncludeText )
+m_field-SetText( GetTextField() );
m_field-SetSize( wxSize( m_textsize, m_textsize ) );
m_field-SetOrientation( m_textorient );
diff --git a/eeschema/dialogs/dialog_edit_one_field.h b/eeschema/dialogs/dialog_edit_one_field.h
index 7edd99b..c52d4ef 100644
--- a/eeschema/dialogs/dialog_edit_one_field.h
+++ b/eeschema/dialogs/dialog_edit_one_field.h
@@ -74,14 +74,27 @@ public:
/**
* Function TransfertDataToField
* Converts fields from dialog window to variables to be used by child classes
+ *
+ * @param aIncludeText Whether the valies transferred should include the actual
+ * item text. If this is false, formatting will be transferred, but text will
+ * not.
*/
-virtual void TransfertDataToField();
+virtual void TransfertDataToField( bool aIncludeText = true );
void SetTextField( const wxString aText )
{
m_TextValue-SetValue( aText );
}
+/**
+ * Function SetPowerWarning
+ * Disables the Text field and displays the Power component values cannot
+ * be modified! warning, if aWarn is true. Performs the inverse if aWarn
+ * is false (this, however, is the default).
+ *
+ * @param aWarn whether or not to produce the warning
+ */
+void SetPowerWarning( bool aWarn );
protected:
/**
@@ -143,7 +156,7 @@ public:
~DIALOG_LIB_EDIT_ONE_FIELD() {};
-void TransfertDataToField();
+void TransfertDataToField( bool aIncludeText = true );
/**
* Function GetTextField
@@ -186,7 +199,7 @@ public:
// ~DIALOG_SCH_EDIT_ONE_FIELD() {};
-void TransfertDataToField();
+void TransfertDataToField( bool aIncludeText = true );
/**
* Function GetTextField
diff --git a/eeschema/dialogs/dialog_lib_edit_text_base.cpp b/eeschema/dialogs/dialog_lib_edit_text_base.cpp
index 70324cc..5d3ca5a 100644
--- a/eeschema/dialogs/dialog_lib_edit_text_base.cpp
+++ b/eeschema/dialogs/dialog_lib_edit_text_base.cpp
@@ -1,5 +1,5 @@
Re: [Kicad-developers] [PATCH] Option in eeschema to annotate keeping multi-unit parts grouped
Got it - fixed. Looks like I was a bit overzealous in correcting the
first patch and introduced this.
I also found another issue - it didn't treat unannotated parts
differently, so if you had a schematic full of R?A it would try to make
them all R1A. Also fixed.
I can't think of anything else to test. I tried it on every combination
of hierarchical nastiness I could and it worked fine. Here's the latest
version, and final if you also can't think of anything else.
Thanks,
Chris
On Sun, Mar 22, 2015 at 04:06:57PM +0100, jp charras wrote:
Le 22/03/2015 03:18, Chris Pavlina a écrit :
Here is a fixed version of the patch. It handled perfectly any complex
hierarchies I could throw at it. Got anything worse to torture it with?
Chris
Better, but not yet perfect...
There is an issue for units of a package which are on different sheets
(both simple and complex hierarchies).
The normal annotation use only one package:
For instance unit A of package U1 is in a sheet, unit B of the same
package U1 is on an other sheet.
The do not swap units uses one package per sheet (U1A for a sheet, but
U2B for the other sheet).
--
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
diff --git a/eeschema/annotate.cpp b/eeschema/annotate.cpp
index 3fccb8e..f041fe3 100644
--- a/eeschema/annotate.cpp
+++ b/eeschema/annotate.cpp
@@ -38,6 +38,7 @@
#include sch_component.h
#include lib_pin.h
+#include boost/foreach.hpp
void SCH_EDIT_FRAME::DeleteAnnotation( bool aCurrentSheetOnly )
{
@@ -62,7 +63,8 @@ void SCH_EDIT_FRAME::AnnotateComponents( bool aAnnotateSchematic,
ANNOTATE_ORDER_T aSortOption,
ANNOTATE_OPTION_T aAlgoOption,
bool aResetAnnotation,
- bool aRepairTimestamps )
+ bool aRepairTimestamps,
+ bool aLockUnits )
{
SCH_REFERENCE_LIST references;
@@ -73,6 +75,9 @@ void SCH_EDIT_FRAME::AnnotateComponents( bool aAnnotateSchematic,
// Build the sheet list.
SCH_SHEET_LIST sheets;
+// Map of locked components
+SCH_MULTI_UNIT_REFERENCE_MAP lockedComponents;
+
// Test for and replace duplicate time stamps in components and sheets. Duplicate
// time stamps can happen with old schematics, schematic conversions, or manual
// editing of files.
@@ -88,6 +93,19 @@ void SCH_EDIT_FRAME::AnnotateComponents( bool aAnnotateSchematic,
}
}
+// If units must be locked, collect all the sets that must be annotated together.
+if( aLockUnits )
+{
+if( aAnnotateSchematic )
+{
+sheets.GetMultiUnitComponents( Prj().SchLibs(), lockedComponents );
+}
+else
+{
+m_CurrentSheet-GetMultiUnitComponents( Prj().SchLibs(), lockedComponents );
+}
+}
+
// If it is an annotation for all the components, reset previous annotation.
if( aResetAnnotation )
DeleteAnnotation( !aAnnotateSchematic );
@@ -141,7 +159,7 @@ void SCH_EDIT_FRAME::AnnotateComponents( bool aAnnotateSchematic,
}
// Recalculate and update reference numbers in schematic
-references.Annotate( useSheetNum, idStep );
+references.Annotate( useSheetNum, idStep, lockedComponents );
references.UpdateAnnotation();
wxArrayString errors;
diff --git a/eeschema/component_references_lister.cpp b/eeschema/component_references_lister.cpp
index 15eb9e6..6796ef3 100644
--- a/eeschema/component_references_lister.cpp
+++ b/eeschema/component_references_lister.cpp
@@ -39,6 +39,8 @@
#include sch_reference_list.h
#include sch_component.h
+#include boost/foreach.hpp
+
//#define USE_OLD_ALGO
@@ -283,7 +285,8 @@ int SCH_REFERENCE_LIST::CreateFirstFreeRefId( std::vectorint aIdList, int aFi
}
-void SCH_REFERENCE_LIST::Annotate( bool aUseSheetNum, int aSheetIntervalId )
+void SCH_REFERENCE_LIST::Annotate( bool aUseSheetNum, int aSheetIntervalId,
+ SCH_MULTI_UNIT_REFERENCE_MAP aLockedUnitMap )
{
if ( componentFlatList.size() == 0 )
return;
@@ -327,6 +330,24 @@ void SCH_REFERENCE_LIST::Annotate( bool aUseSheetNum, int aSheetIntervalId )
if( componentFlatList[ii].m_Flag )
continue;
+// Check whether this component is in aLockedUnitMap.
+SCH_REFERENCE_LIST* lockedList = NULL;
+BOOST_FOREACH( SCH_MULTI_UNIT_REFERENCE_MAP::value_type pair, aLockedUnitMap )
+{
+unsigned n_refs = pair.second.GetCount();
+for( unsigned thisRefI = 0; thisRefI
[Kicad-developers] [proposal] Handling conflict between projname-cache.lib and an updated library
When loading an old schematic, it's fairly common for it to be broken, if symbols have changed significantly in the libraries. An example: https://i.imgur.com/7cVBneA.png A workaround suggested by Wayne is to make a local copy of the projname-cache.lib file, and add it to the project as a library, at the top of the list. This way, components in it will override the system libs. I think it will be friendlier for newer users if we can detect this, and offer to solve it. What if we were to display something along these lines, when loading a schematic where projname-cache.lib has symbols with significant differences from system versions? This project appears to use different versions of some components from what is installed on your system. What would you like to do? [] Update this project to use the new components. There may be parts that longer fit correctly, and you will have to fix them yourself. [] Create a new library containing the versions of the components used in this project, and add it to the project. [] Choose manually for each component. === [] Never ask me again, I can handle this myself. The first option would do what it does now - components will be loaded from the system libraries. The second version will save a copy of projname-cache.lib into the project directory and add it to the top of the library list. This may require a way to make sure that a library is loaded directly out of the project directory rather than checking the entire search path - I'd think this could be relatively simple, perhaps load from the project directory if a library filename in the list starts with ./ ? The third option will display all the conflicting components with a list of the references using them, allowing only *some* of them to be exported to the new library. I know that there are plans to completely change the way libraries work, but this problem really seems to confuse some beginners, and this seems to me like a decent stopgap. What do you think? Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [proposal] Handling conflict between projname-cache.lib and an updated library
I like your idea - I proposed it myself, but it was not well received ;) (Bah, still getting used to the fact that Launchpad doesn't set reply-to) On Mon, Mar 23, 2015 at 05:06:08PM +0100, Ladislav Laska wrote: Hi! That is unfortunate. I really would like this: use the cached version, unless you choose to update from library (in a global menu, or per component). This is really handy, since you don't have to do anything, unless you specifically want to (for example, there is a new, better symbol), and you can still use the up to date library (for new parts). A win-win situation. On Mon, Mar 23, 2015 at 11:52:48AM -0400, Chris Pavlina wrote: When loading an old schematic, it's fairly common for it to be broken, if symbols have changed significantly in the libraries. An example: https://i.imgur.com/7cVBneA.png A workaround suggested by Wayne is to make a local copy of the projname-cache.lib file, and add it to the project as a library, at the top of the list. This way, components in it will override the system libs. I think it will be friendlier for newer users if we can detect this, and offer to solve it. What if we were to display something along these lines, when loading a schematic where projname-cache.lib has symbols with significant differences from system versions? This project appears to use different versions of some components from what is installed on your system. What would you like to do? [] Update this project to use the new components. There may be parts that longer fit correctly, and you will have to fix them yourself. [] Create a new library containing the versions of the components used in this project, and add it to the project. [] Choose manually for each component. === [] Never ask me again, I can handle this myself. The first option would do what it does now - components will be loaded from the system libraries. The second version will save a copy of projname-cache.lib into the project directory and add it to the top of the library list. This may require a way to make sure that a library is loaded directly out of the project directory rather than checking the entire search path - I'd think this could be relatively simple, perhaps load from the project directory if a library filename in the list starts with ./ ? The third option will display all the conflicting components with a list of the references using them, allowing only *some* of them to be exported to the new library. I know that there are plans to completely change the way libraries work, but this problem really seems to confuse some beginners, and this seems to me like a decent stopgap. What do you think? Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp -- S pozdravem Ladislav Láska la...@kam.mff.cuni.cz Katedra Aplikované Matematiky, MFF UK tel.: +420 739 464 167 ___ Mailing list: https://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] Handling conflict between projname-cache.lib and an updated library
On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote: On 3/23/2015 12:12 PM, Chris Pavlina wrote: I like your idea - I proposed it myself, but it was not well received ;) [[snip]] Please see the discussion here on why this will not work. https://bugs.launchpad.net/kicad/+bug/1435338 I see no point in replacing one bug with another bug that doesn't fix the underlying problem. Haha, just kidding, I know :) Rather than just copy the cache file, rename all of the footprints in the copied library with a prefix or suffix, i.e. 74LS00 in the cache becomes 74LS00_SCH in the new library. Then rename all the components in the schematic accordingly if the user chooses the new library option. This way there will be little chance of conflicting component names and the library search order is less likely to be an issue. This gives you the best of both worlds. You keep your existing components in the schematic and you can still use the updated components from the your libraries if you so choose. Obviously this still wont fix the library search ordering issue but it would be a more robust solution. Actually, I quite like this idea. ___ Mailing list: https://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] Feature Request: ViaStiching
KiCad does not currently support standalone vias, and I think that would be a necessity before a *clean* implementation of this could be done. The only other options are to either place a /footprint/ as a via (nasty), or place a web of traces along with the vias (terribly, horribly filthy). That said, I think both are excellent ideas. They won't make it before the freeze, but they ought to be added after it anyway, in the proper order required. -- Chris On Mon, Mar 23, 2015 at 06:48:18PM +0100, Michael Heidinger wrote: Hello, I would like to propose a tool via stitching. Simply many via next to each other. Via stitching is required for me to do thermal transfer from one side to the other. Manual placing requires a lot of effort, a tool could simplify that. Usage: I would to specify the area and the net and the tool should place the the vias for me. Do you think that such tool could be possible? Altium has a great implementation of via stiching: Do you think that's possible? http://techdocs.altium.com/display/ADOH/Via+Stitching - Michael ___ Mailing list: https://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?] Handling conflict between projname-cache.lib and an updated library
Thanks. I'll patch these bits soon. I'll have to try it on Windows and see how that dialog displays, it's fine here in Linux. Also, I'll get writing the documentation for it. Personally, I like the idea of having a summary at the end, as you might want to have an actual list of the components changed. Actually, I'd even prefer if it were in a format that could be put on the clipboard. Anyone else have a comment on that? On Sat, Apr 25, 2015 at 06:29:32PM -0400, Wayne Stambaugh wrote: Chris, I committed your patch in the product branch r5623. Very nice work by the way. I have a few minor comments. * Most of the wxT() and _() macros are missing spaces between the braces and the string. * The rescue dialog does not have a default button set so that you can just hit enter to select the default action. In this case it should be the OK button. * I'm not sure we need a second dialog after the rescue dialog. It seems a bit like nagware to me. If we decide to keep the rescue status dialog, it needs to be fixed because it has to be expanded (at least on windows) because it doesn't show anything other than the headers. Try using Fit() after populating the control before the dialog is shown. There are examples of this in other kicad dialogs. * Everyone please test this thoroughly if you have any old schematics so we can be sure it's robust enough for the stable release. Thanks, Wayne On 4/12/2015 1:57 PM, Chris Pavlina wrote: And, because I'm excessively stupid today, here's a version of the patch that I didn't diff incorrectly. On Fri, Apr 10, 2015 at 07:15:00PM -0400, Wayne Stambaugh wrote: On 4/8/2015 8:48 PM, Chris Pavlina wrote: Any more devs have an opinion on this? I've already said it would be a good idea albeit a temporary one for the upcoming stable release. I just saw another reply to a bug report about someones schematic being incorrect because the library components have changed. Looking at the changes to the component libraries, it would be my guess that we will have a lot of upset users who have not upgrade from the previous stable release. Does anyone else have any opinions about this? On Mon, Mar 30, 2015 at 02:01:07PM -0400, Wayne Stambaugh wrote: On 3/30/2015 1:58 PM, Chris Pavlina wrote: On Mar 30, 2015 1:49 PM, Wayne Stambaugh stambau...@gmail.com mailto:stambau...@gmail.com wrote: Please fix your coding style issues. I saw: if( foo ) bar; should be: if( foo ) bar; Also, two blank lines between function definitions in cpp files. Oops, missed these bits of the style. Will fix by tomorrow. In the future, please do not create OnOk()/OnCancel() message handlers then call EndModal() in your dialogs. This is broken by design. Your dialog may not always be modal. It may be useful to create them as modeless or quasi-modal so calling EndModal() fail. I know it is used in virtually every dialog in KiCad and it is fundamentally wrong. The wxWidgets developers were kind enough to create all the necessary plumbing to handle this. Please read http://docs.wxwidgets.org/3.0/overview_validator.html and take look at common/dialogs/dialog_env_var_config.cpp for tips on transferring data to and from the controls using wxDialog. Oh, you'll have to forgive me, I'm a bit new to wx. Not just in the future, I'll get this fixed as well. Last thing I want to do is add broken code to KiCad. Perhaps I'll help out and start working on fixing some of the existing ones too. Thanks. Don't worry about the existing ones until after the stable release. I want to keep focused on that until it's done. Otherwise, we will just keep making changes and never get the stable release out the door. I want to let everything stabilize and make sure we get all of the bugs fixed. [snip] I need your assurance that you will see it through to the stable release before I'm willing to give it my approval. I would also appreciate if you could update the Eeschema documentation at https://github.com/ciampix/kicad-doc or have someone document it for you. What say the rest of you? Yup, plan was to see it through. I'll document it as well - just let me get these fixes implemented first. You've got plenty of time. The stable release goal is the late June/early July time frame. On 3/30/2015 11:43 AM, Chris Pavlina wrote: Well, seems I missed the freeze on this one, but I've got a patch, might as well share. Works well for me - comments welcome, of course, and ideas for more testcases. At schematic load, or when the tool is selected from the menu, the schematic is analyzed for any problematic components. These are where the component found in the cache has pins moved or changed from the one found in the system libraries. When this happens, the following dialog is displayed: https://db.tt/qIAesEQv The user can choose per symbol whether to keep the library version or the cached version. Any cached components selected for rescue are renamed to $componentname-RESCUE
[Kicad-developers] [PATCH] lib-cache-rescue default button in dialog
Here's a patch that sets the 'OK' button as default in the rescue dialog.
--
Chris
commit 028e30fb7d422ae2d1aa2a6bcd60c4962e7385e9
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Sun May 3 12:37:50 2015 -0400
Set default button in rescue dialog
diff --git a/eeschema/dialogs/dialog_rescue_each.cpp b/eeschema/dialogs/dialog_rescue_each.cpp
index 54e1842..58d1c30 100644
--- a/eeschema/dialogs/dialog_rescue_each.cpp
+++ b/eeschema/dialogs/dialog_rescue_each.cpp
@@ -86,6 +86,7 @@ DIALOG_RESCUE_EACH::DIALOG_RESCUE_EACH( SCH_EDIT_FRAME* aParent, std::vectorRES
m_insideUpdateEvent( false )
{
m_Config = Kiface().KifaceSettings();
+m_stdButtonsOK-SetDefault();
}
___
Mailing list: https://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] lib-cache-rescue coding style fixes
Here's a patch that fixes a few minor coding style issues with lib-cache-rescue.
--
Chris
commit 18380f35788821b508c4a01a420f67d17eea4d37
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Sun May 3 12:26:55 2015 -0400
Fix coding style
Add space inside parentheses
diff --git a/eeschema/dialogs/dialog_rescue_each.cpp b/eeschema/dialogs/dialog_rescue_each.cpp
index 3a20775..54e1842 100644
--- a/eeschema/dialogs/dialog_rescue_each.cpp
+++ b/eeschema/dialogs/dialog_rescue_each.cpp
@@ -99,10 +99,10 @@ bool DIALOG_RESCUE_EACH::TransferDataToWindow()
if( !wxDialog::TransferDataToWindow() )
return false;
-m_ListOfConflicts-AppendToggleColumn( _(Rescue symbol) );
-m_ListOfConflicts-AppendTextColumn( _(Symbol name) );
-m_ListOfInstances-AppendTextColumn( _(Reference) );
-m_ListOfInstances-AppendTextColumn( _(Value) );
+m_ListOfConflicts-AppendToggleColumn( _( Rescue symbol ) );
+m_ListOfConflicts-AppendTextColumn( _( Symbol name ) );
+m_ListOfInstances-AppendTextColumn( _( Reference ) );
+m_ListOfInstances-AppendTextColumn( _( Value ) );
PopulateConflictList();
PopulateInstanceList();
@@ -152,7 +152,7 @@ void DIALOG_RESCUE_EACH::PopulateInstanceList()
data.clear();
data.push_back( each_component-GetRef( m_Parent-GetCurrentSheet() ) );
-data.push_back( valueField ? valueField-GetText() : wxT() );
+data.push_back( valueField ? valueField-GetText() : wxT( ) );
m_ListOfInstances-AppendItem( data );
}
diff --git a/eeschema/lib_cache_rescue.cpp b/eeschema/lib_cache_rescue.cpp
index e8f9680..e4a7bd6 100644
--- a/eeschema/lib_cache_rescue.cpp
+++ b/eeschema/lib_cache_rescue.cpp
@@ -247,7 +247,7 @@ static void find_rescues( std::vectorSCH_COMPONENT* aComponents, PART_LIBS* a
static PART_LIB* create_rescue_library( wxFileName aFileName )
{
wxFileName fn( g_RootSheet-GetScreen()-GetFileName() );
-fn.SetName( fn.GetName() + wxT(-rescue) );
+fn.SetName( fn.GetName() + wxT( -rescue ) );
fn.SetExt( SchematicLibraryFileExtension );
aFileName.SetPath( fn.GetPath() );
aFileName.SetName( fn.GetName() );
@@ -321,7 +321,7 @@ bool SCH_EDIT_FRAME::RescueCacheConflicts( bool aRunningOnDemand )
get_components( components );
prj = Prj();
libs = prj-SchLibs();
-part_name_suffix = wxT(-RESCUE-) + prj-GetProjectName();
+part_name_suffix = wxT( -RESCUE- ) + prj-GetProjectName();
// Start!
find_rescues( components, libs, candidates );
___
Mailing list: https://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] lib-cache-rescue: remove summary dialog, correct minor bug
://www.wxformbuilder.org/
//
// PLEASE DO NOT EDIT THIS FILE!
diff --git a/eeschema/dialogs/dialog_rescue_summary.cpp b/eeschema/dialogs/dialog_rescue_summary.cpp
deleted file mode 100644
index cd68ed2..000
--- a/eeschema/dialogs/dialog_rescue_summary.cpp
+++ /dev/null
@@ -1,88 +0,0 @@
-/*
- * This program source code file is part of KiCad, a free EDA CAD application.
- *
- * Copyright (C) 2015 Chris Pavlina pavlina.ch...@gmail.com
- * Copyright (C) 2015 Kicad Developers, see change_log.txt for contributors.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version 2
- * of the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, you may find one here:
- * http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
- * or you may search the http://www.gnu.org website for the version 2 license,
- * or you may write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
- */
-
-#include schframe.h
-#include invoke_sch_dialog.h
-#include dialog_rescue_summary_base.h
-#include kiface_i.h
-#include lib_cache_rescue.h
-#include sch_component.h
-#include vector
-#include boost/foreach.hpp
-
-class DIALOG_RESCUE_SUMMARY: public DIALOG_RESCUE_SUMMARY_BASE
-{
-public:
-DIALOG_RESCUE_SUMMARY( SCH_EDIT_FRAME* aParent, std::vectorRESCUE_LOG aRescueLog );
-
-private:
-SCH_EDIT_FRAME* m_Parent;
-wxConfigBase* m_Config;
-std::vectorRESCUE_LOG* m_RescueLog;
-
-bool TransferDataToWindow();
-void OnOkClick( wxCommandEvent event );
-};
-
-
-DIALOG_RESCUE_SUMMARY::DIALOG_RESCUE_SUMMARY( SCH_EDIT_FRAME* aParent, std::vectorRESCUE_LOG aRescueLog )
-: DIALOG_RESCUE_SUMMARY_BASE( aParent ), m_Parent( aParent), m_RescueLog( aRescueLog )
-{
-m_Config = Kiface().KifaceSettings();
-}
-
-
-bool DIALOG_RESCUE_SUMMARY::TransferDataToWindow()
-{
-if( !wxDialog::TransferDataToWindow() )
-return false;
-
-m_ListOfChanges-AppendTextColumn( wxT( Reference ) );
-m_ListOfChanges-AppendTextColumn( wxT( Old Symbol ), wxDATAVIEW_CELL_INERT, /*width*/ 100);
-m_ListOfChanges-AppendTextColumn( wxT( New Symbol ), wxDATAVIEW_CELL_INERT, /*width*/ 100);
-
-wxVectorwxVariant data;
-BOOST_FOREACH( RESCUE_LOG each_log_item, *m_RescueLog )
-{
-data.clear();
-data.push_back( each_log_item.component-GetRef( m_Parent-GetCurrentSheet() ) );
-data.push_back( each_log_item.old_name );
-data.push_back( each_log_item.new_name );
-m_ListOfChanges-AppendItem( data );
-}
-
-GetSizer()-Layout();
-GetSizer()-Fit( this );
-GetSizer()-SetSizeHints( this );
-Centre();
-
-return true;
-}
-
-
-int InvokeDialogRescueSummary( SCH_EDIT_FRAME* aCaller, std::vectorRESCUE_LOG aRescueLog )
-{
-DIALOG_RESCUE_SUMMARY dlg( aCaller, aRescueLog );
-return dlg.ShowModal();
-}
diff --git a/eeschema/dialogs/dialog_rescue_summary_base.cpp b/eeschema/dialogs/dialog_rescue_summary_base.cpp
deleted file mode 100644
index 816e789..000
--- a/eeschema/dialogs/dialog_rescue_summary_base.cpp
+++ /dev/null
@@ -1,48 +0,0 @@
-///
-// C++ code generated with wxFormBuilder (version Jun 5 2014)
-// http://www.wxformbuilder.org/
-//
-// PLEASE DO NOT EDIT THIS FILE!
-///
-
-#include dialog_rescue_summary_base.h
-
-///
-
-DIALOG_RESCUE_SUMMARY_BASE::DIALOG_RESCUE_SUMMARY_BASE( wxWindow* parent, wxWindowID id, const wxString title, const wxPoint pos, const wxSize size, long style ) : DIALOG_SHIM( parent, id, title, pos, size, style )
-{
- this-SetSizeHints( wxDefaultSize, wxDefaultSize );
-
- wxBoxSizer* bmainSizer;
- bmainSizer = new wxBoxSizer( wxVERTICAL );
-
- wxBoxSizer* bupperSizer;
- bupperSizer = new wxBoxSizer( wxVERTICAL );
-
- m_staticText5 = new wxStaticText( this, wxID_ANY, _(The symbols of the following components were changed:), wxDefaultPosition, wxDefaultSize, 0 );
- m_staticText5-Wrap( -1 );
- bupperSizer-Add( m_staticText5, 0, wxTOP|wxRIGHT|wxLEFT, 5 );
-
- m_ListOfChanges = new wxDataViewListCtrl( this, wxID_ANY, wxDefaultPosition, wxDefaultSize, 0 );
- m_ListOfChanges-SetMinSize( wxSize( -1,200 ) );
-
- bupperSizer-Add( m_ListOfChanges, 1, wxALL|wxEXPAND, 5 );
-
- m_sdbSizer = new wxStdDialogButtonSizer();
- m_sdbSizerOK = new wxButton( this, wxID_OK );
- m_sdbSizer-AddButton( m_sdbSizerOK
Re: [Kicad-developers] kicad main icons - minor improvements
People recognize icons quickly by their silhouettes. This is already pretty hard with the existing KiCad icon set, and you're making it harder, by making so many icons into a symbol on top of paper. I agree that the icons need work, but we've got to keep good UI design practices in mind while doing it. Can you do them in a way that makes them *more* individually distinctive? -- Chris On Mon, May 04, 2015 at 08:42:05PM +0200, Fabrizio Tappero wrote: Hello, I am working on some styling improvements of the main kicad icons. The two lib component editor and lib footprint editor really need some work, I think. This is some intermediate result: [image: Inline image 2] Any feedback would be great. I think that the pen (that suggest the editing) is actually quite redundant. I attach the svg file just in case somebody (Konstantin?) feels like contributing. Regards Fabrizio ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] lib-cache-rescue: remove summary dialog, correct minor bug
Hi Wayne, That's interesting. I can't really imagine what would cause that, and I haven't seen anything like that - I've tested it on many projects that should have stirred that bug up if it existed. Any chance you can share with me the problem project? Chris On Wed, May 13, 2015 at 11:01:17AM -0400, Wayne Stambaugh wrote: Chris, I just tested this and I like the changes. I believe I found a bug. I just rescued an old project and noticed all of the zener diodes were oriented 180 degrees from the unrescued version. When you get a chance, would you please verify the component orientation against the rescued library is correct. I'll commit this patch. If you find a bug, please apply the patch against this patch. Thanks, Wayne On 5/4/2015 1:30 PM, Chris Pavlina wrote: I've got two changes here - they're a bit inadvertently intertwined, so I left them as one patch, otherwise one would depend on the other anyway. Let me know if you want me to discard half. 1. Remove the summary dialog from lib-cache-rescue. I originally created it so the user would know what the new names of the components were; I compensated by changing the main dialog to display the suffix that will be added to the parts. 2. Minor bugfix: If no parts are rescued, an empty rescue library shouldn't be written. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] lib-cache-rescue: remove summary dialog, correct minor bug
I don't use the KiCad libraries usually, so I'm unaware - were the pin numbers swapped? If that's the case, I'm not sure of a way to handle that gracefully, as from the software's perspective, pin 1 is pin 1 is pin 1 - the fact that the cathode band is drawn elsewhere obviously doesn't factor into that, it's just a graphical change. Any ideas on how I could handle that? -- Chris On Wed, May 13, 2015 at 11:45:38AM -0400, Wayne Stambaugh wrote: This is altogether possible as I have recently installed the latest library changes. On 5/13/2015 11:37 AM, Maciej Sumiński wrote: Is it possible the problem is related to the recent diode pin swapping in KiCad library? Regards, Orson On 05/13/2015 05:35 PM, Chris Pavlina wrote: Hi Wayne, That's interesting. I can't really imagine what would cause that, and I haven't seen anything like that - I've tested it on many projects that should have stirred that bug up if it existed. Any chance you can share with me the problem project? Chris On Wed, May 13, 2015 at 11:01:17AM -0400, Wayne Stambaugh wrote: Chris, I just tested this and I like the changes. I believe I found a bug. I just rescued an old project and noticed all of the zener diodes were oriented 180 degrees from the unrescued version. When you get a chance, would you please verify the component orientation against the rescued library is correct. I'll commit this patch. If you find a bug, please apply the patch against this patch. Thanks, Wayne On 5/4/2015 1:30 PM, Chris Pavlina wrote: I've got two changes here - they're a bit inadvertently intertwined, so I left them as one patch, otherwise one would depend on the other anyway. Let me know if you want me to discard half. 1. Remove the summary dialog from lib-cache-rescue. I originally created it so the user would know what the new names of the components were; I compensated by changing the main dialog to display the suffix that will be added to the parts. 2. Minor bugfix: If no parts are rescued, an empty rescue library shouldn't be written. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH] Hide Power component value text cannot be modified in libedit
When I submitted the patch to allow editing power component value text properties, I didn't realize that the edit dialog base class was subclassed /twice/ - I missed a required edit to the libedit subclass of it, so the Power component value text cannot be modified! warning is not properly hidden when editing texts in libedit. Here's a quick patch to fix that. -- Chris diff --git a/eeschema/dialogs/dialog_lib_edit_text.cpp b/eeschema/dialogs/dialog_lib_edit_text.cpp index 778fa89..8d8a519 100644 --- a/eeschema/dialogs/dialog_lib_edit_text.cpp +++ b/eeschema/dialogs/dialog_lib_edit_text.cpp @@ -134,6 +134,10 @@ void DIALOG_LIB_EDIT_TEXT::initDlg( ) // Hide the select button as the child dialog classes use this m_TextValueSelectButton-Hide(); + +// Hide the Power component value text cannot be modified! warning +m_PowerComponentValues-Show( false ); +Fit(); } ___ Mailing list: https://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?] Handling conflict between projname-cache.lib and an updated library
I should add that Nick found a bug that I am working on fixing at this moment - stopped working after a certain revision when something was changed - so anyone who wants to try it, either wait for me to track down what changed or apply the patch to a revision from around the time I submitted it. I've got git-bisect compiles running in the background as I type. On Fri, Apr 10, 2015 at 07:15:00PM -0400, Wayne Stambaugh wrote: On 4/8/2015 8:48 PM, Chris Pavlina wrote: Any more devs have an opinion on this? I've already said it would be a good idea albeit a temporary one for the upcoming stable release. I just saw another reply to a bug report about someones schematic being incorrect because the library components have changed. Looking at the changes to the component libraries, it would be my guess that we will have a lot of upset users who have not upgrade from the previous stable release. Does anyone else have any opinions about this? On Mon, Mar 30, 2015 at 02:01:07PM -0400, Wayne Stambaugh wrote: On 3/30/2015 1:58 PM, Chris Pavlina wrote: On Mar 30, 2015 1:49 PM, Wayne Stambaugh stambau...@gmail.com mailto:stambau...@gmail.com wrote: Please fix your coding style issues. I saw: if( foo ) bar; should be: if( foo ) bar; Also, two blank lines between function definitions in cpp files. Oops, missed these bits of the style. Will fix by tomorrow. In the future, please do not create OnOk()/OnCancel() message handlers then call EndModal() in your dialogs. This is broken by design. Your dialog may not always be modal. It may be useful to create them as modeless or quasi-modal so calling EndModal() fail. I know it is used in virtually every dialog in KiCad and it is fundamentally wrong. The wxWidgets developers were kind enough to create all the necessary plumbing to handle this. Please read http://docs.wxwidgets.org/3.0/overview_validator.html and take look at common/dialogs/dialog_env_var_config.cpp for tips on transferring data to and from the controls using wxDialog. Oh, you'll have to forgive me, I'm a bit new to wx. Not just in the future, I'll get this fixed as well. Last thing I want to do is add broken code to KiCad. Perhaps I'll help out and start working on fixing some of the existing ones too. Thanks. Don't worry about the existing ones until after the stable release. I want to keep focused on that until it's done. Otherwise, we will just keep making changes and never get the stable release out the door. I want to let everything stabilize and make sure we get all of the bugs fixed. [snip] I need your assurance that you will see it through to the stable release before I'm willing to give it my approval. I would also appreciate if you could update the Eeschema documentation at https://github.com/ciampix/kicad-doc or have someone document it for you. What say the rest of you? Yup, plan was to see it through. I'll document it as well - just let me get these fixes implemented first. You've got plenty of time. The stable release goal is the late June/early July time frame. On 3/30/2015 11:43 AM, Chris Pavlina wrote: Well, seems I missed the freeze on this one, but I've got a patch, might as well share. Works well for me - comments welcome, of course, and ideas for more testcases. At schematic load, or when the tool is selected from the menu, the schematic is analyzed for any problematic components. These are where the component found in the cache has pins moved or changed from the one found in the system libraries. When this happens, the following dialog is displayed: https://db.tt/qIAesEQv The user can choose per symbol whether to keep the library version or the cached version. Any cached components selected for rescue are renamed to $componentname-RESCUE-$projectname and placed in a $projectname-rescue library, which is added to the project at the top of the library list. When the operation is complete, the user is presented with a nice summary of the renames done. Aliases are a tricky case, because the cached and library components don't have to have the same alias list. The simplest way I found to handle this was to break apart aliases in the -rescue library: all components are stored as single parts with no aliases. For those who don't want their hands held, there is a Never Show Again button. The setting for this can be reverted by a checkbox in Component Libraries if done by mistake. -- Chris On Mon, Mar 23, 2015 at 01:27:35PM -0400, Wayne Stambaugh wrote: On 3/23/2015 1:16 PM, Chris Pavlina wrote: On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote: On 3/23/2015 12:12 PM, Chris Pavlina wrote: I like your idea - I proposed it myself, but it was not well received ;) [[snip]] Please see the discussion here on why this will not work. https://bugs.launchpad.net/kicad/+bug/1435338 I see no point in replacing one bug with another bug that doesn't fix the underlying problem. Haha, just
[Kicad-developers] [PATCH] Correct tab order in pcbnew text properties dialog
The logical flow of the Text Properties dialog in pcbnew is vertical, not horizontal, but the wx grid control naturally arranges the widgets horizontally and the tab order follows that. This means that after Size X, [tab] moves to Position X, which is unlikely to be the next desired control. It's really annoying when editing a bunch of texts. Here's a patch that manually assigns the tab order in that dialog according to the natural flow of the controls. -- Chris diff --git a/pcbnew/dialogs/dialog_pcb_text_properties.cpp b/pcbnew/dialogs/dialog_pcb_text_properties.cpp index eca91a1..13b52f5 100644 --- a/pcbnew/dialogs/dialog_pcb_text_properties.cpp +++ b/pcbnew/dialogs/dialog_pcb_text_properties.cpp @@ -153,6 +153,18 @@ void DIALOG_PCB_TEXT_PROPERTIES::MyInit() EDA_TEXT_HJUSTIFY_T hJustify = m_SelectedPCBText-GetHorizJustify(); m_justifyChoice-SetSelection( (int) hJustify + 1 ); +// Manually set tab order +m_SizeXCtrl-MoveAfterInTabOrder( m_TextContentCtrl ); +m_SizeYCtrl-MoveAfterInTabOrder( m_SizeXCtrl ); +m_ThicknessCtrl-MoveAfterInTabOrder( m_SizeYCtrl ); +m_PositionXCtrl-MoveAfterInTabOrder( m_ThicknessCtrl ); +m_PositionYCtrl-MoveAfterInTabOrder( m_PositionXCtrl ); +m_OrientationCtrl-MoveAfterInTabOrder( m_PositionYCtrl ); +m_LayerSelectionCtrl-MoveAfterInTabOrder( m_OrientationCtrl ); +m_StyleCtrl-MoveAfterInTabOrder( m_LayerSelectionCtrl ); +m_DisplayCtrl-MoveAfterInTabOrder( m_StyleCtrl ); +m_justifyChoice-MoveAfterInTabOrder( m_DisplayCtrl ); + // Set focus on most important control m_TextContentCtrl-SetFocus(); m_TextContentCtrl-SetSelection( -1, -1 ); diff --git a/pcbnew/dialogs/dialog_pcb_text_properties_base.cpp b/pcbnew/dialogs/dialog_pcb_text_properties_base.cpp index 7473eb8..8a3f0eb 100644 --- a/pcbnew/dialogs/dialog_pcb_text_properties_base.cpp +++ b/pcbnew/dialogs/dialog_pcb_text_properties_base.cpp @@ -1,5 +1,5 @@ /// -// C++ code generated with wxFormBuilder (version Oct 8 2012) +// C++ code generated with wxFormBuilder (version Mar 13 2015) // http://www.wxformbuilder.org/ // // PLEASE DO NOT EDIT THIS FILE! diff --git a/pcbnew/dialogs/dialog_pcb_text_properties_base.fbp b/pcbnew/dialogs/dialog_pcb_text_properties_base.fbp index 22b5ab4..547aa6b 100644 --- a/pcbnew/dialogs/dialog_pcb_text_properties_base.fbp +++ b/pcbnew/dialogs/dialog_pcb_text_properties_base.fbp @@ -1,6 +1,6 @@ ?xml version=1.0 encoding=UTF-8 standalone=yes ? wxFormBuilder_Project -FileVersion major=1 minor=11 / +FileVersion major=1 minor=13 / object class=Project expanded=1 property name=class_decoration/property property name=code_generationC++/property @@ -20,8 +20,10 @@ property name=path./property property name=precompiled_header/property property name=relative_path1/property +property name=skip_lua_events1/property property name=skip_php_events1/property property name=skip_python_events1/property +property name=ui_tableUI/property property name=use_enum0/property property name=use_microsoft_bom0/property object class=Dialog expanded=1 diff --git a/pcbnew/dialogs/dialog_pcb_text_properties_base.h b/pcbnew/dialogs/dialog_pcb_text_properties_base.h index c049515..d134b4c 100644 --- a/pcbnew/dialogs/dialog_pcb_text_properties_base.h +++ b/pcbnew/dialogs/dialog_pcb_text_properties_base.h @@ -1,5 +1,5 @@ /// -// C++ code generated with wxFormBuilder (version Oct 8 2012) +// C++ code generated with wxFormBuilder (version Mar 13 2015) // http://www.wxformbuilder.org/ // // PLEASE DO NOT EDIT THIS FILE! ___ Mailing list: https://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?] Handling conflict between projname-cache.lib and an updated library
Any more devs have an opinion on this? On Mon, Mar 30, 2015 at 02:01:07PM -0400, Wayne Stambaugh wrote: On 3/30/2015 1:58 PM, Chris Pavlina wrote: On Mar 30, 2015 1:49 PM, Wayne Stambaugh stambau...@gmail.com mailto:stambau...@gmail.com wrote: Please fix your coding style issues. I saw: if( foo ) bar; should be: if( foo ) bar; Also, two blank lines between function definitions in cpp files. Oops, missed these bits of the style. Will fix by tomorrow. In the future, please do not create OnOk()/OnCancel() message handlers then call EndModal() in your dialogs. This is broken by design. Your dialog may not always be modal. It may be useful to create them as modeless or quasi-modal so calling EndModal() fail. I know it is used in virtually every dialog in KiCad and it is fundamentally wrong. The wxWidgets developers were kind enough to create all the necessary plumbing to handle this. Please read http://docs.wxwidgets.org/3.0/overview_validator.html and take look at common/dialogs/dialog_env_var_config.cpp for tips on transferring data to and from the controls using wxDialog. Oh, you'll have to forgive me, I'm a bit new to wx. Not just in the future, I'll get this fixed as well. Last thing I want to do is add broken code to KiCad. Perhaps I'll help out and start working on fixing some of the existing ones too. Thanks. Don't worry about the existing ones until after the stable release. I want to keep focused on that until it's done. Otherwise, we will just keep making changes and never get the stable release out the door. I want to let everything stabilize and make sure we get all of the bugs fixed. [snip] I need your assurance that you will see it through to the stable release before I'm willing to give it my approval. I would also appreciate if you could update the Eeschema documentation at https://github.com/ciampix/kicad-doc or have someone document it for you. What say the rest of you? Yup, plan was to see it through. I'll document it as well - just let me get these fixes implemented first. You've got plenty of time. The stable release goal is the late June/early July time frame. On 3/30/2015 11:43 AM, Chris Pavlina wrote: Well, seems I missed the freeze on this one, but I've got a patch, might as well share. Works well for me - comments welcome, of course, and ideas for more testcases. At schematic load, or when the tool is selected from the menu, the schematic is analyzed for any problematic components. These are where the component found in the cache has pins moved or changed from the one found in the system libraries. When this happens, the following dialog is displayed: https://db.tt/qIAesEQv The user can choose per symbol whether to keep the library version or the cached version. Any cached components selected for rescue are renamed to $componentname-RESCUE-$projectname and placed in a $projectname-rescue library, which is added to the project at the top of the library list. When the operation is complete, the user is presented with a nice summary of the renames done. Aliases are a tricky case, because the cached and library components don't have to have the same alias list. The simplest way I found to handle this was to break apart aliases in the -rescue library: all components are stored as single parts with no aliases. For those who don't want their hands held, there is a Never Show Again button. The setting for this can be reverted by a checkbox in Component Libraries if done by mistake. -- Chris On Mon, Mar 23, 2015 at 01:27:35PM -0400, Wayne Stambaugh wrote: On 3/23/2015 1:16 PM, Chris Pavlina wrote: On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote: On 3/23/2015 12:12 PM, Chris Pavlina wrote: I like your idea - I proposed it myself, but it was not well received ;) [[snip]] Please see the discussion here on why this will not work. https://bugs.launchpad.net/kicad/+bug/1435338 I see no point in replacing one bug with another bug that doesn't fix the underlying problem. Haha, just kidding, I know :) Rather than just copy the cache file, rename all of the footprints in the copied library with a prefix or suffix, i.e. 74LS00 in the cache becomes 74LS00_SCH in the new library. Then rename all the components in the schematic accordingly if the user chooses the new library option. This way there will be little chance of conflicting component names and the library search order is less likely to be an issue. This gives you the best of both worlds. You keep your existing components in the schematic and you can still use the updated components from the your libraries if you so choose. Obviously this still wont fix the library search ordering issue but it would be a more robust solution. Actually, I quite like this idea. I know it's more work but it solves the component name clash issues and the user will still be able to use their normal libraries
[Kicad-developers] [PATCH] User Grid dimensions don't update in GAL footprint editor
The User Grid dimension dialog in the footprint editor is missing the calls to
update the grid in GAL, so the user grid doesn't update until you switch to a
different grid and back. Here's a patch.
Chris Pavlina
(Ref. bug #1426098: https://bugs.launchpad.net/kicad/+bug/1426098)
diff --git a/pcbnew/dialogs/dialog_set_grid.cpp b/pcbnew/dialogs/dialog_set_grid.cpp
index 689b803..4821654 100644
--- a/pcbnew/dialogs/dialog_set_grid.cpp
+++ b/pcbnew/dialogs/dialog_set_grid.cpp
@@ -34,6 +34,8 @@
#include pcbnew_id.h
#include dialog_set_grid_base.h
#include invoke_pcb_dialog.h
+#include gal/graphics_abstraction_layer.h
+#include class_draw_panel_gal.h
class DIALOG_SET_GRID : public DIALOG_SET_GRID_BASE
@@ -216,12 +218,21 @@ bool PCB_BASE_FRAME::InvokeDialogGrid()
SetGridOrigin( grid_origin );
-GetScreen()-AddGrid( m_UserGridSize, m_UserGridUnit, ID_POPUP_GRID_USER );
+BASE_SCREEN* screen = GetScreen();
+
+screen-AddGrid( m_UserGridSize, m_UserGridUnit, ID_POPUP_GRID_USER );
// If the user grid is the current option, recall SetGrid()
// to force new values put in list as current grid value
-if( GetScreen()-GetGridId() == ID_POPUP_GRID_USER )
-GetScreen()-SetGrid( ID_POPUP_GRID_USER );
+if( screen-GetGridId() == ID_POPUP_GRID_USER )
+screen-SetGrid( ID_POPUP_GRID_USER );
+
+if( IsGalCanvasActive() )
+{
+GetGalCanvas()-GetGAL()-SetGridSize( VECTOR2D( screen-GetGrid().m_Size.x,
+screen-GetGrid().m_Size.y ) );
+GetGalCanvas()-GetView()-MarkTargetDirty( KIGFX::TARGET_NONCACHED );
+}
m_canvas-Refresh();
diff --git a/pcbnew/dialogs/dialog_set_grid_base.cpp b/pcbnew/dialogs/dialog_set_grid_base.cpp
index 3530f39..9f12078 100644
--- a/pcbnew/dialogs/dialog_set_grid_base.cpp
+++ b/pcbnew/dialogs/dialog_set_grid_base.cpp
@@ -1,5 +1,5 @@
///
-// C++ code generated with wxFormBuilder (version Oct 8 2012)
+// C++ code generated with wxFormBuilder (version Mar 13 2015)
// http://www.wxformbuilder.org/
//
// PLEASE DO NOT EDIT THIS FILE!
diff --git a/pcbnew/dialogs/dialog_set_grid_base.fbp b/pcbnew/dialogs/dialog_set_grid_base.fbp
index ac115f7..0679f75 100644
--- a/pcbnew/dialogs/dialog_set_grid_base.fbp
+++ b/pcbnew/dialogs/dialog_set_grid_base.fbp
@@ -1,6 +1,6 @@
?xml version=1.0 encoding=UTF-8 standalone=yes ?
wxFormBuilder_Project
-FileVersion major=1 minor=11 /
+FileVersion major=1 minor=13 /
object class=Project expanded=1
property name=class_decoration/property
property name=code_generationC++/property
@@ -20,8 +20,10 @@
property name=path./property
property name=precompiled_header/property
property name=relative_path1/property
+property name=skip_lua_events1/property
property name=skip_php_events1/property
property name=skip_python_events1/property
+property name=ui_tableUI/property
property name=use_enum0/property
property name=use_microsoft_bom0/property
object class=Dialog expanded=1
diff --git a/pcbnew/dialogs/dialog_set_grid_base.h b/pcbnew/dialogs/dialog_set_grid_base.h
index 9bb3e86..32a92c2 100644
--- a/pcbnew/dialogs/dialog_set_grid_base.h
+++ b/pcbnew/dialogs/dialog_set_grid_base.h
@@ -1,5 +1,5 @@
///
-// C++ code generated with wxFormBuilder (version Oct 8 2012)
+// C++ code generated with wxFormBuilder (version Mar 13 2015)
// http://www.wxformbuilder.org/
//
// PLEASE DO NOT EDIT THIS FILE!
___
Mailing list: https://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] eeschema sheet pin width and height are swapped
Tiny little bug in eeschema: when you set the height of a sheet pin text, it actually sets the width, and vice versa. diff --git a/eeschema/sheetlab.cpp b/eeschema/sheetlab.cpp index 9f90792..8a10319 100644 --- a/eeschema/sheetlab.cpp +++ b/eeschema/sheetlab.cpp @@ -94,8 +94,8 @@ int SCH_EDIT_FRAME::EditSheetPin( SCH_SHEET_PIN* aSheetPin, wxDC* aDC ) } aSheetPin-SetText( dlg.GetLabelName() ); -aSheetPin-SetSize( wxSize( ValueFromString( g_UserUnit, dlg.GetTextHeight() ), -ValueFromString( g_UserUnit, dlg.GetTextWidth() ) ) ); +aSheetPin-SetSize( wxSize( ValueFromString( g_UserUnit, dlg.GetTextWidth() ), +ValueFromString( g_UserUnit, dlg.GetTextHeight() ) ) ); aSheetPin-SetShape( dlg.GetConnectionType() ); if( aDC ) ___ Mailing list: https://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] Question on kicad-install.sh
Thank you.
From the original list:
1. install_prerequisites()This function is using a single command
apt-get install for ALL of the software packages. It would work
smoothly if ALL of the packages were available. Unfurtunately, in the
Ubuntu 14.04 case, python-wxgtk3.0 is not yet available and the command
will fail for ALL of the packages. Thus libwxgtk3.0-dev will not be
installed at all (which will cause another error that needs an improved
error handling. See #2).
Suggestion: Change to use a local loop to install each of the packages
so that command apt-get install fails only for a single package, thus
avoiding failing for ALL.
2. CMake check listWhen libwxgtk3.0-dev is not installed, due to the
faillure in #1 aboe, the CMake check part stops short during compiling,
but kicad-install.sh does not detect this failed compiling and just
continue to install or copy parts files and doc files into the destnated
directory. At the end, it seems all install succeeded. But there is NO
kicad binary installed at all, much less of the rest of the binaries.
This situation has caused confussions to me a few times already.
It still seems that the loop is a bit silly, though. You have to sit
there authorizing each and every install. Since python-wxgtk3.0 is
apparently optional, how about just installing *that* one individually,
and then installing the rest with a single command?
You could even test whether it's available and only attempt to install
it if it is, or perhaps print an explanation of the consequences of not
having it.
On Wed, Apr 01, 2015 at 03:34:56PM +0200, Nick Østergaard wrote:
https://lists.launchpad.net/kicad-developers/msg15134.html
2015-04-01 9:53 GMT+02:00 Nick Østergaard oe.n...@gmail.com:
Search the mailing list archive. Try to also use the keyword fedora when
searching. I am currently not on a proper machine.
Den 01/04/2015 01.48 skrev Chris Pavlina pavlina.ch...@gmail.com:
Does anyone know why kicad-install.sh does this?
for p in ${prerequisite_list}
do
sudo apt-get install $p || exit 1
done
Rather than something along the lines of this:
echo ${prerequisite_list} | xargs -d\n sudo apt-get install
The long prompts for permission to install each package have, erm,
aggravated some users, and adding -y isn't quite the right choice IMHO as it
removes the user's ability to veto the package list.
Any chance of changing it?
Chris
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Schematic Symbol Philosophy?
The assignment of footprints to schematic symbols is largely a KiCad quirk. Many other tools consider a component to be a single package containing symbol and footprint. In my own library I have a part per actual electronic part (one called MMBT3904, for instance), which already has the Footprint field set from the very beginning, no mucking about with the nightmare that is cvpcb. Also, footprints are much more critical, in that you have to get all the dimensions very correct, so it makes much more sense in terms of being less error-prone to have multiple symbols linked to one footprint than one symbol linked to multiple footprints. On Thu, Jun 04, 2015 at 10:23:40PM -0500, Adam Wolf wrote: Hi folks, I was using KiCad to make a board today (yeah, the novelty of actually *using* it!), and I noticed that there's been some changes in schematic symbols--and I'm wondering if it was on purpose. I was adding a pmos to my schematic, and I noticed there are: Q_PMOS_DGS Q_PMOS_DSG Q_PMOS_GDS Q_PMOS_GSD Q_PMOS_SDG Q_PMOS_SGD and the change is basically to change the pin numbers. Years ago, I thought it was that the schematic was a logical representation of your circuit, and the assignment of footprints to schematic symbols was where you chose parts, especially for things like fets. Is this a transitory thing, or is this the way we've chosen to set up the official kicad libraries? This isn't criticism, more something I was a little confused by and decided I'd check on. Thanks! 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
[Kicad-developers] [PATCH] Hide pin targets when properly connected
Recently a proposal was made on Launchpad for pins to indicate when they
are connected: https://bugs.launchpad.net/kicad/+bug/1458083
Sounds like a good idea to me; I recently asked on the list, and on both
list and Launchpad there is general agreement that the second proposal
(hide the pin target after the connection is made) was best. Here's a
patch to do this.
IMO it makes the schematic look a lot cleaner in addition to helping
make sure the schematic is connected correctly :)
--
Chris
commit ecbf90b995f609c5eab550e9941d4d8ed27ce2ed
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Thu Jun 4 17:53:06 2015 -0400
Do not display pin targets when pins are connected
diff --git a/eeschema/class_libentry.cpp b/eeschema/class_libentry.cpp
index 654dc74..2ba8989 100644
--- a/eeschema/class_libentry.cpp
+++ b/eeschema/class_libentry.cpp
@@ -312,7 +312,7 @@ void LIB_PART::SetName( const wxString aName )
void LIB_PART::Draw( EDA_DRAW_PANEL* aPanel, wxDC* aDc, const wxPoint aOffset, int aMulti,
int aConvert, GR_DRAWMODE aDrawMode, EDA_COLOR_T aColor,
const TRANSFORM aTransform, bool aShowPinText, bool aDrawFields,
- bool aOnlySelected )
+ bool aOnlySelected, const std::vectorbool* aPinsDangling )
{
BASE_SCREEN* screen = aPanel ? aPanel-GetScreen() : NULL;
@@ -360,6 +360,9 @@ void LIB_PART::Draw( EDA_DRAW_PANEL* aPanel, wxDC* aDc, const wxPoint aOffset,
}
}
+// Track the index into the dangling pins list
+size_t pin_index = 0;
+
BOOST_FOREACH( LIB_ITEM drawItem, drawings )
{
if( aOnlySelected !drawItem.IsSelected() )
@@ -381,8 +384,16 @@ void LIB_PART::Draw( EDA_DRAW_PANEL* aPanel, wxDC* aDc, const wxPoint aOffset,
if( drawItem.Type() == LIB_PIN_T )
{
-drawItem.Draw( aPanel, aDc, aOffset, aColor, aDrawMode, (void*) aShowPinText,
- aTransform );
+uintptr_t flags = 0;
+if( aShowPinText )
+flags |= PIN_DRAW_TEXTS;
+
+if( !aPinsDangling || (aPinsDangling-size() pin_index (*aPinsDangling)[pin_index] ) )
+flags |= PIN_DRAW_DANGLING;
+
+drawItem.Draw( aPanel, aDc, aOffset, aColor, aDrawMode, (void*) flags, aTransform );
+
+++pin_index;
}
else if( drawItem.Type() == LIB_FIELD_T )
{
diff --git a/eeschema/class_libentry.h b/eeschema/class_libentry.h
index 3d6381c..c90ddac 100644
--- a/eeschema/class_libentry.h
+++ b/eeschema/class_libentry.h
@@ -35,6 +35,7 @@
#include lib_field.h
#include boost/shared_ptr.hpp
#include boost/weak_ptr.hpp
+#include vector
class LINE_READER;
class OUTPUTFORMATTER;
@@ -418,13 +419,18 @@ public:
* the lib part fields).
* @param aOnlySelected - Draws only the body items that are selected.
*Used for block move redraws.
+ * @param aPinsDangling - if not NULL, this should be a pointer to
+ * vectorbool exactly the same length as the number of pins,
+ * indicating whether each pin is dangling. If NULL, all pins
+ * will be drawn as if they were dangling.
*/
void Draw( EDA_DRAW_PANEL* aPanel, wxDC* aDc, const wxPoint aOffset,
int aMulti, int aConvert, GR_DRAWMODE aDrawMode,
EDA_COLOR_T aColor = UNSPECIFIED_COLOR,
const TRANSFORM aTransform = DefaultTransform,
bool aShowPinText = true, bool aDrawFields = true,
- bool aOnlySelected = false );
+ bool aOnlySelected = false,
+ const std::vectorbool* aPinsDangling = NULL );
/**
* Plot lib part to plotter.
diff --git a/eeschema/lib_pin.cpp b/eeschema/lib_pin.cpp
index 4ac66f2..a8d4b10 100644
--- a/eeschema/lib_pin.cpp
+++ b/eeschema/lib_pin.cpp
@@ -875,12 +875,12 @@ void LIB_PIN::drawGraphic( EDA_DRAW_PANEL* aPanel,
aColor = GetInvisibleItemColor();
}
-// aData is used here as bool: if not null, draw pin texts
-//(i.e = true to draw pin texts, false to draw only the pin shape, which
-// is useful to draw moving component in fast mode)
-
LIB_PART* Entry = GetParent();
-bool drawPinText = aData ? true : false;
+
+// aData is used here as a bitfield of flags.
+uintptr_t flags = (uintptr_t) aData;
+bool drawPinText = flags PIN_DRAW_TEXTS;
+bool drawPinDangling = flags PIN_DRAW_DANGLING;
/* Calculate pin orient taking in account the component orientation. */
int orient = PinDrawOrient( aTransform );
@@ -889,7 +889,7 @@ void LIB_PIN::drawGraphic( EDA_DRAW_PANEL* aPanel,
wxPoint pos1 = aTransform.TransformCoordinate( m_position ) + aOffset;
/* Drawing from the pin and the special symbol combination */
-DrawPinSymbol( aPanel, aDC, pos1, orient, aDrawMode, aColor );
+DrawPinSymbol( aPanel, aDC
[Kicad-developers] [PATCH] Show targets on bus entry as well, hide when connected
Hi,
I already sent in this patch but as a reply to my existing pin targets
thread; I think it may have got lost. This patch enables pin targets
on bus entries as well, as Wayne suggested, and hides them when the bus
entry is connected.
--
Chris
commit a646e6c4b1a9ef624b4f56101d3a55f747558bf2
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Sun Jun 7 22:02:45 2015 -0400
Show targets on bus entries
diff --git a/eeschema/sch_bus_entry.cpp b/eeschema/sch_bus_entry.cpp
index 227f88a..6b3e3b6 100644
--- a/eeschema/sch_bus_entry.cpp
+++ b/eeschema/sch_bus_entry.cpp
@@ -35,6 +35,7 @@
#include common.h
#include richio.h
#include plot_common.h
+#include boost/foreach.hpp
#include eeschema_config.h
#include general.h
@@ -182,6 +183,7 @@ void SCH_BUS_ENTRY_BASE::Draw( EDA_DRAW_PANEL* aPanel, wxDC* aDC, const wxPoint
GR_DRAWMODE aDrawMode, EDA_COLOR_T aColor )
{
EDA_COLOR_T color;
+EDA_RECT* clipbox = aPanel-GetClipBox();
if( aColor = 0 )
color = aColor;
@@ -190,8 +192,16 @@ void SCH_BUS_ENTRY_BASE::Draw( EDA_DRAW_PANEL* aPanel, wxDC* aDC, const wxPoint
GRSetDrawMode( aDC, aDrawMode );
-GRLine( aPanel-GetClipBox(), aDC, m_pos.x + aOffset.x, m_pos.y + aOffset.y,
+GRLine( clipbox, aDC, m_pos.x + aOffset.x, m_pos.y + aOffset.y,
m_End().x + aOffset.x, m_End().y + aOffset.y, GetPenSize(), color );
+
+if( m_isDanglingStart ) {
+GRCircle( clipbox, aDC, m_pos.x + aOffset.x, m_pos.y + aOffset.y, TARGET_BUSENTRY_RADIUS, 0, color );
+}
+
+if( m_isDanglingEnd ) {
+GRCircle( clipbox, aDC, m_End().x + aOffset.x, m_End().y + aOffset.y, TARGET_BUSENTRY_RADIUS, 0, color );
+}
}
@@ -230,6 +240,50 @@ void SCH_BUS_ENTRY_BASE::GetEndPoints( std::vector DANGLING_END_ITEM aItemLi
}
+bool SCH_BUS_ENTRY_BASE::IsDanglingStateChanged( std::vectorDANGLING_END_ITEM aItemList )
+{
+bool previousStateStart = m_isDanglingStart;
+bool previousStateEnd = m_isDanglingEnd;
+
+m_isDanglingStart = m_isDanglingEnd = true;
+
+// Wires and buses are stored in the list as a pair, start and end. This
+// variable holds the start position from one iteration so it can be used
+// when the end position is found.
+wxPoint seg_start;
+
+BOOST_FOREACH( DANGLING_END_ITEM each_item, aItemList )
+{
+if( each_item.GetItem() == this )
+continue;
+
+switch( each_item.GetType() )
+{
+case WIRE_START_END:
+case BUS_START_END:
+seg_start = each_item.GetPosition();
+break;
+case WIRE_END_END:
+case BUS_END_END:
+if( IsPointOnSegment( seg_start, each_item.GetPosition(), m_pos ) )
+m_isDanglingStart = false;
+if( IsPointOnSegment( seg_start, each_item.GetPosition(), m_End() ) )
+m_isDanglingEnd = false;
+default:
+break;
+}
+}
+
+return (previousStateStart != m_isDanglingStart) || (previousStateEnd != m_isDanglingEnd);
+}
+
+
+bool SCH_BUS_ENTRY_BASE::IsDangling() const
+{
+return m_isDanglingStart || m_isDanglingEnd;
+}
+
+
bool SCH_BUS_ENTRY_BASE::IsSelectStateChanged( const wxRect aRect )
{
bool previousState = IsSelected();
diff --git a/eeschema/sch_bus_entry.h b/eeschema/sch_bus_entry.h
index 09e1007..5de14e6 100644
--- a/eeschema/sch_bus_entry.h
+++ b/eeschema/sch_bus_entry.h
@@ -32,6 +32,8 @@
#include sch_item_struct.h
+#define TARGET_BUSENTRY_RADIUS 12 // Circle diameter drawn at the ends
+
/**
* Class SCH_BUS_ENTRY_BASE
@@ -43,6 +45,7 @@ class SCH_BUS_ENTRY_BASE : public SCH_ITEM
protected:
wxPoint m_pos;
wxSize m_size;
+bool m_isDanglingStart, m_isDanglingEnd;
public:
SCH_BUS_ENTRY_BASE( KICAD_T aType, const wxPoint pos = wxPoint( 0, 0 ), char shape = '\\' );
@@ -100,6 +103,10 @@ public:
void GetEndPoints( std::vector DANGLING_END_ITEM aItemList );
+bool IsDanglingStateChanged( std::vectorDANGLING_END_ITEM aItemList );
+
+bool IsDangling() const;
+
bool IsSelectStateChanged( const wxRect aRect );
bool IsConnectable() const { return true; }
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Schematic Symbol Philosophy?
On Mon, Jun 08, 2015 at 11:28:08PM +0200, Heiko Rosemann wrote: A given component should have exactly ONE available footprint. If your opamp comes in PDIP-8 and SOIC-8, those are two different components. Why? There's a good point for the opposite: Making different PCBs (SMD for series production/no SMD for prototyping/hobbyists or different casings) from a single - consistent - schematic. Otherwise you are going to run into trouble because you'll have multiple schematics of the same system and you need to change something on the logical (schematic) side. I explained this already. Look at the pinouts for the different footprints of LT1013. Only a very inexperienced person would claim that assuming different footprints have the same pinout is a good idea. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH] Refresh eeschema canvas after placing part to avoid graphic debris
When you pick up a part and move it in eeschema, the canvas is not refreshed after it is placed, leaving behind graphical debris. Here's a patch that adds this refresh. Goes particularly well with my recent patch to hide the pin targets after a connection has been made, as it is much more immediately obvious now that a part has been connected. -- Chris commit 175650781ec7dd5ec51f72bbeb8d6cf8c60677fc Author: Chris Pavlina cpavl...@binghamton.edu Date: Sun Jun 7 15:18:27 2015 -0400 Refresh canvas after placing part to avoid graphic debris diff --git a/eeschema/schframe.cpp b/eeschema/schframe.cpp index a9c3290..b27cab0 100644 --- a/eeschema/schframe.cpp +++ b/eeschema/schframe.cpp @@ -1222,6 +1222,8 @@ void SCH_EDIT_FRAME::addCurrentItemToList( wxDC* aDC ) EDA_CROSS_HAIR_MANAGER( m_canvas, aDC ); // Erase schematic cursor undoItem-Draw( m_canvas, aDC, wxPoint( 0, 0 ), GR_DEFAULT_DRAWMODE ); } + +m_canvas-Refresh(); } ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Schematic Symbol Philosophy?
On Fri, Jun 05, 2015 at 02:31:06PM -0400, Wayne Stambaugh wrote: On 6/5/2015 2:00 PM, Andy Peters wrote: *snip * *snip* Trying to provide a fully defined symbol for every transistor would be a huge under taking. Our solution may not be ideal but I'm not sure I want to sift through thousands (tens of thousands?) of transistor part numbers to find what I'm looking for. You should never have to sift! We need to create a standardized way to write description that is easily searched. This is how I manage my library - it's quite large, but I know how the descriptions work and I can just start typing what I'm looking for. I wonder how well Henner's component chooser search code would handle that number of symbols. Optimize it if it can't! Searching through even *millions* of data points is a solved problem in computing. Ideally we'd have optional wildcard and regex search too - something I might be willing to contribute to in the near future. These can all be quite fast if done right. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Schematic Symbol Philosophy?
Thank you for saying this - op amps are the perfect example of why relying on standard pinouts is a *terrible* idea! Let's look at a few eight-pin DIP/SOIC/TSSOP dual op amps, shall we? TL072? out in- in+ v- in+ in- out v+ LM358? out in- in+ v- in+ in- out v+ MC33078?out in- in+ v- in+ in- out v+ NE5532? out in- in+ v- in+ in- out v+ MCP6002?out in- in+ v- in+ in- out v+ AD8552? out in- in+ v- in+ in- out v+ LF353? out in- in+ v- in+ in- out v+ LT1013*N? out in- in+ v- in+ in- out v+ LT1013*S? in+ v- in+ in- out v+ out in- See the problem? On Fri, Jun 05, 2015 at 08:46:26PM +0200, Lorenzo Marcantonio wrote: On Fri, Jun 05, 2015 at 11:08:19AM -0700, Andy Peters wrote: I realize that there’s an argument that goes, “Well, the library will be super big if we want to support all of the possible transistors out there.” And that argument is silly. Does anyone use a generic op-amp symbol instead of placing a TL072ACD (there it is again, symbol name calling out footprint!) on the schematic? No, of course not. So why is that OK for transistors? I do that actually before chosing the op amp:D industry standard pinouts are useful, and the dual amp is the perfect example! -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://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] compile broken on clang - overload conflict
Nope, using a by-reference parameter does not appease clang; no idea about MSVC. On Mon, Jun 08, 2015 at 09:15:16AM -0400, Wayne Stambaugh wrote: On 6/8/2015 8:58 AM, Chris Pavlina wrote: It can't and it shouldn't - gcc is the one at fault here. wxString provides the constructor: wxString(char ch, size_t nRepeat=1) which is the one in question, I believe, as the integer literal can also represent a character. Using a reference should work too, though changing the name is a more common solution (and better IMHO) particularly considering the two methods do provide slightly different functions. I would think that searching a list with a string vs. an index is pretty self explanatory but maybe I've been doing this too long :) Apparently MSVC won't compile it either. On Mon, Jun 08, 2015 at 08:50:15AM -0400, Wayne Stambaugh wrote: Really! Clang can't differentiate between SCH_SHEET_LIST::GetSheet(const wxString, bool); and SCH_SHEET_LIST::GetSheet(int); How can these two definitions be ambiguous? Does using a reference to the wxString instead of passing the entire string on the stack fix the problem? If so, I would prefer that fix. On 6/7/2015 9:17 PM, Chris Pavlina wrote: 5720 broke the build on clang by making SCH_SHEET_LIST::GetSheet(int) a const method, which changed the overload resolution order and resulted in failure due to ambiguity. This patch ranames SCH_SHEET_LIST::GetSheet(const wxString, bool) to ::GetSheetByPath to resolve that conflict. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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] compile broken on clang - overload conflict
One is a search and the other is a direct access by index. It's an academic discussion anyway - as long as the conflict is resolved somehow so that kicad compiling doesn't depend on a gcc quirk, I'm happy. On Mon, Jun 08, 2015 at 09:15:16AM -0400, Wayne Stambaugh wrote: On 6/8/2015 8:58 AM, Chris Pavlina wrote: It can't and it shouldn't - gcc is the one at fault here. wxString provides the constructor: wxString(char ch, size_t nRepeat=1) which is the one in question, I believe, as the integer literal can also represent a character. Using a reference should work too, though changing the name is a more common solution (and better IMHO) particularly considering the two methods do provide slightly different functions. I would think that searching a list with a string vs. an index is pretty self explanatory but maybe I've been doing this too long :) Apparently MSVC won't compile it either. On Mon, Jun 08, 2015 at 08:50:15AM -0400, Wayne Stambaugh wrote: Really! Clang can't differentiate between SCH_SHEET_LIST::GetSheet(const wxString, bool); and SCH_SHEET_LIST::GetSheet(int); How can these two definitions be ambiguous? Does using a reference to the wxString instead of passing the entire string on the stack fix the problem? If so, I would prefer that fix. On 6/7/2015 9:17 PM, Chris Pavlina wrote: 5720 broke the build on clang by making SCH_SHEET_LIST::GetSheet(int) a const method, which changed the overload resolution order and resulted in failure due to ambiguity. This patch ranames SCH_SHEET_LIST::GetSheet(const wxString, bool) to ::GetSheetByPath to resolve that conflict. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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] compile broken on clang - overload conflict
It can't and it shouldn't - gcc is the one at fault here. wxString provides the constructor: wxString(char ch, size_t nRepeat=1) which is the one in question, I believe, as the integer literal can also represent a character. Using a reference should work too, though changing the name is a more common solution (and better IMHO) particularly considering the two methods do provide slightly different functions. Apparently MSVC won't compile it either. On Mon, Jun 08, 2015 at 08:50:15AM -0400, Wayne Stambaugh wrote: Really! Clang can't differentiate between SCH_SHEET_LIST::GetSheet(const wxString, bool); and SCH_SHEET_LIST::GetSheet(int); How can these two definitions be ambiguous? Does using a reference to the wxString instead of passing the entire string on the stack fix the problem? If so, I would prefer that fix. On 6/7/2015 9:17 PM, Chris Pavlina wrote: 5720 broke the build on clang by making SCH_SHEET_LIST::GetSheet(int) a const method, which changed the overload resolution order and resulted in failure due to ambiguity. This patch ranames SCH_SHEET_LIST::GetSheet(const wxString, bool) to ::GetSheetByPath to resolve that conflict. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Hide pin targets when properly connected
Also keep in mind that the standard is pay-to-access. That's not fit for an open-source project. I rather suspect it would be frowned upon if we were to buy a copy and then put it into the documentation for all to access - and if we don't, how can we follow it? Forget the damn standard. Make our own, if need be. On Mon, Jun 08, 2015 at 08:58:50AM -0400, Wayne Stambaugh wrote: Let's not get too hung up on EN60617-3. I really don't care if KiCad is compliant to some standard other than exporting to third party file formats. What I do care about is the user experience. If the goal is to make it obvious to the user (IMO a good thing) that a schematic connection is or is not made, then I would rather do what makes the best user experience rather than follow some standard generated by government body and/or committee. On 6/8/2015 8:25 AM, Chris Pavlina wrote: 60617-3 allows a dotless junction (as in 03-02-06), but the same connection can be represented with two 03-02-05; it is not a violation of the standard to always use dots. On Mon, Jun 08, 2015 at 08:48:12AM +0300, Vesa Solonen wrote: 08/06/15, 00:44, Wayne Stambaugh kirjoitti: One thing I did notice is that bus entries do not draw the connection point so they cannot show their connection status. It would be nice if bus entries exhibited the same behavior. I'm not sure how much work would be involved. I'm surprised I never noticed that before or AFAIR no one has every said anything about it. Are you guys aware that to support both options in EN 60617-3 (1997) [symbols 03-02-04 to 03-02-07] the connection point must only be drawn when the connection is in crossing or identical branching [symbol 03-02-09] wires/buses? Otherwise it should be an user configurable option. Maybe Kicad could use the same end-centered ring hint for all open connections in addition to pins, also while drawing wires and buses. -Vesa ___ Mailing list: https://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] Hide pin targets when properly connected
60617-3 allows a dotless junction (as in 03-02-06), but the same connection can be represented with two 03-02-05; it is not a violation of the standard to always use dots. On Mon, Jun 08, 2015 at 08:48:12AM +0300, Vesa Solonen wrote: 08/06/15, 00:44, Wayne Stambaugh kirjoitti: One thing I did notice is that bus entries do not draw the connection point so they cannot show their connection status. It would be nice if bus entries exhibited the same behavior. I'm not sure how much work would be involved. I'm surprised I never noticed that before or AFAIR no one has every said anything about it. Are you guys aware that to support both options in EN 60617-3 (1997) [symbols 03-02-04 to 03-02-07] the connection point must only be drawn when the connection is in crossing or identical branching [symbol 03-02-09] wires/buses? Otherwise it should be an user configurable option. Maybe Kicad could use the same end-centered ring hint for all open connections in addition to pins, also while drawing wires and buses. -Vesa ___ Mailing list: https://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] Hide pin targets when properly connected
Yes, but we are not a small group, we are everybody who can contribute. How can an open source project implement/follow a standard when it can't make that standard available to its contributors? On Mon, Jun 08, 2015 at 05:34:46PM +0300, Vesa Solonen wrote: I generally agree with both of you, but if Kicad wants to be a serious tool for documentation it has to support EN60617 pretty well. No company can use it for official documentation and certainly some one guy design offices will lose bids if they can not fullfill customer requirement of EN60617 compliant schematics... It certainly will be frowned upon if we copied the standard, but making a component library or software functionality according to one is certainly not copying, but implementing the standard. I havent read the fine print regarding implementation fee, but somehow I suspect every screw made to DIN913 has to pay either. -Vesa ___ Mailing list: https://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] GAL arc-drawing crash
It seems to me that it should be 100% reproducible, but there's only one specific way to trigger it, perhaps you're not doing it right? Here's what I did: 1. In GAL, select the arc tool. 2. Click to set the midpoint. 3. Move directly left to set the radius and startpoint. 4. Move directly left from there, so that the angle is zero, the mouse click is outside the arc radius, and the center, startpoint and click point are collinear. 5. Click to end the arc. AFAIK putting the click-point inside the radius works too, but the three must be perfectly collinear and the click-point must not be *on* the arc. On Tue, Jun 02, 2015 at 08:19:46PM +0200, Maciej Sumiński wrote: Hi Chris, I could not reproduce the assert, but your patch surely will not harm the code, so there are chances it is going to work better. Thank you, I committed your changes in revision 5695. Regards, Orson On 06/02/2015 05:44 PM, Chris Pavlina wrote: In GAL, an assertion (drawing_tool.cpp:925) will fail if you begin drawing an arc, and then accidentally terminate the arc at zero angle with the cursor /outside/ the arc radius. It seems that an attempt was made to check for this but the conditional wasn't written quite right. Here's a patch to fix the conditional and correctly cancel terminating the arc instead. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Show targets on bus entry as well, hide when connected
I'm not sure about that one - it's common to draw buses in a manner that leaves their ends open. On Tue, Jun 09, 2015 at 01:43:56PM -0400, Wayne Stambaugh wrote: I've tried this patch and it works as expected. Good work Chris. Does anyone have any objections to this patch before I commit it? One other thing I noticed is the bus wires (and I'm guessing bus entries as well) do not have any segment end point connection indicators. It would be nice if they supported them as well. On 6/8/2015 5:38 PM, Chris Pavlina wrote: Hi, I already sent in this patch but as a reply to my existing pin targets thread; I think it may have got lost. This patch enables pin targets on bus entries as well, as Wayne suggested, and hides them when the bus entry is connected. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Show targets on bus entry as well, hide when connected
Okay, I see what you're talking about in the video demo. Here's a quick screenshot for those who want to follow along: http://misc.c4757p.com/video-demo-block.png Simply put, those wires ARE being displayed correctly. The *ends* *are* dangling. Nothing is connected to them. There is no possible way I could write a test that detects that a label is on the wire and somehow decides which end to associate it with, hiding the target. The point of hiding the targets is to show that *that* connection point is correctly in use. These are not in use, so why hide the target? The equivalent here is the target on the label itself, which has always hidden when connected. If you're going to use labels to make connections, and want the targets to disappear, then you'll have to place the label target on the wire target. This is the same as for pins, if you stick a pin in the middle of a wire and connect it with a junction, the *end* of the wire is still not connected. I think this is correct behavior. On Tue, Jun 09, 2015 at 03:33:56PM -0400, Wayne Stambaugh wrote: How does this bus connect to another bus without a label that looks something like A[19..32] on other open ended buses? Unless the bus is directly connected I believe the label is required. FYI. I need to get my eyes checked. If a wire doesn't end on the label connection point, then open ended wires are shown as unconnected. It looks the dangling end test is in need of some improvement. Again, see the video demo. There are examples of both cases. On 6/9/2015 3:24 PM, Chris Pavlina wrote: No, I just mean things like this: http://misc.c4757p.com/bus.png The bus is very frequently drawn past the end of a row of connections to emphasize the fact that it is a bus. (Imagine the bit going off to the right goes somewhere else.) On Tue, Jun 09, 2015 at 03:17:52PM -0400, Wayne Stambaugh wrote: Yes, but typically in open ended bus use case they have a label attached to them that makes the connection. The same thing can be done with wires which does show the connection status correctly when a wire is open ended but has a label attached to it. The video demo project is a good example of both behaviors. It's not that important but some users may wonder why the difference between wire and bus connections. It's something to think about. On 6/9/2015 2:30 PM, Chris Pavlina wrote: I'm not sure about that one - it's common to draw buses in a manner that leaves their ends open. On Tue, Jun 09, 2015 at 01:43:56PM -0400, Wayne Stambaugh wrote: I've tried this patch and it works as expected. Good work Chris. Does anyone have any objections to this patch before I commit it? One other thing I noticed is the bus wires (and I'm guessing bus entries as well) do not have any segment end point connection indicators. It would be nice if they supported them as well. On 6/8/2015 5:38 PM, Chris Pavlina wrote: Hi, I already sent in this patch but as a reply to my existing pin targets thread; I think it may have got lost. This patch enables pin targets on bus entries as well, as Wayne suggested, and hides them when the bus entry is connected. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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
Re: [Kicad-developers] [PATCH] Show targets on bus entry as well, hide when connected
On Tue, Jun 09, 2015 at 03:33:56PM -0400, Wayne Stambaugh wrote: How does this bus connect to another bus without a label that looks something like A[19..32] on other open ended buses? Unless the bus is directly connected I believe the label is required. I said Imagine the bit going off to the right goes somewhere else. - i.e., it is directly connected. FYI. I need to get my eyes checked. If a wire doesn't end on the label connection point, then open ended wires are shown as unconnected. It looks the dangling end test is in need of some improvement. Again, see the video demo. There are examples of both cases. I don't see the problem, can you give me a more specific example? On 6/9/2015 3:24 PM, Chris Pavlina wrote: No, I just mean things like this: http://misc.c4757p.com/bus.png The bus is very frequently drawn past the end of a row of connections to emphasize the fact that it is a bus. (Imagine the bit going off to the right goes somewhere else.) On Tue, Jun 09, 2015 at 03:17:52PM -0400, Wayne Stambaugh wrote: Yes, but typically in open ended bus use case they have a label attached to them that makes the connection. The same thing can be done with wires which does show the connection status correctly when a wire is open ended but has a label attached to it. The video demo project is a good example of both behaviors. It's not that important but some users may wonder why the difference between wire and bus connections. It's something to think about. On 6/9/2015 2:30 PM, Chris Pavlina wrote: I'm not sure about that one - it's common to draw buses in a manner that leaves their ends open. On Tue, Jun 09, 2015 at 01:43:56PM -0400, Wayne Stambaugh wrote: I've tried this patch and it works as expected. Good work Chris. Does anyone have any objections to this patch before I commit it? One other thing I noticed is the bus wires (and I'm guessing bus entries as well) do not have any segment end point connection indicators. It would be nice if they supported them as well. On 6/8/2015 5:38 PM, Chris Pavlina wrote: Hi, I already sent in this patch but as a reply to my existing pin targets thread; I think it may have got lost. This patch enables pin targets on bus entries as well, as Wayne suggested, and hides them when the bus entry is connected. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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
[Kicad-developers] [PATCH] Fix: Also hide pin targets for junction dots
Bit of a bug in my pin target hiding code: junction dots on pins should also hide the target. I forgot you can connect them that way. http://misc.c4757p.com/target_hide_bug.png This patch fixes that. -- Chris commit 7a5c65519bfa49ebc25a2c50c89d0f53ff2c86e4 Author: Chris Pavlina cpavl...@binghamton.edu Date: Wed Jun 10 09:55:23 2015 -0400 Bugfix: also hide pin targets for junction dots diff --git a/eeschema/sch_component.cpp b/eeschema/sch_component.cpp index 502f980..dbe2f81 100644 --- a/eeschema/sch_component.cpp +++ b/eeschema/sch_component.cpp @@ -1658,6 +1658,7 @@ bool SCH_COMPONENT::IsPinDanglingStateChanged( std::vectorDANGLING_END_ITEM a case WIRE_START_END: case WIRE_END_END: case NO_CONNECT_END: +case JUNCTION_END: if( pin_position == each_item.GetPosition() ) m_isDangling[aPin] = false; break; ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Show targets on bus entry as well, hide when connected
No, I just mean things like this: http://misc.c4757p.com/bus.png The bus is very frequently drawn past the end of a row of connections to emphasize the fact that it is a bus. (Imagine the bit going off to the right goes somewhere else.) On Tue, Jun 09, 2015 at 03:17:52PM -0400, Wayne Stambaugh wrote: Yes, but typically in open ended bus use case they have a label attached to them that makes the connection. The same thing can be done with wires which does show the connection status correctly when a wire is open ended but has a label attached to it. The video demo project is a good example of both behaviors. It's not that important but some users may wonder why the difference between wire and bus connections. It's something to think about. On 6/9/2015 2:30 PM, Chris Pavlina wrote: I'm not sure about that one - it's common to draw buses in a manner that leaves their ends open. On Tue, Jun 09, 2015 at 01:43:56PM -0400, Wayne Stambaugh wrote: I've tried this patch and it works as expected. Good work Chris. Does anyone have any objections to this patch before I commit it? One other thing I noticed is the bus wires (and I'm guessing bus entries as well) do not have any segment end point connection indicators. It would be nice if they supported them as well. On 6/8/2015 5:38 PM, Chris Pavlina wrote: Hi, I already sent in this patch but as a reply to my existing pin targets thread; I think it may have got lost. This patch enables pin targets on bus entries as well, as Wayne suggested, and hides them when the bus entry is connected. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Show targets on bus entry as well, hide when connected
Ah, but what of the possibility to make more than two connections on a wire? You could connect both endpoints and still put a label on the wire! Interesting to think about, but it seems to me that if you go for logical connections instead of purely graphical ones, you're opening up a huge can of complex worms. Suppose I have a wire that is disconnected at both ends and then I place a label in the middle. Which target should disappear? Suppose I have a wire that goes to a pin at one end, and I place a label in the middle. The target at the other end disappears, but now I have nothing indicating whether the /third/ connection that I intended to make (which the connection algorithm didn't know about) was successful. The targets indicating connection only for that exact graphical point is the way most software packages would handle this, and I think the way most users will expect. On Tue, Jun 09, 2015 at 07:44:37PM -0400, Wayne Stambaugh wrote: On 6/9/2015 4:45 PM, Chris Pavlina wrote: Okay, I see what you're talking about in the video demo. Here's a quick screenshot for those who want to follow along: http://misc.c4757p.com/video-demo-block.png Simply put, those wires ARE being displayed correctly. The *ends* *are* dangling. Nothing is connected to them. There is no possible way I could write a test that detects that a label is on the wire and somehow decides which end to associate it with, hiding the target. This depends on your definition of dangling end. If you mean there is no graphical item connection, then wires shown are dangling. However, if by dangling end you mean no electrical connection (net), then these wires are not dangling. They are connected by net to another wire/label/pin combination which yields a valid net. In this case the test code is the same code that generates the net list. It's fine for now and I'm not looking for you to make this change. I just wanted to get you thinking about what connection really means in a schematic. The point of hiding the targets is to show that *that* connection point is correctly in use. These are not in use, so why hide the target? The equivalent here is the target on the label itself, which has always hidden when connected. If you're going to use labels to make connections, and want the targets to disappear, then you'll have to place the label target on the wire target. This is the same as for pins, if you stick a pin in the middle of a wire and connect it with a junction, the *end* of the wire is still not connected. I think this is correct behavior. On Tue, Jun 09, 2015 at 03:33:56PM -0400, Wayne Stambaugh wrote: How does this bus connect to another bus without a label that looks something like A[19..32] on other open ended buses? Unless the bus is directly connected I believe the label is required. FYI. I need to get my eyes checked. If a wire doesn't end on the label connection point, then open ended wires are shown as unconnected. It looks the dangling end test is in need of some improvement. Again, see the video demo. There are examples of both cases. On 6/9/2015 3:24 PM, Chris Pavlina wrote: No, I just mean things like this: http://misc.c4757p.com/bus.png The bus is very frequently drawn past the end of a row of connections to emphasize the fact that it is a bus. (Imagine the bit going off to the right goes somewhere else.) On Tue, Jun 09, 2015 at 03:17:52PM -0400, Wayne Stambaugh wrote: Yes, but typically in open ended bus use case they have a label attached to them that makes the connection. The same thing can be done with wires which does show the connection status correctly when a wire is open ended but has a label attached to it. The video demo project is a good example of both behaviors. It's not that important but some users may wonder why the difference between wire and bus connections. It's something to think about. On 6/9/2015 2:30 PM, Chris Pavlina wrote: I'm not sure about that one - it's common to draw buses in a manner that leaves their ends open. On Tue, Jun 09, 2015 at 01:43:56PM -0400, Wayne Stambaugh wrote: I've tried this patch and it works as expected. Good work Chris. Does anyone have any objections to this patch before I commit it? One other thing I noticed is the bus wires (and I'm guessing bus entries as well) do not have any segment end point connection indicators. It would be nice if they supported them as well. On 6/8/2015 5:38 PM, Chris Pavlina wrote: Hi, I already sent in this patch but as a reply to my existing pin targets thread; I think it may have got lost. This patch enables pin targets on bus entries as well, as Wayne suggested, and hides them when the bus entry is connected. -- Chris ___ Mailing list: https://launchpad.net/~kicad
Re: [Kicad-developers] [PATCH] Hide pin targets when properly connected
I could add this too. On Sun, Jun 07, 2015 at 05:44:09PM -0400, Wayne Stambaugh wrote: One thing I did notice is that bus entries do not draw the connection point so they cannot show their connection status. It would be nice if bus entries exhibited the same behavior. I'm not sure how much work would be involved. I'm surprised I never noticed that before or AFAIR no one has every said anything about it. On 6/4/2015 6:21 PM, Chris Pavlina wrote: Recently a proposal was made on Launchpad for pins to indicate when they are connected: https://bugs.launchpad.net/kicad/+bug/1458083 Sounds like a good idea to me; I recently asked on the list, and on both list and Launchpad there is general agreement that the second proposal (hide the pin target after the connection is made) was best. Here's a patch to do this. IMO it makes the schematic look a lot cleaner in addition to helping make sure the schematic is connected correctly :) -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH] pcbnew crashes when loading file with bad net ID
If you try to load a kicad_pcb into pcbnew that refers to an invalid net
ID, pcbnew crashes after failing an assertion. It should display an
error indicating that the file is corrupt instead. I've changed
BOARD_CONNECTED_ITEM::SetNetCode() to be able to indicate whether the
code was valid, rather than just asserting, and then changed
PCB_PARSER::parseTRACK() to check for this and complain using
Expecting().
I'd rather have used an exception to do this, but we don't have any
exception types that look suitable. Thoughts?
Here's a board file that causes this:
http://misc.c4757p.com/2VB701E.kicad_pcb
--
Chris
diff --git a/pcbnew/class_board_connected_item.cpp b/pcbnew/class_board_connected_item.cpp
index 797e2ee..82a2153 100644
--- a/pcbnew/class_board_connected_item.cpp
+++ b/pcbnew/class_board_connected_item.cpp
@@ -48,7 +48,7 @@ BOARD_CONNECTED_ITEM::BOARD_CONNECTED_ITEM( const BOARD_CONNECTED_ITEM aItem )
}
-void BOARD_CONNECTED_ITEM::SetNetCode( int aNetCode )
+bool BOARD_CONNECTED_ITEM::SetNetCode( int aNetCode, bool aNoAssert )
{
// if aNetCode 0 ( typically NETINFO_LIST::FORCE_ORPHANED )
// or no parent board,
@@ -61,7 +61,9 @@ void BOARD_CONNECTED_ITEM::SetNetCode( int aNetCode )
else
m_netinfo = NETINFO_LIST::ORPHANED;
-assert( m_netinfo );
+if( !aNoAssert )
+assert( m_netinfo );
+return m_netinfo;
}
diff --git a/pcbnew/class_board_connected_item.h b/pcbnew/class_board_connected_item.h
index 15dfe31..fea4554 100644
--- a/pcbnew/class_board_connected_item.h
+++ b/pcbnew/class_board_connected_item.h
@@ -104,9 +104,11 @@ public:
* Function SetNetCode
* sets net using a net code.
* @param aNetCode is a net code for the new net. It has to exist in NETINFO_LIST held by BOARD.
+ * @param aNoAssert if true, do not assert that the net exists.
* Otherwise, item is assigned to the unconnected net.
+ * @return true on success, false if the net did not exist
*/
-void SetNetCode( int aNetCode );
+bool SetNetCode( int aNetCode, bool aNoAssert=false );
/**
* Function GetSubNet
diff --git a/pcbnew/pcb_parser.cpp b/pcbnew/pcb_parser.cpp
index c9a2e42..a7ede89 100644
--- a/pcbnew/pcb_parser.cpp
+++ b/pcbnew/pcb_parser.cpp
@@ -2408,7 +2408,8 @@ TRACK* PCB_PARSER::parseTRACK() throw( IO_ERROR, PARSE_ERROR )
break;
case T_net:
-track-SetNetCode( getNetCode( parseInt( net number ) ) );
+if( ! track-SetNetCode( getNetCode( parseInt( net number ) ), /* aNoAssert */ true ) )
+Expecting( valid net ID );
break;
case T_tstamp:
___
Mailing list: https://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] compile broken on clang - overload conflict
5720 broke the build on clang by making SCH_SHEET_LIST::GetSheet(int) a
const method, which changed the overload resolution order and resulted
in failure due to ambiguity. This patch ranames
SCH_SHEET_LIST::GetSheet(const wxString, bool) to ::GetSheetByPath to
resolve that conflict.
--
Chris
commit e950b692b8985c1c5037999b3f6936f1d1c993d3
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Sun Jun 7 21:14:07 2015 -0400
Resolve clang overload conflict
diff --git a/eeschema/find.cpp b/eeschema/find.cpp
index 74801bf..2d4b55c 100644
--- a/eeschema/find.cpp
+++ b/eeschema/find.cpp
@@ -366,7 +366,7 @@ void SCH_EDIT_FRAME::OnFindReplace( wxFindDialogEvent aEvent )
SetUndoItem( undoItem );
-sheet = schematic.GetSheet( data.GetSheetPath() );
+sheet = schematic.GetSheetByPath( data.GetSheetPath() );
wxCHECK_RET( sheet != NULL, wxT( Could not find sheet path ) + data.GetSheetPath() );
@@ -396,7 +396,7 @@ void SCH_EDIT_FRAME::OnFindReplace( wxFindDialogEvent aEvent )
SetUndoItem( undoItem );
-sheet = schematic.GetSheet( data.GetSheetPath() );
+sheet = schematic.GetSheetByPath( data.GetSheetPath() );
wxCHECK_RET( sheet != NULL, wxT( Could not find sheet path ) + data.GetSheetPath() );
@@ -429,7 +429,7 @@ void SCH_EDIT_FRAME::updateFindReplaceView( wxFindDialogEvent aEvent )
{
wxLogTrace( traceFindReplace, wxT( Found ) + m_foundItems.GetText() );
-SCH_SHEET_PATH* sheet = schematic.GetSheet( data.GetSheetPath() );
+SCH_SHEET_PATH* sheet = schematic.GetSheetByPath( data.GetSheetPath() );
wxCHECK_RET( sheet != NULL, wxT( Could not find sheet path ) +
data.GetSheetPath() );
diff --git a/eeschema/sch_sheet_path.cpp b/eeschema/sch_sheet_path.cpp
index 3fa59f3..52027e3 100644
--- a/eeschema/sch_sheet_path.cpp
+++ b/eeschema/sch_sheet_path.cpp
@@ -624,7 +624,7 @@ SCH_SHEET_PATH* SCH_SHEET_LIST::GetSheet( int aIndex ) const
}
-SCH_SHEET_PATH* SCH_SHEET_LIST::GetSheet( const wxString aPath, bool aHumanReadable )
+SCH_SHEET_PATH* SCH_SHEET_LIST::GetSheetByPath( const wxString aPath, bool aHumanReadable )
{
SCH_SHEET_PATH* sheet = GetFirst();
wxString sheetPath;
diff --git a/eeschema/sch_sheet_path.h b/eeschema/sch_sheet_path.h
index 0afdc6a..5cd60bc 100644
--- a/eeschema/sch_sheet_path.h
+++ b/eeschema/sch_sheet_path.h
@@ -423,7 +423,7 @@ public:
SCH_SHEET_PATH* GetSheet( int aIndex ) const;
/**
- * Function GetSheet
+ * Function GetSheetByPath
* returns a sheet matching the path name in \a aPath.
*
* @param aPath A wxString object containing path of the sheet to get.
@@ -432,7 +432,7 @@ public:
* @return The sheet that matches \a aPath or NULL if no sheet matching
* \a aPath is found.
*/
-SCH_SHEET_PATH* GetSheet( const wxString aPath, bool aHumanReadable = true );
+SCH_SHEET_PATH* GetSheetByPath( const wxString aPath, bool aHumanReadable = true );
/**
* Function IsModified
___
Mailing list: https://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] Hide pin targets when properly connected
Almost no work at all - here you go.
On Sun, Jun 07, 2015 at 07:49:58PM -0400, Wayne Stambaugh wrote:
If you have the time and can get too it in the not too distant future,
then please do. I think this would be a nice addition to your patch. I
will go ahead and commit this patch along with the refresh patch that
goes along with it for now.
On 6/7/2015 6:14 PM, Chris Pavlina wrote:
I could add this too.
On Sun, Jun 07, 2015 at 05:44:09PM -0400, Wayne Stambaugh wrote:
One thing I did notice is that bus entries do not draw the connection
point so they cannot show their connection status. It would be nice if
bus entries exhibited the same behavior. I'm not sure how much work
would be involved. I'm surprised I never noticed that before or AFAIR
no one has every said anything about it.
On 6/4/2015 6:21 PM, Chris Pavlina wrote:
Recently a proposal was made on Launchpad for pins to indicate when they
are connected: https://bugs.launchpad.net/kicad/+bug/1458083
Sounds like a good idea to me; I recently asked on the list, and on both
list and Launchpad there is general agreement that the second proposal
(hide the pin target after the connection is made) was best. Here's a
patch to do this.
IMO it makes the schematic look a lot cleaner in addition to helping
make sure the schematic is connected correctly :)
--
Chris
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
commit a646e6c4b1a9ef624b4f56101d3a55f747558bf2
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Sun Jun 7 22:02:45 2015 -0400
Show targets on bus entries
diff --git a/eeschema/sch_bus_entry.cpp b/eeschema/sch_bus_entry.cpp
index 227f88a..6b3e3b6 100644
--- a/eeschema/sch_bus_entry.cpp
+++ b/eeschema/sch_bus_entry.cpp
@@ -35,6 +35,7 @@
#include common.h
#include richio.h
#include plot_common.h
+#include boost/foreach.hpp
#include eeschema_config.h
#include general.h
@@ -182,6 +183,7 @@ void SCH_BUS_ENTRY_BASE::Draw( EDA_DRAW_PANEL* aPanel, wxDC* aDC, const wxPoint
GR_DRAWMODE aDrawMode, EDA_COLOR_T aColor )
{
EDA_COLOR_T color;
+EDA_RECT* clipbox = aPanel-GetClipBox();
if( aColor = 0 )
color = aColor;
@@ -190,8 +192,16 @@ void SCH_BUS_ENTRY_BASE::Draw( EDA_DRAW_PANEL* aPanel, wxDC* aDC, const wxPoint
GRSetDrawMode( aDC, aDrawMode );
-GRLine( aPanel-GetClipBox(), aDC, m_pos.x + aOffset.x, m_pos.y + aOffset.y,
+GRLine( clipbox, aDC, m_pos.x + aOffset.x, m_pos.y + aOffset.y,
m_End().x + aOffset.x, m_End().y + aOffset.y, GetPenSize(), color );
+
+if( m_isDanglingStart ) {
+GRCircle( clipbox, aDC, m_pos.x + aOffset.x, m_pos.y + aOffset.y, TARGET_BUSENTRY_RADIUS, 0, color );
+}
+
+if( m_isDanglingEnd ) {
+GRCircle( clipbox, aDC, m_End().x + aOffset.x, m_End().y + aOffset.y, TARGET_BUSENTRY_RADIUS, 0, color );
+}
}
@@ -230,6 +240,50 @@ void SCH_BUS_ENTRY_BASE::GetEndPoints( std::vector DANGLING_END_ITEM aItemLi
}
+bool SCH_BUS_ENTRY_BASE::IsDanglingStateChanged( std::vectorDANGLING_END_ITEM aItemList )
+{
+bool previousStateStart = m_isDanglingStart;
+bool previousStateEnd = m_isDanglingEnd;
+
+m_isDanglingStart = m_isDanglingEnd = true;
+
+// Wires and buses are stored in the list as a pair, start and end. This
+// variable holds the start position from one iteration so it can be used
+// when the end position is found.
+wxPoint seg_start;
+
+BOOST_FOREACH( DANGLING_END_ITEM each_item, aItemList )
+{
+if( each_item.GetItem() == this )
+continue;
+
+switch( each_item.GetType() )
+{
+case WIRE_START_END:
+case BUS_START_END:
+seg_start = each_item.GetPosition();
+break;
+case WIRE_END_END:
+case BUS_END_END:
+if( IsPointOnSegment( seg_start, each_item.GetPosition(), m_pos
Re: [Kicad-developers] Build failed in Jenkins: kicad-noscript-fedora20 #421
Oh look, another stupid mistake. **hands in C++ card** I'll get a patch in soon, working on fixing another bug right now. I see the problem. -- Chris On Mon, Jun 22, 2015 at 12:35:35PM -0400, Wayne Stambaugh wrote: Chris, Would you please take a look at this when you get a chance? Thanks, Wayne On 6/21/2015 7:51 PM, Miguel Angel Ajo wrote: See http://ci.kicad-pcb.org/job/kicad-noscript-fedora20/421/changes Changes: [Wayne Stambaugh] Eeschema: component library rescue improvements. * Fix case sensitive component library name searches * Factor out rescue code into a generic rescue project class. -- Started by upstream project kicad-full build number 524 originally caused by: Started by an SCM change Building remotely on fedora21 in workspace http://ci.kicad-pcb.org/job/kicad-noscript-fedora20/ws/ $ bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-noscript-fedora20/ws/ info result: bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-noscript-fedora20/ws/ returned 0. Command output: 5802 maciej.sumin...@cern.ch-20150622122440-f6j78o9jc867dl80 stderr: [kicad-noscript-fedora20] $ bzr pull --overwrite lp:kicad You have not informed bzr of your Launchpad ID, and you must do this to write to Launchpad or access private data. See bzr help launchpad-login. http://bazaar.launchpad.net/~kicad-product-committers/kicad/product is permanently redirected to http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/changes You have not informed bzr of your Launchpad ID, and you must do this to write to Launchpad or access private data. See bzr help launchpad-login. +N eeschema/project_rescue.cpp +N eeschema/project_rescue.h M eeschema/CMakeLists.txt M eeschema/class_library.cpp M eeschema/dialogs/dialog_rescue_each.cpp M eeschema/dialogs/dialog_rescue_each_base.cpp M eeschema/dialogs/dialog_rescue_each_base.fbp M eeschema/files-io.cpp M eeschema/invoke_sch_dialog.h -D eeschema/lib_cache_rescue.cpp -D eeschema/lib_cache_rescue.h M eeschema/menubar.cpp M eeschema/schframe.cpp M eeschema/schframe.h All changes applied successfully. Now on revision 5803. [kicad-noscript-fedora20] $ bzr revert $ bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-noscript-fedora20/ws/ info result: bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-noscript-fedora20/ws/ returned 0. Command output: 5803 stambau...@verizon.net-20150622153854-a3gx0llvfwvg9n40 stderr: [kicad-noscript-fedora20] $ bzr log -v -r revid:maciej.sumin...@cern.ch-20150622122440-f6j78o9jc867dl80..revid:stambau...@verizon.net-20150622153854-a3gx0llvfwvg9n40 --long --show-ids Getting local revision... $ bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-noscript-fedora20/ws/ info result: bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-noscript-fedora20/ws/ returned 0. Command output: 5803 stambau...@verizon.net-20150622153854-a3gx0llvfwvg9n40 stderr: RevisionState revno:5803 revid:stambau...@verizon.net-20150622153854-a3gx0llvfwvg9n40 [kicad-noscript-fedora20] $ /bin/sh -xe /tmp/hudson2998838704902014135.sh + OPTS=' -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=OFF -DKICAD_SCRIPTING=OFF -DKICAD_SCRIPTING_MODULES=OFF -DKICAD_SCRIPTING_WXPYTHON=OFF -DwxWidgets_CONFIG_EXECUTABLE=/usr/bin/wx-config-3.0 -DKICAD_USE_WEBKIT=OFF' + '[' -d build ']' + cd build + /usr/bin/cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=OFF -DKICAD_SCRIPTING=OFF -DKICAD_SCRIPTING_MODULES=OFF -DKICAD_SCRIPTING_WXPYTHON=OFF -DwxWidgets_CONFIG_EXECUTABLE=/usr/bin/wx-config-3.0 -DKICAD_USE_WEBKIT=OFF -- Check for installed OpenGL -- found -- Found Glew: /usr/lib64/libGLEW.so -- Check for installed GLEW -- found -- Check for installed Cairo -- found -- Bazaar version control system version 2.6.0 found. -- Kicad Bazaar build version: (2015-06-22 BZR 5803) -- Configuring done -- Generating done -- Build files have been written to: http://ci.kicad-pcb.org/job/kicad-noscript-fedora20/ws/build + rm -f pcbnew/scripting/pcbnewPYTHON_wrap.cxx.o + rm -f pcbnew/scripting/pcbnewPYTHON_wrap.cxx + make -j4 [ 0%] [ 1%] [ 1%] Built target netlist_lexer_source_files Built target page_layout_lexer_source_files Built target boost [ 1%] [ 1%] [ 1%] Built target fp_lib_table_lexer_source_files Built target pcb_lexer_source_files Generating headers containing GLSL source code [ 1%] [ 1%] Built target pcb_plot_lexer_source_files Built target specctra_lexer_source_files Headers are up-to-date [ 1%] Built target shader_headers [ 1%] [ 1%] Built target cmp_library_lexer_source_files Built target dialog_bom_cfg_lexer_source_files [ 37%] Built target bitmaps [ 37%] [ 37%] Built target field_template_lexer_source_files Built target lib_dxf [ 38%] Built target
[Kicad-developers] [PATCH] Update dangling ends when adding no-connect
Since my recent change to hide dangling ends also responds to no-connect markers, SCH_NO_CONNECT should be changed to correctly update dangling ends after it is placed. This patch accomplishes that. -- Chris commit 32d30d6b24bc75bdfa300153d5e4430a15234456 Author: Chris Pavlina cpavl...@binghamton.edu Date: Mon Jun 22 11:23:50 2015 -0400 Update dangling ends when adding no-connect diff --git a/eeschema/bus-wire-junction.cpp b/eeschema/bus-wire-junction.cpp index 62141bd..a33f7b5 100644 --- a/eeschema/bus-wire-junction.cpp +++ b/eeschema/bus-wire-junction.cpp @@ -379,14 +379,10 @@ SCH_NO_CONNECT* SCH_EDIT_FRAME::AddNoConnect( wxDC* aDC, const wxPoint aPositio SCH_NO_CONNECT* no_connect = new SCH_NO_CONNECT( aPosition ); SetRepeatItem( no_connect ); - -m_canvas-CrossHairOff( aDC ); // Erase schematic cursor -no_connect-Draw( m_canvas, aDC, wxPoint( 0, 0 ), GR_DEFAULT_DRAWMODE ); - -m_canvas-CrossHairOn( aDC ); // Display schematic cursor - GetScreen()-Append( no_connect ); +GetScreen()-SchematicCleanUp( m_canvas, aDC ); OnModify(); +m_canvas-Refresh(); SaveCopyInUndoList( no_connect, UR_NEW ); return no_connect; } ___ Mailing list: https://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 build error from 5803
Nice, I was just about to submit a second patch to fix that destructor. :) On Mon, Jun 22, 2015 at 08:36:12PM +0200, jp charras wrote: Le 22/06/2015 20:17, Chris Pavlina a écrit : Oh, wow. God, I'm a bloody idiot. Third time's the charm? On Mon, Jun 22, 2015 at 02:13:40PM -0400, Chris Pavlina wrote: Found the problem in the rescue update - left a couple unused variable declarations behind, which were no longer valid. Not sure why clang was okay with them, it shouldn't have been. -- Chris I committed your fix. Thanks. To avoid a compil warning I also added a virtual destructor (which do nothing) in class RESCUE_CANDIDATE. -- 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
Re: [Kicad-developers] [PATCH] Fix build error from 5803
Uh, oops. Apparently I can't export a patch. On Mon, Jun 22, 2015 at 02:13:40PM -0400, Chris Pavlina wrote: Found the problem in the rescue update - left a couple unused variable declarations behind, which were no longer valid. Not sure why clang was okay with them, it shouldn't have been. -- Chris commit 1fdae20da0b75c5e5a96e181bc24748b7ad577e9 Merge: 3fa3c4b 1ffd93a Author: Chris Pavlina cpavl...@binghamton.edu Date: Mon Jun 22 14:14:16 2015 -0400 Merge branch 'master' into field_autoplace ___ Mailing list: https://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] Update the PCB from schematics in one click
If I had to give my opinion, I'd say it still needs some work before it's ready for release. At very least, I found it rather unintuitive that it silently fails if you run it while pcbnew isn't running. Any chance of changing that, preferably so that it launches pcbnew? It has a few other minor quirks, but that one in particular struck me as unfriendly. (I'd list more if I still had the build around... but can go back to it later today.) On Tue, Jun 23, 2015 at 04:11:09PM +0200, Tomasz Wlostowski wrote: On 23.06.2015 14:11, ea...@katamail.com wrote: @Tom is this patch going to be committed to the stable release? It's up to Wayne JP. I'm not insisting on putting it in the stable release. Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Remove backtracking wires in eeschema
Sure, I can. I usually prefer to use dynamic_cast because it will fail
if the subclass isn't correct (even if you don't test, since a NULL
access will result in a segfault) - just more or less as a sanity check.
There's really no circumstance under which the pointer should not be an
instance of SCH_LINE, and the behavior when it fails with dynamic_cast
is a bit more obvious.
I can throw an assert in there, though, that'd definitely be more
correct. Modified patch attached.
On Tue, Jun 23, 2015 at 09:24:36AM +0200, jp charras wrote:
Le 22/06/2015 22:50, Chris Pavlina a écrit :
If you place a wire segment and then backtrack over it, you end up with
a broken wire in the end:
http://misc.c4757p.com/backtrack.mp4
This is because the two segments are merged together, rather than the
second *subtracting* from the first, even though the latter case is the
way it's shown as you're drawing. This patch fixes that by adding a
function to erase backtracks.
--
Chris
Thanks for this patch, it is very usefull.
I noticed you are using a dynamic cast in line:
SCH_LINE *line = dynamic_castSCH_LINE*( p );
but the variable line is used without any test for NULL.
Can you have a look at this (use a static cast or a test for NULL) ?
Thanks.
--
Jean-Pierre CHARRAS
commit 5b7beeba531124fe9b7786df9f4e977f8ada7ff5
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Tue Jun 23 09:18:36 2015 -0400
Remove backtracking segments when drawing wires
diff --git a/eeschema/bus-wire-junction.cpp b/eeschema/bus-wire-junction.cpp
index 62141bd..c173f4e 100644
--- a/eeschema/bus-wire-junction.cpp
+++ b/eeschema/bus-wire-junction.cpp
@@ -43,6 +43,7 @@
#include sch_text.h
#include sch_component.h
#include sch_sheet.h
+#include trigo.h
static void AbortCreateNewLine( EDA_DRAW_PANEL* aPanel, wxDC* aDC );
@@ -53,6 +54,47 @@ static DLIST SCH_ITEM s_wires; // when creating a new set of wires,
/**
+ * In a contiguous list of wires, remove wires that backtrack over the previous
+ * wire. Example:
+ *
+ * Wire is added:
+ *
+ *
+ * A second wire backtracks over it:
+ * ---
+ *
+ * RemoveBacktracks is called:
+ * ---
+ */
+static void RemoveBacktracks( DLISTSCH_ITEM aWires )
+{
+SCH_LINE* last_line = NULL;
+
+EDA_ITEM* first = aWires.GetFirst();
+for( EDA_ITEM* p = first; p; p = p-Next() )
+{
+SCH_LINE *line = dynamic_castSCH_LINE*( p );
+wxASSERT_MSG( line, RemoveBacktracks() requires SCH_LINE items );
+continue;
+
+if( p != first )
+{
+wxASSERT_MSG( last_line-GetEndPoint() == line-GetStartPoint(),
+RemoveBacktracks() requires contiguous lines );
+if( IsPointOnSegment( last_line-GetStartPoint(), line-GetStartPoint(),
+line-GetEndPoint() ) )
+{
+last_line-SetEndPoint( line-GetEndPoint() );
+delete s_wires.Remove( line );
+p = line;
+}
+}
+last_line = line;
+}
+}
+
+
+/**
* Mouse capture callback for drawing line segments.
*/
static void DrawSegment( EDA_DRAW_PANEL* aPanel, wxDC* aDC, const wxPoint aPosition,
@@ -261,6 +303,9 @@ void SCH_EDIT_FRAME::EndSegment( wxDC* DC )
SaveCopyInUndoList( oldItems, UR_WIRE_IMAGE );
+// Remove segments backtracking over others
+RemoveBacktracks( s_wires );
+
// Add the new wires
screen-Append( s_wires );
___
Mailing list: https://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] Remove backtracking wires in eeschema
Wow. I made enough stupid yesterday for all of us, didn't I?
Here you go. I'll try to read over my code more carefully, today...
On Tue, Jun 23, 2015 at 04:04:25PM +0200, jp charras wrote:
Le 23/06/2015 15:19, Chris Pavlina a écrit :
Sure, I can. I usually prefer to use dynamic_cast because it will fail
if the subclass isn't correct (even if you don't test, since a NULL
access will result in a segfault) - just more or less as a sanity check.
There's really no circumstance under which the pointer should not be an
instance of SCH_LINE, and the behavior when it fails with dynamic_cast
is a bit more obvious.
I can throw an assert in there, though, that'd definitely be more
correct. Modified patch attached.
Thanks.
But there is yet something strange for me:
I am thinking data is used after deleting:
delete s_wires.Remove( line ) delete the data referenced by line.
then after p = line and last_line = line.
but p-Next() and last_line-GetStartPoint() use this deleted data.
I can be wrong.
--
Jean-Pierre CHARRAS
commit 8b36ca6c62fb2c1a125dc0ba25b82f42d3f7d1c9
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Tue Jun 23 10:22:00 2015 -0400
Remove backtracking segments when drawing wires
diff --git a/eeschema/bus-wire-junction.cpp b/eeschema/bus-wire-junction.cpp
index 62141bd..d0c6994 100644
--- a/eeschema/bus-wire-junction.cpp
+++ b/eeschema/bus-wire-junction.cpp
@@ -43,6 +43,7 @@
#include sch_text.h
#include sch_component.h
#include sch_sheet.h
+#include trigo.h
static void AbortCreateNewLine( EDA_DRAW_PANEL* aPanel, wxDC* aDC );
@@ -53,6 +54,53 @@ static DLIST SCH_ITEM s_wires; // when creating a new set of wires,
/**
+ * In a contiguous list of wires, remove wires that backtrack over the previous
+ * wire. Example:
+ *
+ * Wire is added:
+ *
+ *
+ * A second wire backtracks over it:
+ * ---
+ *
+ * RemoveBacktracks is called:
+ * ---
+ */
+static void RemoveBacktracks( DLISTSCH_ITEM aWires )
+{
+SCH_LINE* last_line = NULL;
+
+EDA_ITEM* first = aWires.GetFirst();
+for( EDA_ITEM* p = first; p; )
+{
+SCH_LINE *line = dynamic_castSCH_LINE*( p );
+if( !line )
+{
+wxFAIL_MSG( RemoveBacktracks() requires SCH_LINE items );
+break;
+}
+p = line-Next();
+
+if( last_line )
+{
+wxASSERT_MSG( last_line-GetEndPoint() == line-GetStartPoint(),
+RemoveBacktracks() requires contiguous lines );
+if( IsPointOnSegment( last_line-GetStartPoint(), line-GetStartPoint(),
+line-GetEndPoint() ) )
+{
+last_line-SetEndPoint( line-GetEndPoint() );
+delete s_wires.Remove( line );
+}
+else
+last_line = line;
+}
+else
+last_line = line;
+}
+}
+
+
+/**
* Mouse capture callback for drawing line segments.
*/
static void DrawSegment( EDA_DRAW_PANEL* aPanel, wxDC* aDC, const wxPoint aPosition,
@@ -261,6 +309,9 @@ void SCH_EDIT_FRAME::EndSegment( wxDC* DC )
SaveCopyInUndoList( oldItems, UR_WIRE_IMAGE );
+// Remove segments backtracking over others
+RemoveBacktracks( s_wires );
+
// Add the new wires
screen-Append( s_wires );
___
Mailing list: https://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] Rotated pads in PNS
Any thoughts on this?
pns_router.cpp:212:
else if( orient != 0.0 orient != 180.0 )
{
// rotated pads are replaced by for the moment by circles due to my
laziness ;)
solid-SetShape( new SHAPE_CIRCLE( c, std::max( sz.x, sz.y ) / 2 ) );
nonOrtho = true;
}
It seems a rather big bug to me, to not be able to route around
rotated pads within their true clearance. PCBs with footprints rotated
45 degrees are actually somewhat common, and when treating the pads like
circles it's not possible to route adjacent pads on most IC footprints.
Any idea when this will be fully implemented?
--
Chris
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Rotated pads in PNS
On Tue, Jun 23, 2015 at 06:11:52PM +0200, Tomasz Wlostowski wrote: Chris, There is a patch by Mathias Grimberger (he sent it quite a bit of time ago), which I'm planning to integrate with PS this week, along with other, IMHO more urgent bugfixes (e.g. assert failures). Excellent! I started doing it myself, but as I'm quite unfamiliar with the PNS code I was having trouble and figured a better use of my time would be fixing things up in an area I'm more familiar with for now. Nice to hear someone already got it. Honestly, I don't consider this a really big bug. It's just an annoyance we could live with. It doesn't prevent you from using rotated pads, you'll just have to route some of them without PS. I respectfully disagree. It's not just PNS, it's all of GAL - even just choosing Highlight collisions you still can't route that unless you disable DRC or switch to legacy. If GAL is indeed supposed to be a full replacement for legacy, I'd want to be at a point where all work can be done in GAL before release. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Eeschema field autoplace, rev 3
/
+path
+ d=m 32.61729,0.60054242 5.062392,0 2.531196,2.39929998 0,2.3993 -2.531196,2.3992997 -2.531196,0 0,2.3992999 -2.53044,0 0,-4.7986996 5.062392,0 0,-2.3993 -5.06196,0 0,-2.39929998 z
+ id=path147
+ inkscape:connector-curvature=0
+ style=fill-rule:evenodd /
+path
+ d=m 15.393889,11.860171 6.40475,0 0,2.3244 -3.84285,6.990866 -2.5619,0 3.84285,-6.9732 -3.84285,0 0,-2.342995 z
+ id=path75
+ inkscape:connector-curvature=0
+ style=fill-rule:evenodd /
+path
+ d=m 39.731939,11.860171 0,2.3244 3.84285,0 0,1.1622 -3.84285,3.4866 0,2.3244 6.40475,0 0,-2.3244 -3.84285,0 3.84285,-3.4866 0,-2.3244 -1.28095,-1.179842 -5.1238,0.01767 z
+ id=path77
+ inkscape:connector-curvature=0
+ style=fill-rule:evenodd /
+path
+ d=m 32.046239,14.312413 0.01947,4.520958 1.261505,2.3244 3.84285,0 1.300395,-2.452242 0,-4.6488 -1.300395,-2.196488 -3.84285,0 -1.28095,2.452242 z
+ id=path79
+ inkscape:connector-curvature=0
+ style=fill-rule:evenodd /
+path
+ d=m 33.327189,15.346771 1.28095,-1.1622 1.28095,0 1.28095,1.1622 0,2.3244 -1.28095,1.1622 -1.28095,0 -1.28095,-1.1622 0,-2.3244 z
+ id=path81
+ inkscape:connector-curvature=0
+ style=fill:#ff;fill-rule:evenodd /
+path
+ d=m 23.079589,11.860171 0,5.811 5.1238,0 0,3.4866 2.5619,0 0,-9.2976 -2.5619,0 0,3.4866 -2.5619,0 0,-3.4866 -2.5619,0 z
+ id=path83
+ inkscape:connector-curvature=0
+ style=fill-rule:evenodd /
+ /g
+/svg
diff --git a/eeschema/CMakeLists.txt b/eeschema/CMakeLists.txt
index d6cc1cd..349decb 100644
--- a/eeschema/CMakeLists.txt
+++ b/eeschema/CMakeLists.txt
@@ -75,6 +75,7 @@ set( EESCHEMA_DLGS
)
set( EESCHEMA_SRCS
+autoplace_fields.cpp
annotate.cpp
backanno.cpp
block.cpp
diff --git a/eeschema/autoplace_fields.cpp b/eeschema/autoplace_fields.cpp
new file mode 100644
index 000..dd7fa92
--- /dev/null
+++ b/eeschema/autoplace_fields.cpp
@@ -0,0 +1,387 @@
+/*
+ * This program source code file is part of KiCad, a free EDA CAD application.
+ *
+ * Copyright (C) 2015 Chris Pavlina pavlina.ch...@gmail.com
+ * Copyright (C) 2015 KiCad Developers, see change_log.txt for contributors.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, you may find one here:
+ * http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
+ * or you may search the http://www.gnu.org website for the version 2 license,
+ * or you may write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
+ */
+
+#include schframe.h
+#include hotkeys_basic.h
+#include sch_component.h
+#include lib_pin.h
+#include class_drawpanel.h
+#include class_libentry.h
+#include eeschema_config.h
+#include kiface_i.h
+#include boost/foreach.hpp
+#include vector
+#include algorithm
+
+#define FIELD_V_SPACING 100
+#define HPADDING 25
+#define VPADDING 50
+
+enum component_side
+{
+SIDE_TOP, SIDE_BOTTOM, SIDE_LEFT, SIDE_RIGHT
+};
+
+/**
+ * Function round_n
+ * Round up/down to the nearest multiple of n
+ */
+templatetypename T T round_n( const T value, const T n, bool aRoundUp )
+{
+if( value % n )
+return n * (value / n + (aRoundUp ? 1 : 0));
+else
+return value;
+}
+
+
+/**
+ * Function get_pin_side
+ * Return the side that a pin is on.
+ */
+static enum component_side get_pin_side( SCH_COMPONENT* aComponent, LIB_PIN* aPin )
+{
+int pin_orient = aPin-PinDrawOrient( aComponent-GetTransform() );
+switch( pin_orient )
+{
+case PIN_RIGHT:
+return SIDE_LEFT;
+case PIN_LEFT:
+return SIDE_RIGHT;
+case PIN_UP:
+return SIDE_BOTTOM;
+case PIN_DOWN:
+return SIDE_TOP;
+default:
+wxFAIL_MSG( Invalid pin orientation );
+return SIDE_LEFT;
+}
+}
+
+
+/**
+ * Function pins_on_side
+ * Count the number of pins on a side of the component
+ */
+static unsigned pins_on_side( SCH_COMPONENT* aComponent, enum component_side aSide )
+{
+unsigned pin_count = 0;
+
+std::vectorLIB_PIN* pins;
+aComponent-GetPins( pins );
+
+BOOST_FOREACH( LIB_PIN* each_pin, pins )
+{
+if( !each_pin-IsVisible() )
+continue;
+if( get_pin_side( aComponent, each_pin ) == aSide )
+++pin_count;
+}
+
+return pin_count;
+}
+
+
+// Used for iteration
+struct side {
+enum component_side name
Re: [Kicad-developers] [PATCH] Fix segfault on quit
Wayne, commit this one instead of the destroy() patch - found the problem. Also commit the second one, that's a separate (but similar) problem. On Mon, Jun 22, 2015 at 07:41:24PM -0400, Wayne Stambaugh wrote: Is this in addition to or instead of your previous patch that removed destroy() from ~PGM_BASE()? On 6/22/2015 7:04 PM, Chris Pavlina wrote: Under certain (but not all) conditions, kicad applications segfault on quit. This has been reported: https://bugs.launchpad.net/kicad/+bug/1431028 https://bugs.launchpad.net/kicad/+bug/1467221 It appears to be the case that Pgm().OnPgmExit() was called in the wrong place. This patch moves it from APP_SINGLE_TOP::OnRun() to APP_SINGLE_TOP::OnExit(), which appears to correct the issue. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp commit 7360bdf3d29ff8af6070c9e4f8fdc84285974e68 Author: Chris Pavlina cpavl...@binghamton.edu Date: Mon Jun 22 20:56:03 2015 -0400 Add missing cleanup call to PGM_SINGLE_TOP::OnPgmInit diff --git a/common/single_top.cpp b/common/single_top.cpp index c1d8f17..dba849d 100644 --- a/common/single_top.cpp +++ b/common/single_top.cpp @@ -278,6 +278,11 @@ bool PGM_SINGLE_TOP::OnPgmInit( wxApp* aWxApp ) // OpenProjectFiles() API asks that it report failure to the UI. // Nothing further to say here. +// We've already initialized things at this point, but wx won't call OnExit if +// we fail out. Call our own cleanup routine here to ensure the relevant resources +// are freed at the right time (if they aren't, segfaults will occur). +OnPgmExit(); + // Fail the process startup if the file could not be opened, // although this is an optional choice, one that can be reversed // also in the KIFACE specific OpenProjectFiles() return value. ___ Mailing list: https://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] Fix segfault on quit
Under certain (but not all) conditions, kicad applications segfault on
quit. This has been reported:
https://bugs.launchpad.net/kicad/+bug/1431028
https://bugs.launchpad.net/kicad/+bug/1467221
It appears to be the case that Pgm().OnPgmExit() was called in the wrong
place. This patch moves it from APP_SINGLE_TOP::OnRun() to
APP_SINGLE_TOP::OnExit(), which appears to correct the issue.
--
Chris
commit 1fd47fa8a2bdb3daef67029ed076005e049737b7
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Mon Jun 22 19:01:12 2015 -0400
Move OnPgmExit to the correct place to avoid segfault
diff --git a/common/single_top.cpp b/common/single_top.cpp
index 8addf58..c1d8f17 100644
--- a/common/single_top.cpp
+++ b/common/single_top.cpp
@@ -143,6 +143,8 @@ struct APP_SINGLE_TOP : public wxApp
int OnExit() // overload wxApp virtual
{
+Pgm().OnPgmExit();
+
return wxApp::OnExit();
}
@@ -169,8 +171,6 @@ struct APP_SINGLE_TOP : public wxApp
wxLogError( wxT( Unhandled exception of unknown type ) );
}
-Pgm().OnPgmExit();
-
return ret;
}
___
Mailing list: https://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 segfault on quit
Actually this might also fix the other one too, don't know. But it won't hurt to have both, so you might as well commit them for now. I'll finish investigating the other one later tonight or tomorrow. On Jun 22, 2015 19:43, Chris Pavlina pavlina.ch...@gmail.com wrote: Addition. I still haven't tracked down the root cause of the other one, but this is unrelated. On Jun 22, 2015 19:41, Wayne Stambaugh stambau...@gmail.com wrote: Is this in addition to or instead of your previous patch that removed destroy() from ~PGM_BASE()? On 6/22/2015 7:04 PM, Chris Pavlina wrote: Under certain (but not all) conditions, kicad applications segfault on quit. This has been reported: https://bugs.launchpad.net/kicad/+bug/1431028 https://bugs.launchpad.net/kicad/+bug/1467221 It appears to be the case that Pgm().OnPgmExit() was called in the wrong place. This patch moves it from APP_SINGLE_TOP::OnRun() to APP_SINGLE_TOP::OnExit(), which appears to correct the issue. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] lib-cache-rescue upgrade
Am I just missing something, or did you reply to the wrong mail? ;) On Fri, Jun 19, 2015 at 05:37:16PM -0400, Wayne Stambaugh wrote: Chris, I'm not opposed to this patch. I actually prefer the footprint viewer over the footprint search dialog for two reasons. One, the footprint viewer uses lazy loading (it doesn't actually read the footprint files until you select a library) so there is no lag showing the viewer due to loading all of the footprints in every library as is the case with the search dialog. Two, you can actually view the footprint to make sure that is really what you want. That being said, I'm sure not everyone shares my enthusiasm for the footprint viewer so a better solution may be to add a separate button to launch the footprint viewer and leave the footprint search dialog in place for users who prefer using that instead. I promise you if we remove the footprint search dialog, someone will file a bug report about it shortly there after. :) Wayne On 6/18/2015 3:07 PM, Chris Pavlina wrote: Hi all, It's come to my attention that we have another old project compatibility issue: https://forum.kicad.info/t/exisiting-schematic-component-not-being-found-in-library-error/976 The behavior when loading a very old project with case-insensitive part names isn't nice at all, there's no easy way to change them over. It gives suggestions for new part names, but you still have to change them one by one. I adapted lib-cache-rescue into a more generic project-rescue, which can handle multiple types of rescue cases, and added one for missing symbols with differently cased versions available. It looks roughly like this now (though I've changed the descriptive text at the top since taking that screenshot): http://misc.c4757p.com/newrescue.png Please, as many people as possible, try this out. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Footprint license
What is the license for the footprint libraries? These should probably have a COPYING.txt in the individual repos - I'm sure I could find the license if I searched around, but it should be right there. ___ Mailing list: https://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] Cleanup: remove unnecessary macros
Hi,
macros.h provides two macros that appear to me completely unnecessary:
EXCHG and NEGATE.
The comment above EXCHG points out that it differs from std::swap in
that it accepts arguments of different types. I could not find a single
instance depending on that - it always swapped values of the same type.
It also remarks I hope to get rid of this soon or late. I removed it
and replaced its uses with std::swap.
The comment above NEGATE justifies it:
// This really needs a function? well, it is used *a lot* of times
Doesn't really mean it needs a macro though, otherwise we might as well
go defining macros like DOUBLE() and INCREMENT() and so on... It's just
as easy to type something like x = -x or x *= -1, and the latter is
_shorter_ than NEGATE( x ). I removed this too.
Up to you whether or not you want to accept the patch, but I think it's
a step in the direction of cleaner code. Macros for simple things that
don't need them confuse people - you have to go check the definition to
see if it does something special. They also result in some clumsy use
cases like this, from trying to shove them in:
m_pos.x -= aYaxis_position;
NEGATE( m_pos.x );
m_pos.x += aYaxis_position;
Writing out the NEGATE makes it clear that the lines are all very
similar and can easily be simplified:
m_pos.x = 2 * aYaxis_position - m_pos.x;
That's a lot clearer... I don't know about you, but I can visualize what
that's doing graphically a lot better too.
--
Chris
commit f96cd3a51e8c63f3f96a96d3a1e30e88723b9085
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Fri Jun 26 01:28:30 2015 -0400
Remove unnecessary macros EXCHG and NEGATE
diff --git a/3d-viewer/3d_draw_helper_functions.cpp b/3d-viewer/3d_draw_helper_functions.cpp
index 577be18..25e3e6e 100644
--- a/3d-viewer/3d_draw_helper_functions.cpp
+++ b/3d-viewer/3d_draw_helper_functions.cpp
@@ -219,7 +219,7 @@ void EDA_3D_CANVAS::draw3DGrid( double aGriSizeMM )
wxSize brd_size = getBoardSize();
wxPoint brd_center_pos = getBoardCenter();
-NEGATE( brd_center_pos.y );
+brd_center_pos.y *= -1;
int xsize = std::max( brd_size.x, Millimeter2iu( 100 ) ) * 1.2;
int ysize = std::max( brd_size.y, Millimeter2iu( 100 ) ) * 1.2;
diff --git a/common/class_plotter.cpp b/common/class_plotter.cpp
index 427a094..3150d2c 100644
--- a/common/class_plotter.cpp
+++ b/common/class_plotter.cpp
@@ -150,7 +150,7 @@ void PLOTTER::Arc( const wxPoint centre, double StAngle, double EndAngle, int r
const int delta = 50; // increment (in 0.1 degrees) to draw circles
if( StAngle EndAngle )
-EXCHG( StAngle, EndAngle );
+std::swap( StAngle, EndAngle );
SetCurrentLineWidth( width );
/* Please NOTE the different sign due to Y-axis flip */
@@ -406,7 +406,7 @@ void PLOTTER::sketchOval( const wxPoint pos, const wxSize aSize, double orient
if( size.x size.y )
{
-EXCHG( size.x, size.y );
+std::swap( size.x, size.y );
orient = AddAngles( orient, 900 );
}
diff --git a/common/common.cpp b/common/common.cpp
index 6018e71..34aebf7 100644
--- a/common/common.cpp
+++ b/common/common.cpp
@@ -280,7 +280,7 @@ double RoundTo0( double x, double precision )
long long ix = KiROUND( x * precision );
if ( x 0.0 )
-NEGATE( ix );
+ix *= -1;
int remainder = ix % 10; // remainder is in precision mm
@@ -290,7 +290,7 @@ double RoundTo0( double x, double precision )
ix += 10 - remainder; // round to near number
if ( x 0 )
-NEGATE( ix );
+ix *= -1;
return (double) ix / precision;
}
diff --git a/common/common_plotDXF_functions.cpp b/common/common_plotDXF_functions.cpp
index 545b5ca..da5ef03 100644
--- a/common/common_plotDXF_functions.cpp
+++ b/common/common_plotDXF_functions.cpp
@@ -508,7 +508,7 @@ void DXF_PLOTTER::Arc( const wxPoint centre, double StAngle, double EndAngle, i
// If StAngle EndAngle, it is CW. So transform it to CCW
if( StAngle EndAngle )
{
-EXCHG( StAngle, EndAngle );
+std::swap( StAngle, EndAngle );
}
DPOINT centre_dev = userToDeviceCoordinates( centre );
@@ -536,7 +536,7 @@ void DXF_PLOTTER::FlashPadOval( const wxPoint pos, const wxSize aSize, double
* (Oval vertical orientation 0) */
if( size.x size.y )
{
-EXCHG( size.x, size.y );
+std::swap( size.x, size.y );
orient = AddAngles( orient, 900 );
}
diff --git a/common/common_plotGERBER_functions.cpp b/common/common_plotGERBER_functions.cpp
index a2a912f..2e041e6 100644
--- a/common/common_plotGERBER_functions.cpp
+++ b/common/common_plotGERBER_functions.cpp
@@ -459,7 +459,7 @@ void GERBER_PLOTTER::FlashPadOval( const wxPoint pos, const wxSize aSize, doub
trace_mode == FILLED )
{
if( orient == 900 || orient == 2700 ) /* orientation turned 90 deg. */
-EXCHG( size.x, size.y );
+std::swap( size.x
Re: [Kicad-developers] [PATCH] Skip redundant repetition of component name in component chooser
Are you positive that a better fix wouldn't be to stop putting redundant things in component descriptions? This seems like a poor way to KISS... On Thu, Jun 25, 2015 at 06:24:33PM -0700, Henner Zeller wrote: Hi, In component descriptions, often the first word in the description is a repetition of the component name. While this is generally not a problem when reading this in a description box, if displayed in the brief description in the tree view, this is redundant information, taking space of more relevant information (see first attachment picture). This patch uses some heuristic to get rid of these and thus generally improves the experience for these components: https://github.com/hzeller/kicad/compare/skip-redundant-name-repetition-in-tree.diff See second picture for an example. Henner. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Skip redundant repetition of component name in component chooser
I want the description column to show exactly what's in the component description field, as it does now. I'm not opposed to different behavior, I'd just ideally like an optional way to keep it the way it is. I maintain my own libraries, and if there's something wrong with them like that, I'd rather see it so I can fix it! I don't think I'm the only one who'd like to see major interface elements like that stay relatively simple and predictable. It's POLA - it claims to be a description column, so you expect it to directly show the description. https://en.wikipedia.org/wiki/Principle_of_least_astonishment On Thu, Jun 25, 2015 at 07:28:31PM -0700, Henner Zeller wrote: On 25 June 2015 at 19:18, Chris Pavlina pavlina.ch...@gmail.com wrote: Any chance of making it configurable? Or at least, of not being offended if I throw in a patch to do that? ;) What do you want to make configurable ? Do you _want_ to see the redundant information ? On Thu, Jun 25, 2015 at 07:15:36PM -0700, Henner Zeller wrote: On 25 June 2015 at 19:09, Chris Pavlina pavlina.ch...@gmail.com wrote: Are you positive that a better fix wouldn't be to stop putting redundant things in component descriptions? It would be good if that wouldn't happen, yes. But I can't change all the libraries that exist in the world; changing only the KiCAD internal libraries would probably be feasible (need to hack up something) and should probably be done independently. This change helps to have KiCAD behave best in the real world. -h On Thu, Jun 25, 2015 at 06:24:33PM -0700, Henner Zeller wrote: Hi, In component descriptions, often the first word in the description is a repetition of the component name. While this is generally not a problem when reading this in a description box, if displayed in the brief description in the tree view, this is redundant information, taking space of more relevant information (see first attachment picture). This patch uses some heuristic to get rid of these and thus generally improves the experience for these components: https://github.com/hzeller/kicad/compare/skip-redundant-name-repetition-in-tree.diff See second picture for an example. Henner. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH] Quick rescue fixes
Here are a couple quick fixes to project_rescue.
- Components with multiple converts were rendered with all of them
overlapping instead of just one.
- Schematics missing a -cache.lib resulted in unnecessary renaming
suggestions.
- The dialog title Conflicts Checking is inaccurate now (as we're
checking for more than just conflicts) and also somewhat awkward,
unidiomatic GUI English; I renamed it to Project Rescue Helper.
--
Chris
commit b4359ade0ab17ca967338cc30b7994208481ddc9
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Thu Jun 25 20:26:10 2015 -0400
Rescue fixes
diff --git a/eeschema/dialogs/dialog_rescue_each.cpp b/eeschema/dialogs/dialog_rescue_each.cpp
index 31c424a..69fc5ec 100644
--- a/eeschema/dialogs/dialog_rescue_each.cpp
+++ b/eeschema/dialogs/dialog_rescue_each.cpp
@@ -219,7 +219,7 @@ void DIALOG_RESCUE_EACH::renderPreview( LIB_PART* aComponent, int aUnit, wxPanel
dc.SetDeviceOrigin( dc_size.x / 2, dc_size.y / 2 );
// Find joint bounding box for everything we are about to draw.
-EDA_RECT bBox = aComponent-GetBoundingBox( aUnit, /* deMorganConvert */ 0 );
+EDA_RECT bBox = aComponent-GetBoundingBox( aUnit, /* deMorganConvert */ 1 );
const double xscale = (double) dc_size.x / bBox.GetWidth();
const double yscale = (double) dc_size.y / bBox.GetHeight();
const double scale = std::min( xscale, yscale ) * 0.85;
@@ -235,7 +235,7 @@ void DIALOG_RESCUE_EACH::renderPreview( LIB_PART* aComponent, int aUnit, wxPanel
if( !width || !height )
return;
-aComponent-Draw( NULL, dc, offset, aUnit, /* deMorganConvert */ 0, GR_COPY,
+aComponent-Draw( NULL, dc, offset, aUnit, /* deMorganConvert */ 1, GR_COPY,
UNSPECIFIED_COLOR, DefaultTransform, true, true, false );
}
diff --git a/eeschema/dialogs/dialog_rescue_each_base.fbp b/eeschema/dialogs/dialog_rescue_each_base.fbp
index fcc7882..5199216 100644
--- a/eeschema/dialogs/dialog_rescue_each_base.fbp
+++ b/eeschema/dialogs/dialog_rescue_each_base.fbp
@@ -47,7 +47,7 @@
property name=size529,593/property
property name=stylewxDEFAULT_DIALOG_STYLE|wxRESIZE_BORDER/property
property name=subclassDIALOG_SHIM; dialog_shim.h/property
-property name=titleConflicts Checking/property
+property name=titleProject Rescue Helper/property
property name=tooltip/property
property name=window_extra_style/property
property name=window_name/property
diff --git a/eeschema/dialogs/dialog_rescue_each_base.h b/eeschema/dialogs/dialog_rescue_each_base.h
index e6490c3..40d1b11 100644
--- a/eeschema/dialogs/dialog_rescue_each_base.h
+++ b/eeschema/dialogs/dialog_rescue_each_base.h
@@ -62,7 +62,7 @@ class DIALOG_RESCUE_EACH_BASE : public DIALOG_SHIM
public:
- DIALOG_RESCUE_EACH_BASE( wxWindow* parent, wxWindowID id = wxID_ANY, const wxString title = _(Conflicts Checking), const wxPoint pos = wxDefaultPosition, const wxSize size = wxSize( 529,593 ), long style = wxDEFAULT_DIALOG_STYLE|wxRESIZE_BORDER );
+ DIALOG_RESCUE_EACH_BASE( wxWindow* parent, wxWindowID id = wxID_ANY, const wxString title = _(Project Rescue Helper), const wxPoint pos = wxDefaultPosition, const wxSize size = wxSize( 529,593 ), long style = wxDEFAULT_DIALOG_STYLE|wxRESIZE_BORDER );
~DIALOG_RESCUE_EACH_BASE();
};
diff --git a/eeschema/project_rescue.cpp b/eeschema/project_rescue.cpp
index 9104372..5645787 100644
--- a/eeschema/project_rescue.cpp
+++ b/eeschema/project_rescue.cpp
@@ -243,7 +243,7 @@ public:
{
wxString part_name( each_component-GetPartName() );
-LIB_PART* case_sensitive_match = find_component( part_name, aRescuer.GetLibs(), /* aCached */ true );
+LIB_ALIAS* case_sensitive_match = aRescuer.GetLibs()-FindLibraryEntry( part_name );
std::vectorLIB_ALIAS* case_insensitive_matches;
aRescuer.GetLibs()-FindLibraryNearEntries( case_insensitive_matches, part_name );
___
Mailing list: https://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] Update dangling ends when adding no-connect
Haha, okay, I'll try to be more patient... On Wed, Jun 24, 2015 at 11:17:03AM -0400, Wayne Stambaugh wrote: It didn't. I'm working on it now. On 6/24/2015 11:15 AM, Chris Pavlina wrote: Quick bump, I think this patch might have got lost in Monday's patch storm :) On Mon, Jun 22, 2015 at 11:26:14AM -0400, Chris Pavlina wrote: Since my recent change to hide dangling ends also responds to no-connect markers, SCH_NO_CONNECT should be changed to correctly update dangling ends after it is placed. This patch accomplishes that. -- Chris commit 32d30d6b24bc75bdfa300153d5e4430a15234456 Author: Chris Pavlina cpavl...@binghamton.edu Date: Mon Jun 22 11:23:50 2015 -0400 Update dangling ends when adding no-connect diff --git a/eeschema/bus-wire-junction.cpp b/eeschema/bus-wire-junction.cpp index 62141bd..a33f7b5 100644 --- a/eeschema/bus-wire-junction.cpp +++ b/eeschema/bus-wire-junction.cpp @@ -379,14 +379,10 @@ SCH_NO_CONNECT* SCH_EDIT_FRAME::AddNoConnect( wxDC* aDC, const wxPoint aPositio SCH_NO_CONNECT* no_connect = new SCH_NO_CONNECT( aPosition ); SetRepeatItem( no_connect ); - -m_canvas-CrossHairOff( aDC ); // Erase schematic cursor -no_connect-Draw( m_canvas, aDC, wxPoint( 0, 0 ), GR_DEFAULT_DRAWMODE ); - -m_canvas-CrossHairOn( aDC ); // Display schematic cursor - GetScreen()-Append( no_connect ); +GetScreen()-SchematicCleanUp( m_canvas, aDC ); OnModify(); +m_canvas-Refresh(); SaveCopyInUndoList( no_connect, UR_NEW ); return no_connect; } ___ Mailing list: https://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] Eeschema field autoplacing: second rev
=path129
+ inkscape:connector-curvature=0 /
+path
+ d=m 31.68259,28.343835 a 2.531196,2.3993 0 0 1 -5.062392,0 2.531196,2.3993 0 1 1 5.062392,0 z
+ id=path131
+ style=fill:url(#linearGradient3479)
+ inkscape:connector-curvature=0 /
+rect
+ y=27.144733
+ width=6.3132482
+ x=32.962929
+ height=2.3993001
+ id=rect133 /
+path
+ d=m 22.49337,0.60054242 0,7.19799968 2.531196,2.3992999 2.531196,0 2.531196,-2.3992999 0,-7.19799968 -2.531196,0 0,7.19799968 -2.531196,0 0,-7.19799968 -2.53152,0 z
+ id=path135
+ inkscape:connector-curvature=0
+ style=fill-rule:evenodd /
+path
+ d=m 32.61729,0.60054242 5.062392,0 2.531196,2.39929998 0,2.3993 -2.531196,2.3992997 -2.531196,0 0,2.3992999 -2.53044,0 0,-4.7986996 5.062392,0 0,-2.3993 -5.06196,0 0,-2.39929998 z
+ id=path147
+ inkscape:connector-curvature=0
+ style=fill-rule:evenodd /
+path
+ d=m 15.393889,11.860171 6.40475,0 0,2.3244 -3.84285,6.990866 -2.5619,0 3.84285,-6.9732 -3.84285,0 0,-2.342995 z
+ id=path75
+ inkscape:connector-curvature=0
+ style=fill-rule:evenodd /
+path
+ d=m 39.731939,11.860171 0,2.3244 3.84285,0 0,1.1622 -3.84285,3.4866 0,2.3244 6.40475,0 0,-2.3244 -3.84285,0 3.84285,-3.4866 0,-2.3244 -1.28095,-1.179842 -5.1238,0.01767 z
+ id=path77
+ inkscape:connector-curvature=0
+ style=fill-rule:evenodd /
+path
+ d=m 32.046239,14.312413 0.01947,4.520958 1.261505,2.3244 3.84285,0 1.300395,-2.452242 0,-4.6488 -1.300395,-2.196488 -3.84285,0 -1.28095,2.452242 z
+ id=path79
+ inkscape:connector-curvature=0
+ style=fill-rule:evenodd /
+path
+ d=m 33.327189,15.346771 1.28095,-1.1622 1.28095,0 1.28095,1.1622 0,2.3244 -1.28095,1.1622 -1.28095,0 -1.28095,-1.1622 0,-2.3244 z
+ id=path81
+ inkscape:connector-curvature=0
+ style=fill:#ff;fill-rule:evenodd /
+path
+ d=m 23.079589,11.860171 0,5.811 5.1238,0 0,3.4866 2.5619,0 0,-9.2976 -2.5619,0 0,3.4866 -2.5619,0 0,-3.4866 -2.5619,0 z
+ id=path83
+ inkscape:connector-curvature=0
+ style=fill-rule:evenodd /
+ /g
+/svg
diff --git a/eeschema/CMakeLists.txt b/eeschema/CMakeLists.txt
index 0982735..5cba4f1 100644
--- a/eeschema/CMakeLists.txt
+++ b/eeschema/CMakeLists.txt
@@ -75,6 +75,7 @@ set( EESCHEMA_DLGS
)
set( EESCHEMA_SRCS
+autoplace_fields.cpp
annotate.cpp
backanno.cpp
block.cpp
diff --git a/eeschema/autoplace_fields.cpp b/eeschema/autoplace_fields.cpp
new file mode 100644
index 000..11ab31d
--- /dev/null
+++ b/eeschema/autoplace_fields.cpp
@@ -0,0 +1,359 @@
+/*
+ * This program source code file is part of KiCad, a free EDA CAD application.
+ *
+ * Copyright (C) 2015 Chris Pavlina pavlina.ch...@gmail.com
+ * Copyright (C) 2015 KiCad Developers, see change_log.txt for contributors.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, you may find one here:
+ * http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
+ * or you may search the http://www.gnu.org website for the version 2 license,
+ * or you may write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
+ */
+
+#include schframe.h
+#include hotkeys_basic.h
+#include sch_component.h
+#include lib_pin.h
+#include class_drawpanel.h
+#include class_libentry.h
+#include eeschema_config.h
+#include kiface_i.h
+#include boost/foreach.hpp
+#include vector
+#include algorithm
+
+#define FIELD_V_SPACING 100
+#define HORIZ_PADDING 50
+
+enum component_side {
+SIDE_TOP, SIDE_BOTTOM, SIDE_LEFT, SIDE_RIGHT
+};
+
+
+/**
+ * Function round_n
+ * Round up/down to the nearest multiple of n
+ */
+templatetypename T T round_n( const T value, const T n, bool aRoundUp )
+{
+if( value % n )
+return n * (value / n + (aRoundUp ? 1 : 0));
+else
+return value;
+}
+
+
+/**
+ * Function get_pin_side
+ * Return the side that a pin is on.
+ */
+static enum component_side get_pin_side( SCH_COMPONENT* aComponent, LIB_PIN* aPin )
+{
+int pin_orient = aPin-PinDrawOrient( aComponent-GetTransform() );
+switch( pin_orient )
+{
+case PIN_RIGHT:
+return SIDE_LEFT;
+case PIN_LEFT:
+return SIDE_RIGHT;
+case PIN_UP:
+return SIDE_BOTTOM;
+case PIN_DOWN:
+return SIDE_TOP;
+default:
+wxFAIL_MSG( Invalid pin
Re: [Kicad-developers] [PATCH] Autosave assertion failure workaround
Oops, the same thing has to be applied in pcbnew. Patch attached.
On Thu, Jun 18, 2015 at 02:43:56PM -0400, Wayne Stambaugh wrote:
Patch committed in product branch r5782. Thanks.
On 6/16/2015 11:40 AM, Chris Pavlina wrote:
When eeschema attempts to autosave a schematic that hasn't been saved
before, an assertion (common/basicframe.cpp:656) fails. Here's a patch
that works around that.
I call this a workaround rather than a fix because I'd rather autosave
still work for things that don't have a filename yet, but that has to be
done more carefully. It would require a check at startup for a backup
file saved to a predetermined location (ideally somewhere within either
/tmp or ~/.kicad on Linux, and the equivalent locations on other
systems).
--
Chris
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
commit 9f36d7a5da4c6dbc1ce9f2b2d65387a7e9e06699
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Tue Jun 16 16:22:48 2015 -0400
Fix autosave bug in pcbnew too
diff --git a/pcbnew/files.cpp b/pcbnew/files.cpp
index 68e0085..b9c7dbb 100644
--- a/pcbnew/files.cpp
+++ b/pcbnew/files.cpp
@@ -813,7 +813,9 @@ bool PCB_EDIT_FRAME::doAutoSave()
wxLogTrace( traceAutoSave,
wxT( Creating auto save file + fn.GetFullPath() ) + wxT( ) );
-if( SavePcbFile( fn.GetFullPath(), NO_BACKUP_FILE ) )
+if( !fn.IsOk() )
+return false;
+else if( SavePcbFile( fn.GetFullPath(), NO_BACKUP_FILE ) )
{
GetScreen()-SetModify();
GetBoard()-SetFileName( tmpFileName.GetFullPath() );
___
Mailing list: https://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] lib-cache-rescue upgrade
+20,7 @@ DIALOG_RESCUE_EACH_BASE::DIALOG_RESCUE_EACH_BASE( wxWindow* parent, wxWindowID i
m_lblInfo-Wrap( 500 );
bSizerMain-Add( m_lblInfo, 0, wxALL|wxEXPAND, 5 );
- m_staticText5 = new wxStaticText( this, wxID_ANY, _(Symbols with cache/library conflicts:), wxDefaultPosition, wxDefaultSize, 0 );
+ m_staticText5 = new wxStaticText( this, wxID_ANY, _(Symbols to update:), wxDefaultPosition, wxDefaultSize, 0 );
m_staticText5-Wrap( -1 );
m_staticText5-SetFont( wxFont( wxNORMAL_FONT-GetPointSize(), 70, 90, 92, false, wxEmptyString ) );
diff --git a/eeschema/dialogs/dialog_rescue_each_base.fbp b/eeschema/dialogs/dialog_rescue_each_base.fbp
index dee774b..fcc7882 100644
--- a/eeschema/dialogs/dialog_rescue_each_base.fbp
+++ b/eeschema/dialogs/dialog_rescue_each_base.fbp
@@ -208,7 +208,7 @@
property name=gripper0/property
property name=hidden0/property
property name=idwxID_ANY/property
-property name=labelSymbols with cache/library conflicts:/property
+property name=labelSymbols to update:/property
property name=max_size/property
property name=maximize_button0/property
property name=maximum_size/property
diff --git a/eeschema/files-io.cpp b/eeschema/files-io.cpp
index 39922f5..3bf97b9 100644
--- a/eeschema/files-io.cpp
+++ b/eeschema/files-io.cpp
@@ -43,7 +43,7 @@
#include sch_sheet_path.h
#include sch_component.h
#include wildcards_and_files_ext.h
-#include lib_cache_rescue.h
+#include project_rescue.h
#include eeschema_config.h
@@ -307,7 +307,7 @@ bool SCH_EDIT_FRAME::OpenProjectFiles( const std::vectorwxString aFileSet, in
UpdateFileHistory( fullFileName );
-// Check to see whether some old, cached library parts need to be rescued
+// Check to see whether some old library parts need to be rescued
// Only do this if RescueNeverShow was not set.
wxConfigBase *config = Kiface().KifaceSettings();
bool rescueNeverShow = false;
@@ -315,7 +315,7 @@ bool SCH_EDIT_FRAME::OpenProjectFiles( const std::vectorwxString aFileSet, in
if( !rescueNeverShow )
{
-if( RescueCacheConflicts( false ) )
+if( RescueProject( false ) )
{
GetScreen()-CheckComponentsToPartsLinks();
GetScreen()-TestDanglingEnds();
diff --git a/eeschema/invoke_sch_dialog.h b/eeschema/invoke_sch_dialog.h
index 0a9cbe4..e4395ee 100644
--- a/eeschema/invoke_sch_dialog.h
+++ b/eeschema/invoke_sch_dialog.h
@@ -48,8 +48,7 @@ class wxDialog;
class LIB_PART;
class PART_LIBS;
class SCH_COMPONENT;
-class RESCUE_CANDIDATE;
-class RESCUE_LOG;
+class RESCUER;
// Often this is not used in the prototypes, since wxFrame is good enough and would
// represent maximum information hiding.
@@ -60,12 +59,10 @@ class SCH_EDIT_FRAME;
* This dialog asks the user which rescuable, cached parts he wants to rescue.
* Any rejects will be pruned from aCandidates.
* @param aCaller - the SCH_EDIT_FRAME calling this
- * @param aCandidates - the list of RESCUE_CANDIDATES
- * @param aComponents - a vector of all the components in the schematic
+ * @param aRescuer - the active RESCUER instance
* @param aAskShowAgain - if true, a Never Show Again button will be included
*/
-int InvokeDialogRescueEach( SCH_EDIT_FRAME* aCaller, std::vectorRESCUE_CANDIDATE aCandidates,
-std::vectorSCH_COMPONENT* aComponents, bool aAskShowAgain );
+int InvokeDialogRescueEach( SCH_EDIT_FRAME* aCaller, RESCUER aRescuer, bool aAskShowAgain );
/// Create and show DIALOG_ANNOTATE and return whatever
/// DIALOG_ANNOTATE::ShowModal() returns.
diff --git a/eeschema/lib_cache_rescue.cpp b/eeschema/lib_cache_rescue.cpp
deleted file mode 100644
index da74997..000
--- a/eeschema/lib_cache_rescue.cpp
+++ /dev/null
@@ -1,385 +0,0 @@
-/*
- * This program source code file is part of KiCad, a free EDA CAD application.
- *
- * Copyright (C) 2015 Chris Pavlina pavlina.ch...@gmail.com
- * Copyright (C) 2015 KiCad Developers, see change_log.txt for contributors.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version 2
- * of the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, you may find one here:
- * http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
- * or you may search the http://www.gnu.org website for the version 2 license,
- * or you may
[Kicad-developers] [PATCH] Fix build error from 5803
Found the problem in the rescue update - left a couple unused variable declarations behind, which were no longer valid. Not sure why clang was okay with them, it shouldn't have been. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Fix build error from 5803
Oh, wow. God, I'm a bloody idiot.
Third time's the charm?
On Mon, Jun 22, 2015 at 02:13:40PM -0400, Chris Pavlina wrote:
Found the problem in the rescue update - left a couple unused variable
declarations behind, which were no longer valid. Not sure why clang was
okay with them, it shouldn't have been.
--
Chris
commit 1ffd93a238adcec2ae485ab1eaf4fe0ffddf8d17
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Mon Jun 22 14:12:18 2015 -0400
Remove unused variables which caused build error
diff --git a/eeschema/project_rescue.cpp b/eeschema/project_rescue.cpp
index 7150928..fe5dbfd 100644
--- a/eeschema/project_rescue.cpp
+++ b/eeschema/project_rescue.cpp
@@ -487,10 +487,6 @@ void RESCUER::UndoRescues()
bool SCH_EDIT_FRAME::RescueProject( bool aRunningOnDemand )
{
-// Data that will be used throughout the operation
-std::vectorRESCUE_CANDIDATE candidates;
-wxStringpart_name_suffix;
-
RESCUER rescuer( *this, Prj() );
rescuer.FindCandidates();
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Stable release update.
On Sat, Jun 20, 2015 at 09:14:14PM +0100, David J S Briscoe wrote: [snip] I'm afraid I will screw up the files on Github so probably better for me to do it the old fashioned way. Who can I send the edited files to? If you do this, someone will have to convert them back to AsciiDoc *by hand*. The AsciiDoc is the original source now. You'll have to learn git. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] lib-cache-rescue upgrade
No - I attached another in response to JP's recent mail about Coverity.
Here it is again:
Chris,
Is this patch good to go? I'm having trouble keeping up with the patch
volume so I want to make sure before I commit it.
Thanks,
Wayne
On 6/18/2015 3:07 PM, Chris Pavlina wrote:
Hi all,
It's come to my attention that we have another old project compatibility
issue:
https://forum.kicad.info/t/exisiting-schematic-component-not-being-found-in-library-error/976
The behavior when loading a very old project with case-insensitive part
names isn't nice at all, there's no easy way to change them over. It
gives suggestions for new part names, but you still have to change them
one by one.
I adapted lib-cache-rescue into a more generic project-rescue, which can
handle multiple types of rescue cases, and added one for missing symbols
with differently cased versions available.
It looks roughly like this now (though I've changed the descriptive text
at the top since taking that screenshot):
http://misc.c4757p.com/newrescue.png
Please, as many people as possible, try this out.
--
Chris
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
diff --git a/eeschema/CMakeLists.txt b/eeschema/CMakeLists.txt
index 0982735..d6cc1cd 100644
--- a/eeschema/CMakeLists.txt
+++ b/eeschema/CMakeLists.txt
@@ -114,7 +114,6 @@ set( EESCHEMA_SRCS
libedit_undo_redo.cpp
lib_arc.cpp
lib_bezier.cpp
-lib_cache_rescue.cpp
lib_circle.cpp
lib_collectors.cpp
lib_draw_item.cpp
@@ -139,6 +138,7 @@ set( EESCHEMA_SRCS
plot_schematic_PS.cpp
plot_schematic_PDF.cpp
plot_schematic_SVG.cpp
+project_rescue.cpp
sch_base_frame.cpp
sch_bitmap.cpp
sch_bus_entry.cpp
diff --git a/eeschema/class_library.cpp b/eeschema/class_library.cpp
index 4fac061..bbda657 100644
--- a/eeschema/class_library.cpp
+++ b/eeschema/class_library.cpp
@@ -38,7 +38,7 @@
#include richio.h
#include config_params.h
#include wildcards_and_files_ext.h
-#include lib_cache_rescue.h
+#include project_rescue.h
//#include richio.h
#include general.h
diff --git a/eeschema/dialogs/dialog_rescue_each.cpp b/eeschema/dialogs/dialog_rescue_each.cpp
index 8b896f4..31c424a 100644
--- a/eeschema/dialogs/dialog_rescue_each.cpp
+++ b/eeschema/dialogs/dialog_rescue_each.cpp
@@ -32,7 +32,7 @@
#include set
#include vector
#include boost/foreach.hpp
-#include lib_cache_rescue.h
+#include project_rescue.h
#include eeschema_config.h
class DIALOG_RESCUE_EACH: public DIALOG_RESCUE_EACH_BASE
@@ -43,24 +43,19 @@ public:
* This dialog asks the user which rescuable, cached parts he wants to rescue.
* Any rejects will be pruned from aCandidates.
* @param aCaller - the SCH_EDIT_FRAME calling this
- * @param aCandidates - the list of RESCUE_CANDIDATES
- * @param aComponents - a vector of all the components in the schematic
+ * @param aRescuer - the active RESCUER instance
* @param aAskShowAgain - if true, a Never Show Again button will be included
*/
-DIALOG_RESCUE_EACH( SCH_EDIT_FRAME* aParent, std::vectorRESCUE_CANDIDATE aCandidates,
-std::vectorSCH_COMPONENT* aComponents, bool aAskShowAgain );
+DIALOG_RESCUE_EACH( SCH_EDIT_FRAME* aParent, RESCUER aRescuer, bool aAskShowAgain );
~DIALOG_RESCUE_EACH();
private:
SCH_EDIT_FRAME* m_Parent;
wxConfigBase* m_Config;
-std::vectorRESCUE_CANDIDATE* m_Candidates;
-std::vectorSCH_COMPONENT** m_Components;
+RESCUER*m_Rescuer;
boolm_AskShowAgain;
-bool m_insideUpdateEvent;
-
bool TransferDataToWindow();
bool TransferDataFromWindow();
void PopulateConflictList();
@@ -75,31 +70,22 @@ private:
};
-DIALOG_RESCUE_EACH::DIALOG_RESCUE_EACH( SCH_EDIT_FRAME* aParent, std::vectorRESCUE_CANDIDATE aCandidates,
-std::vectorSCH_COMPONENT* aComponents, bool aAskShowAgain )
-
+DIALOG_RESCUE_EACH::DIALOG_RESCUE_EACH( SCH_EDIT_FRAME* aParent, RESCUER aRescuer,
+bool aAskShowAgain )
: DIALOG_RESCUE_EACH_BASE( aParent ),
m_Parent( aParent ),
- m_Candidates( aCandidates ),
- m_Components( aComponents ),
- m_AskShowAgain( aAskShowAgain ),
- m_insideUpdateEvent( false )
+ m_Rescuer( aRescuer ),
+ m_AskShowAgain( aAskShowAgain )
{
m_Config = Kiface().KifaceSettings();
m_stdButtonsOK-SetDefault();
// Set the info message, customized to include the proper suffix.
-wxString info_message;
-info_message.Printf
Re: [Kicad-developers] Interesting compiler warning
That's what I thought. Okay - I'm putting together a few patches for a few interesting warnings, I'll include this. (I'll keep the patches separate this time so you can easily disregard ones you don't agree with.) On Fri, Jun 26, 2015 at 03:25:18PM +0200, jp charras wrote: Le 26/06/2015 15:19, Chris Pavlina a écrit : Hi, clang gives this warning a couple times: [ 45%] Building CXX object polygon/CMakeFiles/polygon.dir/math_for_graphics.cpp.o /home/cmp/git/kicad/polygon/math_for_graphics.cpp:71:39: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value] *dist = std::min( abs( a - xi ), abs( a - xf ) ); ^ /home/cmp/git/kicad/polygon/math_for_graphics.cpp:71:39: note: use function 'std::abs' instead *dist = std::min( abs( a - xi ), abs( a - xf ) ); ^~~ std::abs Can someone familiar with that section have a look and see if that is indeed the desired behavior? I'm thinking this will cause some rounding errors in potentionally subtle places. -- Chris should be std::abs. Generally speaking, only std::min, std::max std::abs should be used in Kicad code. -- 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
[Kicad-developers] cvpcb netlist behavior
Hi, Lately I've noticed a whole bunch of people coming into the IRC channel confused by the new behavior of cvpcb. Since it now pushes changes back to eeschema instead of writing a file, there is an extra step: you have to go back into eeschema and export the netlist again. A lot of people are seeing the Cannot add new component due to missing footprint messages and thinking there's a bug. Any chance of adjusting this behavior before the release to stop the confusion? Perhaps cvpcb could trigger a netlist write on save, or maybe pcbnew could use kiway to see the update footprints and pull them in / warn about them. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH] Rescue UX fixes
Hi,
Attached is a patch to fix a few annoyances people have been having with
project_rescue. I know it's not a true bug fix in that nothing is
crashing or eating data, but the whole idea of project_rescue is to be
easy for newbies who don't understand why their old projects don't load
under the new release, and I'd like to get this fixed up and ready to go
before the release...
- Slightly change the info text in the dialog. Add a definition of
exactly what it means to rescue a component, and add a line break
that makes it more readable.
- Reload the project libraries when a project is opened, even if kicad
is already running and the same project is open. I've heard confusion
a couple times now about the fact that if you cancel rescue, save and
reopen, it shows up again (because even though eeschema writes out the
-cache.lib, it's not reloaded).
- Set the Modified flag on cancel, because a change has indeed been
made (choosing not to rescue is equivalent to updating the
components). Save seems to be the first place people go after
pressing cancel, and they're confused that it's greyed out.
Thanks.
--
Chris
commit faada345467f40e1b5b35b73b6112cc6849eb838
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Sat Jun 27 11:52:47 2015 -0400
Rescue improvements
diff --git a/eeschema/dialogs/dialog_rescue_each.cpp b/eeschema/dialogs/dialog_rescue_each.cpp
index 69fc5ec..ac804ba 100644
--- a/eeschema/dialogs/dialog_rescue_each.cpp
+++ b/eeschema/dialogs/dialog_rescue_each.cpp
@@ -84,8 +84,9 @@ DIALOG_RESCUE_EACH::DIALOG_RESCUE_EACH( SCH_EDIT_FRAME* aParent, RESCUER aRescu
wxString info_message =
_( It looks like this project was made using older schematic component libraries.\n
Some parts may need to be relinked to a different symbol name, and some symbols\n
- may need to be \rescued\ into a new library.\n
- The following changes are recommended to update the project.\n );
+ may need to be \rescued\ (cloned and renamed) into a new library.\n
+ \n
+ The following changes are recommended to update the project. );
m_lblInfo-SetLabel( info_message );
}
diff --git a/eeschema/files-io.cpp b/eeschema/files-io.cpp
index 3bf97b9..c09ab2d 100644
--- a/eeschema/files-io.cpp
+++ b/eeschema/files-io.cpp
@@ -285,6 +285,7 @@ bool SCH_EDIT_FRAME::OpenProjectFiles( const std::vectorwxString aFileSet, in
// event handler in there.
// And when a schematic file is loaded, we need these libs to initialize
// some parameters (links to PART LIB, dangling ends ...)
+Prj().SetElem( PROJECT::ELEM_SCH_PART_LIBS, NULL );
Prj().SchLibs();
if( is_new )
diff --git a/eeschema/project_rescue.cpp b/eeschema/project_rescue.cpp
index 5645787..ce07852 100644
--- a/eeschema/project_rescue.cpp
+++ b/eeschema/project_rescue.cpp
@@ -330,7 +330,7 @@ public:
wxString part_name( each_component-GetPartName() );
LIB_PART* cache_match = find_component( part_name, aRescuer.GetLibs(), /* aCached */ true );
-LIB_PART* lib_match = find_component( part_name, aRescuer.GetLibs(), /* aCached */ false );
+LIB_PART* lib_match = aRescuer.GetLibs()-FindLibPart( part_name );
// Test whether there is a conflict
if( !cache_match || !lib_match )
@@ -514,6 +514,10 @@ bool SCH_EDIT_FRAME::RescueProject( bool aRunningOnDemand )
{
wxMessageDialog dlg( this, _( No symbols were rescued. ) );
dlg.ShowModal();
+
+// Set the modified flag even on Cancel. Many users seem to instinctively want to Save at
+// this point, due to the reloading of the symbols, so we'll make the save button active.
+OnModify();
return true;
}
___
Mailing list: https://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] Questionable code
/files-io.cpp
@@ -43,7 +43,7 @@
#include sch_sheet_path.h
#include sch_component.h
#include wildcards_and_files_ext.h
-#include lib_cache_rescue.h
+#include project_rescue.h
#include eeschema_config.h
@@ -307,7 +307,7 @@ bool SCH_EDIT_FRAME::OpenProjectFiles( const std::vectorwxString aFileSet, in
UpdateFileHistory( fullFileName );
-// Check to see whether some old, cached library parts need to be rescued
+// Check to see whether some old library parts need to be rescued
// Only do this if RescueNeverShow was not set.
wxConfigBase *config = Kiface().KifaceSettings();
bool rescueNeverShow = false;
@@ -315,7 +315,7 @@ bool SCH_EDIT_FRAME::OpenProjectFiles( const std::vectorwxString aFileSet, in
if( !rescueNeverShow )
{
-if( RescueCacheConflicts( false ) )
+if( RescueProject( false ) )
{
GetScreen()-CheckComponentsToPartsLinks();
GetScreen()-TestDanglingEnds();
diff --git a/eeschema/invoke_sch_dialog.h b/eeschema/invoke_sch_dialog.h
index 0a9cbe4..e4395ee 100644
--- a/eeschema/invoke_sch_dialog.h
+++ b/eeschema/invoke_sch_dialog.h
@@ -48,8 +48,7 @@ class wxDialog;
class LIB_PART;
class PART_LIBS;
class SCH_COMPONENT;
-class RESCUE_CANDIDATE;
-class RESCUE_LOG;
+class RESCUER;
// Often this is not used in the prototypes, since wxFrame is good enough and would
// represent maximum information hiding.
@@ -60,12 +59,10 @@ class SCH_EDIT_FRAME;
* This dialog asks the user which rescuable, cached parts he wants to rescue.
* Any rejects will be pruned from aCandidates.
* @param aCaller - the SCH_EDIT_FRAME calling this
- * @param aCandidates - the list of RESCUE_CANDIDATES
- * @param aComponents - a vector of all the components in the schematic
+ * @param aRescuer - the active RESCUER instance
* @param aAskShowAgain - if true, a Never Show Again button will be included
*/
-int InvokeDialogRescueEach( SCH_EDIT_FRAME* aCaller, std::vectorRESCUE_CANDIDATE aCandidates,
-std::vectorSCH_COMPONENT* aComponents, bool aAskShowAgain );
+int InvokeDialogRescueEach( SCH_EDIT_FRAME* aCaller, RESCUER aRescuer, bool aAskShowAgain );
/// Create and show DIALOG_ANNOTATE and return whatever
/// DIALOG_ANNOTATE::ShowModal() returns.
diff --git a/eeschema/lib_cache_rescue.cpp b/eeschema/lib_cache_rescue.cpp
deleted file mode 100644
index da74997..000
--- a/eeschema/lib_cache_rescue.cpp
+++ /dev/null
@@ -1,385 +0,0 @@
-/*
- * This program source code file is part of KiCad, a free EDA CAD application.
- *
- * Copyright (C) 2015 Chris Pavlina pavlina.ch...@gmail.com
- * Copyright (C) 2015 KiCad Developers, see change_log.txt for contributors.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version 2
- * of the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, you may find one here:
- * http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
- * or you may search the http://www.gnu.org website for the version 2 license,
- * or you may write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
- */
-
-#include class_drawpanel.h
-#include class_library.h
-#include confirm.h
-#include invoke_sch_dialog.h
-#include kicad_device_context.h
-#include lib_cache_rescue.h
-#include sch_component.h
-#include sch_sheet.h
-#include schframe.h
-#include wildcards_and_files_ext.h
-
-#include boost/foreach.hpp
-#include map
-
-
-typedef std::pairSCH_COMPONENT*, wxString COMPONENT_NAME_PAIR;
-
-
-/**
- * Function save_library
- * writes the library out to disk. Returns true on success.
- *
- * @param aFileName - Filename to receive the library
- * @param aLibrary - Library to write
- * @param aEditFrame - the calling SCH_EDIT_FRAME
- */
-static bool save_library( const wxString aFileName, PART_LIB* aLibrary, SCH_EDIT_FRAME* aEditFrame )
-{
-try
-{
-FILE_OUTPUTFORMATTER formatter( aFileName );
-
-if( !aLibrary-Save( formatter ) )
-{
-wxString msg = wxString::Format( _(
-An error occurred attempting to save component library '%s'. ),
-GetChars( aFileName )
-);
-DisplayError( aEditFrame, msg );
-return false;
-}
-}
-catch( ... /* IO_ERROR ioe */ )
-{
-wxString msg = wxString::Format( _(
-Failed to create component library file '%s' ),
-GetChars( aFileName
Re: [Kicad-developers] [PATCH] Compile warning cleanups
The warning is definitely valid, for the reason I explained. You're comparing a negative value to a value that is allowed to (and explicitly declared to, in some compiler versions according to a preprocessor directive) be unsigned. Compilers can, and some will, assume that the comparison is false because an unsigned value can never be negative. This isn't a bogus warning. In any case, I've no problem with only posting true bugfix patches from now on. On Fri, Jun 26, 2015 at 07:54:26PM -0400, Wayne Stambaugh wrote: I committed patches 1 2 for the time being. I'm not completely sold enum part of patch 3. Using a word like tautological always makes me suspicious. :). Please don't assume a compiler warning is bad code and that the person who wrote the code didn't understand what they were doing. Too many developers put way too much stock in compiler warnings. Sometimes they are valid but more often than not they are benign or worse noise that distracts developers from real issues. From now until the stable release, please only post patches that fix actual bugs. Thanks, Wayne On 6/26/2015 1:58 PM, Chris Pavlina wrote: Hi, Attached are three patches to clean up some compiler warnings from clang. 1: replace abs() with std::abs() in polygon/math_for_graphics.cpp This is the correct usage. The math is being done from double to double, but abs() is an integer function. std::abs() will return the correct types. 2: delete a couple unused variables 3: correct a couple tautological comparisons By defining UNDEFINED_LAYER and UNSELECTED_LAYER as follows: #define UNDEFINED_LAYER LAYER_ID(-1) #define UNSELECTED_LAYERLAYER_ID(-2) enum LAYER_ID is allowed to be an unsigned type (in fact, it is explicitly declared to be one). A compiler is totally free to assume that any comparison between this unsigned enum and a negative value is false by definition and not actually perform the comparison. Currently we aren't having this problem, but because it's allowed, it could become a problem in the future with different or newer compilers and different optimization settings. I removed the explicit declaration of the enum as unsigned and defined UNDEFINED_LAYER and UNSELECTED_LAYER _in_ the enum. In polygon/poly2tri/sweep/sweep.cc, the address of a reference is tested against NULL. This is a similar tautological comparison because C++ explicitly disallows references to NULL. I changed this to a pointer type (which had the added benefit of making it more consistent with the other functions in the file). -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Compile warning cleanups
On Fri, Jun 26, 2015 at 08:12:21PM -0400, Wayne Stambaugh wrote: On 6/26/2015 8:02 PM, Chris Pavlina wrote: The warning is definitely valid, for the reason I explained. You're comparing a negative value to a value that is allowed to (and explicitly declared to, in some compiler versions according to a preprocessor directive) be unsigned. Compilers can, and some will, assume that the comparison is false because an unsigned value can never be negative. This isn't a bogus warning. While agree with you on a technical level, reality may be somewhat different. Do you have any evidence that the existing code is producing buggy behavioral results within the layer manipulation code that uses this enumeration? If so, than this patch is a no brainer and I will commit it. If not, it fixes nothing other than a compiler warning. Nope - I specifically said, it doesn't produce any known bugs _now_, but it will with different compilers or compiler settings and so is a potential trap for the future. I will definitely argue that this patch is a Good Thing and cleans up the code - the way it's written now is quite bizarre - but if you want to do only /true/ bugfixes and not cleanup until stable, that's fine by me, I'll sit on it. In any case, I've no problem with only posting true bugfix patches from now on. Not from now on. Only until after the stable release. Once the stable release is done, we can resume with new features and compiler warning fixes. Yeah, that's what I meant :) On Fri, Jun 26, 2015 at 07:54:26PM -0400, Wayne Stambaugh wrote: I committed patches 1 2 for the time being. I'm not completely sold enum part of patch 3. Using a word like tautological always makes me suspicious. :). Please don't assume a compiler warning is bad code and that the person who wrote the code didn't understand what they were doing. Too many developers put way too much stock in compiler warnings. Sometimes they are valid but more often than not they are benign or worse noise that distracts developers from real issues. From now until the stable release, please only post patches that fix actual bugs. Thanks, Wayne On 6/26/2015 1:58 PM, Chris Pavlina wrote: Hi, Attached are three patches to clean up some compiler warnings from clang. 1: replace abs() with std::abs() in polygon/math_for_graphics.cpp This is the correct usage. The math is being done from double to double, but abs() is an integer function. std::abs() will return the correct types. 2: delete a couple unused variables 3: correct a couple tautological comparisons By defining UNDEFINED_LAYER and UNSELECTED_LAYER as follows: #define UNDEFINED_LAYER LAYER_ID(-1) #define UNSELECTED_LAYERLAYER_ID(-2) enum LAYER_ID is allowed to be an unsigned type (in fact, it is explicitly declared to be one). A compiler is totally free to assume that any comparison between this unsigned enum and a negative value is false by definition and not actually perform the comparison. Currently we aren't having this problem, but because it's allowed, it could become a problem in the future with different or newer compilers and different optimization settings. I removed the explicit declaration of the enum as unsigned and defined UNDEFINED_LAYER and UNSELECTED_LAYER _in_ the enum. In polygon/poly2tri/sweep/sweep.cc, the address of a reference is tested against NULL. This is a similar tautological comparison because C++ explicitly disallows references to NULL. I changed this to a pointer type (which had the added benefit of making it more consistent with the other functions in the file). -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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
[Kicad-developers] [PATCH] More invalid net ID crash fixes
Recently I submitted a patch to catch an error that occurred when loading a kicad_pcb containing invalid net IDs; I missed a couple spots. Here's another patch to fix the rest of them. -- Chris commit 98126b8cfba53c52119f809b094cbae266b41b75 Author: Chris Pavlina cpavl...@binghamton.edu Date: Thu Jun 11 19:44:14 2015 -0400 Correct remaining invalid net ID crashes diff --git a/pcbnew/pcb_parser.cpp b/pcbnew/pcb_parser.cpp index 500e0c0..898551e 100644 --- a/pcbnew/pcb_parser.cpp +++ b/pcbnew/pcb_parser.cpp @@ -2310,9 +2310,17 @@ D_PAD* PCB_PARSER::parseD_PAD( MODULE* aParent ) throw( IO_ERROR, PARSE_ERROR ) break; case T_net: -pad-SetNetCode( getNetCode( parseInt( net number ) ) ); +if( ! pad-SetNetCode( getNetCode( parseInt( net number ) ), /* aNoAssert */ true ) ) +THROW_IO_ERROR( +wxString::Format( _( invalid net ID in\nfile: %s\nline: %d\noffset: %d ), + GetChars( CurSource() ), CurLineNumber(), CurOffset() ) +); NeedSYMBOLorNUMBER(); -assert( FromUTF8() == m_board-FindNet( pad-GetNetCode() )-GetNetname() ); +if( FromUTF8() != m_board-FindNet( pad-GetNetCode() )-GetNetname() ) +THROW_IO_ERROR( +wxString::Format( _( invalid net ID in\nfile: %s\nline: %d\noffset: %d ), +GetChars( CurSource() ), CurLineNumber(), CurOffset() ) +); NeedRIGHT(); break; @@ -2490,7 +2498,11 @@ VIA* PCB_PARSER::parseVIA() throw( IO_ERROR, PARSE_ERROR ) break; case T_net: -via-SetNetCode( getNetCode( parseInt( net number ) ) ); +if(! via-SetNetCode( getNetCode( parseInt( net number ) ), /* aNoAssert */ true)) +THROW_IO_ERROR( +wxString::Format( _( invalid net ID in\nfile: %s\nline: %d\noffset: %d ), + GetChars( CurSource() ), CurLineNumber(), CurOffset() ) +); NeedRIGHT(); break; @@ -2550,7 +2562,11 @@ ZONE_CONTAINER* PCB_PARSER::parseZONE_CONTAINER() throw( IO_ERROR, PARSE_ERROR ) if( tmp 0 ) tmp = 0; -zone-SetNetCode( tmp ); +if( ! zone-SetNetCode( tmp, /* aNoAssert */ true ) ) +THROW_IO_ERROR( +wxString::Format( _( invalid net ID in\nfile: %s\nline: %d\noffset: %d ), + GetChars( CurSource() ), CurLineNumber(), CurOffset() ) +); NeedRIGHT(); break; ___ Mailing list: https://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] Autosave assertion failure workaround
When eeschema attempts to autosave a schematic that hasn't been saved before, an assertion (common/basicframe.cpp:656) fails. Here's a patch that works around that. I call this a workaround rather than a fix because I'd rather autosave still work for things that don't have a filename yet, but that has to be done more carefully. It would require a check at startup for a backup file saved to a predetermined location (ideally somewhere within either /tmp or ~/.kicad on Linux, and the equivalent locations on other systems). -- Chris commit f56c975823f66fa690ca44a35a2dd96f0dc6d831 Author: Chris Pavlina cpavl...@binghamton.edu Date: Tue Jun 16 11:36:51 2015 -0400 Workaround for autosave assertion failure diff --git a/eeschema/files-io.cpp b/eeschema/files-io.cpp index 4ef6572..39922f5 100644 --- a/eeschema/files-io.cpp +++ b/eeschema/files-io.cpp @@ -509,6 +509,9 @@ bool SCH_EDIT_FRAME::doAutoSave() tmp.AssignDir( fn.GetPath() ); +if( !tmp.IsOk() ) +return false; + if( !IsWritable( tmp ) ) return false; ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH] Show bus entry joining two wires as dangling
Another improvement to the pin/entry targets: if a bus entry is drawn between
two WIRES (not a wire and a bus, or two buses), it looks like it's connecting
the wires together, but doesn't actually represent a connection. This patch
makes it display as dangling in that case, to make it clear to the user that
a connection has not actually been made.
--
Chris
commit 04217c50d45ce0ed4e291c24e559da133aa4e181
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Mon Jun 15 11:05:25 2015 -0400
Show bus entry joining two wires as dangling
diff --git a/eeschema/sch_bus_entry.cpp b/eeschema/sch_bus_entry.cpp
index c655750..1819cae 100644
--- a/eeschema/sch_bus_entry.cpp
+++ b/eeschema/sch_bus_entry.cpp
@@ -258,6 +258,12 @@ bool SCH_BUS_ENTRY_BASE::IsDanglingStateChanged( std::vectorDANGLING_END_ITEM
// when the end position is found.
wxPoint seg_start;
+// Special case: if both items are wires, show as dangling. This is because
+// a bus entry between two wires will look like a connection, but does NOT
+// actually represent one. We need to clarify this for the user.
+bool start_is_wire = false;
+bool end_is_wire = false;
+
BOOST_FOREACH( DANGLING_END_ITEM each_item, aItemList )
{
if( each_item.GetItem() == this )
@@ -269,17 +275,29 @@ bool SCH_BUS_ENTRY_BASE::IsDanglingStateChanged( std::vectorDANGLING_END_ITEM
case BUS_START_END:
seg_start = each_item.GetPosition();
break;
+
case WIRE_END_END:
+if( IsPointOnSegment( seg_start, each_item.GetPosition(), m_pos ) )
+start_is_wire = true;
+if( IsPointOnSegment( seg_start, each_item.GetPosition(), m_End() ) )
+end_is_wire = true;
+// Fall through
+
case BUS_END_END:
if( IsPointOnSegment( seg_start, each_item.GetPosition(), m_pos ) )
m_isDanglingStart = false;
if( IsPointOnSegment( seg_start, each_item.GetPosition(), m_End() ) )
m_isDanglingEnd = false;
+break;
default:
break;
}
}
+// See above: show as dangling if joining two wires
+if( start_is_wire end_is_wire )
+m_isDanglingStart = m_isDanglingEnd = true;
+
return (previousStateStart != m_isDanglingStart) || (previousStateEnd != m_isDanglingEnd);
}
___
Mailing list: https://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] LIB_TEXT bounding boxes
Hi all,
While working on that field autoplace feature, I noticed that
LIB_PART::GetBodyBoundingBox was returning incorrect bounding boxes when
the parts contained a LIB_TEXT. Further investigation revealed that
there was an extra negation of the vertical dimension somewhere in the
mix. The trouble is, there appear to be multiple of these, because
adding or removing negations would fix it in this place, but would cause
other troubles (text rendering in the wrong spot in libedit, or clicks
not being received). The only way I found that worked was to
special-case LIB_TEXT inside LIB_PART::GetBodyBoundingBox, negating both
the Y position and Y size. Ugly hack attached.
Anyone familiar enough to have a guess as to what the real problem is,
without me spending hours digging into the entirety of the bounding box
code? The ugly hack works, but... ew.
--
Chris
commit c2a1607092013825312608a454f3861fd4b07547
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Tue Jun 16 17:59:28 2015 -0400
Preliminary fix for eeschema text bounding boxes
diff --git a/eeschema/class_libentry.cpp b/eeschema/class_libentry.cpp
index 2ba8989..81429c8 100644
--- a/eeschema/class_libentry.cpp
+++ b/eeschema/class_libentry.cpp
@@ -1142,6 +1142,7 @@ bool LIB_PART::LoadFootprints( LINE_READER aLineReader, wxString aErrorMsg )
const EDA_RECT LIB_PART::GetBoundingBox( int aUnit, int aConvert ) const
{
EDA_RECT bBox( wxPoint( 0, 0 ), wxSize( 0, 0 ) );
+bool first = true;
for( unsigned ii = 0; ii drawings.size(); ii++ )
{
@@ -1157,7 +1158,21 @@ const EDA_RECT LIB_PART::GetBoundingBox( int aUnit, int aConvert ) const
if ( ( item.Type() == LIB_FIELD_T ) !( ( LIB_FIELD ) item ).IsVisible() )
continue;
-bBox.Merge( item.GetBoundingBox() );
+EDA_RECT item_bb = item.GetBoundingBox();
+
+if( item.Type() == LIB_TEXT_T || item.Type() == LIB_FIELD_T )
+{
+item_bb.SetY( -item_bb.GetY() );
+item_bb.SetSize( item_bb.GetSize().x, -item_bb.GetSize().y );
+}
+
+if( first )
+{
+bBox = item_bb;
+first = false;
+}
+else
+bBox.Merge( item_bb );
}
return bBox;
@@ -1167,6 +1182,7 @@ const EDA_RECT LIB_PART::GetBoundingBox( int aUnit, int aConvert ) const
const EDA_RECT LIB_PART::GetBodyBoundingBox( int aUnit, int aConvert ) const
{
EDA_RECT bBox( wxPoint( 0, 0 ), wxSize( 0, 0 ) );
+bool first = true;
for( unsigned ii = 0; ii drawings.size(); ii++ )
{
@@ -1182,7 +1198,21 @@ const EDA_RECT LIB_PART::GetBodyBoundingBox( int aUnit, int aConvert ) const
if ( item.Type() == LIB_FIELD_T )
continue;
-bBox.Merge( item.GetBoundingBox() );
+EDA_RECT item_bb = item.GetBoundingBox();
+
+if( item.Type() == LIB_TEXT_T )
+{
+item_bb.SetY( -item_bb.GetY() );
+item_bb.SetSize( item_bb.GetSize().x, -item_bb.GetSize().y );
+}
+
+if( first )
+{
+bBox = item_bb;
+first = false;
+}
+else
+bBox.Merge( item_bb );
}
return bBox;
___
Mailing list: https://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] Scripting
Oh, sweet! I'll definitely contribute to this. Hopefully we can get it in usable condition soon. Thanks! On Sun, Jun 14, 2015 at 12:23:16PM +0200, Miguel Angel Ajo wrote: I can't do more than agree, and this is why (very slowly) I'm working on this: https://github.com/kicad/kicad-python https://github.com/KiCad/kicad-python/blob/master/doc/source/index.rst https://github.com/KiCad/kicad-python/blob/master/kicad/pcbnew/board.py https://github.com/KiCad/kicad-python/blob/master/tests/unit/pcbnew/test_pcbnew_board.py This is a work that Piers Titus van der Torren started, and that I perverted a bit to add documentation, testing, and trying to keep uniformity across all object interfaces. If you want to contribute, it can be done via pull requests to the main repository, those are automatically checked by CI, and reported back to github. I haven't wrote any rules yet, but I really believe we should: 1) Document as we code 2) Write unit tests as we code So we avoid regressions and provide a very consistent API for the users, where we can detect regressions or any issues. Chris Pavlina wrote: wrt scripting and SWIG - SWIG's good for generating a low-level wrapper, but if we'd like scripting to go anywhere, I really think we should come up with a more scripting-friendly API and high-level wrapper. Something with more proper iterables, fewer integer enums, fewer getters and setters, objects that are fully and usefully introspectable at the console, etc. Fewer things like this scattered about: http://ci.kicad-pcb.org/job/kicad-doxygen/ws/build/pcbnew/doxygen-python/html/classpcbnew_1_1MODULE.html#a549dccf2a9eecffa83f76cfe8d1a7d19 Anyone else interested in seeing scripting improve? I'd be willing to contribute to this. On Sat, Jun 13, 2015 at 05:26:58PM -0400, Wayne Stambaugh wrote: On 6/12/2015 10:48 AM, Rob Maris wrote: Hi, I'm interested in adding Lua scripting to Kicad as an alternative to Python. Can anybody present some information about complexity and API in order to integrate a lua interpreter? Regards, Rob Rob, There has been some interest in lua in the past. I'm not opposed to adding lua as another scripting language. I not sure if lua can be swigged. That would be the preferred method for generating the lua scripting libraries. To get an idea of the complexity of the kicad API, look at the python swig code and the c++ code documentation at kicad-pcb.org. At this time only Pcbnew is scripted. Eeschema is due a major over hall after the next stable release so I expected it to be scripted at that point. Also, we are pretty much in feature freeze for the next stable release so anything major like supporting another scripting language will have to wait until after the next stable release. Cheers, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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] Mac paths help?
Hi all, I'm looking into prepopulating the list of BOM plugins in eeschema, and further possibly cleaning up resource file access in general. Can I get someone who's using kicad on Mac to run this script in the pcbnew Python console to help me out a bit? import wx; sp = wx.StandardPaths.Get() for i in dir(sp): if not i.startswith(Get): continue try: print(%s:\t%s % (i, getattr(sp, i)())) except Exception: pass You might have to copy and paste it in two blocks as split above...the console's a bit quirky for me. Thanks! -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH] Display pin/entry targets while moving part
This patch displays pin and bus entry targets while they are being
moved, as they are also dangling then (even though the dangling status
has not been updated). This seems to make the interface feel a bit more
responsive, IMO.
--
Chris
commit e2ac9aaff17da3e8cdf3bfb5a698194eb8216d9d
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Sun Jun 14 15:24:47 2015 -0400
Display pin targets while dragging components and bus entries
diff --git a/eeschema/sch_bus_entry.cpp b/eeschema/sch_bus_entry.cpp
index 6b3e3b6..b26d5d6 100644
--- a/eeschema/sch_bus_entry.cpp
+++ b/eeschema/sch_bus_entry.cpp
@@ -195,11 +195,15 @@ void SCH_BUS_ENTRY_BASE::Draw( EDA_DRAW_PANEL* aPanel, wxDC* aDC, const wxPoint
GRLine( clipbox, aDC, m_pos.x + aOffset.x, m_pos.y + aOffset.y,
m_End().x + aOffset.x, m_End().y + aOffset.y, GetPenSize(), color );
-if( m_isDanglingStart ) {
+
+// Draw pin targets if part is being dragged
+bool dragging = ( aPanel-GetScreen()-GetCurItem() == this );
+
+if( m_isDanglingStart || dragging ) {
GRCircle( clipbox, aDC, m_pos.x + aOffset.x, m_pos.y + aOffset.y, TARGET_BUSENTRY_RADIUS, 0, color );
}
-if( m_isDanglingEnd ) {
+if( m_isDanglingEnd || dragging ) {
GRCircle( clipbox, aDC, m_End().x + aOffset.x, m_End().y + aOffset.y, TARGET_BUSENTRY_RADIUS, 0, color );
}
}
diff --git a/eeschema/sch_component.cpp b/eeschema/sch_component.cpp
index dbe2f81..44763d5 100644
--- a/eeschema/sch_component.cpp
+++ b/eeschema/sch_component.cpp
@@ -350,8 +350,11 @@ void SCH_COMPONENT::Draw( EDA_DRAW_PANEL* aPanel, wxDC* aDC, const wxPoint aOff
{
if( PART_SPTR part = m_part.lock() )
{
+// Draw pin targets if part is being dragged
+bool dragging = ( aPanel-GetScreen()-GetCurItem() == this );
+
part-Draw( aPanel, aDC, m_Pos + aOffset, m_unit, m_convert, aDrawMode, aColor,
-m_transform, aDrawPinText, false, false, m_isDangling );
+m_transform, aDrawPinText, false, false, dragging ? NULL : m_isDangling );
}
else// Use dummy() part if the actual cannot be found.
{
___
Mailing list: https://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] Use new footprint selector for Change Footprints
This patch enables use of the new (kiface) footprint selector in the
Exchange Footprints dialog.
As suggested in this bug report: https://bugs.launchpad.net/kicad/+bug/1464821
I'll look into making this change in the module editor as well, but that
will require more work.
--
Chris
commit 6f3c07f0835898bb4cc022b45c586c4aecaef4b2
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Sun Jun 14 16:28:06 2015 -0400
Use new footprint selector for Change Footprints
diff --git a/pcbnew/xchgmod.cpp b/pcbnew/xchgmod.cpp
index 3ae43b8..a481419 100644
--- a/pcbnew/xchgmod.cpp
+++ b/pcbnew/xchgmod.cpp
@@ -43,6 +43,7 @@
#include pcbnew.h
#include dialog_exchange_modules_base.h
#include wildcards_and_files_ext.h
+#include kiway.h
#include boost/bind.hpp
#include tool/tool_manager.h
@@ -95,14 +96,14 @@ void PCB_EDIT_FRAME::InstallExchangeModuleFrame( MODULE* Module )
{
DIALOG_EXCHANGE_MODULE dialog( this, Module );
-dialog.ShowModal();
+dialog.ShowQuasiModal();
}
void DIALOG_EXCHANGE_MODULE::OnQuit( wxCommandEvent event )
{
m_selectionMode = m_Selection-GetSelection();
-EndModal( 0 );
+EndQuasiModal( wxID_CANCEL );
}
@@ -507,11 +508,14 @@ void DIALOG_EXCHANGE_MODULE::BrowseAndSelectFootprint( wxCommandEvent event )
{
wxString newname;
-newname = m_parent-SelectFootprint( m_parent, wxEmptyString, wxEmptyString, wxEmptyString,
- Prj().PcbFootprintLibs() );
+KIWAY_PLAYER* frame = Kiway().Player( FRAME_PCB_MODULE_VIEWER_MODAL, true );
-if( newname != wxEmptyString )
+if( frame-ShowModal( newname, this ) )
+{
m_NewModule-SetValue( newname );
+}
+
+frame-Destroy();
}
___
Mailing list: https://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] Fix LIB_TEXT and LIB_FIELD bounding boxes
You probably saw my thread about the bounding boxes for LIB_TEXT and
LIB_FIELD, which were being merged with the main component bounding box
incorrectly. I tracked down what the bug was:
in ::GetBoundingBox(), the coordinates are inverted because Y
coordinates for LIB_ITEMs are bottom to top. Problem is, the bounding
boxes aren't used that way, they're expected in most places to be
noninverted. The only place the LIB_TEXT bounding box should be inverted
is in ::drawGraphics.
This patch moves the inversion to ::drawGraphics, fixing the bounding
box bug. The overall bounding box is now calculated correctly:
http://misc.c4757p.com/correct_bbox.png
Compare to the original version, where the text object that I moved
upwards caused the box to extend downwards:
http://misc.c4757p.com/bbox_wtf.png
This patch also corrects one other minor bug: the bounding box was
always calculated to include (0,0), even if the component itself doesn't
include this point.
--
Chris
diff --git a/eeschema/class_libentry.cpp b/eeschema/class_libentry.cpp
index 2ba8989..3c33c51 100644
--- a/eeschema/class_libentry.cpp
+++ b/eeschema/class_libentry.cpp
@@ -1142,6 +1142,7 @@ bool LIB_PART::LoadFootprints( LINE_READER aLineReader, wxString aErrorMsg )
const EDA_RECT LIB_PART::GetBoundingBox( int aUnit, int aConvert ) const
{
EDA_RECT bBox( wxPoint( 0, 0 ), wxSize( 0, 0 ) );
+bool first = true;
for( unsigned ii = 0; ii drawings.size(); ii++ )
{
@@ -1157,7 +1158,15 @@ const EDA_RECT LIB_PART::GetBoundingBox( int aUnit, int aConvert ) const
if ( ( item.Type() == LIB_FIELD_T ) !( ( LIB_FIELD ) item ).IsVisible() )
continue;
-bBox.Merge( item.GetBoundingBox() );
+EDA_RECT item_bb = item.GetBoundingBox();
+
+if( first )
+{
+bBox = item_bb;
+first = false;
+}
+else
+bBox.Merge( item_bb );
}
return bBox;
@@ -1167,6 +1176,7 @@ const EDA_RECT LIB_PART::GetBoundingBox( int aUnit, int aConvert ) const
const EDA_RECT LIB_PART::GetBodyBoundingBox( int aUnit, int aConvert ) const
{
EDA_RECT bBox( wxPoint( 0, 0 ), wxSize( 0, 0 ) );
+bool first = true;
for( unsigned ii = 0; ii drawings.size(); ii++ )
{
@@ -1182,7 +1192,15 @@ const EDA_RECT LIB_PART::GetBodyBoundingBox( int aUnit, int aConvert ) const
if ( item.Type() == LIB_FIELD_T )
continue;
-bBox.Merge( item.GetBoundingBox() );
+EDA_RECT item_bb = item.GetBoundingBox();
+
+if( first )
+{
+bBox = item_bb;
+first = false;
+}
+else
+bBox.Merge( item_bb );
}
return bBox;
diff --git a/eeschema/lib_field.cpp b/eeschema/lib_field.cpp
index 3cbc198..f374fa2 100644
--- a/eeschema/lib_field.cpp
+++ b/eeschema/lib_field.cpp
@@ -303,6 +303,12 @@ void LIB_FIELD::drawGraphic( EDA_DRAW_PANEL* aPanel, wxDC* aDC, const wxPoint a
* bounding box calculation. */
#if 0
EDA_RECT bBox = GetBoundingBox();
+/* Y coordinates for LIB_ITEMs are bottom to top, so we must invert the bounding
+ * box vertically when usint it to draw the graphics.
+ */
+bBox.SetY( -bBox.GetY() );
+bBox.SetSize( bBox.GetSize().x, -bBox.GetSize().y );
+
EDA_RECT grBox;
grBox.SetOrigin( aTransform.TransformCoordinate( bBox.GetOrigin() ) );
grBox.SetEnd( aTransform.TransformCoordinate( bBox.GetEnd() ) );
@@ -505,15 +511,10 @@ wxString LIB_FIELD::GetFullText( int unit )
const EDA_RECT LIB_FIELD::GetBoundingBox() const
{
-/* Y coordinates for LIB_ITEMS are bottom to top, so we must invert the Y position when
- * calling GetTextBox() that works using top to bottom Y axis orientation.
- */
EDA_RECT rect = GetTextBox( -1, -1, true );
wxPoint orig = rect.GetOrigin();
wxPoint end = rect.GetEnd();
-NEGATE( orig.y);
-NEGATE( end.y);
RotatePoint( orig, m_Pos, -m_Orient );
RotatePoint( end, m_Pos, -m_Orient );
diff --git a/eeschema/lib_text.cpp b/eeschema/lib_text.cpp
index d4b2a3f..15d0afb 100644
--- a/eeschema/lib_text.cpp
+++ b/eeschema/lib_text.cpp
@@ -388,6 +388,12 @@ void LIB_TEXT::drawGraphic( EDA_DRAW_PANEL* aPanel, wxDC* aDC, const wxPoint aO
* and use GetBoundaryBox to know the text coordinate considered as centered
*/
EDA_RECT bBox = GetBoundingBox();
+
+/* Y coordinates for LIB_ITEMs are bottom to top, so we must invert the bounding
+ * box vertically when using it to draw the graphics.
+ */
+bBox.SetY( -bBox.GetY() );
+bBox.SetSize( bBox.GetSize().x, -bBox.GetSize().y );
wxPoint txtpos = bBox.Centre();
// Calculate pos accordint to mirror/rotation.
@@ -426,15 +432,10 @@ void LIB_TEXT::GetMsgPanelInfo( MSG_PANEL_ITEMS aList )
const EDA_RECT LIB_TEXT::GetBoundingBox() const
{
-/* Y coordinates for LIB_ITEMS are bottom to top, so we must invert the Y position when
- * calling GetTextBox() that
Re: [Kicad-developers] LIB_TEXT bounding boxes
Yeah, I know that much - I'm just trying to figure out where the LIB_TEXT bounding boxes are going /wrong/. Try it - turn on the switch to view the bounding boxes (sch_component.cpp line 382, recommend changing GetBoundingBox on 385 to GetBodyBoundingBox, it's a bit more helpful in this case) and move around some LIB_TEXT instances in a component. The vertical axis is inverted, so that when you move the text downwards, the bounding box grows upwards. On Wed, Jun 17, 2015 at 05:35:43PM +0200, jp charras wrote: Le 17/06/2015 00:11, Chris Pavlina a écrit : Hi all, While working on that field autoplace feature, I noticed that LIB_PART::GetBodyBoundingBox was returning incorrect bounding boxes when the parts contained a LIB_TEXT. Further investigation revealed that there was an extra negation of the vertical dimension somewhere in the mix. The trouble is, there appear to be multiple of these, because adding or removing negations would fix it in this place, but would cause other troubles (text rendering in the wrong spot in libedit, or clicks not being received). The only way I found that worked was to special-case LIB_TEXT inside LIB_PART::GetBodyBoundingBox, negating both the Y position and Y size. Ugly hack attached. Anyone familiar enough to have a guess as to what the real problem is, without me spending hours digging into the entirety of the bounding box code? The ugly hack works, but... ew. -- Chris For historical reasons, the Y axis is bottom to top for coordinates of symbols (graphic items, texts ..) in libraries, and is top to bottom in schematic. When drawing a symbol, a matrix transform is applied to coordinates, to take in account the Y axis orientation, as well as component orientation (rotation, mirroring). -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] LIB_TEXT bounding boxes
I'm looking into it, anyway, just wanted to know if anyone knew much about it. There's always the possibility that I misunderstood something, since I'm working in a section I haven't been in before, so I'd rather dive into it myself than waste your time. I'll submit a patch if there really is a bug here, after I investigate further to figure out /exactly/ what the problem is. On Wed, Jun 17, 2015 at 06:29:56PM +0200, jp charras wrote: Le 17/06/2015 17:39, Chris Pavlina a écrit : Yeah, I know that much - I'm just trying to figure out where the LIB_TEXT bounding boxes are going /wrong/. Try it - turn on the switch to view the bounding boxes (sch_component.cpp line 382, recommend changing GetBoundingBox on 385 to GetBodyBoundingBox, it's a bit more helpful in this case) and move around some LIB_TEXT instances in a component. The vertical axis is inverted, so that when you move the text downwards, the bounding box grows upwards. OK. I see. -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] LIB_TEXT bounding boxes
For the curious, have a look at this bizarre screenshot: http://misc.c4757p.com/bbox_wtf.png I turned on drawing of bounding boxes for both component bodies and LIB_TEXTs - the text's bounding box renders correctly, but it merges with the rest of the component drawing item boxes wrong, growing the box in the wrong direction... My ugly hack patch in the first message fixes this, by special-casing it so that LIB_TEXT and LIB_FIELD items have their boxes inverted **only when merging to get the combined bounding box**. WTF. On Wed, Jun 17, 2015 at 06:29:56PM +0200, jp charras wrote: Le 17/06/2015 17:39, Chris Pavlina a écrit : Yeah, I know that much - I'm just trying to figure out where the LIB_TEXT bounding boxes are going /wrong/. Try it - turn on the switch to view the bounding boxes (sch_component.cpp line 382, recommend changing GetBoundingBox on 385 to GetBodyBoundingBox, it's a bit more helpful in this case) and move around some LIB_TEXT instances in a component. The vertical axis is inverted, so that when you move the text downwards, the bounding box grows upwards. OK. I see. -- 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
[Kicad-developers] [PATCH] Rescue error message not shown
There's a minor bug in lib_cache_rescue - if it fails to insert the new library into the project, the error message for this is not displayed. This patch adds the necessary ShowModal() call. -- Chris commit a2f938a9c25bf1273a9e7c8f8919a0e95b695ff3 Author: Chris Pavlina cpavl...@binghamton.edu Date: Sat Jun 13 16:41:49 2015 -0400 Bugfix: rescue error message not shown diff --git a/eeschema/lib_cache_rescue.cpp b/eeschema/lib_cache_rescue.cpp index 91a545d..da74997 100644 --- a/eeschema/lib_cache_rescue.cpp +++ b/eeschema/lib_cache_rescue.cpp @@ -379,6 +379,7 @@ bool SCH_EDIT_FRAME::RescueCacheConflicts( bool aRunningOnDemand ) rescue_log_item.component-SetPartName( rescue_log_item.old_name ); } wxMessageDialog dlg( this, _( An error occurred while attempting to rescue components. No changes have been made. ) ); +dlg.ShowModal(); return false; } } ___ Mailing list: https://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] Scripting
wrt scripting and SWIG - SWIG's good for generating a low-level wrapper, but if we'd like scripting to go anywhere, I really think we should come up with a more scripting-friendly API and high-level wrapper. Something with more proper iterables, fewer integer enums, fewer getters and setters, objects that are fully and usefully introspectable at the console, etc. Fewer things like this scattered about: http://ci.kicad-pcb.org/job/kicad-doxygen/ws/build/pcbnew/doxygen-python/html/classpcbnew_1_1MODULE.html#a549dccf2a9eecffa83f76cfe8d1a7d19 Anyone else interested in seeing scripting improve? I'd be willing to contribute to this. On Sat, Jun 13, 2015 at 05:26:58PM -0400, Wayne Stambaugh wrote: On 6/12/2015 10:48 AM, Rob Maris wrote: Hi, I'm interested in adding Lua scripting to Kicad as an alternative to Python. Can anybody present some information about complexity and API in order to integrate a lua interpreter? Regards, Rob Rob, There has been some interest in lua in the past. I'm not opposed to adding lua as another scripting language. I not sure if lua can be swigged. That would be the preferred method for generating the lua scripting libraries. To get an idea of the complexity of the kicad API, look at the python swig code and the c++ code documentation at kicad-pcb.org. At this time only Pcbnew is scripted. Eeschema is due a major over hall after the next stable release so I expected it to be scripted at that point. Also, we are pretty much in feature freeze for the next stable release so anything major like supporting another scripting language will have to wait until after the next stable release. Cheers, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Feature freeze.
On Mon, Jun 15, 2015 at 06:29:29PM +0200, jp charras wrote: [[snip]] keywords like UNDEFINED, INFO, WARNING , ERROR are widely used, the risk of collision is high. Usually I use something like: RPT_UNDEFINED, RPT_INFO , RPT_WARNING , RPT_ERROR to avoid this risk. What about namespaces? Thanks. -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
