Перенос пользовательских карт (maps.ini)

[feya]

Идея разделения карт на пользовательские и непользовательские мне както не очень нравится.

[feya]

Единственный походу выход делать менеджер карт (чего почемуто не хочется))

[gisof]

Единственный походу выход делать менеджер карт

Зачем?
По моему варианту всё очень просто и логично.

[feya]

gisof
И мы опять будем иметь эти раздражающие цифры)

[svp]

И мы опять будем иметь эти раздражающие цифры)

Нет. С очерёдностью карт в меню можно бороться точно так же как и с положением в меню в целом.
Только кроме пути надо будет хранить ещё две циферки и никакой уникальности от этих циферок не требовать.
Первая цифра -- это номер группы в меню. Меню может разбиваться разделителями "-". Так вот, свойство MenuSubgroup будет определять номер подгруппы внутри меню по указанному пути.
Таким образом Если в меню уже есть два разделителя, то значит в нём три группы: 0, 1, 2. Если группа пуста, то её нижний разделитель делается невидимым либо не создаётся вовсе.
Так если в Планету подключается карта с группой №50, а в меню реально есть только 3 группы, то создаётся 4-я группа и карта закрепляется за ней. Если после этого регистрируется карта с группой 30, то создаётся ещё одна группа перед 50-й. Другими словами делается столько групп, сколько их разных встречается среди карт.
С номерами карты в группе можно поступать также:
То есть сортируем карты в группе по номеру (NumberInGroup), если встретились одинаковые номера, то сортируем по алфавиту.
В maps.ini все эти три параметра (MenuPath, MenuSubgroup, NumberInGroup) можно перекрывать.
В настройках же планеты достаточно будет простого списка карт и двух кнопок для перемещения их вверх и вниз на одну позицию. При перемещении карты выше, её номер меняется местами с предыдущей картой. Ниже -- с последующей. Если карты с одинаковыми номерами, то перенумеровываем все карты ниже текущей. Вот и всё.
Все настроенные (перекрытые) пользователем параметры для каждой карты со ссылкой по гуиду будут храниться в maps.ini. Если какой-то карты вдруг не станет, а потом её положат в кталог карт снова, то все настройки её останутся=).

PS
И ещё:
1. Цифры мы имеем и здесь, но задумываться о них пользователю не надо будет.
2. Менеджер карт становится тривиальным. Всё сводится к перемещению элементов списка взад/вперёд. Ну или по дереву. Можно, ведь, отрисовать в настройках меню в виде дерева.
3. Могу подготовить соответствующий фрейм для настроек.

[Parasite]

а как решить очерёдность карт?
тоесть сначала обрабатываетется файл с картами программы (maps.ini) а затем уже пользовательский , и карты пользователя будут однозначно ниже в списке.....

А так ли нужна эта сортировка в одном меню?
Стандартные карты будут определяться сортировкой в maps.ini, пользовательские - в custommaps.ini. Зачем их смешивать в одно меню - я не представляю. Лично я это вижу так:

<ВЫБОР КАРТЫ>
|-карта А из maps.ini
|-карта B из maps.ini
|-карта C из maps.ini
...
|-карта Z из maps.ini
|-ПОЛЬЗОВАТЕЛЬСКИЕ КАРТЫ
___|-карта А из custommaps.ini
___|-карта B из custommaps.ini
___|-карта C из custommaps.ini
___...
___|-карта Z из custommaps.ini

Либо пункт "ПОЛЬЗОВАТЕЛЬСКИЕ КАРТЫ" выше всех пунктов из maps.ini

[svp]

Сортировка и группировка нужна однозначно. И я написал к4ак это сделать.
А насчёт того зачем она нужна... Для конечного пользователя совершенно неважно какие карты пользовательские, а какие предустановленные. Для него важно какие карты ему нужны, а какие нет. Важно также, чтобы при поиске нужной карты среди двух десятков не приходилось пробегать взглядом весь этот огромный список. Если учесть сколько сейчас развелось картографических ресурсов и снимков в инете, группировка в подменю и разделителями, а также сортировка нужна однозначно.
Механизм перекрытия настроек, который я предложил, позволит также перекрывать помимо положения карты в меню по умолчанию ещё и сочетание клавиш карты, URL в инете, и прочие ЛЮБЫЕ настройки не меняя при этом zip-архив карты или слоя.
Реализуется механизм элементарно:
1. Загружается ini-файл настроек карты из zip'а.
2. По GUID'у карты находится соответствующая группа в maps.ini и все параметры из неё переносятся в текущий загруженный контекст карты (с заменой естественно). То есть происходит слияние двух ассоциативных списков, реализованных, например, на TStrings парами Value[Name].
3. Инициализируется карта из получившегося контекста.

Минимум переделок.
При сохранении настроек карты или слоя всё сохраняем в maps.ini в группу с таким именем какой GUID карты.

[Parasite]

Механизм перекрытия настроек, который я предложил, позволит также перекрывать помимо положения карты в меню по умолчанию ещё и сочетание клавиш карты, URL в инете, и прочие ЛЮБЫЕ настройки не меняя при этом zip-архив карты или слоя.

Зачем обязательно ЗИП? Хай буде куча файлов в директории, например, /CONFIG/ (менять - проще, открытие программой - быстрее, сама программа - хоть немного, но проще)?

При сохранении настроек карты или слоя всё сохраняем в maps.ini в группу с таким именем какой GUID карты.

maps.ini будет поставляться в комплекте с сасом, насколько я понимаю?

[svp]

Зачем обязательно ЗИП? Хай буде куча файлов в директории, например, /CONFIG/ (менять - проще, открытие программой - быстрее, сама программа - хоть немного, но проще)?

Затем, что карта должна готовиться однажды и впредь должна распространяться в неизменном виде. Выглядеть это будет как плагин. Кинули карту в каталог -- она есть, не кинули -- её нет. Для непродвинутых коих много. И вообще, программы надо писать для людей, а не для IT-шников.
А ещё, если карту поправил пользователь под себя, то при распаковке новой версии мы имеем ту же проблему, что сейчас с maps.ini: карты из комплекта со стандартными настройками заменят отредактированные пользователями карты. Разносить комплектные и пользовательские карты по разным каталогам -- это плохо. К тому же этот вариант ничем не лучше того, что предложил я.

maps.ini будет поставляться в комплекте с сасом, насколько я понимаю?

Нет. Maps.ini ни в коем случае поставляться не должен. Это файл с чисто пользовательскими настройками. Если его нет, то он создаётся по умолчанию.
В этом файле хранятся все перекрытые пользователем частные настройки карт (как комплектных, так и своих собственных).

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

[Parasite]

Затем, что карта должна готовиться однажды и впредь должна распространяться в неизменном виде.

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

Или я что-то не так понял?

Выглядеть это будет как плагин. Кинули карту в каталог -- она есть, не кинули -- её нет.

Чем плох вариант "Кинули строчку в custommaps.ini (единственный файл, а не фолдер с кучей ЗИПов) -- карта есть, не кинули -- её нет"?
Открыть Блокнотом инишник и вписать единственную строчку сможет даже нуб, имхо (либо я совсем уж потеряю веру в человечество).

И вообще, программы надо писать для людей, а не для IT-шников.

Странное утверждение. Почему-то гинекологические инструменты делают для гинекологов, ювелирные - для ювелиров, химическую посуду - для химиков, а газоинтерферометры - для физиков газовых сред. С какого перепугу в мир пришла мысль о том, что компьютерные инструменты (по сложности реализации и функционалу на порядки превосходящие всё вышеперечисленное вместе взятое) должны быть доступны всем желающим, тем более "апупею апофеоза" - необученным нубам из оного числа всех желающих? Довольно забавно было бы дать обезьяне шелл-доступ к вычислителю коллайдера - и ожидать, что она тут же с успехом - и, главное, правильно и разумно! - начнет им пользоваться. Кесарю-кесарево, имхо.
Впрочем, оффтоп. Но моя бы воля - я бы даже для доступа в инет заставлял бы как минимум тест на IQ проходить (в фидо, кстати, просто так как раз и не пущали - и там много лучше и интереснее в данном смысле)

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

Ну дак и чем же плох вариант с custommaps.ini? Ничего нигде не перезаписывается, правь сколько влезет - штатными средствами системы, переделка САСа минимальна. Что и требовалось. Ась? При необходимости сохранения именно настроек текущего пользователя - точно так же приходим к файлу settings_<username>.ini, либо просто тупо customsettings.ini. Полей же в эти файлы можно наклепать каких угодно, в том числе и для сортировки контента.
В чем Вам видятся минусы данного метода?

Нет. Maps.ini ни в коем случае поставляться не должен. Это файл с чисто пользовательскими настройками. Если его нет, то он создаётся по умолчанию. В этом файле хранятся все перекрытые пользователем частные настройки карт (как комплектных, так и своих собственных).

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

То же должно касаться и файла настроек программы. Если я однажды настроил прокси, зачем мне это делать каждый раз при распаковке новой версии?

Тогда Вам в файлик customsettings.ini (не входящий в состав САСа, соответственно неперезаписываемый, и соответственно создающийся с основными дефолтовыми полями юзера если такого файлика не было найдено в папке САСа при первом старте оного). То же самое и про пути к кэшу (в тот же файл), итд итп. Можно даже все настройки из custommaps.ini утоптать сюда же, в юзерозависимый файлик - и обойтись им одним на каждого конкретного юзера САСа, чтобы не распыляться по миллионам несколькобайтных инишников\зипов. Ведь основная идея - не дать каждой настройке по своему файлу, а вынести юзерозависимые настройки от системозависимых, исключив затирание первых при апдейтах собственно программы. В самих же юзерозависимых настройках можно нагородить что угодно (опять же без распыления на миллион отдельных инишников).

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

+1