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 _______________________________________________ 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