kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 8/19/2015 4:03 PM, jp charras wrote:
> Le 19/08/2015 21:12, Wayne Stambaugh a écrit :
>>
>>
>> On 8/19/2015 12:10 PM, Lorenzo Marcantonio wrote:
>>> On Wed, 19 Aug 2015 17:47:56 +0200,
>>> Wayne Stambaugh wrote:
>>>
>>>> This may be window manager related.  I get no assertion on windows.
>>>> I've seen this before and it appears to be a unfortunate side effect of
>>>> the Kiway design.  Any dialog derived from DIALAG_SHIM must have a Kiway
>>>> object as a parent if it is shown as quasimodal.  If you try to make the
>>>> parent another DIALOG_SHIM object, you will get the assertion.  If you
>>>> don't derive you dialog from DIALOG_SHIM and show it as modal, it will
>>>> block all of the other open main windows launched by KiCad.
>>>
>>> So no nested dialogs seems the solution... other than junking kiway
>>> which sadly is not feasible :P (still don't like it)
>>
>> The problem is replace it with what?  Kiway tries to straddle the
>> difference between the all windows in one process behavior versus the
>> each application in it's own process behavior.  It does it about as well
>> as could be expected unless you switch to entirely modeless dialogs
>> which opens an entirely new set of issues.  I'm wondering if we should
>> just use a multiple document interface (MDI) based on wxAui.  This way
>> when a modal dialog blocks the application, users won't assume that all
>> of the other windows are still usable.  A lot of this has to due with
>> users being used to the old behavior when Pcbnew and Eeschema were
>> launched by kicad as a separate process which had it's own set of issues.
>>
>>>
>>> As a workaround what about to change the code flow so that the change
>>> footprint is opened after the closure of the footprint properties? there
>>> is no need for it to be kept open. Shouldn't be difficult to add a
>>> return value from the properties saying 'closed down but now open the
>>> change footprint'.
>>>
>>> Or move the whole change footprint launch from the footprint properties
>>> to the footprint menu (seems better to me, given that it can also do
>>> mass updates).
>>
>> I actually was considering this myself.  I don't like launching a dialog
>> from a dialog.  I would rather remove the "Change Footprint(s)" and
>> "Footprint Editor" launch buttons from the footprint properties dialog.
>>  The footprint editor can already be opened directly from the footprint
>> context menu or the Ctrl+E hot key.  There is no reason we couldn't add
>> a context menu entry and a hot key to directly open the change footprint
>> dialog.  It seem like being able to directly open the change footprints
>> dialog would be an improvement over having to open the footprint
>> properties dialog first.
>>
>>>
>>> Or simply do nothing, I reported the fault but it's possible that
>>> nothing bad is really happening undercover...
>>>
> 
> I can reproduce that on Windows.
> This is really a (very minor) bug:
> the EndQuasiModal() in the footprint properties dialog is actually
> called twice:
> one time because is is called in the function which open the exchange
> footprint dialog
> one time when clicking on the close button (this is possible because the
> exchange footprint dialog is called quasi modal (to allow running the
> footprint viewer).
> 
> Like in many cases, the first call is delayed because it is made after
> opening the exchange footprint dialog. (this is frequently the case in
> dialogs and it is a normal behavior: closing them is not deleting them).
> And when the exchange footprint dialog is closed, this delayed call is
> executed.
> 
> It is not due to an issue in Kiway (which works fine).
> I have fixed this issue in my working tree (just moving the call before
> opening the exchange footprint dialog).
> 
> 

JP,

Have you committed this fix in your recent commits?

Thanks,

Wayne