> Этот единый интерфейс потянет за собой наличие библиотек подо все языки.

Разумеется. Поэтому его сделали на С. Байндинги к другим языкам или уже есть, или легко делаются.

http://gtk2-perl.sourceforge.net/doc/pod/Gnome2/GConf.html

http://www.dr-baum.net/gnocl/

Про шелл - это тот самый gconftool-2. Достаточно?

а може ну его, этот gconf ? Давай лучше по пиву

> я не умею в уме рассматривать картинку, закодированную в base64

Ой, а в уме рассматривать картинку в gif вы умеете? При этом (по установленному лично Вами условию редактирования текстовыми тулзами) единственной тулзой, доступной Вам, является vim, в консоли.

> А выгрузка в отдельный файл уже нарушает всеобщность хранения конфигов в gconf.

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

Еще раз - если картинка хранится вне gconf, она перестает быть частью конфигурации. В этом случае в конфигурацию входит ее url/path.

Re^4: Чем плох GConf?

>> Они нужны для удобства программиста. И юзера.

> Для удобства программиста куда важнее единый удобный API - в терминах соотв. абстракций.

ну вот я в tcl тупо пишу list в файл, а потом читаю его eval-ом, и всё. остальное за меня делает интерпретатор. Удобнее абстракцию

тут придумать сложно.

Явакодеру тоже лечге будет сериализовать класс SuperPuperConfig, а потом десериализовать его. Хотят ут теряется читабельность.

> gconftool-2 идет вместе с gconf. Так что если у Вас есть gconf - у Вас есть gconftool-2. Можете "рассчитывать на наличие".

Я знаю, где оно лежит, dpkg -S мне всё рассказал. Но как моя сферическая программа в вакууме, написаная для редактирования конфигов апача, может надеяться на часть гнома. Или мы только про гном?

> В реальности ни в одном из конфигурационных файлов в /etc я не видел комментариев на русском (кстати, не желаете ли обсудить, в какой кодировке должны быть эти комментарии?)

Ну так в начале поста сказано, что это нужно только power user-ам, засем им русский? Ну а за кодировки, отличную от utf-8 вполне могут назвать некрофилом.

Ладно, это всё шуточки... Но, если честно, я не могу представить необходимости хранить в конфиге, тем более в /etc русскоязычные комментарии.

Re^8: Чем плох GConf?

> а може ну его, этот gconf ? Давай лучше по пиву

Пива нету. Но я налил в стакан лимонад и чокнулся с экраном :)

> ну вот я в tcl тупо пишу list в файл, а потом читаю его eval-ом, и всё. остальное за меня делает интерпретатор. Удобнее абстракцию тут придумать сложно.

А я хочу в твой конфиг залезть программой из С. Что мне делать? ембеддить tcl что-ли?

Re^8: Чем плох GConf?

>> я не умею в уме рассматривать картинку, закодированную в base64

> Ой, а в уме рассматривать картинку в gif вы умеете? При этом (по установленному лично Вами условию редактирования текстовыми тулзами) единственной тулзой, доступной Вам, является vim, в консоли.

Вы недооцениваете формат xpm. Он читаем и редактируем даже шелловыми утилитами.

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

> Еще раз - если картинка хранится вне gconf, она перестает быть частью конфигурации. В этом случае в конфигурацию входит ее url/path.

Т.е. gconf не всеобщ.

> Удобнее абстракцию тут придумать сложно.

Да-а?... А если кто-то поменял этот файл - Вас кто оповестит? Тот же вопрос про жабку. А если Вы захотите централизованно управлять установками (что позволяет ldap backend) - куда пойдут все Ваши текстовые файлы? Звать на помощь костыль под названием yp ?

> Или мы только про гном?

Пока мы говорим о gconf - мы говорим только про гном. Как только появится system-wide gconf (это отдельная задача, текущий gconf под нее не заточен), когда оно появится в LSB - тогда будем говорить про всякие апачи.

> power user-ам, засем им русский?

Вы не поверите, бывают русскоязычные power users. И многие из них, даже владея английским - предпочтут хороший русский перевод.

> Но, если честно, я не могу представить необходимости хранить в конфиге, тем более в /etc русскоязычные комментарии.

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

Re^4: Чем плох GConf?

>> Этот единый интерфейс потянет за собой наличие библиотек подо все языки.

> Разумеется. Поэтому его сделали на С. Байндинги к другим языкам или уже есть, или легко делаются.

> Про шелл - это тот самый gconftool-2. Достаточно?

Достаточно.

> Вы недооцениваете формат xpm. Он читаем и редактируем даже шелловыми утилитами.

Я не помню, когда последний раз видел картинки в формате xpm. Кстати, как любитель awk/sed/... - Вы никогда не задумывались о реализации ImageMagick при помощи этих утилит (только для формата xpm)? Должно получиться мощщщно...

> А вообще, отдельно лежащий файл можно чем-нибудь открыть, в то время как base64 в конфиге придётся выковыривать, распаковывать, а потом уже скармливаьт вьюеру.

И это говорит человек, рвавший на груди рубаху за применение sed/awk/... и других утилит командной строки? Кроме того, что значит "отдельно лежащий"? У Вас картинка в файле конфигурации или где?

> Т.е. gconf не всеобщ.

Всеобщ только Св.Падрег и анонимус. А gconf всего лишь хранит конфигурацию. Если разработчик решил, что картинка - не конфигурация, значит, она не будет в gconf.

Re^6: Чем плох GConf?

>> ну вот я в tcl тупо пишу list в файл, а потом читаю его eval-ом, и всё. остальное за меня делает интерпретатор. Удобнее абстракцию тут придумать сложно.

> А я хочу в твой конфиг залезть программой из С. Что мне делать? ембеддить tcl что-ли?

Ну зачем? Файл скармливается аналогу gconftool на tcl-е, который делает то, что нужно.

> Ну зачем? Файл скармливается аналогу gconftool на tcl-е, который делает то, что нужно.

Я правильно понимаю, что для каждой программы предлагается писать аналог gconftool? Или будет один большой аналог для всех конфигов? Тогда это бекенд gconf на TCL-е :)

Re^6: Чем плох GConf?

>> Удобнее абстракцию тут придумать сложно.

> Да-а?... А если кто-то поменял этот файл - Вас кто оповестит? Тот же вопрос про жабку. А если Вы захотите централизованно управлять установками (что позволяет ldap backend) - куда пойдут все Ваши текстовые файлы? Звать на помощь костыль под названием yp ?

"А теперь открой для себя управление всей сетью средствами AD+GPO...", как сказал бы анонимный тролль. Да, тут текстовые конфиги, да и вообще любые конфиги без конфиг-демона не справляются.

Может тогда с этим демоном через d-bus общаться? а? Биндинги для d-bus тоже можно к любым языкам сделать

>> Но, если честно, я не могу представить необходимости хранить в конфиге, тем более в /etc русскоязычные комментарии.

> Зря. Весьма удобно. Одна из реальных проблем виндового реестра - недокументированность значений. Пользователи порой тыркаются как слепые котята...

Так мы не о документированности, мы о "Цвет текста" vs "Font color".

Re^10: Чем плох GConf?

>> Вы недооцениваете формат xpm. Он читаем и редактируем даже шелловыми утилитами.

> Я не помню, когда последний раз видел картинки в формате xpm.

Я -- сегодня.

> Кстати, как любитель awk/sed/... - Вы никогда не задумывались о реализации ImageMagick при помощи этих утилит (только для формата xpm)? Должно получиться мощщщно...

...по потреблению памяти и тормознутости :) Кстати, бытует мнение, что netpbm более юникс-веен нежели imagemagick.

>> А вообще, отдельно лежащий файл можно чем-нибудь открыть, в то время как base64 в конфиге придётся выковыривать, распаковывать, а потом уже скармливаьт вьюеру.

> И это говорит человек, рвавший на груди рубаху за применение sed/awk/... и других утилит командной строки?

Вижу иронию, но не вижу того, что автор хотел высмеять.

> Кроме того, что значит "отдельно лежащий"? У Вас картинка в файле конфигурации или где?

У меня картинка -- в удобном мне месте. Т.е. в виде файла в файловой системе. Кстати, файловая система -- как раз древовидное хранилище пресловутых текстовых конфигов.

Re^8: Чем плох GConf?

>> Ну зачем? Файл скармливается аналогу gconftool на tcl-е, который делает то, что нужно.

> Я правильно понимаю, что для каждой программы предлагается писать аналог gconftool? Или будет один большой аналог для всех конфигов? Тогда это бекенд gconf на TCL-е :)

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

> Может тогда с этим демоном через d-bus общаться? а? Биндинги для d-bus тоже можно к любым языкам сделать

Вполне возможно. Только тяжеловато. Локальный api сильно дешевле. Впрочем, есть gconfd. Сочетание "демон + локальный кэш" представляется оптимальным.

> Так мы не о документированности, мы о "Цвет текста" vs "Font color".

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

Re^8: Чем плох GConf?

>> Может тогда с этим демоном через d-bus общаться? а? Биндинги для d-bus тоже можно к любым языкам сделать

> Вполне возможно. Только тяжеловато. Локальный api сильно дешевле. Впрочем, есть gconfd. Сочетание "демон + локальный кэш" представляется оптимальным.

Предлагаю это запостить тем, кто занимается разработкой "общесистемного gconfd"ю

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

>> Так мы не о документированности, мы о "Цвет текста" vs "Font color".

> Если уж ввели документированность на значения - почему не сделать следующий логический шаг, и не сделать ее локализуемой? Поверюзер не обязан знать (и тем более любить) английские описания.

ну, в /etc-то всё должно быть в посиксной локали. Вот с локализацией пользовательских конфигов я вполне согласен. Но я не вижу причин, по которым это неимоверно сложно реализовать без gconfd

> Вижу иронию, но не вижу того, что автор хотел высмеять.

Я не понимаю, какая у Вас проблема вытащить картинку из base64 формата. Скрипт из одной строки "Вытащить значение по ключу из gconf, сконвертировать из base64 и вызвать мой любимый eog" - явно не стОит длительных дискуссий.

> У меня картинка -- в удобном мне месте.

У меня тоже. А как программа узнает о том, что эта картинка должна использоваться как аватара?

> Кстати, файловая система -- как раз древовидное хранилище пресловутых текстовых конфигов.

Увы, увы... Под классическими унихами (я не беру модные plan9 и пр.) файловая система слишком неспешная для таких развлечений. Формально - да, можно было б сделать бекенд к gconf, используя только плоские текстовые конфиги и каталоги (за деньги готов разработать лично). Но это будет только бекенд. Главный пункт в крутости gconf - программе ПОФИГ, как хранится конфигурация. Есть уровень абстракции, не зависящий от того, что "снизу". Вот в чем сила.

> ну, в /etc-то всё должно быть в посиксной локали.

Почему, кстати? Только потому что древние терминалки не справляются?

cлушай, ты дурак или прикидываешься? Я сказал, что редактировать sed/awk в конфигах ЮЗЕРСКИХ программ. Для тебя расшифровываю: браузеры, почтовики, графические редакторы, просмотрщики всякой хни итд.

Про пользу шела я и без тебя знаю. Я вот не знаю как эту пользу именно в этой нише приткнуть. Оно тут тупо не нужно.

мало того, в первой команде ты забыл про /etc/shadow, man userdel

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

Епт, и эти евреи будут учить нас экономике (ц)

Re^12: Чем плох GConf?

> Я не понимаю, какая у Вас проблема вытащить картинку из base64 формата. Скрипт из одной строки "Вытащить значение по ключу из gconf, сконвертировать из base64 и вызвать мой любимый eog" - явно не стОит длительных дискуссий.

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

> А как программа узнает о том, что эта картинка должна использоваться как аватара?

файл $XDG_CONFIG_HOME/$PROGRAM_NAME/avatars/$USER.png вряд ли может быть использован как мелодия звонка.

> Главный пункт в крутости gconf - программе ПОФИГ, как хранится конфигурация. Есть уровень абстракции, не зависящий от того, что "снизу". Вот в чем сила.

Сила есть. Только сила тянет за собой накладные расходы: лишняя занятая память, лишний процесс, лишнее время на чтение конфигов конфиг-демона, лишние сторонние компоненты, которые шаловливые ручки могу сломать и т.д. И не надо говорить, что я скряга и нищеброд, у меня на наладоннике время запуска ksycoca заметно(правда, не могу сказать такого же про gconf, ибо он не пишет в консоль, когда запускается).

Щас скажу, как обычный пользователь скажу. При стандартном подходе для меня удобно, что я всегда знаю, где искать конфиги соответсвующих приложений. Тупо nano ~/.<имя_приложения>/<имя_приложения>.*

В случае с gconf мне нужно ещё подумать - а к какому классу/подклассу относится приложение? Плюс я терпеть ненавижу элемент интерфейса типа "дерево" - ни черта не показывает и пользоваться неудобно.

Ручками, как белковому организму, мне проще отредактировать текстовый файл, и неважно записано там в строчках "option=true" или "value:1". А когда я вижу нагромождение XML (который как упомянуто выше хз где лежит), то руки сразу опускаются. Не встроили ещё в мозг парсер/валидатор XML, а на проблемы программиста мне нас-рать.

Re^10: Чем плох GConf?

>> ну, в /etc-то всё должно быть в посиксной локали.

> Почему, кстати? Только потому что древние терминалки не справляются?

Потому что на одной машине могут сидеть люди с разными локалями и языками. А /etc -- общий

> И это говорит человек, рвавший на груди рубаху за применение sed/awk/... и других утилит командной строки? Кроме того, что значит "отдельно лежащий"? У Вас картинка в файле конфигурации или где?

Cву, не трави человека. Судя по его экзамплам человек только строит из себя любителя этого самого sed/awk/grep, но в предмете нихрена не разбирающийся.

Очередной лоровский пионер

Re^4: Чем плох GConf?

> cлушай, ты дурак или прикидываешься?

Переход на личности засчитан.

> Я сказал, что редактировать sed/awk в конфигах ЮЗЕРСКИХ программ. Для тебя расшифровываю: браузеры, почтовики, графические редакторы, просмотрщики всякой хни итд.

ну поменяй имя файла на .mozilla/firefox/3jxyqq9e.default/extensions.ini

> мало того, в первой команде ты забыл про /etc/shadow, man userdel

в иллюстрациях много о чём можно забыть.

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

угу, а в инсталляционный скрипт вставить "откройте vim и наберите...".

> Епт, и эти евреи будут учить нас экономике (ц)

Сарочка, пойдём есть мацу!

думать не нужно. gconf-editor->/apps/appname/

как человек админивший такие сервера, скажу, что в таких случаях пользователи пользуются UTF-8.

> как человек админивший такие сервера, скажу, что в таких случаях пользователи пользуются UTF-8.

И поголовно русский язык.

>> мало того, в первой команде ты забыл про /etc/shadow, man userdel

>в иллюстрациях много о чём можно забыть.

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

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

> угу, а в инсталляционный скрипт вставить "откройте vim и наберите...".

про скрипты тут никто по-мойму не говорил :) Вообще. Ну и касательно gconf'а, в инсталяции можно просто положить в дерево доп конфиг с нужными значениями. :) Как это делает ubuntu.

английский, испанский, немецкий и русский. Но в итоге всем достало мешанина и все договорились писать комментарии на английском :)

Но, это подтверждает, что в /etc никто не запрещает использование родных языков. Мало того, файлы в /etc/ правятся только администратором.

> про скрипты тут никто по-мойму не говорил :) Вообще.

Без использования в скриптах весь флейм теряет силу.

> Мало того, файлы в /etc/ правятся только администратором.

А читаются - всеми. Да даже если хранить их на языке администратора, в каком виде они должны лежать в дистрибутивных пакетах?

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

Можно обойтись вообще без многого. Но есть набор требований, которым подход "текстовый конфиг-файл" не удовлетворяет. И если у айтишника и программиста есть такие требования - нужен gconf.

> файл $XDG_CONFIG_HOME/$PROGRAM_NAME/avatars/$USER.png вряд ли может быть использован как мелодия звонка.

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

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

Может, просто потому что вывод на консоль тормозит? У меня на н810 все вполне шустро. Ресурсы, потребляемые gconf - уже давно ниже того уровня, который стоит серьезно обсуждать для десктопов (и существенной части мобильных устройств). И еще раз, прошу не уползать из изначально обсуждаемой ниши. Мы говорим о гноме, о полноценном десктопе.

> Потому что на одной машине могут сидеть люди с разными локалями и языками. А /etc -- общий

Поэтому надо использовать систему с нормальной локализацией. А текстовые файлы и /etc - отправить фтопку. Что, соббсно, и сделал apple в macos.

> Тупо nano ~/.<имя_приложения>/<имя_приложения>.*

Действительно тупо. Особенно если учесть, что букоффки бывают большие и маленькие, что минус и подчеркивание часто путаются и пр. В общем, удачи...

> В случае с gconf мне нужно ещё подумать - а к какому классу/подклассу относится приложение?

??? Вы на дерево gconf хоть раз смотрели? /apps/<имя приложения> - И ВСЕ.

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

Купите хороший монитор. Измените dpi. Или используйте gconftool-2.

> А когда я вижу нагромождение XML

Да не надо лезть в XML вообще! Нечего пользователю там делать (Вам - тем более, с Вашими проблемами)! ВООБЩЕ. Это внутренняя деталь реализации. Для пользователей есть нормальные тулзы, как графические, так и командной строки.

> а на проблемы программиста мне нас-рать.

Проблемы программиста оборачиваются проблемами пользователя. Надо быть близоруким на все -10, чтобы этого не понимать.

Re^14: Чем плох GConf?

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

Тот самый демон с нотификацией об изменении или что-то ещё?

> И если у айтишника и программиста есть такие требования - нужен gconf.

...или его аналог

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

Ну на это есть спецификация, в каком порядке обрабатывать места расположения конфигов.

> Взял путь из gconf - и никакой перхоти.

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

Re^12: Чем плох GConf?

>> Потому что на одной машине могут сидеть люди с разными локалями и языками. А /etc -- общий

> Поэтому надо использовать систему с нормальной локализацией.

Как нормальная локализация помогает преодолеть языковой барьер при чтении одного локализованного файла разными пользователями?

> А текстовые файлы и /etc - отправить фтопку. Что, соббсно, и сделал apple в macos.

Поясните несведещему: Там нет глобальных конфигов? Или их нельзя редактировать через vim

?

> Тот самый демон с нотификацией об изменении или что-то ещё?

Централизованное управление. Контроль над тем, кому что можно менять в настройках. Достаточно?

> ...или его аналог

Сколько угодно!

> Ну на это есть спецификация, в каком порядке обрабатывать места расположения конфигов.

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

> Некоторые называют такой подход "забивание гвоздей микроскопом"

Ээээ использования API конфигурирования для получения конфигурации - это уже считается чрезмерным??? Это какие-то странные "некоторые".

> Как нормальная локализация помогает преодолеть языковой барьер при чтении одного локализованного файла разными пользователями?

Очень просто! Нет файла - нет проблемы. Есть хранилище. Являющееся ... не важно чем. Доступ к нему - только через утилиты, которые сами заботятся о локализации.

> Поясните несведещему: Там нет глобальных конфигов? Или их нельзя редактировать через vim

Нельзя редактировать. Какая-то мелочевка в /etc осталось - но все остальное в netinfo. И есть утилиты командной строки (и гуевые) для доступа к этой инфе.

http://en.wikipedia.org/wiki/NetInfo_Manager

> ??? Вы на дерево gconf хоть раз смотрели? /apps/<имя приложения> - И ВСЕ.

.gconf/apps/gnumeric/core/gui/toolbars/%gconf.xml , хотя это действительно соответствует паттерну /apps/<имя приложения>

Кстати, всплывает в памяти заявление, что хранить иерархию в файловой системе нерационально.

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

О, кстати, а эти тулзы умеют после сноса gnumeric-а подчищать его конфиги?

>> Тот самый демон с нотификацией об изменении или что-то ещё?

> Централизованное управление. Контроль над тем, кому что можно менять в настройках. Достаточно?

Вполне. Можно ещё, для закрепления, рассказать use case для двух перечисленных требований?

> Слишком сложно. И, главное, все это будет присутствовать в каждой программе как кусок откопипащенного и покореженного кода. Нафига?

Ну да, я это отметил чуть ниже.

>> Некоторые называют такой подход "забивание гвоздей микроскопом"

> Ээээ использования API конфигурирования для получения конфигурации - это уже считается чрезмерным???

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

>Действительно тупо. Особенно если учесть, что букоффки бывают большие и маленькие, что минус и подчеркивание часто путаются и пр. В общем, удачи...

Минус и подчёркивание не путаю, пользуюсь автодополнением, большие буквы в путях не встречал, потому что не пользуюсь поделиями некоего VaSyAP00PkIn.

>??? Вы на дерево gconf хоть раз смотрели? /apps/<имя приложения> - И ВСЕ.

Нет, не ВСЁ, к сожалению. Иерархия в конфиге не нужна.

>Купите хороший монитор. Измените dpi. Или используйте gconftool-2.

Первые два "совета" суть издевательство. gconftool-2 попробую.

>Да не надо лезть в XML вообще! Нечего пользователю там делать (Вам - тем более, с Вашими проблемами)! ВООБЩЕ. Это внутренняя деталь реализации. Для пользователей есть нормальные тулзы, как графические, так и командной строки.

К сожалению, из-за гномовского ХЫГ'а в самом приложении покрутить мало что можно. А параметры командной строки - тоже внутренняя часть реализации?

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

Программист не имеет права ставить удобство для себя выше удобства для пользователя.

>> Как нормальная локализация помогает преодолеть языковой барьер при чтении одного локализованного файла разными пользователями?

> Очень просто! Нет файла - нет проблемы. Есть хранилище. Являющееся ... не важно чем. Доступ к нему - только через утилиты, которые сами заботятся о локализации.

А при сбое на диске, повредившем эту волшебную утилиту, что делать?

А при неинтерактивном развёртывании некоей сетевой конфигурации эти настройки можно вбить в аналог солярисного flash-архива, чтоб потом на установленной системе они были уже указанными а не дефолтными? Чтоб после единственной перезагрузки получить работающую систему.

Это не какое-то из пальца высосанное требование, это реальный use case, который очень хорошо получался именно с текстовыми конфигами, редактируемыми скриптами.

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

al@gaa:~$ la | grep '\.[A-Z]'
.DCOPserver_gaa__0
.DCOPserver_gaa_:0
.DCOPserver_gaa_localhost_11
.DCOPserver_gaa_localhost:11
.FBReader
.ICEauthority
.QuiteInsaneFolder
.VirtualBox
.Wammu
.Xauthority

> .gconf/apps/gnumeric/core/gui/toolbars/%gconf.xml

Не надо туда лезть! Только /apps/gnumeric/core/gui/toolbars и соотв. утилиты. Оставьте Вы уже свою привычку шариться по файловой системе. Вы же не лезете ручками в БД мускула или оракла!

> О, кстати, а эти тулзы умеют после сноса gnumeric-а подчищать его конфиги?

Нет. Потому что никому не нужно. Сегодня я снес гнумерик, завтра поставил снова - что ж мне, заново его конфигурировать?

> Можно ещё, для закрепления, рассказать use case для двух перечисленных требований?

Enterprise. Куча параметров могут быть устанавливаемы централизованно - от обоев до адреса прокси. И закрыть доступ к этим параметрам. Да, туда же Kiosk Mode.

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

Демон - не "свой" - а один на весь десктоп. Централизованное управление и контроль - это ВОЗМОЖНОСТИ. Которые, кстати, в простейшей реализации отсутствуют - и соотв. ничего не стоят. Но реализацию можно при необходимости усложнить - без изменения программ.

>Нет. Потому что никому не нужно. Сегодня я снес гнумерик, завтра поставил снова - что ж мне, заново его конфигурировать?

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

> Иерархия в конфиге не нужна.

No comments.

> А параметры командной строки - тоже внутренняя часть реализации?

Нет. gconftool-2 часть пользовательского интерфейса. По идее, должен быть стабильным и поддерживаемым.

> Программист не имеет права ставить удобство для себя выше удобства для пользователя.

Разумеется. Поэтому для удобства пользователя есть соотв. тулзы. Если для Вас удобство является синонимом "редактируется в vim" - Вы принадлежите к меньшинству, на которое программисты вправе забить болт, если это противоречит другим требованиям.

Re^2: Чем плох GConf?

>> .gconf/apps/gnumeric/core/gui/toolbars/%gconf.xml

> Не надо туда лезть! Только /apps/gnumeric/core/gui/toolbars и соотв. утилиты. Оставьте Вы уже свою привычку шариться по файловой системе. Вы же не лезете ручками в БД мускула или оракла!

Да это так, для примера. Так что там с неэффективностью выкладывания иерархии в файловую систему?

>> О, кстати, а эти тулзы умеют после сноса gnumeric-а подчищать его конфиги?

> Нет. Потому что никому не нужно. Сегодня я снес гнумерик, завтра поставил снова - что ж мне, заново его конфигурировать?

Это не аргумент. Ну вот не понравился мне гнумерик, решил я его в порыве ярости удалить, запуржить, да снести конфиг. А иначе как ковырянием ручками в фс, я его удалить не смогу.

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

Вот из $XDG_CONFIG_HOME я и сам удалить смогу. А из иерархии, в которую не рекомендуется лазать руками, кто его вычистит?

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