Re: Run in an X window - Feature request.

[Dave D. <dde...@es...>]

Daniel J Sebald <dan...@ie...> writes:

> Dave Denholm wrote:
>
>>There's a tool you can use to watch X packets. xmon I think. This
>>would let you see raw X error packets being sent - you can never
>>entirely trust programs to show you the actual errors.
>>
>>
>>Did you go with making a new window parented by the supplied window,
>>or drawing directly to the given window ?
>>
>
> I used the given window.  (Furthermore, it has to be on the display
> that gnuplot is on... would have to add some code to handle different
> displays.)  I guess it boils down to how the application plans to use
> this.  If gnuplot_x11 builds its own window derived from the one
> given, then the application loses track of the window gnuplot_x11 is
> using.  In some cases that is no big deal, say gnuplot_x11 is used as
> a "plug-in" for a browser and you simple want the plots to appear as
> usual but in a browser window.  However, if one wants to put
> additional stuff on the window along with the plot, for whatever
> reason, then what?
>
> The pr_window() routine in gplt_x11.c is the one that handles the X
> window stuff.  The code I added boils down to the following when the
> plot->window variable is non-zero:
>
>         XWindowAttributes gattr;
>         XGetWindowAttributes(dpy, plot->window, &gattr);
>         plot->x = gattr.x;
>         plot->y = gattr.y;
>         plot->width = gattr.width;
>         plot->height = gattr.height;
>         /* Not exactly sure how to call some routine to compute ->gheight.
>          * I tried calling XResizeWindow like is done elsewhere.  But that
>          * didn't seem to help.  It would be nice if this were called after
>          * the mouse stuff were set up, but it is called by prepare_plot()
>          * before the mouse variables are initialized.  Ethan, any ideas?
>          */
>         /* Make sure that unsigned number doesn't underflow. */
>         if (plot->str[0] || 1) /* FORCE TRUE AS A HACK */
>         plot->gheight = (vchar > plot->height) ? 0 : plot->height - vchar;
>         else
>         plot->gheight = plot->height;
>
>>  Do you use the existing
>>colormap or try to impose one.
>>
>
> I didn't investigate that far.  But I believe it is set up to impose
> one.  (Whatever appears after the above code.)  I know there is a bit
> of a conflict there, i.e., accepting the given window then trying to
> impose a colormap.  But, if gnuplot doesn't provide the color map,
> what good is it?  The plots will make no sense.


But if you are reusing the window in order to allow the owning app to
add it's own stuff, then that will make no sense..

It definitely gets complicated if you try to use the existing
colormap. You have to mess around based on visual type :

 if it's static (staticGray, staticColor, TrueColor) you can just ask
 it to give you appropriate pixels given RGB. The server does the
 lookup.

 But if it's dynamic (pseudoColor or DirectColor) then you can't ask
 the X server to choose the nearest existing colour, which is a
 pain. You can usually treat DirectColor as TrueColor. pseudocolor is
 then the problem. When I was working on it, pseudocolor was pretty
 common, but I suspect everyone uses truecolor these days.


I can't rememver if you can retrieve all the assigned pixels. But of
course, since another app owns the colormap, it may reassign them
randomly.

dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com