Новый GLib с новой спецификой хранения настроек.

Каком, нахрен, будущем?!! Насрали и забыли уже сто раз. EMACS мать его! ion3 полно этого настоящего.

Как известно, гном - это такая винда.

> видно же, что в пику QSettings

При чём тут QSettings? Может, всё-таки Ksycoca?

>О ужас, с каких это пор оно стало в XML ?

XML-style, не более. В Apache тоже XML-style.

а) читабельно

4.2

Чем нечитабельно, если с подсветкой синтаксиса? Берем тот же fonts.conf - все читабельно и ясно.

Молодец, премию пхп быдлокодера заработал.

>На кой болт для локальных файлов какие-то неудобные локальному же пользователю протоколы?

Проблема не в протоколах и синтаксисах, а в том, что нормального интерфейса для изменения настроек нету. Ладно, оставим графические программы, там разработчик сам может впихнуть окно с настройками. Другое дело в консольных программах, всяких демонах.
Ну попытались сделать что-то в дебиане (deb-conf) и что? Все равно, при добавление новой опции в дебиане мейнтейнер может это пропустить и в итоге нужно самому лезть в конф-файлы - фэйл одним словом. Так что, будь стандарный и гибкий интерфейс (который использовали все разрабы и это было стандарт де-факто) проблема в чем и как хранить конф-файлы отпадет разом.

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

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

Там была озвучена такая проблема, что гору зависимых текстовых конфигов, а особенно XML, не удаётся быстро и эффективно парсить (конкретно, в момент загрузки). Соответственно, решили хранить это в бинарном формате, который считывается быстро. Если его формат открыт (а он открыт), нет проблем его парсить кому угодно. Вы ведь примирились с sqlite в браузерах и плеерах? Ну вот, это примерно то же самое.

Естественно, можно будет сделать поверх бинарного формата файловую системку. Тогда внешне это будет выглядеть как файлики ini (и работать будет быстро, кстати), а детали внутренней реализации никого не колышут. Есть процессы в виде файлов, есть устройства в виде файлов, ну будут еще и конфиги в виде файлов, только со своей FS. Т.е. каждый своим любимым редактором сможет их править, grep будет работать как обычно и всё такое. И все забудут, что где-то в глубине конфиги хранятся в бинарном виде.

Другое дело, что получается, что в винде, оказывается, изначально было сделано ПРАВИЛЬНО. Это вызывает у многих баттхёрт. Бинарный формат, оказывается, быстрее и экономнее, чем XML.

Главное не забыть его открыть.

> Ну слава не знаю кому, но hal из Xorg попёрли.

Нужно вещи называть своими именами. Его не попёрли, а проект hal закрыли.

>Вы ведь примирились с sqlite в браузерах и плеерах?

Во-первых, откуда множественное число? Во-вторых, у меня places.sqlite 42мб весит, в отличие от парукилобайтных (в среднем) конфигов, и дергается всяко почаще. Немного другие задачи, не?

никто не мешает намудрить, что-то и в редакторе.

а если кто-то от большого ума один бинарный файл сотрёт?

я говорю про то, что текстовой файл (всё равно в каком формате) легко поправить, в случае чего, в любом редакторе, а бинарный ИМХО без спец софта никак, его можно только стереть, а случаи бывают разные :-).

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

И ini файлы (key-value) уже сейчас далеко не везде подходят.

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

+, будет как раньше, фс в бинарном редакторе восстанавливать. Компромиссный вариант иметь скомпилированые версии конфигов в бинарный формат.

>Мне же НЕ НАДО! И бинаря этого НЕ НАДО!
А лично мне вообще пофиг.

>В чем именно проблема, в добавлении новых опций в конфиг?

Берем настройки конфигурации шрифтов в fonts-config. Вы видите там опции для настройки отдельного шрифта? Нет, вот и я не вижу, но мне это надо.

Хотя писать туда дефолтные значения тоже как-то не комильфо.

По идее, должно настраивать все в том размере каком это максимально возможно. К сожалению deb-conf никогда не выходил на роль интерфейса всего и вся - лишь приблуда для лентяев. Безусловно потенциал есть.

>Берем настройки конфигурации шрифтов в fonts-config. Вы видите там опции для настройки отдельного шрифта? Нет, вот и я не вижу, но мне это надо.

Таких вообще не существует, или они просто не заданы? Не понял, причем тут именно формат конфигов.

> XML-style, не более. В Apache тоже XML-style.

Так любой конфиг, имеющий древовидную структуру, можно обозвать XML-style. Главное, что оно не-XML и выглядит читабельно.

Чем нечитабельно, если с подсветкой синтаксиса?

Не читабельно вообще, подсветка не сильно улучшает ситуацию

Берем тот же fonts.conf - все читабельно и ясно.

бугага

>По идее, должно настраивать все в том размере каком это максимально возможно. К сожалению deb-conf никогда не выходил на роль интерфейса всего и вся

по идее ровно наоборот — debconf настраивает все в минимально возможном объеме

блин, вот только собрался поучить, как обращаться с gconf'ом...

samy_volosaty> так сейчас реестра физически нет. он виртуальный.

Зато чистилка реестра реальная.

>Естественно, можно будет сделать поверх бинарного формата файловую системку.

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

И не говори, это же надо такое придумать!

> >О ужас, с каких это пор оно стало в XML ?

XML-style, не более. В Apache тоже XML-style.

Это какой-то вами придуманный термин. В Apache как раз нормальные текcтовые конфиги, а не эти убогие ini, которых хватает только на самое примитивное и не эти монстры - XML конфиги, которые можно читать и (не дай бог) править ручками, только когда они не слишком большие, а с учетом перенасыщенности самого XML, они очень быстро становятся большими.

XML удобны для универсального машинного парсинга, но не человеческого.

>XML удобны для универсального машинного парсинга, но не человеческого.

Тоже распространённое заблуждение.

>Другое дело, что получается, что в винде, оказывается, изначально было сделано ПРАВИЛЬНО. Бинарный формат, оказывается, быстрее и экономнее, чем XML.

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

> >XML удобны для универсального машинного парсинга, но не человеческого.

Тоже распространённое заблуждение.

Это не заблуждение, это факт. Если вы намекаете на то, что XML не так уж удобен для машинного парсинга, то я не об этом, я о том, что для машинного он боле удобен, чем для человеческого. А вообще все зависит от задачи. В задаче создания конфигов, которые предполагается к чтению и изменению человеком, XML не лучший выбор.

>Вы ведь примирились с sqlite в браузерах и плеерах?

Хотел бы я увидеть свою фразу из которой это бы следовало. Тут многие опять не понимают разницы между парсером и синтаксическим анализатором. «Парсить» конфиг может только программа для которой этот файл родной. Не важно на каком иврите он написан, эта программа поймёт его смысл. Любая сторонняя видит только xml-соглашение о кодировании (протокол взаимодействия со статической сущностью - xml файлом). То есть смысла не видит, диапазона значений не видит, ограничений нет. Многие тут пытались аппелировать к дополнительным стандартам которые нужно наложить на xml, и типа всё будет в ажуре. Но при внимательном, а не оголотелом, рассмотрении вместо одного стандарта на каждый конфигурационный файл мы получаем 3 на все и обратно 2 на каждый. Ищите здесь же про xml-config-и, кому действительно интересно. То есть цель xml-party всех нагнуть, но нарисовать в графике красивое дерево из настроек любого ПО. Налицо самоцель и самолюбование. Ещё раз. Если разработчик ПО не даст вам рюшечного интефейса для настройки своей программы, но никакой xml-parser вам не поможет. Всё это будет бутафория.

И обратно не ясно что неофиты нашли такого в xml чего они не увидели в S-expression, YAML, INI. Опять новые люди на планете? Г'еволюционэры? ПТУ? Обычно историю не учат омерикосы - им не положено, у них авианосцы есть, а нашим что, завидно?

>Если вы намекаете на то, что XML не так уж удобен для машинного парсинга, то я не об этом, я о том, что для машинного он боле удобен, чем для человеческого.

Не распарсил, но key=vakue парсится в несколько строк на любом языке. А вот с конструкциями <key>value</key> придётся подключать внешний xml-парсер.

нет, не так. Надо так: <key><operation «assign»>value</operation></key>. Но можно и атрибутом и куча других вариантов кошерных.

Вот именно, ваш парсер дал сбой и вы сделали не верный вывод о моем высказывании. Повторю еще раз - я говорил не о том, как трудно парсить машинно, речь о том как трудно парсить XML «глазами». Вы как раз про то как трудно парсить машинно.
Лично я не люблю XML в любом виде.

>В Apache тоже XML-style

В Apache зачетный формат. Хотя, имхо, можно было добавить = между клюючами и значениями, получился бы xml

>Вы как раз про то как трудно парсить машинно.

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

Не лопни смотри, деточка :}