Thank you very much for your help. Now I've realized the magnitude of gui programming. I tried vb once but ... ( no wonder why ppl call vb a "barbie" programming (%) )
> Hope this helps. It's a great help. I have to understand how the "terminal" and the "ping" has been used with fltk. These are the matters I have been looking for. First I should concentrate on http://seriss.com/people/erco/fltk/unix-bidir-dumb-terminal.cxx Thanx again. > > The main point I try to understand is how a gui library interacts > > with unix system call and other system tools. If I develop a console > > (CLI) based program, and later implement the same program in gui then > > what I need to do. Rewrite it with C++ and fltk or develop a gui (with > > buttons, labels, text boxes etc) and attach the native c program to > > it. > > Command line programs and GUIs usually work in completely different ways. > The command line allows input and produces output based on it, and the > code is usually very sequential in nature. GUIs tend to be event driven > with internal state machines, because at any point there are so many > different things that the user can do (hide/show/resize the window, > click on different buttons, enter things in different fields, and you > have very little control over what is going to happen next. So it's not > always a straightforward task to add a GUI to a command line utility. > > Secondly, you need to understand that there are different ways of one > program calling and interacting with another. In Unix, the system() call > is probably the crudest: the thread of execution in your program is > completely suspended while the called program is running. Of course, > you may use fork() or threads, but your child process or thread will > not get back full control until the system() call completes. To allow > a bit more interaction between your program and the called one, you > can use popen(), but your program still needs to handle asynchronous > communication with the one it is calling. None of this is FLTK specific. > > If you are handling asynchronous communications in FLTK you are > probably going to need a multithreaded application, where the main > thread handles the GUI (some operating systems require this so this > is the FLTK advice for portability reasons) and the other threads do > the work. Then you can either arrange for the main GUI thread to read > data from the other threads, or the other threads have to call a lock, > request the GUI to do some update, and then unlock again, and then let > the GUI thread do the update when it is next scheduled to do so. > > Greg's Cheat Sheet has several examples of popen: > http://seriss.com/people/erco/fltk/#add_fd > http://seriss.com/people/erco/fltk/#SimpleTerminal > > Locking is demonstrated in the fltk-1.3/test/threads.cxx demo. > > Hope this helps. > D. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
