kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 08/15/2014 10:00 AM, Wayne Stambaugh wrote:
> 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.
> 


Actions speak louder than words.  And since your post does not even mention quasimodal, it
will not get a verbal one from me other than this.

I believe, as in faith or professional judgement, that the quasimodal support can be made
to work on any platform and wx version.  However doing all platforms and wx versions is
much work.  Still probably less work than any other path.

However, with the advent of wx3.0 in the Ubuntu package repo, I will focus on getting
quasimodal to work well on wx3.x for linux, and hope that also does the job on other
platforms too.  Where it does not work, we can use macros to defeat it and devolve to modal.

My motive to support wx2.8 is now zilch.  The project can make its own policy without my
input on wx2.8 support, but I personally won't spend another minute on it.

Here is my personal reasoning:  Ubuntu Trusty is free, my time is not.


Dick