On Tue, Sep 10, 2013 at 7: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.
I did have exactly the same problem with all the stupid ssh library out there that where never designed to be integrated into a GUI. At the end, solution where tested in that order : - Use the library from a thread. - Implementation of ecore_coroutine, to be able to put a function in standby and go back to the main loop. - Use ssh binary and ecore_exe. - Implement a ssh library that does it right. I am now working on the fourth solution, all previous attemps resulted in failure. Take it as an hint on what you are trying to do and maybe jump directly to that solution. I have no idea what your library is doing, but I can tell you, it will be painful ! -- Cedric BAIL ------------------------------------------------------------------------------ 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
