Comments 34
Кроме того, все эмуляторы трэкпадов на google play, которые я нашёл, используют серверную часть. Поэтому, я решил не морочить голову.
Если у кого-нибудь есть пример, как можно заставить телефон притвориться bluetooth клавиатурой или мышью для внешнего устройства, буду очень рад ссылке.
Про MOUSE4, MOUSE5, — это не должно быть проблемой в реализации и сейчас. Robot вроде как это всё поддерживает.
А как тогда определять какое окно в данный момент открыто?
Другое дело, что они как были в разными в разых «ветвях» IDE, так и остались. По той же причине, собственно.
Ну а дальше — та самая «мышечная» память и невозможность ничего изменить…
Вот список того, что я нашёл. Все проекты ниже пытаются решить схожие задачи:
- textexpander — преобразует небольшую последовательность, введённую с клавиатуры в длинный текст
- CodingKeys — унифицирует горячие клавиши различных IDE на маках.
- SHORTCUT-S — хардварная реализация похожей идеи
- keyboardtrader — тут я так и не понял, насколько её можно конфигурировать
- оптимусы от Артемия
Допустим, вы отлаживаете клиент-серверную систему, где сервер написан на с++ в Visual Studio, а клиент — приложение на java в IDEA или eclipse.
Можно использовать Delphi, где и сервер и клиент можно писать в пределах одной IDE. Будет и язык один и хоткеи.
Пример про VS и eclipse я привёл в статье просто как самый очевидный.
Кроме того, язык программирования следует выбирать исходя из задачи, которую надо решить, а не из того, на чём написаны смежные инструменты.
Следуя вашей логике, все браузеры нужно писать на js или php, потому что они взаимодействуют с кодом на этих языках.
Кроме того, язык программирования следует выбирать исходя из задачи, которую надо решить
Да. Только решать стоит минимальными средствами и с максимальным удобством. Искать язык (или несколько), которые максимально покрывают насущные и вероятные будущие потребности. В нашем случае, например, это Delphi + JS, с разными языками и средами работают разные люди.
все браузеры нужно писать на js или php
это вообще никак не вытекает из моей логики :)
Однако, согласитесь, что если выбор есть, разумно закладываться на один язык, одну кодовую базу и, одну среду.По поводу одного языка и одной кодовой базы ничего говорить не буду — случаи могут быть разные, надо смотреть на конкретную ситуацию. Однако, однозначно не могу согласиться с утверждением по поводу одной среды. А если среда перестанет развиваться, или вам нужно будет перейти на платформу, которую данная среда не поддерживает?
Я наоборот стараюсь в своих проектах писать код так, чтобы минимизировать потенциальное количество работы по переходу между платформами (даже, если я этого делать не планирую).
В нашем случае, например, это Delphi + JS, с разными языками и средами работают разные люди.Так мой изначальный пример как раз про ситуацию, когда одному человеку приходится работать в двух средах одновременно.
это вообще никак не вытекает из моей логики :)Как я понял, по вашей логике, нужно писать на Delphi ;)
Что-то я так и не понял, как описываемая система позволяет повысить продуктивность работы, если вы всё равно отказываетесь от мышечной памяти? Вместо того, чтобы совершенно автоматически нажать комбинацию клавиш, нужно переводить взгляд на телефон, копаться в менюшках, выбирая функцию и контролируя, в правильное ли окно она отправится, а потом снова переключать фокус не IDE. Так и какую же проблему вы решили и решили ли её?
Во время работы, страница с соответствующим режимом отрыта на телефоне и всё время перед глазами (телефон на подставке, поэтому брать в руки его обычно не надо). Поэтому, чаще всего, нужное действие можно выполнить в один тап по экрану телефона.
Для отладки телефон берётся в руку и кнопки пошагового исполнения нажимаются большим пальцем не глядя (обратите внимание, как они разнесены пространственно по экрану, — это гарантирует, что я не промахнусь и не нажму не на ту кнопку). Поскольку во время пошаговой отладки основное внимание уделяется происходящему на экране, а печатать на клавиатуре особо не нужно, то этот подход для меня работает нормально.
Кроме того, я использую систему в качестве ассистента во время набора текста (вещи, похожие на те примеры, которые приведены в конце статьи).
На счёт мышки — я лично не люблю блуждать по менюшкам (но это уже во многом дело вкуса).
Я делал hardware реализацию для хоткеев на POS клавиатуре. Из всего что пробовал, оказалось самым удобным вариантом. Но и сил на нее надо потратить не мало. У меня этот проект больше года развивался. Щас иду дальше, заменяя некоторые макросы нажатий клавиш на пайтон скрипты. Так некоторые фичи работают быстрее и стабильнее.
Если кому интересно, вот ссылка на статью: https://geektimes.ru/post/273182/
Идея была тогда выдрать микросхему из старой клавиатуры, сделать девайс с 4-5 кнопками, которые бы закорачивали соответствующие контакты на микросхеме и симулировали таким образом нажатия. Был бы такой пультик управления дебаггером.
Однако, когда начал более-менее серьёзно что-то делать, решил, что програмную реализацию будет сделать попроще всё-таки, да и возможностей у неё будет побольше.
Абстрагируемся от горячих клавиш в десктопных приложениях, или как отлаживаться в любом IDE одними и теми же кнопками