R>Второй вариант плюнуть на этот паскаль и переписать все на C++. Но, понимаю, что возможно с лазарусом обойдется малой кровью, R>все же переписыать настолько много придется, что проще на все забить и начать новый проект с нуля по мотивам старого.
Я два года назад нанял программиста в своём городе, который переписал мою программу на Lazarus. Я толком её даже не тестировал, вроде юзеры жалуются на проблемы, продаж почти ноль. Может это специфика ниши. Собственно я конкретной и полезной информации вам дать не могу, просто захотелось что-то написать (а заодно присоединиться к вопросу — тот программист сейчас пропал, возможно мне захочется обновить Lnux-версию своей программы).
R>Самый последний вариант — покупка последней дельфы. Не хочется этого никак.
Почему собственно?
А что последняя Delphi вообще поддерживает Linux?
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Здравствуйте, rean, Вы писали:
R>Так что задумался над Лазарусом. R>У кого есть опыт, скажите, как оно, какие подводные камни?
Теоретически «Лазарус» придумывали для быстрого портирования программ, если они не используют грязные хаки VLC и обращения к API. С другой стороны, могут начаться большие-пребольшие проблемы с AnsiString и WideString.
R>Есть ли способ быстрого портирования исходников дельфы, чтобы не переделывать с нуля все формы?
Формы, возможно, придется переделывать.
R>Как оно работает в маке, есть ли там подводные камни?
Последний раз, когда я смотрел, сама среда работала, что-то пыталась компилировать, но работать на «Маках» скомпиленное отказывалось.
Здравствуйте, rean, Вы писали:
R>Есть куча старых проектов на Turbo Delphi Explorer (аналог Delphi 2006). Все компоненты из стандартной вкладки. Никакого мудреного взаимодействия с VCL.
Рекомендую перейти на Delphi 5. Никаких проблем с иконками нет, хоть 2024*2024. В открытом доступе все можно было найти 15 лет назад и допилить напильником под современные размеры.
Если посмотреть на поставщиков компонентов (TMS) то они выпускают версии под Lazarus... думаю это о чем то говорит... Выдел несколько проектов сделанных на нем.
Большой плюс — он работает на Мак...
Здравствуйте, rean, Вы писали:
R>Но хочется все-же юникод и 64 бит.
Нам в свое время хотелось от Delphi не только юникод и 64 бита, но и компиляцию в OSX и Linux. В результате 64 бита так и не дождались, кодогенерация в OSX была настоклько ужасной, что лучше бы ее вообще не было. В результате оказалось намного проще все переписать на С++ и Qt.
P.S. Мне тут недавно знакомый рассказывал, что Embarcadero в последних версиях окончательно проср@ло все полимеры и теперь некоторые большие проекты (которые раньше собирались на ура в родном компиляторе), теперь не собираются по причине недостатки памяти в переделанном LLVM компиляторе.
Здравствуйте, salnicoff, Вы писали:
S>Здравствуйте, Khimik, Вы писали:
K>>А что последняя Delphi вообще поддерживает Linux?
S>10.2.3 — поддерживает. Но: S>— только 64-битные бинарники; S>— только FireMonkey (никакого VCL).
Здравствуйте, drVanо, Вы писали:
V>P.S. Мне тут недавно знакомый рассказывал, что Embarcadero в последних версиях окончательно проср@ло все полимеры и теперь некоторые большие проекты (которые раньше собирались на ура в родном компиляторе), теперь не собираются по причине недостатки памяти в переделанном LLVM компиляторе.
Здравствуйте, wamaco, Вы писали:
V>>P.S. Мне тут недавно знакомый рассказывал, что Embarcadero в последних версиях окончательно проср@ло все полимеры и теперь некоторые большие проекты (которые раньше собирались на ура в родном компиляторе), теперь не собираются по причине недостатки памяти в переделанном LLVM компиляторе.
W>Вас ввели в глубокое заблуждение. Это не правда.
К сожалению это правда. Компилятору (а он у них теперь везде 32-х битный) теперь не хватает адресного пространтства чтобы слинковать несколько тысяч юнитов. На родном компиляторе (он был 64-х битным) такой проблемы не было.
Здравствуйте, drVanо, Вы писали:
V>К сожалению это правда. Компилятору (а он у них теперь везде 32-х битный) теперь не хватает адресного пространтства чтобы слинковать несколько тысяч юнитов. На родном компиляторе (он был 64-х битным) такой проблемы не было.
Так может нужно на пакеты разбить монолит из нескольких тысяч юнитов?
Здравствуйте, rean, Вы писали:
R>Отбой. Глючит на High-DPI при перемещении между мониторами. R>Все компоненты на форме улетают неизвестно куда, форма ресайзится в нулевые высоту и ширину. Появляются какие-то черные линии в виде артефактов.
R>Всего-лишь включил штатную поддержку High-DPI Windows 10...
Это как в анекдоте:
В администрацию пришла жалоба: "Напротив моего окна — женская баня, это мне мешает!".
Приехала комиссия, смотрят в окно:
— Ничего такого не видно, что бы могло вам мешать…
— А вы на шкаф, на шкаф залезьте!
Также и тут. Юзкейс по перетаскиванию окна между мониторами с разными DPI настолько маловероятен, что я даже не знаю, почему из-за него нужно переписывать работающий софт на другом языке. У меня Delphi Rio в продакшене. Полет нормальный. До 200% масштабирования все работает. Иконки для всех DPI куплены у glyfz.
Здравствуйте, rkcsoft, Вы писали:
R>Здравствуйте, drVanо, Вы писали:
V>>К сожалению это правда. Компилятору (а он у них теперь везде 32-х битный) теперь не хватает адресного пространтства чтобы слинковать несколько тысяч юнитов. На родном компиляторе (он был 64-х битным) такой проблемы не было.
R>Так может нужно на пакеты разбить монолит из нескольких тысяч юнитов?
Специально для вас выделю жирным шрифтом: На родном компиляторе (он был 64-х битным) такой проблемы не было.
Здравствуйте, drVanо, Вы писали:
V> P.S. Мне тут недавно знакомый рассказывал, что Embarcadero в последних версиях окончательно проср@ло все полимеры и теперь некоторые большие проекты (которые раньше собирались на ура в родном компиляторе), теперь не собираются по причине недостатки памяти в переделанном LLVM компиляторе.
У знакомого проекты на билдере? Просто в Delphi LLVM используется только для линукса и мобильных платформ.
Здравствуйте, rudzuk, Вы писали:
V>> P.S. Мне тут недавно знакомый рассказывал, что Embarcadero в последних версиях окончательно проср@ло все полимеры и теперь некоторые большие проекты (которые раньше собирались на ура в родном компиляторе), теперь не собираются по причине недостатки памяти в переделанном LLVM компиляторе.
R>У знакомого проекты на билдере? Просто в Delphi LLVM используется только для линукса и мобильных платформ.
Не у знакомого, а у крупной компании, в которой он работает. Да, на билдере.
Здравствуйте, rudzuk, Вы писали:
R>У знакомого проекты на билдере? Просто в Delphi LLVM используется только для линукса и мобильных платформ.
Он (drVano) перешёл на qt с Delphi и теперь при каждом удобном случае набрасывает на вентилятор.
Но не понимает, что не у всех в приложениях 5 форм, как у него. Ну и визуальная часть у него не главное.
Здравствуйте, rean, Вы писали:
R>Когда сидел на дельфе, считал, что с Борланд/Inprise/Emba придется терпеть, с глюками IDE терпеть, с неюникодом терпеть, с не 64 бит терпеть, R>с виндой терпеть, с необходимостью дописывать хидеры Win32 терпеть, с многословностью паскаля терпеть, с ограничениями VCL терпеть. R>Вечное программирование в стиле «терпеть».
Глюки IDE есть. Но не критичные. Во всяком случае по сравнению с D2009 огромный прогресс. Юникод есть, работает нормально. 64 бита есть.
Винда вообще непонятно каким боком здесь.
Хидеры Win32 уже кучу лет не дописывал. Тем более если винда-боль, то зачем еще глубже в неё залезать?
Многословность Паскаля — это про begin/end? Какие-то священные войны.
Здравствуйте, rkcsoft, Вы писали:
R>Он (drVano) перешёл на qt с Delphi и теперь при каждом удобном случае набрасывает на вентилятор.
Я не набрасываю, я прямым текстом говорю, что Delphi уже давно мертв. "Спецы" из эмбаркадеры уже не могут тянуть даже собственный компилятор и массово переходят на LLVM.
R>Но не понимает, что не у всех в приложениях 5 форм, как у него. Ну и визуальная часть у него не главное.
При чем тут 5 или 100 форм? Я например как разработчик хочу кросплатформенности с минимальныим услиями. Delphi/BCB может это предложить? Нет и походу уже никогда не предложит.
Здравствуйте, rean, Вы писали:
R>Эти споры — путь в никуда. Вы не сможете заставить меня любить то, от чего я мучаюсь.
Да я и не спорю. Я удивлен желанию переписать работающий софт на другом языке программирования.
Хотя я же не знаю всех вводных. Может там исходников всего 100 килобайт...
Новый проект я бы на Delphi сейчас, скорее всего, не начал (хотя зависит от проекта). Но переписывать старый не стал бы 100%, если бы это не сулило огромных финансовых выгод.
Здравствуйте, drVanо, Вы писали:
V>Я не набрасываю, я прямым текстом говорю, что Delphi уже давно мертв.
Есть и другая точка зрения. То, что она тебе не близка, не говорит о ее неверности.
V>При чем тут 5 или 100 форм?
Попробуй перепиши приложение с 500+ формами и диалогами на Qt. Тогда поговорим.
V>Я например как разработчик хочу кросплатформенности с минимальныим услиями.
Твое требование кросплатформенности — это только твое требование. А у многих требования ограничиваются "шоб под виндой работало".
Здравствуйте, rean, Вы писали:
R>Так что задумался над Лазарусом. R>У кого есть опыт, скажите, как оно, какие подводные камни? R>Есть ли способ быстрого портирования исходников дельфы, чтобы не переделывать с нуля все формы? R>Как оно работает в маке, есть ли там подводные камни?
Я перенес вот этот проект из Делфи в Лазарус недавно, тк хотелось его сделать кросс-платформенным. 10 тыс строк кода, 20 форм.
Формы удалось перенести с минимальными усилиями, просто переименовав их в LFM и кликая ОК чтобы пропустить свойства не поддерживаемые Лазарусом (Margin в основном).
Из проблем было:
1) Virtual TListView не работает толком на маке и линухе — пришлось менять на virtual tree view.
2) Некоторые контролы не работают на macOS/Cocoa, потому маковская версия пока собирается с Qt
3) Нужно помнить что строки в лазарусе это Utf8, а в дельфи и винде Unicode (в старых делфи — ANSI)
Из того что сделано лучше чем в делфи:
1) Можно сишные либы типа sqlite слинковать прямо в бинарник в виде статической либы, FPC поддерживает $LINKLIB.
2) Есть многоразмерный TImageList, хотя вроде в последних делфях он тоже появился
Здравствуйте, rean, Вы писали:
R>Есть куча старых проектов на Turbo Delphi Explorer (аналог Delphi 2006). Все компоненты из стандартной вкладки. Никакого мудреного взаимодействия с VCL.
R>Самый последний вариант — покупка последней дельфы. Не хочется этого никак.
ИМХО, Лазарус как был так и остался поделкой для курсовых. Нужно переходить на Qt или .Net
Здравствуйте, Черный Властелин, Вы писали:
ЧВ>1) Можно сишные либы типа sqlite слинковать прямо в бинарник в виде статической либы, FPC поддерживает $LINKLIB.
Delphi это умеет делать уже лет десять
ЧВ>2) Есть многоразмерный TImageList, хотя вроде в последних делфях он тоже появился
зачем эти костыли если можно использовать векторный формат для всех разрешений
Здравствуйте, icezone, Вы писали: I>Здравствуйте, Черный Властелин, Вы писали: ЧВ>>1) Можно сишные либы типа sqlite слинковать прямо в бинарник в виде статической либы, FPC поддерживает $LINKLIB. I>Delphi это умеет делать уже лет десять
Как? Линковать OBJ файлы по одному да еще и в нужном порядке — дикий геморрой.
ЧВ>>2) Есть многоразмерный TImageList, хотя вроде в последних делфях он тоже появился I>зачем эти костыли если можно использовать векторный формат для всех разрешений
Ну так в Дельфи встроенного векторного движка тоже нет. Я для делфи использую вот это, автор работает над версией для лазаруса.
Здравствуйте, Черный Властелин, Вы писали:
ЧВ>Как? Линковать OBJ файлы по одному да еще и в нужном порядке — дикий геморрой.
да, приходится поштучно линковать
ЧВ>Ну так в Дельфи встроенного векторного движка тоже нет. Я для делфи использую вот это, автор работает над версией для лазаруса.
его нигде нет
все либы что я видел (C и Delphi) косячат
Здравствуйте, icezone, Вы писали: I>Здравствуйте, Черный Властелин, Вы писали: ЧВ>>Как? Линковать OBJ файлы по одному да еще и в нужном порядке — дикий геморрой. I>да, приходится поштучно линковать
Ну вот, а в FPC можно вот так целыми либами. Оно само разрулит связи:
{$IFDEF WIN32}
{$LINKLIB 32-bit\sqlite.a}
{$LINKLIB 32-bit\kernel32.a}
{$LINKLIB 32-bit\msvcrt.a}
{$LINKLIB 32-bit\gcc.a}
{$ENDIF}
{$IFDEF WIN64}
{$LINKLIB 64-bit\sqlite.a}
{$LINKLIB 64-bit\kernel32.a}
{$LINKLIB 64-bit\msvcrt.a}
{$LINKLIB 64-bit\gcc.a}
{$ENDIF}
ЧВ>>Ну так в Дельфи встроенного векторного движка тоже нет. Я для делфи использую вот это, автор работает над версией для лазаруса. I>его нигде нет I>все либы что я видел (C и Delphi) косячат
Вот еще недавно новая либа появилась — хз как она правда: https://svgmagic.io
Здравствуйте, Черный Властелин, Вы писали:
ЧВ>Вообще ИМО в большинстве приложений нужен векторный TImageList, сделал один раз иконки и все работает на любом разрешении и в любом месте.
Не могу согласиться. То, что выглядит супер в svg 128x128 — не выглядит также в 16х16.
Нужна ручная доводка человеком. Поэтому лучше растр под разные DPI.
Здравствуйте, rkcsoft, Вы писали:
R>Здравствуйте, rean, Вы писали:
R>>Отбой. Глючит на High-DPI при перемещении между мониторами. R>>Все компоненты на форме улетают неизвестно куда, форма ресайзится в нулевые высоту и ширину. Появляются какие-то черные линии в виде артефактов.
R>Также и тут. Юзкейс по перетаскиванию окна между мониторами с разными DPI настолько маловероятен,
Воткнул ноут во внешний монитор/проектор, перетащил окно на него, каждый день так делаю
Здравствуйте, icezone, Вы писали:
I>и сколько этих разных DPI твоя программа поддерживает?
На текущий момент 100, 125, 150, 175 и 200 процентов от 96DPI. Пользователям хватает, тем более Win10 только с шагом 25 процентов и позволяет менять DPI. Больше 200 процентов ещё запросов не было.
Здравствуйте, rkcsoft, Вы писали:
R>Также и тут. Юзкейс по перетаскиванию окна между мониторами с разными DPI настолько маловероятен, что я даже не знаю, почему из-за него нужно переписывать работающий софт на другом языке. У меня Delphi Rio в продакшене. Полет нормальный. До 200% масштабирования все работает. Иконки для всех DPI куплены у glyfz.
Последние лет 5 наблюдаю у всех на работе лэптопы с HighDPI, к ним подключают мониторы побольше где масштабирование не нужно.
Вот и получаем разные DPI.
Мы прямо сейчас переводом большой проект с Turbo Delphi (2006) на Lazarus. Продукт в стадии бета-тестирования, уже есть стабильная 64-бит версия, Mac версию надеемся осилить. Есть особенности — например отладчик не всегда корректно работает. Но в целом проблем нет — Lazarus очень быстро работает, с кодом проблем нет.
Embarcadero Delphi несколько раз пробовали — слишком много багов. Последний раз новейшую триалку ставил 2 месяца назад — в Firemonkey по прежнему много визуальных багов (как и 5 лет назад). Сама IDE Delphi до сих пор НЕ работает в HighDPI — все мыльное (как разрабатывать софт на HighDPI мониторе???).
Наш продукт при попытке компиляции намертво вешает IDE новой Delphi. Чего не было ни в старой Delphi ни в Lazarus. И за это платить сотни тысяч рублей?!!
Здравствуйте, PeterOfLight, Вы писали:
POL>Мы прямо сейчас переводом большой проект с Turbo Delphi (2006) на Lazarus. Продукт в стадии бета-тестирования, уже есть стабильная 64-бит версия, Mac версию надеемся осилить. Есть особенности — например отладчик не всегда корректно работает. Но в целом проблем нет — Lazarus очень быстро работает, с кодом проблем нет.
У Лазаруса раньше отладчик был не очень юзабельный, значения property к примеру не показывал. Миритесь с этим или он сейчас нормально работает? Как там на Лазарусе с разработкой ГУИ в MetroStyle?
Здравствуйте, mauzer_tim, Вы писали:
_>Здравствуйте, PeterOfLight, Вы писали:
POL>>Мы прямо сейчас переводом большой проект с Turbo Delphi (2006) на Lazarus. Продукт в стадии бета-тестирования, уже есть стабильная 64-бит версия, Mac версию надеемся осилить. Есть особенности — например отладчик не всегда корректно работает. Но в целом проблем нет — Lazarus очень быстро работает, с кодом проблем нет. _>У Лазаруса раньше отладчик был не очень юзабельный, значения property к примеру не показывал. Миритесь с этим или он сейчас нормально работает? Как там на Лазарусе с разработкой ГУИ в MetroStyle?
Да, отладчик Lazarus показывает меньше информации.
Мы написали свой аналог Firemonkey для своих контролов. По необходимости. Т.к. в нашем продукте сложный редактор объектов, интерфейса и нужна быстрая отрисовка — ни VCL, ни Firemonkey это не тянет. Свои контролы работают намного быстрее с рендерингом через Direct3D.
POL>Мы написали свой аналог Firemonkey для своих контролов. По необходимости. Т.к. в нашем продукте сложный редактор объектов, интерфейса и нужна быстрая отрисовка — ни VCL, ни Firemonkey это не тянет. Свои контролы работают намного быстрее с рендерингом через Direct3D.
Было бы интересно посмотреть ("свой аналог Firemonkey для своих контролов")...
Это можно где нибудь осуществить?
Здравствуйте, wamaco, Вы писали:
W>Здравствуйте, PeterOfLight, Вы писали:
POL>>Мы написали свой аналог Firemonkey для своих контролов. По необходимости. Т.к. в нашем продукте сложный редактор объектов, интерфейса и нужна быстрая отрисовка — ни VCL, ни Firemonkey это не тянет. Свои контролы работают намного быстрее с рендерингом через Direct3D.
W>Было бы интересно посмотреть ("свой аналог Firemonkey для своих контролов")... W>Это можно где нибудь осуществить?
Здравствуйте, PeterOfLight, Вы писали:
POL>Мы написали свой аналог Firemonkey для своих контролов. По необходимости. Т.к. в нашем продукте сложный редактор объектов, интерфейса и нужна быстрая отрисовка — ни VCL, ни Firemonkey это не тянет. Свои контролы работают намного быстрее с рендерингом через Direct3D.
аналогично, сделал свой набор контролов на GDI+, можно перевести на Direct2D при необходимости
FireMonkey пробовал в разных версиях Delphi, результат неудовлетворительный
