Hi,

I'm trying to create a number of shortcuts for a variety of applications. The method that seems to work best is to assign a key combination using:
System Settings -> Shortcuts and Gestures -> Edit -> New -> Global Shortcut -> Send keyboard input -> Action

This works in instances where the application response time is at, or below, the response time of whatever it is that is sending the keystrokes. If the application is slower, then the keystrokes that follow the one that did not respond fast enough, seem to be ignored or processed against something that can not respond to them. The example that I have run into most recently is in Dolphin. I am trying to use shift+tab to move to the Editable Location field. The tabbing takes longer than the process sends the key, and so, the following keys are ignored or processed incorrectly and silently.

So, does 'Send keyboard input' have a sleep or delay command? Is there a user manual for the 'Send keyboard input' macro language, if that is what it is?

Please note, I am not a programmer or script writer, just a dumb-user attempting to improve my productivity using a single, simple, readable tool to create consistent results. And yes, I have tried other reasonably simple tools, like xte in the Command/URL screen. However, they all fail regularly in a range of other ways. 'Send keyboard input seems the most reliable.

Cheers

I forgot to mention that I did find:
https://docs.kde.org/stable4/en/kde-wor ... uts-action

I hope that is not, all that there is.

Cheers

Not sure whether I got you right, but what I got, sounds like "insane" :-P

You are trying to create a global shortcut to send keystrokes to the active window to perform local shortcuts there?
Why don't you just adjust the local shortcuts instead?

The default shortcut for dolphin to enter the location bar is "Ctrl+L" (as is in about any file/web-browser of the past 20 years), but if you would prefer to use SHIFT+Tab, just edit dolphin shortcuts (Settings/Edit shortcuts), filter for location and change the primary or add an alternative shortcut.

Hi,

Sounds like you didn't get what I was saying. I am trying to create a single, simple, readable way of creating macros, if that is the correct term, that will send key stroke sequences to any application. It might be called automating the keyboard, that is, a way of sending a predetermined series of keyboard key actions to an application. I have a number of applications that I want to automate various repetitive, multi-step tasks.

The example I gave in Dolphin was to demonstrate the actual issue I have. The 'Send keyboard input' facility sends keystrokes to applications too fast for the applications to respond to each key stroke. When that happens the following keystrokes disappear with no indication of what happened. Hence, the need for the capacity to tell the process to wait for the application to finish the current task before sending the next key stroke. Sleep or delay is a clumsy workaround to get 'Send keyboard input' to wait for the previous task initiated by the previous key stroke. I can live with it, if it is available.

I understand the ctrl+l option in Dolphin, but it didn't work either. That is also because Dolphin responds too slowly and the following key stroke actions disappear. Ctrl+l occurs in the middle of a sequence of actions, it is not the task itself. I have the same problem with key strokes being delivered too quickly with other applications as well.

As I said previously, I am not a programmer nor a KDE expert that knows all the places and various ways where the same objective can be achieved. I do not have the time or effort available to understand the vagaries of trying to automate every different application in it's own different way. If there is a 'local', whatever that means, way of sending key strokes to applications, on an application by application manner, then I would be interested. However, only if it is similar to the 'Send keyboard input' method, that is, if it is a single, simple, readable method that works on any application and is suitable to me as an end-user.

BTW last time I checked 'insane' is neither a technical term in computing, nor, polite language. Thanks for the rest of your input. The questions I am trying to get answered are:

So, does 'Send keyboard input' have a sleep or delay command? Is there a user manual for the 'Send keyboard input' macro language, if that is what it is?

Cheers

Ah, it wasn't clear to me that you wanted to trigger a shortcut in a series of events, ie your problem is that you want to focus the input area before editing it (and since this async, the input focus is not where you want it when sending the actual content)

No, that's not supported.
My suggestion would be to use a bash script and invoke multiple xdotool calls (with a sleep call - or anything else - inbetween) - or, if defining localtion shortcuts is your major purpose, simply file a wish/bug against dolphin to add shortcuts for random paths.


---
polite or not, defining a global shortcut to only trigger a local shortcut in the active window *would* be insane by any definition :-P

OK. Thanks for the idea about a bash script with xdotool . Unfortunately, you missed my dumb user comments each time. I am not a script writer and do not have the time or capacity to change that.

Also, I have tried using xdotool and xte in the Command/URL option and both fail in various ways in different scenarios.

Also, you have the entire issue upsidedown. I want to trigger a shortcut that is a series of keyboard function keys, letters, symbols, other key strokes and combinations (ie, Alt+ Ctrl+ Meta+ Shift+...) to achieve a series of actions in a particular application that I have created it for. There will be a number of shortcuts for a number of applications to do different tasks. That is why I am trying to get 'Send keyboard input' to do what is says it does in a way that works.

Also, once again, this is NOT a Dolphin issue. That was just a single example of the real issue, which is, 'Send keyboard input' sends keys too quickly for some operations in some applications, hence the need for something like sleep or delay in 'Send keyboard input'.

I do not understand what you mean by

defining a global shortcut to only trigger a local shortcut in the active window.

Does that mean there is another, more appropriate way to do this? Does that mean there is another method of sending key strokes inside applications, rather than typing on a keyboard? Remember when answering that I am a dumb user and will need either detailed instructions or references to user manuals.

To anyone else that reads this, please reply if you know anything about this or can answer the original questions

So, does 'Send keyboard input' have a sleep or delay command? Is there a user manual for the 'Send keyboard input' macro language, if that is what it is?

Then maybe I can make progress on this, or at least give up and say, 'well you can do this in windows, KDE, not so much'.

I am not a script writer and do not have the time or capacity to change that.

You want to SCRIPT input, right? So you're a script writer already; the syntax does hardly matter.
Also what you want to do is rather trivial (no branches/flow control)

Code: Select all

#!/bin/sh
xdotool key Ctrl+l
sleep 0.25 # wait a quartersecond
xdotool key Ctrl+a key a+b+c+d


Also, you have the entire issue upsidedown.

I don't think so. You want to send a series of input events, but need to wait for the client to react after some of them.

I have tried using xdotool and xte in the Command/URL option and both fail in various ways in different scenarios

What "various ways"?
If you cannot control input IN THE DESIRED WAY via scripted xdotool calls, pretty much all hope is lost - there'll be a fundamental logical or technical blocker.

Does that mean there is another, more appropriate way to do this?

No. It means that I initially thought you wanted to define a global shortcut Ctrl+A to just trigger a local shortcut Ctrl+B by sending key input.

at least give up and say, "well you can do this in windows, KDE, not so much"

As explicitly stated before: there's no way to delay input events IN THIS MODULE.
The module is not thought for such and also quite unmaintained - however the generic way to script input on X11 is (the far more powerful) xdotool

Thanks, now I understand what you were saying. I didn't understand what some the things you wrote implied. Thanks for your persistence.

I think what I am after is really record and replay. After that it is something as simple as the command style of 'Send keyboard input'. Real simple and as close to plain readable as possible. I'm thinking macros, as in the way excel worked years ago, before MS decided we all needed to learn to code in Basic or whatever it was and maybe still is. MS actually had a great record and replay programme many years ago. It was probably before even WinNT. It just worked and you didn't need learn anything, just point and click. It even worked across multiple applications in the one run. Of course, they found out it was incredibly useful and got rid of it.

If bash is the only real way to do this, then there is a great opportunity for someone to take up 'Send keyboard input' and make it work, and be end-user friendly. I only ran into 'Send keyboard input' when reading a blog three or four months ago. I'm probably wrong, but going by the complexity of the commands it looks to me the development history went xte -> xdotool -> 'Send keyboard input'. I am more than happy to work with someone and do testing for them. Even help with the requirements if useful.

I'm guessing naming the bash script and putting the name in a Command/URL entry would work.

As far as xte and xdotool go I would need a number of assistance requests or bug reports. From memory, I could not get the str function in xte to work and was reduced to using the key command for each letter, individually. For xdotool commands in Command/URL I could not get the delay to work. There were others, but I did not document them. If xdotool delay works fine in bash, maybe there is a bug with Command/URL and handling the xdotool delay. There were no error messages on screen that alerted me to any issues with my 'scripts' in Command/URL, even when I had made mistakes with the commands. It just ate the input in different ways, depending on what I got wrong.

I would like to raise a bug for this module in terms of the timing issue. The only documentation I found states

Remember, you must enter keystrokes here exactly as you would on a keyboard.

So, either the module is not fully developed, is buggy or the documentation needs amending to let end users know what will not work. What is the module called? I'm guessing it does not have a man page.

Once again, thank you for your persistence. I will now go away and create some of the dumbest bash scripts the world has ever seen.

Cheers

Bug reports here:
https://bugs.kde.org/buglist.cgi?produc ... id=1282771

However, the feature predates xdotool and has rather been unmaintained for the past 10 years.
Given xdotool exists (and follows the unix philosophy to do one job well) it would seem more reasonably to me to simply make that kcm a frontend for xdotool (on X11)

Code: Select all

xdotool key a sleep 5 key b key c+d+e


actually works as expected here

It's hard to say why it failed for you, but I'd suggest to try first things from konsole (eg. prepended with a "sleep 5;" to have enough time to switch to the desired window - xdotool can however also activate windows) - this will also let you see error messages.

Hi,

Back again, sorry to say.

This is unresolved because the fix by using xdotool is unreliable between different executions of exactly the same code. This time I was trying to switch between instances of kwrite. The code for xdotool is:

sleep 1
xdotool key --clearmodifiers Alt+Tab
sleep 2

It will some times work as expected, that is, switch to the next application, which is another instance of kwrite. On other occasions xdotool will insert a Space and Tab into the first instance of kwrite. In both cases it is very easy to watch what happens when it gets it right, and when it gets it wrong. So it does not appear to be an issue with the system being busy.

I will report a bug about the timing timing issue with 'Send keyboard input' at:
https://bugs.kde.org/buglist.cgi?produc ... id=1282771
as suggested and add a reference to this discussion. Unfortunately, xdotool appears to have the same issue with waiting correctly for a key stroke to complete whatever action it initiates, as well as misinterpreting Alt+Tab.

That's not about waiting at all.
Alt+Tab is usually passivley grabbed by kglobalaccel (the assignment of global shortcuts) but if a client actively grabs ipnut (eg. because of an open popup menu or a pressed pushbutton), it will receive all input events exclusively (and deal them locally)

I'll now make a very bold statement, since I don't know what you're trying to do, but you're doing it wrongly.

Whatever you want to script, if it's not *actual* keyboard input but state manipulation, don't try to script it by emulating keyboard events - that implies to rely on specific system conditions (in this case not only the input grabbing, but also the focus chain) and will easily fail in *many* places, but by controlling the system programatically through calls to the windowmanager or the clients via IPC.

In the particular case (if you *really* wanted to walk through windows by the kwin focus chain):

Code: Select all

qdbus org.kde.kglobalaccel /component/kwin invokeShortcut "Walk Through Windows"


Hi luebking,

Thanks for replying, again.

That's not about waiting at all.

Yes, even a dumb user like myself knows that. The issue I raised was to demonstrate that the proposed solution, use xdotool rather than the 'Send keyboard input' method, does not work. The xdotool man page claims that

xdotool lets you programatically (or manually) simulate keyboard input and mouse activity, move and resize windows, etc.

So again, we have an example of documentation that needs to nominate what the limitations are.

Alt+Tab is usually passivley grabbed by kglobalaccel (the assignment of global shortcuts) but if a client actively grabs ipnut (eg. because of an open popup menu or a pressed pushbutton), it will receive all input events exclusively (and deal them locally)

Incomprehensible programmer gobbledegook. I have told you, more than six times, that I am an end user (dumb user in programmer terms) and so, that paragraph adds no value to the discussion from my perspective.

I'll now make a very bold statement, since I don't know what you're trying to do, but you're doing it wrongly.

Not bold, presumptive and oblivious to my efforts to communicate with you. I have stated on multiple occasions what I am trying to do. Reread the thread. If your previously stated solution has limitations, then go right ahead and state them. Do not waste my time and your effort by making it sound like you have an answer when you do not. If I am trying to do it wrong then I suggest that, if you want to help, nominate a method that works. By works, I mean for me, an end user. My experience with bash and xdotool has created vast amounts of frustration for me.

Whatever you want to script, if it's not *actual* keyboard input

Again, reread the thread. If Alt+Tab is not keyboard input, please tell me what it is. It works when I input it through my keyboard, but only sometimes works when I use a shortcut calling a bash script that does nothing else. Obviously something an end user would not be expected to know is broken and buggy.

that implies to rely on specific system conditions (in this case not only the input grabbing, but also the focus chain) and will easily fail in *many* places, but by controlling the system programatically through calls to the windowmanager or the clients via IPC.

In the particular case (if you *really* wanted to walk through windows by the kwin focus chain):

Code: Select all
qdbus org.kde.kglobalaccel /component/kwin invokeShortcut "Walk Through Windows"

Even more incomprehensible programmer gobbledegook. Is that meant to be a solution for my previously stated requirement as an end user? Seriously? Then there is no hope. The real answer is, multiple pieces of software have false claims about their capability, and there is nothing for an end user to meet my requirements.

Just for anyone else makes that it this far, this is what I, as an end user, want to do

I want to trigger a shortcut that is a series of keyboard function keys, letters, symbols, other key strokes and combinations (ie, Alt+ Ctrl+ Meta+ Shift+...) to achieve a series of actions in a particular application that I have created it for. There will be a number of shortcuts for a number of applications to do different tasks.

or put another way

what I am after is really record and replay. After that it is something as simple as the command style of 'Send keyboard input'. Real simple and as close to plain readable as possible.

Thanks

Ok, I'll put it very simple:
your approach will not work for principle reasons and no whatsoever operating system.
You try to control the system by faking input but completely ignore that the system may respond differently to that input, depending on its current state.