+1 к dwm, использую его уже хз сколько лет, не самый навороченный WM в мире, но простой как 3 копейки. Написан на C в весьма кратком и понятном стиле с использованием Xlib, можно хакать даже не будучи знакомым с Xlib и разбираться уже по ходу, также на suckless есть патчи с фичами.
То есть, клиентское приложение должно знать про все возможные языки (включая тот, который я, возможно, только что придумал и про который пишу пост), про все возможные стили графиков, и так далее?
Ничего не понял. С чего ему знать про ВСЕ возможные языки? Если вы пишете пост про язык с неизвестным синтаксисом, раскрашивайте код сами через теги смены цвета, возможно экспортируя из IDE с поддержкой данного языка как это делает например emacs htmlize, больше тут не сделать ничего. Если пишется кусок кода на известном языке под тегом типа "```javascript" в markdown, то пусть клиент реализует поддержку синтаксиса известных языков насколько хочет/насколько хватает ресурсов, и раскрашивает, заодно цветовую схему будет контролировать юзер, а не автор поста. То же самое про стили графиков, не понял что имелось в виду, в том же gnuplot есть типовые стили и никто не требует от него возможности рисовать произвольным стилем.
Процедурных расширений стандарт веб-документов должен избегать как огня, иначе получится второй js.
(Голос из могилы) Usenet! Gopher! Fidonet!
Социальные платформы с plaintext форматом данных (в который можно впихнуть хоть html5 хоть sgml хоть этот ваш маркдаун) и поддержкой федерации/оффлайна уже давно реализованы, но только разговоры про отказ от сложного веба я слышу уже лет 10, а пользователи все как сидели так и сидят в современном вебе. То же самое с веб-приложениями, их недостатки 100 раз объяснены, только всё равно 99.9% пользуются веб-почтой, новостными веб-порталами и т.д., и привыкли всё делать из браузера. Успокойтесь, эта война проиграна давно.
То что вы перечислили это вообще не проблемы, проблемы programmer dvorak в другом (см ниже). "Отсутствует в стандартной поставке любых ОС" — в линуксе (Xorg) Programmer Dvorak имеется (setxkbmap -layout us -variant dvp), про остальные ОС я не в курсе, но авторы и энтузиасты раскладок часто выкладывают готовые конфиги под Win, Mac, Linux и/или типовой софт д. управления раскладками, например Autohotkey. Ну и вообще, кто мешает написать свой конфиг, там не ядерная физика. То же к комменту про когнитивный диссонанс при смене языка — если при этом перемешиваются цифры то это исключительно проблема конфига, надо писать конфиг где цифровые клавиши единообразны во всех раскладках.
Остальные пункты про цифры — это аналоги недостатка "в двораке всё не так как в qwerty". Дворак уже переворачивает с ног на голову практически все буквенные позиции qwerty, толку в этой ситуации пытаться сохранить ещё и привычки по цифровому ряду.
Про Dvorak vs Programmer Dvorak (dvp) vs другие конкуренты скажу вот что. (Дисклеймер: Я автор собственной раскладки — форка Дворака, проделавший путь qwerty -> dvorak -> dvp -> своя раскладка, и собственной раскладки (в начальной стадии) для модальных редакторов (это вим со всем семейством, хоткеи hjkl, dcyp, вот это всё)).
Почти любая раскладка эффективнее QWERTY (говорил в др комментарии), в тч Dvorak, dvp, colemak, ...
Какая альт. раскладка реально лучшая — тайна, покрытая мраком. Идеальной метрики ещё не придумано, в качестве доказательства эффективности своих раскладок фанаты раскладок любят приводить ограниченные/неточные метрики (например travel distance, согласно которой лучшая раскладка всех времён и народов это 3l).
Основной недостаток раскладки Дворака — она была придумана во времена, когда ПК ещё был близко не изобретён. В итоге она прекрасно оптимизирована под набор английского литературного текста, но неэффективна при наборе кода, тк не знает ничего про современную роль символьных (скобки, операторы...) клавиш, модальных (всякие ctrl и tab) клавиш, автодополнение и сниппеты IDE, и т.д. ...
Programmer Dvorak бесит меня больше всего. Он заявляет, что создан для решения проблемы выше и ориентирован на C-подобные языки, но это всё громкие пустые заявления. Слэш и минус, одни из самых частых символов в C-подобных языках, задвинуты чёрт-те куда, C-шные самые частые биграммы /* */ (я знаю про nerdcommenter, дело не в этом) набираются 1 рукой неэффективным движением (weird motion), C-шному -> и Rust'овому => сразу до свидания, анализ частотности биграмм (сразу бы привлёкший внимание к биграммам ); -> л/п буква+скобка л/п буква+подчёркивание) судя по всему даже не проводился. Ну и никаких design documents нет, как понять и оценить принципы по которым формировалась раскладка не представляется возможным. Причём для понимания проблемы с Си достаточно просто поюзать раскладку один день и осознать "чёрт, набор -> и комментов же ужасен, надо что-то улучшать", автор как будто на Сях на своём же творении вообще не писал. Итог: dvp чуть лучше dvorak для кодинга за счёт пары удачных решений (скобки, изменённый порядок цифр, лучше раскиданы символы), но лучший метод общения с ним — взять это удачное решение и идти дальше искать лучшую раскладку или делать свою.
Сменить раскладку (именно как средство набора текста) вообще не проблема, несколько недель или пара месяцев. То же кстати касается и альт. клавиатур. Первая реальная проблема, актуальная для вимеров и вообще любителей хоткеев — все хоткеи при смене раскладки рассыпаются, а их десятки, сотни. Проще всего решить это, создав т.н. позиционную раскладку (т.е. перезабить все клавиши так, что позиции пальцев останутся старыми, например hjkl на двораке будет dhtn). А можно пойти дальше и осознать, что кое-что в типовой vim раскладке не идеально, например почему это клавиши движения и операций ([w]ord, [c]hange) мнемонические (по первым буквам), а не оптимизированы по частоте операций (согласно которой forward word это третья по частоте операция). И пойти убивать остаток жизни на создание новой идеальной раскладки IDE (тот же Xah Lee по ссылке, уж какой признанный клавиатурный гуру, но и он признавался, что создание единой логичной раскладки ide, оптимизированной по частоте, он не возьмётся, пока ему не дадут года 2 так свободного времени).
Ergodox это рай для вимера из-за уникальных средних клавиш, на одну из которых удобно вешать Esc. На обычных PC104 клавиатурах вимеры часто меняют местами CapsLock и Esc для приближения Esc и это всё равно мало помогает — новая позиция Esc жмётся слабым пальцем (мизинцем).
Статья замечательная, но откровенно скажу — в эргономике клавиатур вы затронули только верхушку айсберга.
Физическая клавиатура является лишь одним из "большой тройки" компонентов, определяющих эргономику и скорость набора. Двумя другими, не менее важными, являются раскладка клавиатуры и раскладка горячих клавиш приложений, в первую очередь IDE. Оставаясь на QWERTY и точечных улучшениях хоткеев, вы обходите вниманием эти 2 оставшихся компонента.
Раскладка клавиатуры: каждый фанат альтернативной раскладки будет разумеется хвалить свою собственную, но думаю все они сойдутся на мысли, что с кверти надо бежать куда угодно, на любую раскладку, пусть она хоть как-то задумывается о базовых принципах эргономики набора (передвижение более частых букв на home row и под более сильные пальцы, hand alternation, finger rolling). Подойдёт буквально любая, от античного Dvorak до более новых альтернатив, таких как 3l и arensito.
Хоткеи IDE: Лидерами в эффективности хоткеев являются модальные редакторы и имитирующие их плагины для других приложений (Vimperator). Ну а разработка кастомной модальной раскладки для редактора, aka попытки упихнуть десятки модальных команд (forward/backward word/WORD/block/paragraph/..., операции с буфером, выделением итд) на удобные позиции в соответствии с их частотой, является задачей уровня epic.
По поводу QMK: я считаю, что программирование обработки нажатий клавиш на уровне железа, например QMK или хардварный ремаппинг, является проигрышной практикой в сравнении с софтверным конфигурированием (в тч программированием хоткеев в IDE), по следующим причинам:
Не универсально, требует клавиатуры со специальными возможностями и знания уникального в каждом случае средства настройки (QMK, механизм макросов и ремапа kinesis advantage, ...). Софтовое конфигурирование работает на любой клавиатуре и использует универсальные средства — конфигуратор раскладки вашей графической среды (XKB в X.org) и скриптовый язык IDE (если вы конфигурируете команду IDE).
Физическое расположение клавиш становится чёрным ящиком для софта. Задав аппаратный маппинг, вы не сможете например сгенерировать геометрическую картинку своей клавиатуры через xkbprint или измерить расстояние, преодолеваемое пальцами (travel distance) в какой-либо задаваемой программно задаче, не захардкоживая геометрию вашей раскладки.
Хардверная конфигурация проигрывает софтверной в гибкости и количестве возможностей. В случае железа ограничивающим фактором являются ограничения, вложенные в платформу, на которые вы никак повлиять не можете. В случае софта вы можете выбирать любой конфигуратор — XKB в Xorg, xcape, Autohotkey, скриптовый язык IDE, самописный обработчик.
Хардверный обработчик не знает ничего о контексте набираемых символов, плагин для IDE — знает.
Софтовый конфиг легче переносим между различными ПК, а в случае одного ПК позволяет разным пользователям иметь разные раскладки.
Осилить конкурента для X11 для гугла не проблема — они уже сделали surefaceflinger для android, например.
Я имел в виду именно "конкурента", а не "свою NIH реализацию display server". Конкурент должен: 1) иметь работающую реализацию хотя бы на десктопном линуксе (опционально на прочих свободных юниксах типа *bsd ит.д.) 2) поддерживаться хотя бы Gtk и Qt, иначе как же компилировать и запускать существующий GUI софт под этот новый чудо-графический сервер. В списке бэкендов Gtk и Qt под линукс никакой альтернативы X11 кроме Wayland и Mir пока не наблюдается.
Меня всегда вводят в состояние глубочайшего недоумения слова «мы вложили кучу сил и средств в наш плагин для Chrome / в приложение для G-play и внезапно гугл нам всё заблокировал и поставил бизнес под угрозу». Так и представляю разговор, состоявшийся между авторами и инвесторами 3 года назад:
— Привет, мы делаем приложение под весьма специфическую платформу, контролируемую гуглом, и под конкретный браузер, под редчайшую задачу, имеются сильные конкуренты. От вас потребуется оплата ТРЁХЛЕТНЕГО труда коллектива разработчиков фулл-тайм, а потом с итоговым продуктом сыграют в рулетку модераторы гугла, известные тем, что банят приложения по желанию левой пятки без права обжалования. Что же может пойти не так.
— Конечно, о чём речь, вот вам инвестиции
Вдогонку: а почему у вас на сайте нет кнопки прямой загрузки плагина как альтернативы chrome store, настолько смирились со стором?
Можно бесконечно смотреть на 3 вещи: огонь, воду и как fillpackart клепает статьи об инженерах, которые практикуют правильный подход к технологиям, но мир несовершенен и поэтому они страдают.
Вы ошибаетесь. Aurа лежит в стеке UI выше чем X/Wayland и использует корневое окно иксов, см. архитектурную схему. Можно спросить ТСа, я думаю в выхлопе top на скриншоте у него ниже имеется Xorg. Aura — конкурент например для Gtk+, но не для иксов. Сомневаюсь, что гугл вообще осилит такую титаническую работу как конкурент X Window, по вейланду можно примерно понять чего это стоит, это не новый WM написать, здесь куча стандартов (я посмотрю как они xkb перепишут например), протоколов, легаси софта.
Пользуюсь постоянно Toshiba Chromebook 2 как основной машиной (с полной заменой ChromeOS на обычный десктопный Linux), данный коммент пишу с него, в 2017 писал статью на хабр про свой хромбук, с тех пор ничего не поменялось, работает как часы. TL;DR машинка ещё слабее acer-а (2 Gb RAM, SoC Baytrail N2840 с 2-ядерным целероном), преднамеренно нищебродская (~170$) тк считаю что задача, требующая большой мощности ПК, как правило указывает на недостатки workflow а не на слабость железа. Программирование, почта, веб, медиафайлы, всё как у остальных.
Я считерил с экономией на доставке, попросив начальника (американца) привезти мне его, как только он поехал в командировку в Россию. :) Без этого доставка дорогая, в России хромбуков не водится.
Про хромОС: Кодеки являются большой проблемой. Многие фильмы и музыка стоковым плеером не открываются. Я так понимаю, гугл предполагает, что юзеры будут смотреть всё только на ютубе. Решается crouton'ом или что там сейчас для чрута/виртуализации появилось, и установкой нормального плеера в гостевой ОС, как у вас в статье написано, но это мягко говоря не уровень "домашнего пользователя", на коих ориентированы хромбуки.
Подозреваю что имеется проблема с домашними медиасерверами и сетевыми дисками. Хром ОС ориентирована на облака гугла, подключение к NFS/Samba и возможно DLNA в стоковой поставке отсутствует, не уверен например что модуль NFS оставили в ядре (ходят тут всякие умные, ставят гостевые линуксы и из них монтируют домашний сетевой диск).
Да, это так, Windows 10 в случае с UEFI/GPT слава богу просто добавляет свой бутлоадер на EFI system partition, не вредя уже имеющимся бутлоадерам (в теории, на практике слышал что она может затирать и чужие бутлоадеры на ESP).
Но старые машины с BIOS никуда не делись. Да и загрузочный список UEFI установщик Win10 модифицирует в своём типичном стиле — ставит себя на первое место в списке. Что вызывает некоторое недоумение у тех, кто использует GRUB+UEFI и после установки обнаруживает, что вместо граба по дефолту грузится винда. Хотя казалось бы, наличие GRUB это чёткое указание, что на этой машине он контролирует загрузку и надо бы не мешать человеку загрузиться по умолчанию в юникс и добавить винду через update-grub.
Возможность писать фронтенд и плагины на любом языке. Это отдельные приложения, сервер общается с ними на JSON-RPC, асинхронно. По сравнению с Vimscript и Emacs Lisp — просто небо и земля (хотя, справедливости ради, в Emacs есть API для динамической загрузки плагинов на C).
Быстродействие и снижение затрат по памяти — священная корова проекта. В документации прямым текстом требуется от разработчиков "любая базовая операция редактирования должна выполняться не больше 16ms". Куча оптимизированных структур данных (инкрементальные обновления кэша строк д. клиентов, оптимизированное хранение строк), всюду асинхронность.
Высокая модульность, отдельно сервер, отдельно клиент, отдельно language server, предпринимаются попытки выделить структурные компоненты редактора в отдельный SDK, на котором можно писать xi-подобные редакторы.
(Только для разработчиков IDE): редактор в начальной стадии разработки, можно попытаться реализовать мечту об идеальном редакторе. Проект известный, можно почесать эго и вписать своё имя в историю.
(Только для Rust разработчиков): Идеален для вкатывания в rust разработчику уровня сеньёра с опытом в других языках — многокомпонентный сложный продукт, даёт универсальные знания (обработка юникода, кэшей строк, асинхронное взаимодействие компонентов), куча как архитектурных задач так и деталей реализации. Отличная строчка в резюме.
Rust и Cargo со всеми их преимуществами.
Я ещё года полтора назад услышал про xi, но так и не понял почему некоторые его восхваляют(ну помимо фанатов rust'a). Особого смысла от разделения на бэк и фронт для текстового редактора я не вижу, а остальные фичи не кажутся значимым и частично реализованы в современных сборках vim и emacs.
Это так, редактор выстрелит только если реализует какие-то киллер-фичи для разработчиков которые будут в нём кодить, а для не разработчиков редакторов. Пока я слышал восторги только от вторых (которые на данный момент и являются основной аудиторией xi), из пользовательских фич пока демонстрировать нечего.
Вообще, заметил за любителями rust склонность переписывать всё что угодно на rust. Иногда получается что-то достойное, но зачастую выходит по функционалу 80% от оригинала. Причём в ридми помимо прочих фич этого «крутого» проекта обязательно указывается бонусом то, что он написан на «безопасном и быстром» расте.
Хех, есть такое, Xi ещё ладно, это разработка с нуля, а вот тут Emacs переписывают на расте. А ещё на расте (не на шелле) написан rustup, инструмент разворачивания и управления toolchain'ами раста. Да, чтобы изменить его поведение, надо его перекомпилировать, что очень весело делать, если он не отработал до конца и rustc ещё нет в системе.)) За себя скажу, что мне подход "Rust всюду" не нравится, я при всей своей симпатии к Rust не применяю его без нужды. В любом случае, эта проблема к Xi не относится, я бы контрибутил в него даже если бы он был скажем на C/C++ а не на Rust, его фишка в архитектуре и структурах данных, а не в языке.
P.S. Глянул ридми различных фронтендов, что-то не заметно прогресса за год.
Это известная проблема, сервер (xi-core) страдает от нехватки внимания ключевых разработчиков, тк лидер проекта и ещё 1 ключевой разработчик сейчас заняты на платной основе другими проектами на Rust — runebender и druid. А разработка клиентов тормозится багами сервера и тем фактом что я уже упомянул — догнать известные редакторы/IDE по функциям это задача на годы.
VS Code не изолированный продукт. К примеру, он использует для синтактического анализа LSP (language server protocol), созданный Microsoft как раз для VS Code. Затем LSP стал открытым стандартом, продолжая оставаться под контролем MS, и вот тут уже MS во всей красе показала свою типичную тактику по отношению к открытым стандартам. LSP допускает широкую трактовку во многих местах, так что де-факто стандартом становится референсное поведение vscode, также "неудобные" жалобы на критические недостатки протокола порой просто-напросто игнорируются. В итоге у MS под контролем один из лидеров рынка программируемых редакторов, задающий стандарты, а бессмысленность форкания LSP или VS Code думаю объяснять не стоит.
+1 к dwm, использую его уже хз сколько лет, не самый навороченный WM в мире, но простой как 3 копейки. Написан на C в весьма кратком и понятном стиле с использованием Xlib, можно хакать даже не будучи знакомым с Xlib и разбираться уже по ходу, также на suckless есть патчи с фичами.
Ничего не понял. С чего ему знать про ВСЕ возможные языки? Если вы пишете пост про язык с неизвестным синтаксисом, раскрашивайте код сами через теги смены цвета, возможно экспортируя из IDE с поддержкой данного языка как это делает например emacs htmlize, больше тут не сделать ничего. Если пишется кусок кода на известном языке под тегом типа "```javascript" в markdown, то пусть клиент реализует поддержку синтаксиса известных языков насколько хочет/насколько хватает ресурсов, и раскрашивает, заодно цветовую схему будет контролировать юзер, а не автор поста. То же самое про стили графиков, не понял что имелось в виду, в том же gnuplot есть типовые стили и никто не требует от него возможности рисовать произвольным стилем.
Процедурных расширений стандарт веб-документов должен избегать как огня, иначе получится второй js.
(Голос из могилы) Usenet! Gopher! Fidonet!
Социальные платформы с plaintext форматом данных (в который можно впихнуть хоть html5 хоть sgml хоть этот ваш маркдаун) и поддержкой федерации/оффлайна уже давно реализованы, но только разговоры про отказ от сложного веба я слышу уже лет 10, а пользователи все как сидели так и сидят в современном вебе. То же самое с веб-приложениями, их недостатки 100 раз объяснены, только всё равно 99.9% пользуются веб-почтой, новостными веб-порталами и т.д., и привыкли всё делать из браузера. Успокойтесь, эта война проиграна давно.
Это всё задачи клиентского приложения, они не являются частью формата веб-документа.
То что вы перечислили это вообще не проблемы, проблемы programmer dvorak в другом (см ниже). "Отсутствует в стандартной поставке любых ОС" — в линуксе (Xorg) Programmer Dvorak имеется (
setxkbmap -layout us -variant dvp), про остальные ОС я не в курсе, но авторы и энтузиасты раскладок часто выкладывают готовые конфиги под Win, Mac, Linux и/или типовой софт д. управления раскладками, например Autohotkey. Ну и вообще, кто мешает написать свой конфиг, там не ядерная физика. То же к комменту про когнитивный диссонанс при смене языка — если при этом перемешиваются цифры то это исключительно проблема конфига, надо писать конфиг где цифровые клавиши единообразны во всех раскладках.Остальные пункты про цифры — это аналоги недостатка "в двораке всё не так как в qwerty". Дворак уже переворачивает с ног на голову практически все буквенные позиции qwerty, толку в этой ситуации пытаться сохранить ещё и привычки по цифровому ряду.
Про Dvorak vs Programmer Dvorak (dvp) vs другие конкуренты скажу вот что. (Дисклеймер: Я автор собственной раскладки — форка Дворака, проделавший путь qwerty -> dvorak -> dvp -> своя раскладка, и собственной раскладки (в начальной стадии) для модальных редакторов (это вим со всем семейством, хоткеи hjkl, dcyp, вот это всё)).
Почти любая раскладка эффективнее QWERTY (говорил в др комментарии), в тч Dvorak, dvp, colemak, ...
Какая альт. раскладка реально лучшая — тайна, покрытая мраком. Идеальной метрики ещё не придумано, в качестве доказательства эффективности своих раскладок фанаты раскладок любят приводить ограниченные/неточные метрики (например travel distance, согласно которой лучшая раскладка всех времён и народов это 3l).
Основной недостаток раскладки Дворака — она была придумана во времена, когда ПК ещё был близко не изобретён. В итоге она прекрасно оптимизирована под набор английского литературного текста, но неэффективна при наборе кода, тк не знает ничего про современную роль символьных (скобки, операторы...) клавиш, модальных (всякие ctrl и tab) клавиш, автодополнение и сниппеты IDE, и т.д. ...
Programmer Dvorak бесит меня больше всего. Он заявляет, что создан для решения проблемы выше и ориентирован на C-подобные языки, но это всё громкие пустые заявления. Слэш и минус, одни из самых частых символов в C-подобных языках, задвинуты чёрт-те куда, C-шные самые частые биграммы
/* */(я знаю про nerdcommenter, дело не в этом) набираются 1 рукой неэффективным движением (weird motion), C-шному->и Rust'овому=>сразу до свидания, анализ частотности биграмм (сразу бы привлёкший внимание к биграммам); ->л/п буква+скобка л/п буква+подчёркивание) судя по всему даже не проводился. Ну и никаких design documents нет, как понять и оценить принципы по которым формировалась раскладка не представляется возможным. Причём для понимания проблемы с Си достаточно просто поюзать раскладку один день и осознать "чёрт, набор->и комментов же ужасен, надо что-то улучшать", автор как будто на Сях на своём же творении вообще не писал. Итог: dvp чуть лучше dvorak для кодинга за счёт пары удачных решений (скобки, изменённый порядок цифр, лучше раскиданы символы), но лучший метод общения с ним — взять это удачное решение и идти дальше искать лучшую раскладку или делать свою.Сменить раскладку (именно как средство набора текста) вообще не проблема, несколько недель или пара месяцев. То же кстати касается и альт. клавиатур. Первая реальная проблема, актуальная для вимеров и вообще любителей хоткеев — все хоткеи при смене раскладки рассыпаются, а их десятки, сотни. Проще всего решить это, создав т.н. позиционную раскладку (т.е. перезабить все клавиши так, что позиции пальцев останутся старыми, например hjkl на двораке будет dhtn). А можно пойти дальше и осознать, что кое-что в типовой vim раскладке не идеально, например почему это клавиши движения и операций ([w]ord, [c]hange) мнемонические (по первым буквам), а не оптимизированы по частоте операций (согласно которой forward word это третья по частоте операция). И пойти убивать остаток жизни на создание новой идеальной раскладки IDE (тот же Xah Lee по ссылке, уж какой признанный клавиатурный гуру, но и он признавался, что создание единой логичной раскладки ide, оптимизированной по частоте, он не возьмётся, пока ему не дадут года 2 так свободного времени).
Ergodox это рай для вимера из-за уникальных средних клавиш, на одну из которых удобно вешать Esc. На обычных PC104 клавиатурах вимеры часто меняют местами CapsLock и Esc для приближения Esc и это всё равно мало помогает — новая позиция Esc жмётся слабым пальцем (мизинцем).
Статья замечательная, но откровенно скажу — в эргономике клавиатур вы затронули только верхушку айсберга.
Физическая клавиатура является лишь одним из "большой тройки" компонентов, определяющих эргономику и скорость набора. Двумя другими, не менее важными, являются раскладка клавиатуры и раскладка горячих клавиш приложений, в первую очередь IDE. Оставаясь на QWERTY и точечных улучшениях хоткеев, вы обходите вниманием эти 2 оставшихся компонента.
Раскладка клавиатуры: каждый фанат альтернативной раскладки будет разумеется хвалить свою собственную, но думаю все они сойдутся на мысли, что с кверти надо бежать куда угодно, на любую раскладку, пусть она хоть как-то задумывается о базовых принципах эргономики набора (передвижение более частых букв на home row и под более сильные пальцы, hand alternation, finger rolling). Подойдёт буквально любая, от античного Dvorak до более новых альтернатив, таких как 3l и arensito.
Хоткеи IDE: Лидерами в эффективности хоткеев являются модальные редакторы и имитирующие их плагины для других приложений (Vimperator). Ну а разработка кастомной модальной раскладки для редактора, aka попытки упихнуть десятки модальных команд (forward/backward word/WORD/block/paragraph/..., операции с буфером, выделением итд) на удобные позиции в соответствии с их частотой, является задачей уровня epic.
По поводу QMK: я считаю, что программирование обработки нажатий клавиш на уровне железа, например QMK или хардварный ремаппинг, является проигрышной практикой в сравнении с софтверным конфигурированием (в тч программированием хоткеев в IDE), по следующим причинам:
Не универсально, требует клавиатуры со специальными возможностями и знания уникального в каждом случае средства настройки (QMK, механизм макросов и ремапа kinesis advantage, ...). Софтовое конфигурирование работает на любой клавиатуре и использует универсальные средства — конфигуратор раскладки вашей графической среды (XKB в X.org) и скриптовый язык IDE (если вы конфигурируете команду IDE).
Физическое расположение клавиш становится чёрным ящиком для софта. Задав аппаратный маппинг, вы не сможете например сгенерировать геометрическую картинку своей клавиатуры через xkbprint или измерить расстояние, преодолеваемое пальцами (travel distance) в какой-либо задаваемой программно задаче, не захардкоживая геометрию вашей раскладки.
Хардверная конфигурация проигрывает софтверной в гибкости и количестве возможностей. В случае железа ограничивающим фактором являются ограничения, вложенные в платформу, на которые вы никак повлиять не можете. В случае софта вы можете выбирать любой конфигуратор — XKB в Xorg, xcape, Autohotkey, скриптовый язык IDE, самописный обработчик.
Хардверный обработчик не знает ничего о контексте набираемых символов, плагин для IDE — знает.
Софтовый конфиг легче переносим между различными ПК, а в случае одного ПК позволяет разным пользователям иметь разные раскладки.
Я имел в виду именно "конкурента", а не "свою NIH реализацию display server". Конкурент должен: 1) иметь работающую реализацию хотя бы на десктопном линуксе (опционально на прочих свободных юниксах типа *bsd ит.д.) 2) поддерживаться хотя бы Gtk и Qt, иначе как же компилировать и запускать существующий GUI софт под этот новый чудо-графический сервер. В списке бэкендов Gtk и Qt под линукс никакой альтернативы X11 кроме Wayland и Mir пока не наблюдается.
— Привет, мы делаем приложение под весьма специфическую платформу, контролируемую гуглом, и под конкретный браузер, под редчайшую задачу, имеются сильные конкуренты. От вас потребуется оплата ТРЁХЛЕТНЕГО труда коллектива разработчиков фулл-тайм, а потом с итоговым продуктом сыграют в рулетку модераторы гугла, известные тем, что банят приложения по желанию левой пятки без права обжалования. Что же может пойти не так.
— Конечно, о чём речь, вот вам инвестиции
Вдогонку: а почему у вас на сайте нет кнопки прямой загрузки плагина как альтернативы chrome store, настолько смирились со стором?
Можно бесконечно смотреть на 3 вещи: огонь, воду и как fillpackart клепает статьи об инженерах, которые практикуют правильный подход к технологиям, но мир несовершенен и поэтому они страдают.
Вы ошибаетесь. Aurа лежит в стеке UI выше чем X/Wayland и использует корневое окно иксов, см. архитектурную схему. Можно спросить ТСа, я думаю в выхлопе top на скриншоте у него ниже имеется Xorg. Aura — конкурент например для Gtk+, но не для иксов. Сомневаюсь, что гугл вообще осилит такую титаническую работу как конкурент X Window, по вейланду можно примерно понять чего это стоит, это не новый WM написать, здесь куча стандартов (я посмотрю как они xkb перепишут например), протоколов, легаси софта.
Пользуюсь постоянно Toshiba Chromebook 2 как основной машиной (с полной заменой ChromeOS на обычный десктопный Linux), данный коммент пишу с него, в 2017 писал статью на хабр про свой хромбук, с тех пор ничего не поменялось, работает как часы. TL;DR машинка ещё слабее acer-а (2 Gb RAM, SoC Baytrail N2840 с 2-ядерным целероном), преднамеренно нищебродская (~170$) тк считаю что задача, требующая большой мощности ПК, как правило указывает на недостатки workflow а не на слабость железа. Программирование, почта, веб, медиафайлы, всё как у остальных.
Я считерил с экономией на доставке, попросив начальника (американца) привезти мне его, как только он поехал в командировку в Россию. :) Без этого доставка дорогая, в России хромбуков не водится.
Про хромОС: Кодеки являются большой проблемой. Многие фильмы и музыка стоковым плеером не открываются. Я так понимаю, гугл предполагает, что юзеры будут смотреть всё только на ютубе. Решается crouton'ом или что там сейчас для чрута/виртуализации появилось, и установкой нормального плеера в гостевой ОС, как у вас в статье написано, но это мягко говоря не уровень "домашнего пользователя", на коих ориентированы хромбуки.
Подозреваю что имеется проблема с домашними медиасерверами и сетевыми дисками. Хром ОС ориентирована на облака гугла, подключение к NFS/Samba и возможно DLNA в стоковой поставке отсутствует, не уверен например что модуль NFS оставили в ядре (ходят тут всякие умные, ставят гостевые линуксы и из них монтируют домашний сетевой диск).
Да, это так, Windows 10 в случае с UEFI/GPT слава богу просто добавляет свой бутлоадер на EFI system partition, не вредя уже имеющимся бутлоадерам (в теории, на практике слышал что она может затирать и чужие бутлоадеры на ESP).
Но старые машины с BIOS никуда не делись. Да и загрузочный список UEFI установщик Win10 модифицирует в своём типичном стиле — ставит себя на первое место в списке. Что вызывает некоторое недоумение у тех, кто использует GRUB+UEFI и после установки обнаруживает, что вместо граба по дефолту грузится винда. Хотя казалось бы, наличие GRUB это чёткое указание, что на этой машине он контролирует загрузку и надо бы не мешать человеку загрузиться по умолчанию в юникс и добавить винду через update-grub.
Молодцы, а теперь мб наконец научите установщик windows не затирать сторонний загрузчик?
В zsh с включенным multios.
С системными требованиями "2 Гб ОЗУ и 20 Гб HDD" как-то отучение от bloatware не задалось :-/
Для меня:
Возможность писать фронтенд и плагины на любом языке. Это отдельные приложения, сервер общается с ними на JSON-RPC, асинхронно. По сравнению с Vimscript и Emacs Lisp — просто небо и земля (хотя, справедливости ради, в Emacs есть API для динамической загрузки плагинов на C).
Быстродействие и снижение затрат по памяти — священная корова проекта. В документации прямым текстом требуется от разработчиков "любая базовая операция редактирования должна выполняться не больше 16ms". Куча оптимизированных структур данных (инкрементальные обновления кэша строк д. клиентов, оптимизированное хранение строк), всюду асинхронность.
Высокая модульность, отдельно сервер, отдельно клиент, отдельно language server, предпринимаются попытки выделить структурные компоненты редактора в отдельный SDK, на котором можно писать xi-подобные редакторы.
(Только для разработчиков IDE): редактор в начальной стадии разработки, можно попытаться реализовать мечту об идеальном редакторе. Проект известный, можно почесать эго и вписать своё имя в историю.
(Только для Rust разработчиков): Идеален для вкатывания в rust разработчику уровня сеньёра с опытом в других языках — многокомпонентный сложный продукт, даёт универсальные знания (обработка юникода, кэшей строк, асинхронное взаимодействие компонентов), куча как архитектурных задач так и деталей реализации. Отличная строчка в резюме.
Rust и Cargo со всеми их преимуществами.
Это так, редактор выстрелит только если реализует какие-то киллер-фичи для разработчиков которые будут в нём кодить, а для не разработчиков редакторов. Пока я слышал восторги только от вторых (которые на данный момент и являются основной аудиторией xi), из пользовательских фич пока демонстрировать нечего.
Хех, есть такое, Xi ещё ладно, это разработка с нуля, а вот тут Emacs переписывают на расте. А ещё на расте (не на шелле) написан rustup, инструмент разворачивания и управления toolchain'ами раста. Да, чтобы изменить его поведение, надо его перекомпилировать, что очень весело делать, если он не отработал до конца и rustc ещё нет в системе.)) За себя скажу, что мне подход "Rust всюду" не нравится, я при всей своей симпатии к Rust не применяю его без нужды. В любом случае, эта проблема к Xi не относится, я бы контрибутил в него даже если бы он был скажем на C/C++ а не на Rust, его фишка в архитектуре и структурах данных, а не в языке.
Это известная проблема, сервер (xi-core) страдает от нехватки внимания ключевых разработчиков, тк лидер проекта и ещё 1 ключевой разработчик сейчас заняты на платной основе другими проектами на Rust — runebender и druid. А разработка клиентов тормозится багами сервера и тем фактом что я уже упомянул — догнать известные редакторы/IDE по функциям это задача на годы.
VS Code не изолированный продукт. К примеру, он использует для синтактического анализа LSP (language server protocol), созданный Microsoft как раз для VS Code. Затем LSP стал открытым стандартом, продолжая оставаться под контролем MS, и вот тут уже MS во всей красе показала свою типичную тактику по отношению к открытым стандартам. LSP допускает широкую трактовку во многих местах, так что де-факто стандартом становится референсное поведение vscode, также "неудобные" жалобы на критические недостатки протокола порой просто-напросто игнорируются. В итоге у MS под контролем один из лидеров рынка программируемых редакторов, задающий стандарты, а бессмысленность форкания LSP или VS Code думаю объяснять не стоит.