[Kicad-developers] macOS updates
Hi folks, I am still digesting a lot of the macOS news from today, but have no fear about Python! Lots of folks are freaking out online about future versions of macOS not coming with Python or Ruby or other interpreters, but Apple told us this years ago, and that's why we package Python and bundle it into KiCad.app. (It was a huge pain and took like 6 months, but I feel pretty smug about doing it now :) ) I have to I gotta get back to getting Python 3 working! Adam ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Enable floating point exceptions in Debug, disable in Release
On 2019-05-28 10:51, Simon Richter wrote: Hi, this enables FP exceptions everywhere in Debug mode, and disables them in Release mode. This is for testing only, and should *not* yet go into mainline. Still needed: - signal handler that complains and allows continuing - context library handling - tests Hi Simon- It looks like you are using the gcc extensions here. Any reason not to use std::fesetenv? -Seth ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Show grid in eeschema status line
On 6/3/19 10:42 AM, Wayne Stambaugh wrote:
> Hi Steve,
>
> Your patch no longer applies cleanly as there has been some serious
> refactoring and legacy code removal. I think your patch is a good idea
> but it will need to be fixed. I do have a few comments from your
> original patch:
>
> * Please use `git commit` to commit your code to your local repo and
> `git format-patch` to create patches to send to the mailing list.
Thanks for the review, and for your patience as I "learn the ropes" Wayne.
I've attached a rebased patch using "git format-patch". I generated it both
for master and for 5.1, in case you want it in both branches. Personally, I'd
like it in both.
> * There tabs and indentation errors in your original patch.
I think I've fixed all of those. If I missed any, please let me know.
> * I don't think you need to make the precision of millimeter grid units
> 4. 2 should be more than acceptable given that you are using 3 for
> inches units. You may want to increase this by one for the board
> editor. The board editor has far greater precision than the schematic
> editor.
I chose 4 decimal places because the eeschema grid seems to be in English units
internally, even when I switch the UI to metric. I.e., when I switch eeschema
to metric, the finest grid in the pull-down menu is shown as "0.0254 mm (1.00
mils)". I don't see a way to set the eeschema grid to a round number of mm. I
will be happy to change the display to 2 places if you still want that, but
then the status line will show 0.02 mm rather than 0.0254 mm. Please confirm
which way you want it.
Steve
From 9c652a1a9c7a60927d1f9d043b00d15d809848cc Mon Sep 17 00:00:00 2001
From: "Steven A. Falco"
Date: Fri, 24 May 2019 09:55:33 -0400
Subject: [PATCH] Show the current grid setting.
---
common/legacy_gal/eda_draw_frame.cpp | 28
eeschema/sch_base_frame.cpp | 3 +++
include/draw_frame.h | 5 +
kicad/mainframe.cpp | 6 +++---
4 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/common/legacy_gal/eda_draw_frame.cpp b/common/legacy_gal/eda_draw_frame.cpp
index 6c3a3a47b..d02837ff6 100644
--- a/common/legacy_gal/eda_draw_frame.cpp
+++ b/common/legacy_gal/eda_draw_frame.cpp
@@ -546,6 +546,34 @@ void EDA_DRAW_FRAME::SaveSettings( wxConfigBase* aCfg )
m_galDisplayOptions.WriteConfig( *aCfg, baseCfgName );
}
+void EDA_DRAW_FRAME::DisplayGridMsg()
+{
+wxString line;
+wxString gridformatter;
+
+switch( m_UserUnits )
+{
+case INCHES:
+gridformatter = "grid %.3f";
+break;
+
+case MILLIMETRES:
+gridformatter = "grid %.4f";
+break;
+
+default:
+gridformatter = "grid %f";
+break;
+}
+
+wxRealPoint curr_grid_size = GetScreen()->GetGridSize();
+double grid = To_User_Unit( GetUserUnits(), curr_grid_size.x );
+line.Printf( gridformatter, grid );
+
+SetStatusText( line, 5 );
+}
+
+
void EDA_DRAW_FRAME::AppendMsgPanel( const wxString& textUpper, const wxString& textLower,
COLOR4D color, int pad )
diff --git a/eeschema/sch_base_frame.cpp b/eeschema/sch_base_frame.cpp
index 28b664f77..5b2bd0dbc 100644
--- a/eeschema/sch_base_frame.cpp
+++ b/eeschema/sch_base_frame.cpp
@@ -259,6 +259,9 @@ void SCH_BASE_FRAME::UpdateStatusBar()
// refresh units display
DisplayUnitsMsg();
+
+// refresh grid display
+DisplayGridMsg();
}
diff --git a/include/draw_frame.h b/include/draw_frame.h
index 431c0d1d6..63aa3ab0e 100644
--- a/include/draw_frame.h
+++ b/include/draw_frame.h
@@ -628,6 +628,11 @@ public:
*/
void DisplayUnitsMsg();
+/**
+ * Display current grid pane on the status bar.
+ */
+void DisplayGridMsg();
+
/* interprocess communication */
void CreateServer( int service, bool local = true );
void OnSockRequest( wxSocketEvent& evt );
diff --git a/kicad/mainframe.cpp b/kicad/mainframe.cpp
index 0d1bdd3cd..95d352bde 100644
--- a/kicad/mainframe.cpp
+++ b/kicad/mainframe.cpp
@@ -67,10 +67,10 @@ KICAD_MANAGER_FRAME::KICAD_MANAGER_FRAME( wxWindow* parent,
m_AboutTitle = "KiCad";
// Create the status line (bottom of the frame)
-static const int dims[3] = { -1, -1, 100 };
+static const int dims[4] = { -1, -1, -1, 100 };
-CreateStatusBar( 3 );
-SetStatusWidths( 3, dims );
+CreateStatusBar( 4 );
+SetStatusWidths( 4, dims );
// Give an icon
wxIcon icon;
--
2.21.0
From b9ce731455b69db76749e74c066257a4a1218ecf Mon Sep 17 00:00:00 2001
From: "Steven A. Falco"
Date: Fri, 24 May 2019 09:55:33 -0400
Subject: [PATCH] Show the current grid setting.
---
common/legacy_gal/eda_draw_frame.cpp | 28
common/legacy_wx/eda_draw_frame.cpp | 28
eeschema/sch_base_frame.cpp | 3 +++
include/draw_frame.h | 5 +
Re: [Kicad-developers] Show grid in eeschema status line
Hi Steve, Your patch no longer applies cleanly as there has been some serious refactoring and legacy code removal. I think your patch is a good idea but it will need to be fixed. I do have a few comments from your original patch: * Please use `git commit` to commit your code to your local repo and `git format-patch` to create patches to send to the mailing list. * There tabs and indentation errors in your original patch. * I don't think you need to make the precision of millimeter grid units 4. 2 should be more than acceptable given that you are using 3 for inches units. You may want to increase this by one for the board editor. The board editor has far greater precision than the schematic editor. Thanks, Wayne On 5/24/19 9:55 AM, Steven A. Falco wrote: > On 5/23/19 1:59 PM, Wayne Stambaugh wrote: >> Hey Steve, >> >> Adding "grid" to the coordinates in the status bar is not correct. >> These are the cursor coordinates not the grid coordinates. To add the >> current grid size to the status bar, you would need to add another pane >> to status bar and fetch the current grid setting from the current SCREEN >> object. > > In the attached patch I tried to make the changes you suggested, Wayne. > Please let me know if it is ok, or if there are still problems. > > I find the panes confusing, because mainframe.cpp allocates 3 panes via > "CreateStatusBar( 3 );", but I see higher numbers elsewhere in the code, such > as EDA_DRAW_FRAME::DisplayToolMsg which uses "SetStatusText( msg, 5 );". I > increased the count in mainframe.cpp to 4 to cover the my new grid pane, but > I don't know if I really needed to do that. > > Steve > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://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] Crash Reporter
On 5/31/19 4:23 PM, Tomasz Wlostowski wrote: > On 30/05/2019 21:12, Wayne Stambaugh wrote: >> Nothing was displayed. I was running from the project manager. I even >> crashed the project manager. I'm using msys2 to create mingw32 and >> mingw64 debug builds of KiCad. I'm using wxWidgets 3.0.4 (not a debug >> build). I did not check to see if the msys2 wxWidgets package builds >> are configured with wxDebugReport enabled so maybe that was the issue. >> I'll check the next time I'm in windows. However, your debug reporter >> branch built fine so I suspect this was not the issue. > > Hi Wayne, > > Ddoes any window pop up when you trigger the crash from pcbnew running > in standalone mode? The only other difference I see is my wxWidgets > version is 3.1.1. > > Tom > Tom, I didn't test in the stand alone mode. I'm traveling this week so I wont be able to test with windows again until I get home next weekend. As soon as I test the stand alone mode, I will let you know if it worked any differently than running from KiCad. 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
[Kicad-developers] KiCad templates repo reorganization
A pull request to KiCad templates repository has started a discussion on the need to split or reorganize the structure for this repo [1]. Based on this I've opened a PR [2] that reorganizes the repository into two main folders; one for projects and another one for worksheets. The reorganization required changes in CMake files and I am not native in this language so I would like to request the support and revision of packagers to avoid problems. Another concern would be the fact that the default worksheet file has been moved and that may require further changes in code. Thanks! [1] https://github.com/KiCad/kicad-templates/pull/13#issuecomment-498154971 [2] https://github.com/KiCad/kicad-templates/pull/21 ___ Mailing list: https://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] cvPCB Hotkey Handling
Jeff,
Thanks for taking a look at it and refactoring those actions. I didn't
think it made sense to have them duplicated in cvpcb when they were in
common already.
With the eventual rebuild of the hotkey system it makes sense to hold off
fixing the issues, but I think that 5.1 then should be patched to remove
the references to the hotkeys from the tooltips displayed for the buttons.
Currently, those bindings are hard-coded into the tooltips so users would
expect them to work. If people agree, I can put that patch together.
-Ian
On Sun, Jun 2, 2019 at 3:40 PM Jeff Young wrote:
> Hi Ian,
>
> I just wandered into CVPCB to fix the Show3DView stuff.
>
> While CVPCB did indeed have a different hotkey for unit toggling, I don’t
> think that’s a good enough reason to keep it. So I nuked its action in
> favour of Common.Control.toggleUnits. Same for switching the cursor style.
>
> As for the hotkey issues, I don’t think they’re worth addressing right
> now. For 6.0 we’re planning on re-implementing hotkeys to just be keys
> assigned to actions. The defaults will be defined in the action
> definitions (where we call TOOL_ACTION::LegacyHotKey() today), and the
> config files will just be {action-name, hotkey-sequence} tuples.
>
> Cheers,
> Jeff.
>
> On 31 May 2019, at 23:26, Ian McInerney wrote:
>
> So, I have been able to implement the hotkeys I wanted (Jeff, thanks for
> the pointers), and those changes were in the patchset I just sent. However
> in doing so I discovered that the hotkey infrastructure for the footprint
> viewer window is broken/somewhat a mess. It seems that the hotkeys assigned
> to the CVPCB_ACTIONS work with their assigned hotkeys, but anything from
> the common tools library does not work (such as the zoom functions). Just
> to see, I tried hardcoding the hotkey for zoom to fit to WXK_HOME in
> actions.cpp, and then it worked in the footprint viewer. So it seems that
> cvpcb is not setup to have the proper hotkey bindings for these actions
> since they are defined using a TOOL_ACTION::LegacyHotKey() call.
>
> Additionally, is there a reason to leave cvpcb with its own change units
> action instead of using Common.Control.toggleUnits? The current change
> units toggles the units, but does not toggle the highlighted buttons on the
> toolbar to the left. The cvpcb action also has a different hotkey than the
> one that is used in eeschema/pcbnew (cvpcb has U hardcoded while the others
> have Ctrl-U).
>
> The hotkey issues exist in both the 5.1 and master branches, so it is
> necessary to decide if this is something that should be fixed in 5.1 or
> just left to fix in the 6.0 branch (if the latter, then the text for the
> buttons should be changed to remove the hotkey indication).
>
> I am willing to take on this work, but I would appreciate some guidance as
> to how to move forward (w.r.t to the 5.1/6.0 fixes and with how to get the
> hotkeys into the common tools for cvpcb). I think it would also make the
> most sense if we could standardize these hotkeys with those of pcbnew.
>
> -Ian
>
> On Tue, May 28, 2019 at 7:46 PM Jeff Young wrote:
>
>> D’oh. You’re right: the whole tool framework in cvPCB is just for the
>> Footprint Viewer window.
>>
>> Give a holler if you get stuck.
>>
>> Cheers,
>> Jeff.
>>
>> On 28 May 2019, at 19:17, Ian McInerney wrote:
>>
>> Jeff,
>>
>> Thanks for the pointer. I looked through the CVPCB_ACTIONS code last
>> night, and I came to the conclusion that it is only active in the footprint
>> viewer window (that seems to be where the tool manager for them is
>> instantiated). (also those tools also don't seem to have a
>> user-configurable hotkey either) . I think addding the copy/paste/delete as
>> tools would require some refactoring of the current action code, which I
>> would like to avoid.
>>
>> The method you pointed to in the other window object looks like a good
>> fit for cvpcb (there aren't going to be many hotkeys, and the ones there
>> are will be pretty standard). So I will give that method a try and see how
>> it goes.
>>
>> Thanks,
>> -Ian
>>
>> On Tue, 28 May 2019, 4:07 p.m. Jeff Young, wrote:
>>
>>> Hi Ian,
>>>
>>> The tool architecture allows hotkeys to be assigned to ACTIONs, which
>>> are then executed by a TOOL. So you’d need to define cut/copy/paste
>>> CVPCB_ACTIONs, and also give cvPCB a hotkeys file (and allow them to be
>>> edited).
>>>
>>> But I don’t think we need to support editable hotkeys for
>>> cut/copy/paste/delete. I’d be more inclined to do a light-weight solution
>>> inside the wxWidget. See GRID_TRICKS for an example.
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>
>>> > On 28 May 2019, at 13:29, Ian McInerney
>>> wrote:
>>> >
>>> > I am currently looking into adding some usability features to cvPCB
>>> (copy/paste, single association delete, etc.) and want to also include the
>>> relevant hotkey assignments for them. I am slightly confused where the
>>> hotkey handling for cvPCB is handled though, since I can't see any handling
