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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
