From: Maurice L. <mj...@ga...> - 2002-03-04 21:25:41
|
Alan W. Irwin writes: > Maurice, you are more expert than me on these kind of questions so I am > tempted to just go along with your vision of supporting 3 separate locate > modes at the device level. But my gut instinct tells me that the device > level should be making minimum decisions. Instead, my view is it should pass > back data to the PLplot library level in sufficiently general form so that > the decisions (possibly including the 3 options above) could be done in that > more centralized place. I believe we should discuss simplifying the device > level handling of locate mode because it makes it much easier to have the > same minimum locate mode behaviour for all interactive drivers that support > it. Moving all of the locate control logic up to the core is not realistic in my opinion, not while preserving existing functionality. OTOH there are some sections of code that could be hoisted up to core functions that could be shared among multiple driver locate implementations. If I find myself doing any signficant changes to that section of code I'll look into it. > Furthermore, once we decide on what parts can be done at the PLplot > library level versus what must be done at the device level (even if that > turns out to be the status quo for what goes on with the xwin device driver > now), then we should document the device driver requirements, and review > each interactive driver to make sure it provides what is required. > ... > In your opinion, is such a common API (with variables and arrays in argument > lists as opposed to structs) straightforward to write based on our current > public (as opposed to common) API for locate mode? If so, I am willing to > write such a common API, but of course I would probably need a lot of help > from you. Sure, just (a) see that the struct contains everything you will ever want to return to the user (we talked about adding a window index parameter), and then just (b) flatten it out into an argument list of pointers. -- Maurice LeBrun mj...@ga... |