I am currently developing a kiosk application in QML and I want to use kvkbd virtual keyboard for user input.
When used with a window manager (such as icewm), kvkbd works well, but since my application runs without a window manager (it is a kiosk application), kvkbd does not send the keys to the focused field (e.g. a text input).
A simple script for testing would be (I am using OpenSUSE 13.1):
X :1
export DISPLAY=:1
kvkbd
xterm
After switching to the new display (Ctrl + Alt + F_digit), I am able to send input to xterm from keyboard, but not from kvkbd.
Do you have any ideas how can explicitly specify the focused window to kvkbd?
Or any ideas how I can accomplish this issue?
Thanks.
Related
I'm running the KDE desktop, and I'd like to associate hotkeys with a set of windows and use those hotkeys to activate those windows from anywhere. Ideally, this would work like in Windows - where the key launches the app the first time you press it, and thereafter just brings it to the front. But I don't think that's possible in KDE (why not???).
Anyway, the kwin window menu has a "More Actions/Window Shortcut" option that does let you set a key combination that will bring that window to the front. Except that it only works for the current session. Is there no way to make that association permanent?
In my normal Windows workspace, I have 2 PuTty sessions logged on to a unix host under different user ids. Each of these has an associated hotkey. In addition, I have the app I work in (a browser of sorts) with its own hotkey, and a programming editor with its own key. I am constantly switching between these 4 windows, and I do it all with keystrokes. And I use the same keystrokes to start those sessions up when I first need them. It's great - the only Windows feature that I seriously miss when running Linux. How can I come closest to having that in KDE? Or some other Linux desktop?
Well, I tried xdotool, and combined in a script and attached to a KDE custom shortcut, it actually works. Launches the app if xdotool doesn't find it, and activates the window if it does. Painful, but it does work. The app in question is WIN32 code - hence launching it via wine.
Here's the script:
#!/bin/bash
pid=`xdotool search --name Medialine`
if [ "$pid" == "" ]; then
wine /home/rob/wem.exe&
else
xdotool windowactivate $pid
fi
I'm launching multiple instances of a game via bash. Each instance has it's own login password, which I can retrieve from my password manager, which will place it in the clipboard. I'd like to send each instance it's corresponding password and an "Enter" key event, to log them in automatically. The game runs inside a wine virtual desktop, and each instance has a unique window title in WM_NAME.
Any way I can automate the login process?
try xte & wmctrl packages... Using wmctrl, you can focus any specific window & using xte, you can fake keystrokes.
Based on title, you can focus any window, using wmctrl.
They add some time delay, if required
Send keystrokes using xte
Check the man-pages for syntax.
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)
I have a gVIM script that parses current buffer and offers user to select one of multiple choices. It is implemented as console input, but since i'm using graphical version of gVIM, maybe it's possible to use graphical version of multiple choice dialog? I have tried to use python + Tkinter but it's very unstable and is not working on some NIX boxes :(. Any ideas?
GVim has, in its functions and settings, nothing that would enable showing GUI elements (with a few noble exceptions, like closing dialog and such.).
That being said, GVim is open source, and nothing stops you from downloading the source and messing with it.
After some research i have found a solution. VIM supports so-called "clientserver" mode and external application can send a command to it. So this task (and many others) can be solved with following technique (tested on Windows, OSX and Ubuntu):
VIMscript that handles a command launches standalone GUI script in
separate process and returns.
Standalone GUI script (python/ruby/.exe/whatever) displays GUI and
waits for user interaction.
After user interaction, standalone GUI script closes it's window,
communicates back to VIM via "clientserver" interface (call another
script, open file, move cursor etc) and exits.
I have Debian 2.6 running on a SBC that I plan on using in an embedded setup. What I need to do is configure it so that linux will start up and run just my Qt GUI application. Do I need a window manager to do this or can I just do it with X11. Also because it is going to be for an embedded system I do not want to load any desktop manager. Any info on how this can be done would be great!
Yes you can do this without a window manager.
first: You need to boot into a non X session, init level 1 or 3.
second: You need to start the X server, in a basic mode by just calling X or xinit.
third: Start your app. You may need to take a little more control over where your app is positioned on the screen and its dimensions in your code, as you will not have a window manager to help with this.
alternatively: you can launch one of the more basic window managers to see how they play with your system. Motif Window Manager (mwm) and Tab Window Manager (twm)
Note: While working without a window manager, you may get into a state where you cannot do some very basic operations (ex: close a window, move a window, resize a window). You may find that you cannot survive without at least some of the more basic window management functions. Until you close the loop on this, remember, Ctrl + Alt + Backspace will kill the XServer.
If you want to start your app just with X11, you need do:
copy file /etc/X11/xinit/xinitrc to ~/.xinitrc
write all you want to run to it
run command startx
It worked for me and I hope it will help you