https://www.opennet.ru/openforum/vsluhforumID3/112573.html Сформирован (https://blog.gtk.org/2017/10/23/gtk-3-92/) очередной тестовый выпуск будущего стабильного релиза GTK+ 4. Ветка GTK+ 4 развивается в рамках нового процесса разработки, который пытается предоставить разработчикам приложений стабильный и поддерживаемый в течение нескольких лет API, который можно использовать не опасаясь, что каждые полгода придётся переделывать приложение из-за изменения API в очередной ветке GTK+. До полной стабилизации GTK+ 4, приложения, предлагаемые для пользователей, рекомендуется продолжить собирать с использованием ветки GTK+ 3.22, которая будет поддерживаться три года.<br><br><br><br>Основные изменения (ftp://ftp.gnome.org/pub/gnome/sources/gtk+/3.92/gtk+-3.92.1.news) в GTK+ 3.92.1:<br><br><br><br>- Прекращение поддержки сборочной системы на базе autotools в пользу инструментария Meson (https://www.opennet.ru/opennews/art.shtml?num=47031);<br><br>- Поддержка управления шрифтами через CSS-свойство font-variant (https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant);<br><br><br><br>- В GtkEntr https://www.opennet.ru/openforum/vsluhforumID3/112573.html#165 Thu, 26 Oct 2017 07:34:48 GMT &gt;&gt; У меня своя система сборки. На все правки, включая написание программ для <br>&gt;&gt; сборки и обработки config.cache ушло 3-4 часа.<br>&gt; Поддержание своей системы сборки будет требовать гораздо больше времени.<br><br>На самом деле - не факт. Все зависит от задач. Если вы постоянно (ежедневно) меняете набор приложений - то да, лучше использовать готовый дистрибутив. Если набор приложений относительно стабилен - то затраты по времени не большие.<br><br>Вы хорошо озвучили проблемы gentoo:<br><br>1. Глубокая модификация требует больших затрат по времени.<br>40-80 часов для задачи, которая в моем случае отняла 3-4 часа (да и то, если бы я сам не писал программы для этой задачи, то правки/тест сборочной системы отняли бы менее 30 минут).<br><br>У меня в год на систему уходит 40-80 часов, да и то, только если я провожу эксперименты вроде обсуждаемого.<br><br>2. Поддержка своих изменений. Чем их больше, тем сложнее поддерживать. В итоге от них приходится отказываться.<br><br>У меня есть похожая проблема, но на другом уровне: я часто модифицирую соф https://www.opennet.ru/openforum/vsluhforumID3/112573.html#164 Thu, 26 Oct 2017 00:05:55 GMT &gt; У меня своя система сборки. На все правки, включая написание программ для <br>&gt; сборки и обработки config.cache ушло 3-4 часа.<br><br>Поддержание своей системы сборки будет требовать гораздо больше времени. Все эти задачи связанные с обсчётом депендансов, выкачиванием сорцов нужных версий из нужных мест по нужным протоколам, обходом всех специальных случаев... В gentoo это решается написанием ебилда на каждый пакет. Но, вот, допустим, я пользуюсь оверлеем rust, чтобы иметь в системе расты разных версий, причём хоть самых-самых nightly. Иногда это требует правки ебилдов. Но мне приходилось отказываться от внесения каких-то изменений, потому что это были изменения, которые не примут в "апстрим", а самостоятельно поддерживать эти изменения я не готов совершенно. Внести и отправить пулл-реквест -- легко: поигрался с ebuild, выполняя работу emerge поэтапно, создал патч, оттестил его, отправил и забыл. А вот следить за актуальностью моего форка оверлея -- не, спасибо, вот заняться мне больше нечем. Если что, я могу и по https://www.opennet.ru/openforum/vsluhforumID3/112573.html#163 Wed, 25 Oct 2017 18:46:15 GMT Тогда почему, уведомления показываются маленьким круглешком? почему не мигает, тебе пришло уведомление,а в это время ты отвелекся, и всё, хз что тебе пришло, я вообщевообще не замечал этого маленького кружочка, и получается постоянно смотришь, нет ли у тебя уведомления, а не работаешь. https://ibb.co/dhB6am<br> https://www.opennet.ru/openforum/vsluhforumID3/112573.html#162 Wed, 25 Oct 2017 18:44:33 GMT &gt;&gt; Сделал программу, которая собирает config.cache после сборки. Потом запускаю вторую программу, которая анализирует все имеющиеся config.cache и создает config.site, в который попадают только те переменные, которые имеют одно и тоже значение во всех config.cache.<br>&gt; И это работает?<br><br>Собираем всю систему и попутно собираем все config.cache. Генерируем config.site. Повторная сборка системы будет гораздо быстрее.<br><br>Но да, все это можно легко сломать.<br><br>&gt; Другое дело, что может если собрать переменные, которые стопудов никогда не меняются <br>&gt; (скажем, относящиеся к проверкам libc и cc) и один раз их <br>&gt; сложить в config.site...<br><br>Таких переменных не так уж и много. Выигрыш будет не большой.<br><br>Тут нужна методика четко позволяющая отделить переменные и константы для конкретно вашей системы. Есть у меня мысль попробовать исключить все переменные, которые используются менее трех раз.<br><br>Но в итоге и встает вопрос, а стоит ли оно того?<br><br>&gt; Таким образом, чтобы с этого получить хоть какой-нибудь бонус по скорос https://www.opennet.ru/openforum/vsluhforumID3/112573.html#161 Wed, 25 Oct 2017 17:14:43 GMT &gt;&gt; Весь этот вывод configure уже заучен наизусть, я его сам могу на клавиатуре набрать с закрытыми глазами, ан нет, автотулзы продолжают долбить в одну и ту же точку.<br>&gt; Во-первых, у configure есть кеш, см. (./configure --help); во-вторых, даже если автор <br>&gt; не предусмотрел (--enable-foo/--with-bar), любую закорюку/переменную можно переопределить <br>&gt; в командной строке, так что configure будет думать, что проверка сделана <br>&gt; и результат взят из кэша. Например, моэно убедить configure, что заголовок <br>&gt; sys/wtf.h существует, и т. д.<br><br>Если я вожусь с командной строкой, то тормоза вносимые моими кривыми пальчиками и процессом мышления гораздо выше, чем тормоза ./configure. Это значит, что я только что сделал wget, потом tar jxf, вот сейчас делаю ./configure, потом буду делать make, потом искать способа потестировать работает ли без установки, потом решать, что делать с результатом -- вкатать в /usr/local при помощи make install, поставить в ~/local, поставить при помощи INSTALL_ROOT в /tmp, а потом вспоминать https://www.opennet.ru/openforum/vsluhforumID3/112573.html#160 Wed, 25 Oct 2017 16:38:41 GMT Раскройте макрос GTK_LABEL(label), будете удивлены. :) Там встроено самотестирование. Выполняется функция g_type_check_instance:<br>https://github.com/GNOME/glib/blob/master/gobject/gtype.h<br>https://github.com/GNOME/glib/blob/master/gobject/gtype.c<br><br>Можно, конечно делать явное приведение типов, но самотестирование имеет свои плюсы. Тем более, что грамотный подход позволяет снизить до минимум накладные расходы. Ну и стараемся соблюдать стилистику GTK.<br> https://www.opennet.ru/openforum/vsluhforumID3/112573.html#159 Wed, 25 Oct 2017 16:35:50 GMT &gt; Сделал программу, которая собирает config.cache после сборки. Потом запускаю вторую программу, которая анализирует все имеющиеся config.cache и создает config.site, в который попадают только те переменные, которые имеют одно и тоже значение во всех config.cache.<br><br>И это работает? Ну, в том смысле, что между генерацией config.cache и следующим запуском ./configure произойдёт установка пакета, которая вообще-то может инвалидировать какие-то переменные в этом config.cache. Кстати да, я даже конкретный сценарий могу предложить. Ставим софтину с опциональной зависимостью от gtk. Её configure проверяет наличие gtk, не находит его в системе, вносит в config.cache запись о том, что gtk в системе нет. Ставим gtk. А теперь ставим софтину с жёсткой зависимостью от gtk. Теперь configure заглядывает в config.site, находит, что gtk в системе нету, и отказывается генерировать Makefile.<br><br>Другое дело, что может если собрать переменные, которые стопудов никогда не меняются (скажем, относящиеся к проверкам libc и cc) и один https://www.opennet.ru/openforum/vsluhforumID3/112573.html#158 Wed, 25 Oct 2017 15:42:49 GMT &gt; Мух от котлет делить не учили? Какое б**ть удобство в огромных кнопках <br>&gt; может быть??? Разве что тем, кто мышь держит двумя пальцами в раскарячку <br><br>Ты живешь на другой планете и планшеты туда не завезли? Ребят, соберите несчастным аборигенам транспортник.<br> https://www.opennet.ru/openforum/vsluhforumID3/112573.html#157 Wed, 25 Oct 2017 14:41:21 GMT &gt; Вообще не понимаю что такое "апгрейды" и зачем они нужны. Это какой-то <br>&gt; упоризм - купить дешевое гогно, через год его продать за треть <br>&gt; цены в лучшем случае, купить другое дешевое гогно, чуть получше, goto <br>&gt; 1.<br><br>Я описывал выше два примера стратегий поддержания железа в актуальном состоянии. Либо менять каждые два три года, либо не менять, но поддерживать в актуальном состоянии. Ничего не надо продавать. Не, ну бывает конечно, если меняешь процессор, то старый можно и продать, если кто купит. Но процессор далеко не всегда самое узкое место. Такие задачи, как покупки SSD, жёстких дисков, планок оперативки не требуют замены, они аддитивно вставляются в существующую систему.<br><br>&gt; Я в 14-м году собрал себе домой систему на Asus <br>&gt; Rampage 4, i7-3970X, 64Gb мозгов и NVidia Titan X 6Gb. Стоило <br>&gt; все это ~200k, но даже сейчас оно лучше многого того, что <br>&gt; продают как новое.<br><br>Главное купить мать, которую можно потом постепенно обвешивать всякими приблудами. Чё делать с видеокартами я не знаю, но у ме