On Tue, 10 Sep 2013 22:06:39 -0300 Lucas De Marchi <lucas.demar...@profusion.mobi> said:
> On Tue, Sep 10, 2013 at 10:02 PM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Tue, 10 Sep 2013 21:53:59 -0300 Lucas De Marchi > > <lucas.demar...@profusion.mobi> said: > > > >> On Tue, Sep 10, 2013 at 2:45 PM, Robert Heller <hel...@deepsoft.com> wrote: > >> > At Tue, 10 Sep 2013 17:51:38 +0100 Michael Blumenkrantz > >> > <michael.blumenkra...@gmail.com> wrote: > >> > > >> >> > >> >> On Tue, 10 Sep 2013 12:34:21 -0400 > >> >> Robert Heller <hel...@deepsoft.com> wrote: > >> >> > >> >> > I am in the process of modifying E17 (I want to add so additional > >> >> > functionality to the file manager). One of the things I need to be > >> >> > able to do is have a 'modal' dialog, that is a dislog box that grabs > >> >> > the focus and causes the program (the file manager) to wait. I want > >> >> > events to be processed, but I want psuedo code like this: > >> >> > > >> >> > dialog = make_dialog(...); > >> >> > show(dialog); > >> >> > wait_for(dialog); > >> >> > > >> >> > The 'wait_for()' call would not return until the OK button or Cancel > >> >> > (close) button on the dialog has been clicked. It is not clear how to > >> >> > do this -- the documentation does not seem to cover this case (or I > >> >> > can't it in the documentation). > >> >> > > >> >> > Any pointers would be helpful. Thanks in advance. > >> >> > > >> >> > >> >> yeahhh you can't do that. > >> >> > >> >> what you CAN do is something like the > >> >> uhh...modules/conf_theme/e_int_config_wallpaper.c dialog does. you set > >> >> the parent dialog (though make sure you do this AFTER you show both > >> >> dialogs or it won't work) to set up your modal: the first param is your > >> >> intended modal, the second is the parent window which is getting > >> >> blocked. then you can basically just wait for the modal to die and > >> >> you'll know that there will be no events on the parent. > >> >> > >> >> I'll say this, however: we STRONGLY discourage the use of modal dialogs > >> >> in e. unless you have a really good reason for it, I'm unlikely to > >> >> accept any patches which introduce modal dialogs. > >> > > >> > Yes, I fully understand the 'evils' of modal dialogs, but there are times > >> > when it is the only option. In this case I am interfacing to a library > >> > that has a callback that wants some input (a passphrase) and I cannot > >> > just return without the passphrase and I don't know (in advance) if the > >> > passphrase is even needed or what the hint for the passphrase is (this > >> > info gets passed into the callback). And the callback might be called > >> > again if the passphrase is wrong. I may implement this with a > >> > subprocess, but then the subprocess itself will need to have a modal > >> > dialog. I am only interested a *local* type modal dialog. > >> > >> If you know the evils of modal dialogs: back in 2010 when working in > >> webkit I remember opening another mainloop for doing modal dialogs. > >> Then spending a day to fix nested mainloops in EFL. Things might be > >> better these days. > > > > you poor bastard :( > > > hehe... note that I'm not recommending to do it. Just to make it stronger: > > AVOID IT AS YOU CAN!! IF YOU CAN'T, RUN! > > Better this way? :) very clear. and my advice is the same. do everything you can to avoid modal-style coding (separate from ui modality - which is in and of itself also evil, but in different ways). if you have a library or api forcing modal coding styles, work around it somehow (eg subprocess or threads+messaging) and then pass on your complaints to whoever owns/maintains that api and try and get it fixed. send patches. whatever... we must rid the world of this disease! -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
