Вопрос о совместимости Delphi и Lazarus

[Евгений]

Здравствуйте.
Имеется несколько крупных проектов на Delphi 7 для работы с БД (Postgres). В проектах используются некоторые нестандартные пакеты (напр. для работы с БД, расширенный TDbGrid). Необходимо перекомпилировать проекты под Linux. Хотелось бы спросить у знающих людей, стоит ли попытаться переписать эти проекты с Delphi на Lazarus, или только время убьется? Получится это сделать или все же проще будет переписать их с нуля на том же Qt?

[Sniper]

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

[SergKam]

с Делфи в qt C++, это что шутка?
Подкоранать интерфейс под линукс или переписывать с нуля? странный выбор.
Прежде чем спрашивать попробуй сначала сам, узнай какие проблемы возникнут, а потом думай.
День потратишь, зато потом жалеть не будешь.
По своему опыту скажу, что портировать всетаки легче
(алгоритм есть, какието компоненты можно и заменить на другие или портировать)

[Guest]

Здравствуйте.
Имеется несколько крупных проектов на Delphi 7 для работы с БД (Postgres). В проектах используются некоторые нестандартные пакеты (напр. для работы с БД, расширенный TDbGrid). Необходимо перекомпилировать проекты под Linux.

У лазаря поддержка БД пока рудиментарная, и пока ничего не менятся, увы.
Есть другой FPC IDE for Linux/Windows - MSEGUI/IDE. В нем поддержка БД уже весьма приличная ( также исправляются и обходятся ошибки FPC SQLDB ), есть мощные средства для БД редактирования - lookup-компоненты, grids виде репитеров - для редактирования через выпадающие списки, решенная проблема интернационализации, и т.д.

Один минус ( или не минус ? ) - демонстративно несовместим с Дельфи, и потому нельзя пользоваться дельфийской докой (а своей пока нет - проект очень молодой ) ...

[Replicator]

а своей пока нет

И потому приходится все делать на ощупь. В том-то и проблема. Хотя, на мой взгляд, он обходит Лазарус по многим параметрам, но работать в нем после Delphi уж очень непривычно.

[haword]

Угу поэтому почему то он мне и не понравился MSEGUI этот, хотя по наворотом очень даже приличный блин, но огромная неохота автора хотябы в мелочах делать совместимость с Делфи делает очень не удобную работу в нем Если бы только автор не начал выдумывать свои типы и методы для обработки то можно было бы уже на лазаря забивать

[Sniper]

>>У лазаря поддержка БД пока рудиментарная, и пока ничего не менятся, увы.

Если судить по SVN то они только БД и занимаются )
Да и по свойствам в Object Inspector'e всё правктически одинаковое за небольшим исключением.

Вот чего пофиксили недавно(последняя ревизия 9243):
Implements dbgrid.SelectedRows (issue 1849) rev9234
fixed autofillcolumns scroll columns (issue 2032) rev9225
Notifications Col/Row inserted/deleted for ColCount and RowCount issue rev9216
row autonumbering only if there is no text in cell (issue 2033) rev9215
fixed grids picklist losing focus when dropdown the combobox list rev9123
enabled more events for TDBComboBox (issue 1976) rev9116

После выхода 0.9.14 (rev9050)

Этот MSEGUI/IDE мне вообще не понравился... в первую очередь отстойным интерфейсом

[Guest]

>>У лазаря поддержка БД пока рудиментарная, и пока ничего не менятся, увы.

Если судить по SVN то они только БД и занимаются )
Да и по свойствам в Object Inspector'e всё правктически одинаковое за небольшим исключением.

После выхода 0.9.14 (rev9050)

Этот MSEGUI/IDE мне вообще не понравился... в первую очередь отстойным интерфейсом

Тогда поговорим предметно...

Пробовал уже, и обжигался... Попробуйте что-нибудь серьезное сделать под БД на Лазарусе... Даже отталкиваясь от более-менее безглючной ZeosLIB ( "чистый" FPC SQLDB без обходных маневров и оперативного патчинга пока ну очень сыроват )

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

Автор MSEGUI вообще считает, что Borland слегка перемудрила, когда проектировала БД -поддержку (да и не только ), то бишь - не отделила мух от котлет, попытавшись предвосхитить самые изощренные пожелания программистов ( шокировать "фичами" - чтобы лучше продавалось ?).
Судя по темпам, LCL пытается всю эту изощренку воспроизвести, но, даже не сделав и 1/3 части ( не говорю уже про MIDAS, lookup&nested datasets ) - порядком подзапуталась. Очень хочется верить, что в этом направлении она не зайдут в тупик...
Народ, кто полюбил Лазарус - ну помогите же его команде наконец - не словом, а делом !
Для начала, лично я считаю, что огромной услугой Лазурусу стала бы "прикрутка" JVCL3 ( не путать с JCL ) - там по части БД ( да и не только ) очень много классного сделано.

А MSEGUI слеплен по принципу "Если хорошо подумать, то всегда можно найти изящное решение, сложив мозаику из хорошо подгоняемых стеклышек". И ведь складывается, если начать дуиать не по-ходу, а заранее.

Ну и беда лазаруса ( во многом из-за FPC ) - гигантские exe-фалы (про UPX просьба не упоминать). Мегабайты после смартлинка и страйпа - ну никак не напрашиваются на обновление через модемные соединения и т.п.
( MSEGUI сложный БД проект с задействованной ( транзитом через SQLDB ) variants-поддержкой ( 150K в exe ), WIDESTRING как тип по-умолчанию для реально беспроблемной интернационализации ( тоже дофига КБайт ), антиалиасингом шрифтов, GUI с косметическими наворотами, и SQLDB - вписывается в 1.1 М ).
Но - недавно прочитал в новостях точку зрения автора MSEGUI - "не предназначено для начинающих". Короче, думайте о себе как хотите

Вообще, оба эти проекта - отличные задумки, и у них разные ниши. Лазарус - для перекомпиляции с Дельфей, а MSEGUI - для новых проектов повышенной производительности...

[Sniper]

>>MSEGUI - "не предназначено для начинающих"
Да. Точно не для начинающих потому что из-за "/C:/Downloaded/mseide_bin_0_8b/bin/i386-win32/" я не могу создать/открыть ниодин файл... ещё я не могу закрыть диалог выбора файла крестиком - что бесит.

[haword]

Автор MSEGUI вообще считает, что Borland слегка перемудрила, когда проектировала БД -поддержку (да и не только ), то бишь - не отделила мух от котлет, попытавшись предвосхитить самые изощренные пожелания программистов ( шокировать "фичами" - чтобы лучше продавалось ?).

Ну и зря он так считает! Хотя поправде говоря каждый делает то что он хочет, но если бы он не называл своими именами классы которых есть аналоги у Борландского паскаля, думаю согласишся что будет лучше? Автору надо немного поубавить самомнения о себе

GUI с косметическими наворотами

Блин не знаю какие они там косметические но что вид отстойный это да! Говоришь автор все продумывает хорошо? Гм, сделал я как то попытку сделать поприличнее чтобы меню выглядело и не типа аля-вынь95, так оказывается прорисовка всех елементов гую делается одной функцией!!! И пришлось именно для меню добавлять другую. Потом по ходу программы частенько у елементов встречалась дефаултовая окраска не по родительскому елементу а по прописанному в коде значению! Потому как изменив цвет на родителе, лежащий на нем компонент не перекрашивался, может щас и исправил он это дело но раньше так было! Правильно если он увлекся базами данных то понятно почему тогда интерфейс так страдает. Грид у него гм, блин вид отстойнее не придумаешь, только название что грид! Сообщения типа SendMessage не послать елементам так как они их нормально не отрабатывают, например попытался я найти как перерыть несколько сообщений как в LCL или VCL типа TWMSize TLMSize и обломись! OnPaint нету не у одного елемента чтобы допустим его нарисавать так как мне нравиться! Обработчки событий лежат в одном месте с параметрами в инспекторе. Чтобы добратся до какогото параметра 10 плюсиков нажать надо и это я бы не сказал что продуманная логика работы. Короче пока этот гуй по моему мнению находится на стадии поделки с уклоном на базы данных. Даже у LPTK и то красивее елементы блин чем у MSEGUI! Но если этот товарисч все приведет в норму и ПРЕСТАНЕТ КЛАССЫ И МЕТОДЫ ПИСАТЬ МЕЛНЬКИМИ БУКВАМИ отмазываясь что так удобнее у него появятся еще поклонники!

[STAKANOV]

Блин не знаю какие они там косметические но что вид отстойный это да! Говоришь автор все продумывает хорошо?
...

Самое интересное что в линуксе у меня это не вызывало проблем. А вот в виндовсе уже слишком чужеродно все получилось (интерфейс должен быть привычным, а не оригинальным!). Мартин гордится тем, что сделал что-то оригинальное. Причем утверждает, что основывается прежде всего на собственном опыте работы с Delphi и Kylix. Точнее на неудовлетворенности возможностями этих продуктов. В результате получились у него элементы с огромным количеством параметров. ИМХО: перемудрил.

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

И хотя MSEide мне понравилось, но от MSEgui теперь держусь подальше.

По теме: учитывая поставленный изначально вопрос советую в сторону MSEide+MSEgui даже не смотреть.

[STAKANOV]

Ну и беда лазаруса ( во многом из-за FPC ) - гигантские exe-фалы (про UPX просьба не упоминать). Мегабайты после смартлинка и страйпа - ну никак не напрашиваются на обновление через модемные соединения и т.п.

К этому предлагаю относится как к детским болезням. Над этой проблемой в команде FPC ведется работа. В частности по созданию собственного внутреннего линкера. Т.е. существует вероятность, что к окончанию процесса портирования это проблема будет решена ... Я надеюсь ...

[Guest]

Ну и беда лазаруса ( во многом из-за FPC ) - гигантские exe-фалы (про UPX просьба не упоминать). 

К этому предлагаю относится как к детским болезням. Над этой проблемой в команде FPC ведется работа. В частности по созданию собственного внутреннего линкера. Т.е. существует вероятность, что к окончанию процесса портирования это проблема будет решена ... Я надеюсь ...

Линкер тут ни при чем... Все дело в дизайне, и в РЕАЛЬНОЙ НЕОБХОДИМОСТИ большого количества кода. Те же variant&widestring (за что команде FPC надо памятник ставить) реально можно уменьшить, только переписав на ассемблере. В довесок, эти модули имеют менежеров, запускаемых в initialization-секциях - то есть сразу отжирают оперативку.

В части GUI (lazarus, msegui, ... ) линкер может помочь, только если писать специально под смартлинк - спецтрюки, маленькие классы, минимальные отличия от дефолтных значений ( чтобы при чтении свойств из ресурсов - не вызывать лишние функции для их настройки, и дофига чего еще ). Посморите на внутренности lib*.a, созданных при компиляции Lazarus-проектов, и офигейте - сколько методов тащит за собой каждый класс - какой уж тут сматлинк, если ничего нельзя отбросить! Отсюда, из-за больших классов, и необходимости переинитить длинный список их свойств (а умолчания отличаются в разных ОС и GUI-тулкитах !) и происходит громадный размер - инициализация одного большого класса влечет за собой вызов по цепочке чуть не целого тулкита... Короче, сам ехе - в несколько мегабайт, так еще и тулкит - эдак 10...20 весит.

[Guest]

Блин не знаю какие они там косметические но что вид отстойный это да! Говоришь автор все продумывает хорошо?
...

Самое интересное что в линуксе у меня это не вызывало проблем. А вот в виндовсе уже слишком чужеродно все получилось (интерфейс должен быть привычным, а не оригинальным!). Мартин гордится тем, что сделал что-то оригинальное. Причем утверждает, что основывается прежде всего на собственном опыте работы с Delphi и Kylix. Точнее на неудовлетворенности возможностями этих продуктов. В результате получились у него элементы с огромным количеством параметров. ИМХО: перемудрил.

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

И хотя MSEide мне понравилось, но от MSEgui теперь держусь подальше.

По теме: учитывая поставленный изначально вопрос советую в сторону MSEide+MSEgui даже не смотреть.

Ну что вы к виду прицепились - обычный консервативный подход человека, проработавщего в отрасли немерянное количество лет.
К тому же хуки на внешнось и поддержание выбранного стиля во всех элементах проекта - закачешься ( frame & face templates ), очень напоминает CSS . Лично я в том проекте нашел хорошую поддержку баз данных, средств их представления и редактирования - причем все на базе сверхскоростного FPC ( спасибо команде! ) SQLDB, и отличную UTF8-интернационализацию, причем без необходимости отказа от KOI8.

И тоже мне претензия - все идентификаторы малыми буквами, самим не смешно ?

"Огромное количество параметров" MSEGUI сделано не через свойства, а через enums - кстати, чрезвычайно экономичное решение. А если еще принять в внимание, что автор каждую мелочь рассматривает и проверяет под возможности сматрлинкинга...

И насчет в одиночку... Должен же кто-то начать - как и любое дело. Теперь он опубликовал проект... а после некоторого "причесываения" и вычистки crash-багов - собирается выложить и на SVN. Какое теперь в одиночку ?

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

[wellx]

Для начала, лично я считаю, что огромной услугой Лазурусу стала бы "прикрутка" JVCL3 ( не путать с JCL ) - там по части БД ( да и не только ) очень много классного сделано.

Проблема в диком нежелании ментейнеров проекта снимать зависимость от win32 кода и интерфрейсов. Этот вопрос регулярно в ньюсах пробегает и ответ тот же. Не будем! Но, если выдрать некий субсет компонентов,то вполне возможно, но тогда это будет отдельный продукт. ИМХО в JVCL3 слишком много ненужных компонентов, зачастую дублирующих друг друга.