[Kicad-developers] BOM component table dialog (quasi-)modality in osx

[Dan Green]

Hi,  
I’ve lurked this list for quite some time, and finally applied to join, so 
thank you for approving me. I hope I can make some contributions to this 
excellent project.

I use KiCAD in OSX 10.12 and noticed an issue with the recent BOM component 
table feature.
When closing the dialog box, the main KiCAD windows and menus still behave as 
if a modal dialog box is still open: all menu items are greyed-out, and the 
windows don't respond to clicks or other events, and I have to kill the process 
from the OS.

After reading some explanations in the comments, I can’t say I fully grasp the 
issue, but when I try invoking and closing the dialog as QuasiModal, it seems 
to work. I don’t know if this breaks it for other OS’s or if it violates a UI 
policy, so please let me know if there’s a better way!

Attached is the simple hack I made.

thanks!

From 2253bec68af9b0b4ffc177bccc1325b4702ee084 Mon Sep 17 00:00:00 2001  
From: danngreen 
Date: Thu, 1 Jun 2017 13:08:17 -0700
Subject: [PATCH] Made BOM editor dialog quasi modal

---  
 eeschema/dialogs/dialog_bom_editor.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/eeschema/dialogs/dialog_bom_editor.cpp 
b/eeschema/dialogs/dialog_bom_editor.cpp  
index e5114e533..f1d9a9aee 100644
--- a/eeschema/dialogs/dialog_bom_editor.cpp
+++ b/eeschema/dialogs/dialog_bom_editor.cpp
@@ -44,7 +44,7 @@
 int InvokeDialogCreateBOMEditor( SCH_EDIT_FRAME* aCaller )
 {
 DIALOG_BOM_EDITOR dlg( aCaller );
-return dlg.ShowModal();
+return dlg.ShowQuasiModal();
 }
  
 DIALOG_BOM_EDITOR::DIALOG_BOM_EDITOR( SCH_EDIT_FRAME* parent ) :
@@ -129,6 +129,7 @@ bool DIALOG_BOM_EDITOR::CloseDialog()
 {
 if( !m_bom->HaveFieldsChanged() )
 {
+EndQuasiModal( wxID_CANCEL );
 Destroy();
 return true;
 }
@@ -146,6 +147,7 @@ bool DIALOG_BOM_EDITOR::CloseDialog()
break;
 }
  
+EndQuasiModal( wxID_CANCEL );
 Destroy();
 return true;
 }
--  
2.11.0


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

Re: [Kicad-developers] BOM component table dialog (quasi-)modality in osx

[Dan Green]

Hi Wayne, here’s the patch.

I appreciate your comments about the confusion over quasi-modal boxes.
In the future, what would be a good example to follow?
Perhaps DIALOG_EESCHEMA_OPTIONS?

thanks
Dan



0001-Made-BOM-editor-dialog-quasi-modal.patch
Description: Binary data


> On Jun 6, 2017, at 8:47 AM, Wayne Stambaugh <stambau...@gmail.com> wrote:
> 
> Dan,
> 
> Would you please send your patch using `git format-patch` as an
> attachment or inline in an email directly to me so I can commit it?  I
> tried using the response to your original message with `git am` but it
> didn't like it and I inadvertently deleted you original post.
> 
> Thanks,
> 
> Wayne
> 
> On 6/5/2017 8:49 AM, Bernhard Stegmaier wrote:
>> Hi,
>> 
>> I can confirm that with latest official nightly build (also on 10.12.x).
>> With my own builds using wxWidgets master (I know… officially unsupported) 
>> it doesn’t hang but just crashes on closing the window.
>> Different, but not better… :)
>> 
>> I also can confirm that the proposed fix works for my own wxWidgets master 
>> builds (no crash anymore, everything fine after closing the window).
>> So, I’d vote for submitting it...
>> 
>> 
>> Regards,
>> Bernhard
>> 
>>> On 2. Jun 2017, at 21:06, Wayne Stambaugh <stambau...@gmail.com> wrote:
>>> 
>>> Hello Dan,
>>> 
>>> Welcome to the KiCad developer's mailing list and thank you for your
>>> interest in contributing to KiCad.  We can always use another OSX
>>> developer.  It's the one platform where we could use the extra help.
>>> 
>>> The modal dialog issue became a problem when we moved from a multiple
>>> binary solution to a single binary solution.  The quasi-modal dialog
>>> mode allows the main application to continue to receive events while
>>> blocking events to the window that launched the dialog.  The problem is
>>> if another modal dialog is launched from the quasi-modal dialog then the
>>> same problem occurs.  I haven't tried to stack quasi-modal dialog calls
>>> so I'm not sure what the outcome would be but in theory it should work
>>> and would be a major improvement over what we have now.  The other
>>> option is to go modeless but that requires a lot of manual intervention
>>> between the window that launched the dialog and the dialog itself.  I
>>> agree that the BOM editor should be launched as quasi-modal rather than
>>> modal.   FYI, you really should be call EndQuasiModel from with the
>>> dialog because you cannot know ahead of time how the dialog was
>>> launched.  This is all handled correctly by the DIALOG_SHIM object close
>>> event handler.  We still seem to have trouble understanding how to
>>> properly close dialogs with wxWidgets.  Don't use the code in most of
>>> the dialogs in KiCad as they are incorrect and are poor examples of how
>>> to do it correctly.  There are a few that are correct and none of them
>>> call either EndQuasiModal or EndModal or even handle the OK and/or
>>> cancel button events.  They use TranferData{To,From}Window for updating
>>> the data between the controls and the object storage.
>>> 
>>> Cheers,
>>> 
>>> Wayne
>>> 
>>> 
>>> On 6/1/2017 4:47 PM, Dan Green wrote:
>>>> Hi, 
>>>> I’ve lurked this list for quite some time, and finally applied to join,
>>>> so thank you for approving me. I hope I can make some contributions to
>>>> this excellent project.
>>>> 
>>>> I use KiCAD in OSX 10.12 and noticed an issue with the recent BOM
>>>> component table feature.
>>>> When closing the dialog box, the main KiCAD windows and menus still
>>>> behave as if a modal dialog box is still open: all menu items are
>>>> greyed-out, and the windows don't respond to clicks or other events, and
>>>> I have to kill the process from the OS.
>>>> 
>>>> After reading some explanations in the comments, I can’t say I fully
>>>> grasp the issue, but when I try invoking and closing the dialog as
>>>> QuasiModal, it seems to work. I don’t know if this breaks it for other
>>>> OS’s or if it violates a UI policy, so please let me know if there’s a
>>>> better way!
>>>> 
>>>> Attached is the simple hack I made.
>>>> 
>>>> thanks!
>>>> 
>>>> From 2253bec68af9b0b4ffc177bccc1325b4702ee084 Mon Sep 17 00:00:00 2001
>>>> 
>>>> From: danngreen <danngre...@gm

[Kicad-developers] [Patch] Update PCB from Schematic hotkey in pcbnew and bug in schematic filename

[Dan Green]

Hi all, here are two patches to address some minor issues with the "Update PCB 
from Schematic” tool when called from pcbnew. The first adds the F8 hotkey to 
match eeschema. The second fixes a bug that happens if the project name 
contains a period (e.g.: MyProject_rev1.2). In this case, the wxFileName 
command SetExt() would detect an existing extension as “2” and replace it with 
“sch”. Thus using the tool from pcbnew would make it look for (and hopefully 
not find!) MyProject_rev1.sch. The bug wouldn’t happen if the schematic window 
was already open, so it was pretty rare.
thanks!
Dan


0001-Added-pcbnew-hotkey-for-Update-PCB-from-Schematic.patch
Description: Binary data


0002-Fixed-OnUpdatePCBFromSch-correctly-determines-schema.patch
Description: Binary data
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [Patch] Update PCB from Schematic hotkey in pcbnew and bug in schematic filename

[Dan Green]

Ah yes, of course, all that makes sense. Thanks for explaining it.
Alt+F8 is available, so attached is a patch using that as the default (and with 
IS_ACCELERATOR).  
thanks,
Dan
   

On Tuesday, September 26, 2017 at 6:57 AM, Wayne Stambaugh wrote:

> Hey Dan,
>  
> I have a few comments on your patches.
>  
> The "Update PCB from Schematic" patch uses a duplicate hotkey. F8 is
> already assigned to the HK_SWITCH_LAYER_TO_INNER4 command ID. Check the
> pcbnew/hotkeys.cpp file for the list of assigned hotkey. Also, you are
> using F8 as a menu accelerator not a hotkey which requires you to add
> the IS_ACCEL HOTKEY_ACTION_TYPE to the AddHotkeyName() call. You are
> going to have to choose a different hotkey and resubmit your patch.
>  
> Technically the file name fix patch works but you should use the
> wxFileName( path, name, ext) ctor to create the full file name. I've
> been trying to weed out this particular issue in KiCad but I must have
> missed this one. Also, there is no need to wrap "%s.%s" in with the
> internationalization macro _(). There is no text to translate in the
> string. I will fix this one now that I know where the issue exists.
>  
> Thanks,
>  
> Wayne
>  
> On 9/25/2017 7:19 PM, Dan Green wrote:
> > Hi all, here are two patches to address some minor issues with the "Update 
> > PCB from Schematic” tool when called from pcbnew. The first adds the F8 
> > hotkey to match eeschema. The second fixes a bug that happens if the 
> > project name contains a period (e.g.: MyProject_rev1.2). In this case, the 
> > wxFileName command SetExt() would detect an existing extension as “2” and 
> > replace it with “sch”. Thus using the tool from pcbnew would make it look 
> > for (and hopefully not find!) MyProject_rev1.sch. The bug wouldn’t happen 
> > if the schematic window was already open, so it was pretty rare.
> > thanks!
> > Dan
> >  
> >  
> >  
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net 
> > (mailto: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 
> (mailto:kicad-developers@lists.launchpad.net)
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>  




0001-Added-hotkey-in-pcbnew-for-Update-PCB-from-Schematic.patch
Description: Binary data
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [Patch] Update PCB from Schematic hotkey in pcbnew and bug in schematic filename

[Dan Green]

Odd, on macOS the menu displays properly as the option symbol+F8. Yes I can 
look into tomorrow, I have kicad building on a linux machine at work.

Looks like AddModifierToKey() in hotkeys_basic.cpp is adding an extra “Alt” to 
any accelerator key that’s not between ‘A’ - ‘Z’. 
Anyone know why this is? I’ll try to figure it out tomorrow…

Dan



> On Sep 28, 2017, at 9:47 AM, Wayne Stambaugh <stambau...@gmail.com> wrote:
> 
> Dan,
> 
> I found an issue but I don't think it's your issue but rather a bug in
> the AddHotKeyName() function.  The menu accelerator for the "Update PCB
> from Schematic" menu entry ends up being "Alt + Alt + F8" instead of
> "Alt + F8" (see attached image).  Do you have time to look at this and
> see if you can fix it?  The broken code is in common/hotkeys.cpp.  This
> will have to be fixed to include your patch.
> 
> Wayne
> 
> On 9/26/2017 6:35 PM, Dan Green wrote:
>> Ah yes, of course, all that makes sense. Thanks for explaining it.
>> Alt+F8 is available, so attached is a patch using that as the default (and 
>> with IS_ACCELERATOR).  
>> thanks,
>> Dan
>> 
>> 
>> On Tuesday, September 26, 2017 at 6:57 AM, Wayne Stambaugh wrote:
>> 
>>> Hey Dan,
>>> 
>>> I have a few comments on your patches.
>>> 
>>> The "Update PCB from Schematic" patch uses a duplicate hotkey. F8 is
>>> already assigned to the HK_SWITCH_LAYER_TO_INNER4 command ID. Check the
>>> pcbnew/hotkeys.cpp file for the list of assigned hotkey. Also, you are
>>> using F8 as a menu accelerator not a hotkey which requires you to add
>>> the IS_ACCEL HOTKEY_ACTION_TYPE to the AddHotkeyName() call. You are
>>> going to have to choose a different hotkey and resubmit your patch.
>>> 
>>> Technically the file name fix patch works but you should use the
>>> wxFileName( path, name, ext) ctor to create the full file name. I've
>>> been trying to weed out this particular issue in KiCad but I must have
>>> missed this one. Also, there is no need to wrap "%s.%s" in with the
>>> internationalization macro _(). There is no text to translate in the
>>> string. I will fix this one now that I know where the issue exists.
>>> 
>>> Thanks,
>>> 
>>> Wayne
>>> 
>>> On 9/25/2017 7:19 PM, Dan Green wrote:
>>>> Hi all, here are two patches to address some minor issues with the "Update 
>>>> PCB from Schematic” tool when called from pcbnew. The first adds the F8 
>>>> hotkey to match eeschema. The second fixes a bug that happens if the 
>>>> project name contains a period (e.g.: MyProject_rev1.2). In this case, the 
>>>> wxFileName command SetExt() would detect an existing extension as “2” and 
>>>> replace it with “sch”. Thus using the tool from pcbnew would make it look 
>>>> for (and hopefully not find!) MyProject_rev1.sch. The bug wouldn’t happen 
>>>> if the schematic window was already open, so it was pretty rare.
>>>> thanks!
>>>> Dan
>>>> 
>>>> 
>>>> 
>>>> ___
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to : kicad-developers@lists.launchpad.net 
>>>> (mailto: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 
>>> (mailto: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 
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp 
>> <https://help.launchpad.net/ListHelp>
>> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <https://help.launchpad.net/ListHelp>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [Patch] Update PCB from Schematic hotkey in pcbnew and bug in schematic filename

[Dan Green]

On Friday, September 29, 2017 at 11:32 PM, jp charras wrote:

> Le 29/09/2017 à 03:51, Dan Green a écrit :
> > Odd, on macOS the menu displays properly as the option symbol+F8. Yes I can 
> > look into tomorrow, I
> > have kicad building on a linux machine at work.
> >  
> > Looks like AddModifierToKey() in hotkeys_basic.cpp is adding an extra “Alt” 
> > to any accelerator key
> > that’s not between ‘A’ - ‘Z’.  
> > Anyone know why this is? I’ll try to figure it out tomorrow…
> >  
> > Dan
>  
> AddHotkeyName automatically adds “Alt” or "Ctrl" to a key if IS_ACCELERATOR 
> option is used.
>  
> IS_ACCELERATOR option modify the key code and is useful *only* if the "same" 
> key (like hotkeys ZOOM
> F1 and F2 and a few others) is used *both* as hotkey and accelerator, and if 
> the action is nearly
> the same but differs by using the mouse position.
> (For instance in zoom: the zoom center is the mouse position if the hotkey is 
> pressed, and the
> screen center if the menu or accelerator key is pressed).
>  
> This is due to the fact I never found a easy way (common to the 3 platforms) 
> to know if a menuitem
> was activated by a click on it or by its accelerator key to use or not the 
> mouse position.
>  
> If it is not the case (if the key is not also used as hotkey or if the mouse 
> position is not used),
> do not use IS_ACCELERATOR option that adds a SHIFT or ALT to the base key.
> Just set the key code: in this case ALT+F8 (or perhaps CTRL+F8)
>  
Thanks jp, I see what IS_ACCELERATOR is for now.  
The easy solution would be to patch AddHotkeyName() and/or AddModifierToKey() 
to disallow adding an Alt if an Alt  
already exists in the hotkey (in which case, try adding Ctrl, etc).

But thinking about this more, it seems that there are really two distinct 
actions we want to do. For example:
Begin Wire (W = hotkey) vs. switch to Wire Tool (Shift+W = accelerator/menu)

Perhaps each action needs its own entry in the *_Hotkey_List, and its own 
command event ID (e.g. there would be  
ID_BEGIN_WIRE in addition to ID_WIRE_BUTT)

From the user’s perspective, this would match the menu bar displaying Shift+W, 
vs. the WIDGET_HOTKEY_LIST  
displaying just W. An added benefit would be that it won’t be confusing to a 
user who tries to change a new hotkey  
in the preferences, and sees it showing up as having an extra Shift or Alt 
added to it in the menu bar.

Is this worthwhile to change, or is there some other layer of complexity I’m 
missing that requires us to tie the two  
actions together? I can volunteer to tackle this unless you or someone else 
would prefer.

Also on my short to-do list is to bring the hotkeys up to compliance with Mac 
OS keyboards, allowing for use of (raw) Ctrl  
for hotkeys, and calling Alt by it’s Mac name “Opt”.

thanks,
Dan
>  
> >  
> >  
> > > On Sep 28, 2017, at 9:47 AM, Wayne Stambaugh <stambau...@gmail.com 
> > > <mailto:stambau...@gmail.com>>
> > > wrote:
> > >  
> > > Dan,
> > >  
> > > I found an issue but I don't think it's your issue but rather a bug in
> > > the AddHotKeyName() function. The menu accelerator for the "Update PCB
> > > from Schematic" menu entry ends up being "Alt + Alt + F8" instead of
> > > "Alt + F8" (see attached image). Do you have time to look at this and
> > > see if you can fix it? The broken code is in common/hotkeys.cpp. This
> > > will have to be fixed to include your patch.
> > >  
> > > Wayne
> > >  
> > > On 9/26/2017 6:35 PM, Dan Green wrote:
> > > > Ah yes, of course, all that makes sense. Thanks for explaining it.
> > > > Alt+F8 is available, so attached is a patch using that as the default 
> > > > (and with IS_ACCELERATOR).  
> > > > thanks,
> > > > Dan
> > > >  
> > > >  
> > > > On Tuesday, September 26, 2017 at 6:57 AM, Wayne Stambaugh wrote:
> > > >  
> > > > > Hey Dan,
> > > > >  
> > > > > I have a few comments on your patches.
> > > > >  
> > > > > The "Update PCB from Schematic" patch uses a duplicate hotkey. F8 is
> > > > > already assigned to the HK_SWITCH_LAYER_TO_INNER4 command ID. Check 
> > > > > the
> > > > > pcbnew/hotkeys.cpp file for the list of assigned hotkey. Also, you are
> > > > > using F8 as a menu accelerator not a hotkey which requires you to add
> > > > > the IS_ACCEL HOTKEY_ACTION_TYPE to the AddHotkeyName() call. You are
> > > > > going to

Re: [Kicad-developers] Need testers for a patch to merge hotkeys and accelerators

[Dan Green]

I’m testing the V2 patch on OS X now. I made sure the hotkeys were set back to 
their defaults in the preferences before testing.
Unfortunately, pressing a hotkey just triggers the accelerator action, and not 
the hotkey. Same thing in eeschema as well as GAL and Legacy canvases.

Oddly, in GAL and Legacy canvases, when the Track tool is already the current 
tool, pressing Ctrl+X will trigger the hotkey and a new track will begin from 
the mouse position. There is one difference I see between GAL and Legacy: In 
GAL if the Track tool is not current, Ctrl+X does *not* trigger the hotkey. But 
in Legacy, regardless of what tool is current, Ctrl+X calls the hotkey and 
starts a new track immediately.
Eeschema’s hotkeys behave the same as pcbnew Legacy: for example W will always 
call the accelerator. Like pcbnew legacy canvas, Ctrl+W will call the hotkey.

By ‘Ctrl’ I mean the OS X Control key, i.e. WXK_RAW_CONTROL

As far as the python scripting console, I’m not sure what to be testing here. 
All keys, including ‘O’ and ‘X’, show up in the console window when I type.

Hope that helps. Thanks,
Dan




On Wednesday, October 4, 2017 at 5:10 AM, jp charras wrote:

> Le 03/10/2017 à 21:01, jp charras a écrit :
> > Hi All,
> >  
> > Currently, when a key is used as hotkey and if we want to display it in a 
> > sub-menu of the main menu,
> > because it becomes a accelerator key, we need to modify it (adding shift or 
> > alt modifier) when the
> > action differs (uses the mouse position) when called from a menu or a key.
> >  
> > Although there are not a lot of cases (zoom in and out are 2 cases, and 
> > there are more cases in
> > Eeschema), this is annoying for 2 reasons:
> > - Many users do not know the difference between a accelerator key and a 
> > hotkey.
> > - 2 similar actions use 2 keys instead of only one key, and we do not have 
> > a lot of available keys
> > for hotkeys, so wasting a few keys is very annoying.
> >  
> > I wrote a patch to use the same key as accelerator key and hotkey.
> >  
> > In fact, if a menu uses (for a accelerator key) the same key as a hotkey, 
> > the key event is not sent
> > to this menu, and the "accelerator key" becomes just a comment in menu.
> >  
> > To do that, the EVT_CHAR_HOOK key event is now managed by the main frame 
> > and is filtered, and not
> > sent to the GUI if a hotkey handles this key event (this is the normal way 
> > to handle keys whenn we
> > have special requirements).
> >  
> > Unfortunately, the way EVT_CHAR_HOOK and EVT_CHAR key events are exactly 
> > working is highly dependent
> > of platforms, and a bit tricky.
> >  
> > I tested this patch on Windows 32 bits, and partially on Linux (I was not 
> > able to test the python
> > console), but not on OSX.
> >  
> > Obviously, it must be tested (both in legacy canvas and GEL canvas) on OSX, 
> > and Linux (and of course
> > on Windows 64 bits), and especially with Pcbnew in python console:
> > are all chars captured in the console, especially the 2 accelerators 'O' 
> > and 'X'
> >  
> > Thanks.
>  
> I fixed some issues found in my first patch.
> I also tested the wxpython console both on Windows and Linux.
> I fixed an issue on Linux, and the python console works now.
>  
> So tests on OSX are now needed.
>  
> Thanks
>  
> --  
> Jean-Pierre CHARRAS
>  
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net 
> (mailto:kicad-developers@lists.launchpad.net)
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>  
>  
> Attachments:  
> - merge_hotkeys_and_accelerators_V2.patch
>  




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

Re: [Kicad-developers] eeschema copy working?

[Dan Green]

Hi Bernhard,  
Selecting a block and then hitting Cmd-C works for me in the latest master 
branch. The Paste toolbar icon becomes un-grey when I hit Cmd-C and the block 
becomes de-selected. Then clicking the Paste icon inserts a new block that I 
can place by clicking. Likewise, hitting Cmd-V does the same as the Paste icon.

However, the toolbar icons for Cut or Copy don't work for me. They un-grey when 
I drag to create a block, but as soon as I move the mouse even one pixel, they 
go back to grey. So I never have the chance to click them when they’re un-grey.

The contextual menu for “Cut” or “Copy” also doesn’t work for me. Selecting 
these in the contextual menu doesn’t seem to have any effect on the clipboard 
or the block (existing data in the clipboard stays there, and if it was empty 
it will remain empty, and the block does not get removed if I select Cut). 
Other contextual menu items that effect blocks work fine (Duplicate Block, Drag 
Block…)

Dan
  


On Tuesday, October 24, 2017 at 11:52 AM, Bernhard Stegmaier wrote:

> Hi all,
>  
> does copy of a selected block in eeschema (master branch) in general 
> work right now (on Windows, Linux)?
> For me on macOS it doesn’t seem to work in any way…
>  
> I can select a block, then either hit Cmd-C or select copy via context menu.
> If I try to paste via Cmd-V I just get a warning “No block to paste”.
> Toolbar buttons also don’t work - just greyed out all the time.
> I can remember that buttons always had some issues, but at least using 
> shortcuts did work some while ago...
>  
>  
> Regards,
> Bernhard
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net 
> (mailto: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] GAL canvas strategy - testers needed!

[Dan Green]

> -Click+dragging on a symbol starts a selection rectangle instead of moving 
> the symbol

Scratch this one. It's the same behavoir as in the current nightly. 


> On Sep 7, 2018, at 5:36 PM, dann  wrote:
> 
> Nice!
> 
> Here’s a few things I found on OSX 10.13.6, Retina iMac:
> 
> -Click+dragging on a symbol starts a selection rectangle instead of moving 
> the symbol
> 
> -With the schematic and PCB windows open at the same time, clicking a 
> footprint on the PCB makes the schematic jump and zoom, but it doesn’t always 
> put the selected component in view. Often the entire schematic is zoomed out 
> and/or panned off-screen. It seems to be inconsistent, that is, it doesn’t 
> always pan and zoom to the same place when clicking on the same component.
> 
> -Likewise, I have to double-click a symbol in eeschema to have it highlight 
> in the PCB window. This opens up the Symbol Properties dialog box as well. 
> Single clicking seems to have no effect.
> 
> -When changing the anti-aliasing mode, immediately after closing the 
> Preferences window, the schematic pane goes solid blue for a moment. The 
> toolbars stay normal, just the center pane turns blue.
> 
> -Toggling the “Use touchpad to Pan” setting has no effect until Eeschema is 
> closed and re-opened.
> 
> -Junctions are drawn underneath components. Not sure if this is good or bad, 
> just different from the non-GAL version.
> 
> -I get this Debug Alert when I use the wire tool. It happens whenever I end a 
> wire segment by double-clicking:
> 
> /Users/design/src/kicad-mac-builder/build/kicad/src/kicad/common/dlist.cpp(104):
>  assert "item->GetList() == " failed in append().
> Call stack:
> [00] SCH_SCREEN::Append(DLIST&) sch_screen.h:16
> [01] SCH_BASE_FRAME::AddToScreen(DLIST&)sch_base_frame.cpp:57
> [02] SCH_EDIT_FRAME::EndSegment() bus-wire-junction.cpp:32
> [03] SCH_EDIT_FRAME::OnLeftDClick(wxDC*, wxPoint const&)  
> onleftclick.cpp:45
> [04] SCH_DRAW_PANEL::OnMouseEvent(wxMouseEvent&)  sch_draw_panel.cpp:30
> [05] wxEvtHandler::SearchDynamicEventTable(wxEvent&) 
> [06] wxEvtHandler::ProcessEventLocally(wxEvent&) 
> [07] wxEvtHandler::ProcessEvent(wxEvent&)
> [08] wxEvtHandler::ProcessPendingEvents()
> [09] wxAppConsoleBase::ProcessPendingEvents() 
> [10] wxCFEventLoop::OSXCommonModeObserverCallBack(__CFRunLoopObserver*, int, 
> void*) 
> [11] __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ 
> [12] __CFRunLoopDoObservers  
> [13] __CFRunLoopRun  
> [14] CFRunLoopRunSpecific
> [15] RunCurrentEventLoopInMode   
> [16] ReceiveNextEventCommon  
> [17] _BlockUntilNextEventMatchingListInModeWithFilter 
> [18] _DPSNextEvent   
> [19] -[NSApplication(NSEvent) 
> _nextEventMatchingEventMask:untilDate:inMode:dequeue:] 
> [20] -[NSApplication run]
> Do you want to stop the program?
> You can also choose [Cancel] to suppress further warnings.
> 
> Hope that helps! Really happy to see this come along
> 
> Cheers,
> Dan
> 
> 
>> On Sep 6, 2018, at 8:57 AM, Tomasz Wlostowski  
>> wrote:
>> 
>> On 06/09/18 17:37, Jeff Young wrote:
>>> Hi Tom,
>>> 
>>> I have committed the completion of the block rotate and mirror fixes 
>>> (including for LibEdit).
>> 
>> Hi Jeff,
>> 
>> Thanks, I played with eeschema for a short while and I really appreciate
>> all the work you have done!
>> 
>> Dear devs (non-devs too ;-) - whoever is interested in testing this
>> branch, please compile this and send the feedback here:
>> 
>> https://git.launchpad.net/~jeyjey/kicad/log/?h=tom-eeschema-gal-aug27
>> 
>> Cheers,
>> Tom
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 


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