plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Other problems with -locate option on x01c

[Alan W. I. <ir...@be...>]

On Sun, 3 Mar 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > Thanks for answering my questions/comments.
>  >
>  > I suggest you could improve the design by printing a warning message when
>  > outside a viewport but continue to stay in locate mode for that situation so
>  > that subsequent clicks inside viewports still work (without having to
>  > reinvoke L).  Otherwise, for an example like x01c with lots of area outside
>  > viewports, the first impression is that locate mode is severely broken.
>  > (At least that was my impression....;-)) Of course to finish locate mode you
>  > don't have to click on an area with no viewport.  Instead, simply type <ESC>
>  > as now.
>
> I only just now got around to looking into this.  As it stands, "it's a
> feature, not a bug".
>
> When I was putting this in, Geoff and I discussed the issue and decided the
> best course on invalid input -- i.e. clicking outside a viewport/window -- was
> to simply turn off locate mode.  The program's stdout (or stderr) isn't always
> handy so it's handy to have a graphical cue that you're giving bogus input,
> and aborting locate mode at that point seems reasonable.  I'm still happy with
> this decision, but I'll admit documentation is a problem (has been, for a
> while, but better recently :).

I am now only mildly unhappy with this since I can always use L to get into
locate mode again.  However, it might be worth changing it to put in some
warning message (e.g., "Locate mode is terminated because you are outside a
viewport.  To restart use L") so that if, e.g., plwarn works, then the user
will get this message.

>
>  > By the way, before you (and recently somebody else also) mentioned the L
>  > command and now <ESC> I had never heard of them and had no idea you could
>  > use locate mode for any of the examples other than x01c.
>  >
>  > Part of the reason it is taking me so long to get up to speed on this
>  > interactive stuff is I cannot find any documentation.  Are there any other
>  > "locate" commands besides L and <ESC>?  Do all interactive drivers have this
>  > capability? Is there some documentation that I have missed?  If you point me
>  > to some documentation or provide me with some, I will put it in the docbook
>  > documentation form so everybody can easily find it.  Probably the best place
>  > would be
>  > http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0.4.3/interactive-devices.html.
>
> The internally recognized keys in normal (plotting) mode in the xwin driver
> are featured in xwin.c:ProcessKey().  These are:
>
> /* Handle internal events */
>
>     switch (gin->keysym) {
>
>     case PLK_Return:
>     case PLK_Linefeed:
>     case PLK_Next:
>     /* Advance to next page (i.e. terminate event loop) on a <eol> */
>     /* Check for both <CR> and <LF> for portability, also a <Page Down> */
>         dev->exit_eventloop = TRUE;
>         break;
>
>     case 'Q':
>     /* Terminate on a 'Q' (not 'q', since it's too easy to hit by mistake) */
>         pls->nopause = TRUE;
>         plexit("");
>         break;
>
>     case 'L':
>     /* Begin locate mode */
>         dev->locate_mode = LOCATE_INVOKED_VIA_DRIVER;
>         CreateXhairs(pls);
>         break;
>     }

Thanks for this.  I have noticed experimentally, that right-clicking the
mouse when outside locate mode advances to the next page like CR, but I
don't see that right-click implemented above.  Also, from the above I don't
see how <ESC> is used to leave locate mode.  So the above code must only be
part of the interactive story.

Alan

Re: [Plplot-devel] Other problems with -locate option on x01c

[Maurice L. <mj...@ga...>]

Joao Cardoso writes:
 > On Friday 01 March 2002 9:52 pm, Alan W. Irwin wrote:
 > > With -dev tk you get identical bad results when clicking outside a
 > > viewport. However, if you stick inside viewports there is an extra twist;
 > > you get two (!) sets of coordinates for every mouse click.
 > 
 > I can't reproduce this one.

Nor I.

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] Other problems with -locate option on x01c

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > Thanks for answering my questions/comments.
 > 
 > I suggest you could improve the design by printing a warning message when
 > outside a viewport but continue to stay in locate mode for that situation so
 > that subsequent clicks inside viewports still work (without having to
 > reinvoke L).  Otherwise, for an example like x01c with lots of area outside
 > viewports, the first impression is that locate mode is severely broken.
 > (At least that was my impression....;-)) Of course to finish locate mode you
 > don't have to click on an area with no viewport.  Instead, simply type <ESC>
 > as now.

I only just now got around to looking into this.  As it stands, "it's a
feature, not a bug".

When I was putting this in, Geoff and I discussed the issue and decided the
best course on invalid input -- i.e. clicking outside a viewport/window -- was
to simply turn off locate mode.  The program's stdout (or stderr) isn't always
handy so it's handy to have a graphical cue that you're giving bogus input,
and aborting locate mode at that point seems reasonable.  I'm still happy with
this decision, but I'll admit documentation is a problem (has been, for a
while, but better recently :).

 > By the way, before you (and recently somebody else also) mentioned the L
 > command and now <ESC> I had never heard of them and had no idea you could
 > use locate mode for any of the examples other than x01c.
 > 
 > Part of the reason it is taking me so long to get up to speed on this
 > interactive stuff is I cannot find any documentation.  Are there any other
 > "locate" commands besides L and <ESC>?  Do all interactive drivers have this
 > capability? Is there some documentation that I have missed?  If you point me
 > to some documentation or provide me with some, I will put it in the docbook
 > documentation form so everybody can easily find it.  Probably the best place
 > would be
 > http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0.4.3/interactive-devices.html.

The internally recognized keys in normal (plotting) mode in the xwin driver
are featured in xwin.c:ProcessKey().  These are:

/* Handle internal events */ 
 
    switch (gin->keysym) { 
 
    case PLK_Return: 
    case PLK_Linefeed: 
    case PLK_Next: 
    /* Advance to next page (i.e. terminate event loop) on a <eol> */ 
    /* Check for both <CR> and <LF> for portability, also a <Page Down> */ 
        dev->exit_eventloop = TRUE; 
        break; 
 
    case 'Q': 
    /* Terminate on a 'Q' (not 'q', since it's too easy to hit by mistake) */ 
        pls->nopause = TRUE; 
        plexit(""); 
        break; 
 
    case 'L': 
    /* Begin locate mode */ 
        dev->locate_mode = LOCATE_INVOKED_VIA_DRIVER; 
        CreateXhairs(pls); 
        break; 
    } 

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] Other problems with -locate option on x01c

[Alan W. I. <ir...@be...>]

Thanks for answering my questions/comments.

I suggest you could improve the design by printing a warning message when
outside a viewport but continue to stay in locate mode for that situation so
that subsequent clicks inside viewports still work (without having to
reinvoke L).  Otherwise, for an example like x01c with lots of area outside
viewports, the first impression is that locate mode is severely broken.
(At least that was my impression....;-)) Of course to finish locate mode you
don't have to click on an area with no viewport.  Instead, simply type <ESC>
as now.

By the way, before you (and recently somebody else also) mentioned the L
command and now <ESC> I had never heard of them and had no idea you could
use locate mode for any of the examples other than x01c.

Part of the reason it is taking me so long to get up to speed on this
interactive stuff is I cannot find any documentation.  Are there any other
"locate" commands besides L and <ESC>?  Do all interactive drivers have this
capability? Is there some documentation that I have missed?  If you point me
to some documentation or provide me with some, I will put it in the docbook
documentation form so everybody can easily find it.  Probably the best place
would be
http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0.4.3/interactive-devices.html.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Sat, 2 Mar 2002, Joao Cardoso wrote:

> On Friday 01 March 2002 9:52 pm, Alan W. Irwin wrote:
> > Joao's recent xwin fix only solved a tiny part of the problem.
> >
> > Using
> >
> > ./x01c -locate -dev xwin
> >
> > you can click on any viewport and get back world coordinates and relative
> > device coordinates, but as soon as you make the mistake of clicking outside
> > a viewport, the mouse is hosed, i.e. mouseclicks are ignored from then on.
>
> This is the intended behavior. Also, if you invoke the cursor via the
> driver, typing 'L' (no need for -locate in the cmdline), you finish it either
> typing <ESC> or clicking out a vieport.
>
> > Since the xwin fix, the cross-hairs turn off when the mouse is hosed, but
> > that is the only change in the bad behavior.
> >
> > With -dev tk you get identical bad results when clicking outside a
> > viewport. However, if you stick inside viewports there is an extra twist;
> > you get two (!) sets of coordinates for every mouse click.
>
> I can't reproduce this one.
>
> >
> > With -dev ntk you get identical bad results when clicking outside a
> > viewport. However, if you stick inside viewports, you get the normal one
> > line of results per click, but no cross-hairs are displayed at all!
>
> ntk does not yet uses crosshairs; instead it uses a cross cursor. It does not
> also implement the driver locate mode vie key 'L', nor resizes, nor...
>
> >
> > So there is a whole lot of little things which are not right as well as the
> > bigger problem of the mouse stopping working entirely if you ever click
> > outside a viewport by mistake.
>
> We can change this, but it works as designed. I agree that at first it seems
> strange, or even bad design, as one can leave locate mode inadvertly, but
> there must exist a way to finish locate mode. Suggestions?
>
> Joao
>
> >
> > Once the interactive drivers, the C library and C front-end start dealing
> > with interactive mouse clicks properly, I will want to get this working for
> > the python (or pyqt) front end as well. I have a research project on the
> > horizon involving the analysis of many spectra that requires good
> > fundamental mouse interactivity for PLplot.
> >
> > Alan
> >
> > email: ir...@be...
> > phone: 250-727-2902	FAX: 250-721-7715
> > snail-mail:
> > Dr. Alan W. Irwin
> > Department of Physics and Astronomy,
> > University of Victoria, P.O. Box 3055,
> > Victoria, British Columbia, Canada, V8W 3P6
> > __________________________
> >
> > Linux-powered astrophysics
> > __________________________
> >
> >
> > _______________________________________________
> > Plplot-devel mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] Other problems with -locate option on x01c

[Joao C. <jc...@fe...>]

On Friday 01 March 2002 9:52 pm, Alan W. Irwin wrote:
> Joao's recent xwin fix only solved a tiny part of the problem.
>
> Using
>
> ./x01c -locate -dev xwin
>
> you can click on any viewport and get back world coordinates and relati=
ve
> device coordinates, but as soon as you make the mistake of clicking out=
side
> a viewport, the mouse is hosed, i.e. mouseclicks are ignored from then =
on.

This is the intended behavior. Also, if you invoke the cursor via the=20
driver, typing 'L' (no need for -locate in the cmdline), you finish it ei=
ther=20
typing <ESC> or clicking out a vieport.

> Since the xwin fix, the cross-hairs turn off when the mouse is hosed, b=
ut
> that is the only change in the bad behavior.
>
> With -dev tk you get identical bad results when clicking outside a
> viewport. However, if you stick inside viewports there is an extra twis=
t;
> you get two (!) sets of coordinates for every mouse click.

I can't reproduce this one.

>
> With -dev ntk you get identical bad results when clicking outside a
> viewport. However, if you stick inside viewports, you get the normal on=
e
> line of results per click, but no cross-hairs are displayed at all!

ntk does not yet uses crosshairs; instead it uses a cross cursor. It does=
 not=20
also implement the driver locate mode vie key 'L', nor resizes, nor...

>
> So there is a whole lot of little things which are not right as well as=
 the
> bigger problem of the mouse stopping working entirely if you ever click
> outside a viewport by mistake.

We can change this, but it works as designed. I agree that at first it se=
ems=20
strange, or even bad design, as one can leave locate mode inadvertly, but=
=20
there must exist a way to finish locate mode. Suggestions?

Joao

>
> Once the interactive drivers, the C library and C front-end start deali=
ng
> with interactive mouse clicks properly, I will want to get this working=
 for
> the python (or pyqt) front end as well. I have a research project on th=
e
> horizon involving the analysis of many spectra that requires good
> fundamental mouse interactivity for PLplot.
>
> Alan
>
> email: ir...@be...
> phone: 250-727-2902=09FAX: 250-721-7715
> snail-mail:
> Dr. Alan W. Irwin
> Department of Physics and Astronomy,
> University of Victoria, P.O. Box 3055,
> Victoria, British Columbia, Canada, V8W 3P6
> __________________________
>
> Linux-powered astrophysics
> __________________________
>
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Other problems with -locate option on x01c

[Alan W. I. <ir...@be...>]

Joao's recent xwin fix only solved a tiny part of the problem.

Using

./x01c -locate -dev xwin

you can click on any viewport and get back world coordinates and relative
device coordinates, but as soon as you make the mistake of clicking outside
a viewport, the mouse is hosed, i.e. mouseclicks are ignored from then on.
Since the xwin fix, the cross-hairs turn off when the mouse is hosed, but
that is the only change in the bad behaviour.

With -dev tk you get identical bad results when clicking outside a viewport.
However, if you stick inside viewports there is an extra twist; you get two
(!) sets of coordinates for every mouse click.

With -dev ntk you get identical bad results when clicking outside a
viewport. However, if you stick inside viewports, you get the normal one
line of results per click, but no cross-hairs are displayed at all!

So there is a whole lot of little things which are not right as well as the
bigger problem of the mouse stopping working entirely if you ever click
outside a viewport by mistake.

Once the interactive drivers, the C library and C front-end start dealing
with interactive mouse clicks properly, I will want to get this working for
the python (or pyqt) front end as well. I have a research project on the
horizon involving the analysis of many spectra that requires good
fundamental mouse interactivity for PLplot.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)

[Alan W. I. <ir...@be...>]

On Thu, 28 Feb 2002, Joao Cardoso wrote:

> PS-subpages, viewports, and windows, and now subplots!

My paranoid view is all these hierarchies are a plot (heh) against the poor
documenter....;-)

To be serious, taking consideration of the further input from you and
Maurice, I will leave c_plcalc_world as is except for a change of the index
name from subpage to window and with some additional documentation of what
exactly that index is.

Thanks very much to all of you for your most helpful input.

I will leave it to somebody else to include a place for this index in the
PLGraphicsIn struct, and modify plTranslateCursor to load the index into
the revised PLGraphicsIn *plg.

Also, I will leave it to somebody else (smile) to fix the cursor freeze bug
I found.

Alan

Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)

[Joao C. <jc...@fe...>]

On Thursday 28 February 2002 7:31 pm, Alan W. Irwin wrote:

=2E..
> I am now leaning toward changing c_plcalc_world to just return a status=
 in
> the argument list and drop the idea of returning the windows index
> altogether. That's what I will probably do unless I hear some good
> arguments to keep it (especially from Joao since he probably had some
> specific use in mind when he originally brought up the possibility of
> returning this index).

Good arguments? No. Only that most of my plots and most published plot ha=
ve a=20
simple "layout", and given that simplicity returning the subplot number c=
an=20
be helpfull to identify the plot that the user is interested in.

Suppose that in x01c you want to give the user the choice of selecting on=
e of=20
the subplots, clicking on it, and then plotting only it. I can think in l=
ots=20
of other applications where it is desirable to identify a subplot by clic=
king=20
on it (printing or saving only one subplot, have a plot browser that plot=
s=20
tiny plots of your plmeta-saved plot, ...).

Joao

PS-subpages, viewports, and windows, and now subplots!

>
> Alan
>
> email: ir...@be...
> phone: 250-727-2902=09FAX: 250-721-7715
> snail-mail:
> Dr. Alan W. Irwin
> Department of Physics and Astronomy,
> University of Victoria, P.O. Box 3055,
> Victoria, British Columbia, Canada, V8W 3P6
> __________________________
>
> Linux-powered astrophysics
> __________________________
>
> On Thu, 28 Feb 2002, Maurice LeBrun wrote:
> > I looked at the dox & code, and all looks cool.
> >
> > My only nit is that the references to "subpage" should be replaced by
> > "window".  I like the more general term better since the code should =
work
> > fine even if not using the usual PLplot subpage model.  In fact I
> > originally wrote the window registration code with a completely diffe=
rent
> > windowing front-end in mind.
> >
> > --
> > Maurice LeBrun    mj...@ga...
> >
> > _______________________________________________
> > Plplot-devel mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > I am now leaning toward changing c_plcalc_world to just return a status in
 > the argument list and drop the idea of returning the windows index
 > altogether. That's what I will probably do unless I hear some good arguments
 > to keep it (especially from Joao since he probably had some specific use in
 > mind when he originally brought up the possibility of returning this index).

Even with all the caveats, I think the window index can still be useful.  The
simplest case being that the user keeps track of the window number / page and
already knows what to do with it.  In a general implementation you could keep
a window counter that gets reset every new-page, perhaps with a function
pointer for each value of the window counter to go do stuff upon an event in
that window.  At its simplest, a fixed association could be used, e.g. each
page represents a point in time with multiple plots/page of various physical
quantities, always in a fixed location.  So then an event in window #2 means
the user is messing with the temperature plot, in window #3 the electric field
intensity, and so on.

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)

[Alan W. I. <ir...@be...>]

Thanks, Maurice, for your comment below which inspired me to look further at
the code and documentation.  As my previous posts have shown, I was confused
about the differences between (sub-)pages, viewports, and windows.  But now
I have looked again at the advanced section of the documentation, and it is
all clearly layed out there.

Each (sub-)page can have more than one (possibly overlapping) viewport, and
each viewport can have various windows superimposed by repeated calls to
plwind (with data registered for each plwind call with plP_swin).  The
windows for a given viewport only differ in the world coordinates of their
minimum and maximum x and y values so multiple windows allow you the option
of making single viewport plots with multiple sets of world coordinates. If
you do have multiple sets of world coordinates for a single viewport, the
data for each plwind call are registered with plP_swin with an ascending
windows index.

Note that in normal use there is only one window per viewport and the
viewports don't physically overlap.  But in the most general case we have
overlapping viewports with multiple windows each. Note in c_plcalc_world I
continue to use Paul Casteel's trick of searching backwards through the
windows indices.  Thus, the code finds the last possibly overlapping defined
viewport and last window defined for that viewport that contains the
relative device coordinates.  This completely answers my concern (Maurice
answered it as well) over what happens with multiple viewports per sub-page.
However, the windows (incorrectly named subpage) index currently returned is
something with a very special internal meaning.

Now that I understand this index, I don't see much public use for it. Does
Joao need this index just for extra information for human consumption?  It
won't make much sense unless you repeat all the ifs, ands, and buts from
above in the documentation. Alternatively, if it is meant to be used to
index some information from plplot, I am not aware of any public (much less
common) API that uses this index.

I am now leaning toward changing c_plcalc_world to just return a status in
the argument list and drop the idea of returning the windows index
altogether. That's what I will probably do unless I hear some good arguments
to keep it (especially from Joao since he probably had some specific use in
mind when he originally brought up the possibility of returning this index).

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Thu, 28 Feb 2002, Maurice LeBrun wrote:

> I looked at the dox & code, and all looks cool.
>
> My only nit is that the references to "subpage" should be replaced by
> "window".  I like the more general term better since the code should work fine
> even if not using the usual PLplot subpage model.  In fact I originally wrote
> the window registration code with a completely different windowing front-end
> in mind.
>
> --
> Maurice LeBrun    mj...@ga...
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)

[Joao C. <jc...@fe...>]

On Thursday 28 February 2002 5:39 am, Maurice LeBrun wrote:
> Alan W. Irwin writes:
>  > On Wed, 27 Feb 2002, Maurice LeBrun wrote:
=2E..
>  > Also, to move to a related topic, can anybody explain the cursor fre=
eze
>  > I encountered when outside a viewport?  I assume it is an x01c.c pro=
blem
>  > or else a problem in the xwin, tk, and ntk drivers.
>
> Hmm.. never noticed it before.  Crappy error handling probably. :)
> If you invoke locate with the "L" key binding there's no problem.
> I'll look into it when I get a chance.

In xwin.c:GetCursorCmd() I added DestroyXhairs() at the function end,=20
otherwise the xhairs would stay "alive" to the next plot. This can't be s=
ee=20
in x01c, as it only has one plot, but is obvious in x20c. It looks like i=
t=20
has negative side effects... any clue?

Joao

Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)

[Maurice L. <mj...@ga...>]

I looked at the dox & code, and all looks cool.

My only nit is that the references to "subpage" should be replaced by
"window".  I like the more general term better since the code should work fine
even if not using the usual PLplot subpage model.  In fact I originally wrote
the window registration code with a completely different windowing front-end
in mind.

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > On Wed, 27 Feb 2002, Maurice LeBrun wrote:
 > 
 > > I don't really think the return code should be overloaded with window number.
 > > To me it's better/clearer to put it in a separate PLGraphicsIn struct entry.
 > 
 > That's okay if you are talking about plTranslateCursor, but I hope you
 > ignore that completely for now since it is a separate issue.  c_plcalc_world

Right, I was talking about plTranslateCursor.  My message was more relevant
when I wrote it, quite a few hours before it actually appeared.

 > does not use PLGraphicsIn data since it is common API where the various
 > front ends typically demand simple variable or array argument lists.  Its
 > purpose is to convert relative device coordinates to world coordinates with
 > no assumptions about what the front ends will use that data for.  Is there
 > any reason in the c_plcalc_world case not to return -1 for the subpage
 > number when there is no valid subpage?

Sounds fine.
 > I understand the first part, but I don't see the problem since each subpage
 > (or window or subwindow, grrr) is registered as you say.  But I am not sure
 > what you mean by "per-page list of windows".  Is that a list of sub-pages
 > for the current page?  If so, isn't that exactly what your registering
 > already does so that to get data for each subpage you simply walk through
 > the list?  For example, c_plcalc_windows does this by the following
 > fragment of code:
 > 
 > for (i = lastwin; i >= firstwin; i--) {
 >       w = &plsc->plwin[i % PL_MAXWINDOWS];

Whoops, I forgot that was in there.. cool.  OK, so forget about that
part of my message as it's already done.  Then if you are returning the
window number as found above, I'm happy.

 > One concern I still have with c_plcalc_world is whether it gives good
 > results for multiple viewports per (sub-)page.  Geoffrey, I hope you will
 > test that directly since you brought up this case originally (;-)) and you
 > apparently had several examples of this you were concerned about.

It should.  The plsc->plwin struct only cares about windows "registered"
through the plwind call, so it's nicely general.  Doesn't care if it's
in a subwindow or not.

 > Also, to move to a related topic, can anybody explain the cursor freeze
 > I encountered when outside a viewport?  I assume it is an x01c.c problem or
 > else a problem in the xwin, tk, and ntk drivers.

Hmm.. never noticed it before.  Crappy error handling probably. :)
If you invoke locate with the "L" key binding there's no problem.
I'll look into it when I get a chance.

 > This thread has been confused today because the e-mail delivery for
 > plplot_devel has been extraordinarily erratic (one of my key messages about
 > the cursor freeze, etc. got held up for many hours while later messages
 > sailed through). Thus, I am going to send extra copies of this directly to
 > the principal contributors (Maurice, Geoffrey, and Joao) to make sure
 > they get it in a timely manner.
 > 
 > Alan

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)

[Alan W. I. <ir...@be...>]

On Wed, 27 Feb 2002, Maurice LeBrun wrote:

> I don't really think the return code should be overloaded with window number.
> To me it's better/clearer to put it in a separate PLGraphicsIn struct entry.

That's okay if you are talking about plTranslateCursor, but I hope you
ignore that completely for now since it is a separate issue.  c_plcalc_world
does not use PLGraphicsIn data since it is common API where the various
front ends typically demand simple variable or array argument lists.  Its
purpose is to convert relative device coordinates to world coordinates with
no assumptions about what the front ends will use that data for.  Is there
any reason in the c_plcalc_world case not to return -1 for the subpage
number when there is no valid subpage?

BTW, I have just rebuilt the documentation so you can see the description of
the c_plcalc_world API at
http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0.4.3/plcalc_world.html.

>
> As for Geoff's comment, plots that go beyond the simple single-plot /
> subwindow model are indeed a problem.  Although right now we do not number the
> windows created, we do "register" them with the plP_swin call at the end of
> plwind().  I added this ages ago with the hopes of supporting per-window
> operations from plrender for apps that handle their own windowing.  Anyway,
> we could add the window defn at that point to a per-page list of windows,
> which is searched through for input events.  Then return a window index in the
> PLGraphicsIn struct.  Would need an API call to return the current window
> list too.

I understand the first part, but I don't see the problem since each subpage
(or window or subwindow, grrr) is registered as you say.  But I am not sure
what you mean by "per-page list of windows".  Is that a list of sub-pages
for the current page?  If so, isn't that exactly what your registering
already does so that to get data for each subpage you simply walk through
the list?  For example, c_plcalc_windows does this by the following
fragment of code:

for (i = lastwin; i >= firstwin; i--) {
      w = &plsc->plwin[i % PL_MAXWINDOWS];

One concern I still have with c_plcalc_world is whether it gives good
results for multiple viewports per (sub-)page.  Geoffrey, I hope you will
test that directly since you brought up this case originally (;-)) and you
apparently had several examples of this you were concerned about.

Also, to move to a related topic, can anybody explain the cursor freeze
I encountered when outside a viewport?  I assume it is an x01c.c problem or
else a problem in the xwin, tk, and ntk drivers.

This thread has been confused today because the e-mail delivery for
plplot_devel has been extraordinarily erratic (one of my key messages about
the cursor freeze, etc. got held up for many hours while later messages
sailed through). Thus, I am going to send extra copies of this directly to
the principal contributors (Maurice, Geoffrey, and Joao) to make sure
they get it in a timely manner.

Alan

Re: [Plplot-devel] valgrind [purify killer]

[Maurice L. <mj...@ga...>]

Geoffrey Furnish writes:
 > Maurice LeBrun writes:
 >  > Geoffrey Furnish writes:
 >  >  > For those whoe know Rational's purify product, this is the GPL app
 >  >  > that's gonna crush purify, at least on the Linux platform.  Rational
 >  > 
 >  > I'm glad to see it.  I left a message on Rational's web site about
 >  > Linux support, and although they did eventually get back to me, their
 >  > response was ludicrous -- yes they were going to support Linux but only
 >  > for IA-64. <snort>  Unbelievable.  Let's see, just how many installed
 >  > platforms IS that? :)
 > 
 > purify licenses are /really/ expensive.  When I talked to their
 > director of Unix tools some years ago while I was at LANL, he
 > basically said they didn't believe Linux users would be willing to pay
 > their Solaris/HPUX fees.  I had to agree.

Well no one says they have to maintain their extremely high margins for a
Linux offering either.  I have a hard time believing they couldn't make a
profit on a Linux support, considering how many scientific users (among other
potential buyers) have Linux boxes these days.  And to base their argument
on the availability of a hardware vapor product (IA-64) is just a cop out
to me -- it let them write down the magical phrase "Linux support" in order
to impress somebody (stockholder?) without actually doing anything about it.
But anyway, too late for any of this to matter, thankfully..

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)

[Maurice L. <mj...@ga...>]

I don't really think the return code should be overloaded with window number.
To me it's better/clearer to put it in a separate PLGraphicsIn struct entry.

As for Geoff's comment, plots that go beyond the simple single-plot /
subwindow model are indeed a problem.  Although right now we do not number the
windows created, we do "register" them with the plP_swin call at the end of
plwind().  I added this ages ago with the hopes of supporting per-window
operations from plrender for apps that handle their own windowing.  Anyway,
we could add the window defn at that point to a per-page list of windows,
which is searched through for input events.  Then return a window index in the
PLGraphicsIn struct.  Would need an API call to return the current window
list too.

Maybe best to just punt on it for now, but keep it in mind for a future
project.  Return a window number parameter in the PLGraphicsIn that for now is
just a subpage number, but in the future may be a more generalized window
number (making sure the two are compatible).

Geoffrey Furnish writes:
 > Alan W. Irwin writes:
 >  > Using the return value in two different ways is a little awkward because I
 >  > believe the first sub-page is numbered zero rather than one.  We could
 >  > return i+1 but that could lead to all sorts of misunderstandings.  So how
 >  > about just changing the API?  It is possible this might hurt some of our
 >  > users since it is public API, but I feel this is not too likely since it is
 >  > not part of the documented common API.
 >  > 
 >  > If we agree that it is okay to change the API, I am thinking of returning
 >  > the window number in the argument list and returning success or failure as
 >  > before.  But I am no API expert so any other suggestions are welcome
 >  > especially if there is some obvious data structure where the returned
 >  > window number could be stored.
 >  > 
 >  > As far as the common API version is concerned (let's call it c_plgwc where
 >  > "gwc" stands for get world coordinates), I also intend to have a return of 1
 >  > for success and 0 for failure. Essentially it will be identical to the
 >  > current plTranslateCursor except it will have x and y "absolute" coordinates
 >  > as input, and world coordinates and window number as output rather than
 >  > assuming those data are accessible to/from a PLGraphicsIn struct.  The new
 >  > plTranslateCursor would then consist essentially of a call to c_plgwc with
 >  > an argument transformation from a PLGraphicsIn struct to the simple input
 >  > variables of c_plgwc on input and the reverse on the returned variables.
 >  > 
 >  > I intend to implement these ideas right away, and after checking that it
 >  > works I will commit it subject to change if anybody has some API ideas
 >  > in the meanwhile.
 > 
 > wheeee!  Well, I love to see prompt action, but I do have one concern
 > about what is being discussed in this thread.
 > 
 > I remember when Maurice and I first talked about this thing, years
 > ago, but the language that is being used in this thread does not match
 > up with what I remember we had talked about.  So either my memory is
 > wrong, or maybe somehow we never implemented what I wanted, or
 > something.  I dunno, it's been too long.
 > 
 > Anyway, my concern is that the "window", as in the "sub page window",
 > may not be the right--or maybe just not sufficient--info to return.  I
 > think we also need to return something about the viewport definition.
 > Many "windows" have more than one active viewport.  I /often/ make my
 > plots have two viewports, the "main" one where the plot goes, and an
 > additional one where the legend goes.  For example, on shade plots, I
 > may draw one big squarish region with the shaded data, and then a
 > little thin/tall bar on the left which shows the color map used in the
 > shade, with the y axis on this color bar being the function value
 > range in the main plot.
 > 
 > Now, if the user uses the locator and selects a coordinate, they might
 > be asking the interactive tool to tell them the world coordinates at
 > some point in the main picture area, but they might also be trying to
 > determine the value of some particular part of the legend box.  So, it
 > seems to me that to really do this right, you need to convert the
 > screen (pixel) coords to world coordinates, and return both the window
 > (sub page) and the viewport for which the match was found.
 > 
 > I think, reaching way back into the cobwebs, that the fly in the
 > ointment here is that we don't number the viewports.
 > 
 > _______________________________________________
 > Plplot-devel mailing list
 > Plp...@li...
 > https://lists.sourceforge.net/lists/listinfo/plplot-devel

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)

[Joao C. <jc...@fe...>]

On Wednesday 27 February 2002 6:25 pm, Geoffrey Furnish wrote:
> Alan W. Irwin writes:
>  > Using the return value in two different ways is a little awkward bec=
ause
>  > I believe the first sub-page is numbered zero rather than one.  We c=
ould
>  > return i+1 but that could lead to all sorts of misunderstandings.  S=
o
>  > how about just changing the API?  It is possible this might hurt som=
e of
>  > our users since it is public API, but I feel this is not too likely
>  > since it is not part of the documented common API.
>  >
>  > If we agree that it is okay to change the API, I am thinking of
>  > returning the window number in the argument list and returning succe=
ss
>  > or failure as before.  But I am no API expert so any other suggestio=
ns
>  > are welcome especially if there is some obvious data structure where=
 the
>  > returned window number could be stored.
>  >
>  > As far as the common API version is concerned (let's call it c_plgwc
>  > where "gwc" stands for get world coordinates), I also intend to have=
 a
>  > return of 1 for success and 0 for failure. Essentially it will be
>  > identical to the current plTranslateCursor except it will have x and=
 y
>  > "absolute" coordinates as input, and world coordinates and window nu=
mber
>  > as output rather than assuming those data are accessible to/from a
>  > PLGraphicsIn struct.  The new plTranslateCursor would then consist
>  > essentially of a call to c_plgwc with an argument transformation fro=
m a
>  > PLGraphicsIn struct to the simple input variables of c_plgwc on inpu=
t
>  > and the reverse on the returned variables.
>  >
>  > I intend to implement these ideas right away, and after checking tha=
t it
>  > works I will commit it subject to change if anybody has some API ide=
as
>  > in the meanwhile.
>
> wheeee!  Well, I love to see prompt action, but I do have one concern
> about what is being discussed in this thread.
>
> I remember when Maurice and I first talked about this thing, years
> ago, but the language that is being used in this thread does not match
> up with what I remember we had talked about.  So either my memory is
> wrong, or maybe somehow we never implemented what I wanted, or
> something.  I dunno, it's been too long.
>
> Anyway, my concern is that the "window", as in the "sub page window",
> may not be the right--or maybe just not sufficient--info to return.  I
> think we also need to return something about the viewport definition.
> Many "windows" have more than one active viewport.  I /often/ make my
> plots have two viewports, the "main" one where the plot goes, and an
> additional one where the legend goes.  For example, on shade plots, I
> may draw one big squarish region with the shaded data, and then a
> little thin/tall bar on the left which shows the color map used in the
> shade, with the y axis on this color bar being the function value
> range in the main plot.
>
> Now, if the user uses the locator and selects a coordinate, they might
> be asking the interactive tool to tell them the world coordinates at
> some point in the main picture area, but they might also be trying to
> determine the value of some particular part of the legend box.

I don't think this to be very likely... but one can never guess what user=
s=20
will do (need). That's why I think that returning the subwindow will be=20
enough for most applications; users with special needs will learn that=20
clicking in the legend is a "feature" not yet supported, and will avoid u=
sing=20
it. This is perhaps too pragmatic, but as you say bellow, we don't store=20
viewport info.

In my personal case, I plot the legend bar for shade and contour plots in=
side=20
the main plot, which make things worse than for you (but I have an iterat=
ive=20
legend placement utility, to manually move the legend position away of=20
interesting regions).

But this issue raises some future (possible) development compatibility=20
problems, and as such I think that is better to just add a field to the=20
PLGraphicsIn structure to indicate the subwindow number (instead of using=
 the=20
function return value for this--see my other post); latter, another field=
=20
could be added to also indicate the viewport.

Joao

>  So, it
> seems to me that to really do this right, you need to convert the
> screen (pixel) coords to world coordinates, and return both the window
> (sub page) and the viewport for which the match was found.
>
> I think, reaching way back into the cobwebs, that the fly in the
> ointment here is that we don't number the viewports.
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] plgetpos transformation (was valgrind)

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > It would be a big help if one of you could give me a definition of absolute,
 > relative, and normalized coordinates.  Perhaps for completeness you should
 > also include world coordinates, but I think I understand what those are.

I could've sworn I went through and documented these some time ago in response
to a similar request.  Can't find any trace of it now though, sigh.  Since I
get confused too I had to go through the code to refresh my memory, and this
is what I came up with:

    physical coordinates and device coordinates

are the same thing.  The "pixel" addresses in device space, typically 0 up to
some large value in each coordinate.

    absolute coordinates

are page coordinates in mm.  Only strictly accurate for fixed-page-size output
devices.

    relative device coordinates and normalized device coordinates

are the same same thing -- position in a [0.,1.] by [0.,1.] representation of
the page.

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)

[Alan W. I. <ir...@be...>]

The new common API function c_plcalc_world (note the name change) can have
any API it likes since this is a new function.  So the goal there is to be
the best possible API.  Now my understanding is that common API functions
are all void, i.e., the only way they return status information is via the
argument list.  For now I am going to return (via the argument list) a
window value starting at zero with a window value of -1 indicating failure
to find a valid window.  I am no API expert so if that is the wrong way to
go from the best possible API point of view let me know, and I will change
it.  But the API for this function is a completely separate issue from
the plTranslateCursor API.

For now, I will leave the plTranslateCursor API strictly as is, but I
will change its internals to call c_plcalc_world.  Once consensus has
been reached on changing the plTranslateCursor API, then all data
returned from c_plcalc_world will be available to plTranslateCursor
to facilitate that changed API.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Wed, 27 Feb 2002, Joao Cardoso wrote:

> On Wednesday 27 February 2002 5:03 pm, Alan W. Irwin wrote:
> > Using the return value in two different ways is a little awkward because I
> > believe the first sub-page is numbered zero rather than one.  We could
> > return i+1 but that could lead to all sorts of misunderstandings.  So how
> > about just changing the API?
>
> My suggestion was intended to avoid this API break. However, I don't think
> that it would confuse users. Many standard C library functions are expected
> to return e.g. a pointer on sucess or NULL to indicate failure.
>
> Currently, plGetCursor() comments say:
>  Returns 0 if no translation to world coordinates is possible.
>
> I would propose that it says:
>  Returns the subwindow number, starting at 1, or 0 if no translation to world
> coordinates is possible.
>
> With this approach I thing that most code would still work without
> modifications; x01c will.
>
> If you think that this is not reasonable, them the PLGraphicsIn structure
> could contain one more field, the subwindow number; existing code will still
> work, but should be recompiled.
>
> >  It is possible this might hurt some of our
> > users since it is public API, but I feel this is not too likely since it is
> > not part of the documented common API.
> >
> > If we agree that it is okay to change the API, I am thinking of returning
> > the window number in the argument list and returning success or failure as
> > before.  But I am no API expert so any other suggestions are welcome
> > especially if there is some obvious data structure where the returned
> > window number could be stored.
> >
> > As far as the common API version is concerned (let's call it c_plgwc where
> > "gwc" stands for get world coordinates), I also intend to have a return of
> > 1 for success and 0 for failure. Essentially it will be identical to the
> > current plTranslateCursor except it will have x and y "absolute"
> > coordinates as input, and world coordinates and window number as output
> > rather than assuming those data are accessible to/from a PLGraphicsIn
> > struct.  The new plTranslateCursor would then consist essentially of a call
> > to c_plgwc with an argument transformation from a PLGraphicsIn struct to
> > the simple input variables of c_plgwc on input and the reverse on the
> > returned variables.
> >
> > I intend to implement these ideas right away, and after checking that it
> > works I will commit it subject to change if anybody has some API ideas
> > in the meanwhile.
> >
> > Alan
> >
> > email: ir...@be...
> > phone: 250-727-2902	FAX: 250-721-7715
> > snail-mail:
> > Dr. Alan W. Irwin
> > Department of Physics and Astronomy,
> > University of Victoria, P.O. Box 3055,
> > Victoria, British Columbia, Canada, V8W 3P6
> > __________________________
> >
> > Linux-powered astrophysics
> > __________________________
> >
> > On Wed, 27 Feb 2002, Joao Cardoso wrote:
> > > On Wednesday 27 February 2002 04:07, Alan W. Irwin wrote:
> > > | I would appreciate further discussion of one aspect of the
> > > | plTranslateCursor code.
> > > |
> > > | It goes through a reversed list of windows (I assume these are
> > > | sub-windows?) and for the first one where the cursor is inside the
> > > | sub-window it does the transformation and returns.
> > > |
> > > | If I have this interpretation right, then it looks like the pyqt
> > > | group's plgetpos using data in the PLStream struct won't really
> > > | work since on a page with subwindowing, the world coordinates can
> > > | vary wildly form sub-window to sub-window (e.g., example 1), and
> > > | their code doesn't take account of this.  So my guess is they are
> > > | going to be forced (by example 1) to go to the plTranslateCursor
> > > | type of transformation.
> > >
> > > One problem with plGetCursor() is that it doesn't give information on
> > > which sub-page the mouse event occurred. I always found this a
> > > serious limitation.
> > >
> > > Perhaps using the "i" variable as the return value from
> > > plGetCursor()? of course existing code that relies on a "1" to be
> > > returned would fail, but I guess that most code is just checking for
> > > a zero/non-zero return value. An advantage of this approach is that
> > > it wouldn't break API compatibility.
> > >
> > > Joao
> > >
> > > | Do you agree?
> > > |
> > > | Alan
> > > |
> > > | email: ir...@be...
> > > | phone: 250-727-2902	FAX: 250-721-7715
> > > | snail-mail:
> > > | Dr. Alan W. Irwin
> > > | Department of Physics and Astronomy,
> > > | University of Victoria, P.O. Box 3055,
> > > | Victoria, British Columbia, Canada, V8W 3P6
> > > | __________________________
> > > |
> > > | Linux-powered astrophysics
> > > | __________________________
> > > |
> > > |
> > > | _______________________________________________
> > > | Plplot-devel mailing list
> > > | Plp...@li...
> > > | https://lists.sourceforge.net/lists/listinfo/plplot-devel
> > >
> > > _______________________________________________
> > > Plplot-devel mailing list
> > > Plp...@li...
> > > https://lists.sourceforge.net/lists/listinfo/plplot-devel
> >
> > _______________________________________________
> > Plplot-devel mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] plgetpos transformation (was valgrind)

[Alan W. I. <ir...@be...>]

Thanks, Maurice, for that information.  It is a big help!

Where multiple terms are used in the documentation for the same thing, I
will try and replace all variations by one term.  However, it will be a long
process....

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)

[Alan W. I. <ir...@be...>]

OK, I have just created c_plcalc_world, changed plTranslateCursor to call
this function, tested the result using ./x01c -locate -dev xwin, and
committed it.  If you have any API concerns for c_plcalc_world now is the
time to express them because I am going to docbook/document it shortly.

As expected (since the code is meant to do the same thing) I found identical
behaviour for both the old and new plplot library.  However, that behaviour
wasn't very good. ./x01c -locate -dev xwin works fine so long as your cursor
is inside a viewport.  However, outside a viewport the cursor just freezes.

This bug makes some sense since there is no world coordinate information
outside viewports. But I expect the xwin driver is simply ignoring the
current 0 return code when no valid world coordinates can be found, and
therefore getting into trouble.  Can somebody find a quick fix to this
driver behaviour? (I just verified this cursor freeze also shows up for tk
and ntk.) Instead of the cursor freeze, you should get a message back that
there are no world coordinates at the current position, and you should be
able to move the cursor to new valid viewport locations.  On second thought,
is this a x01c.c problem?

Geoffrey, could you please verify that c_plcalc_world and its parent
plTranslateCursor always return valid world coordinates so long as the
cursor is inside *some* viewport within some subpage?  If it passes this
test, I think I am done since nobody has spoken up about how we could
identify the various viewports within a particular subpage.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Wed, 27 Feb 2002, Alan W. Irwin wrote:

> The new common API function c_plcalc_world (note the name change) can have
> any API it likes since this is a new function.  So the goal there is to be
> the best possible API.  Now my understanding is that common API functions
> are all void, i.e., the only way they return status information is via the
> argument list.  For now I am going to return (via the argument list) a
> window value starting at zero with a window value of -1 indicating failure
> to find a valid window.  I am no API expert so if that is the wrong way to
> go from the best possible API point of view let me know, and I will change
> it.  But the API for this function is a completely separate issue from
> the plTranslateCursor API.
>
> For now, I will leave the plTranslateCursor API strictly as is, but I
> will change its internals to call c_plcalc_world.  Once consensus has
> been reached on changing the plTranslateCursor API, then all data
> returned from c_plcalc_world will be available to plTranslateCursor
> to facilitate that changed API.
>
> Alan
>
> email: ir...@be...
> phone: 250-727-2902	FAX: 250-721-7715
> snail-mail:
> Dr. Alan W. Irwin
> Department of Physics and Astronomy,
> University of Victoria, P.O. Box 3055,
> Victoria, British Columbia, Canada, V8W 3P6
> __________________________
>
> Linux-powered astrophysics
> __________________________

Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)

[Alan W. I. <ir...@be...>]

Some of the confusion here is that the documentation talks about sub-pages,
sub-windows (which I think are the same thing) and lots of different kinds
of coordinates (some of which are the same).  And now Geoffrey has brought
multiple viewports to our attention.  (Thanks, I think....;-))

From the documentation:

Viewports are created within the current subpage. If the division of the
output device into equally sized subpages is inappropriate, it is best to
specify only a single subpage which occupies the entire output device (by
setting nx = 1 and ny = 1 in plstart or plstar), and use one of the viewport
specification subroutines below to place the plot in the desired position on
the page.

So my mental model of what is usually done is the arrangement of sub-pages
is set up by plssub (or equivalent plstart, etc.), and the actual sub-page
you are currently plotting to is specified by pladv.  Only after that
sub-page is specified would you set up possibly multiple (as Geoffrey has
indicated) viewports.

For now, I am going to go ahead with c_plcalc_world as is which will produce
the same functionality as before.  (I am assuming here that the sub-pages
discussed above are identical with the "windows" specified in the code.)

But from Geoffrey's argument below that functionality is broken for multiple
viewports on the same sub-page (or page if there is only one of them).  The
reason I say this is that different viewports will have different world
coordinates, and there doesn't seem to be any provision for that case in the
current code.

Geoffrey, could you please test the current functionality of plGetCursor (as
in example 1, but with your multiple viewports per page) to see what world
coordinates (if any) it returns for your multiple viewports?

Ultimately, I think we will have to change c_plcalc_world to deal with world
coordinates of multiple viewports, but I want to concentrate for now on
getting the current functionality replicated in the common API.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Wed, 27 Feb 2002, Geoffrey Furnish wrote:

> Alan W. Irwin writes:
>  > Using the return value in two different ways is a little awkward because I
>  > believe the first sub-page is numbered zero rather than one.  We could
>  > return i+1 but that could lead to all sorts of misunderstandings.  So how
>  > about just changing the API?  It is possible this might hurt some of our
>  > users since it is public API, but I feel this is not too likely since it is
>  > not part of the documented common API.
>  >
>  > If we agree that it is okay to change the API, I am thinking of returning
>  > the window number in the argument list and returning success or failure as
>  > before.  But I am no API expert so any other suggestions are welcome
>  > especially if there is some obvious data structure where the returned
>  > window number could be stored.
>  >
>  > As far as the common API version is concerned (let's call it c_plgwc where
>  > "gwc" stands for get world coordinates), I also intend to have a return of 1
>  > for success and 0 for failure. Essentially it will be identical to the
>  > current plTranslateCursor except it will have x and y "absolute" coordinates
>  > as input, and world coordinates and window number as output rather than
>  > assuming those data are accessible to/from a PLGraphicsIn struct.  The new
>  > plTranslateCursor would then consist essentially of a call to c_plgwc with
>  > an argument transformation from a PLGraphicsIn struct to the simple input
>  > variables of c_plgwc on input and the reverse on the returned variables.
>  >
>  > I intend to implement these ideas right away, and after checking that it
>  > works I will commit it subject to change if anybody has some API ideas
>  > in the meanwhile.
>
> wheeee!  Well, I love to see prompt action, but I do have one concern
> about what is being discussed in this thread.
>
> I remember when Maurice and I first talked about this thing, years
> ago, but the language that is being used in this thread does not match
> up with what I remember we had talked about.  So either my memory is
> wrong, or maybe somehow we never implemented what I wanted, or
> something.  I dunno, it's been too long.
>
> Anyway, my concern is that the "window", as in the "sub page window",
> may not be the right--or maybe just not sufficient--info to return.  I
> think we also need to return something about the viewport definition.
> Many "windows" have more than one active viewport.  I /often/ make my
> plots have two viewports, the "main" one where the plot goes, and an
> additional one where the legend goes.  For example, on shade plots, I
> may draw one big squarish region with the shaded data, and then a
> little thin/tall bar on the left which shows the color map used in the
> shade, with the y axis on this color bar being the function value
> range in the main plot.
>
> Now, if the user uses the locator and selects a coordinate, they might
> be asking the interactive tool to tell them the world coordinates at
> some point in the main picture area, but they might also be trying to
> determine the value of some particular part of the legend box.  So, it
> seems to me that to really do this right, you need to convert the
> screen (pixel) coords to world coordinates, and return both the window
> (sub page) and the viewport for which the match was found.
>
> I think, reaching way back into the cobwebs, that the fly in the
> ointment here is that we don't number the viewports.
>

Re: [Plplot-devel] valgrind [purify killer]

[Joao C. <jc...@fe...>]

On Wednesday 27 February 2002 4:31 pm, Geoffrey Furnish wrote:
> Joao Cardoso writes:
>  > While reading the valgrind docs, it looks like that it's output is
>  > very verbose. In your experience can this be a problem? 500 errors t=
o
>  > parse :-x
>
> valgrind gives you one block of errors for each "context", and
> multiple occurrences of an error in a context result in no additional
> printings of that context block during the program run.  Then at the
> end, it summarizes activity in each context.  So no, 500 errors is not
> that bad, because its only a few contexts, with a few lines each.
> Again, if you've used purify, this will look very familiar.

Ah, 50, not 500 (possible) errors, and only on 3 contexts, related with t=
he=20
same line of code! which does look OK...
I will investigate it latter.

Thanks,
Joao

> For example, here's the error output for x08c:
>
> [furnish@xiphi tmp2]$ valgrind x08c -dev xwin
> =3D=3D7932=3D=3D valgrind-20020224, a memory error detector for x86 GNU=
/Linux.
> =3D=3D7932=3D=3D Copyright (C) 2000-2002, and GNU GPL'd, by Julian Sewa=
rd.
> =3D=3D7932=3D=3D For more details, rerun with: -v
> =3D=3D7932=3D=3D
> =3D=3D7932=3D=3D Use of uninitialised value of size 4
> =3D=3D7932=3D=3D    at 0x402C3582: plnxtvhi_draw (plot3d.c:826)
> =3D=3D7932=3D=3D    by 0x402C34E8: plnxtvhi (plot3d.c:793)
> =3D=3D7932=3D=3D    by 0x402C32F9: plnxtv (plot3d.c:725)
> =3D=3D7932=3D=3D    by 0x402C1EE3: plt3zz (plot3d.c:499)
> =3D=3D7932=3D=3D
> =3D=3D7932=3D=3D Use of uninitialised CPU condition code
> =3D=3D7932=3D=3D    at 0x402C35B2: plnxtvhi_draw (plot3d.c:837)
> =3D=3D7932=3D=3D    by 0x402C34E8: plnxtvhi (plot3d.c:793)
> =3D=3D7932=3D=3D    by 0x402C32F9: plnxtv (plot3d.c:725)
> =3D=3D7932=3D=3D    by 0x402C1EE3: plt3zz (plot3d.c:499)
> =3D=3D7932=3D=3D
> =3D=3D7932=3D=3D Use of uninitialised value of size 4
> =3D=3D7932=3D=3D    at 0x402C4AD6: pl3cut (plot3d.c:1563)
> =3D=3D7932=3D=3D    by 0x402C3A96: plnxtvhi_draw (plot3d.c:949)
> =3D=3D7932=3D=3D    by 0x402C34E8: plnxtvhi (plot3d.c:793)
> =3D=3D7932=3D=3D    by 0x402C32F9: plnxtv (plot3d.c:725)
> =3D=3D7932=3D=3D
> =3D=3D7932=3D=3D Use of uninitialised value of size 4
> =3D=3D7932=3D=3D    at 0x402C4B2F: pl3cut (plot3d.c:1574)
> =3D=3D7932=3D=3D    by 0x402C3A96: plnxtvhi_draw (plot3d.c:949)
> =3D=3D7932=3D=3D    by 0x402C34E8: plnxtvhi (plot3d.c:793)
> =3D=3D7932=3D=3D    by 0x402C32F9: plnxtv (plot3d.c:725)
> =3D=3D7932=3D=3D
> =3D=3D7932=3D=3D Use of uninitialised CPU condition code
> =3D=3D7932=3D=3D    at 0x402C4B35: pl3cut (plot3d.c:1575)
> =3D=3D7932=3D=3D    by 0x402C3A96: plnxtvhi_draw (plot3d.c:949)
> =3D=3D7932=3D=3D    by 0x402C34E8: plnxtvhi (plot3d.c:793)
> =3D=3D7932=3D=3D    by 0x402C32F9: plnxtv (plot3d.c:725)
> =3D=3D7932=3D=3D
> =3D=3D7932=3D=3D Use of uninitialised value of size 4
> =3D=3D7932=3D=3D    at 0x402C4B87: pl3cut (plot3d.c:1588)
> =3D=3D7932=3D=3D    by 0x402C3A96: plnxtvhi_draw (plot3d.c:949)
> =3D=3D7932=3D=3D    by 0x402C34E8: plnxtvhi (plot3d.c:793)
> =3D=3D7932=3D=3D    by 0x402C32F9: plnxtv (plot3d.c:725)
> =3D=3D7932=3D=3D
> =3D=3D7932=3D=3D Use of uninitialised value of size 4
> =3D=3D7932=3D=3D    at 0x402C3582: plnxtvhi_draw (plot3d.c:826)
> =3D=3D7932=3D=3D    by 0x402C34E8: plnxtvhi (plot3d.c:793)
> =3D=3D7932=3D=3D    by 0x402C32F9: plnxtv (plot3d.c:725)
> =3D=3D7932=3D=3D    by 0x402C2C41: plgrid3 (plot3d.c:640)
> =3D=3D7932=3D=3D
> =3D=3D7932=3D=3D Use of uninitialised CPU condition code
> =3D=3D7932=3D=3D    at 0x402C35B2: plnxtvhi_draw (plot3d.c:837)
> =3D=3D7932=3D=3D    by 0x402C34E8: plnxtvhi (plot3d.c:793)
> =3D=3D7932=3D=3D    by 0x402C32F9: plnxtv (plot3d.c:725)
> =3D=3D7932=3D=3D    by 0x402C2C41: plgrid3 (plot3d.c:640)
> =3D=3D7932=3D=3D
> =3D=3D7932=3D=3D Use of uninitialised value of size 4
> =3D=3D7932=3D=3D    at 0x402C1C8C: plt3zz (plot3d.c:463)
> =3D=3D7932=3D=3D    by 0x402C0BF8: c_plotsh3d (plot3d.c:159)
> =3D=3D7932=3D=3D    by 0x8048F28: main (x08c.c:113)
> =3D=3D7932=3D=3D    by 0x406D5627: __libc_start_main
> (../sysdeps/generic/libc-start.c:129)
> =3D=3D7932=3D=3D
> =3D=3D7932=3D=3D Invalid read of size 4
> =3D=3D7932=3D=3D    at 0x402C35AC: plnxtvhi_draw (plot3d.c:837)
> =3D=3D7932=3D=3D    by 0x402C34E8: plnxtvhi (plot3d.c:793)
> =3D=3D7932=3D=3D    by 0x402C32F9: plnxtv (plot3d.c:725)
> =3D=3D7932=3D=3D    by 0x402C1EE3: plt3zz (plot3d.c:499)
> =3D=3D7932=3D=3D    Address 0x4164BE20 is 0 bytes after a block of size=
 24
> alloc'd
> =3D=3D7932=3D=3D    at 0x4005745E: malloc (vg_clientmalloc.c:590)
> =3D=3D7932=3D=3D    by 0x402C335B: plnxtvhi (plot3d.c:746)
> =3D=3D7932=3D=3D    by 0x402C32F9: plnxtv (plot3d.c:725)
> =3D=3D7932=3D=3D    by 0x402C1EE3: plt3zz (plot3d.c:499)
> =3D=3D7932=3D=3D
> =3D=3D7932=3D=3D Invalid read of size 4
> =3D=3D7932=3D=3D    at 0x402C35AC: plnxtvhi_draw (plot3d.c:837)
> =3D=3D7932=3D=3D    by 0x402C34E8: plnxtvhi (plot3d.c:793)
> =3D=3D7932=3D=3D    by 0x402C32F9: plnxtv (plot3d.c:725)
> =3D=3D7932=3D=3D    by 0x402C1EE3: plt3zz (plot3d.c:499)
> =3D=3D7932=3D=3D    Address 0x41664284 is 0 bytes after a block of size=
 376
> alloc'd
> =3D=3D7932=3D=3D    at 0x4005745E: malloc (vg_clientmalloc.c:590)
> =3D=3D7932=3D=3D    by 0x402C335B: plnxtvhi (plot3d.c:746)
> =3D=3D7932=3D=3D    by 0x402C32F9: plnxtv (plot3d.c:725)
> =3D=3D7932=3D=3D    by 0x402C1EE3: plt3zz (plot3d.c:499)
> =3D=3D7932=3D=3D
> =3D=3D7932=3D=3D Use of uninitialised value of size 4
> =3D=3D7932=3D=3D    at 0x402C3582: plnxtvhi_draw (plot3d.c:826)
> =3D=3D7932=3D=3D    by 0x402C34E8: plnxtvhi (plot3d.c:793)
> =3D=3D7932=3D=3D    by 0x402C32F9: plnxtv (plot3d.c:725)
> =3D=3D7932=3D=3D    by 0x402C2E61: plgrid3 (plot3d.c:658)
> =3D=3D7932=3D=3D
> =3D=3D7932=3D=3D Use of uninitialised CPU condition code
> =3D=3D7932=3D=3D    at 0x402C35B2: plnxtvhi_draw (plot3d.c:837)
> =3D=3D7932=3D=3D    by 0x402C34E8: plnxtvhi (plot3d.c:793)
> =3D=3D7932=3D=3D    by 0x402C32F9: plnxtv (plot3d.c:725)
> =3D=3D7932=3D=3D    by 0x402C2E61: plgrid3 (plot3d.c:658)
> =3D=3D7932=3D=3D
> =3D=3D7932=3D=3D Use of uninitialised value of size 4
> =3D=3D7932=3D=3D    at 0x402C1C8C: plt3zz (plot3d.c:463)
> =3D=3D7932=3D=3D    by 0x402C0CE9: c_plotsh3d (plot3d.c:164)
> =3D=3D7932=3D=3D    by 0x8048F28: main (x08c.c:113)
> =3D=3D7932=3D=3D    by 0x406D5627: __libc_start_main
> (../sysdeps/generic/libc-start.c:129)
> =3D=3D7932=3D=3D
> =3D=3D7932=3D=3D ERROR SUMMARY: 5079 errors from 14 contexts (suppresse=
d: 16
> from 1)
> =3D=3D7932=3D=3D malloc/free: in use at exit: 9184 bytes in 69 blocks.
> =3D=3D7932=3D=3D malloc/free: 765 allocs, 696 frees, 878849 bytes alloc=
ated.
> =3D=3D7932=3D=3D For a detailed leak analysis,  rerun with: --leak-chec=
k=3Dyes
> =3D=3D7932=3D=3D For counts of detected errors, rerun with: -v
> [furnish@xiphi tmp2]$

Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)

[Geoffrey F. <fu...@ga...>]

Alan W. Irwin writes:
 > Using the return value in two different ways is a little awkward because I
 > believe the first sub-page is numbered zero rather than one.  We could
 > return i+1 but that could lead to all sorts of misunderstandings.  So how
 > about just changing the API?  It is possible this might hurt some of our
 > users since it is public API, but I feel this is not too likely since it is
 > not part of the documented common API.
 > 
 > If we agree that it is okay to change the API, I am thinking of returning
 > the window number in the argument list and returning success or failure as
 > before.  But I am no API expert so any other suggestions are welcome
 > especially if there is some obvious data structure where the returned
 > window number could be stored.
 > 
 > As far as the common API version is concerned (let's call it c_plgwc where
 > "gwc" stands for get world coordinates), I also intend to have a return of 1
 > for success and 0 for failure. Essentially it will be identical to the
 > current plTranslateCursor except it will have x and y "absolute" coordinates
 > as input, and world coordinates and window number as output rather than
 > assuming those data are accessible to/from a PLGraphicsIn struct.  The new
 > plTranslateCursor would then consist essentially of a call to c_plgwc with
 > an argument transformation from a PLGraphicsIn struct to the simple input
 > variables of c_plgwc on input and the reverse on the returned variables.
 > 
 > I intend to implement these ideas right away, and after checking that it
 > works I will commit it subject to change if anybody has some API ideas
 > in the meanwhile.

wheeee!  Well, I love to see prompt action, but I do have one concern
about what is being discussed in this thread.

I remember when Maurice and I first talked about this thing, years
ago, but the language that is being used in this thread does not match
up with what I remember we had talked about.  So either my memory is
wrong, or maybe somehow we never implemented what I wanted, or
something.  I dunno, it's been too long.

Anyway, my concern is that the "window", as in the "sub page window",
may not be the right--or maybe just not sufficient--info to return.  I
think we also need to return something about the viewport definition.
Many "windows" have more than one active viewport.  I /often/ make my
plots have two viewports, the "main" one where the plot goes, and an
additional one where the legend goes.  For example, on shade plots, I
may draw one big squarish region with the shaded data, and then a
little thin/tall bar on the left which shows the color map used in the
shade, with the y axis on this color bar being the function value
range in the main plot.

Now, if the user uses the locator and selects a coordinate, they might
be asking the interactive tool to tell them the world coordinates at
some point in the main picture area, but they might also be trying to
determine the value of some particular part of the legend box.  So, it
seems to me that to really do this right, you need to convert the
screen (pixel) coords to world coordinates, and return both the window
(sub page) and the viewport for which the match was found.

I think, reaching way back into the cobwebs, that the fly in the
ointment here is that we don't number the viewports.

Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)

[Joao C. <jc...@fe...>]

On Wednesday 27 February 2002 5:03 pm, Alan W. Irwin wrote:
> Using the return value in two different ways is a little awkward becaus=
e I
> believe the first sub-page is numbered zero rather than one.  We could
> return i+1 but that could lead to all sorts of misunderstandings.  So h=
ow
> about just changing the API?

My suggestion was intended to avoid this API break. However, I don't thin=
k=20
that it would confuse users. Many standard C library functions are expect=
ed=20
to return e.g. a pointer on sucess or NULL to indicate failure.

Currently, plGetCursor() comments say:
 Returns 0 if no translation to world coordinates is possible.

I would propose that it says:
 Returns the subwindow number, starting at 1, or 0 if no translation to w=
orld=20
coordinates is possible.

With this approach I thing that most code would still work without=20
modifications; x01c will.

If you think that this is not reasonable, them the PLGraphicsIn structure=
=20
could contain one more field, the subwindow number; existing code will st=
ill=20
work, but should be recompiled.

>  It is possible this might hurt some of our
> users since it is public API, but I feel this is not too likely since i=
t is
> not part of the documented common API.
>
> If we agree that it is okay to change the API, I am thinking of returni=
ng
> the window number in the argument list and returning success or failure=
 as
> before.  But I am no API expert so any other suggestions are welcome
> especially if there is some obvious data structure where the returned
> window number could be stored.
>
> As far as the common API version is concerned (let's call it c_plgwc wh=
ere
> "gwc" stands for get world coordinates), I also intend to have a return=
 of
> 1 for success and 0 for failure. Essentially it will be identical to th=
e
> current plTranslateCursor except it will have x and y "absolute"
> coordinates as input, and world coordinates and window number as output
> rather than assuming those data are accessible to/from a PLGraphicsIn
> struct.  The new plTranslateCursor would then consist essentially of a =
call
> to c_plgwc with an argument transformation from a PLGraphicsIn struct t=
o
> the simple input variables of c_plgwc on input and the reverse on the
> returned variables.
>
> I intend to implement these ideas right away, and after checking that i=
t
> works I will commit it subject to change if anybody has some API ideas
> in the meanwhile.
>
> Alan
>
> email: ir...@be...
> phone: 250-727-2902=09FAX: 250-721-7715
> snail-mail:
> Dr. Alan W. Irwin
> Department of Physics and Astronomy,
> University of Victoria, P.O. Box 3055,
> Victoria, British Columbia, Canada, V8W 3P6
> __________________________
>
> Linux-powered astrophysics
> __________________________
>
> On Wed, 27 Feb 2002, Joao Cardoso wrote:
> > On Wednesday 27 February 2002 04:07, Alan W. Irwin wrote:
> > | I would appreciate further discussion of one aspect of the
> > | plTranslateCursor code.
> > |
> > | It goes through a reversed list of windows (I assume these are
> > | sub-windows?) and for the first one where the cursor is inside the
> > | sub-window it does the transformation and returns.
> > |
> > | If I have this interpretation right, then it looks like the pyqt
> > | group's plgetpos using data in the PLStream struct won't really
> > | work since on a page with subwindowing, the world coordinates can
> > | vary wildly form sub-window to sub-window (e.g., example 1), and
> > | their code doesn't take account of this.  So my guess is they are
> > | going to be forced (by example 1) to go to the plTranslateCursor
> > | type of transformation.
> >
> > One problem with plGetCursor() is that it doesn't give information on
> > which sub-page the mouse event occurred. I always found this a
> > serious limitation.
> >
> > Perhaps using the "i" variable as the return value from
> > plGetCursor()? of course existing code that relies on a "1" to be
> > returned would fail, but I guess that most code is just checking for
> > a zero/non-zero return value. An advantage of this approach is that
> > it wouldn't break API compatibility.
> >
> > Joao
> >
> > | Do you agree?
> > |
> > | Alan
> > |
> > | email: ir...@be...
> > | phone: 250-727-2902=09FAX: 250-721-7715
> > | snail-mail:
> > | Dr. Alan W. Irwin
> > | Department of Physics and Astronomy,
> > | University of Victoria, P.O. Box 3055,
> > | Victoria, British Columbia, Canada, V8W 3P6
> > | __________________________
> > |
> > | Linux-powered astrophysics
> > | __________________________
> > |
> > |
> > | _______________________________________________
> > | Plplot-devel mailing list
> > | Plp...@li...
> > | https://lists.sourceforge.net/lists/listinfo/plplot-devel
> >
> > _______________________________________________
> > Plplot-devel mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel