Re: [Kicad-developers] BOM component table dialog (quasi-)modality in osx
Hey Dan,
I committed your patch to the master branch. Thank you for your
contribution to KiCad.
Cheers,
Wayne
On 6/6/2017 12:31 PM, Dan Green wrote:
> 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
>
>
>
>
>
>> On Jun 6, 2017, at 8:47 AM, Wayne Stambaugh 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 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
>
> 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 )
>
> {
>
Re: [Kicad-developers] BOM component table dialog (quasi-)modality in osx
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 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 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
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_
Re: [Kicad-developers] BOM component table dialog (quasi-)modality in osx
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 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
>>>
>>> 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;
>>>
>>> }
>>>
>>
Re: [Kicad-developers] BOM component table dialog (quasi-)modality in osx
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 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
>>
>> 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
>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-develope
Re: [Kicad-developers] BOM component table dialog (quasi-)modality in osx
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
>
> 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
>
___
Mailing list: https://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] BOM component table dialog (quasi-)modality in osx
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
