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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
