Re: [Kicad-developers] Hotkeys Editor

[Chris Pavlina]

I really don't care. The original motivation was simply being able to
cleanly put it as a tab inside the preferences dialog without nesting, I
really didn't think putting them in a single list would make them
undiscoverable (and this is the first I've heard that comment, to be
honest). But I have no real attachment to it. I just hope we don't end
up with nested tabs.

On Fri, Jan 12, 2018 at 03:42:12AM +, Seth Hillbrand wrote:
> Hi All-
> 
> Sorry, this seems to have gotten off-track.  Let's pause the button
> discussion for a moment.  I'm really more concerned about the tree-list
> layout hiding hotkeys from users.  Does anyone feel like we need the
> treelist here?
> 
> Chris, I know this was originally your commit and I don't mean to be overly
> negative about it.  What was the original motivation for it?  Would you be
> open to my modifying it to improve the accessibility?
> 
> Thanks-
> Seth
> 
> On 11. Januar 2018 um 19:24, Andrey Kuznetsov  wrote:
> 
> > If that would be the intended functionality, then I'd suggest "Reset
> > Selected" instead of "Reset".
> >
> > On Thu, Jan 11, 2018 at 5:01 AM, yann jautard  wrote:
> >
> >> what about  keeping four buttons :
> >>
> >> *Defaults* that reset all hotkeys *of the current tab* to default
> >>
> >> *Reset* that reset *the selected* hotkey only to default
> >>
> >> *Cancel* that close the window and undo the current changes
> >>
> >> *Save* that close the window and save the current changes
> >>
> >>
> >> With a tooltip when getting the mouse over each button that clearly says
> >> this.
> >>
> >>
> >>
> >> On 11/01/2018 13:16, Clemens Koller wrote:
> >>
> >>> Hi!
> >>>
> >>> On 2018-01-11 02:07, Seth Hillbrand wrote:
> >>>
>  I don't recall when this change happened but I'd like any feedback on
>  whether folks are adverse
>  to reverting to the 4.0.7 tabbed layout while keeping the "Reset" and
>  "Defaults" buttons,
>  that I think are really good additions.
> 
> >>> I agree, but I still don't understand why we don't use the huge screen
> >>> real-estate we have nowadays on our desks and display all of them in one
> >>> table with i.e. four columns. It would be easy then to check the hotkeys
> >>> across all tools without changing tabs.
> >>> The Buttons "Default" might become "Reset all Hotkeys to Kicad's
> >>> defaults. Are you sure Y/N?"
> >>> The Buttons "Reset" might become "Reset to previous settings" - but that
> >>> might simply be the "Cancel" button.
> >>>
> >>>
> >>> The menu entry Help -> List Hotkeys seems redundant to Preferences ->
> >>> Hotkey Options -> Edit Hotkeys.
> >>> One of the dialogs might be removed.
> >>> In the latest-git, the Hotkey '?' doesn't work for me. I get a beep,
> >>> when I am lucky... usually it is just ignored.
> >>>
> >>> In Eeschema, the Help -> List Hotkeys doesn't show the '?'
> >>> There the Hotkey-Editor can be reached via Preferences -> General
> >>> Options -> Controls Tab...
> >>>
> >>> GUI consistency would improve UX a lot. These are IMO the low-hanging
> >>> fruits to attract users to use Kicad.
> >>>
> >>> Regards,
> >>>
> >>> Clemens
> >>>
> >>> On 2018-01-11 02:07, Seth Hillbrand wrote:
> >>>
>  I feel that there is a usability issue with the current hotkeys editor
>  that is a regression from the 4.0.7 hotkeys editor.
> 
>  I've attached images for both to this message.  The current editor
>  opens with a tree view that hides the hotkeys below "Common".  Users 
>  would
>  be forgiven for not realizing that there were additional hotkeys specific
>  to each application -- see current_hotkeys.png
> 
>  Previously, the hotkeys were displayed in tabs that were, I think, more
>  clear -- see prev_hotkeys.png.
> 
>  I don't recall when this change happened but I'd like any feedback on
>  whether folks are adverse to reverting to the 4.0.7 tabbed layout while
>  keeping the "Reset" and "Defaults" buttons, that I think are really good
>  additions.
> 
>  -S
> 
> 
>  ___
>  Mailing list: https://launchpad.net/~kicad-developers
>  Post to : kicad-developers@lists.launchpad.net
>  Unsubscribe : https://launchpad.net/~kicad-developers
>  More help   : https://help.launchpad.net/ListHelp
> 
>  ___
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> Post to : kicad-developers@lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> >>>
> >>
> >>
> >> ___
> >> Mailing list: https://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] Defer canvas type setting save until destruction of EDA_DRAW_FRAME

[Jon Evans]

Updated patch attached (missed initializers in the original)

On Wed, Jan 10, 2018 at 11:40 PM, Jon Evans  wrote:

> Hopefully this fixes:
> https://bugs.launchpad.net/kicad/+bug/1741787
> although I don't currently have a good way of reproducing the crash.
>
> Chris, if you can give it a try on your crashing machine that would be
> greatly appreciated.
>
> Thanks
> -Jon
>
From 1eb7a5ca257a9e8d0a5dfad08ed74f3a238df2b0 Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Thu, 11 Jan 2018 23:02:18 -0500
Subject: [PATCH] Defer canvas type setting save until destruction of 
 EDA_DRAW_FRAME

Fixes: lp:1741787
* https://bugs.launchpad.net/kicad/+bug/1741787
---
 common/draw_frame.cpp| 5 +
 gerbview/events_called_functions.cpp | 4 +++-
 include/draw_frame.h | 6 ++
 pcbnew/basepcbframe.cpp  | 4 +++-
 4 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/common/draw_frame.cpp b/common/draw_frame.cpp
index bd9342155..49b2df5c6 100644
--- a/common/draw_frame.cpp
+++ b/common/draw_frame.cpp
@@ -142,6 +142,8 @@ EDA_DRAW_FRAME::EDA_DRAW_FRAME( KIWAY* aKiway, wxWindow* aParent,
 m_hotkeysDescrList= NULL;
 
 m_canvas  = NULL;
+m_canvasType  = EDA_DRAW_PANEL_GAL::GAL_TYPE_NONE;
+m_canvasTypeDirty = false;
 m_galCanvas   = NULL;
 m_galCanvasActive = false;
 m_actions = NULL;
@@ -216,6 +218,9 @@ EDA_DRAW_FRAME::EDA_DRAW_FRAME( KIWAY* aKiway, wxWindow* aParent,
 
 EDA_DRAW_FRAME::~EDA_DRAW_FRAME()
 {
+if( m_canvasTypeDirty )
+saveCanvasTypeSetting( m_canvasType );
+
 delete m_actions;
 delete m_toolManager;
 delete m_toolDispatcher;
diff --git a/gerbview/events_called_functions.cpp b/gerbview/events_called_functions.cpp
index 05d611aac..222ff9953 100644
--- a/gerbview/events_called_functions.cpp
+++ b/gerbview/events_called_functions.cpp
@@ -563,10 +563,12 @@ void GERBVIEW_FRAME::SwitchCanvas( wxCommandEvent& aEvent )
 break;
 }
 
-saveCanvasTypeSetting( canvasType );
 UseGalCanvas( use_gal );
 wxUpdateUIEvent e;
 OnUpdateSwitchCanvas( e );
+
+m_canvasType = canvasType;
+m_canvasTypeDirty = true;
 }
 
 
diff --git a/include/draw_frame.h b/include/draw_frame.h
index 899c9784b..6d925eb52 100644
--- a/include/draw_frame.h
+++ b/include/draw_frame.h
@@ -141,6 +141,12 @@ protected:
 /// One-shot to avoid a recursive mouse event during hotkey movement
 boolm_movingCursorWithKeyboard;
 
+/// Flag indicating that drawing canvas type needs to be saved to config
+boolm_canvasTypeDirty;
+
+/// The current canvas type
+EDA_DRAW_PANEL_GAL::GAL_TYPEm_canvasType;
+
 void SetScreen( BASE_SCREEN* aScreen )  { m_currentScreen = aScreen; }
 
 /**
diff --git a/pcbnew/basepcbframe.cpp b/pcbnew/basepcbframe.cpp
index 54ba21cb7..62245fc45 100644
--- a/pcbnew/basepcbframe.cpp
+++ b/pcbnew/basepcbframe.cpp
@@ -958,7 +958,9 @@ void PCB_BASE_FRAME::SwitchCanvas( wxCommandEvent& aEvent )
 }
 
 UseGalCanvas( use_gal );
-saveCanvasTypeSetting( canvasType );
+
+m_canvasType = canvasType;
+m_canvasTypeDirty = true;
 }
 
 
-- 
2.14.1

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

Re: [Kicad-developers] Hotkeys Editor

[Seth Hillbrand]

Hi All-

Sorry, this seems to have gotten off-track.  Let's pause the button
discussion for a moment.  I'm really more concerned about the tree-list
layout hiding hotkeys from users.  Does anyone feel like we need the
treelist here?

Chris, I know this was originally your commit and I don't mean to be overly
negative about it.  What was the original motivation for it?  Would you be
open to my modifying it to improve the accessibility?

Thanks-
Seth

On 11. Januar 2018 um 19:24, Andrey Kuznetsov  wrote:

> If that would be the intended functionality, then I'd suggest "Reset
> Selected" instead of "Reset".
>
> On Thu, Jan 11, 2018 at 5:01 AM, yann jautard  wrote:
>
>> what about  keeping four buttons :
>>
>> *Defaults* that reset all hotkeys *of the current tab* to default
>>
>> *Reset* that reset *the selected* hotkey only to default
>>
>> *Cancel* that close the window and undo the current changes
>>
>> *Save* that close the window and save the current changes
>>
>>
>> With a tooltip when getting the mouse over each button that clearly says
>> this.
>>
>>
>>
>> On 11/01/2018 13:16, Clemens Koller wrote:
>>
>>> Hi!
>>>
>>> On 2018-01-11 02:07, Seth Hillbrand wrote:
>>>
 I don't recall when this change happened but I'd like any feedback on
 whether folks are adverse
 to reverting to the 4.0.7 tabbed layout while keeping the "Reset" and
 "Defaults" buttons,
 that I think are really good additions.

>>> I agree, but I still don't understand why we don't use the huge screen
>>> real-estate we have nowadays on our desks and display all of them in one
>>> table with i.e. four columns. It would be easy then to check the hotkeys
>>> across all tools without changing tabs.
>>> The Buttons "Default" might become "Reset all Hotkeys to Kicad's
>>> defaults. Are you sure Y/N?"
>>> The Buttons "Reset" might become "Reset to previous settings" - but that
>>> might simply be the "Cancel" button.
>>>
>>>
>>> The menu entry Help -> List Hotkeys seems redundant to Preferences ->
>>> Hotkey Options -> Edit Hotkeys.
>>> One of the dialogs might be removed.
>>> In the latest-git, the Hotkey '?' doesn't work for me. I get a beep,
>>> when I am lucky... usually it is just ignored.
>>>
>>> In Eeschema, the Help -> List Hotkeys doesn't show the '?'
>>> There the Hotkey-Editor can be reached via Preferences -> General
>>> Options -> Controls Tab...
>>>
>>> GUI consistency would improve UX a lot. These are IMO the low-hanging
>>> fruits to attract users to use Kicad.
>>>
>>> Regards,
>>>
>>> Clemens
>>>
>>> On 2018-01-11 02:07, Seth Hillbrand wrote:
>>>
 I feel that there is a usability issue with the current hotkeys editor
 that is a regression from the 4.0.7 hotkeys editor.

 I've attached images for both to this message.  The current editor
 opens with a tree view that hides the hotkeys below "Common".  Users would
 be forgiven for not realizing that there were additional hotkeys specific
 to each application -- see current_hotkeys.png

 Previously, the hotkeys were displayed in tabs that were, I think, more
 clear -- see prev_hotkeys.png.

 I don't recall when this change happened but I'd like any feedback on
 whether folks are adverse to reverting to the 4.0.7 tabbed layout while
 keeping the "Reset" and "Defaults" buttons, that I think are really good
 additions.

 -S


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

 ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> --
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss the
> future [JFK]
>
> kandre...@gmail.com
> Live Long and Prosper,
> Andrey
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More 

Re: [Kicad-developers] Libedit and Modedit Icons

[Andrey Kuznetsov]

Awesome, thanks!

Looks good.

On Thu, Jan 11, 2018 at 7:27 PM Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Andrey,
>
> Here's all I can provide currently (at work!)
>
> [image: Inline image 1]
>
> I have sent the entire patch to Wayne and JP privately so the merging is
> now in their capable hands :)
>
> On Fri, Jan 12, 2018 at 2:20 PM, Andrey Kuznetsov 
> wrote:
>
>> Also the attached image of the final icon set was discarded, can you
>> please resend the final icon image set?
>>
>> Thank you
>>
>> On Thu, Jan 11, 2018 at 8:35 AM, jp charras 
>> wrote:
>>
>>> Le 11/01/2018 à 08:54, Oliver Walters a écrit :
>>> > Wayne,
>>> >
>>> > I have taken further suggestions and final icon set is shown below:
>>> >
>>> > [image: Inline image 1]
>>> >
>>> > The attached patch incorporates all of the icon changes thus far
>>> > implemented.
>>> >
>>> > Thanks,
>>> > Oliver
>>> >
>>>
>>> Oliver,
>>>
>>> For some unknown reason, your mail was blocked by Launchpad.
>>> And the attached patch was discarded.
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>> --
>> Remember The Past, Live The Present, Change The Future
>> Those who look only to the past or the present are certain to miss the
>> future [JFK]
>>
>> kandre...@gmail.com
>> Live Long and Prosper,
>> Andrey
>>
>
> --
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

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

Re: [Kicad-developers] Libedit and Modedit Icons

[Oliver Walters]

Andrey,

Here's all I can provide currently (at work!)

[image: Inline image 1]

I have sent the entire patch to Wayne and JP privately so the merging is
now in their capable hands :)

On Fri, Jan 12, 2018 at 2:20 PM, Andrey Kuznetsov 
wrote:

> Also the attached image of the final icon set was discarded, can you
> please resend the final icon image set?
>
> Thank you
>
> On Thu, Jan 11, 2018 at 8:35 AM, jp charras  wrote:
>
>> Le 11/01/2018 à 08:54, Oliver Walters a écrit :
>> > Wayne,
>> >
>> > I have taken further suggestions and final icon set is shown below:
>> >
>> > [image: Inline image 1]
>> >
>> > The attached patch incorporates all of the icon changes thus far
>> > implemented.
>> >
>> > Thanks,
>> > Oliver
>> >
>>
>> Oliver,
>>
>> For some unknown reason, your mail was blocked by Launchpad.
>> And the attached patch was discarded.
>>
>>
>> --
>> 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
>>
>
>
>
> --
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss the
> future [JFK]
>
> kandre...@gmail.com
> Live Long and Prosper,
> Andrey
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Hotkeys Editor

[Andrey Kuznetsov]

If that would be the intended functionality, then I'd suggest "Reset
Selected" instead of "Reset".

On Thu, Jan 11, 2018 at 5:01 AM, yann jautard  wrote:

> what about  keeping four buttons :
>
> *Defaults* that reset all hotkeys *of the current tab* to default
>
> *Reset* that reset *the selected* hotkey only to default
>
> *Cancel* that close the window and undo the current changes
>
> *Save* that close the window and save the current changes
>
>
> With a tooltip when getting the mouse over each button that clearly says
> this.
>
>
>
> On 11/01/2018 13:16, Clemens Koller wrote:
>
>> Hi!
>>
>> On 2018-01-11 02:07, Seth Hillbrand wrote:
>>
>>> I don't recall when this change happened but I'd like any feedback on
>>> whether folks are adverse
>>> to reverting to the 4.0.7 tabbed layout while keeping the "Reset" and
>>> "Defaults" buttons,
>>> that I think are really good additions.
>>>
>> I agree, but I still don't understand why we don't use the huge screen
>> real-estate we have nowadays on our desks and display all of them in one
>> table with i.e. four columns. It would be easy then to check the hotkeys
>> across all tools without changing tabs.
>> The Buttons "Default" might become "Reset all Hotkeys to Kicad's
>> defaults. Are you sure Y/N?"
>> The Buttons "Reset" might become "Reset to previous settings" - but that
>> might simply be the "Cancel" button.
>>
>>
>> The menu entry Help -> List Hotkeys seems redundant to Preferences ->
>> Hotkey Options -> Edit Hotkeys.
>> One of the dialogs might be removed.
>> In the latest-git, the Hotkey '?' doesn't work for me. I get a beep, when
>> I am lucky... usually it is just ignored.
>>
>> In Eeschema, the Help -> List Hotkeys doesn't show the '?'
>> There the Hotkey-Editor can be reached via Preferences -> General Options
>> -> Controls Tab...
>>
>> GUI consistency would improve UX a lot. These are IMO the low-hanging
>> fruits to attract users to use Kicad.
>>
>> Regards,
>>
>> Clemens
>>
>> On 2018-01-11 02:07, Seth Hillbrand wrote:
>>
>>> I feel that there is a usability issue with the current hotkeys editor
>>> that is a regression from the 4.0.7 hotkeys editor.
>>>
>>> I've attached images for both to this message.  The current editor opens
>>> with a tree view that hides the hotkeys below "Common".  Users would be
>>> forgiven for not realizing that there were additional hotkeys specific to
>>> each application -- see current_hotkeys.png
>>>
>>> Previously, the hotkeys were displayed in tabs that were, I think, more
>>> clear -- see prev_hotkeys.png.
>>>
>>> I don't recall when this change happened but I'd like any feedback on
>>> whether folks are adverse to reverting to the 4.0.7 tabbed layout while
>>> keeping the "Reset" and "Defaults" buttons, that I think are really good
>>> additions.
>>>
>>> -S
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>



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

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

Re: [Kicad-developers] Libedit and Modedit Icons

[Andrey Kuznetsov]

Also the attached image of the final icon set was discarded, can you please
resend the final icon image set?

Thank you

On Thu, Jan 11, 2018 at 8:35 AM, jp charras  wrote:

> Le 11/01/2018 à 08:54, Oliver Walters a écrit :
> > Wayne,
> >
> > I have taken further suggestions and final icon set is shown below:
> >
> > [image: Inline image 1]
> >
> > The attached patch incorporates all of the icon changes thus far
> > implemented.
> >
> > Thanks,
> > Oliver
> >
>
> Oliver,
>
> For some unknown reason, your mail was blocked by Launchpad.
> And the attached patch was discarded.
>
>
> --
> 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
>



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

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

[Kicad-developers] [PATCH] Save view control settings before dispatching new tool events

[Jon Evans]

Fix another cause of https://bugs.launchpad.net/kicad/+bug/1741357

Using the "add via" hotkey was causing an immediate dispatch of that tool
event, which was overriding the view settings of the active tool (i.e.
router tool with cursor displayed).

This patch saves and restores the view settings before dispatching tool
events, which fixes this and should prevent some other weirdness if one
tool dispatches another with modified view settings.

-Jon
From ca0c6b04451154c33882ddf4d363a97a0753f69a Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Thu, 11 Jan 2018 22:12:46 -0500
Subject: [PATCH] Save view control settings before dispatching new tool events

Fixes: lp:1741357
* https://bugs.launchpad.net/kicad/+bug/1741357
---
 common/tool/tool_manager.cpp | 5 +
 1 file changed, 5 insertions(+)

diff --git a/common/tool/tool_manager.cpp b/common/tool/tool_manager.cpp
index 669b62f11..bfc628200 100644
--- a/common/tool/tool_manager.cpp
+++ b/common/tool/tool_manager.cpp
@@ -510,6 +510,9 @@ OPT TOOL_MANAGER::ScheduleWait( TOOL_BASE* aTool,
 
 void TOOL_MANAGER::dispatchInternal( const TOOL_EVENT& aEvent )
 {
+// Save current settings before overwriting with the dispatched tool
+auto vc_settings = m_viewControls->GetSettings();
+
 // iterate over all registered tools
 for( auto it = m_activeTools.begin(); it != m_activeTools.end(); ++it )
 {
@@ -591,6 +594,8 @@ void TOOL_MANAGER::dispatchInternal( const TOOL_EVENT& aEvent )
 if( finished )
 break;  // only the first tool gets the event
 }
+
+m_viewControls->ApplySettings( vc_settings );
 }
 
 
-- 
2.14.1

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

Re: [Kicad-developers] desired layer sequence for pcb technical layers

[Jon Evans]

My original question is about the structure of the kicad code, not about
the layer manager. I'm asking if there is any technical reason why back
layers are listed first in a specific part of the code base. If no one has
a good answer, I'm going to submit a patch to change it to have front
layers first to be consistent with the rest of the UI code.

-Jon


On Jan 11, 2018 18:55, "Andrey Kuznetsov"  wrote:

Actually, programs like Altium and Allegro allow you to swap the order of
layers, to change visibility of transparent layers.
For example, make back layer have higher priority, and front layer lower
priority, with the back layer setting to 50% transparency, etc.

But I guess this layer manager is going to be in v6?

On Thu, Jan 11, 2018 at 11:19 AM, Jon Evans  wrote:

> Yes, in the KiCad codebase, they are called Front and Back, and my
> question is independent of whether or not they should be called Top and
> Bottom :-)
>
> On Thu, Jan 11, 2018 at 2:16 PM, Diego Herranz <
> diegoherr...@diegoherranz.com> wrote:
>
>> Regarding Front vs Top, I see it called Top everywhere else, but back to
>> the original question: +1 for Top/Front first.
>>
>> Thanks,
>> Diego
>>
>> On Thu, Jan 11, 2018 at 5:52 AM, Andrey Kuznetsov 
>> wrote:
>>
>>> Why is it Front and Back, as opposed to Top and Bottom?
>>> Front/Top should be first.
>>>
>>> On Wed, Jan 10, 2018 at 8:50 PM, Jon Evans  wrote:
>>>
 Hi all,

 Right now, we have conflicting "desired order" for technical layers in
 various places.

 The layer widget displays "front first", i.e. F.Paste before B.Paste,
 F.Fab before B.Fab, etc.

 Everywhere else in the codebase is "back first".
 This leads to this bug: https://bugs.launchpad.net/kicad/+bug/1673792
 because the properties dialog is using LSET::UIOrder() which uses the
 "preferred" back first ordering.

 Which way should we actually have it?  "front first" makes sense to me,
 and that is the precedent set in the most user-visible part (the layer
 manager) but then why in LSET::Technicals() is there a comment saying the
 desired order is "back first"?

 -Jon

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


>>>
>>>
>>> --
>>> Remember The Past, Live The Present, Change The Future
>>> Those who look only to the past or the present are certain to miss the
>>> future [JFK]
>>>
>>> kandre...@gmail.com
>>> Live Long and Prosper,
>>> Andrey
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>


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

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

Re: [Kicad-developers] desired layer sequence for pcb technical layers

[Andrey Kuznetsov]

Actually, programs like Altium and Allegro allow you to swap the order of
layers, to change visibility of transparent layers.
For example, make back layer have higher priority, and front layer lower
priority, with the back layer setting to 50% transparency, etc.

But I guess this layer manager is going to be in v6?

On Thu, Jan 11, 2018 at 11:19 AM, Jon Evans  wrote:

> Yes, in the KiCad codebase, they are called Front and Back, and my
> question is independent of whether or not they should be called Top and
> Bottom :-)
>
> On Thu, Jan 11, 2018 at 2:16 PM, Diego Herranz <
> diegoherr...@diegoherranz.com> wrote:
>
>> Regarding Front vs Top, I see it called Top everywhere else, but back to
>> the original question: +1 for Top/Front first.
>>
>> Thanks,
>> Diego
>>
>> On Thu, Jan 11, 2018 at 5:52 AM, Andrey Kuznetsov 
>> wrote:
>>
>>> Why is it Front and Back, as opposed to Top and Bottom?
>>> Front/Top should be first.
>>>
>>> On Wed, Jan 10, 2018 at 8:50 PM, Jon Evans  wrote:
>>>
 Hi all,

 Right now, we have conflicting "desired order" for technical layers in
 various places.

 The layer widget displays "front first", i.e. F.Paste before B.Paste,
 F.Fab before B.Fab, etc.

 Everywhere else in the codebase is "back first".
 This leads to this bug: https://bugs.launchpad.net/kicad/+bug/1673792
 because the properties dialog is using LSET::UIOrder() which uses the
 "preferred" back first ordering.

 Which way should we actually have it?  "front first" makes sense to me,
 and that is the precedent set in the most user-visible part (the layer
 manager) but then why in LSET::Technicals() is there a comment saying the
 desired order is "back first"?

 -Jon

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


>>>
>>>
>>> --
>>> Remember The Past, Live The Present, Change The Future
>>> Those who look only to the past or the present are certain to miss the
>>> future [JFK]
>>>
>>> kandre...@gmail.com
>>> Live Long and Prosper,
>>> Andrey
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>


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

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

Re: [Kicad-developers] desired layer sequence for pcb technical layers

[Jon Evans]

Yes, in the KiCad codebase, they are called Front and Back, and my question
is independent of whether or not they should be called Top and Bottom :-)

On Thu, Jan 11, 2018 at 2:16 PM, Diego Herranz <
diegoherr...@diegoherranz.com> wrote:

> Regarding Front vs Top, I see it called Top everywhere else, but back to
> the original question: +1 for Top/Front first.
>
> Thanks,
> Diego
>
> On Thu, Jan 11, 2018 at 5:52 AM, Andrey Kuznetsov 
> wrote:
>
>> Why is it Front and Back, as opposed to Top and Bottom?
>> Front/Top should be first.
>>
>> On Wed, Jan 10, 2018 at 8:50 PM, Jon Evans  wrote:
>>
>>> Hi all,
>>>
>>> Right now, we have conflicting "desired order" for technical layers in
>>> various places.
>>>
>>> The layer widget displays "front first", i.e. F.Paste before B.Paste,
>>> F.Fab before B.Fab, etc.
>>>
>>> Everywhere else in the codebase is "back first".
>>> This leads to this bug: https://bugs.launchpad.net/kicad/+bug/1673792
>>> because the properties dialog is using LSET::UIOrder() which uses the
>>> "preferred" back first ordering.
>>>
>>> Which way should we actually have it?  "front first" makes sense to me,
>>> and that is the precedent set in the most user-visible part (the layer
>>> manager) but then why in LSET::Technicals() is there a comment saying the
>>> desired order is "back first"?
>>>
>>> -Jon
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>>
>> --
>> Remember The Past, Live The Present, Change The Future
>> Those who look only to the past or the present are certain to miss the
>> future [JFK]
>>
>> kandre...@gmail.com
>> Live Long and Prosper,
>> Andrey
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://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] desired layer sequence for pcb technical layers

[Diego Herranz]

Regarding Front vs Top, I see it called Top everywhere else, but back to
the original question: +1 for Top/Front first.

Thanks,
Diego

On Thu, Jan 11, 2018 at 5:52 AM, Andrey Kuznetsov 
wrote:

> Why is it Front and Back, as opposed to Top and Bottom?
> Front/Top should be first.
>
> On Wed, Jan 10, 2018 at 8:50 PM, Jon Evans  wrote:
>
>> Hi all,
>>
>> Right now, we have conflicting "desired order" for technical layers in
>> various places.
>>
>> The layer widget displays "front first", i.e. F.Paste before B.Paste,
>> F.Fab before B.Fab, etc.
>>
>> Everywhere else in the codebase is "back first".
>> This leads to this bug: https://bugs.launchpad.net/kicad/+bug/1673792
>> because the properties dialog is using LSET::UIOrder() which uses the
>> "preferred" back first ordering.
>>
>> Which way should we actually have it?  "front first" makes sense to me,
>> and that is the precedent set in the most user-visible part (the layer
>> manager) but then why in LSET::Technicals() is there a comment saying the
>> desired order is "back first"?
>>
>> -Jon
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss the
> future [JFK]
>
> kandre...@gmail.com
> Live Long and Prosper,
> Andrey
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxStaticBoxSizer fixes

[jp charras]

Le 11/01/2018 à 19:29, Chris Pavlina a écrit :
> Interesting. I wonder if we could implement a wrapper around
> wxStaticBoxSizers to fix the issue rather than switching away from them
> - they look much nicer than the replacement. Which KDE version are you
> using specifically? I'd like to have a look at this.
> 
> (Would be nice if these fixes could also be submitted upstream...)
> 

I am using Kubuntu 14.04 LTS.
This is a old version, but it is a good version to test build issues
(I have a more recent version installed: Ubuntu 16.04 LTS / Unity for other 
tests:
Unity has its own issues)
I am thinking my WM version is KDE 4
Note also the issue is annoying only when using wxNotebooks.

This issue is especially noticeable with wxWidgets built against GTK3 (although 
GTK3 is not usable
because wxDC just does not work for us: it is broken).

About: "look much nicer than the replacement", it is hard to have a strong 
opinion:
Remember, the beauty is in the eye of the guy who is looking at.

For me, I prefer the replacement on KDE and the wxStaticBoxSizer version on 
Windows.

Good luck.


-- 
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] Minor releases (post v5.0.0)

[José Ignacio]

I think this is relevant now so the feature set can be frozen definitely,
but also don't make people feel like they either have to rush it now or
wait years for their pet feature to appear on the next stable release, this
could also mean dropping unfinished features in the interest of having v5
out the door on schedule, knowing that they will be there when ready in the
next release.

On Thu, Jan 11, 2018 at 12:41 PM, Wayne Stambaugh 
wrote:

> Please save this for the post v5 discussion.
>
> On 1/11/2018 1:27 PM, Chris Pavlina wrote:
> > I agree with all of this 100%.
> >
> > On Thu, Jan 11, 2018 at 11:45:58AM -0600, José Ignacio wrote:
> >> I've started to see a flurry of features that are either getting rushed
> in
> >> for v5.0 or being pushed aside to the future "v6" version of kicad. Due
> to
> >> the limited resources of the development team and the sheer amount of
> work
> >> for each major release, the development cycles get pretty long, and many
> >> small but significant features will not see wide use until v6 will come
> out
> >> in a couple of years, as new features are not allowed in bugfix
> releases.
> >>
> >> Would it be possible to this week clamp down completely now on _any_
> kind
> >> of new feature for v5.0, and instead of pushing it to v6 (which sounds
> very
> >> far in the future), push it instead to v5.1, which could be released
> just a
> >> few months after v5.0 and include small features that don't break
> >> compatibility in a major way. That should also ease the continual
> >> backporting of bug fixes as the stable branch wont get overly stale, and
> >> small convenience features will get much better testing before the rush
> of
> >> the next release. IMO it will make the 5->6.0 cycle a lot less stressful
> >> than it's been for the past two cycles.
> >>
> >> Features in the v4->5 cycle that have forced me to use the master branch
> >> for production are things like the eeschema field autoplacing, eeschema
> >> field editor, gal performance improvements, STEP support. All things
> that
> >> didn't really break compatibility of my projects as much as a major
> release
> >> can do, but many people using the stable release haven't been able to
> test.
> >>
> >> ~Jose
> >
> >
> > ___
> > Mailing list: https://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] Minor releases (post v5.0.0)

[Wayne Stambaugh]

Please save this for the post v5 discussion.

On 1/11/2018 1:27 PM, Chris Pavlina wrote:
> I agree with all of this 100%.
> 
> On Thu, Jan 11, 2018 at 11:45:58AM -0600, José Ignacio wrote:
>> I've started to see a flurry of features that are either getting rushed in
>> for v5.0 or being pushed aside to the future "v6" version of kicad. Due to
>> the limited resources of the development team and the sheer amount of work
>> for each major release, the development cycles get pretty long, and many
>> small but significant features will not see wide use until v6 will come out
>> in a couple of years, as new features are not allowed in bugfix releases.
>>
>> Would it be possible to this week clamp down completely now on _any_ kind
>> of new feature for v5.0, and instead of pushing it to v6 (which sounds very
>> far in the future), push it instead to v5.1, which could be released just a
>> few months after v5.0 and include small features that don't break
>> compatibility in a major way. That should also ease the continual
>> backporting of bug fixes as the stable branch wont get overly stale, and
>> small convenience features will get much better testing before the rush of
>> the next release. IMO it will make the 5->6.0 cycle a lot less stressful
>> than it's been for the past two cycles.
>>
>> Features in the v4->5 cycle that have forced me to use the master branch
>> for production are things like the eeschema field autoplacing, eeschema
>> field editor, gal performance improvements, STEP support. All things that
>> didn't really break compatibility of my projects as much as a major release
>> can do, but many people using the stable release haven't been able to test.
>>
>> ~Jose
> 
> 
> ___
> Mailing list: https://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] wxStaticBoxSizer fixes

[Chris Pavlina]

Interesting. I wonder if we could implement a wrapper around
wxStaticBoxSizers to fix the issue rather than switching away from them
- they look much nicer than the replacement. Which KDE version are you
using specifically? I'd like to have a look at this.

(Would be nice if these fixes could also be submitted upstream...)

On Thu, Jan 11, 2018 at 07:14:27PM +0100, jp charras wrote:
> Le 11/01/2018 à 18:27, Chris Pavlina a écrit :
> > Hi (@JP mostly),
> > 
> > I see you're removing wxStaticBoxSizers [1] due to issues with KDE. Have
> > you tried the fix I implemented in [2] for what I think is the same
> > issue? You commented on the bug report and said it worked for you, and I
> > didn't have to remove the wxStaticBoxSizer, only change a property of
> > it.
> > 
> > [1] 
> > https://git.launchpad.net/kicad/commit/?id=6f2beebf2c623b9cf85faa6deb8f65d32b8ef7ff
> > [2] 
> > https://git.launchpad.net/kicad/commit/?id=6f900530204b44c0e80464ea3c752877c4ff6fc7
> > 
> > I'm not sure exactly how this is connected to KDE, I'm quite curious
> > about that - but they do seem to be wonky without that setting change.
> > I'll admit I don't fully understand why my own fix works.
> > 
> 
> 
> On KDE, I always had issues with wxStaticBoxSizers. It is not a recent issue.
> But the issue is not the same as [2].
> 
> They are incorrectly vertically sized (incorrect height: a few pixels error).
> 
> And when  wxStaticBoxSizer are used in wxNotebook, when placed in page 2, 
> they are correctly sized
> only after the dialog is resized if the dialog is opened with wxNotebook page 
> 1 selected.
> 
> of course if the dialog is opened with wxNotebook page 2 selected, 
> wxStaticBoxSizers used in page 1
> are incorrectly sized (and correctly sized after a dialog resize).
> 
> I do not have this issue on Unity.
> 
> -- 
> 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] Minor releases (post v5.0.0)

[Chris Pavlina]

I agree with all of this 100%.

On Thu, Jan 11, 2018 at 11:45:58AM -0600, José Ignacio wrote:
> I've started to see a flurry of features that are either getting rushed in
> for v5.0 or being pushed aside to the future "v6" version of kicad. Due to
> the limited resources of the development team and the sheer amount of work
> for each major release, the development cycles get pretty long, and many
> small but significant features will not see wide use until v6 will come out
> in a couple of years, as new features are not allowed in bugfix releases.
> 
> Would it be possible to this week clamp down completely now on _any_ kind
> of new feature for v5.0, and instead of pushing it to v6 (which sounds very
> far in the future), push it instead to v5.1, which could be released just a
> few months after v5.0 and include small features that don't break
> compatibility in a major way. That should also ease the continual
> backporting of bug fixes as the stable branch wont get overly stale, and
> small convenience features will get much better testing before the rush of
> the next release. IMO it will make the 5->6.0 cycle a lot less stressful
> than it's been for the past two cycles.
> 
> Features in the v4->5 cycle that have forced me to use the master branch
> for production are things like the eeschema field autoplacing, eeschema
> field editor, gal performance improvements, STEP support. All things that
> didn't really break compatibility of my projects as much as a major release
> can do, but many people using the stable release haven't been able to test.
> 
> ~Jose


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

[jp charras]

Le 11/01/2018 à 18:27, Chris Pavlina a écrit :
> Hi (@JP mostly),
> 
> I see you're removing wxStaticBoxSizers [1] due to issues with KDE. Have
> you tried the fix I implemented in [2] for what I think is the same
> issue? You commented on the bug report and said it worked for you, and I
> didn't have to remove the wxStaticBoxSizer, only change a property of
> it.
> 
> [1] 
> https://git.launchpad.net/kicad/commit/?id=6f2beebf2c623b9cf85faa6deb8f65d32b8ef7ff
> [2] 
> https://git.launchpad.net/kicad/commit/?id=6f900530204b44c0e80464ea3c752877c4ff6fc7
> 
> I'm not sure exactly how this is connected to KDE, I'm quite curious
> about that - but they do seem to be wonky without that setting change.
> I'll admit I don't fully understand why my own fix works.
> 


On KDE, I always had issues with wxStaticBoxSizers. It is not a recent issue.
But the issue is not the same as [2].

They are incorrectly vertically sized (incorrect height: a few pixels error).

And when  wxStaticBoxSizer are used in wxNotebook, when placed in page 2, they 
are correctly sized
only after the dialog is resized if the dialog is opened with wxNotebook page 1 
selected.

of course if the dialog is opened with wxNotebook page 2 selected, 
wxStaticBoxSizers used in page 1
are incorrectly sized (and correctly sized after a dialog resize).

I do not have this issue on Unity.

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

[Kicad-developers] Minor releases (post v5.0.0)

[José Ignacio]

I've started to see a flurry of features that are either getting rushed in
for v5.0 or being pushed aside to the future "v6" version of kicad. Due to
the limited resources of the development team and the sheer amount of work
for each major release, the development cycles get pretty long, and many
small but significant features will not see wide use until v6 will come out
in a couple of years, as new features are not allowed in bugfix releases.

Would it be possible to this week clamp down completely now on _any_ kind
of new feature for v5.0, and instead of pushing it to v6 (which sounds very
far in the future), push it instead to v5.1, which could be released just a
few months after v5.0 and include small features that don't break
compatibility in a major way. That should also ease the continual
backporting of bug fixes as the stable branch wont get overly stale, and
small convenience features will get much better testing before the rush of
the next release. IMO it will make the 5->6.0 cycle a lot less stressful
than it's been for the past two cycles.

Features in the v4->5 cycle that have forced me to use the master branch
for production are things like the eeschema field autoplacing, eeschema
field editor, gal performance improvements, STEP support. All things that
didn't really break compatibility of my projects as much as a major release
can do, but many people using the stable release haven't been able to test.

~Jose
___
Mailing list: https://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] wxStaticBoxSizer fixes

[Chris Pavlina]

Hi (@JP mostly),

I see you're removing wxStaticBoxSizers [1] due to issues with KDE. Have
you tried the fix I implemented in [2] for what I think is the same
issue? You commented on the bug report and said it worked for you, and I
didn't have to remove the wxStaticBoxSizer, only change a property of
it.

[1] 
https://git.launchpad.net/kicad/commit/?id=6f2beebf2c623b9cf85faa6deb8f65d32b8ef7ff
[2] 
https://git.launchpad.net/kicad/commit/?id=6f900530204b44c0e80464ea3c752877c4ff6fc7

I'm not sure exactly how this is connected to KDE, I'm quite curious
about that - but they do seem to be wonky without that setting change.
I'll admit I don't fully understand why my own fix works.

-- 
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] Implement primitive icon scaling for high DPI

[Chris Pavlina]

Yup. For reference my own display is around 280 DPI.

On Thu, Jan 11, 2018 at 10:35:15AM +, Jeff Young wrote:
> 2560x1440 @ 24” is only 122 DPI. 
> 
> Apple’s Retina displays are 220 or 227, and the Surface Book in the original 
> bug report is 267 DPI.
> 
> > On 11 Jan 2018, at 09:54, kristoffer Ödmark  
> > wrote:
> > 
> > I have 2560x1440, 24" screens, I think those qualifies as high DPI?
> > 
> > The slider value is at 100, and the diag value is at 23. The icons are ish 
> > 5mm large.
> > 
> > But i guess that is uneccesary since It seems the scaling works as 
> > intended, I was just doing it wrong, so no errors, sorry :)
> > 
> > The scaling seems correct as well, 100 = 5mm, 150 = 7.5, 200 = 11, measured 
> > with a tape measure, so variance in size is expected.
> > 
> > 
> > Application: kicad
> > Version: (2018-01-11 revision a5b3d8e57)-master, debug build
> > Libraries:
> > wxWidgets 3.0.3
> > libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 
> > (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0
> > Platform: Linux 4.9.74-2-MANJARO x86_64, 64 bit, Little endian, wxGTK
> > Build Info:
> > wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
> > Boost: 1.65.1
> > Curl: 7.57.0
> > Compiler: GCC 7.2.1 with C++ ABI 1011
> > 
> > Build settings:
> > USE_WX_GRAPHICS_CONTEXT=OFF
> > USE_WX_OVERLAY=OFF
> > KICAD_SCRIPTING=ON
> > KICAD_SCRIPTING_MODULES=ON
> > KICAD_SCRIPTING_WXPYTHON=ON
> > KICAD_SCRIPTING_ACTION_MENU=OFF
> > BUILD_GITHUB_PLUGIN=ON
> > KICAD_USE_OCE=ON
> > KICAD_SPICE=ON
> > 
> > 
> > On 2018-01-11 01:13, Chris Pavlina wrote:
> >> If your system DPI is already within a certain range it won't do
> >> anything. Are you using a high DPI display? If it's not scaled
> >> correctly, would you please share with me the diagnostic number reported
> >> by the scale slider in eeschema prefs as well as a rough indication of
> >> the icons' physical size? Thanks.
> >> 
> >> On Wed, Jan 10, 2018 at 11:16:46PM +, kristoffer Ödmark wrote:
> >>> Tried the patch, didnt really notice anything different though, I guess 
> >>> you
> >>> need to add some custom scaling for this to take effect?
> >>> 
> >>> 
> >>> On 2018-01-10 22:23, Chris Pavlina wrote:
>  Sure, assign me to it. I should have time to work on it tonight or
>  tomorrow.
>  
>  On Wed, Jan 10, 2018 at 04:20:21PM -0500, Wayne Stambaugh wrote:
> > FYI, the edit footprint dialog in Pcbnew is not sized properly (at least
> > on windows) which I'm pretty sure is related to your recent HiDPI work.
> > Do you want me to file a bug report for it?
> > 
> > On 1/10/2018 2:01 PM, Chris Pavlina wrote:
> >> By the way, I'm going to go ahead and push this tonight-ish if nobody
> >> objects. I know it's on the big side, but due to my limited number of
> >> machines to test on I really want time for user feedback. I'll be 
> >> around
> >> to put out any fires.
> >> 
> >> On Wed, Jan 10, 2018 at 11:07:49AM -0700, Chris Pavlina wrote:
> >>> Rebased patch attached.
> >>> 
> >>> On Tue, Jan 09, 2018 at 01:27:16PM +, Maciej Sumiński wrote:
>  Hi Chris,
>  
>  The patch does not apply cleanly on the current master, would you 
>  rebase
>  it? Thanks in advance.
>  
>  Cheers,
>  Orson
>  
>  On 01/09/2018 03:43 AM, Chris Pavlina wrote:
> > Hi,
> > 
> > As discussed with Wayne earlier, I've attached a patch which adds 
> > simple
> > toolbar icon scaling so the toolbars are readable on high-DPI 
> > systems.
> > 
> > This is meant as a stopgap for 5.0, with plans to add proper scaled
> > icons in the 6.0 cycle. A function KiScaledBitmap() is added, which
> > works like KiBitmap() except it scales the bitmap according to the
> > calling window's font size. Controls have been added to all the main
> > applications to let the user select scaling manually (these were 
> > omitted
> > from smaller apps that didn't already have a place to put them).
> > 
> > In addition, in eeschema only, the pixel height of the system font 
> > is
> > shown in the options dialog for diagnostics. This is only for 
> > collecting
> > feedback before 5.0 release from users with different displays and 
> > will
> > be removed.
> > 
> > I would like to push this fairly soon, as I want to get as much user
> > feedback as possible before release. I have a limited number of 
> > systems
> > to test this on myself.
> > 
> > 
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to  

Re: [Kicad-developers] [PATCH] Implement primitive icon scaling for high DPI

[Chris Pavlina]

You're right on the threshold I chose (somewhat arbitrarily). 5mm
sounds decent. I made an intentional choice not to start scaling until
it's quite necessary, because it's just simple bitmap scaling and on
displays that are lower in DPI they _look_ scaled.

On Thu, Jan 11, 2018 at 09:53:52AM +, kristoffer Ödmark wrote:
> I have 2560x1440, 24" screens, I think those qualifies as high DPI?
> 
> The slider value is at 100, and the diag value is at 23. The icons are ish
> 5mm large.
> 
> But i guess that is uneccesary since It seems the scaling works as intended,
> I was just doing it wrong, so no errors, sorry :)
> 
> The scaling seems correct as well, 100 = 5mm, 150 = 7.5, 200 = 11, measured
> with a tape measure, so variance in size is expected.
> 
> 
> Application: kicad
> Version: (2018-01-11 revision a5b3d8e57)-master, debug build
> Libraries:
>     wxWidgets 3.0.3
>     libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1
> (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0
> Platform: Linux 4.9.74-2-MANJARO x86_64, 64 bit, Little endian, wxGTK
> Build Info:
>     wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
>     Boost: 1.65.1
>     Curl: 7.57.0
>     Compiler: GCC 7.2.1 with C++ ABI 1011
> 
> Build settings:
>     USE_WX_GRAPHICS_CONTEXT=OFF
>     USE_WX_OVERLAY=OFF
>     KICAD_SCRIPTING=ON
>     KICAD_SCRIPTING_MODULES=ON
>     KICAD_SCRIPTING_WXPYTHON=ON
>     KICAD_SCRIPTING_ACTION_MENU=OFF
>     BUILD_GITHUB_PLUGIN=ON
>     KICAD_USE_OCE=ON
>     KICAD_SPICE=ON
> 
> 
> On 2018-01-11 01:13, Chris Pavlina wrote:
> > If your system DPI is already within a certain range it won't do
> > anything. Are you using a high DPI display? If it's not scaled
> > correctly, would you please share with me the diagnostic number reported
> > by the scale slider in eeschema prefs as well as a rough indication of
> > the icons' physical size? Thanks.
> > 
> > On Wed, Jan 10, 2018 at 11:16:46PM +, kristoffer Ödmark wrote:
> > > Tried the patch, didnt really notice anything different though, I guess 
> > > you
> > > need to add some custom scaling for this to take effect?
> > > 
> > > 
> > > On 2018-01-10 22:23, Chris Pavlina wrote:
> > > > Sure, assign me to it. I should have time to work on it tonight or
> > > > tomorrow.
> > > > 
> > > > On Wed, Jan 10, 2018 at 04:20:21PM -0500, Wayne Stambaugh wrote:
> > > > > FYI, the edit footprint dialog in Pcbnew is not sized properly (at 
> > > > > least
> > > > > on windows) which I'm pretty sure is related to your recent HiDPI 
> > > > > work.
> > > > > Do you want me to file a bug report for it?
> > > > > 
> > > > > On 1/10/2018 2:01 PM, Chris Pavlina wrote:
> > > > > > By the way, I'm going to go ahead and push this tonight-ish if 
> > > > > > nobody
> > > > > > objects. I know it's on the big side, but due to my limited number 
> > > > > > of
> > > > > > machines to test on I really want time for user feedback. I'll be 
> > > > > > around
> > > > > > to put out any fires.
> > > > > > 
> > > > > > On Wed, Jan 10, 2018 at 11:07:49AM -0700, Chris Pavlina wrote:
> > > > > > > Rebased patch attached.
> > > > > > > 
> > > > > > > On Tue, Jan 09, 2018 at 01:27:16PM +, Maciej Sumiński wrote:
> > > > > > > > Hi Chris,
> > > > > > > > 
> > > > > > > > The patch does not apply cleanly on the current master, would 
> > > > > > > > you rebase
> > > > > > > > it? Thanks in advance.
> > > > > > > > 
> > > > > > > > Cheers,
> > > > > > > > Orson
> > > > > > > > 
> > > > > > > > On 01/09/2018 03:43 AM, Chris Pavlina wrote:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > As discussed with Wayne earlier, I've attached a patch which 
> > > > > > > > > adds simple
> > > > > > > > > toolbar icon scaling so the toolbars are readable on high-DPI 
> > > > > > > > > systems.
> > > > > > > > > 
> > > > > > > > > This is meant as a stopgap for 5.0, with plans to add proper 
> > > > > > > > > scaled
> > > > > > > > > icons in the 6.0 cycle. A function KiScaledBitmap() is added, 
> > > > > > > > > which
> > > > > > > > > works like KiBitmap() except it scales the bitmap according 
> > > > > > > > > to the
> > > > > > > > > calling window's font size. Controls have been added to all 
> > > > > > > > > the main
> > > > > > > > > applications to let the user select scaling manually (these 
> > > > > > > > > were omitted
> > > > > > > > > from smaller apps that didn't already have a place to put 
> > > > > > > > > them).
> > > > > > > > > 
> > > > > > > > > In addition, in eeschema only, the pixel height of the system 
> > > > > > > > > font is
> > > > > > > > > shown in the options dialog for diagnostics. This is only for 
> > > > > > > > > collecting
> > > > > > > > > feedback before 5.0 release from users with different 
> > > > > > > > > displays and will
> > > > > > > > > be removed.
> > > > > > > > > 
> > > > > > > > > I would like to push this fairly soon, as I want to get as 
> > > > > > > > > much user
> > > > > > > > > feedback as 

Re: [Kicad-developers] Daily build for KiCad on Ubuntu (ppa)

[Jean-Samuel Reynaud]

Hi all,

 Ubuntu had re-enable the build farm but there is a large number of
other packages waiting for rebuild. As I see, it should take 1 or 2 days
before daily build of new packages.

Regards,
Le 09/01/2018 à 20:36, Jean-Samuel Reynaud a écrit :
> Hi all,
> 
> Launchpad build farm is currently disabled due to security issues
> (Meltdown and Spectre) [1]. So for the moment new KiCad daily build are
> disabled. 
> Existing packages are still available but not new build...
> Sorry for this (temporary) bad news.
> 
> 
> [1]
> https://lists.ubuntu.com/archives/launchpad-announce/2018-January/000103.html
> 


___
Mailing list: https://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] Libedit and Modedit Icons

[jp charras]

Le 11/01/2018 à 08:54, Oliver Walters a écrit :
> Wayne,
> 
> I have taken further suggestions and final icon set is shown below:
> 
> [image: Inline image 1]
> 
> The attached patch incorporates all of the icon changes thus far
> implemented.
> 
> Thanks,
> Oliver
> 

Oliver,

For some unknown reason, your mail was blocked by Launchpad.
And the attached patch was discarded.


-- 
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] Libedit and Modedit Icons

[Oliver Walters]

Wayne,

I have taken further suggestions and final icon set is shown below:

[image: Inline image 1]

The attached patch incorporates all of the icon changes thus far
implemented.

Thanks,
Oliver

On Thu, Jan 11, 2018 at 1:58 AM, Wayne Stambaugh 
wrote:

> I see scope creep happening here.  I thought the original goal was to
> make some minor tweaks to our existing icons not wholesale replacement
> of the them.  I don't like the camera either.  I'm not a big fan of the
> calculator icon.  Both of these icons looks completely out of place with
> our other icons.  Please keep the scope of these changes in check.  If
> we want to discuss an entirely new icon theme for v6, that's fine at the
> appropriate time but not for v5.
>
> On 1/10/2018 9:42 AM, Jeff Young wrote:
> > Splendid!
> >
> > Although I agree with Kristoffer that the new bitmap2component icon
> > isn’t much help.  Import/Export is the one area where we’ve kept the
> > arrows (which I think is fine).  Given that, the pixelated “a” with an
> > import arrow would be perfect.
> >
> > FWIW, this is one area where I disagree with Nick.  I did user interface
> > design and software architecture for Adobe for 25 years and in my
> > professional opinion, these icons are a HUGE improvement.
> >
> > Cheers,
> > Jeff
> >
> >
> >> On 10 Jan 2018, at 14:28, Oliver Walters
> >>  >> > wrote:
> >>
> >> Also, would it be too much to ask for getting the arrows, the
> >> diskette and the folder in the repo with the patch, basically if
> >> someone wants to create future icons. They could use the same
> >> arrows for any kind of export, import, save, inspect or view.
> >>
> >>
> >> I have created a set of "common icons" for exactly this purpose :)
> >>
> >>
> >> On Thu, Jan 11, 2018 at 1:27 AM, Kristoffer Ödmark
> >> >
> >> wrote:
> >>
> >> Wow, really nice! Although, the icon for the bitmap2component
> >> basically looks like a screenshot symbol to me, or something
> >> related to a webcam.
> >>
> >> The old one isnt as polished, but I think it fits better.
> >>
> >> Also, would it be too much to ask for getting the arrows, the
> >> diskette and the folder in the repo with the patch, basically if
> >> someone wants to create future icons. They could use the same
> >> arrows for any kind of export, import, save, inspect or view.
> >>
> >> Basically to help get a icon theme thing going ;)
> >>
> >>
> >>
> >>  -Kristoffer
> >>
> >>
> >> On 01/10/2018 03:13 PM, Oliver Walters wrote:
> >>
> >> Wayne,
> >>
> >> Here is the outcome of removing the save / load arrows and
> >> replacing with
> >> standard load / save icons.
> >>
> >> I have also further tweaked the main icons as per suggestions.
> >>
> >> Screenshots here:
> >>
> >> https://imgur.com/a/DzZhZ
> >>
> >> This is about as far as I want to go with this, please let me
> >> know if there
> >> are any outstanding issues that prevent me from submitting a
> >> patch.
> >>
> >> Thanks,
> >> Oliver
> >>
> >> On Wed, Jan 10, 2018 at 8:09 AM, Oliver Walters <
> >> oliver.henry.walt...@gmail.com
> >> > wrote:
> >>
> >> Ok, that's good to hear. I will take another look at the
> >> Gerber icons and
> >> otherwise see if anyone can suggest some simple clean
> >> replacements for the
> >> arrows. If not, I'll push a patch.
> >>
> >> On Wed, Jan 10, 2018 at 8:05 AM, Wayne Stambaugh
> >> >
> >> wrote:
> >>
> >> One good thing about bitmaps is they are low risk
> >> (other than the
> >> complaining that will surely ensue) so we can merge
> >> them just about any
> >> time.  I don't want to wait too long so our doc images
> >> can be updated to
> >> reflect the changes so if we cannot come up with
> >> better alternatives to
> >> replace the arrows, I'm OK with leaving them as is and
> >> pushing it off
> >> until v6.
> >>
> >> Cheers,
> >>
> >> Wayne
> >>
> >> On 1/9/2018 3:31 PM, Jeff Young wrote:
> >>
> >> I think the changes are absolutely good in
> >> general, and I’d very much
> >> like to see them get merged.  Not that I have any
> >> control over that. ;)
> >>
> >> As for the arrows, I’d still really like to see
> >> them go away.  The
> >>

Re: [Kicad-developers] [PATCH] Implement primitive icon scaling for high DPI

[Wayne Stambaugh]

Chris,

I submitted the bug report[1] for this issue.  Thanks for looking into it.

Cheers,

Wayne

[1]: https://bugs.launchpad.net/kicad/+bug/1742701

On 1/10/2018 4:23 PM, Chris Pavlina wrote:
> Sure, assign me to it. I should have time to work on it tonight or
> tomorrow.
> 
> On Wed, Jan 10, 2018 at 04:20:21PM -0500, Wayne Stambaugh wrote:
>> FYI, the edit footprint dialog in Pcbnew is not sized properly (at least
>> on windows) which I'm pretty sure is related to your recent HiDPI work.
>> Do you want me to file a bug report for it?
>>
>> On 1/10/2018 2:01 PM, Chris Pavlina wrote:
>>> By the way, I'm going to go ahead and push this tonight-ish if nobody
>>> objects. I know it's on the big side, but due to my limited number of
>>> machines to test on I really want time for user feedback. I'll be around
>>> to put out any fires.
>>>
>>> On Wed, Jan 10, 2018 at 11:07:49AM -0700, Chris Pavlina wrote:
 Rebased patch attached.

 On Tue, Jan 09, 2018 at 01:27:16PM +, Maciej Sumiński wrote:
> Hi Chris,
>
> The patch does not apply cleanly on the current master, would you rebase
> it? Thanks in advance.
>
> Cheers,
> Orson
>
> On 01/09/2018 03:43 AM, Chris Pavlina wrote:
>> Hi,
>>
>> As discussed with Wayne earlier, I've attached a patch which adds simple
>> toolbar icon scaling so the toolbars are readable on high-DPI systems.
>>
>> This is meant as a stopgap for 5.0, with plans to add proper scaled
>> icons in the 6.0 cycle. A function KiScaledBitmap() is added, which
>> works like KiBitmap() except it scales the bitmap according to the
>> calling window's font size. Controls have been added to all the main
>> applications to let the user select scaling manually (these were omitted
>> from smaller apps that didn't already have a place to put them).
>>
>> In addition, in eeschema only, the pixel height of the system font is
>> shown in the options dialog for diagnostics. This is only for collecting
>> feedback before 5.0 release from users with different displays and will
>> be removed.
>>
>> I would like to push this fairly soon, as I want to get as much user
>> feedback as possible before release. I have a limited number of systems
>> to test this on myself.
>>
>>
>>
>> ___
>> Mailing list: https://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] Hotkeys Editor

[yann jautard]

what about  keeping four buttons :

*Defaults* that reset all hotkeys *of the current tab* to default

*Reset* that reset *the selected* hotkey only to default

*Cancel* that close the window and undo the current changes

*Save* that close the window and save the current changes


With a tooltip when getting the mouse over each button that clearly says 
this.



On 11/01/2018 13:16, Clemens Koller wrote:

Hi!

On 2018-01-11 02:07, Seth Hillbrand wrote:

I don't recall when this change happened but I'd like any feedback on whether 
folks are adverse
to reverting to the 4.0.7 tabbed layout while keeping the "Reset" and 
"Defaults" buttons,
that I think are really good additions.

I agree, but I still don't understand why we don't use the huge screen 
real-estate we have nowadays on our desks and display all of them in one table 
with i.e. four columns. It would be easy then to check the hotkeys across all 
tools without changing tabs.
The Buttons "Default" might become "Reset all Hotkeys to Kicad's defaults. Are you 
sure Y/N?"
The Buttons "Reset" might become "Reset to previous settings" - but that might simply be 
the "Cancel" button.


The menu entry Help -> List Hotkeys seems redundant to Preferences -> Hotkey 
Options -> Edit Hotkeys.
One of the dialogs might be removed.
In the latest-git, the Hotkey '?' doesn't work for me. I get a beep, when I am 
lucky... usually it is just ignored.

In Eeschema, the Help -> List Hotkeys doesn't show the '?'
There the Hotkey-Editor can be reached via Preferences -> General Options -> 
Controls Tab...

GUI consistency would improve UX a lot. These are IMO the low-hanging fruits to 
attract users to use Kicad.

Regards,

Clemens

On 2018-01-11 02:07, Seth Hillbrand wrote:

I feel that there is a usability issue with the current hotkeys editor that is 
a regression from the 4.0.7 hotkeys editor.

I've attached images for both to this message.  The current editor opens with a tree view 
that hides the hotkeys below "Common".  Users would be forgiven for not 
realizing that there were additional hotkeys specific to each application -- see 
current_hotkeys.png

Previously, the hotkeys were displayed in tabs that were, I think, more clear 
-- see prev_hotkeys.png.

I don't recall when this change happened but I'd like any feedback on whether folks are adverse to 
reverting to the 4.0.7 tabbed layout while keeping the "Reset" and "Defaults" 
buttons, that I think are really good additions.

-S


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


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



___
Mailing list: https://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] Libedit and Modedit Icons

[Clemens Koller]

On 2018-01-11 11:06, Jörg Hermann wrote:
> After all of Olivers work and the amount of time discussed here, I strongly 
> vote for accepting the changes, as they are a huge improvement.
> I agree on keeping the “old” pixelated a and PCB calculator, if that helps 
> accepting the remaining changes.

I fully agree here. The improvements are IMO really huge.
And I would suggest that Oliver just takes care of the remaining icons for the 
Bitmap converter/vectorizer as well as the PCB calculator for V5.

Regards,

Clemens

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

Re: [Kicad-developers] Hotkeys Editor

[Jeff Young]

I agree that the tabs were better.

And I agree that the Defaults button is a good addition.

I don’t agree about the Reset button.  Too much visual complexity when the user 
can just hit Cancel and then Edit Hotkeys again to achieve the same effect.

Cheers,
Jeff.


> On 11 Jan 2018, at 01:07, Seth Hillbrand  wrote:
> 
> I feel that there is a usability issue with the current hotkeys editor that 
> is a regression from the 4.0.7 hotkeys editor.
> 
> I've attached images for both to this message.  The current editor opens with 
> a tree view that hides the hotkeys below "Common".  Users would be forgiven 
> for not realizing that there were additional hotkeys specific to each 
> application -- see current_hotkeys.png
> 
> Previously, the hotkeys were displayed in tabs that were, I think, more clear 
> -- see prev_hotkeys.png.
> 
> I don't recall when this change happened but I'd like any feedback on whether 
> folks are adverse to reverting to the 4.0.7 tabbed layout while keeping the 
> "Reset" and "Defaults" buttons, that I think are really good additions.
> 
> -S
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [PATCH] Implement primitive icon scaling for high DPI

[Jeff Young]

2560x1440 @ 24” is only 122 DPI. 

Apple’s Retina displays are 220 or 227, and the Surface Book in the original 
bug report is 267 DPI.

> On 11 Jan 2018, at 09:54, kristoffer Ödmark  
> wrote:
> 
> I have 2560x1440, 24" screens, I think those qualifies as high DPI?
> 
> The slider value is at 100, and the diag value is at 23. The icons are ish 
> 5mm large.
> 
> But i guess that is uneccesary since It seems the scaling works as intended, 
> I was just doing it wrong, so no errors, sorry :)
> 
> The scaling seems correct as well, 100 = 5mm, 150 = 7.5, 200 = 11, measured 
> with a tape measure, so variance in size is expected.
> 
> 
> Application: kicad
> Version: (2018-01-11 revision a5b3d8e57)-master, debug build
> Libraries:
> wxWidgets 3.0.3
> libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 
> (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0
> Platform: Linux 4.9.74-2-MANJARO x86_64, 64 bit, Little endian, wxGTK
> Build Info:
> wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
> Boost: 1.65.1
> Curl: 7.57.0
> Compiler: GCC 7.2.1 with C++ ABI 1011
> 
> Build settings:
> USE_WX_GRAPHICS_CONTEXT=OFF
> USE_WX_OVERLAY=OFF
> KICAD_SCRIPTING=ON
> KICAD_SCRIPTING_MODULES=ON
> KICAD_SCRIPTING_WXPYTHON=ON
> KICAD_SCRIPTING_ACTION_MENU=OFF
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCE=ON
> KICAD_SPICE=ON
> 
> 
> On 2018-01-11 01:13, Chris Pavlina wrote:
>> If your system DPI is already within a certain range it won't do
>> anything. Are you using a high DPI display? If it's not scaled
>> correctly, would you please share with me the diagnostic number reported
>> by the scale slider in eeschema prefs as well as a rough indication of
>> the icons' physical size? Thanks.
>> 
>> On Wed, Jan 10, 2018 at 11:16:46PM +, kristoffer Ödmark wrote:
>>> Tried the patch, didnt really notice anything different though, I guess you
>>> need to add some custom scaling for this to take effect?
>>> 
>>> 
>>> On 2018-01-10 22:23, Chris Pavlina wrote:
 Sure, assign me to it. I should have time to work on it tonight or
 tomorrow.
 
 On Wed, Jan 10, 2018 at 04:20:21PM -0500, Wayne Stambaugh wrote:
> FYI, the edit footprint dialog in Pcbnew is not sized properly (at least
> on windows) which I'm pretty sure is related to your recent HiDPI work.
> Do you want me to file a bug report for it?
> 
> On 1/10/2018 2:01 PM, Chris Pavlina wrote:
>> By the way, I'm going to go ahead and push this tonight-ish if nobody
>> objects. I know it's on the big side, but due to my limited number of
>> machines to test on I really want time for user feedback. I'll be around
>> to put out any fires.
>> 
>> On Wed, Jan 10, 2018 at 11:07:49AM -0700, Chris Pavlina wrote:
>>> Rebased patch attached.
>>> 
>>> On Tue, Jan 09, 2018 at 01:27:16PM +, Maciej Sumiński wrote:
 Hi Chris,
 
 The patch does not apply cleanly on the current master, would you 
 rebase
 it? Thanks in advance.
 
 Cheers,
 Orson
 
 On 01/09/2018 03:43 AM, Chris Pavlina wrote:
> Hi,
> 
> As discussed with Wayne earlier, I've attached a patch which adds 
> simple
> toolbar icon scaling so the toolbars are readable on high-DPI systems.
> 
> This is meant as a stopgap for 5.0, with plans to add proper scaled
> icons in the 6.0 cycle. A function KiScaledBitmap() is added, which
> works like KiBitmap() except it scales the bitmap according to the
> calling window's font size. Controls have been added to all the main
> applications to let the user select scaling manually (these were 
> omitted
> from smaller apps that didn't already have a place to put them).
> 
> In addition, in eeschema only, the pixel height of the system font is
> shown in the options dialog for diagnostics. This is only for 
> collecting
> feedback before 5.0 release from users with different displays and 
> will
> be removed.
> 
> I would like to push this fairly soon, as I want to get as much user
> feedback as possible before release. I have a limited number of 
> systems
> to test this on myself.
> 
> 
> 
> ___
> Mailing list: https://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 : 

Re: [Kicad-developers] COMPONENT_TREE performance

[Jörg Hermann]

Gaurav asked for examples using Qt: Eagle.
As they implemented their awkward UI across all OS, I see no problems 
whatsoever for Kicad.

Having done multiplatform / multiarchitecture releases with Qt, I can confirm 
it was totally stable and automatized.

Wayne is correct, a huge amount of effort will go into the switch. At the same 
time there are numerous threads on this list about wx behaving differently on 
the platforms, you need to maintain patches, are bound to python 2 and what not.
I can’t remember that much hassle from Qt, and that was with Qt 3.

Olivers Idea is most practical: Where can we add griefs, pros and cons?

Jörg


___
Mailing list: https://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] Implement primitive icon scaling for high DPI

[kristoffer Ödmark]

I have 2560x1440, 24" screens, I think those qualifies as high DPI?

The slider value is at 100, and the diag value is at 23. The icons are 
ish 5mm large.


But i guess that is uneccesary since It seems the scaling works as 
intended, I was just doing it wrong, so no errors, sorry :)


The scaling seems correct as well, 100 = 5mm, 150 = 7.5, 200 = 11, 
measured with a tape measure, so variance in size is expected.



Application: kicad
Version: (2018-01-11 revision a5b3d8e57)-master, debug build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 
libpsl/0.19.1 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0

Platform: Linux 4.9.74-2-MANJARO x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.65.1
    Curl: 7.57.0
    Compiler: GCC 7.2.1 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=OFF
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=ON


On 2018-01-11 01:13, Chris Pavlina wrote:

If your system DPI is already within a certain range it won't do
anything. Are you using a high DPI display? If it's not scaled
correctly, would you please share with me the diagnostic number reported
by the scale slider in eeschema prefs as well as a rough indication of
the icons' physical size? Thanks.

On Wed, Jan 10, 2018 at 11:16:46PM +, kristoffer Ödmark wrote:

Tried the patch, didnt really notice anything different though, I guess you
need to add some custom scaling for this to take effect?


On 2018-01-10 22:23, Chris Pavlina wrote:

Sure, assign me to it. I should have time to work on it tonight or
tomorrow.

On Wed, Jan 10, 2018 at 04:20:21PM -0500, Wayne Stambaugh wrote:

FYI, the edit footprint dialog in Pcbnew is not sized properly (at least
on windows) which I'm pretty sure is related to your recent HiDPI work.
Do you want me to file a bug report for it?

On 1/10/2018 2:01 PM, Chris Pavlina wrote:

By the way, I'm going to go ahead and push this tonight-ish if nobody
objects. I know it's on the big side, but due to my limited number of
machines to test on I really want time for user feedback. I'll be around
to put out any fires.

On Wed, Jan 10, 2018 at 11:07:49AM -0700, Chris Pavlina wrote:

Rebased patch attached.

On Tue, Jan 09, 2018 at 01:27:16PM +, Maciej Sumiński wrote:

Hi Chris,

The patch does not apply cleanly on the current master, would you rebase
it? Thanks in advance.

Cheers,
Orson

On 01/09/2018 03:43 AM, Chris Pavlina wrote:

Hi,

As discussed with Wayne earlier, I've attached a patch which adds simple
toolbar icon scaling so the toolbars are readable on high-DPI systems.

This is meant as a stopgap for 5.0, with plans to add proper scaled
icons in the 6.0 cycle. A function KiScaledBitmap() is added, which
works like KiBitmap() except it scales the bitmap according to the
calling window's font size. Controls have been added to all the main
applications to let the user select scaling manually (these were omitted
from smaller apps that didn't already have a place to put them).

In addition, in eeschema only, the pixel height of the system font is
shown in the options dialog for diagnostics. This is only for collecting
feedback before 5.0 release from users with different displays and will
be removed.

I would like to push this fairly soon, as I want to get as much user
feedback as possible before release. I have a limited number of systems
to test this on myself.



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

Re: [Kicad-developers] [PATCH] Implement primitive icon scaling for high DPI

[kristoffer Ödmark]

I have 2560x1440, 24" screens, I think those qualifies as high DPI?

The slider value is at 100, and the diag value is at 23. The icons are 
ish 5mm large.


But i guess that is uneccesary since It seems the scaling works as 
intended, I was just doing it wrong, so no errors, sorry :)


The scaling seems correct as well, 100 = 5mm, 150 = 7.5, 200 = 11, 
measured with a tape measure, so variance in size is expected.



Application: kicad
Version: (2018-01-11 revision a5b3d8e57)-master, debug build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 
libpsl/0.19.1 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0

Platform: Linux 4.9.74-2-MANJARO x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.65.1
    Curl: 7.57.0
    Compiler: GCC 7.2.1 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=OFF
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=ON


On 2018-01-11 01:13, Chris Pavlina wrote:

If your system DPI is already within a certain range it won't do
anything. Are you using a high DPI display? If it's not scaled
correctly, would you please share with me the diagnostic number reported
by the scale slider in eeschema prefs as well as a rough indication of
the icons' physical size? Thanks.

On Wed, Jan 10, 2018 at 11:16:46PM +, kristoffer Ödmark wrote:

Tried the patch, didnt really notice anything different though, I guess you
need to add some custom scaling for this to take effect?


On 2018-01-10 22:23, Chris Pavlina wrote:

Sure, assign me to it. I should have time to work on it tonight or
tomorrow.

On Wed, Jan 10, 2018 at 04:20:21PM -0500, Wayne Stambaugh wrote:

FYI, the edit footprint dialog in Pcbnew is not sized properly (at least
on windows) which I'm pretty sure is related to your recent HiDPI work.
Do you want me to file a bug report for it?

On 1/10/2018 2:01 PM, Chris Pavlina wrote:

By the way, I'm going to go ahead and push this tonight-ish if nobody
objects. I know it's on the big side, but due to my limited number of
machines to test on I really want time for user feedback. I'll be around
to put out any fires.

On Wed, Jan 10, 2018 at 11:07:49AM -0700, Chris Pavlina wrote:

Rebased patch attached.

On Tue, Jan 09, 2018 at 01:27:16PM +, Maciej Sumiński wrote:

Hi Chris,

The patch does not apply cleanly on the current master, would you rebase
it? Thanks in advance.

Cheers,
Orson

On 01/09/2018 03:43 AM, Chris Pavlina wrote:

Hi,

As discussed with Wayne earlier, I've attached a patch which adds simple
toolbar icon scaling so the toolbars are readable on high-DPI systems.

This is meant as a stopgap for 5.0, with plans to add proper scaled
icons in the 6.0 cycle. A function KiScaledBitmap() is added, which
works like KiBitmap() except it scales the bitmap according to the
calling window's font size. Controls have been added to all the main
applications to let the user select scaling manually (these were omitted
from smaller apps that didn't already have a place to put them).

In addition, in eeschema only, the pixel height of the system font is
shown in the options dialog for diagnostics. This is only for collecting
feedback before 5.0 release from users with different displays and will
be removed.

I would like to push this fairly soon, as I want to get as much user
feedback as possible before release. I have a limited number of systems
to test this on myself.



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

Re: [Kicad-developers] Hotkeys Editor

[Thomas Kindler]

On Thu, January 11, 2018 09:37, Andrey Kuznetsov wrote:
> I wonder if "Undo All" is more appropriate if all the changes during that
>  session are undone, as opposed to just the last one.
>

That's very similar to "Cancel" then. Perhaps, we can remove the Undo
button entirely in this case.


> On Thu, Jan 11, 2018 at 12:35 AM, Thomas Kindler
> 
> wrote:
>
>
>>
>> On Thu, January 11, 2018 02:07, Seth Hillbrand wrote:
>>
>>> I feel that there is a usability issue with the current hotkeys
>>> editor that is a regression from the 4.0.7 hotkeys editor.
>>>
>>> I've attached images for both to this message.  The current editor
>>> opens with a tree view that hides the hotkeys below "Common".  Users
>>> would be forgiven for not realizing that there were additional hotkeys
>>> specific to each application -- see current_hotkeys.png
>>>
>>> Previously, the hotkeys were displayed in tabs that were, I think,
>>> more clear -- see prev_hotkeys.png.
>>>
>>> I don't recall when this change happened but I'd like any feedback on
>>>  whether folks are adverse to reverting to the 4.0.7 tabbed layout
>>> while keeping the "Reset" and "Defaults" buttons, that I think are
>>> really good additions.
>>
>> What's the difference between "Reset" and "Defaults"?
>>
>>
>> I think "Undo" and "Defaults" would be much better.
>>

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

Re: [Kicad-developers] Hotkeys Editor

[Andrey Kuznetsov]

I wonder if "Undo All" is more appropriate if all the changes during that
session are undone, as opposed to just the last one.

On Thu, Jan 11, 2018 at 12:35 AM, Thomas Kindler 
wrote:

>
> On Thu, January 11, 2018 02:07, Seth Hillbrand wrote:
> > I feel that there is a usability issue with the current hotkeys editor
> > that is a regression from the 4.0.7 hotkeys editor.
> >
> > I've attached images for both to this message.  The current editor opens
> > with a tree view that hides the hotkeys below "Common".  Users would be
> > forgiven for not realizing that there were additional hotkeys specific to
> >  each application -- see current_hotkeys.png
> >
> > Previously, the hotkeys were displayed in tabs that were, I think, more
> > clear -- see prev_hotkeys.png.
> >
> > I don't recall when this change happened but I'd like any feedback on
> > whether folks are adverse to reverting to the 4.0.7 tabbed layout while
> > keeping the "Reset" and "Defaults" buttons, that I think are really good
> > additions.
>
> What's the difference between "Reset" and "Defaults"?
>
> I think "Undo" and "Defaults" would be much better.
>
> --
> Thomas Kindler 
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>



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

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

Re: [Kicad-developers] Hotkeys Editor

[Thomas Kindler]

On Thu, January 11, 2018 02:07, Seth Hillbrand wrote:
> I feel that there is a usability issue with the current hotkeys editor
> that is a regression from the 4.0.7 hotkeys editor.
>
> I've attached images for both to this message.  The current editor opens
> with a tree view that hides the hotkeys below "Common".  Users would be
> forgiven for not realizing that there were additional hotkeys specific to
>  each application -- see current_hotkeys.png
>
> Previously, the hotkeys were displayed in tabs that were, I think, more
> clear -- see prev_hotkeys.png.
>
> I don't recall when this change happened but I'd like any feedback on
> whether folks are adverse to reverting to the 4.0.7 tabbed layout while
> keeping the "Reset" and "Defaults" buttons, that I think are really good
> additions.

What's the difference between "Reset" and "Defaults"?

I think "Undo" and "Defaults" would be much better.

-- 
Thomas Kindler 

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