Não há mais atalhos de teclado possíveis com base na 'super' key aka 'windows' em qualquer WM

1

Desde = ~ 2 anos, parece que não podemos usar a tecla Super (também conhecida como tecla windows) para executar alguns atalhos de teclado.

Eu tento com o kde, gnome, xfce4, nenhum funciona totalmente.

Por exemplo, eu tenho um atalho de teclado para digitar a data como se eu tivesse digitado atribuido via Super + a , quando eu clico nas teclas, nada acontece. / p>

A linha de comando é bash -c 'xvkbd -xsendevent -text $(date +%Y%m%d)' configurada corretamente nas preferências do xfce4.

Eu atualmente uso o archlinux x86_64, com o kernel 4.15.1-2-ARCH.

Alguém sabe o que há de errado? Onde ? Existe uma correção? Uma solução alternativa?

    
por Gilles Quenot 10.02.2018 / 19:09

1 resposta

1

O atalho principal usado não é o problema

Você pode verificar se o atalho de teclado está sendo definido com êxito, substituindo o comando bash … por xterm (ou algum outro aplicativo gráfico). Se uma janela aparecer, seu atalho está definido corretamente. A questão é quase certamente o comando desejado:

bash -c 'xvkbd -xsendevent -text $(date +%Y%m%d)'

Na minha experiência, o uso de XSendEvent não é confiável. 1 Isso pode ser a origem do seu problema. Usando xdotool , é possível selecionar entre XTEST e XSendEvent , e o primeiro geralmente funciona para mim. Seu xvkbd pode ter opções semelhantes.

Ao enviar sequências de teclas, você precisa limpar os modificadores atuais para garantir que esteja enviando a sequência desejada (por exemplo, test e não Super + t , Super + e , etc.)

Além disso, xdotool tem um comportamento estranho, no qual, se enviar eventos muito em breve, eles desaparecem. 2 Isso pode de fato ser o servidor X descartando eventos, ou pode ser algo totalmente diferente. Em qualquer caso, você pode contornar isso (pelo menos em xdotool ) com um atraso:

xdotool sleep 0.125 type --clearmodifiers 'string to type'

O subcomando type tem uma opção --delay caso o atraso inicial não seja suficiente para impedir a eliminação de eventos.

Em resumo

Eu usaria:

bash -c 'xdotool sleep 0.125 type --clearmodifiers --delay 125 "$(date +%Y%m%d)"'

para replicar seu comportamento pretendido, embora os valores usados para sleep e --delay possam precisar de ajuste, dependendo da sua configuração.

Outra opção possível

Se você não se importa em invadir sua área de transferência, uma abordagem melhor pode ser enviar o atalho padrão para paste selection :

bash -c 'printf "%s" "$(date +%Y%m%d)" | tee >(xsel -bi) | xsel -i; xdotool sleep 0.125 key --clearmodifiers shift+Insert'

Isso usa xsel para colocar o texto desejado em ambas as seleções CLIPBOARD e PRIMARY (como Shift Inserir não é consistente em qual delas usa ). Em seguida, ele sintetiza a seqüência de teclas para colar essa seleção. Como isso requer apenas dois pressionamentos de tecla sintetizados, é menos provável que elimine eventos do que o outro método.

1 De xdotool(1) :

SENDEVENT NOTES

If you are trying to send key input to a specific window, and it does not appear to be working, then it's likely your application is ignoring the events xdotool is generating. This is fairly common.

Sending keystrokes to a specific window uses a different API than simply typing to the active window. If you specify 'xdotool type --window 12345 hello' xdotool will generate key events and send them directly to window 12345. However, X11 servers will set a special flag on all events generated in this way (see XEvent.xany.send_event in X11's manual). Many programs observe this flag and reject these events.

It is important to note that for key and mouse events, we only use XSendEvent when a specific window is targeted. Otherwise, we use XTEST.

Some programs can be configured to accept events even if they are generated by xdotool. Seek the documentation of your application for help.

Specific application notes (from the author's testing):

  • Firefox 3 seems to ignore all input when it does not have focus.
  • xterm can be configured while running with ctrl+leftclick, 'Allow SendEvents'
  • gnome-terminal appears to accept generated input by default.

2 Eu revisitarei esta resposta e expandirei este ponto se eu souber exatamente porque este é o caso.

    
por 10.02.2018 / 19:26