Я уже добавил

Да, совсем забыл: можно будет (наконец!) реализовать скрытие свойств (вспомним про color и button), прописав - например - такое:

А теперь второй вопрос -- кто это все будет лопатить, или конвертор предлагаешь сделать

А зачем останавливаться?! За историю HiAsm было множество изменений, ставивших всё с ног на голову. Вот примеры:

• Переход к кодогенерации для Delphi (2.x -> 3.x)
• Появление других пакетов: PocketPC, затем FTCG (a.k.a. Web), в будущем - RTCG (если допилит Dilma)
• Отказ от хранения списка элементов в ini-файле и переход к БД
• Установка компонентов и проектов: hic -> his -> ini
• Появление менеджеров - новая парадигма "невидимых связей"

------------ Дoбавленo в 19.56:
nesco, если обговорим схему описания, то беру на себя разработку преобразователя (консольного).

О! А тебе вот этот метод не кажется на порядок перспективней, предложенного тобой -- загнать все свойства в базу данных Elements.db, вместо XML

nesco, "не смеши мои шнурки!" (с)
А кто во втором посте темы кричал, что XML редактировать сложно? А db-то ещё сложнее!

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

iarspider, я ещё непротив иметь немецкий, французский, арабский и иврит.
------------ Дoбавленo в 20.12:
По поводу быстродействия : У нас что, при выборе пакета, грузятся все ini-файлы пакета в память?

nesco, помнится anderstudio приводил пример работы с XML-файлом на VBS. А в состав FPC (по кр. мере 2.4.0, за остальные не скажу) входят уже готовые классы для работы с XML.
------------ Дoбавленo в 20.24:

Да хучь язык народности бонго-бонго.

т.е. скажем прогрессу НЕТ?

Давайте подойдем к решению проблемы сначала с позиции цифр, чтобы исключить из дальнейшего обсуждения вещи, которые поддаются объективной оценки. И так, имеем три озвученных варианта хранения конфигурации элемента с поддержкой нескольких языков:
1) INI файл специального формата для хранения собственно конфигурации и некоторое хранилище для текстов с переводом(файл индексов или БД)
2) хранение всей информации в БД
3) хранение всей информации в XML

Расположим эти три варианта по следующим критериям:

• скорость загрузки 1) средняя
  2) самая высокая
  3) самая низкая

• удобство редактирования и сопровождения 1) самое высокое (никаких инструментов не нужно, минимум дополнительной информации, легко переносится в SVN)
  2) самое низкое (невозможно править без дополнительных программ, невозможно хранить на SVN "в оригинале")
  3) среднее (можно править без инструментов, но не желательно - появляется вероятность нарушения связей)

• ухудшение скорости загрузки с увеличением сложности конфигурации 1) среднее
  2) минимальное
  3) высокое

• простота расширения, наращивания возможностей в будущем 1) средне
  2) сложно
  3) легко

Выводы делаем самостоятельно.


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

Dilma, я думаю nesco имел в виду, что надо хоть одну версию "вылизать", а потом уже заниматься большими реформами (кстати, оригинальный тег темы - "HiAsm +1", т.е. предложения для HiAsm 5.x).

Сейчас напишу конвертер и посмотрю тайминги. Что-то мне кажется, что не так уж и медленно xml читается.

надо в bug трекере ввести статус "For next HiAsm generation" на случай таких пожеланий...


если в одном формате лишней информации больше, чем в другом, то он по определению должен медленнее парситься(при условии оптимальных реализаций). Однако показанные тобой возможности привязок видимо говорят в пользу данной технологии. Тут не столько интересна реализация линковки с данными для перевода, сколько отображение одних св-тв(точек) в зависимости от других. К примеру у элемента Convertor могло бы быть такое описание:


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

Существует готовое решение работы с http://en.wikipedia.org/wiki/Property_list. Исходники на REALbasic. Пару недель назад занялся переносом кода на VBScript и есть потребность в этом же классе для JScript. Могу поделиться информацией.

Ну, не обязан созданием только и исключительно ECreator заниматься. Я, например, когда создаю элемент на основе готового объекта, часто копирую из его хелпа список методов-свойств и закидываю в секцию [Methods], а в ECreator'е дошлифовки идут. Иногда удаётся вставить сразу с описаниями. Если бы я только на ECreator полагался бы я бы многого не осилил бы.
Следующим шагом для xml-щиков обычно идёт хранение самого xml в zip'e (как в docx, xlsx, fb2z)

[flood]На десятке форумов которые я посещаю тегом офтопика является [off], я привык набирать теги вручную (интернет был дорогой, а теги отображались на картинках кнопок, которых я не видел т.к. отключал их). Просьбу использовать стандартный тег, а не придумывать новый я в соответствующей теме озвучивал. Буду пытаться пользоваться нестандартом, но 100% гарантии дать не могу.
зы некоторые движки, помнится, позволяли паралельное существование полного и сокращенного написания тега [bold] - [ b], [ offtopic] - [off][/flood]

db или xml, результат будет один, желающих(могущих) написать компонент будут еденицы .
Руки порочь от ini .