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

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

Ладно, для упорствующих рассказываю популярно: на тонком клиенте A запускается X-сервер, к которому подключаются клиент-гимп с машины B и клиент-файрфокс с машины C. И выглядят они по-разному, потому что настройка внешнего вида gtk-приложений на машине B и на машине C различается.
Потом запускается tkabber с B и xpdf с C. И они используют одну цветовую схему, потому что берут ресурсы с X-сервера A.

Доходчиво?

> Вот интересно, на каком ходу он вспомнит, что раньше шрифты рендерились на сервере, и это было Ъ

Примерно после перехода на клиентскую отрисовку они и стали пресловутым "говном", кстати.

> Монстры прошлого века на десктопе? o.O
Про HPUX не знаю, а AIX в полный рост live and kicking. Правда, не на десктопе.

> Это вообще очень хорошиц вопрос, что же сейчас ожидают от десктопа.
Что-то по юзабельности сравнимое и лучшее, чем винда и макос. Но не мотиф.

> Проблемы пары негров с фреймбуффером не волнуют белого шерифа.
Шериф в своей деревне хочет остаться один?

Времена, когда икс-сервер выполнял что-то кроме отрисовки простейших примитивов - прошли. Ему даже текст выводить не доверяют (а ведь были даже шрифтовые серверы...) А еще когда-то всякие XPRINT расширения были. Все поросло. Иксовый сервер больше никого не интересует с т.зр. "высокоуровневой" десктопной функциональности. Все, что от него требуется - выводить графику с максимальной скоростью. Остальное - работа клиентских приложений.

>> Это об Оуэне Тейлоре штоле? :) Молодая кровь, гы :)
> Не, это он про Gettys & Packard. И кого колышет, что Gettys участвовал в изначальной разработке иксов...

Последним произведением Льва Николаевича Толстого были собственноручно сшитые сапоги.

> И выглядят они по-разному
Не вижу проблемы. Проблема только только в том, что use case откровенно извратный и экзотический, подстраивать софт под него никто не будет. Куда более осмысленный и частый use case - это login на одну систему с разных терминалов. И в этом случае пользователь хочет видеть по возможности ОДИНАКОВЫЙ интерфейс. Разумеется, с учетом коррекции по глубине цвета, разрешению и пр. - это дело софта аккуратненько все адаптировать.

Доходчиво?

> Примерно после перехода на клиентскую отрисовку они и стали пресловутым "говном", кстати.
А что, алгоритмы растеризации шрифтов меняются от того, на какой машине производят вычисления? Теплый лапмповый серверный растеризатор рулит?

so what?

>> Капитан, озвучьте разницу!

> http://standards.freedesktop.org/xsettings-spec/xsettings-spec-0.5.html#existing

Я же сказал, что по этой ссылке я бывал.

> The Xrm database merges information from various sources - the ~/.Xdefaults file on the root window, and a property on the root window. This means that to programatically configure the Xrm database in response to a GUI config tool is difficult and unreliable.

Я авторов kcontrol такой проблемы не возникло почему-то и xresources они обновляют (почти) корректно. (почти: по какой-то ляд определяется ресурс *background, который переопределяет все бэкграунды разом)

> The Xrm database was not designed for on-the-fly changing of settings.

xrdb -merge < new-resources. А про обновление запущенных приложений я уже сказал: это слишком сложно в случае, когда надо сделать нечто более сложное, чем перекраску кнопочек.

> The Xrm database stores all information in a single text property on the root window. This makes it difficult to determine what settings have changed; it is necessary to parse the property and do string comparisons.

Проблемы не умеющих сериализовать данные в строку юникс-программистов вообще никогда не касались.

>> Подстройка внешнего вида и шрифтов (я напираю именно на внешний вид, чётко отделяя его от настроек)
> А с какого рожна их отделять? Это тоже настройка. Что в ней такого особенного? К тому же, явно для клиентской стороны - x server даже понятия не имеет про доступные на клиенте шрифты, так с какого рожна ему хранить бессмысленную для него инфу?

А с такого. Советую ещё вспомнить, что у разных экранов бывает разное dpi, и, кроме того, я могу захотеть запустить на своём х-сервере программу с другого компьютера. И хочу, чтобы она выглядела так, как все остальные у меня, а не у соседа.

>> И усложнять из-за этой единовременной операции штатный режим работы с поломкой обратной совместимости нерационально.
> Штатный режим никто не усложняет. Кто хочет использовать xrdb - волен (я уже говорил, что в гноме есть write-only поддержка).
Угу-угу, в результате tkabber, xpdf, xclearcase, xmaxima и другие выглядят неродными, как ни крути настройки *DE.

>> Какой ещё из стандартов от fd.o я не покрыл?
> Где у Вас .desktop? Где аналог dbus (corba не предлагать)? Меню, Темы иконок? Изучайте http://standards.freedesktop.org/ до просветления.

Дельные там только xembed и tray. Список аналогов d-bus легко находится на страничке описания d-bus.

d-bus --- это вообще отдельная песня про оверинжиниринг и попытку всё подряд притягивать к объектной модели. Это я как соавтор dbus-tcl и автор dbus-snit говорю.

>> Это вообще очень хорошиц вопрос, что же сейчас ожидают от десктопа.
> Что-то по юзабельности сравнимое и лучшее, чем винда и макос. Но не мотиф.

Это не ответ. "Хочу то не знаю что"

>> Проблемы пары негров с фреймбуффером не волнуют белого шерифа.
> Шериф в своей деревне хочет остаться один?
Шериф идёт за мейнстримом, в котором фреймбуферов нет.

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

И как это сочетается с отрицанием xrdb и изобретением велосипеда ему на замену?

> so what?

Все могут уходить в сторону от когда-то сделанных полезных дел и заниматься ерундой.

> Я же сказал, что по этой ссылке я бывал.
Ну что ж поделать, если прочесть толком не справились?...

> А про обновление запущенных приложений я уже сказал
Не аргумент. Что там геморройно, что обновлять - это пусть решают уровнем выше. Система конфигурирования должна предоставлять механизм. Он теперь есть. И, судя по активному использованию, он полезен.

> Проблемы не умеющих сериализовать данные в строку юникс-программистов вообще никогда не касались.
Причем тут "не умеющих"? Можно, но неудобно! Интерфейс должен быть юзабельным. Заниматься парсеньем, выкусыванием, склеиванием... бррр. Куда как проще отдельную проперть записать-прочесть. Не подумали авторы того стандарта. Надо менять.

> Советую ещё вспомнить, что у разных экранов бывает разное dpi
Это пусть клиентский рендерер учитывает. У него эта инфа от сервера есть. В любом случае - рендеринг шрифтов на сервере мертв, это факт.

> И хочу, чтобы она выглядела так, как все остальные у меня, а не у соседа.
Зашарьте домашний каталог.

> Угу-угу, в результате tkabber, xpdf, xclearcase, xmaxima и другие выглядят неродными, как ни крути настройки *DE.
Баги есть везде... Впрочем, они всегда будут неродными, потому что тулкит другой.

> Список аналогов d-bus легко находится на страничке описания d-bus.
Очевидно, что они чем-то отличаются от него;)

> и попытку всё подряд притягивать к объектной модели.
Это как раз самый рулез. Этим он близок к любимой мной корбе. Легковесная корба - самое оно!

>> И выглядят они по-разному
> Не вижу проблемы.
А вот те, у кого юникс --- не {десктопная система одного пользователя, отключенная от сети}, видят проблему.

И авторы велосипеда xsettings тоже видят проблему: "Why is the settings property screen specific? While most settings are expected to be shared across all screens of a display, some settings, such as font sizes will be screen specific, and it is considered easier to let the settings manager propagate shared resources across screens then to have both screen-specific and screen-independent resources."

> Проблема только только в том, что use case откровенно извратный и экзотический, подстраивать софт под него никто не будет. Куда более осмысленный и частый use case - это login на одну систему с разных терминалов.

Несколько приложений с разных машин на одном дисплее --- далеко не редкость.
Это ведь как надо умудриться заср-ть клиент-серверную архитектуру X11, чтобы получить из неё десктоп винды!?

> Доходчиво?
Вполне. Теперь я уверен, что ты из тех, у кого юникс-машина --- однопользовательский десктоп.

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

> Это не ответ. "Хочу то не знаю что"
Полного ответа у меня нет (был бы - стал бы во главе гнома;) У Вас есть?

> Шериф идёт за мейнстримом, в котором фреймбуферов нет.
В мейнстриме использование иксов на вывод мало чем отличается от фреймбуфера.

> И как это сочетается с отрицанием xrdb и изобретением велосипеда ему на замену?
Почему xrdb плох - отвечено в спеках xsettings, обсуждается в другом мини-треде.

> Несколько приложений с разных машин на одном дисплее --- далеко не редкость.
На массовом десктопе??? Вернитесь с небес на землю?

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

> xft на стороне сервера, емнип, невозможен.
Вопрос о другом - что из доступного на сервере недоступно на клиенте? А xft - нужен однозначно, как и поддержка векторных шрифтов.

>> А про обновление запущенных приложений я уже сказал
> Не аргумент. Что там геморройно, что обновлять - это пусть решают уровнем выше.
В итоге перекрашиваться будут только кнопочки, а в новую редакцию fd.o HIG войдёт пункт "не кладите сложные данные в настройки" :о)

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

>> Проблемы не умеющих сериализовать данные в строку юникс-программистов вообще никогда не касались.
> Причем тут "не умеющих"? Можно, но неудобно! Интерфейс должен быть юзабельным. Заниматься парсеньем, выкусыванием, склеиванием... бррр.
Страхи и фобии не-юниксовых программистов юниксовых программистов тоже мало волнуют.

> Куда как проще отдельную проперть записать-прочесть. Не подумали авторы того стандарта. Надо менять.
Кому неудобно --- пусть обвязку пишет. Объектно-ориентированную. С доступом через d-bus. Пусть только xrdb не трогает и не замещает.

>> И хочу, чтобы она выглядела так, как все остальные у меня, а не у соседа.
> Зашарьте домашний каталог.

Замечательный костыль. Канфэтка.

>> Угу-угу, в результате tkabber, xpdf, xclearcase, xmaxima и другие выглядят неродными, как ни крути настройки *DE.
> Баги есть везде... Впрочем, они всегда будут неродными, потому что тулкит другой.

Это не баги. Это ущербность подхода. И она не лечится простым багфиксом.

>> Список аналогов d-bus легко находится на страничке описания d-bus.
> Очевидно, что они чем-то отличаются от него;)

Разумеется. У меня просили аналоги --- я их выдал.

>> и попытку всё подряд притягивать к объектной модели.
> Это как раз самый рулез. Этим он близок к любимой мной корбе. Легковесная корба - самое оно!

А вот в девятом плане предлагают более традиционный для бникса механизм, с блекдже^W^Wс файлами и строками. Без перегрузок.

Если б я ждал, пока в иксы добавят сетево-прозрачную работу с настройками XKB, в гноме юзабельного конфигуратора клавиатуры не было б до сих пор. А так у меня есть бага о сломанной сетевой (и вендорной) прозрачности. И будет висеть, пока не пофиксят иксы. Грустно - но таков реализм. Если б я думал по-Вашему, люди по-прежнему должны были курочить xorg.conf или ставить setxkbmap в автозапуск. Что для приличного DE просто позор.

Реалистичнее надо быть!

>> Это не ответ. "Хочу то не знаю что"
> Полного ответа у меня нет (был бы - стал бы во главе гнома;) У Вас есть?

Полного --- тоже нет. Но мои цели гораздо более близки к непосредственному тз. У меня даже бумажка со схемой "порабощения мира" есть. И я потихоньку-полегоньку ставлю там галочки.

> В итоге перекрашиваться будут только кнопочки
С чего б? В нормальном приложении так и должно быть - интерфейс настроек меняет gconf, а все остальные только слушают оповещения. Напрямую никого не конфигурируют.

> а в новую редакцию fd.o HIG войдёт пункт
HIG тут вообще не причем.

> Жду в качестве примера три коммерческих приложения, его использующих.
У нас много коммерческих приложений для гномовского десктопа?

> Страхи и фобии не-юниксовых программистов юниксовых программистов тоже мало волнуют.
Ну вот и оставайтесь таким... невзволнованным. А стандарты будут меняться, чтоб людям было удобно. Делать стандарты "под элитных зубров" - тупиковый путь.

> Пусть только xrdb не трогает и не замещает.
Его никто не трогает. Только не используют. Потому что неудобно. По указанным причинам. А "юниксовые программисты" (тм) пусть используют xrdb. На обочине мейнстрима.

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

> А вот в девятом плане
Очень уважаю его. Но десктоп не может рассчитывать на то, что под ним эта ОС. Да и IPC без ОО как-то некузяво...

>> Несколько приложений с разных машин на одном дисплее --- далеко не редкость.
> На массовом десктопе??? Вернитесь с небес на землю?

На массовом десктопе вообще ни иксов, ни "линапса", ни fd.o нет. Что ж теперь, идти за массовостью?

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

А потом это будет сделать ещё сложнее. Эта функциональность работает _сегодня_. Предлагается же её выбросить и ждать, пока кто-нибудь соберётся её реализовать на новом витке. У меня нет бранных слов, чтобы описать своё к этому отношение.

>> xft на стороне сервера, емнип, невозможен.
> Вопрос о другом - что из доступного на сервере недоступно на клиенте? А xft - нужен однозначно, как и поддержка векторных шрифтов.

всё доступно на клиенте, спаренном с сервером. См. в альтернативной операционной системе.

> У меня даже бумажка со схемой "порабощения мира" есть. И я потихоньку-полегоньку ставлю там галочки.
Ой. Я начал бояться. А эта схема ДСП? Или ее можно опубликовать?

> Если б я думал по-Вашему, люди по-прежнему должны были курочить xorg.conf или ставить setxkbmap в автозапуск. Что для приличного DE просто позор.

А я не вижу проблем с запуском setxkbmap или же исполнением того же самого другой программой при запуске десктопа. Никаких.
Покажи, в чём, кроме nih-синдрома, тут загвоздка.

> Что ж теперь, идти за массовостью?
ДА (шрифтом 72, болд). Бороться за массовый десктоп. Например, начиная с нетбуков.

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

> всё доступно на клиенте, спаренном с сервером.
Это уход от вопроса? Что такого нельзя отрендерить на клиенте?
Что Вы можете противопоставить xft и векторым шрифтам как основе десктопа?

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

Ссылку на багу дать?

Штука в том, что сам по себе setxkbmap имеет некий косяк с сетевой прозрачностью. Именно в силу косяка XKB. Не говоря уж о том, что он только в xorg/xfree - т.е. нестандартен.

>> В итоге перекрашиваться будут только кнопочки
> С чего б? В нормальном приложении так и должно быть - интерфейс настроек меняет gconf, а все остальные только слушают оповещения. Напрямую никого не конфигурируют.

Я приводил уже пример: изменение взаиморасположения кнопочек. Это, в отличие от перекраски, которая реализуется рекурсивным вызовом refresh для дерева виджетов, требует более сложный действий. Если возьмёшься утверждать, что оно работает уже сейчас, приводи пример, как это сделать в момент, когда у меня в гимпе открыто окошко выбора файла.

>> а в новую редакцию fd.o HIG войдёт пункт
> HIG тут вообще не причем.

Это шутка была.

>> Жду в качестве примера три коммерческих приложения, его использующих.
> У нас много коммерческих приложений для гномовского десктопа?

Тогда в чём вообще профит? Будет существовать отдельный гномодесктоп и остальные приложения?

(к сведению: xclearcase без проблем настраивается через xrdb)

>> Страхи и фобии не-юниксовых программистов юниксовых программистов тоже мало волнуют.
> Ну вот и оставайтесь таким... невзволнованным. А стандарты будут меняться, чтоб людям было удобно. Делать стандарты "под элитных зубров" - тупиковый путь.

Не надо соваться со своим уставом в чужой монастырь, раз так.

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

Замечательное извращение фактов. Жил-был себе сетевой юникс с клиент-серверными иксами. Пришли fd.o, всё опошлили и теперь попытки юникса напомнить о себе считаются костылями.

>> А вот в девятом плане
> Очень уважаю его. Но десктоп не может рассчитывать на то, что под ним эта ОС. Да и IPC без ОО как-то некузяво...

Могу расписать убогость оо конкретно в d-bus. При этом похожесть или непохожесть его на корбу меня будет волновать мало.

> Штука в том, что сам по себе setxkbmap имеет некий косяк с сетевой прозрачностью. Именно в силу косяка XKB. Не говоря уж о том, что он только в xorg/xfree - т.е. нестандартен.

Какой косяк?

>> У меня даже бумажка со схемой "порабощения мира" есть. И я потихоньку-полегоньку ставлю там галочки.
> Ой. Я начал бояться.

Зачем бояться? Пункт "убить всех гномеров" там не значится. Там вообще мало экшна :)

> А эта схема ДСП? Или ее можно опубликовать?

Дсп. Ближайшая цель --- показать, что для нормальной работы с vfs под неотмершими юниксами не нужны kio/gio/gvfs/mcvfs.

> Если возьмёшься утверждать, что оно работает уже сейчас, приводи пример, как это сделать в момент, когда у меня в гимпе открыто окошко выбора файла.
Не очень вижу проблему. Тем более со стандартными диалогами. Можно объяснить, где тут собака зарыта?

> Будет существовать отдельный гномодесктоп и остальные приложения?
Будут приложения под гтк, плавно интегрирующиеся в гномдесктоп. Существующие legacy приложения работают (xlibc - священная корова). Но никаких бенефитов новых L&F они не получают.

> Не надо соваться со своим уставом в чужой монастырь, раз так.
Можно захватить в нем власть. Если монастырь пришел в упадок (юниксовый десктоп реально был полумертв в середине 90х, стал узко-узко-нишевым) - тот, кто его ремонтирует, устанавливает правила. Возможно, не нравящиеся кому-то из старожилов. Которым лучше в развалинах, но чтоб привычно.

> Жил-был себе сетевой юникс с клиент-серверными иксами.
Никто не ломает сетевость и клиент-серверность. Но никто не обязывает использовать все стандарты, включая неудобные.

> Могу расписать убогость оо конкретно в d-bus.
Интересует!

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

А пользователю и не надо видеть. Пользователь мышой в окошке указывает, что хочет иметь вот эти раскладки, с вот этими флажками, с переключением вот этими клавишами. Это сохраняется в конфиг, а при запуске среды вызывается setxkbmap с нужными параметрами.
Где файлы? Где утилиты? Не видно их.

> Ссылку на багу дать?
да

>> Что ж теперь, идти за массовостью?
> ДА (шрифтом 72, болд). Бороться за массовый десктоп. Например, начиная с нетбуков.

Фигурный квотинг рулит. Я достаточно толсто намекал, что

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

> Хотя дистрибутивы из коробки обычно отключают его.
ssh -X игнорирует эти запреты.

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

А это уже совсем другой вопрос и направлять его надо не в fd.o, а в багзиллу иксов.

>> всё доступно на клиенте, спаренном с сервером.
> Это уход от вопроса? Что такого нельзя отрендерить на клиенте?
Что Вы можете противопоставить xft и векторым шрифтам как основе десктопа?
Зачем противопоставлять? Я тупо хочу красивые шрифты. До введения xft они были, потом пропали. Теперь появляются снова, но "шрифты говно" уже стало фразеологизмом.
Хотя xft таки можно настроить. Только для этого надо лезть (О УЖАС!!!) в xrdb :)

Обычно setxkbmap запускается на клиентской машине. Он берет рулезы (rules/base) на клиентской машине через libxkbfile, используя model-layout-variant-options (RMLVO). Потом он рулезы отрабатывает и получает набор низкоуровневых компонентов keycodes-geometry-types-compat-symbols. И потом он эти компоненты засылает на иксовый сервер. Который уже У СЕБЯ ЛОКАЛЬНО ищет файлы для этих компонентов, компилирует и загружает конфигурацию. При этом никаких гарантий, что файр рулезов на клиенте хоть как-то соответствует имеющимся на сервер низкоуровневым компонентам.

Беда в том, что высокоуровневые имена RMLVO на иксовый сервер не передать - не умеет такого xkb. А еще xkb не позволяет получить с сервера информацию о наличии высокуровневых компонент. Конфигурация через RMLVO была добавлена в xfree после изобретения xkb. В протоколе не отражена. И сетево непрозрачна.

> Где файлы?
Все лежит в gconf

> Где утилиты?
Какие именно? Из gconf можно в командной строке получать инфу. Но зачем?

> а при запуске среды вызывается setxkbmap с нужными параметрами
Унутре gnome-settings-daemon по сути делается работа setxkbmap, с некоторыми поправками.

> да
http://bugzilla.gnome.org/show_bug.cgi?id=152105

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

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

> Я тупо хочу красивые шрифты. До введения xft они были, потом пропали.
А мне как раз нравятся шрифты xft. Размытенькие такие, плавные. Растровые шрифты - это so 90-s.... Вон я сегодня один скриншотик заапрувил, там Ирих. Прикольно и почетно, но - вчерашний день. Про фразеологизмы - мало ль чего анонимусы лоровские брешут...

>> Если возьмёшься утверждать, что оно работает уже сейчас, приводи пример, как это сделать в момент, когда у меня в гимпе открыто окошко выбора файла.
> Не очень вижу проблему. Тем более со стандартными диалогами. Можно объяснить, где тут собака зарыта?
Надо кнопки переставить. Ещё не видно проблемы?

>> Будет существовать отдельный гномодесктоп и остальные приложения?
> Будут приложения под гтк, плавно интегрирующиеся в гномдесктоп. Существующие legacy приложения работают (xlibc - священная корова). Но никаких бенефитов новых L&F они не получают.

И эти люди потом удивляются, что это никто не хочет писать коммерческую прикладуху под linux.
Не всем удобно использовать gtk. Это аксиома.
Не всем хочется переписывать приложения каждые 5 лет.
Но все хотят выглядеть красиво.

Кстати, вот у конкурентов (микрософт) все приложения, даже legacy, выглядят одинаково (ну не считая совсем уж старья со времён win3.1).

> Не надо соваться со своим уставом в чужой монастырь, раз так.
Можно захватить в нем власть. Если монастырь пришел в упадок (юниксовый десктоп реально был полумертв в середине 90х, стал узко-узко-нишевым) - тот, кто его ремонтирует, устанавливает правила. Возможно, не нравящиеся кому-то из старожилов. Которым лучше в развалинах, но чтоб привычно.

>> Жил-был себе сетевой юникс с клиент-серверными иксами.
> Никто не ломает сетевость и клиент-серверность. Но никто не обязывает использовать все стандарты, включая неудобные.
А в какую именно стенку отправят пользователи меня, если я не буду использовать неудобное мне gvfs? В южную или северную?

>> Могу расписать убогость оо конкретно в d-bus.
> Интересует!

Сложность в определении конкретного объекта: интерфейс+имя вместо короткого имени (пусть диспетчеризацией сам объект занимается).
Нет возможности создать новый объект. Разумеется, всё это делается средствами приложения, но "искаропочного" метода нет.
Нет стандартной возможности создать объект, с которым будет работать только один клиент и который будет убит по завершении сессии.
Ну и не совсем связанное с оо: большое количество сущностей делает всю систему в целом более подверженной проблемам с безопасностью: можно отослать сигнал якобы от имени системного сервиса (уверен, что хоть кто-нибудь, но забыл поставить проверку на sender), аналогично с вызовом методов от passkey agent-ов.
Вот как-то так.

> Беда в том, что высокоуровневые имена RMLVO на иксовый сервер не передать - не умеет такого xkb. А еще xkb не позволяет получить с сервера информацию о наличии высокуровневых компонент. Конфигурация через RMLVO была добавлена в xfree после изобретения xkb. В протоколе не отражена. И сетево непрозрачна.

Спасибо за разъяснение. Вопросов не имею.

>> Где файлы? Где утилиты? Не видно их.

Не надо столь буквально воспринимать художественные обороты моей речи :)
Получается, что я описал именно тот сценарий работы, который и использован.

И я теперь не понимаю смысла фразы "Если б я думал по-Вашему, люди по-прежнему должны были курочить xorg.conf или ставить setxkbmap в автозапуск. Что для приличного DE просто позор."

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

> все приложения, даже legacy, выглядят одинаково
Ой, видел я кастомные приложения-обучалки, как они расползаются под новыми виндами.. Конечно, писаны левой пяткой.

> А в какую именно стенку отправят пользователи меня
Зависит от того, что делает Ваше приложение.

> Сложность в определении конкретного объекта: интерфейс+имя
+1. Перемудрили малехо.
> Нет возможности создать новый объект.
Вроде, про dbus activation что-то было?
> Нет стандартной возможности создать объект, с которым будет работать только один клиент и который будет убит по завершении сессии.
Это как и зачем?
> большое количество сущностей делает всю систему в целом более подверженной проблемам с безопасностью
Да, нормального анализа dbus на секурность я не видел. Нужно делать.

> Вопросов не имею.
Зато я имею. Какие предложения от ревнителя стандартов по поводу утилит конфигурации? Что скажете по поводу той баги?

>> Но не работает так, как хочется, поэтому его легче не использовать.
> Почему??
Потому что 95% пользователей удаляют tkabber после первого запуска, потому что там "щревты".
И те же 95% пользователей плюются от kmail, потому что он выглядит не как весь остальной их гном.
И те же 95% пользователей не будут использовать (и не используют уже сегодня) удалённую работу с приложениями с разных хостов, потому что они выглядят неодинаково.

> Если надо запустить прикладуху с другой машины - Вы ж запускаете. И я запускаю. И не печалюсь. Полезная фишка. А то, что она выглядит немного не так - ну и пес с ним, лишь бы родной десктоп был красившеньким.
Ну так уже сегодня видно, как эту проблему решить. Более того --- она уже 20 лет как решена. Но её ломают.

Смысл - в том, что подобная низкоуровневая возня заставляла бы людей отвечать за то, что они делают. Различать клиент и сервер. Как только мы это все прячем в GUI, мы тем самым говорим "ты можешь в этом не разбираться". Для пользователя больше не существует букв XKB. Мы обещаем ему, что все будет ок. Что в случае сетевого использования - неправда, может случиться косяк. Мы берем на себя ответственность за этот косяк.

>> Вопросов не имею.
> Зато я имею. Какие предложения от ревнителя стандартов по поводу утилит конфигурации? Что скажете по поводу той баги?

Да, бага. Неприятная бага. Надо пинать авторов иксов, чтоб поправили.
Что я могу ещё сказать!?

> Потому что 95% пользователей удаляют tkabber после первого запуска, потому что там "щревты".
Я среди них. Но ведь там и под виндами шревты;)

> И те же 95% пользователей плюются от kmail, потому что он выглядит не как весь остальной их гном.
А зачем использовать kmail под гномом???

> И те же 95% пользователей не будут использовать (и не используют уже сегодня) удалённую работу с приложениями с разных хостов, потому что они выглядят неодинаково.
Если это действительно НУЖНО - пользователь будет использовать удаленные приложения. А при наличии выбора - да, будет стараться использовать только локальные. Это плохо?

Да я уж отпинал. Даниель Стоун что-то такое ковыряет, новую версию XKB. Но когда оно еще будет... При этом код для совместимости со старой версией XKB придется поддерживать некоторое время.

Ланн, пошел я спать. Удачи.

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

Не тормозно, тут другое: задача качественно отличается от задачи "установить атрибут такой-то в такое-то значение".

>> все приложения, даже legacy, выглядят одинаково
> Ой, видел я кастомные приложения-обучалки, как они расползаются под новыми виндами.. Конечно, писаны левой пяткой.
Когда я последний раз пользовался этой системой, всё (написанное более-менее профессионалами) выглядело гламурно и одинаково.

>> А в какую именно стенку отправят пользователи меня
> Зависит от того, что делает Ваше приложение.
То есть вариант "не в стенку" даже не рассматривается? ;)

>> Нет возможности создать новый объект.
> Вроде, про dbus activation что-то было?
Это не оно. Activation запускает приложение, отвечающее за объект по данному пути, а не создаёт новый инстанс.

>> Нет стандартной возможности создать объект, с которым будет работать только один клиент и который будет убит по завершении сессии.
> Это как и зачем?
Чтобы хранить там данные сессии. Или придётся в процедурном стиле таскать их с собой.

>> большое количество сущностей делает всю систему в целом более подверженной проблемам с безопасностью
> Да, нормального анализа dbus на секурность я не видел. Нужно делать.
Ну вот пообкатаю его в деле, напишу развёрнутый отзыв.

Кстати, ещё одна ремарка: ссылок на объекты нет. Вместо них приходится таскать строки с путями. Это не страшно в случае с тем же plumber-ом, но плохо вписывается в ъ-оо.

> Смысл - в том, что подобная низкоуровневая возня заставляла бы людей отвечать за то, что они делают. Различать клиент и сервер. Как только мы это все прячем в GUI, мы тем самым говорим "ты можешь в этом не разбираться".

Это, кстати, плохо. Пользователю не обязательно знать про x-сервер и x-клиент, но что плохого в том, что он бужет знать, что сохранил настройки текущего профиля, а не текущей машины? И что этим профилем он может воспользоваться из другого места.

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

Косяки везде бывают. Что ж теперь, дверсями не пользоваться, дабы не брать ответственности?

>> Потому что 95% пользователей удаляют tkabber после первого запуска, потому что там "щревты".
> Я среди них. Но ведь там и под виндами шревты;)

Разве? Вроде бы tk на винде (в classic теме) вообще неотличим от рочих приложений.

>> И те же 95% пользователей плюются от kmail, потому что он выглядит не как весь остальной их гном.
> А зачем использовать kmail под гномом???
AP страниц 5 назад говорил, что использует, у него спроси.

И про "зачем использовать k* под гномом" --- это тоже плохо. Стратификация коммьюнити, так сказать. У нас не одно сообщество десктопных пользователей и программистов: у нас их как минимум два, а то и три. И это далеко не на руку популяризации и качеству.
Но изобретение велосипедов под флагом унификации положение не улучшит.

>> И те же 95% пользователей не будут использовать (и не используют уже сегодня) удалённую работу с приложениями с разных хостов, потому что они выглядят неодинаково.
> Если это действительно НУЖНО - пользователь будет использовать удаленные приложения. А при наличии выбора - да, будет стараться использовать только локальные. Это плохо?
Именно это --- безразлично.
Но нам же нужен удобный красивый юникс с сетевой прозрачностью, не так ли?

> Ланн, пошел я спать. Удачи.

А по моим биологическим часам время обеда :)

А чем, собственно, гном отличается от КДЕ?

> А чем, собственно, гном отличается от КДЕ?

Тем, что КДЕ может вести себя и выглядеть как гном (процентов на 80-90), гном как КДЕ - не в силах (процентов на десять, от силы).

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

> То есть вариант "не в стенку" даже не рассматривается? ;)
Как исключение;)

> Это не оно. Activation запускает приложение, отвечающее за объект по данному пути, а не создаёт новый инстанс.
Ну да, в этом смысле dbus не объектный, а именно ориентированный. Объекты там неполноценные, согласен.

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

> ссылок на объекты нет.
Ну да, это ИМХО как раз из-за того, что объекты не совсем настоящие... Хотя это-то могли б и добавить в более поздних версиях, это совместимость не сломает.

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

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

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

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