From: Daniel J S. <dan...@ie...> - 2007-06-11 00:56:01
|
I'm trying to debug the "set term x11 <windowID>" feature and have a question. What should be the sequence of initialization for terminals? If one looks at xlib/x11 terminals, CVS is coded like this: X11_options() { [snip] X11_init(); [snip--code using X11_ipc] } TERM_PUBLIC void Xlib_init() { /* x11.trm thinks it is writing to a private pipe, but here we */ /* set it to use the channel opened by 'set output <file>' */ X11_ipc = gpoutfile; fprintf(stderr,"xlib_init\n"); #ifdef PIPE_IPC /* There is, of course, no mouse feedback */ ipc_back_fd = IPC_BACK_UNUSABLE; #endif } Also, the xlib term has X11_options in its table. Now when the code is run, the sequence appears to be: gnuplot> set term xlib 5 1) Terminal type set to 'xlib' 2) X11_options() ... 3) ... which in turn calls X11_init(), given the code we see above. gnuplot> plot x 4) Xlib_init(), which sets X11_ipc. The consequence of this, if you haven't been following the flow is that "set term xlib" first has a series of commands in the X11_options code that actually goes out to gnuplot_x11 rather than being recorded to gpoutfile. (I'd like to see what those are... that's why I'm asking.) So, the questions are: Why doesn't the init function come before the options function in the sequence? Why is X11_init() in the middle of the X11_options function? Something seems contradictory there. If the X11_init() needs to come before writing anything to X11_ipc, it comes back to the first question of why the core code doesn't do a term->init before the term->options. Dan |