octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave plot window input focus


From: Michael D Godfrey
Subject: Re: Octave plot window input focus
Date: Sun, 31 Jan 2010 12:41:25 -0800
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1

On 01/31/2010 01:21 AM, John W. Eaton wrote:
On 31-Jan-2010, David Grundberg wrote:

| ----- Ursprungsmeddelande -----
| > I was checking on matlab behavior and noticed that
| > when a command that creates a plot window is
| > executed:
| >
| > In matlab, the plot window has focus, but keyboard input goes
| > to the command window without having to switch focus.
| >
| > In Octave, the plot window has focus, but keyboard input
| > does not go to the command window.  Focus has to be switched
| > to the command window for input.
| >
| > This has been true, at least on X11  Linux systems for many years.
| > But, it has always seemed to me that it would be much better if
| > input focus stayed with the command window.
| >
| > Do people agree that this change would be a good idea (not
| > just for matlab compatibility)?  And, if so, any ideas where to look in the
| > Octave code to implement the change?
| >
| > There are two possible changes:
| >
| > 1. Do just like matlab.
| >
| > 2. Keep focus with the command window so that it is more obvious that
| >        the window will accept keyboard input.
| >
| > Michael
| >
| 
| Just keep it simple and keep the focus where it was. I don't think anyone but the user should decide where focus is. I insist - don't copy matlab on this.

I also find that applications that move the focus to be very annoying,
so let's not copy this by default.  If people really want this
feature, then let's make it configurable and NOT the default.

jwe
  
It appears that the place to deal with this is in the graphics handle properties.  There
are already properties like: selected, visible, xdisplay, ...  They appear not to do much
at present.  I remember that when I was "documenting" these for the interpreter Manual,
I just listed them without explanation since I could not find what they did.   More work to
do...

One suggestion: it might be user-friendly to provide a "window manager" window.
This could be created on the first instance of a graphics handle.  This window could have
an entry to each current graphics handle and allow setting the  properties of each window.
(The command window is not a graphics window, so it is a special case.)

Michael


reply via email to

[Prev in Thread] Current Thread [Next in Thread]