kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

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


-- 
Jean-Pierre CHARRAS