рисовать блур, затухание и блендинг.
Или возложить на процессор?  

Смотреть время??? Б**ть, это не смотреть, это пялиться на время.
>Тут три момента: сенсорные экраны, CSD и просто удобство

Мух от котлет делить не учили? Какое б**ть удобство в огромных кнопках может быть??? Разве что тем, кто мышь держит двумя пальцами в раскарячку

Вообще-то, все это должно настраиваться. Если я работаю в полноэкранном режиме, зачем мне заголовок с меню и кнопками? Мне нужно меню, которое пулл-даун. Желательно открепляемое и несворачиваемое после открепления.
Пальцем я ничего не тыкаю -- на сей счет есть мышка и планшет, котороые делают все очень аккуратно.

Эм. Да вроде всегда был. Стандартный механизм XDG там используется нынче, как давно уже везде. Что в /etc/xdg/autostart или в ~/.config/autostart имеет метку "X-GNOME-Autostart-enabled=true" - автозапускается.

Хотите гуй к пользовательскому автозапуску - первая вкладка ("автозапуск") в gnome-tweak-tool. Пара кликов и ваш пиджин всегда запускается сам.

>>по феншую в gnome нельзя окна раскрывать на весь экран?
> f11?

Двойной клик по заголовку.. F11 это вроде только браузер и терминалы умеют.

Если приходилось, то чего я объясняю тогда, ты и сам понимаешь.

Это вы ещё Gradle не видели. ;) Обслуживающий сборку код - очевидно ради самого процесса написания обслуживающего кода и ничего больше. Это завораживает.

Вот-вот. Затем, что только компилятор знает, где <foo/bar.h> лежит. Затем, что файл может присутствовать и проглатываться препроцессором, но не самим компилятором или компоновщиком (например, потому что библиотека не установлена). И автотулсы, и симэйк не делают ничего сами, а только то что им сказано: проверить файл, проверить функцию, и т. п. Так что тут мимо. Не только незнание матчасти, но и непонимание целей и задач.

Вот это смешно было :)

Между прочим, я уважаю cmake, и пишу на нём аккуратно, но те задачи, которые должна решать система сборки, cmake делает не очень удобно. Например, глобальный файл config.h, выяснения в какой библиотеке находится некая функция, там нет аналога make distcheck.

И это работает? Ну, в том смысле, что между генерацией config.cache и следующим запуском ./configure произойдёт установка пакета, которая вообще-то может инвалидировать какие-то переменные в этом config.cache. Кстати да, я даже конкретный сценарий могу предложить. Ставим софтину с опциональной зависимостью от gtk. Её configure проверяет наличие gtk, не находит его в системе, вносит в config.cache запись о том, что gtk в системе нет. Ставим gtk. А теперь ставим софтину с жёсткой зависимостью от gtk. Теперь configure заглядывает в config.site, находит, что gtk в системе нету, и отказывается генерировать Makefile.

Другое дело, что может если собрать переменные, которые стопудов никогда не меняются (скажем, относящиеся к проверкам libc и cc) и один раз их сложить в config.site...

Кроме того, тут встаёт проблема, что если я в процессе пересборки системы занимаюсь вознёй с этими кешами, то я встраиваю в процесс пересборки ещё более тормозной этап, нежели ./configure -- себя. Таким образом, чтобы с этого получить хоть какой-нибудь бонус по скорости, надо это всё автоматизировать, а для этого надо лезть в портажи и перелопачивать eclass'ы. В идеальном случае будет достаточно изменить один eclass, но я не верю в идеальные случаи. Скорее всего придётся поменять несколько eclass'ов, и ещё процентов 10 ебилдов всё равно будут всё делать по-своему. То есть, здравый баланс между оптимизмом и пессимизмом предсказывает часов 40-80 на перепиливание портажей. _Моих_ 40-80 часов, а не сборочного кластера. Причём с неопределённым результатом: может быть не удастся сделать так, чтобы config.site не создавал бы помех, и не приходилось бы ещё и вручную периодически вмешиваться, чтобы сборка продолжалась бы.

Если я вожусь с командной строкой, то тормоза вносимые моими кривыми пальчиками и процессом мышления гораздо выше, чем тормоза ./configure. Это значит, что я только что сделал wget, потом tar jxf, вот сейчас делаю ./configure, потом буду делать make, потом искать способа потестировать работает ли без установки, потом решать, что делать с результатом -- вкатать в /usr/local при помощи make install, поставить в ~/local, поставить при помощи INSTALL_ROOT в /tmp, а потом вспоминать, читая man'ы и сорцы, как теперь всё это ebuild'ом раскатать в /usr, чтобы потом можно было бы удалить при помощи emerge... Короче эта история надолго. И в этой истории пара-тройка выполнений ./configure, пока я собираю все опции для него, которые я хотел бы ему передать, -- это вообще ни о чём.