On Tue, 10 Sep 2013 13:45:34 -0400 Robert Heller <hel...@deepsoft.com> said:
> 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. then that library has not been designed with mainloop driven setups. is there another way to do it? you could put that lib usage into a thread of its own and message back and forth - you could use ecore_thread_feedback_run(...,EINA_TRUE) with an explicit special thread of its own - use an ecore_pipe() to send data to the thread, with the heavy thread simply driving the lib and thus its callback, and use the thread feedback func + end func to deliver responses and final decision to the mainloop... -- ------------- 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
