Вызывает интерес вот такой еще разрез

[Лекс Айрин]

Делайте.

И сделаю. Не знаю когда, но меня никто и не торопит.

[alexs]

1. XML с подсветкой синтаксиса читается еще лучше. (Откройте любой XML в редакторе лазаруса)

Вы не поверите - lfm тоже имеет подсветку синтаксиса

2. Компактнее? Да не очень. файл main.lfm 201292 байта. main.xml 215583 байта.

А если убрать пробелы? То что вы видите - это отображение времени разработки. И его чтение глазами гораздо удобнее чем чтение XML (нет идиотских <> и открывающих-закрывающих тэгов)

3. Сжимается в ресурсы. main_lfm.zip 29799 байт main_xml.zip 31263 байта

А уж в ресурсах dfm/lfm вообще в бинарном виде. Без всякого сжатия. Не будете отрицать что бинарное представление меньше чем xml? Да и работает оно быстрее - в смысле чтение ресурсов.

Моё мнение - работает нормально, удобно. Зачем притягивать технологию которая изначально для этого не предназначена? Только потому что можно? Нафиг-нафинг...

[resident]

Безумие какое-то

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

[vitaly_l]

чтение глазами гораздо удобнее чем чтение XML (нет идиотских <> и открывающих-закрывающих тэгов)

должен всех расстроить или обрадовать, но из XML - делают основу для всего. Даже исходники программ под Windows уже в XML + HTML5. Суть предположительно в том, что в XML проще отследить n r, которых глазами не видно, а иногда они(n r) являются частью кода. Честно говоря, других плюсов от использования XML я не вижу. Сейчас всё в лазарусе нормально, лично мне удобен и более читабелен текстовый формат. Однако, в некоторых случаях, когда n r являются частью кода, например: "строки" или "блока" или "серии блоков" - то без XML их увидеть невозможно, т.к. нет начального символа и нет конечного и в n r подсветить нечего... исключением вариантов подсветки являются блокноты, для программистов, но если включить подсветку n r то код становится нечитабельным...

Добавлено спустя 8 минут 88 секунд:
В принципе XML это поимённая пара: begin end;...

[resident]

нет идиотских <> и открывающих-закрывающих тэгов

Паскалист со стажем в миллионы begin-end пишет про идиотские теги человеку с табличкой "пишу на С".

Добавлено спустя 40 секунд:

В принципе XML это поимённая пара: begin end;...

Ха, читаете мои мысли

[alexs]

должен всех расстроить или обрадовать, но из XML - делают основу для всего.

Очередной универсал... Но серебряная пуля тут не получится...

Суть предположительно в том, что в XML проще отследить n r,

Это уже относится к неструктурированным данным. Но у нас ведь разговор про вполне конкретное применение DFM/LFM.

Я в принципе готов мериться с XML в качестве транспорта обмена неструктурированными данными между разнородными приложениями. Но вот строить на нём внутренние коммуникации - бред.

Добавлено спустя 1 минуту 41 секунду:

Паскалист со стажем в миллионы begin-end пишет про идиотские теги человеку с табличкой "пишу на С".

Не надо передёргивать.
begin/end паскале несут смысловую нагрузку и логику.
А в xml этого нет - тэги - это просто ограничители строк.

[vitaly_l]

Но вот строить на нём внутренние коммуникации - бред.

Согласен на все 100%! т.к. сейчас сделано удобнее...
просто Ваде явно лень писать новый парсер, а для XML уже готовые парсеры есть, вот он и пожаловался в народ...
Хотел, чтобы ему облегчили труд парсинга и переделали формат под XML... кстати наверняка экспорт есть... для андроида или около того...

[alexs]

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

А чего жаловаться - берём исходники лазаря и смотрим. Парсер LFM построен на базе класса TParser из модуля classes. Конвертер в xml есть в исходниках лазаря (где именно - не скажу, не искал).
А ломать то что есть - не надо.

[vada]

alexs TParser неплох, но вот такую шнягу он не разбирает.

Код: Выделить всё

Glyph.Data = {
        36040000424D3604000000000000360000002800000010000000100000000100
        2000000000000004000064000000640000000000000000000000FFFFFF00BB6A
        346BBA6530BCBB6631EDBA6630F7BA6630F7BA6630F7BA6530F7BA652FF7B965
        2EF7B9652EF7B9642EF7B9642EEFB7622CBDB7622E63FFFFFF00FFFFFF00BC69
        33DEF8F1EAF2F7ECDFFDF6EBDEFFF6EADEFFF6EADCFFF6EADCFFFAF3EBFFFAF3
        EBFFFAF2EAFFFCF7F3FFFCF8F4FDFEFEFDF0B7602AD5FFFFFF00FFFFFF00BF71


Говорит что это токен Integer, и в другом его не убедить. Ну если только ковычки поставить.

[Vadim]

Вот это странно.

Дык это то как раз и не странно если учесть, что мало кто правит описание формы в "ручном" режиме. Естественно я не беру во внимание форс-мажор, когда описание формы портится из-за некорректной работы IDE.
И ещё хочу внести свои пять копеек по поводу "begin ... end".
Мне, как человеку с плохим зрением такая особенность Паскаля черезвычайно нравится. А вот Си (и Си-подобные) не люблю за его "бледность" границ блоков кода. В XML с этим делом вообще полный ужас.

[vitaly_l]

Мне, как человеку с плохим зрением такая особенность Паскаля черезвычайно нравится. А вот Си (и Си-подобные) не люблю за его "бледность" границ блоков кода. В XML с этим делом вообще полный ужас.

Так ведь XML - это есть ПОПЫТКА Си подобных языков привести их код к нормальному begin ... end... И дело даже не в зрении, т.к. любой человек стремиться к экономии ресурсов, а на идентификацию скобочек... вот этих { } и вот от этих ( )... тратится ГРОМАДНОЕ количество энергии. И они Си подобные языки, решили исправить это путём XML и теперь весь код у них в XML... короче XML - это плохое подражание паре begin ... end... (НО В xml есть и свои плюсы... ) Однако, даже в этом примере, даже при условии что я знаю что я написал, разделение вот этих { } от вот этих ( ) - занимает несколько секунд... в то время как begin ... end - идентификация меньше секунды... всё просто... не так ли?

[SSerge]

И они Си подобные языки, решили исправить это путём XML и теперь весь код у них в XML..

Бгг... Чушь какая...
Хочется пнуть си, так уж издевайтесь например над оформлением функций:

Код: Выделить всё

   #ifdef   __USE_GNU
extern FILE *fopencookie (void *__restrict __magic_cookie,
           const char *__restrict __modes,
           _IO_cookie_io_functions_t __io_funcs) __THROW __wur;
#endif



типа кто больше понаставит подчеркиваний и if/endif и что означает куча макросов где ни попадя

[vitaly_l]

Хочется пнуть си, так уж издевайтесь например над оформлением функций

Я последнее время, когда смотрю на Си-код, то даже в теории не могу понять, как, я, на Си... умудрился написать довольно сложную программу?
И она до сих пор работает. И когда вижу конструкции на подобии приведённой Вами... готов молиться на памятник Паскалю, в благодарностях за созданный им человеко-понимаемый язык, т.к. зная всего 33-55% языка - я свободно понимаю ЛЮБОЙ код.

Ну какой нормальный ребёнок сможет догадаться что "VOID" - это "функция" или "процедура", при условии, что, в Паскале они носят свои имена?
В языке: Си - сделано: ВСЁ!, ЧТО ТОЛЬКО МОЖНО БЫЛО ВЫДУМАТЬ, чтобы было как можно сложнее писать код! Ассемблер и тот проще, для понимания, нежели Си!

Прости меня Вада и все кто прочитает - я не сдержался... эмоции захлестнули... XML - безусловно более удобен для понимания нежели Си!
.

[sts]

Зачем в Lazarus-е реализован такой странный формат данных с описание формы?
Почему, например, не XML? Или это реликты с времен начала начал Lazarus-а?

мда, странные вопросы, ответы доступны невооруженным взглядом

DFM ~ 1996 год
XML ~ 1998 год

DFM немного лучше JSON (жаль в JSONе нельзя написать, по естественным причинам, так - { field: type {} } - народ, в вебразработке, ссалбы кипятком)
DFM намного лучше XML

[debi12345]

вот этих { } и вот от этих ( )... тратится ГРОМАДНОЕ количество энергии

Как с этими скобочками разбирается "PhpStorm" видели ?
(становишься около завершающей скобочки, и вверху всплывает строка, показывающая строку кода с начинающей скобочкой, ессно с правильным отступом)

ПС: лично мне "скобки" больше нравятся (можно стыковать их парность) и хотел бы их в Паскале (ессно как вариант).