gnuplot-beta

mouse big cross cursor and hotkeys in "pause mouse"

[Petr M. <mi...@ph...>]

As I use the new ginput.m for accessing gnuplot mousing events from Octave,
I can see some current "inconvencies". In principle, we would be of
advantage to get ginput(n) functionality of Matlab.

Thus:

A. Currently, there is no indication in the terminal windows that it is
doing "pause mouse".

Solution: change cursor to big cross -- ie like a ruler after "r", but the
cross follows mouse until "pause mouse" stops.


B. Mousing hotkeys (including those "hardcoded" to x11 like "q" and "space")
should be disabled during "pause mouse".

Solution and functionality: If a hotkey is pressed during "pause mouse",
then it stops pausing, and set MOUSE_BUTTON=0 and MOUSE_HOTKEY=keycode for
the key pressed.

Usage - example: Pressing "q" in gnuplot's terminal window will pass the "q"
to the caller by MOUSE_HOTKEY, and it may quit mouse tracking and evaluation
functionality.

Question:

- Should the command be "pause mouse hotkey" or "pause mouse nohotkeys"?

- x11_set_cursor(), pm_set_cursor() etc. should be changed from

	term_set_cursor(int type, int x, int y)
to
	term_set_special(int what, int option, int x, int y)

Then, this API will be general enough to send mousing events without adding
new term functions. E.g.

term->set_special(TERM_SPECIAL_RULER, ruler_type, x, y)
term->set_special(TERM_SPECIAL_HOTKEYS, 1, 0, 0)  // enable hotkeys
term->set_special(TERM_SPECIAL_HOTKEYS, 0, 0, 0)  // disable
term->set_special(TERM_SPECIAL_RAISE, 0, 0, 0)  // used by "raise" and
term->set_special(TERM_SPECIAL_LOWER, 0, 0, 0)  // "lower" commands


What do you think?

Could somebody start to implement this?

--
PM

Making demo programs more evident...

[Daniel J S. <dan...@ie...>]

It may be nice to make more apparent the existence of the demo programs. 
 The demos are on the web page now, which is great.  However, I'm 
thinking from the perspective of a new user like a student in an 
academic environment.  The demos are an eye-opener when it comes to the 
initially arcane command line interface, yet I think a new user who 
doesn't have super user privilege may never realize there are some nice 
demos that would really help in the learning curve.  Maybe a "help demo" 
or "help demos" would be nice to explain how to access the scripts.

Here is the thing.  If I have su privilege I can just change to the 
"demo" directory, run "gnuplot", type "load 'all.dem'" and away we go. 
 But someone who hasn't installed the program, but rather just logs into 
an account and types "gnuplot" will not know where to go for the demos. 
 Neither will he or she be able to run the complete set of demos if, in 
fact, they are found... unless they are smart enough to copy the demos 
to their own account.  If a person without su privilege goes to the 
directory where the demos are and loads them, at least one demo requires 
the creation of a file, which will bomb because the user doesn't have 
privilege to create a file in that directory.

Dan

Re: Making demo programs more evident...

[Ethan M. <merritt@u.washington.edu>]

On Friday 07 May 2004 11:57 am, Daniel J Sebald wrote:

Dan, 

I assume you are talking about unix-like systems.

> Here is the thing.  If I have su privilege I can just change to the
> "demo" directory, run "gnuplot", type "load 'all.dem'" and away we go.

I don't understand this.  Why would you have to be superuser to
run the demos?

>  But someone who hasn't installed the program, but rather just logs into
> an account and types "gnuplot" will not know where to go for the demos.

Surely that is an issue of proper installation.  If the system is properly
configured, then default the when a user logs in the environmental
variable GNUPLOT_LIB is set to the demo dir and everything should
work transparently.    Now admittedly we leave this up to the packagers
of specific gnuplot variants rather than making it part of gnuplot's own
"make install" command.  The linux rpms I have seen put the demos
in /usr/share/doc/gnuplot-VERSION/demo/ so I would expect that 
when a new user logs in that is what he gets as GNUPLOT_LIB.


>  Neither will he or she be able to run the complete set of demos if, in
> fact, they are found... unless they are smart enough to copy the demos
> to their own account.

This just isn't true.  Yes, someone with write privilege has to run "make"
in the demo directory in order to generate some of the data files,
but that should already have happened at install time.

> If a person without su privilege goes to the 
> directory where the demos are and loads them, at least one demo requires
> the creation of a file, which will bomb because the user doesn't have
> privilege to create a file in that directory.

"Don't do that".   Set your current directory to something normal,
and set GNUPLOT_LIB to be the directory where the demos are.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Making demo programs more evident...

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

>On Friday 07 May 2004 11:57 am, Daniel J Sebald wrote:
>
>Dan, 
>
>I assume you are talking about unix-like systems.
>

Yes.

>> But someone who hasn't installed the program, but rather just logs into
>>an account and types "gnuplot" will not know where to go for the demos.
>>    
>>
>
>Surely that is an issue of proper installation.  If the system is properly
>configured, then default the when a user logs in the environmental
>variable GNUPLOT_LIB is set to the demo dir and everything should
>work transparently.    Now admittedly we leave this up to the packagers
>of specific gnuplot variants rather than making it part of gnuplot's own
>"make install" command.  The linux rpms I have seen put the demos
>in /usr/share/doc/gnuplot-VERSION/demo/ so I would expect that 
>when a new user logs in that is what he gets as GNUPLOT_LIB.
>

Oh yes, I see that is where they are.  I've a 3.7 version still hanging 
around.  In any case, GNUPLOT_LIB environment variable is the proper way.

>> Neither will he or she be able to run the complete set of demos if, in
>>fact, they are found... unless they are smart enough to copy the demos
>>to their own account.
>>    
>>
>
>This just isn't true.  Yes, someone with write privilege has to run "make"
>in the demo directory in order to generate some of the data files,
>but that should already have happened at install time.
>

I simply meant that one or two of the demos require gnuplot be launched 
from a directory for which there is write privilege.

>>If a person without su privilege goes to the 
>>directory where the demos are and loads them, at least one demo requires
>>the creation of a file, which will bomb because the user doesn't have
>>privilege to create a file in that directory.
>>    
>>
>
>"Don't do that".   Set your current directory to something normal,
>and set GNUPLOT_LIB to be the directory where the demos are.
>

Right, that is the proper way.  I should have read the INSTALL file all 
the way through.

Thanks,

Dan

Re: Making demo programs more evident...

[Daniel J S. <dan...@ie...>]

>
>
>You don't need su for that --- you just need the demo directory itself
>kept somewhere.  And thanks to the GNUPLOT_LIB variable, you don't
>actually have to cd there, either.
>

Yes, GNUPLOT_LIB works nicely.

Dan

Re: Making demo programs more evident...

[Petr M. <mi...@ph...>]

> It may be nice to make more apparent the existence of the demo programs.
> The demos are on the web page now, which is great.  However, I'm
> thinking from the perspective of a new user like a student in an
> academic environment.  The demos are an eye-opener when it comes to the
> initially arcane command line interface, yet I think a new user who
> doesn't have super user privilege may never realize there are some nice
> demos that would really help in the learning curve.  Maybe a "help demo"
> or "help demos" would be nice to explain how to access the scripts.

That's good idea. Put 'help demo' into gnuplot docs, with link to web, and
to how to running from a properly installed gnuplot.

Hmm on "unix" .. "make install" does not install demos, so there is not
"properly" installed unix. Using a rpm package for gnuplot ... turns you to
demos for an old gnuplot.
=> ordinary people (who do just "make install" have no demos avaible).

INSTALL writes ./configure does not want to decide where to put demos -- why
not?

/usr/local/share/gnuplot/... gnuplot is already writing there, why not use
it for demo?


BTW, "make install" installs big unstriped binaries, even for the final
gnuplot 4.0.0. It's not polite for harddisks of our users. I hope no other
app do that!
	Who knows about "make install-strip", and who actually use it?

---
PM

Re: mouse big cross cursor and hotkeys in "pause mouse"

[Ethan M. <merritt@u.washington.edu>]

On Friday 07 May 2004 01:25 am, Petr Mikulik wrote:
> As I use the new ginput.m for accessing gnuplot mousing events from
> Octave, I can see some current "inconvencies". In principle, we would be
> of advantage to get ginput(n) functionality of Matlab.

I've never used Matlab.  Perhaps you could cut-and-paste a man page
description of ginput(n) so that I know what you have in mind?


> B. Mousing hotkeys (including those "hardcoded" to x11 like "q" and
> "space") should be disabled during "pause mouse".

Why would you want to do that?
I should think it would be useful to be able to zoom, unzoom, and rotate
during mouse mode.  Same for the space key.  

> Solution and functionality: If a hotkey is pressed during "pause mouse",
> then it stops pausing, and set MOUSE_BUTTON=0 and MOUSE_HOTKEY=keycode
> for the key pressed.

I am still not understanding why an application would want to do this.
If you want character input rather than mouse coordinates, then
why are you issuing a 'pause mouse' command in the first place?

Also, if you make 'pause mouse' terminate on key press then you will
become sensitive to the mouse focus settings of your window manager.

> Usage - example: Pressing "q" in gnuplot's terminal window will pass the
> "q" to the caller by MOUSE_HOTKEY, and it may quit mouse tracking and
> evaluation functionality.

You want a way to back out of a 'pause mouse' command without
actually sending mouse coordinates, is that right?
This makes sense to me. Normally you could do this by hitting ctrl-C
in the terminal window, but in a scripted environment that may be
inconvenient. As a matter of ergonomics I wouldn't choose 'q' for this,
however. If people get used to typing 'q' in the plot window they are
going to regret it eventually.

Would it be sufficient to activate a SIGINT handling routine for the
plot window during pause mouse, so that you can type ctrl-C in it?



> - x11_set_cursor(), pm_set_cursor() etc. should be changed from
>
> 	term_set_cursor(int type, int x, int y)
> to
> 	term_set_special(int what, int option, int x, int y)

Those are functionally equivalent, aren't they?  
Your first pair of examples below use an extra parameter, but it doesn't
gain anything other the second pair.
> term->set_special(TERM_SPECIAL_HOTKEYS, 1, 0, 0)  // enable hotkeys
> term->set_special(TERM_SPECIAL_HOTKEYS, 0, 0, 0)  // disable
> term->set_special(TERM_SPECIAL_RAISE, 0, 0, 0)  // used by "raise" and
> term->set_special(TERM_SPECIAL_LOWER, 0, 0, 0)  // "lower" commands


> Could somebody start to implement this?

It does not sound difficult, but I am far from understanding the
the design goal or intended application.  Are you really asking
for a way to type character input into the plot window?

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

An observation in animate demo.

[Daniel J S. <dan...@ie...>]

This is not top priority, but I observe in the animate.dem demo that 
inadvertently typing a <cr> multiple times will cause the screens to 
redraw at two second intervals instead of almost imediately if only one 
<cr> is typed.  That is, type "load 'animate.dem'" and get:

gnuplot> load 'animate.dem'
On some screen terminal drivers for PC screens, you'll have
to hit a key to get to the next frame
Press a key to start the rotation...

Then at that point hit return and the demo starts... and zooms by 
quickly.  But if I hit return once again in the middle of the demo it 
will slow down its redraw rate significantly.

Is this an undocumented feature?  Or is something strange happening?

Dan

demos

[Daniel J S. <dan...@ie...>]

I notice that the first demo in 'all.dem' is 'simple.dem'.  There is no 
"reset" at the start of 'simple.dem', so if one types

set parametric
load 'all.dem'

the result is

******************** file simple.dem ********************
         "simple.dem", line 11: parametric function not fully specified

Is this an issue?  Should demos all have "reset" at the start?  (I think 
Ethan brought this up once before.)  I suppose that may change any setup 
the user has.  (Perhaps Hans' idea of capturing the "state" of the 
variables then restoring them after the demos.  That is, each demo would 
have "save state; reset" at the start and "restore state" at the 
beginning.  That may have drawbacks though too, if the demo escapes 
during its run.)

Dan

Re: mouse big cross cursor and hotkeys in "pause mouse"

[Petr M. <mi...@ph...>]

> > As I use the new ginput.m for accessing gnuplot mousing events from
> > Octave, I can see some current "inconvencies". In principle, we would be
> > of advantage to get ginput(n) functionality of Matlab.
>
> I've never used Matlab.  Perhaps you could cut-and-paste a man page
> description of ginput(n) so that I know what you have in mind?

See
http://www.mathworks.com/access/helpdesk/help/techdoc/ref/ginput.html


In summary, it returns mouse position (x,y) and which mouse button was
clicked (1, 2, 3 from left) or ASCII number if key on the keyboard was hit,
at that position.


> > B. Mousing hotkeys (including those "hardcoded" to x11 like "q" and
> > "space") should be disabled during "pause mouse".
>
> Why would you want to do that?

From Octave, I run 3 instances of gnuplot. The main one draws a map. I do
"infinitely" 'pause mouse' and analyze key or mouse: if 'h' pressed => draw
horizontal section through the map in 2nd gnuplot, 'v' for vertical in 3rd
gnuplot, 'q' get off the loop.

> I should think it would be useful to be able to zoom, unzoom, and rotate
> during mouse mode.  Same for the space key.

Sometimes yes, sometimes not => that's why my proposal for
	pause mouse key

will pause until mouse click or key press, with gnuplot default hotkeys
being switched off.


> If you want character input rather than mouse coordinates, then
> why are you issuing a 'pause mouse' command in the first place?

I want to know the key pressed in x11 graph.


> You want a way to back out of a 'pause mouse' command without
> actually sending mouse coordinates, is that right?

No, I want them too.

> Would it be sufficient to activate a SIGINT handling routine for the
> plot window during pause mouse, so that you can type ctrl-C in it?

Obviously no.


> > - x11_set_cursor(), pm_set_cursor() etc. should be changed from
> >
> > 	term_set_cursor(int type, int x, int y)
> > to
> > 	term_set_special(int what, int option, int x, int y)
>
> Those are functionally equivalent, aren't they?

Currently only for what==TERM_SPECIAL_SETCURSOR

> Your first pair of examples below use an extra parameter, but it doesn't
> gain anything other the second pair.
> > term->set_special(TERM_SPECIAL_HOTKEYS, 1, 0, 0)  // enable hotkeys
> > term->set_special(TERM_SPECIAL_HOTKEYS, 0, 0, 0)  // disable
> > term->set_special(TERM_SPECIAL_RAISE, 0, 0, 0)  // used by "raise" and
> > term->set_special(TERM_SPECIAL_LOWER, 0, 0, 0)  // "lower" commands

The main idea is to avoid plenty of new x11/pm/win API functions in x11.trm,
pm.trm, win.trm, rather than adding a new integer (command) into a table of
interactive terminal functions.

=> support for commands "raise", "lower", "setcursor", "switch hotkeys" etc.
would be done without touching x11.trm, pm.trm etc -- just add one #define
TERM_SPECIAL_BLA into a common .h file, and implement the catch for this
TERM_SPECIAL_BLA in gclient.c, gplt_x11.c or ... (and if not implemented,
then it is silently ignored).


I hope I made it more clear now.

---
PM