При работе со многими программами использование разнообразных комбинаций горячих клавиш — залог высокой производительности и удобства для пользователя. Для достаточно сложных программ мы заучиваем десятки специфических комбинаций клавиш для различный действий. Это позволяет сосредоточиться на фактической работе, а не на блуждании мышкой по многоэтажным меню в поисках необходимого пункта.

Поэтому, идеальная память под комбинации горячих клавиш — мышечная. Пока комбинация в мышечной памяти, не нужно во время работы переключать внимание на выполнение соответствующего действия — оно делается на автоматизме.

Это хорошо, однако у данного интерфейса пользовательского ввода есть проблемы.

Давайте рассмотрим их на примере работы в знакомой большинству обитателей хабра среде — интегрированной среде разработки (IDE).

Это сложная программная система, имеющая множество аспектов использования (написание кода, навигация по коду, рефакторинг, компиляция и исполнение, отладка, работа с системой контроля версий, и.т.д).

Для каждого из этих аспектов есть свои наборы горячих клавиш, которые не используются в других аспектах (когда я пишу код, мне не нужно помнить, какой комбинацией клавиш открывается окно просмотра локальных переменных в отладчике).

Первая проблема — забываются нерегулярно используемые комбинации.



Первая проблема заключается в том, что если какое-либо действие делается нерегулярно, то соответствующая комбинация клавиш с большой вероятностью забудется к следующему разу её использования. При этом, в тот момент, когда эта комбинация снова станет нужна, она может оказаться использованной не один-два раза, а достаточно активно некоторое время.

Пример: допустим, вы решили провести крупномасштабный рефактроинг вашей программной системы.

Основные действия, которые нужно будет делать — внесение различных полуавтоматизированных изменений в код (переименования символов, извлечения кусков кода в отдельные функции, изменения сигнатур функций, и.т.д). Кроме того, вам гораздо чаще придётся прыгать с места на место по проекту, смотреть на различные диаграммы классов, иерархии вызовов, и.т.д.

Данный набор действий может довольно сильно отличается от того, который используется при обычном написании кода, поэтому, комбинации горячих клавиш для таких действий со временем могут вымываться из головы, поскольку крупные рефакторинги делаются нерегулярно.

Для борьбы с этой проблемой некоторые программисты делают себе разнообразные cheat-sheets со списками команд, которые полезны в редких случаях. Когда такой случай наступает, приходится обращаться к шпаргалке (или гуглить).

Вторая проблема — сложность миграции между системами.


Если вам по какой-либо причине пришлось сменить IDE, заученные на уровне мышечной памяти горячие клавиши старой среды разработки могут оказаться серьёзным барьером. Придётся переучиваться, а это не очень приятное и непродуктивное занятие.

Кроме того, старые комбинации в новой системе могут иметь совершенно другие значения, что особо раздражает.

Третья проблема — совместное использование нескольких систем.


Тут всё может быть совсем плохо. Одни и те же действия в разных системах могут иметь разные комбинации горячих клавиш. В этом случае приходится постоянно держать в голове по набору комбинаций для каждой системы. Кроме того, нужно всё время мысленно контролировать, что за система используется прямо прямо сейчас. Ключевое тут: «держать в голове», — о мышечной памяти можно забыть, что повлечёт за собой падение производительности.

Допустим, вы отлаживаете клиент-серверную систему, где сервер написан на с++ в Visual Studio, а клиент — приложение на java в IDEA или eclipse.

Сервер формирует пакет с данными, отправляет их клиенту, который их каким-то образом обрабатывает. Сначала нам необходимо разобраться, правильно ли серверная часть генерирует пакеты для отправки. Затем, после отправки данных сервером, нужно будет в дебаггере на клиентской стороне смотреть, как полученные данные обрабатываются. Причём, общение сервера с клиентом может не ограничиться пересылом одного пакета. В этом случае вам придётся перескакивать туда-обратно между дебаггерами не один раз. Основные действия, которые будут делаться вами в данном случае — команды пошагового исполнения программы (step over, step into, step out). Концептуально, эти действия одни и те же, однако в каждой из сред разработки за них отвечают свои функциональные клавиши:
VS eclipse IDEA
step into F11 F5 F7
step over F10 F6 F8
step out Shift+F11 F7 Shift+F8

При этом, например, 'step into' в eclipse делается клавишей F5, которая в VS отвечает за 'resume execution', что может сбить весь процесс отладки по неосторожности.

В таких ситуациях я часто замечал за собой, что начинаю отлаживать практически исключительно мышкой — это гораздо медленнее, но зато я точно знаю, какое действие и в какой среде я сейчас делаю.

Цель


Создание системы эмуляции клавиатурного ввода, упрощающей использование программ, имеющих большой набор действий, инициируемых при помощи комбинаций горячих клавиш.

Требования к системе:
  • Отсутствие необходимости пользователю помнить фактические значения комбинаций горячих клавиш.
  • Простота отправки команд пользователя приложению. Интерфейс должен позволять организовывать команды таким образом, чтобы их можно было легко и быстро находить и выполнять.
  • Простота настройки системы — пользователь должен иметь возможность подстраивать интерфейс под свои нужды, ограничивать только актуальными командами в данный конкретный момент.
  • Возможность легко переиспользовать конфигурации команд между схожими приложениями.
  • Возможность автоматически контролировать, что окно-адресат для команды активно в момент исполнения команды (чтобы избежать ситуаций, таких как проблема описанная выше — клавиша F5 в дебаггерах eclipse и visual studio).
  • Кросплатформенность приложения — хотелось абстрагироваться не только от фактических комбинаций горячих клавиш, а также и от операционной системы.


Основная идея системы — на компьютере запускается сервер, который отвечает за генерацию клавиатурных команд. Он работает в бэкграунде и отправляет команды активному в тот момент окну. К этому серверу подключается android устройство, которое используется для пользовательского ввода/вывода. Все команды инициируются нажатиями на кнопки, отображаемые на android устройстве. Когда это происходит, сервер отправляет соответствующую комбинацию клавиш активному окну на своей стороне.

Поскольку сопоставление соответствующей комбинации клавиш для данного действия происходит автоматически на сервере, можно будет определить несколько правил такого сопоставления. Это позволяет единообразно работать с разными программами (если наборы действий, производимых в них, схожи).

Конфигурирование сервера


Для работы данной системе необходимо иметь следующую информацию:
  • Данные об окружениях, в которых мы работаем, и для которых мы хотим эмулировать горячие клавиши.
  • Данные о комбинациях горячих клавиш. Необходимо для каждого действия указать комбинацию горячих клавиш, которая его инициирует в каждом из окружений.
  • Конфигурация элементов на клиентском устройстве: расположение, вид и поведение кнопок, которые будут использоваться для отправки команд.


Данные о горячих клавишах в разных окружениях


Данные из первого и второго пункта хранятся в простой таблице (текстовый csv файл с табуляциями в качестве разделителей), которая выглядит примерно так:

Пример конфигурации команд

В нём каждая строка представляют всю информацию об определённой команде. Первые четыре столбца — служебные. В них хранятся данные, которые используются программой для построения интерфейса пользователя:
  1. command_id — уникальное строковое представление команды в системе
  2. command_category — строковое представление категории, к которой команда относится
  3. command_note — короткое описание команды, которое будет написано на её кнопке в пользовательском интерфейсе
  4. command_description — более детальное описание команды

Все остальные столбцы таблицы — информация о комбинациях горячих клавиш в различных окружениях. Формат представления комбинаций описан в документации библиотеки, которую я использую для эмуляции клавиатуры. Описание формата можно посмотреть на сайте документации библиотеки.

Построение интерфейса пользователя


Для писания пользовательского интерфейса используется второй текстовый конфигурационный файл. Интерфейс состоит из набора страниц. На страницах расположены кнопки, каждая из которых соответствует какой-либо команде.

0. простейший вариант


Вот пример простейшей конфигурации страницы и то, как она будет выглядеть на клиентском устройстве:
содержимое конфигурационного файла
page:main page
debug_start
debug_stepInto
debug_stepOver
debug_stepOut
debug_restart


В конфигурации интерфейса просто прописаны идентификаторы команд — по одному в строчку. Это транслируется в такой интерфейс для пользователя:
представление на клиентском устройстве
представление на клиентском устройстве
Если какое-то из действий не определено для данного окружения, то соответствующая кнопка становится неактивна.


1. Несколько кнопок в ряд, промежутки между кнопками


Если в конфигурации указать несколько элементов, разделённых точками с запятой, в одной строке, то соответствующие кнопки будут размещены в один ряд. Между кнопками также можно делать пустые промежутки (для этого достаточно просто не указать идентификатора команды в соответствующем месте).

Следующая конфигурация иллюстрирует данные вещи:
Вертикальные и горизонтальные промежутки между кнопками
page:main page
debug_start;debug_restart;;
;
;debug_stepOver;;
debug_stepInto;;debug_stepOut
;


Интерфейс, в который это транслируется для пользователя:
представление на клиентском устройстве
представление на клиентском устройстве


2. Переиспользование кнопок


Бывают случаи, когда какое-то действие не определено для какого-то из окружений, однако не хочется, чтобы место пустовало. Возможно, есть какое-нибудь другое достаточно схожее действие, которое можно поместить в том же месте в этом случае.

Для этого нужно просто написать по порядку идентификаторы через запятую в соответствующем месте. Система автоматически просканирует список и подберёт первый из вариантов, который будет активен в данном окружении:
Конфигурация с опциями
page:main
debug_start;debug_restart,debug_stopDebugger;;
;
;debug_stepOver;;
debug_stepInto;;debug_stepOut
;


Вид интерфейса в различных окружениях:

представления различных окружений
представления различных окружений

Обратите внимание, как кнопка 'restart' в окружении для VS превращается в 'stop debug' в окружении для eclipse, поскольку для eclipse не определена комбинация для 'restart debug'.

3. Опции.


Многие команды по факту являются целыми группами команд, которые по смыслу схожи, поэтому хочется их объединить вместе в клиентском UI, однако не хочется, чтобы они занимали слишком много места. Для примера можно привести команды типа 'build something': 'build solution', 'build project', 'compile file'. Для таких групп команд можно определить специальную страницу, которая будет автоматически появляться и исчезать при нажатии кнопки группы. Эта специальная страница отличается от стандартной только заголовком — тело у неё такое же.
Пример такой конфигурации
page:main page
debug_start;debug_restart;;
;
do_step
;
optionsSelectorPage:do_step;steps
;debug_stepOver;;
debug_stepInto;;debug_stepOut


Пример работы в UI:
Работа с селектором опций
Работа с селектором опций

Этот подход очень удобен с командами типа '[сделать определённое действие] с [чем-то]', где выбирается ровно один вариант из нескольких для [чего-то].
Все варианты областей действия команды переносятся на дополнительную страницу и автоматически отображаются, когда нужно.

Страницы опций можно также вкладывать одна в другую, образуя более глубокую и разветвлённую структуру.

Привязка к определённому окну ввода


Для того, чтобы не следить за тем, какое окно сейчас активно (чтобы симулируемый клавиатурный ввод не отправился кому попало), можно попросить программу контролировать это. Для этого системе при запуске передаётся опция 'stickEnvToWindow'.
В этом случае при выборе нового окружения, пользователю будет отображаться такой запрос:
Запрос активного окна
Запрос активного окна

Пользователь должен будет сделать нужное ему окно активным и проинформировать об этом программу, нажав кнопку в нижней части экрана клиентского устройства. После этого, всякий раз, когда пользователь запрашивает исполнение команды, сервер будет проверять, правильное ли окно находится в фокусе. Если это не так, то выполнение команды приостанавливается, а пользователю отображается следующая заглушка:
Активное окно не в фокусе
Активное окно потеряло фокус

В этом случае пользователь должен либо вернуть фокус нужному окну и снова запросить выполнение команды, либо отменить команду:
Демонстрация отслеживания окна ввода
Отслеживание окна ввода


Автоматизация клавиатурного ввода


Естественно, данный подход может быть использован не только для горячих клавиш. Любое часто повторяемое действие с клавиатуры может быть автоматизированно при помощи данной программы.

Для себя я регулярно использую подобные вещи:

Вставка слов или фраз на другом языке


Часто при наборе русского текста мне приходится переключаться в английскую раскладку ради одного слова, или даже пары символов. Русская раскладка не признаёт существования следующих символов: ' < > [ ] { } $ # @ & ^ ~, некоторые из которых бывают нужны регулярно. Кроме того, в русском тексте могут встречаться повторяющиеся термины на английском, а, если это html, то ещё и тэги.

Симуляцию набора текста в другой раскладке можно реализовать просто добавив команды переключения раскладки клавиатуры перед и после фактического набора вставляемого текста.

Например, чтобы напечатать тэг <html>, нужно использовать следующую комбинацию: '+{COMMA}html+{PERIOD}'. Она правильно сработает, если включена английская раскладка. Если же включена русская раскладка, то нужно добавить в начало и конец комбинации горячую клавишу переключения раскладки. В моём случае, это '%{SHIFT}' (Alt+Shift). Таким образом, если в текстовом редакторе включена русская раскладка клавиатуры, то следующая последовательность символов: '%{SHIFT}+{COMMA}html+{PERIOD}%{SHIFT}' напечатает там <html>.

Пример работы:
Ввод текста в двух раскладках
Ввод текста в двух раскладках


In-place преобразование выделенного слова


Допустим, мне нужно в большом количестве мест в коде обернуть некоторые переменные в макрос или вызов функции. Например, у какой-то из функций нужно изменить тип параметра, поэтому во всех местах, где эта функция вызывается, нужно сконвертировать то, что туда передавалось в новый тип.

Если подобных изменений нужно сделать хотя бы несколько десятков, то идея это автоматизировать становится очень привлекательной.

Шаги, которые нужно сделать в данном случае:
  1. выделяем переменную двойным щелчком мыши
  2. симулируем команду «вырезать» (Ctrl+x)
  3. симулируем набор текста — название оборачивающей функции и отрывающейся скобки
  4. симулируем команду «вставить» (Ctrl+v)
  5. закрываем скобку

Шаги 2-5 автоматизируются следующей комбинацией: '^{X}my+function+name+9^{V}+0'.
Пример работы:
Оборачивание выделенного текста
Оборачивание выделенного текста

Кроме того, возможно, в разных местах кода вид этих вызовов может немного различаться (возможно, где-то нужно указывать пространство имён вызываемой функции, передавать дополнительные параметры, и.т.д). Всё эти вариации легко реализовать и иметь под рукой.

Заключение



Система пока что сырая — это скорее прототип, а не конечная версия. Но, как мне кажется, уже в её нынешнем состоянии, она способна упростить и повысить эффективность работы с горячими клавишами.

Технические детали реализации я в данной статье не затрагивал, чтобы не раздувать её. Если будет интерес — можно будет сделать статью, посвящённую этому.

Код реализации лежит у меня на гитхабе. Там же есть немного более формальной документации о форматах конфигурационных файлов и аргументов командной строки.

Если не хочется качать исходники и компилировать код, есть собранная для windows версия (для запуска нужно будет поставить Microsoft Visual C++ 2015 Redistributable).
Для самостоятельной компиляции исходников нужен C++14 — совместимый компилятор и boost (используются boost::asio и boost::program_options). В документации есть описание того, как собирать проект при помощи gcc и Visual Studio.

Буду рад услышать критику по поводу реализации, а также предложения о том, что можно добавить в систему. Кроме того, сейчас мне не очень нравится формат конфигурационного файла описания UI. Если у кого-нибудь есть идеи, как можно лучше представить подобный интерфейс (предпочтительно в простом текстовом формате), прошу в комментарии.

Что ещё хочется добавить в данной системе:
  • Возможность выполнять несколько команд одним запросом (это серьёзно улучшит функциональность по симуляции набора текста).
  • Автоматическое отслеживание и переключение раскладки клавиатуры активного окна.
  • Улучшение функциональности работы с конфигурационными файлами, добавление новых типов конфигов.
  • Рефакторинг кода программы.
  • Улучшение системы сообщений пользователю о проблемах в конфигурационных файлах (сейчас сообщения не всегда информативны).
  • Багфиксы симуляции некоторых комбинаций клавиш (см. ниже).


Все ссылки в одном месте:


P.S.



Проблемы и неочевидности, о которых стоит знать перед использованием:
  1. Поддерживается только кодировка UTF-8. Если программе скормить конфиг в другой кодировке, она может выругаться довольно неочевидным сообщением. Пожалуйста, учитывайте это, и сохраняйте файлы в правильной кодировке.
  2. В windows замечена проблема с симуляцией нескольких комбинаций формата Shift+'smth'. Она проявляется для клавиш PgUp, PgDn, Home, End, Insert, Delete и стрелочек. Комбинация типа '+{INSERT}', которая должна симулировать Shift+Insert, по факту симулирует просто нажатие Insert.
  3. В примерах конфигураций многие комбинации горячих клавиш не проверялись на работоспособность. Я просто нагуглил несколько списков и объединил их в общий файл. Поэтому, там возможны ошибки. Буду признателен сообщениям о найденных проблемах в конфигах, а также pull-реквестам.
Поделиться с друзьями
-->

Комментарии (34)


  1. maniacscientist
    03.01.2017 16:27
    +1

    Сейчас все диверсифицируются. JetBrains просто должны выпустить контроллер для дебага (мне миллиард баксов за идею)


  1. qw1
    03.01.2017 17:28

    Гораздо круче было бы заставить телефон представляться USB или BT-клавиатурой (и мышью до кучи, т.к. некоторые приложения ловят кнопки мыши MOUSE4, MOUSE5 — back/forward в браузерах). Не пришлось бы запускать сервер.


    1. taco_attaco
      03.01.2017 18:44

      Когда я начинал писать этот проект, я попробовал поискать информацию о том, как это сделать, но толком ничего не нашёл.
      Кроме того, все эмуляторы трэкпадов на google play, которые я нашёл, используют серверную часть. Поэтому, я решил не морочить голову.
      Если у кого-нибудь есть пример, как можно заставить телефон притвориться bluetooth клавиатурой или мышью для внешнего устройства, буду очень рад ссылке.
      Про MOUSE4, MOUSE5, — это не должно быть проблемой в реализации и сейчас. Robot вроде как это всё поддерживает.


    1. poxu
      03.01.2017 18:48

      А как тогда определять какое окно в данный момент открыто?


      1. taco_attaco
        03.01.2017 19:01

        Кстати, да. Некоторую функциональность в таком случае не реализовать.


  1. Londoner
    03.01.2017 18:01
    +1

    Если бы разработчики IDE производили бы автомобили, то педали у всех были бы, наверно, в разной последовательности. А неужели, чёрт возьми, нельзя всем договориться и использовать одни и те же кнопочки? Или они тоже запатентованы?


    1. taco_attaco
      03.01.2017 18:39

      Иногда, когда просыпается мой внутренний конспиролог, мне кажется, что производители ПО делают это намеренно, чтобы усложнить миграцию для пользователей (см. вторую проблему в начале моей статьи).


      1. Londoner
        03.01.2017 18:53

        Дык, по-моему начинающие IDEделы должны, наоборот, подстраиваться под кнопочки матёрых IDEделов, нет?


        1. taco_attaco
          03.01.2017 18:58

          Начинающие-то да, а вот те, у кого серьёзная доля рынка, как мне кажется, наоборот пытаются выделяться.


          1. khim
            03.01.2017 23:21
            +1

            Нет, не пытаются. За прошедшие четверть века с лишним основные клавиши не поменялись. Как повесили в Turbo Pascal 4.0 Step-Into в 1987м на F7 — так и до сих пор в последней версии IntelliJ висит.

            Другое дело, что они как были в разными в разых «ветвях» IDE, так и остались. По той же причине, собственно.


            1. taco_attaco
              04.01.2017 11:57

              Естественно, исторически сложившиеся тенденции переломить очень сложно. Но у них и в сравнительно недавно появившихся вещах разброд и шатание. Вон, в VS до сих пор ctrl+click не добавили из коробки.


        1. khim
          03.01.2017 23:15
          +2

          Они и подстраиваются. Есть, собственно, три стандарта: IBM Visual Age (потомок — Eclipse), Turbo Pascal 4+ (идейный потомок — через Delphi — IntelliJ IDEA) и Microsoft Visual C++ (самый «свежий», разработка 1993 года, потому не учитывающий существование оригинальной IBM PC клавиатуры с 10ю (а не 12ю!) функциональными клавишами).

          Ну а дальше — та самая «мышечная» память и невозможность ничего изменить…


        1. basili4
          04.01.2017 10:22
          +1

          нормальные IDE делы позваляют выбрать набор какой IDE использовать в их IDE


  1. dimka11
    03.01.2017 18:24

    Все пытаются сделать горячие клавиши более удобными, поэтому везде разные сочетания. С темами, кстати, тоже самое solarized dark во всех ide разная.


  1. usrsse2
    03.01.2017 18:54

    Вы сделали TouchBar


    1. taco_attaco
      03.01.2017 18:56
      +1

      Есть не только TouchBar.
      Вот список того, что я нашёл. Все проекты ниже пытаются решить схожие задачи:

      • textexpander — преобразует небольшую последовательность, введённую с клавиатуры в длинный текст
      • CodingKeys — унифицирует горячие клавиши различных IDE на маках.
      • SHORTCUT-S — хардварная реализация похожей идеи
      • keyboardtrader — тут я так и не понял, насколько её можно конфигурировать
      • оптимусы от Артемия


  1. ElectroGuard
    03.01.2017 22:16
    -1

    Допустим, вы отлаживаете клиент-серверную систему, где сервер написан на с++ в Visual Studio, а клиент — приложение на java в IDEA или eclipse.


    Можно использовать Delphi, где и сервер и клиент можно писать в пределах одной IDE. Будет и язык один и хоткеи.


    1. taco_attaco
      04.01.2017 11:41

      Так можно переписать серверную часть на java и использовать везде eclipse. Тоже решит проблему, а переписывать придётся только половину проекта, а не всё целиком.
      Пример про VS и eclipse я привёл в статье просто как самый очевидный.


      1. ElectroGuard
        04.01.2017 17:30

        Если изначально есть возможность использовать один какой-то язык, одну среду, зачем усложнять себе жизнь переписывая что-либо?


        1. taco_attaco
          05.01.2017 16:32

          Не всегда есть изначальная возможность что-либо выбирать.
          Кроме того, язык программирования следует выбирать исходя из задачи, которую надо решить, а не из того, на чём написаны смежные инструменты.
          Следуя вашей логике, все браузеры нужно писать на js или php, потому что они взаимодействуют с кодом на этих языках.


          1. ElectroGuard
            05.01.2017 20:14

            Я понимаю, что случаи всякие бывают. Разные проекты позже совмещенные в нечто общее либо еще что-то. Однако, согласитесь, что если выбор есть, разумно закладываться на один язык, одну кодовую базу и, одну среду. Чем позже героически решать проблемы, которых могло вообще не быть.

            Кроме того, язык программирования следует выбирать исходя из задачи, которую надо решить

            Да. Только решать стоит минимальными средствами и с максимальным удобством. Искать язык (или несколько), которые максимально покрывают насущные и вероятные будущие потребности. В нашем случае, например, это Delphi + JS, с разными языками и средами работают разные люди.

            все браузеры нужно писать на js или php

            это вообще никак не вытекает из моей логики :)


            1. taco_attaco
              07.01.2017 17:56

              Однако, согласитесь, что если выбор есть, разумно закладываться на один язык, одну кодовую базу и, одну среду.
              По поводу одного языка и одной кодовой базы ничего говорить не буду — случаи могут быть разные, надо смотреть на конкретную ситуацию. Однако, однозначно не могу согласиться с утверждением по поводу одной среды. А если среда перестанет развиваться, или вам нужно будет перейти на платформу, которую данная среда не поддерживает?
              Я наоборот стараюсь в своих проектах писать код так, чтобы минимизировать потенциальное количество работы по переходу между платформами (даже, если я этого делать не планирую).

              В нашем случае, например, это Delphi + JS, с разными языками и средами работают разные люди.
              Так мой изначальный пример как раз про ситуацию, когда одному человеку приходится работать в двух средах одновременно.

              это вообще никак не вытекает из моей логики :)
              Как я понял, по вашей логике, нужно писать на Delphi ;)


  1. Zagrebelion
    04.01.2017 07:37
    +1

    Коллеги, но ведь хоткеи можно изменять.В jetbarinовских IDE даже выбор есть пресетов горячих клавиш: «как в студии», «как в эклипсе», штук 8 их там.


    1. taco_attaco
      04.01.2017 11:39

      Если бы всё ограничивалось только тремя командами дебаггера, то, конечно, я бы не стал заморачиваться.
      По-моему, у этой системы область применения может быть гораздо шире, чем только те примеры, которые я привёл.


  1. Mingun
    04.01.2017 12:48
    +1

    Что-то я так и не понял, как описываемая система позволяет повысить продуктивность работы, если вы всё равно отказываетесь от мышечной памяти? Вместо того, чтобы совершенно автоматически нажать комбинацию клавиш, нужно переводить взгляд на телефон, копаться в менюшках, выбирая функцию и контролируя, в правильное ли окно она отправится, а потом снова переключать фокус не IDE. Так и какую же проблему вы решили и решили ли её?


    1. taco_attaco
      04.01.2017 13:40

      Прошу прощения, ошибся с уровнем. Мой ответ ниже предназначался вам.


  1. taco_attaco
    04.01.2017 13:28

    При обычной работе в IDE я использую конфигурацию, похожую на ту, которая у меня лежит в примерах. Немного её переделал, но идея та же. Там для каждого из режимов работы есть по странице с 4-8 кнопками.
    Во время работы, страница с соответствующим режимом отрыта на телефоне и всё время перед глазами (телефон на подставке, поэтому брать в руки его обычно не надо). Поэтому, чаще всего, нужное действие можно выполнить в один тап по экрану телефона.

    Вот, как выглядят эти страницы на телефоне для этой конфигурации


  1. mtt
    04.01.2017 13:54

    Никогда не забивал себе голову хоткеями — это бесполезный информационный мусор. Ставишь мышку на максимально приемлимую скорость и все получается быстро, а главное именно то что нужно.


    1. taco_attaco
      04.01.2017 14:06

      На счёт информационного мусора — полностью с вами согласен.
      На счёт мышки — я лично не люблю блуждать по менюшкам (но это уже во многом дело вкуса).


      1. mtt
        04.01.2017 19:56
        +1

        Самые нужные команды вытаскиваются из менюшек в тулбары. А дальше всё мышкой, и не надо ничего запоминать


        1. taco_attaco
          05.01.2017 16:30

          Тулбары есть не во всех приложениях, хотя в случае с IDE это может быть довольно эффективным решением.


  1. Evgeniy_M
    04.01.2017 13:57

    Я делал hardware реализацию для хоткеев на POS клавиатуре. Из всего что пробовал, оказалось самым удобным вариантом. Но и сил на нее надо потратить не мало. У меня этот проект больше года развивался. Щас иду дальше, заменяя некоторые макросы нажатий клавиш на пайтон скрипты. Так некоторые фичи работают быстрее и стабильнее.
    Если кому интересно, вот ссылка на статью: https://geektimes.ru/post/273182/


    1. taco_attaco
      04.01.2017 14:00

      Hardware — реализация это круто. Мой проект изначально тоже задумывался как хардварная реализация.
      Идея была тогда выдрать микросхему из старой клавиатуры, сделать девайс с 4-5 кнопками, которые бы закорачивали соответствующие контакты на микросхеме и симулировали таким образом нажатия. Был бы такой пультик управления дебаггером.
      Однако, когда начал более-менее серьёзно что-то делать, решил, что програмную реализацию будет сделать попроще всё-таки, да и возможностей у неё будет побольше. А вырванная микросхемка, у меня до сих пор где-то в шкафу валяется.


      1. Evgeniy_M
        04.01.2017 15:21

        Софт решение однозначно гибче и в разы удобнее. Я в итоге пришел к тому, что на каждую клавишу клавиатуры завел уникальную комбинацию клавиш (ctrl + alt +shift + {any_key}) И все эти комбинации перехватываю через ComfortKey(в ней есть поддержка макросов и еще целый вагон разных фич на все случаи жизни). И если надо переназначить кнопку, трачу на это 10-15 секунд. Что в разы удобнее, чем перепрошивать каждый раз клавиатуру. Так что по сути получилась программно-аппаратная реализация. С плюсам железной (некоторые кнопки жму не глядя) и софтверной по реализации.