С Vala пришлось бы разбираться и читать документацию, поскольку на Vala до сих пор не писал, ушло бы больше времени. Статья же родилась в ходе тестового задания, на которое мне давали неделю (дерево с ленивой подгрузкой данных). Я и так выбрал GTK 4 с расчётом написания статьи на Хабр, зная, что большая часть времени уйдёт на эксперименты, чтение документации и изучение существующих примеров (которых почти нет), поскольку до этого работал только с GTK 3. А так, да, с Vala код был бы читабельнее, хотя своего какого-либо мнения (плюсы/минусы) у меня по этому языку пока нет.
Оформление обычно в CSS задаётся (хотя для графических библиотек некоторая часть указывается в коде). В рамках окружения рабочего стола CSS для GTK задаётся темой оформления. Для разных устройств можно создавать разные темы оформления. На свой вкус можно менять уже существующие.
Можно было бы в одной теме всё задать, но в GTK не поддерживается @media. Нашёл тему об этом ещё 2016 года, там же объясняется, почему поддержку правила @media до сих пор не добавили в GTK: responsive design.
Чем же это может вредить? С таким же успехом навредить может кастомизация горячих клавиш. Мне не нравится F2 для переименовывания файлов, я её на другое действие переназначаю. Алиасы предназначены для катомизации терминала под себя, как будет удобно именно отдельному человеку. Из людей, с кем я работал, один взял мой вариант, а другой сделал себе свои, совсем другие, алиасы.
Что касается пересечений с названиями команд, то писать /bin/dd будет даже более хорошей практикой в скриптах, поскольку исключает пересечение с алиасами. Если часто требуется выполнять эту команду из консоли, то можно не прописывать автоматическое подключение алиасов в bashrc, а инициализировать их раз в день в рабочей консоли отдельной командой. Либо же подобрать другое название, например, dc (diff, color).
И если уж называете вредительсвом, то давайте расшифровку того, что имеете в виду, какие именно случаи, и какой вред в этих случаях алиасы могут нанести.
Поделиться существующей практикой и идеями. Я уже достаточно давно использую алиасы, они оказались намного удобнее, чем вводить команды целиком, причём именно в таком виде, легко запоминаются, нет никакой путаницы, действия доводятся до автоматизма. Собственно, основной моей деятельностью в консоли является работа с git.
Ну и в интернете список алиасов всегда под рукой. :)
dd используется или через sudo, или от имени суперпользователя. В обоих случаях алиасы работать перестают, поскольку прописаны у непривилегированного пользователя. На моей практике у меня не возникало проблем с существующими командами.
Если алиасы совпадают с командами, которые в норме не используются, то проблем нет. Именно поэтому я лишь про команду go упомянул.
С Vala пришлось бы разбираться и читать документацию, поскольку на Vala до сих пор не писал, ушло бы больше времени. Статья же родилась в ходе тестового задания, на которое мне давали неделю (дерево с ленивой подгрузкой данных). Я и так выбрал GTK 4 с расчётом написания статьи на Хабр, зная, что большая часть времени уйдёт на эксперименты, чтение документации и изучение существующих примеров (которых почти нет), поскольку до этого работал только с GTK 3. А так, да, с Vala код был бы читабельнее, хотя своего какого-либо мнения (плюсы/минусы) у меня по этому языку пока нет.
Оформление обычно в CSS задаётся (хотя для графических библиотек некоторая часть указывается в коде). В рамках окружения рабочего стола CSS для GTK задаётся темой оформления. Для разных устройств можно создавать разные темы оформления. На свой вкус можно менять уже существующие.
Можно было бы в одной теме всё задать, но в GTK не поддерживается
@media
. Нашёл тему об этом ещё 2016 года, там же объясняется, почему поддержку правила@media
до сих пор не добавили в GTK: responsive design.Большое спасибо за пояснение! Действительно. Этого момента не знал.
Чем же это может вредить? С таким же успехом навредить может кастомизация горячих клавиш. Мне не нравится F2 для переименовывания файлов, я её на другое действие переназначаю. Алиасы предназначены для катомизации терминала под себя, как будет удобно именно отдельному человеку. Из людей, с кем я работал, один взял мой вариант, а другой сделал себе свои, совсем другие, алиасы.
Что касается пересечений с названиями команд, то писать /bin/dd будет даже более хорошей практикой в скриптах, поскольку исключает пересечение с алиасами. Если часто требуется выполнять эту команду из консоли, то можно не прописывать автоматическое подключение алиасов в bashrc, а инициализировать их раз в день в рабочей консоли отдельной командой. Либо же подобрать другое название, например, dc (diff, color).
И если уж называете вредительсвом, то давайте расшифровку того, что имеете в виду, какие именно случаи, и какой вред в этих случаях алиасы могут нанести.
Поделиться существующей практикой и идеями. Я уже достаточно давно использую алиасы, они оказались намного удобнее, чем вводить команды целиком, причём именно в таком виде, легко запоминаются, нет никакой путаницы, действия доводятся до автоматизма. Собственно, основной моей деятельностью в консоли является работа с git.
Ну и в интернете список алиасов всегда под рукой. :)
dd используется или через sudo, или от имени суперпользователя. В обоих случаях алиасы работать перестают, поскольку прописаны у непривилегированного пользователя. На моей практике у меня не возникало проблем с существующими командами.
Если алиасы совпадают с командами, которые в норме не используются, то проблем нет. Именно поэтому я лишь про команду go упомянул.
Отразил данную информацию в статье.