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? :) Lucas De Marchi ------------------------------------------------------------------------------ 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
