Опубликованы результаты голосования среди гномеров по поводу DVCS

>> Не тормозно, тут другое: задача качественно отличается от задачи "установить атрибут такой-то в такое-то значение".
> Посмотрите как меняют тулбары. Не вижу проблемы поменять место виджета в иерархии и перерисовать.
С тулбарами то же самое: установить атрибут "показывать картинко" в нужное значение. Операций с деревом виджетов там нет.
Ну так обновляется расположение кнопок в гимпе при смене button-order или нет?

>> Чтобы хранить там данные сессии. Или придётся в процедурном стиле таскать их с собой.
> Как мне кажется, dbus для этого не предназначали... Это ж не EJB какие-нибудь;)
Попробуй теперь это среднестатистическому разработчику объяснить. То нельзя, это нельзя... Зато dbus имеет наглость называться "simple" и инбуцирует объектную систему безо всякой нужды в этом.

> установить атрибут "показывать картинко" в нужное значение
Там еще можно менять взаимное расположение текста и картинки. Что геометрически приводит к перерасчету раскладки. Да, это в рамках одного виджета.

> Операций с деревом виджетов там нет.
Это правда. Но я по-прежнему не вижу тут нечеловеческой проблемы. Операция-то на дереве - простейшая.

> Ну так обновляется расположение кнопок в гимпе при смене button-order или нет?
Гхм. А разве есть такой флажок в gconf? Я даж не знал, чесс слово!

> Попробуй теперь это среднестатистическому разработчику объяснить.
Лихко. Пишется cookbook с проверенными стратегиями использования. А все, что вне оного - рассматривается индивидуально, вопрос удачливости;)

> инбуцирует объектную систему безо всякой нужды в этом.
Почему без нужды? Объектность нужна всегда!

>> Вроде бы tk на винде (в classic теме) вообще неотличим от рочих приложений.
> Не знаю, мне пришлось как-то смотреть на ткаббер под виндой (только он позволял обходить местную проксю), я весь исплевался от интерфейса.
Интерфейс у него и мне не нравится (psi user). Но речь-то шла про "щревты".

>> Стратификация коммьюнити, так сказать.
> У этой палки два конца. Да, распыление. Но вместе с тем - конкуренция, кросс-обогащение идеями.
Хоть одну идею со стороны K в fd.o назовёшь?

>> Но изобретение велосипедов под флагом унификации положение не улучшит.
> Надо же на чем-то ездить. Карета прошлого из существующих стандартов - не вмещает.
Ррррр. Надоела аргументация в стиле "это не поддерживается гномом, значит оно неправильное".

>> Но нам же нужен удобный красивый юникс с сетевой прозрачностью, не так ли?
> Желательно. Поэтому кроме gconf есть xsettings.
То есть внезапно настройки внешнего вида стали отделяться от настроек функциональности? Славненько, авось так и до понимания арихитектуры иксов дойдём.

> Но 100 прозрачности быть не может - потому что от клиентской системы зависит очень многое. В частности, на разных клиентах могут быть разные шрифты (или Вы еще не простились с идеей серверного рендеринга?)
Шрифты на клиенте --- зло, ломающее арихитектуру. Этот тезис никуда не делся и не денется.
Поведение "указанный шрифт отсутствует на клиенте, потому откатываемся на дефолтный" проблем при программировании не вызывает абсолютно никаких.

>> установить атрибут "показывать картинко" в нужное значение
> Там еще можно менять взаимное расположение текста и картинки. Что геометрически приводит к перерасчету раскладки. Да, это в рамках одного виджета.
Это делается в рамках одного виджета.

>> Операций с деревом виджетов там нет.
> Это правда. Но я по-прежнему не вижу тут нечеловеческой проблемы. Операция-то на дереве - простейшая.
Она реализована или как?

>> Ну так обновляется расположение кнопок в гимпе при смене button-order или нет?
> Гхм. А разве есть такой флажок в gconf? Я даж не знал, чесс слово!
В gtkrc есть. Если его нет в gconf, то это ещё один аргумент в пользу того, что сложные действия не поддерживаются из-за трудностей с реализайией.

>> Попробуй теперь это среднестатистическому разработчику объяснить.
> Лихко. Пишется cookbook с проверенными стратегиями использования. А все, что вне оного - рассматривается индивидуально, вопрос удачливости;)
"Шаг влево, шаг вправо --- расстрел". Ну-ну, ждите хорошего софта по таким руководствам...

>> инбуцирует объектную систему безо всякой нужды в этом.
> Почему без нужды? Объектность нужна всегда!
У тебя мозг отравлен явой.

> Но речь-то шла про "щревты".
Про шрифты не помню, честно говоря. Помню общее ощущение заколдобежа.

> Хоть одну идею со стороны K в fd.o назовёшь?
Не назову, специально не следил. Но разработчики всех трех офисов общаются друг с другом довольно плотно.

> Ррррр. Надоела аргументация в стиле "это не поддерживается гномом, значит оно неправильное".
Ошибка. В данном случае аргументация в стиле "этого недостаточно для гнома, значит оно неправильное".

> То есть внезапно настройки внешнего вида стали отделяться от настроек функциональности?
Не так. Настройки внешнего вида - частный случай настроек. Их хранение в xsettings - костыль для обеспечения единства внешнего вида с сохранением сетевой прозрачности. Но первичное хранилище настроек - gconf.

> Этот тезис никуда не делся и не денется.
Этот тезис мертв уже несколько лет. Если какая-то архитектура без него ломается - значит, нужно было ее сломать. Красивого рендеринга шрифтов на сервере не добиться. Вот этот тезис действительно никуда не делся, и он продолжает рулить мейнстримом.

> Она реализована или как?
Не знаю, не проверял.

> то это ещё один аргумент в пользу того, что сложные действия не поддерживаются из-за трудностей с реализайией.
Не так. Базовые настройки gtk, увы, приходится хранить в файлах, без gconf. Мне кажется, это не совсем правильно (хотя за этим есть логика) - но оно именно так на сегодня.

> У тебя мозг отравлен явой.
У каждого своя отрава.

>> Ррррр. Надоела аргументация в стиле "это не поддерживается гномом, значит оно неправильное".
> Ошибка. В данном случае аргументация в стиле "этого недостаточно для гнома, значит оно неправильное".
"Разработчики гнома не читали книжек, потому не уживаются с хорошо продуманными интерфейсами"

>> То есть внезапно настройки внешнего вида стали отделяться от настроек функциональности?
> Не так. Настройки внешнего вида - частный случай настроек. Их хранение в xsettings - костыль для обеспечения единства внешнего вида с сохранением сетевой прозрачности. Но первичное хранилище настроек - gconf.
Шило-мочало, начинай сначала.
Use case настроек на стороне сервера озвучен? Озвучен. Им пользуются? Пользуются. В архитектуре иксов он предусмотрен? Предусмотрен. В гноме про него не подумали? Не подумали. Вывод: костыль.
Я хренею от такой логики.

>> Этот тезис никуда не делся и не денется.
> Этот тезис мертв уже несколько лет. Если какая-то архитектура без него ломается - значит, нужно было ее сломать. Красивого рендеринга шрифтов на сервере не добиться. Вот этот тезис действительно никуда не делся, и он продолжает рулить мейнстримом.
Я, кстати, обоснования этого подхода, иного нежели "мы тут потестировали на одной машине и разницы в производительности не заметили" не встречал.

>> Она реализована или как?
> Не знаю, не проверял.
>> то это ещё один аргумент в пользу того, что сложные действия не поддерживаются из-за трудностей с реализайией.
> Не так. Базовые настройки gtk, увы, приходится хранить в файлах, без gconf. Мне кажется, это не совсем правильно (хотя за этим есть логика) - но оно именно так на сегодня.
Круто. Ломаем работающее ради поддержки ненаписанного.

Безотносительно флейма: каковы шансы у проекта спецификации (допустим, xdg file dialogs) за авторством обычного лоровского тролля быть хотя бы рассмотренным?

> "Разработчики гнома не читали книжек, потому не уживаются с хорошо продуманными интерфейсами"
Ага. И критикуют на первой странице своего нового стандарта старый стандарт, которого не читали. Вот неучи!

> В гноме про него не подумали?
Подумали. Нашли проблемы. Придумали свой, лишенный этих проблем. То, что Вы их не считаете проблемами - это Ваше дело.
Слово "костыль", конечно, преувеличение с МОЕЙ (не гнома) стороны, в пылу спора...

> Я, кстати, обоснования этого подхода, иного нежели "мы тут потестировали на одной машине и разницы в производительности не заметили" не встречал.
Обоснование производительности - в сущности, пофиг. Для меня в этом решении первична эстетика.

> каковы шансы у проекта спецификации (допустим, xdg file dialogs) за авторством обычного лоровского тролля быть хотя бы рассмотренным?
Честно скажу - не знаю. Зависит, думаю, от способа подачи. Сто китайских поклонов местным бонзам - и шансы могут возрасти до реалистичных;)

>> "Разработчики гнома не читали книжек, потому не уживаются с хорошо продуманными интерфейсами"
> Ага. И критикуют на первой странице своего нового стандарта старый стандарт, которого не читали. Вот неучи!
Ругать строку как универсальное хранилище _любых_ данных на платформе unix --- полнейшее головотяпство и непрофессионализм.

>> В гноме про него не подумали?
> Подумали. Нашли проблемы. Придумали свой, лишенный этих проблем. То, что Вы их не считаете проблемами - это Ваше дело.
Придумали свой, несовместимый и с другими проблемами.

>> Я, кстати, обоснования этого подхода, иного нежели "мы тут потестировали на одной машине и разницы в производительности не заметили" не встречал.
> Обоснование производительности - в сущности, пофиг. Для меня в этом решении первична эстетика.
Ладно, обоснования того, что эстетика поменяется, если рисовать через xft на стороне сервера, я тоже не видел. ы?

>> каковы шансы у проекта спецификации (допустим, xdg file dialogs) за авторством обычного лоровского тролля быть хотя бы рассмотренным?
> Честно скажу - не знаю. Зависит, думаю, от способа подачи. Сто китайских поклонов местным бонзам - и шансы могут возрасти до реалистичных;)
Кому делать два раза "ку" по завершению написания?

вот это, Господа, Вы и зажгли... браво! глядя на такие аргументы наконец-то пришло просветление и осознание, почему Ешка свои конфиги хранит в бинарном виде (eet) - шаг навстречу друг-другу приверженцы мейнстрим тулкитов не сделают никогда. также пришло понимание, почему гуй в Ешке полностью независим - это из-за всех тех, кто не в состоянии согласовать форматы (посему надо иметь возможность в копьё содрать любой интерфейс).

заодно вместо болтовни сделал очередную тему для ETK/E17:
http://sda.scwlab.com/2be.html
всё (практически) рисует канва самостоятельно, что позволит в будущем (возможно) на основе подобных тем делать "мостики" к мордам других тулкитов.

спасибо за скрин "ириски" - класс, ностальгировал, душа рвалась запустить старый "чпукс", но куда-то его дели из кладовки в моё отсутствие.

и есть махонькая просьба. где почитать о формировании gtk+ тем с примерами? сейчас нужно допустим поднять текст в кнопках вверх на 2 пикселя и/или кнопки/выделение_элемента_выпадающего_списка вниз опустить на те же 2 пикселя. в entry полях то же самое (вверху слишком много свободного места).

спасибо.

P.S. в целом же полностью поддерживаю и согласен с товарищем gaa в данной дискуссии. пока не будет чего-то, аналогичного Cocoa/Carbon - все DE могут пройти(c) со своими представлениями о прекрасном. поэтому эффективная работа и DE (в нонешней ипостаси) есть вещи не совместимые (imho конечно же).

> почему Ешка свои конфиги хранит в бинарном виде (eet)

И эти книжек по юниксу не читали...

> пока не будет чего-то, аналогичного Cocoa/Carbon - все DE могут пройти(c) со своими представлениями о прекрасном. поэтому эффективная работа и DE (в нонешней ипостаси) есть вещи не совместимые (imho конечно же).

Хоть ты и пишешь, что согласен, а ничего не понял. Фреймворки в таком виде не нужны. А уж тем более не нужна "платформа" на базе glib/gtk, которую всеми правдами и неправдами хотят пропихнуть гномеры.

> Красивого рендеринга шрифтов на сервере не добиться.

Мощное заявление, но бездоказательное.

>> И эти книжек по юниксу не читали...
скорость, Господа, скорость...

>> Хоть ты и пишешь, что согласен, а ничего не понял.
куда уж мне..

>> Фреймворки в таком виде не нужны.
об этом и пишу.

>> А уж тем более не нужна "платформа" на базе glib/gtk...
ясен пень, ибо все резко и дружно должны выучить чистый сишник и допилить EFL/Ешку. в результате все выиграют, ибо канва/evas модульна. хотите модулёк к gconf - пжалста, xsettings - легко и т.п..

>> И эти книжек по юниксу не читали...
>скорость, Господа, скорость...

30 лет назад скорости хватало, а сегодня не хватает?

<geek>И причём тут таки скорость Господа?</geek>

>> А уж тем более не нужна "платформа" на базе glib/gtk...
> ясен пень, ибо все резко и дружно должны выучить чистый сишник и допилить EFL/Ешку. в результате все выиграют, ибо канва/evas модульна. хотите модулёк к gconf - пжалста, xsettings - легко и т.п..

Вот он, звериный оскал фанатика! Каждый хочет перетянуть одеяло на свою сторону.

> Ругать строку как универсальное хранилище _любых_ данных на платформе unix --- полнейшее головотяпство и непрофессионализм.
Кто ж ругает строку? xsettings - это тоже строка. Но изобретать хреново структурированное хранилище из одной строки там, где можно аккуратно разложить по нескольким строкам (найди хоть одну техническую причину так не делать, кроме совместимости) - глупо!

> и с другими проблемами.
Проблем кроме совместимости я не вижу.

> Ладно, обоснования того, что эстетика поменяется, если рисовать через xft на стороне сервера, я тоже не видел. ы?
мы ж вроде договорились, что xft возможен только на клиенте??? Эстетика поменяется, потому что клиенту доступна ВСЯ информация о структуре картинки, он ее генерирует целиком, до последнего пикселя. В случае же рендеринга на сервере, сервер не знает до конца, чего хочет клиент - а клиент не знает, как именно будут выглядеть шрифты на сервере. Только примерно, в виде метрик.

>почему Ешка свои конфиги хранит в бинарном виде (eet)

потому же, почему в быдлоёшке весь гуй в одном процессе (даже WM!!!), desktop-файлы вновь созданных элементов меню называются _new_app-%d.desktop, а в самих desktop-файлах юзаются собственные велосипеды: потому что её авторы -- чёртовы латентные вантузятники, которые про unix-way никогда не слышали и которые думают, что кроме их нинаглядной ёшки на этом свете больше ничего не существует.

этому быдлу даже в голову не приходит, что многие любят комбинировать wm, панель, файлменеджер и пр. из разных сред и они могут захотеть запускать efm в своём любимом xfce. им не приходит в голову, что кто-то может пользоваться другим файлменеджером или консолью, и этого кто-то совсем не прикалывает разбирать, какой именно из десятка _new_app - нужный. а за бинарные конфиги в никсах нужно вообще отрывать йайца.. >:[

>> 30 лет назад скорости хватало, а сегодня не хватает?
нет предела совершенству...

>> Вот он, звериный оскал фанатика! Каждый хочет перетянуть одеяло на свою сторону.
увольте, просто немного стёба и собственно далеко не новая мысль, что возможно, концепт EFL более удобен для построения пресловутого десктопа для пользователя.

утрирую конечно. просто очень приятно видеть новые лица в команде девелоперов, особенно лица своих соотечественников.

>ясен пень, ибо все резко и дружно должны выучить чистый сишник и допилить EFL/Ешку.

предлагаю перенести enlightenment на windows7 и сделать там дефолтной оболочкой. всё-равно он идеологически ближе к венде (там как-раз в целях скорости любят всё делать монолитным и бинарным), к использованию одновременно с другими оболочками не приспособлен, свистелок больше, чем полезных фич, разрабов опять же прибавиться. а уж что будет с вантузятниками при виде пульсирующих кнопок и анимированных обоев.. :)

>> предлагаю перенести enlightenment на windows7 и сделать там дефолтной оболочкой.
было бы неплохо кстати. пока порт в cygwin худо-бедно скомпилить и запустить можно (сам не пробовал, но патчи смотрел - вполне адекватные).

что насчёт подъёма текста в gtk+ на пару пикселей? миссион импоссибль?

Как-то хитро разговор с git увели.

По мне так запутанная и непонятная штуковина (по сравнению с SVN). Возможно, я не почувствовал её прелестей.

git требует некоторых усилий по изучению. Советую почитать git community book[http://book.git-scm.com/]

> Как-то хитро разговор с git увели.

> По мне так запутанная и непонятная штуковина (по сравнению с SVN).

Да и пор сравнению с Mercurial - просто ненужные сложности :)

>> Ругать строку как универсальное хранилище _любых_ данных на платформе unix --- полнейшее головотяпство и непрофессионализм.
> Кто ж ругает строку? xsettings - это тоже строка. Но изобретать хреново структурированное хранилище из одной строки там, где можно аккуратно разложить по нескольким строкам
Зачем? Это нужно _только_ для ненужных приблуд типа gconfeditor. Название сеттинга индуцирует его тип и действие, которое надо с ним произвести.

> (найди хоть одну техническую причину так не делать, кроме совместимости) - глупо!
Совместимость и прозрачность всего и вся --- главная причина, почему unix до сих пор на плаву. А не намеренно запутанные велосипеды.

>> Ладно, обоснования того, что эстетика поменяется, если рисовать через xft на стороне сервера, я тоже не видел. ы?
> мы ж вроде договорились, что xft возможен только на клиенте???
Офигенно строгое техническое обоснование. По силам сравнимо разве что с "это так, потому что я так сказал".

> Эстетика поменяется, потому что клиенту доступна ВСЯ информация о структуре картинки, он ее генерирует целиком, до последнего пикселя. В случае же рендеринга на сервере, сервер не знает до конца, чего хочет клиент - а клиент не знает, как именно будут выглядеть шрифты на сервере. Только примерно, в виде метрик.
Список информации о структуре картинки, которая _не_ может быть получена с сервера в студию.

Чем именно git так сложнее Mercurial? SHA1 в голове не укладываются?

> Зачем?
Для удобства программиста.

> Это нужно _только_ для ненужных приблуд типа gconfeditor.
Во-первых, gconf тут не при чем, во вторых подобные тулзы нужны. Пользователь хочет удобных твикалок.

> Название сеттинга индуцирует его тип и действие, которое надо с ним произвести.
Мысль не отпарсил.

> Совместимость и прозрачность всего и вся --- главная причина, почему unix до сих пор на плаву.
Это одна сторона. А вторая - священная корова совместимости часто тянет на дно, поэтому иногда надо на ее забивать болт. Да, старые приложения по-прежнему идут под иксами, xlibc пока жив, по сети запускать приложения можно (протокол не меняли). Вот и хватит совместимости.

> Список информации о структуре картинки, которая _не_ может быть получена с сервера в студию.
Может - любая. Но нафига городить этот идиотский огород, гонять практически полное описание шрифтов на клиент, загружая и клиент и сервер (для этого еще небось и отдельное расширение в протокол запихивать придется)? Проще клиенту сгенерить полную битмапку - для этого надо только знать очень небольшой набор параметров сервера. Единственный резон серверного рендеринга - унификация внешнего вида прикладух с разных клиентов. Но, как было уже отмечено, этот use case на сегодня для разработчиков юниксовых десктопов является низкоприоритетным (конечно, приоритет не равен нулю, но...)

> является низкоприоритетным
Тем более что проблема прекрасно решается унификацией баз шрифтов на клиентах, с дублированием или сетевыми дисками. Низкий приоритет + возможность решить другим способом = забить болт.

> Чем именно git так сложнее Mercurial?

В нем куча ненужных возможностей.

> SHA1 в голове не укладываются?

Зачем их вообще туда укладывать? Локальные номера ревизий рулят.

> сетевыми дисками

Аааааа вендузятнеги фчяти!!!!111

Не пробовал Mercurial, но каждая встреча с git - сплошная головная боль. Вот сейчас пытаюсь решить минимальными движениями простую задачу "забрать один коммит из совершенно чужого репо".

> Да и пор сравнению с Mercurial - просто ненужные сложности :)
кстати да, пользуем именно Mercurial для локадьных проектов. намного проще в освоении imho.

> В нем куча ненужных возможностей.

мда, все ясно

> Вот сейчас пытаюсь решить минимальными движениями простую задачу "забрать один коммит из совершенно чужого репо".

git checkout нужную ветку себе в репо, и git cherry-pick, куда уж проще?

>> Зачем?
> Для удобства программиста.
Программисту конкретной программы всё равно, каким образом обращаться к данным, типизированно или нет. Приделывание же типизации к самому хранилищу никак с автором конкретной программы не связано.

>> Это нужно _только_ для ненужных приблуд типа gconfeditor.
> Во-первых, gconf тут не при чем, во вторых подобные тулзы нужны. Пользователь хочет удобных твикалок.

Нет. Это не штатный режим работы, предназначенный для "advanced" юзеров. А адванцед юзер совершенно не расклеивается от редактирования файла в текстовом редакторе.

>> Название сеттинга индуцирует его тип и действие, которое надо с ним произвести.
> Мысль не отпарсил.
Плохо. Для не умеющих парсить текст: если я работаю с ресурсом background, я всегда знаю, что там лежит _цвет_ и знаю, что это _цвет_ фона. Доходчиво?

>> Совместимость и прозрачность всего и вся --- главная причина, почему unix до сих пор на плаву.
> Это одна сторона. А вторая - священная корова совместимости часто тянет на дно, поэтому иногда надо на ее забивать болт. Да, старые приложения по-прежнему идут под иксами, xlibc пока жив, по сети запускать приложения можно (протокол не меняли). Вот и хватит совместимости.
В результате кто-то утонет: либо юникс, либо "свободный десктоп". Хорошо бы второе.

>> Список информации о структуре картинки, которая _не_ может быть получена с сервера в студию.
> Может - любая. Но нафига городить этот идиотский огород, гонять практически полное описание шрифтов на клиент, загружая и клиент и сервер
Зачем? 99% клиентов работают и без загрузки полного описания. Исключения вроде графических редакторов и вьеров и без того создают огромный трафик.

> (для этого еще небось и отдельное расширение в протокол запихивать придется)?
Ви так говорите, как будто ради xft отдельного расширения не было написано.

> Проще клиенту сгенерить полную битмапку - для этого надо только знать очень небольшой набор параметров сервера.
Не проще --- это дополнительное усложнение _каждого_ тулкита. И оно вполне сочетается с желанием устроить toolkit lock-in.

> Единственный резон серверного рендеринга - унификация внешнего вида прикладух с разных клиентов.
А ничего, что получается неслабое дублирование функциональности, причём с неэквивалентными результатами, что мы можем наблюдать на отрисовке шрифтов через xft в gtk, qt и tk.

> Но, как было уже отмечено, этот use case на сегодня для разработчиков юниксовых десктопов является низкоприоритетным (конечно, приоритет не равен нулю, но...)
Тут меня посещают сомнения, что эти приоритеты не выставлены постфактум.

> Тем более что проблема прекрасно решается унификацией баз шрифтов на клиентах, с дублированием или сетевыми дисками. Низкий приоритет + возможность решить другим способом = забить болт.
Везде можно найти дырку, через которую можно сделать что-нибудь противоестественное, я в этом не сомневался.

> до последнего пикселя. В случае же рендеринга на сервере, сервер не знает до конца, чего хочет клиент - а клиент не знает, как именно будут выглядеть шрифты на сервере. Только примерно, в виде метрик.

И чем вас не устраивают метрики? И зачем может понадобится знать положение глифов еще точнее?

В целом, полностью согласен с gaa --

1. шрифты должны рисоваться сервером

2. настройки внешнего вида (а не функциональности) должны лежать на сервере

При ходьбе на один клиент с разных терминалов -- например с десктопа и КПК -- нужны *разные* настройки внешнего вида. А если ходьба происходит с разных десктопов -- то применяется предложенный вами же раздача конфигов по сети.

3. плохо, что в угоду попсовым десктопам ломают профессиональные фичи

4. cookbook, а шаг от него вправо или влево -- расстрел ради того, чтобы быдло мышетыкало красивые кнопочки -- это не для меня

За разъяснение по поводу xkb -- спасибо. Но я (КДЕ кстати) не считаю зазорным использовать xkb. Наоборот, не понимаю, зачем надо было изобретать kppp как отдельную прогу, а не конфиг к wvdialer.

// www_linux_org_ru

s/а не конфиг к wvdialer/а не конфигуратор к wvdialer/

> И чем вас не устраивают метрики? И зачем может понадобится знать положение глифов еще точнее?

Там есть ещё такая проблема: некоторым клиентам надо подгружать свои шрифты, т.к. некоторые типы документов (pdf, например) носят шрифты с собой. Но решение с xft из разряда "хуже не придумаешь".

> Там есть ещё такая проблема: некоторым клиентам надо подгружать свои шрифты, т.к. некоторые типы документов (pdf, например) носят шрифты с собой. Но решение с xft из разряда "хуже не придумаешь".

PDF вообще уродский формат.

А вот насчет редизайна Х-ов -- вполне возможно, что он нужен, чтобы иксы могли исполняться в GPU графической карты.

>Наоборот, не понимаю, зачем надо было изобретать kppp как отдельную прогу, а не конфиг к wvdialer.

в wvdialer есть аналог kppp rules, позволяющий гибко учитывать трафик и время соединения? нет? фпечь! :)

> в wvdialer есть аналог kppp rules, позволяющий гибко учитывать трафик и время соединения? нет? фпечь! :)

man pppstatus

> git checkout нужную ветку себе в репо, и git cherry-pick, куда уж проще?
А почему я не могу выбирать вишню прямо в чужом репо? Нафига мне ненужные ветки, которые будут жить 1 минуту?

> Нафига мне ненужные ветки, которые будут жить 1 минуту?

Потому что git всегда работает с локальным репозиторием, за исключением команд копирования изменений между репозиториями.

> Программисту конкретной программы всё равно, каким образом обращаться к данным, типизированно или нет.
Типизация - это вторично. Главное - разнесение разных установок про разным пропертям. Отсутствие необходимости заниматься никому не нужным парсингом.

> А адванцед юзер совершенно не расклеивается от редактирования файла в текстовом редакторе.
Мы уходим от темы xsettings? Если про gconf - я уже многократно озвучивал преимущества перед простым текстовым, повторять не буду.

> Для не умеющих парсить текст: если я работаю с ресурсом background, я всегда знаю, что там лежит _цвет_ и знаю, что это _цвет_ фона. Доходчиво?
Вполне. Но это никак не влияет на то, что приложение не может следить за изменением background (и только его).

> В результате кто-то утонет: либо юникс, либо "свободный десктоп". Хорошо бы второе.
Второе, конечно, может утонуть. Беда в том, что Вы не заметили, как много лет назад утонуло первое - на всем, кроме серверов. Иксы существовали в какой-то коматозной "Cobol mode". Если Вас это устраивало, то гномовцев - нет.

> Зачем?
Насколько я знаю рендерилки (CMIIW), размытость шрифта иначе корректно не достичь. Впрочем, могу ошибаться. В любом случае - ответ на Ваш вопрос по идее тот же самый, по которому xft нельзя реализовать на сервере;)

> Не проще --- это дополнительное усложнение _каждого_ тулкита.
Нафига??? Во-первых, на целостном дестктопе должен доминировать один тулкит. Во-вторых, в старье типа мотифовских и пр. тулкитах никто ковыраться не станет - пусть сервер генерит шрифты, как справится (будет выглядеть ужасно - тем больше стимула использовать и портировать родные приложения десктопа)

> причём с неэквивалентными результатами, что мы можем наблюдать на отрисовке шрифтов через xft в gtk, qt и tk.
Вообще-то, ЕМНИП, gtk & qt используют одну и ту же рендерилку. Про tk не знаю.

> Тут меня посещают сомнения, что эти приоритеты не выставлены постфактум.
Скорее всего, оно случилось по ходу жизни, одновременно.

> И чем вас не устраивают метрики? И зачем может понадобится знать положение глифов еще точнее?
Я попробовал объяснить gaa в предыдущем каменте.

> Но я (КДЕ кстати) не считаю зазорным использовать xkb.
Ваше право. Но десктоп должен предоставлять основные настройки (включая клавиатуру и сетевые соединения) без командной строки и текстовых файлов. Это железно.

Вот это-то меня и напрягло...

>> Программисту конкретной программы всё равно, каким образом обращаться к данным, типизированно или нет.
> Типизация - это вторично. Главное - разнесение разных установок про разным пропертям. Отсутствие необходимости заниматься никому не нужным парсингом.
И заниматься вместо этого никому не нужными проверками, держать кучу демонов...

>> Для не умеющих парсить текст: если я работаю с ресурсом background, я всегда знаю, что там лежит _цвет_ и знаю, что это _цвет_ фона. Доходчиво?
> Вполне. Но это никак не влияет на то, что приложение не может следить за изменением background (и только его).
Перенастройка внешнего вида приложений занимает ничтожно малое время в сравнении с временем работы, можно и перезапустить. Более того, не все приложения корректно понимают смену темы.

>> Зачем?
> Насколько я знаю рендерилки (CMIIW), размытость шрифта иначе корректно не достичь. Впрочем, могу ошибаться. В любом случае - ответ на Ваш вопрос по идее тот же самый, по которому xft нельзя реализовать на сервере;)
Я не вижу этого ответа. И нагуглить не смог. Ссылка будет или опять "если так сделано в гноме, то так правильно"?

>> Не проще --- это дополнительное усложнение _каждого_ тулкита.
> Нафига??? Во-первых, на целостном дестктопе должен доминировать один тулкит.
Слова фанатика. С такими людьми о стандартизации говорить бесполезно.

> Во-вторых, в старье типа мотифовских и пр. тулкитах никто ковыраться не станет - пусть сервер генерит шрифты, как справится (будет выглядеть ужасно - тем больше стимула использовать и портировать родные приложения десктопа)
И кто будет переписывать тот же xclearcase чтобы потешить желания левой пятки группы ограниченных людей?

>> причём с неэквивалентными результатами, что мы можем наблюдать на отрисовке шрифтов через xft в gtk, qt и tk.
> Вообще-то, ЕМНИП, gtk & qt используют одну и ту же рендерилку. Про tk не знаю.
Везде xft. И везде различно.

>man pppstatus

забавный hello world.. :) а теперь сравни с http://docs.kde.org/stable/en/kdenetwork/kppp/appendix-accounting-template.html .