On 2009-09-25 14:36+0200 Mark de Wever wrote: > From Alan's mail in that thread I understood that not using offset in > the other drivers was seen as a minor omission. I see some use for the > offset parameter for the extcairo driver; eg you could add a border to > the widget and by setting a proper clip rectangle you can avoid plpot to > draw over that part of the widget. But at the moment I've no use for the > offset value.
Hi Mark: The first part of this is addressed to you, but the latter part makes general remarks about -geometry which should be of interest to all those who are writing interactive devices that ultimately (perhaps many levels deep) depend on X. The x,y offsets have nothing to do with the internals of plotting anything (such as clipping) or with the plotting widget itself (such as widget borders). Instead, those offsets are reserved exclusively (I agree with Werner about that) for specifying the position of the widget relative to the overall screen. In this way, the PLplot -geometry option (for those drivers who have implemented window offsets) should be interpreted exactly like the X -geometry option. See "man X" for details about -geometry. To see how this works in action, try a variety of negative and positive offset values as in -dev tk -geometry 100x100-100+100 You can do similar experiments for any X widget (such as xclock or xeyes). Note that -dev tk is a special case that interprets the -geometry option directly. In contrast, for -dev xwin, this is all handled via USPosition hints about what position the window should occupy. I discovered that -dev xwin does not respond properly to negative X or Y offsets (they are interpreted as 0). I have completed the first step in dealing with this (as of revision 10478 to plargs) to insure negative offset values are parsed correctly, and pls->xoffset and pls->yoffset properly updated to negative values. A side benefit of this update, is the new -geometry parsing logic using sscanf is much simpler than the old logic based on strtok. I have thrown every combination of bad geometry at that new logic that I can think of, and it seems to be well guarded against those type of issues. I have used gdb to show that, e.g., negative pls->xoffset now propagates to InitMain in drivers/xwin.c, but for some reason the XCreateWindow call still incorrectly interprets that negative USPosition hint as if the user asked for a 0 position. So some X expert here needs to figure that out if we ever want -dev xwin to respond properly to negative offsets. However, negative offsets are now parsed properly so that they should work (as in xeyes, xclock, and -dev tk) for other interactive devices such as xcairo and qtwidget _if_ those devices are updated to use the pls->[xy]offset values in a correct manner with regard to the underlying libraries (respectively from pango/cairo and Qt4) which ultimately depend on X. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
