Pull to refresh

Comments 34

Сейчас все диверсифицируются. JetBrains просто должны выпустить контроллер для дебага (мне миллиард баксов за идею)
Гораздо круче было бы заставить телефон представляться USB или BT-клавиатурой (и мышью до кучи, т.к. некоторые приложения ловят кнопки мыши MOUSE4, MOUSE5 — back/forward в браузерах). Не пришлось бы запускать сервер.
Когда я начинал писать этот проект, я попробовал поискать информацию о том, как это сделать, но толком ничего не нашёл.
Кроме того, все эмуляторы трэкпадов на google play, которые я нашёл, используют серверную часть. Поэтому, я решил не морочить голову.
Если у кого-нибудь есть пример, как можно заставить телефон притвориться bluetooth клавиатурой или мышью для внешнего устройства, буду очень рад ссылке.
Про MOUSE4, MOUSE5, — это не должно быть проблемой в реализации и сейчас. Robot вроде как это всё поддерживает.

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

Кстати, да. Некоторую функциональность в таком случае не реализовать.
Если бы разработчики IDE производили бы автомобили, то педали у всех были бы, наверно, в разной последовательности. А неужели, чёрт возьми, нельзя всем договориться и использовать одни и те же кнопочки? Или они тоже запатентованы?
Иногда, когда просыпается мой внутренний конспиролог, мне кажется, что производители ПО делают это намеренно, чтобы усложнить миграцию для пользователей (см. вторую проблему в начале моей статьи).
Дык, по-моему начинающие IDEделы должны, наоборот, подстраиваться под кнопочки матёрых IDEделов, нет?
Начинающие-то да, а вот те, у кого серьёзная доля рынка, как мне кажется, наоборот пытаются выделяться.
Нет, не пытаются. За прошедшие четверть века с лишним основные клавиши не поменялись. Как повесили в Turbo Pascal 4.0 Step-Into в 1987м на F7 — так и до сих пор в последней версии IntelliJ висит.

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

Ну а дальше — та самая «мышечная» память и невозможность ничего изменить…
UFO just landed and posted this here
Все пытаются сделать горячие клавиши более удобными, поэтому везде разные сочетания. С темами, кстати, тоже самое solarized dark во всех ide разная.
Есть не только TouchBar.
Вот список того, что я нашёл. Все проекты ниже пытаются решить схожие задачи:
  • textexpander — преобразует небольшую последовательность, введённую с клавиатуры в длинный текст
  • CodingKeys — унифицирует горячие клавиши различных IDE на маках.
  • SHORTCUT-S — хардварная реализация похожей идеи
  • keyboardtrader — тут я так и не понял, насколько её можно конфигурировать
  • оптимусы от Артемия
Допустим, вы отлаживаете клиент-серверную систему, где сервер написан на с++ в Visual Studio, а клиент — приложение на java в IDEA или eclipse.


Можно использовать Delphi, где и сервер и клиент можно писать в пределах одной IDE. Будет и язык один и хоткеи.
Так можно переписать серверную часть на java и использовать везде eclipse. Тоже решит проблему, а переписывать придётся только половину проекта, а не всё целиком.
Пример про VS и eclipse я привёл в статье просто как самый очевидный.
Если изначально есть возможность использовать один какой-то язык, одну среду, зачем усложнять себе жизнь переписывая что-либо?
Не всегда есть изначальная возможность что-либо выбирать.
Кроме того, язык программирования следует выбирать исходя из задачи, которую надо решить, а не из того, на чём написаны смежные инструменты.
Следуя вашей логике, все браузеры нужно писать на js или php, потому что они взаимодействуют с кодом на этих языках.
Я понимаю, что случаи всякие бывают. Разные проекты позже совмещенные в нечто общее либо еще что-то. Однако, согласитесь, что если выбор есть, разумно закладываться на один язык, одну кодовую базу и, одну среду. Чем позже героически решать проблемы, которых могло вообще не быть.

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

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

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

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

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

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

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

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

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


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

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

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

Hardware — реализация это круто. Мой проект изначально тоже задумывался как хардварная реализация.
Идея была тогда выдрать микросхему из старой клавиатуры, сделать девайс с 4-5 кнопками, которые бы закорачивали соответствующие контакты на микросхеме и симулировали таким образом нажатия. Был бы такой пультик управления дебаггером.
Однако, когда начал более-менее серьёзно что-то делать, решил, что програмную реализацию будет сделать попроще всё-таки, да и возможностей у неё будет побольше. А вырванная микросхемка, у меня до сих пор где-то в шкафу валяется.
Софт решение однозначно гибче и в разы удобнее. Я в итоге пришел к тому, что на каждую клавишу клавиатуры завел уникальную комбинацию клавиш (ctrl + alt +shift + {any_key}) И все эти комбинации перехватываю через ComfortKey(в ней есть поддержка макросов и еще целый вагон разных фич на все случаи жизни). И если надо переназначить кнопку, трачу на это 10-15 секунд. Что в разы удобнее, чем перепрошивать каждый раз клавиатуру. Так что по сути получилась программно-аппаратная реализация. С плюсам железной (некоторые кнопки жму не глядя) и софтверной по реализации.
Only those users with full accounts are able to leave comments. Log in, please.