you will have anyway #ifdef because of the [win32 | fd]_handler_add() in ethumb_slave, so...
On Sat, Dec 24, 2016 at 1:45 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Fri, 23 Dec 2016 12:50:34 +0100 Vincent Torri <vincent.to...@gmail.com> > said: > >> On Fri, Dec 23, 2016 at 11:23 AM, Andrii Kroitor <an.kroi...@samsung.com> >> wrote: >> > >> > On 23.12.16 06:35, Vincent Torri wrote: >> >> hey >> >> >> >> i don't like the idea of getc/ungetc in the thread, imho it's a bad hack >> >> you do that for ethumb_slave, i guess, but i think that the wait for >> >> input should be in ethumb slave, with a thread and ReadConsole(). and >> >> not the hack you did >> >> >> >> Vincent >> >> >> >> ------------------------------------------------------------------------------ >> >> Developer Access Program for Intel Xeon Phi Processors >> >> Access to Intel Xeon Phi processor-based developer platforms. >> >> With one year of Intel Parallel Studio XE. >> >> Training and support from Colfax. >> >> Order your platform today.http://sdm.link/intel >> >> _______________________________________________ >> >> enlightenment-devel mailing list >> >> enlightenment-devel@lists.sourceforge.net >> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> >> >> > I'm also not 100% happy with getc/ungetc thread, but this was the only >> > solution, that works in all cases. >> > I have tried various approaches, but all other are failing to wait for >> > input correctly at least in one of the following cases: >> > 1. direct run and input from console >> > 2. debug run and input from console (yep, this is somehow different from >> > case 1 :( ) >> > 3. redirected stdin input ( "app.exe <in.txt" ) >> > 4. direct run within pipeline ( "some_other_app.exe | app.exe" ) >> > 5. run as subprocess with stdin replaced with pipe from parent (i.e. >> > parent uses ecore_exe) >> > >> > If I remember it right ReadConsole will fail in cases 3-5. >> > >> > So if you find some better solution that will work in all this cases it >> > will be great. > > the POINT of moving it to a thread and just using getc/gets was to be portable > and not have #ifdef'd per os solutions. > >> 1) try with filtering the console mode and flushing the buffer in >> ethumb_slave: >> >> DWORD old_mode; >> HANDLE stdin_handle; >> stdin_handle = GetStdHandle(STD_INPUT_HANDLE); >> GetConsoleMode(, &old_mode); >> mode = oldmode ^ ENABLE_MOUSE_INPUT ^ ENABLE_WINDOW_INPUT; >> SetConsoleMode(stdin_handle, mode); >> FlushConsoleInputBuffer(stdin_handle); >> >> then you should be able to wait on stdin_handle after that. >> >> anyway, ReadConsoleInput() should be used intead of read() >> >> you should restore the old mode to restore it at the end : >> >> SetConsoleMode(stdin_handle, old_mode); >> >> 2) try to redirect console input handle (not tested): >> >> HANDLE stdin_handle; >> int fd; >> FILE *fp; >> >> stdin_handle = GetStdHandle(STD_INPUT_HANDLE); >> fd = _open_osfhandle((intptr_t)stdin_handle, _O_TEXT); >> fp = _fdopen(fd, "r"); >> *stdin = *fp; >> setvbuf(stdin, NULL, _IONBF, 0); >> >> 3) there is another possibility : using WSAWaitForMultipleEvents(), >> but that would mean another way to add a handler in ecore_main.c. >> >> note that it would save my day for another thing i'am working on. >> >> >> > I disagree with you about this code placement. My point is that as many >> > as possible platform-dependent things should be in libraries rather than >> > in client-side code. >> >> it's not possible to have everything platform dependant. I know some >> stuff that will never be platform dependant, by the very nature of >> Windows. >> >> but I think that the ecore_exe way should be the way to go, even if it >> needs modifications >> >> Vincent >> >> > -- >> > *Best Regards, >> > Andrii Kroitor >> > * Engineer, Tizen Platform Lab >> > >> > Samsung R&D Institute Ukraine >> > 57, Lva Tolstogo St., Kyiv 01032, Ukraine >> > email: an.kroi...@samsung.com <mailto:an.kroi...@samsung.com> >> > >> > >> > ------------------------------------------------------------------------------ >> > Developer Access Program for Intel Xeon Phi Processors >> > Access to Intel Xeon Phi processor-based developer platforms. >> > With one year of Intel Parallel Studio XE. >> > Training and support from Colfax. >> > Order your platform today.http://sdm.link/intel >> > _______________________________________________ >> > enlightenment-devel mailing list >> > enlightenment-devel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> >> ------------------------------------------------------------------------------ >> Developer Access Program for Intel Xeon Phi Processors >> Access to Intel Xeon Phi processor-based developer platforms. >> With one year of Intel Parallel Studio XE. >> Training and support from Colfax. >> Order your platform today.http://sdm.link/intel >> _______________________________________________ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
