Injecting commands into the IDE

[MarkMLl]

Considering this thread https://forum.lazarus.freepascal.org/index.php/topic,67137.msg515995.html#msg515995 , how can one inject commands (e.g. search files, full build and so on) or keycode sequences into the IDE particularly on Linux?

For years I have been using a Razer Nostromo keypad to give me single-key access to the most common IDE commands, which I find much less demanding than trying to remember and contort my hands to obscure control/shift/alt combinations. However when I moved to the most recent Debian version I found that it would not daemonise reliably, and it would make sense to tack this sort of event handling directly into the IDE.

MarkMLl

[MarkMLl]

Put another way: the IDE Tools -> Options -> Editor -> Key Mappings handles conversions from keycode combinations to (presumably) some sort of symbolic values representing commands. Where is this handled?

It should in principle be possible, at least in the case of Linux, to have a thread which collects events from specific input devices and injects them into the IDE, provided that the IDE has the focus. This would be broadly comparable with the way that CAD software etc. handles devices such as the SpaceMouse by intercepting events rather than relying on their being converted into standard mouse movement etc.

MarkMLl

[Martin_fr]

Ok, since I don't feel like reading up on the other thread, you want to
1) Have the IDE execute something based on events in the IDE
2) Have something external inject a key-stroke to the IDE (or anything that then trigger something that the IDE can do).

The key mapping is handled  between the IDE and SynEdit.

Though if the editor is not focused, then Keystrokes may be found as they are assigned to menu and toolbutton.  That bit of code I haven't looked at in a while... Search for TIdeCommand and expect a fun trail of pieces to follow)

SynEdit.[utf8]KeyDown can look up the command from the KeyStrokes. It calls SynEdit.CommandProcessor

SynEdit then triggers events OnProcessUserCommand or OnProcessCommand (depending on the command) => those are handled in SourceEditor, and forwarded to the IDE (main.pp IIRC - it should join the TIdeCommand trail at this point).



The IDE has on option to only run one instance, and if you double click a file, then the OS starts a new IDE, but that can find the running IDE, and hand over.
There is (probably) a pid file, or some shared mem lock file or similar....

If you track that down, you can possible use that for other stuff than just opening files... But, that also falls under: I haven't looked at in ages, and even then never in detail.

[MarkMLl]

Thanks, I think that gives me what I need.

Updated: from the POV of IDE commands, the important bit seems to be that in designer.pp, TDesigner.KeyDown() uses FTheFormEditor.TranslateKeyToDesignerCommand() to translate a keycode (TLMKey, from lmessages.pp) to a command with an ec prefix.

I'll probably need to use the debugger to find out the main place where TDesigner.KeyDown() is called, then either find a range of VK_ codes (lcltype.pp) which can be coopted and translated into ec commands by a custom function, or coopt a single code which means "something's available: look at the event input subsystem and generate an ec command directly".

The (Linux) input stuff has a lot of event codes which I wouldn't expect to see converted to keycodes by any standard development environment, since it includes stuff used only by high-end flight control yokes etc. There's also the opposite problem of devices being handled as one or more HIDs by default, with special-purpose buttons simply looking like characters: that means that filter code has to look carefully at the origin of input before deciding what to do with it.

This isn't particularly high-priority for me, unless my existing hack grinds to a halt. If I get anywhere I will, of course, report back; however I wouldn't expect a patch to be accepted by the devs since I have neither the means nor inclination to test on anything other than Linux.

MarkMLl