kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 21/08/2015 15:20, Wayne Stambaugh a écrit :
> 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

Yes, in rev 6109, with minor enhancements in exchange footprints dialog.
(See rev 6109 commit report)
Unfortunately, I forgot to say in the commit report the Bug #1481037 is
fixed.


-- 
Jean-Pierre CHARRAS