Интервью о любимом инструменте легко превращается в список восторгов. Цена такой подачи — читатель переносит чужой рабочий сценарий на свою среду и получает неудобный интерфейс или неподходящий стек.
Сохраняю в материале разговор с Геральдом Нанном и технические детали Tilix, но выношу из него критерии, которые можно проверить самостоятельно. Интервью — источник опыта автора проекта, а не доказательство, что инструмент лучше любого другого терминала.
Что сохраняем из исходной заметки
Йоаким — интервьюер-резидент блога о D. Он также брал интервью у членов D-сообщества для This Week in D и ответственен за портирование LDC для Android.
Геральд Нанн — разработчик Tilix (ранее называвшийся Terminix).
Tilix— продвинутый тайлинговый эмулятор терминалов с открытым исходным кодом, который является самым «звёздным» проектом на основеD наGitHub, недавно даже обогнавший стандартный компилятор D, DMD. В этом году на DConf в Берлине он рассказывал о том, как использует D. Имеются слайды и видео. В своей повседневной работе, которая не имеет ничего общего с настольными графическими приложениями, он является старшим разработчиком промежуточных решений в Red Hat. Подробнее об истории Джеральда в [расширенном интервью— Ред.]
Йоаким: — Что такое тайлинговый эмулятор терминала?
Геральд:— Тайлинговый эмулятор терминала позволяет разделить терминал на несколько частей и распределить их в удобном порядке и месте, что наиболее удобно при работе над конкретной задачей. Люди, которые работают на нескольких терминалах одновременно, как правило, находят такие инструменты наиболее полезными, особенно с постоянно увеличивающимися размерами мониторов и разрешений.
CSD ссылается на заголовок окна, где не диспетчер дисплея, а пользователь берёт на себя ответственность за него и может заполнять панель заголовка кнопками и другими элементами управления. Это часть концепции Gnome HIG, и большинство приложений Gnome (gedit, файлы, видео) по умолчанию используют этот подход. Единственное исключением является gnome-terminal, который вообще не использует CSD.
Й.: — Можете привести несколько примеров того, как вы используете концепцию Gnome HIG?
Г.: — Gnome HIG определяет конкретный язык дизайна в отношении того, как приложения, работающие в Gnome, должны выглядеть и показывать себя. Некоторые примеры Tilix, следующие концепции HIG, включают использование CSD и меню приложений по рекомендациям, таким как интервалы, макеты и т.д. Кроме того, разработчики Gnome собрали множество макетов, как они думают, как должны выглядеть различные приложения. Tilix использует макеты, разработанные дизайнерами Gnome для терминала, где это возможно. Например, в Tilix диалог предпочтений и профилей использовался отдельно, однако один из дизайнеров Gnome предложил этот макет для gnome-терминала. Я пошел вперед и реализовал его в Tilix, гораздо лучше, чем раньше.
В результате использования CSD и концепции Gnome HIG, надеюсь, что использование Tilix в Gnome более органичено для пользователей.
Интересная вещь — это напряженность между людьми, которые используют Tilix на Gnome и тех, кто использует его в других дистрибутивах. Хотя я не имею никаких сомнений в том, что разработка под Gnome является моей основной целью, я стараюсь сделать Tilix лучше и в других средах рабочего стола, разрешив пользователю отключить CSD в пользу обычного заголовка, если они того пожелают.
Й.: — Вы попали в D из среды Java. Вы все еще пишете код в стиле Java на D? Это было легко, т.е. сколько вам пришлось привыкать, чтобы писать на D?
Г.: — Да, чаще всего работаю с Java. Я нашёл это довольно интересным на DConf, когда я спросил, как много людей пришли не из среды C/C++ , только один человек поднял руку.
Если вы посмотрите на мой код в Tilix, то он очень похож на Java-код. Некоторое из этого связано с моей обычное средой, в которой я работаю, а некоторое из-за того, что GtkD является оболочкой классов.
Я считаю, что переключение между D и Java является довольно плавным по большей части; между ними гораздо меньше когнитивного трения, чем, скажем, между переключением между Java и Python.
Самая важная идиома D, которую мне пришлось изучить, — это диапазоны, поскольку они являются основополагающей особенностью D. Однако это не было сильно сложным. Выполнение функций времени компиляции (CTFE) по-прежнему остаются для меня неестественными. Когда я использую их, мне приходится каждый раз искать про них информацию, и мои текущие попытки использования CTFE с точки зрения кода довольны глупы. Я хотел бы больше использовать CTFE в Tilix, поскольку я получаю всё больший опыт использования D.
Наконец, мой недостаток опыта работы с C выявляет другую проблему, с которой я немного борюсь — это взаимодействие с кодом на C. Хотя по большей части это довольно просто, но, когда мне приходится расшифровывать что-то сложное, оно становится не таким простым. Поддержка FlatPak (система изолированных контейнеров для графических приложений) в настоящее время есть, так как мне не приходилось так сильно напрягаться по некоторым вопросам, с которыми я сталкивался на C.
Сказав это, у меня есть некоторый опыт разработки собственного кода, поскольку много лет назад я потратил много времени на разработку кода на Delphi и Object Pascal. Именно на это и приходится большая часть моего опыта работы с графическим интерфейсом.
Й.: — И из вашего выступления на DConf вы явное не беспокоились о сборщике мусора (GC). Вам приходилось думать о нём, когда вы разрабатывали Tilix? Имелись ли проблемы задержек с GUI, вызванные GC?
Г.: — Придя из Java, GC для меня довольно естественен, и я определенно не считаю его плохим для D. Я думаю, что GC в D получает много плохой прессы на основе опыта Java, но важно помнить, что GC в D сильно отличается от того, что в Java. Самое большое различие для меня в том, что в D есть больше возможностей для его управления, так как он хорошо понимает, когда он может начать цикл GC. Я был очень рад видеть, как больше людей поднимают различные темы на reddit и форумах, жалуются на использование GC.
У меня не было никаких проблем с GC с точки зрения пауз, и ни один пользователь Tilix не сообщал об этом. У меня было несколько проблем, связанных с GC, в основном связанных с утечкой памяти из-за хранения ссылок, но все они были ошибками программного кода, а не проблемой с реализацией GC в D. У меня есть другое приложение на GTK D, Visual Grep, где я столкнулся с ужасающей эффективностью при обработке большого количества совпадений в tight-цикле (цикл, который содержит несколько инструкций и повторяется много раз.). Тем не менее, просто отключив GC для этого раздела кода, ускорилось все.
Й.: — Репозиторий github для Tilix замечательно чист, нет открытых запросов «pull request» (PR) и низкий процент проблем, которые все еще открыты. Сколько времени вы еженедельно тратите на Tilix? Является ли Tilix только хобби или он стал чем-то большим?
Механизм без лишних обещаний
Tilix решает конкретную задачу: разделяет терминальные сессии в одном окне и сохраняет рабочий контекст. Ценность появляется там, где человеку действительно нужно видеть несколько процессов рядом; при одной короткой команде тайлинг только добавляет интерфейс.
D в таком проекте важен не как рекламная метка, а как набор свойств реализации: нативный бинарник, доступ к GTK через библиотеку и автоматическое управление памятью. Эти свойства нужно сопоставлять с размером приложения, зависимостями платформы и способом доставки.
Любой отзыв из интервью следует превратить в проверку: открыть исходный код, собрать минимальную версию, проверить горячие клавиши и замерить время запуска в своей среде. Так личная история становится полезной инженерной гипотезой.
Минимальный воспроизводимый пример
Ниже — маленькая проверка, которую можно запустить или адаптировать в отдельном тестовом окружении. Значения демонстрационные; проектные идентификаторы, пути и версии нужно заменить своими и сохранить рядом с результатом.
# Проверка собственного сценария: два процесса и один лог
tilix --session ~/.config/tilix/sessions/debug.json
# В проекте D сначала фиксируем версию компилятора.
dmd --version
dub --version
# Затем собираем без изменения пользовательской системы.
dub build --build=debugМатрица диагностики
| Критерий | Что видно в интервью | Что проверить у себя |
|---|---|---|
| Рабочее окно | Несколько терминалов в одном layout | Сколько панелей реально нужно ежедневно |
| Интеграция | GTK и desktop-сценарий | Версия GTK и поведение на целевой ОС |
| Язык | D используется для приложения | Версия DMD/LDC, время сборки и зависимости |
| Сопровождение | Открытый проект и сообщество | Релизы, issue tracker и способ собрать пакет |
Порядок действий
- Описать один повторяемый сценарий: какие команды запускаются и что нужно видеть одновременно.
- Отделить свойства Tilix от свойств конкретной конфигурации автора интервью.
- Проверить версию приложения, GTK и компилятора в своей системе.
- Собрать маленький D-проект и измерить путь от исходников до запуска.
- Сравнить результат с привычным терминалом по времени и количеству ручных действий.
- Оставить инструмент, если он сокращает конкретную работу; не делать вывод по числу функций.
Ограничения и безопасный следующий шаг
Интервью датировано 2017 годом. Состояние репозитория, пакетов и платформ с тех пор менялось.
Опыт одного разработчика не является benchmark и не заменяет тестирование на целевой ОС.
Сборка с `dub` и `dmd` требует конкретных версий и системных библиотек.
После проверки должен остаться конкретный артефакт: вывод команды, тест, diff конфигурации или запись результата. Если его нет, формулировку нужно вернуть к симптому и не выдавать гипотезу за исправление.
Что записать в ревью
Короткая запись должна отвечать на четыре вопроса: какой вход использовали, какой результат увидели, какая граница была проверена и какое действие разрешено дальше. Такая форма полезнее длинного вывода «всё работает»: другой инженер сможет повторить проверку и понять, где заканчивается пример.
Если результат зависит от версии Windows, PHP, Bitrix, D или браузера, версию фиксируем рядом с командой. Если проверка не охватывает сеть, production или реальные пользовательские данные, это ограничение пишем прямо. Тогда следующий шаг расширяет evidence, а не расширяет обещание.
Проверяемые источники
- Tilix: исходный код — проверяет актуальную структуру и инструкции сборки
- D language: спецификация — фиксирует правила языка, а не личные оценки инструмента
- D: automatic memory management — помогает проверить тезисы об управлении памятью