kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 08/15/2014 02:16 PM, Wayne Stambaugh wrote:
> 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.


It gives you 3 tools in the toolbox, not just 2.  Nobody wants all modeless dialogs.
Nobody wants all modal dialogs.  Nobody wants all quasimodal dialogs.


I can only think about a handful of places for quasimodal, and a handful for modeless.

The user's expectation by far is mostly modal.  When prompted for a filename, imagine
losing track of that kind of dialog if that was modeless.  It could get covered up, and
you'd wonder what you were doing.  If you are like me and my 17 concurrently open PDF
files, you forget what you were even looking for, what day of the week it is, and where
that window is.

The solution strategies, none of them, are mutually exclusive.

However, in the case where quasimodal is either already in use or being discussed, it
seems like the best solution.  It is not a sacrifice from optimal.  It is optimal.

OSX has quasimodal dialog support natively.  This is for a reason.  They saw it solving a
need unmet using the other two dialog types, and I do too.


Dick



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