I'm replying to myself in a 4 month old thread, so this might show
up correctly in your newsreader.
This is documenting a behavioral change between OS X 10.3.9 and
10.4. It is a (potentially serious) bug, and while I like it, it
might cause others trouble. So be careful before you upgrade.
When I type:
IDL> window
from an OS X X11 xterm the IDL plot window does not get the focus.
So far, this is nothing new to those of you using Terminal.app, and
is actually the behavior I requested long ago (and below in this
email).
But now the window *will not* accept focus, even if I mouse over,
click on it, whatever. A WIDGET window does get the focus and
behaves correctly.
The problem with this new behavior, is if I type:
IDL> window
IDL> zoom
I now cannot quit the zoom procedure (because it relies on window
events (right click) to quit). I have to CTRL+z and then 'kill' my
IDL session :(
So beware... any of you that use non-widget window interactive code
(CURSOR, ZOOM, etc.) on OS X, you probably don't want to upgrade to
10.4 right now.
Of course, there is the chance this is local to my machine. Can
anyone verify this? Is it some strange setting in my .xinit or
.Xdefault file?
If this exists on others, what is the procedure for alerting Apple /
RSI? I assume this is an Apple bug as I haven't done anything new
with IDL between yesterday and today, all I did was upgrade my OS.
-k.
--
http://spacebit.dyndns.org/
On Tue, 18 Jan 2005, Ken Mankoff wrote:
> Hi Group,
>
> I am wondering if anyone can help me switch window focus
> programatically, without the keyboard/mouse.
>
> I've always been a bit bothered that the WINDOW procedure takes
> the focus away from my xterm/emacs window and leaves it on the new
> window. Usually (Linux window managers) ALT+TAB (or ALT+SHFT+TAB)
> fixed it, so it wasn't a big deal.
>
> But now I use Aqua/OS X, and ALT+TAB or CMD+TAB cycles apps, not
> windows. CMD+` cycles windows, but only forwards, and if I have n
> X11 windows open (n = 10 to 50; 2 monitors, 8 virtual desktops) it
> takes a while to get back to n-1. CMD+SHFT+` doesn't do anything
> unfortunately, even though SHFT usually means "cycle backward".
> This leaves only the mouse to get focus back to the xterm/emacs,
> and I don't like using the mouse.
>
> So, I would like to change window focus using the shell, not the
> mouse or keyboard.
>
> I am resigned that if I type the PLOT command (which opens a
> window) my emacs/xterm will not have the focus. But I have rolled
> my own winDOH procedure that runs each time I start IDL:
>
> PRO WINDOH, Window_Index, _EXTRA=e
> if ( n_elements( Window_Index ) eq 0 ) then Window_Index = 0
> ; fill entire 2nd monitor
> window, Window_Index, xsize=1280, ysize=1002, xpos=1920, ypos=454, _EXTRA=e
> ; Add a line here to set focus back to *me*
> end
>
> I would like add a line at the end that returns focus to the
> calling window.
>
> I have thought of the following methods, but what initial testing
> I did tells me it is not very easy (for me)
>
> 1) Shell escape sequences
> Not sure what this even entails, but I have glorped that it could be a
> solution. Any advice?
>
> 2) AppleScript
> I can cycle Finder windows, but X11 doesn't have an applescript dictionary,
> so I don't think this can work.
>
> 3) Apple Universal Access This allows programatic control of
> keyboard + mouse. I could fire a mouse click, but that would
> require me to leave the pointer over the parent. Keyboard control
> might be able to count the number of X11 windows and CMD+` cycle
> through them, but I have actually found the cycling to be buggy w/
> 2 monitors and virtual desktops. Some X11 windows are skipped. so
> I don't think this can work.
>
> 4) unix shell scripting
> xev, xwininfo, etc...
> I read some man pages, but have not gotten farther than that yet.
>
> Any advice/help will be greatly appreciated.
>
> Thanks,
>
> -k.
|