On 18 Mar 2012, at 08:49, vectrum wrote:
> Thank you.
>
>> It's unlikely that both sides of the fork() call can access the
>> fltk = > context:
>
> If I'm not mistaken, this might be the reason why my code gives
> two different output. In CLI, it prints both write calls (child
> and parent) but in eclipse, it prints only child call.
Quite likely - though I'd assume that your Eclipse is using gdb for the
debugger, so you can configure that to attach to the other process too, or
instead, if that would help you.
>
>> What are you hoping to achieve here?
>
> Well, as I've said, I try to understand how a gui library handles system call
> so in order to clarify the matter I used this simple sys call as an example.
Ah, no. fork() is about as far from a "simple" call to cope with as it is
possible to imagine. They way it interacts with processes and stuff is very
tricky, and means that you need to deal with IPC to get it to work here.
All good stuff to learn, but not the best place to start...
>
>> ...so you would need to use some form of IPC to allow
>> the child to write back to the GUI that = exists in
>> the parent process. ---(i)
>
>> ...so you can use that to set up a pipe between the
>> two processes to > send = messages back and forth.--(ii)
>
> Do I have to use the *nix native IPC call or does fltk has its
> own IPC function which I can use as a substitute if I want to
> achieve what you suggested, the two instances(i) and (ii).
fltk does not provide wrappers for IPC ("fast" and "light" is not compatible
with providing an abstraction of every possible OS function... If you need that
then QT may be a better bet.)
I usually just use BSD sockets to a local port (this will work on all platforms
we care about) or with named pipes. (The WinXX implementation of named pipes is
"odd" but with a few #ifdef's you can make it work like the *nix pipes do, so
again that is fairly portable...)
All the host OS's also provide some form of message queue mechanism for IPC
too, which may suit your needs...
> I've heard that QT has its own signal, slot etc to handle this
> kind of job.
I'm no expert, but I had the impression they used that for inter-thread comms
rather than inter-process. I may well be wrong.
> QT also has DBus module by which it interacts with
> OS but I have no such knowledge to comprehend this, only getting
> abstruct concept while going the documents available in the web.
Yup, DBus could do it, though it is not portable (since it really only exists
in linux.) Pipes or sockets are simpler and more portable.
> 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.
If you have a working CLI tool, and you have control over its inputs and
outputs, it is often quite easy to write a GUI wrapper that runs the existing
CLI tool, rewriting the base tool may not be necessary.
> Rewrite it with C++ and fltk or
Probably not - and note that C++ can use C code "as is". Getting C to call C++
is trickier... If you have working C code, then invoking that from a C++ code
is straightforward.
> develop a gui (with
> buttons, labels, text boxes etc) and attach the native c program to
> it.
Yes, that'd work.
>
> Bottom Line? :))
> Do I need to know C programming in order to learn unix system programming
> using fltk and C++?
Doing anything low-level in a unix system without a working knowledge of C is
tricky. If you know C++, you mostly know C anyway.
What are your language skills etc.?
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
