kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 8/15/2014 8:47 AM, Dick Hollenbeck wrote:
> On 08/14/2014 07:31 PM, yann jautard wrote:
>>
>> Le 14/08/2014 16:21, Dick Hollenbeck a écrit :
>>>> I don't know if it is technically possible to change this behaviour, but 
>>>> I think it could be a great improvement.
>>>>
>>> :
>>>> yann
>>>>
>>> Hopefully QuasiModal is not a monster.
>>>
>>> For significant dialogs (ones which tend to be open for a while) using the QuasiModal
>>> support in DIALOG_SHIM might be a solution to this.  It disables the window which invokes
>>> the dialog, but nothing more.
>>>
>>> Without the QuasiModal support, the behaviour is platform specific.  On linux, I *CAN*
>>> open the schematic editor while viewing footprint properties and scroll, but I cannot
>>> close the schematic window.  So that behaviour is arguably worse, since it looks like a
>>> bug.  (It is not a bug that I would respond to.  Let's register it as folklore.)
>>
>> Hi Dick,
>>
>> This sounds pretty strange : I'm on linux too, and I can't. Kicad main window frozen when
>> dialog opened in pcbnew.
>>
>>>
>>> Remember if you cannot close a major KIWAY_PLAYER using system window decorations, this
>>> might be because you have a dialog window opened elsewhere on linux.
>>>
>>> Please see if this patch fixes the sample issue for you.  The QuasiModal support was
>>> something I came up with using only the wxWindows API, not a platform specific approach.
>>> I don't know that its been tested enough across all platforms.  Bad news is that there may
>>> not be anything I can do except for Linux to fix it, should it not work wonderfully on all
>>> platforms.
>>
>>
>>
>> Patch solved the issue, seemed to work like a charm... But induced another issue. Step to
>> reproduce :
>>
>> 1 - open kicad, then open eeschema and pcbnew
>> 2 - in pcbnew, open the module properties dialog on any part you want.
>> 3 - go back to eeschema, wich is now responding normally, and open  the component
>> properties dialog, on the same part or another one (doesn't matters).
>> 4 - go back to pcbnew, close the dialog, either with OK or Cancel --> dialog closes, but
>> pcbnew is frozen and also can't be closed in any normal way.
>> eeschema still works, you can close the dialog and use it normally. Kicad main window
>> works also.
>> Eeschema can be closed normally, kicad main window also, but when closing main window,
>> pcbnew window closes too, but the kicad process is still there and you need to kill it.
>>
>> I thought I will modify eeschema in the same way to test if it does something else, and so
>> I noticed the eeschema component properties dialog was alredy a QuasiModal one.
>>
>> And obviously the same test starting with eeschema instead of pcbnew leads to to opposite
>> result : eeschema stuck, pcbnew working.
>> And again, the need to kill kicad process after closing the main window.
> 
> 
> Excellent job testing, yann.
> 
> This will take some time to look into and I started last night.
> 
> Achieving platform independent and wx version independent results looks very difficult at
> this point.

There may be no way to completely fix this without coming up with a
really clever way of processing events between the dialog and the frame
that launched the dialog.  Modal dialogs in wxWidgets by design steal
the event queue from the current process.  Now that all of the top level
frames run in the same process, every open frame will be blocked any
time a modal dialog is run.  If you have Pcbnew and Eeschema open at the
same time, a modal dialog opened in Eeschema will prevent the Pcbnew
frame from receiving events and vice versa until the dialog is closed.
Modeless dialogs would be one possible solution except for one glaring
problem.  AFAIK every dialog (except the Eeshchema find dialog) in KiCad
directly handles the affirmative button event (typically ID_OK) and
calls EndModal() directly without checking to see if the dialog is
modal.  This design is flawed.  I hate to sound like a broken record but
wxValidators should have be used to transfer data between the control
and the data structure (decoupling) instead of directly handling this in
a button event.  This way dialogs could be either modal or modeless
without any changes.  Fixing this now would be a massive undertaking.
I'm not sure there will be a good solution to resolve this issue.