I write automated tests for a website. One of the tests needs to press Ctrl+S and type some letters to save a webpage including CSS/JS. The test should require Firefox to have window focus for those several seconds to be able to type the filename and click "Save" (currently XDoTool is used for pressing keys and clicking the mouse).
Sometimes I run the tests on my computer. I don't want to occasionally type something or change the window focus while the page is being saved, so I want to prohibit changing focus for those several seconds when those mouse clicks/key presses are running.
It's not possible to do it at the Webdriver level (a tool that I use for controlling the browser), so I think I should do it at the OS level. Can I prohibit the user from changing window focus or typing anything for a period of time? It may look like:
prohibit user from typing keys/change window focus
save page
allow user to type/change window focus
I guess that another way to achieve the desired effect would be to run Firefox and your automated tests on a nested X server (xf86-video-nested/Xephyr/Xnest).
$ Xnest :1
$ export DISPLAY=:1.0
$ firefox http://something/to/test &
$ your-test-script
Since the nested X server has it's own idea of the focused window, moving the focus on your desktop shouldn't affect it.
(If you don't actually need to see the test progressing, you could use a dummy X server (xf86-video-dummy/Xvfb/Xfake) instead)
Related
I am using Zenity 3.10.2 and any time I use Zenity, regardless of dialog type, the dialog it brings up has focus. i.e. I can straight away press "Enter" straight away and proceed. (I need this ability for automation)
However, there is one exception and it is very difficult to test. It occurs during the KIWI installation of a custom Linux distro and involved a question dialog being created with no focus. Neither enter nor tab have any effect.
There is a bash script which creates this dialog. When I run this in all other contexts, It has focus, but in this install it does not, the cursor appears in random places all around the place. However, from what I can see, the whole point of Zenity is on-top, already focused dialogs.
The actual call to create the dialog is the result of sourcing a file that has the bash script in it i.e. ". ~/.bashrc". Even this approach, always works when I test it manually.
Any ideas as to what could cause a Zenity dialog to be created without focus? Or any way using just Zenity to reclaim / change the focus?
I am aware you can use a window manager such as wmctrl to bring the Dialog to the focus. However this currently not a used package and shouldn't have to do anything else as this is just a simple dialog.
WINDOWMANAGER=/usr/bin/gnome-session
Any guidance would be much appreciated!
I'm trying to configure an automatic, Bluetooth-powered computer lock and unlock system. So far, I've got the lock script down, but I can't think of a script which would unlock the screen, as my comp is password protected. Any ideas?
You normally have two options when you're trying to script something. First, if the application is scriptable then you can issue applescript commands directly to the application. If it's not scriptable then your only other option is with GUI scripting where you simulate pressing buttons and typing keystrokes like if you were sitting in front of the computer doing it yourself. You use System Events commands to do this.
In your case I think you need the second option. In general when you gui script the application has to be frontmost. Since the "unlock screen" is probably frontmost at that moment you have a chance this will work. However I have not tried it so you'll need to do some testing to see if it's possible. Just do some searching for gui scripting examples and give it a try.
I would imagine your script will look something like the following. This assumes the cursor automatically is placed in the password section of the window so that the "keystroke" command will actually be typing in the proper place... otherwise you need to figure a way to put the cursor there before you type anything.
tell application "System Events"
keystroke "unlock password"
delay .5
click button "OK" of window 1
end tell
I want to implement a simple specialized window manager for presentations (not user-controllable) that supports only the following operations:
Moving and resizing of windows
Switching desktops
Starting applications not on current desktop (in background) without disrupting current image.
I don't need any user input, button/titles, ...
What existing window manager should I use as example? There are many little "hello world" window managers, but they usually does not support desktop switching.
You don't need to reimplement the wheel.
openbox will do everything you mention and more besides.
Simply edit the rc.xml to disable the root menu, and re-launch.
Openbox also allows per app setting so that certain applications can open on a particular desktop by default, or with a particular size, or open hidden.
It also supports wildcards in the window selection, so that settings can apply to all windows.
devilspie2 is a window matching utility that can perform actions whenever a window opens.
It is highly hackable and the code is available on github. It will match windows by name/class/etc when they open, and perform actions on them. (including matching all windows and moving them to a different desktop. It will work with most window managers.
Based on the original devilspie which does not have Lua scripting, but is configured using s-exprs instead.
xdotool will also allow you to perform complex actions on windows without hacking any code. It will even fake user input (mouse/kbd) if you need it.
There are a few window managers written in Python that could be good starting points. Qtile and whimsy both describe themselves as hackable.
I have an application that sends the focus to other windows but those windows then don't automatically display themselves in the foreground, i.e. on top of all the other windows. Where can I configure the preferences of my window manager so that this is the default behaviour?
In particular I'm using the Ctrl-0 and Ctrl-Shft-0 shortcuts in the MATLAB IDE to move between the command window and the editor window and although the focus seems to be transferred the new window doesn't automatically redraw itself in the foreground.
Not sure of a key binding off hand that does it, but if you alt-click on a window (which allows you to drag a window) it should come to the front.
As codeDr suggests, MATLAB is also kind of bad about repainting its windows. If you draw to a figure while code is executing, the figure does not update unless you execute drawnow or have some similar pause in the execution to allow the GUI to repaint. Since we're talking about MATLAB, the figure command will also cause the indicated figure to come to the front (in fact, it's harder to get it to not come to the front). So you could do figure(gcf) to bring the current figure to the front, or save the figure number with h = figure; and then later do figure(h). Incidentally, if you want to switch current figures without switching focus, set(0, 'CurrentFigure', h) should set h to the current figure.
Your window manager (probably Metacity?) implements focus-stealing prevention so that rogue apps don't pop up windows that would disturb your typing. Matlab needs to raise its window, and give it the input focus with the correct timestamp. If this is being done from a KeyPress event handler, the timestamp for setting the input focus would be the timestamp from the KeyPress event (i.e. the timestamp of the user-generated event that caused a window to be raised/focused).
To politely give the input focus to a window, google for _NET_ACTIVE_WINDOW.
Usually when the window doesn't repaint, it means that the application's main application loop isn't running to refresh the window. Could it be that Matlab is doing some computation or disk activity when you are switching between windows?
I am working on old Motif-based application for Linux. I want to be able to programmatically change the active window of our application. I can redirect the input by using XSetInputFocus() function and the keyboard input start to go there, but XReconfigureWMWindow() and XRaiseWindow() functions just don't work.
I've read that Window Managers try to stop this behaviour, so tried to disable configure redirection, but this doesn't work either. Any ideas how to make one of my own windows on top of the window stack?
There is a tiny program called wmctrl available (at least in Debian/Ubuntu it is in standard distribution) which is able to perform many operations on windows and desktops, and handles plenty of window managers. I'd suggest testing whether it works in your environment, and if so, peeking at its sources.
You may find the answer to this is dependent on the Window Manager the user is using, or even what settings they've given to the Window Manager. I like to set my Window Managers to do "focus follows mouse", which means you can't send the focus to a window that I haven't put my mouse on, unless you also warp the mouse there (is that function called XWarpMouse?).