"Andre2Buddy" <81820@users.rsdn.ru> сообщил/сообщила в новостях следующее: news:3415608@news.rsdn.ru...
> Здравствуйте, уважаемые!
>
> Перед выпуском американской версии (95%) готов русский релиз:
> http://blogogist.ru/setup.exe
>
> Поругайте программу, пожалуйста.
[skip]
Очень сильно не понравилась ее похотливость до установки в автозагрузку... Зачем?
Ну ладно там первый раз при первом запуске, дык и то простите меня, это не приложение ежеминутного использования — по хорошему бы спросить пользователя надо.
Но вот я из нее вышел, MsConfig`ом вынес из автозагрузки, покодил, пофлудил, bash почитал — ну какие там у нашего брата еще повседневные обязанности... Дай думаю еще разок посмотрю... Запустил — у-у-упс, она опять уже в автозагрузке. Не стоит так делать! Имхо! Конечно.
Остальное чуть позже — еще ковыряю.

Здравствуйте, Carc, Вы писали:

C>Очень сильно не понравилась ее похотливость до установки в автозагрузку... Зачем?
C>Ну ладно там первый раз при первом запуске, дык и то простите меня, это не приложение ежеминутного использования — по хорошему бы спросить пользователя надо.
C>Но вот я из нее вышел, MsConfig`ом вынес из автозагрузки, покодил, пофлудил, bash почитал — ну какие там у нашего брата еще повседневные обязанности... Дай думаю еще разок посмотрю... Запустил — у-у-упс, она опять уже в автозагрузке. Не стоит так делать! Имхо! Конечно.
C>Остальное чуть позже — еще ковыряю.

Спасибо за ответ. Хорошо, наверно, по умолчанию отключу из автозагрузки, гляну другие ридеры. А отключается легко: Инструменты\Параметры\Загружать программу при старте Windows

> Спасибо за ответ. Хорошо, наверно, по умолчанию отключу из автозагрузки, гляну другие ридеры. А отключается легко: Инструменты\Параметры\Загружать программу при старте Windows
1) Проблема может быть и не столько в том, что при первом запуске прописывается — пусть так, хотя можно и в инсталлере для этого галочку сделать (по умолчанию может быть и включенной). Проблема в том, что когда я ее отключил — она при следующем запуске прописалась автоматом снова. Прописываться автоматом при первом запуске это приемлемо, но вот потом не стоит принимать решения за пользователя.

2) Ширина сплиттеров очень маленькая — это плохо. Их приходится таскать постоянно, чтобы увидеть или полностью статью или список и.т.д. Это область данных — там должен хозяйничать пользователь. А попасть в них мышом — это труба полная. Неудобно сильно и да причем для весьма частой операции. Имхо стоит увеличить ширину (может быть сделать настраиваемой?). В свое время в Опере меня это чуть до эпилепсии не довело

C>1) Проблема может быть и не столько в том, что при первом запуске прописывается — пусть так, хотя можно и в инсталлере для этого галочку сделать (по умолчанию может быть и включенной). Проблема в том, что когда я ее отключил — она при следующем запуске прописалась автоматом снова. Прописываться автоматом при первом запуске это приемлемо, но вот потом не стоит принимать решения за пользователя.

Спасибо, понял, проверю прописывание автозапуска в реестре, это баг, этого не должно быть.

C>2) Ширина сплиттеров очень маленькая — это плохо. Их приходится таскать постоянно, чтобы увидеть или полностью статью или список и.т.д. Это область данных — там должен хозяйничать пользователь. А попасть в них мышом — это труба полная. Неудобно сильно и да причем для весьма частой операции. Имхо стоит увеличить ширину (может быть сделать настраиваемой?). В свое время в Опере меня это чуть до эпилепсии не довело

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

Здравствуйте, Andre2Buddy, Вы писали:


C>>1) Проблема может быть и не столько в том, что при первом запуске прописывается — пусть так, хотя можно и в инсталлере для этого галочку сделать (по умолчанию может быть и включенной). Проблема в том, что когда я ее отключил — она при следующем запуске прописалась автоматом снова. Прописываться автоматом при первом запуске это приемлемо, но вот потом не стоит принимать решения за пользователя.

AB>Спасибо, понял, проверю прописывание автозапуска в реестре, это баг, этого не должно быть.
Точно бага! Проверил еще разок — любой запуск и она автоматом включается в HKCU\...\Run

C>>2) Ширина сплиттеров очень маленькая — это плохо. Их приходится таскать постоянно, чтобы увидеть или полностью статью или список и.т.д. Это область данных — там должен хозяйничать пользователь. А попасть в них мышом — это труба полная. Неудобно сильно и да причем для весьма частой операции. Имхо стоит увеличить ширину (может быть сделать настраиваемой?). В свое время в Опере меня это чуть до эпилепсии не довело

AB>Обязательно увеличу, я уже думал об этом, и сделаю возможность настройки тоже, это сделать легко, а пользователю приятно
Было бы просто замечательно. Если будет интересно, вот ссылочка на мои возмущения по поводу стимуляции эпилепсии Оперой

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

Здравствуйте, Carc, Вы писали:

C>Точно бага! Проверил еще разок — любой запуск и она автоматом включается в HKCU\...\Run

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

AB>>Обязательно увеличу, я уже думал об этом, и сделаю возможность настройки тоже, это сделать легко, а пользователю приятно
C>Было бы просто замечательно. Если будет интересно, вот ссылочка на мои возмущения по поводу стимуляции эпилепсии Оперой

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

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

Тоже верно, уберу балун.

Здравствуйте, Andre2Buddy, Вы писали:

AB>Здравствуйте, Carc, Вы писали:

C>>Точно бага! Проверил еще разок — любой запуск и она автоматом включается в HKCU\...\Run

AB>Это в Висте?
Не, XP SP3
AB>Проверил в разных операционках, и не смог воспроизвести. А измененные параметры программы сохраняются в реестре, может нет прав?
Где посмотреть в реестре параметры?
Она вообще как определяет первый запуск? (в смысле первый запуск, то пишемся в автозапуск)?
AB>Думаю, в этом может быть дело, а т.к. по умолчанию стоит автозапуск, то при каждом запуске программы она прописывается в автозагрузку.
Не-е! Эксперимент чистый: стартанули винду, подчистли автозапуск, запустили — упс, опять в HKCU. Повторил в течении сеанса — всё то же самое.

C>Где посмотреть в реестре параметры?

C>Она вообще как определяет первый запуск? (в смысле первый запуск, то пишемся в автозапуск)?

Если ранее сохраненные параметры не найдены в HKCU\Software\Blogogist\Buddy то устанавливаются стандартные значения где автозапуск при старте Windows включен. Я предполагаю, что ветка HKCU\Software\Blogogist\Buddy не создается. Можно изменить что-нить в настройках, закрыть программу и снова запустить и глянуть изменились ли настройки. При выключении чекбокса "автозагрузка" при закрытии окна из реестра HKCU\...\CurrentVersion\Run сразу удаляется "Blogogist Buddy".

AB>>Думаю, в этом может быть дело, а т.к. по умолчанию стоит автозапуск, то при каждом запуске программы она прописывается в автозагрузку.
C>Не-е! Эксперимент чистый: стартанули винду, подчистли автозапуск, запустили — упс, опять в HKCU. Повторил в течении сеанса — всё то же самое.

Может нет разрешения не ветку HKCU\Software? Если есть права, буду думать в чем может быть причина.

Здравствуйте, Andre2Buddy, Вы писали:

C>>Где посмотреть в реестре параметры?

C>>Она вообще как определяет первый запуск? (в смысле первый запуск, то пишемся в автозапуск)?

AB>Если ранее сохраненные параметры не найдены в HKCU\Software\Blogogist\Buddy то устанавливаются стандартные значения где автозапуск при старте Windows включен. Я предполагаю, что ветка HKCU\Software\Blogogist\Buddy не создается. Можно изменить что-нить в настройках, закрыть программу и снова запустить и глянуть изменились ли настройки.
1) Ветка в реестре есть, все ок. Права тоже. Но называется она все таки ... Buddy! (воскл. знак на конце) Может оно?
2) По любому первый запуск должен как-то иначе наверное определяться... Имхо, конечно! Я и сам так делаю — но в любом случае настройки сбросываются в реестр, а не только при изменении.

AB>При выключении чекбокса "автозагрузка" при закрытии окна из реестра HKCU\...\CurrentVersion\Run сразу удаляется "Blogogist Buddy".
Не-е-е, это не очевидно! Поймите — про msconfig в курсе все: клик-клик и готово, мне конечно же очевидно что настройка автозапуска наверняка где-то в софтине есть — но где она там (и потом то я, а то Дуся Блондинова — она может и не знать). В любом случае, MsConfig это проще и быстрее, привычнее что ли. Имхо, нужно автоматом прописываться только при первом запуске — в остальных случаях ни-ни. Ну я не знаю — при первом старте один единственный параметр писать в реестр куда-нить (ну или в ini-файл рядом с софтиной).

AB>>>Думаю, в этом может быть дело, а т.к. по умолчанию стоит автозапуск, то при каждом запуске программы она прописывается в автозагрузку.
C>>Не-е! Эксперимент чистый: стартанули винду, подчистли автозапуск, запустили — упс, опять в HKCU. Повторил в течении сеанса — всё то же самое.

AB>Может нет разрешения не ветку HKCU\Software? Если есть права, буду думать в чем может быть причина.
Права есть...

PS: А юзера захотят portable-версию, что тогда? Как с настройками в реестре быть?

C>1) Ветка в реестре есть, все ок. Права тоже. Но называется она все таки ... Buddy! (воскл. знак на конце) Может оно?
C>2) По любому первый запуск должен как-то иначе наверное определяться... Имхо, конечно! Я и сам так делаю — но в любом случае настройки сбросываются в реестр, а не только при изменении.

Все верно, "Buddy!", но ошибку воспроизвел, дошло да, логическая ошибка, пофиксил.

C> мне конечно же очевидно что настройка автозапуска наверняка где-то в софтине есть — но где она там (и потом то я, а то Дуся Блондинова — она может и не знать). В любом случае, MsConfig это проще и быстрее, привычнее что ли.

Это так она может не знать и наверняка не простит Только один раз буду сохранять.

C>PS: А юзера захотят portable-версию, что тогда? Как с настройками в реестре быть?

Что-нибудь придумаю можно будет сохранять настройки в xml, экспорт в xml будет, проблем не должно быть.

Здравствуйте, Andre2Buddy, Вы писали:
C>>1) Ветка в реестре есть, все ок. Права тоже. Но называется она все таки ... Buddy! (воскл. знак на конце) Может оно?

AB>Все верно, "Buddy!", но ошибку воспроизвел, дошло да, логическая ошибка, пофиксил.
Можно обновить с сайта?

C>>PS: А юзера захотят portable-версию, что тогда? Как с настройками в реестре быть?
AB>Что-нибудь придумаю можно будет сохранять настройки в xml, экспорт в xml будет, проблем не должно быть.
А если не секрет, откуда такая любовь к XML? Почему все так стремятся хранить настройки в XML? Что это дает-то!?!

Понятно когда документ имеет солидную взаимоувязанную внутренную структуру, всякие валидации там — тут как бы XML самое оно. А в настройках же обычно по любому просто набор скалярных величин, которые как-то интерпретируются читающим софтом да причем как правило только им одним — т.е. обмена инфой с "внешним миром" вроде как нет. И один фиг все равно нужно писать код на случай, настройки в XML нет или какой-то подобной ситуации...
Вопрос из интереса, философского так сказать плана — отчего так модно стало настройки в XML сохранять? Зачем?

PS: Никогда не забуду как в одной конторе году в 2000-ом (какой тогда XML-то!?! ) за каким-то хреном переписывали настройки на XML... Причем именно переписывали! Ладно б там с нуля — оно и понятно — как известно "русский витязь прямо не ходит" . Но вот зачем абсолютно нормально работающие настройки переписывать было непонятно.

При этом все равно настройки представляли собой банальные пары ключ-значение, и XML сам по себе ничего не давал (о portable-версиях там и речи быть не могло: жесткий банковский корпоратив на SQL-сервере).

От начальства добиться, нафига менять шило на мыло не удалось даже под газами, единственное помню, что заказчик в сильном возбудении, почти в оргазме, кричал "XML! XML! XML!". А т.к. заказчик был из Швейцарии, то предложение выпить стаканчик-другой водочки и посмотреть с практической точки зрения на ценность его предложений было не очень воспринято...
Не понимают они почему-то как водочка может помогать в проектировании, да и вообще в выработке требований к програмному обеспечению.

В общем, мне действительно интересно: что дает XML в хранении настроек? Можно даже вообще теоретизируя...
Или это просто так принято теперь? Такой стандарт де-факто?

C>Можно обновить с сайта?

К понедельнику бету (http://blogogist.ru/bsetup.exe) выложу, т.к. сейчас дописываю возможность выбора индивидуального стиля к каналу, надо дописать и проверить.

C>>>PS: А юзера захотят portable-версию, что тогда? Как с настройками в реестре быть?
AB>>Что-нибудь придумаю можно будет сохранять настройки в xml, экспорт в xml будет, проблем не должно быть.
C>А если не секрет, откуда такая любовь к XML? Почему все так стремятся хранить настройки в XML? Что это дает-то!?!

C>Понятно когда документ имеет солидную взаимоувязанную внутренную структуру, всякие валидации там — тут как бы XML самое оно. А в настройках же обычно по любому просто набор скалярных величин, которые как-то интерпретируются читающим софтом да причем как правило только им одним — т.е. обмена инфой с "внешним миром" вроде как нет. И один фиг все равно нужно писать код на случай, настройки в XML нет или какой-то подобной ситуации...
C>Вопрос из интереса, философского так сказать плана — отчего так модно стало настройки в XML сохранять? Зачем?

У меня все просто, xml недолюбливаю, но т.к. rss&atom&opml есть подмножество xml и, написав модуль для парсинга opml, естественным путем, даже не задумываясь, храню поисковые шаблоны, шаблоны каналов, условий и действий в xml. Пользователь может их глянуть, отредактировать. А сохраненные сообщения каналов и свойства каналов храню в своем формате.

C>PS: Никогда не забуду как в одной конторе году в 2000-ом (какой тогда XML-то!?! ) за каким-то хреном переписывали настройки на XML... Причем именно переписывали! Ладно б там с нуля — оно и понятно — как известно "русский витязь прямо не ходит" . Но вот зачем абсолютно нормально работающие настройки переписывать было непонятно.

C>При этом все равно настройки представляли собой банальные пары ключ-значение, и XML сам по себе ничего не давал (о portable-версиях там и речи быть не могло: жесткий банковский корпоратив на SQL-сервере).

C>От начальства добиться, нафига менять шило на мыло не удалось даже под газами, единственное помню, что заказчик в сильном возбудении, почти в оргазме, кричал "XML! XML! XML!". А т.к. заказчик был из Швейцарии, то предложение выпить стаканчик-другой водочки и посмотреть с практической точки зрения на ценность его предложений было не очень воспринято...

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

C>Не понимают они почему-то как водочка может помогать в проектировании, да и вообще в выработке требований к програмному обеспечению.

и не только водочка

C>В общем, мне действительно интересно: что дает XML в хранении настроек? Можно даже вообще теоретизируя...

Наглядность, возможность редактирования. В данном случае преимуществ перед ini не вижу, но я пристрастен. Между ini и xml выбрал xml, хотя стоит добавить и ini по выбору пользователя. Даже скажу, что хранить настройки программы правильней в ini, ибо проще и читать, и редактировать, и сохранять.

C>Или это просто так принято теперь? Такой стандарт де-факто?

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

Здравствуйте, Andre2Buddy, Вы писали:
AB>К понедельнику бету (http://blogogist.ru/bsetup.exe) выложу, т.к. сейчас дописываю возможность выбора индивидуального стиля к каналу, надо дописать и проверить.
OK!

AB>У меня все просто, xml недолюбливаю, но т.к. rss&atom&opml есть подмножество xml и, написав модуль для парсинга opml, естественным путем, даже не задумываясь, храню поисковые шаблоны, шаблоны каналов, условий и действий в xml. Пользователь может их глянуть, отредактировать. А сохраненные сообщения каналов и свойства каналов храню в своем формате.
Ну в этом случае логично! а) Код есть — нехай работает б) Есть обмен (программа — пользователь с редактором наперевес) тоже имеет смысл, т.к. более широкораспространненый формат.

AB> Не раз встречал программы, хранящие такие данные в xml, которые хранить не только не нужно, но и глупо, часто используемые базы данных, к примеру.
Аналогично! К чему лишние байты то!?! Которые можно просто хранить в том же ини, который даже блондинка отредактирует!?! Опять же в вышеприведенном примере пришлось еще и тащить за собой MSXML!?!

C>>В общем, мне действительно интересно: что дает XML в хранении настроек? Можно даже вообще теоретизируя...
AB>Наглядность, возможность редактирования. В данном случае преимуществ перед ini не вижу, но я пристрастен. Между ini и xml выбрал xml, хотя стоит добавить и ini по выбору пользователя. Даже скажу, что хранить настройки программы правильней в ini, ибо проще и читать, и редактировать, и сохранять.

C>>Или это просто так принято теперь? Такой стандарт де-факто?
AB>да, любовь к xml объясняется тем, что он считается стандартом передачи данных.

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

Здравствуйте, Carc, Вы писали:

C>Здравствуйте, Andre2Buddy, Вы писали:
AB>>К понедельнику бету (http://blogogist.ru/bsetup.exe) выложу, т.к. сейчас дописываю возможность выбора индивидуального стиля к каналу, надо дописать и проверить.
C>OK!

Бету выложил, добавил хоткей Ctrl+ALt+C дабы быстро скрыть каналы, теперь можно регулировать ширину разделителей и размер их кнопки.

AB>>У меня все просто, xml недолюбливаю, но т.к. rss&atom&opml есть подмножество xml и, написав модуль для парсинга opml, естественным путем, даже не задумываясь, храню поисковые шаблоны, шаблоны каналов, условий и действий в xml. Пользователь может их глянуть, отредактировать. А сохраненные сообщения каналов и свойства каналов храню в своем формате.
C>Ну в этом случае логично! а) Код есть — нехай работает б) Есть обмен (программа — пользователь с редактором наперевес) тоже имеет смысл, т.к. более широкораспространненый формат.

Тоже так думаю, а иначе бы в ini сохранял.

AB>> Не раз встречал программы, хранящие такие данные в xml, которые хранить не только не нужно, но и глупо, часто используемые базы данных, к примеру.
C>Аналогично! К чему лишние байты то!?! Которые можно просто хранить в том же ини, который даже блондинка отредактирует!?! Опять же в вышеприведенном примере пришлось еще и тащить за собой MSXML!?!

Согласен полностью, XML для баз данных совершенно не нужен, так как сохраняется сложней и парсится медленней, а c MSXML вообще не хочу связываться .

Здравствуйте, Andre2Buddy, Вы писали:

AB>Здравствуйте, Carc, Вы писали:

C>>Здравствуйте, Andre2Buddy, Вы писали:
AB>>>К понедельнику бету (http://blogogist.ru/bsetup.exe) выложу, т.к. сейчас дописываю возможность выбора индивидуального стиля к каналу, надо дописать и проверить.
C>>OK!

AB>Бету выложил, добавил хоткей Ctrl+ALt+C дабы быстро скрыть каналы, теперь можно регулировать ширину разделителей и размер их кнопки.
1) Скачал, гут. Проблема с автозагрузкой решена.
2) Сплиттеры — отлично. Только может быть по умолчанию сделать пошире? Все-таки мало где можно настраивать ширину сплиттеров, обычный пользователь может и не догадаться? (типа Good Default UI template...)

Здравствуйте, Carc, Вы писали:

AB>>Бету выложил, добавил хоткей Ctrl+ALt+C дабы быстро скрыть каналы, теперь можно регулировать ширину разделителей и размер их кнопки.
C>1) Скачал, гут. Проблема с автозагрузкой решена.
C>2) Сплиттеры — отлично. Только может быть по умолчанию сделать пошире? Все-таки мало где можно настраивать ширину сплиттеров, обычный пользователь может и не догадаться? (типа Good Default UI template...)

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

Здравствуйте, Carc, Вы писали:

C>>>В общем, мне действительно интересно: что дает XML в хранении настроек? Можно даже вообще теоретизируя...
AB>>Наглядность, возможность редактирования. В данном случае преимуществ перед ini не вижу, но я пристрастен. Между ini и xml выбрал xml, хотя стоит добавить и ini по выбору пользователя. Даже скажу, что хранить настройки программы правильней в ini, ибо проще и читать, и редактировать, и сохранять.

XML дает

1) Автоматическую совместимость сверху вниз и снизу вверх
2) При использовании DOM парсера код зачитки/сохранения простой и читабельный
3) Сами данные опций часто организованы в иерархии\древовидные структуры (плагин 1. панель 1. панель 2. плагин 2. панель 1 ... ) что опять же делает работу с ними через xml простой и гарантирует совместимость. В ini такое сохранить уже сложнее и выглядит не так естественно.

А вообще меняем конечно, то же на то же. Но причин "недолюбливать" xml не вижу. Хотя ваше дело, я например как сохранял опции в xml, так и буду, и не думаю что когда нибудь мне придется рвать на себе волосы и кричать " Ну почему я тогда не послушал Carc'а ??!!!11одинодин"

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Carc, Вы писали:

C>>>>В общем, мне действительно интересно: что дает XML в хранении настроек? Можно даже вообще теоретизируя...
AB>>>Наглядность, возможность редактирования. В данном случае преимуществ перед ini не вижу, но я пристрастен. Между ini и xml выбрал xml, хотя стоит добавить и ini по выбору пользователя. Даже скажу, что хранить настройки программы правильней в ini, ибо проще и читать, и редактировать, и сохранять.

А>XML дает

А>1) Автоматическую совместимость сверху вниз и снизу вверх
ОГО! Серьезный прорыв! Без XML с совместимостью никак!!! Подумываю вот унитаз портировать на XML — а это все эти ручки спусковые некузяво как-то, а так заслал XML-пакет... и поплыло
А>2) При использовании DOM парсера код зачитки/сохранения простой и читабельный
Зачем в опциях DOM-parser? Чего в опциях там "Document Object Model!"? Не! Ну конечно ini по сравнению с XML совсем нечитабельный, и не простой....
А>3) Сами данные опций часто организованы в иерархии\древовидные структуры (плагин 1. панель 1. панель 2. плагин 2. панель 1 ... ) что опять же делает работу с ними через xml простой и гарантирует совместимость. В ini такое сохранить уже сложнее и выглядит не так естественно.
Сами почитайте что написали по сути "XML дает нам возможность работы с XML"? Ну и что? Зачем мне с опциями работать через XML? Причем тут совместимость — совместимость чего с чем, и почему ее нельзя гарантировать без XML?
Вот переносимость ОК, согласен — это довод для многоплатформенности.

А>А вообще меняем конечно, то же на то же. Но причин "недолюбливать" xml не вижу.
Кто сказал что недолюбливаю? Вопрос был про конкретное применение к хранению опций: какие плюсы и минусы... Причем тут XML вообще?
А>Хотя ваше дело, я например как сохранял опции в xml, так и буду,
Где предложение на что-то переходить? С этого все и началось, что исторически в старых проектах как-то обычно опции по другому хранились. Соответветственно и вопрос: "зачем" и "переходить" на XML? Что дает? Переносимость\портабельность случай важный — но все же частный. Вот автор Blogogist`а привел вменяемый и четкоаргументированный довод — есть код разбора XML, доточить его до опций дело трех минут, почему бы нет. Веский довод — повторное использование.

А>и не думаю что когда нибудь мне придется рвать на себе волосы и кричать " Ну почему я тогда не послушал Carc'а ??!!!11одинодин"
Та не! -1 — за логику, и -2 за умение читать вопрос.
Вопрос был об уже существующем коде: вот есть код для ини-файлов в конкретном проекте, а можно на XML — что даст переход, какие плюсы, какие минусы? А Вы ответили в стиле "всэ побэжали и йа пабэжал"

Интересное наблюдение: код сохранения в ини рядом с exe-шником под Вистой работает, а ваш хваленный XML облажается...
А>
Да совсем евагелисты ананимам моск проели
Для полноты обсуждения осталось только услышать довод "XML — это круто" и засим можно будет считать этот вопрос окончательно решенным

А>>2) При использовании DOM парсера код зачитки/сохранения простой и читабельный
Вдогонку — "простой и читабельный"!?! Хех, этот код вообще не должен наружу торчать — для внешнего кода настройки должны выступать как просто сериализуемая сущность, откуда, как да куда это не забота внешнего кода. Иногда бывает нужно чтобы для внешнего кода были дополнительные возможности указать куда именно сохранить файл там или реестр (тот же импорт\экспорт опций), но это дополнительный интерфейс, который используется только, там где нужен.

"Совершенство — это когда не нечего добавить, это когда нечего убрать" ((С) Экзюпери

Ну а читабельность это не монополия XML, у меня к примеру есть код дня настроек и без XML в три строки, куда читабельнее то!?!

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Carc, Вы писали:

C>>>>В общем, мне действительно интересно: что дает XML в хранении настроек? Можно даже вообще теоретизируя...
AB>>>Наглядность, возможность редактирования. В данном случае преимуществ перед ini не вижу, но я пристрастен. Между ini и xml выбрал xml, хотя стоит добавить и ini по выбору пользователя. Даже скажу, что хранить настройки программы правильней в ini, ибо проще и читать, и редактировать, и сохранять.

А>XML дает

А>1) Автоматическую совместимость сверху вниз и снизу вверх

Да.

А>2) При использовании DOM парсера код зачитки/сохранения простой и читабельный

Да, но мне не нужен MSXML, предпочитаю видеть код, т.к. приходится невалидные xml читать. Да и вообще, RSS они хотели запатентовать и улучшить, с них станется, они и свой вариант XML создадут. Предпочитаю использовать парсер с исходным кодом.

А>3) Сами данные опций часто организованы в иерархии\древовидные структуры (плагин 1. панель 1. панель 2. плагин 2. панель 1 ... ) что опять же делает работу с ними через xml простой и гарантирует совместимость. В ini такое сохранить уже сложнее и выглядит не так естественно.

Согласен, с другой стороны ini надежней, в xml одна ошибка и документ неопределен, а неправильных xml видел достаточно. Узкоспециализированную древовидную структуру могу и сам забацать, будет куда удобнее xml.

А>А вообще меняем конечно, то же на то же. Но причин "недолюбливать" xml не вижу.

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

А> Хотя ваше дело, я например как сохранял опции в xml, так и буду, и не думаю что когда нибудь мне придется рвать на себе волосы и кричать " Ну почему я тогда не послушал Carc'а ??!!!11одинодин"
А>

Раньше использовал ini и все прекрасно сохранялось, и если бы я выбрал способ хранения шаблонов в ini у меня бы тоже не было проблем