kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 8/15/2014 3:00 PM, Dick Hollenbeck wrote:
> 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.

If it can be made to work well on all platforms than I am all for it.

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

I am fine with this.  wx3 has been available on Debian testing for quite
a while so I have no interest in supporting wx2.8 either.  Hopefully
before too long we can pull the plug on wx2.8.  I just saw that
python-wx3 recently made it into Debian testing which is really the last
major piece of the puzzle.  Windows and OSX have been using wx3 since
the later 2.9 versions.

> 
> Here is my personal reasoning:  Ubuntu Trusty is free, my time is not.
> 
> 
> Dick
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>