Здравствуйте, Khimik, Вы писали:
K> Я слышал что с Delphi12 можно скомпилировать FMX-приложение для Линукса. Кто-нибудь пробовал так делать? Может Лазарус в топку?
У Delphi нет нативной поддержки Linux GUI. GUI для Linux в Delphi обеспечивала сторонняя библиотека, которую поставляла Embarcadero по соглашению с автором. Автор этой либы недавно отдал Богу душу. Дальше сам думай.
з.ы. Поверь, даже если Embarcadero выкупит права на этут библиотеку и будет ее поддерживать в дальнейшем, перевести VCL-приложение на FMX будет очень не просто. Переделывать придется вообще все. Переехать на лазарь будет сильно проще. Фигею с тебя: который год уже переезжашь... Видимо, не сильно надо
R>перевести VCL-приложение на FMX будет очень не просто
Зависит от сложности приложения. В целом ничего сложного. Если есть компоненты под все задачи, перевести не проблема. Однако, проблема в том, что FMX довольно сырое и ограниченное поделие, даже авторы которого пилят уже другую библиотеку.
Здравствуйте, temnik, Вы писали:
t> R>перевести VCL-приложение на FMX будет очень не просто
t> Зависит от сложности приложения. В целом ничего сложного. Если есть компоненты под все задачи, перевести не проблема.
Смешная шутка.
t> Однако, проблема в том, что FMX довольно сырое и ограниченное поделие
Это еще мягко говоря... Вообще, начинает создаваться впечатление, что FMX перепиливают люди, которых изнасиловали учебником по ООП и паттернам. И, слава яйцам, что они его не поняли.
t> даже авторы которого пилят уже другую библиотеку.
Уж не про FGX ли ты, часом? (если про нее, то вообще мимо кассы)
R>Это еще мягко говоря... Вообще, начинает создаваться впечатление, что FMX перепиливают люди, которых изнасиловали учебником по ООП и паттернам. И, слава яйцам, что они его не поняли.
можно подробнее, кого не поняли — ООП, или FMX?
интересно.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф> R>Это еще мягко говоря... Вообще, начинает создаваться впечатление, что FMX перепиливают люди, которых изнасиловали учебником по ООП и паттернам. И, слава яйцам, что они его не поняли.
Ф> можно подробнее, кого не поняли — ООП, или FMX?
Учебник не поняли, а то натаскали бы паттернов еще больше.
Здравствуйте, rudzuk, Вы писали:
R>Не лютый, но можно было проще. Бесит код, который не задачу решает, а обслуживает идеологию. Однако, wpf и avalonia еще страшнее.
А где сейчас хороший GUI? На маке — вестимо от Apple. На линуксе в KDE лучше всех выглядит Qt, но на том же маке Qt страшен, просто страшен, шрифты все размываются. На винде, как ни странно, WinForms до сих пор выглядит шикарно, а вот WPF что-то меня не радует. К авалонии смешанные чувства. Здорово, что есть какая-никакая кроссплатформа, но их тягу к гигантизму понять не могу.
Вот где взять хороший GUI? Я серьезно спрашиваю. Не вижу пока такого, чтобы везде и сразу. Прямо какая-то нерешаемая проблема. Либо везде писать отдельно под платформу с общим ядром, но реально ли это?
Вы можете меня неправильно понять, но мне понравился LispWorks с его CAPI. Там есть минимальный набор, который на каждой системе выглядит как родной, и по сути является родным для каждой отдельной системы. Где надо, там GTK в линуксе, а для мака будет натуральная Cocoa. Они постарались, но количество компонентов весьма мало. Вот типа такого бы хотелось.
Хотя вот вспомнил про Java SWT, но там тоже не так много родных компонентов, а собственно-ручно написанные на Java выглядят страшно. Да и странно выглядит вся эта возня с явным освобождением ресурсов в языке со сборкой мусора.
А вот свинг где-то на четыре будет по оценке. На винде неплохо выглядит. На линуксе — так себе. На маке дефолтный свинг тоже выглядит неплохо. Хорошим решением будет написание своей собственной темы Look&Feel, что и делают, как в той же Идее.
К своему списку еще добавлю VisualWorks (это смолток такой). Возможно, что они тоже умеют делать хороший GUI под десктопные платформы, но я его внимательно разглядывал лет 12 назад. Поэтому мог забыть детали. Помню, что понравился. Сейчас нас туда не пущают.
В последнее время много шумят о флаттере? Что за зверь такой? Кто пробовал? Там, вообще, многопоточность есть?
Здравствуйте, dsorokin, Вы писали:
d> Вы можете меня неправильно понять, но мне понравился LispWorks с его CAPI. Там есть минимальный набор, который на каждой системе выглядит как родной, и по сути является родным для каждой отдельной системы. Где надо, там GTK в линуксе, а для мака будет натуральная Cocoa. Они постарались, но количество компонентов весьма мало. Вот типа такого бы хотелось.
Именно так сделано в Lazarus. На каждой платформе свои нативные контролы. При этом, единая кодовая база. Очень удобный лайаутинг, с которым чуть разобраться и получается делать резиновый гуй практически без кодирования.
Здравствуйте, rudzuk, Вы писали:
R>Именно так сделано в Lazarus. На каждой платформе свои нативные контролы. При этом, единая кодовая база. Очень удобный лайаутинг, с которым чуть разобраться и получается делать резиновый гуй практически без кодирования.
О, на маке выглядит очень даже неплохо. Только что установил. Накидал простую форму, разные стандартные компоненты. Как это я упустил из виду за столько лет?! Надо будет глянуть на винде и линуксе.
И да, fpc и lazarus не подписаны. Видимо, для программистского софта не так это и важно.
t>> Однако, проблема в том, что FMX довольно сырое и ограниченное поделие
R>Это еще мягко говоря... Вообще, начинает создаваться впечатление, что FMX перепиливают люди, которых изнасиловали учебником по ООП и паттернам. И, слава яйцам, что они его не поняли.
Интересно, авторы FMX хотя бы скомпилировали Delphi на FMX, чтобы пользоваться?
"Ты должен сделать добро из зла, потому что его больше не из чего сделать." Р.П. Уоррен
Здравствуйте, Khimik, Вы писали:
K> Интересно, авторы FMX хотя бы скомпилировали Delphi на FMX, чтобы пользоваться?
Чтобы "скомпилировать Delphi на FMX", нужно, для начала, Delphi на FMX переписать. Это фантастика (c). Тут, в 12.3, представили, наконец-то, бету 64-битной IDE... Через, почти, 14 лет после появления 64-битного компилятора.
Здравствуйте, Slipstream, Вы писали:
S>ЗЫ Двадцать с лишним лет незад ваш покорный слуга приложил руку к компонентам KSDev а многим позже к FireMonkey.
Здравствуйте, temnik, Вы писали:
R>>>Lazarus
D>>О, на маке выглядит очень даже неплохо.
T>Галимое гамно, если честно.
А по мне так нормально. Правда, у меня модель до ретины. Самая последняя прошка до ретины (но у которой я очень задешево нарастил ОЗУ до 16 гигов).
У меня было большое разочарование, когда я на маке увидел программы на Qt, потому что у меня были виды на Qt. Когда увидел там Qt, то первое впечатление было совсем нерадостным. Хотя, может, на маках с современными экранами Qt выглядит лучше.
Кстати, точно также меня и Java SWT разочаровал на маке — на SWT у меня тоже были свои виды.
Буквально на днях обновил Cmake GUI. Он на Qt. Как же там плохо выглядят шрифты! Потом переключаешься на Xcode, и сразу видишь, как должно быть, или как может быть — кому как больше нравится расставить акценты.
Вообще, при использовании мака возникает какое-то обостренное желание, чтобы все было красиво.
Я много не пробовал Lazarus на маке, но вроде вполне нормально выглядят стандартные контролы. Может быть, есть и такие, которые выглядят неважно. Вполне допускаю
P.S. На винде и в линуксе lazarus мне тоже понравился.
P.P.S. Мне кажется, что сейчас многие программисты мыслят слишком стереотипно. Они и самим по себе мыслят стереотипно в большинстве своем (знаком с психологией), а тут от всех этих интернетов эффект стереотипности и шаблонности только усиливается, многократно усиливается. И мне кажется, что паскаль обижают незаслуженно.
Паскаль был одним из моих первых языков. Как-то потом мой путь разошелся с паскалем, но я рад, что он до сих пор выглядит очень достойно.
D>Паскаль был одним из моих первых языков. Как-то потом мой путь разошелся с паскалем, но я рад, что он до сих пор выглядит очень достойно.
У меня пять продуктов сделаныx на FPC/LAZARUS, все что помечены [Windows/macOS/Linux] на главной.
Все собирается из одной кодовой базы и нативно работает на каждой платформе. Да, конечно есть небольшие шереховатости на маке и линухе, но в целом все отлично.
Для FPC/LAZARUS есть такая крутая штука как FPCUPDELUXE, она выкачивает тебе самые свежие версии компилятора и среды разработки, и самое главное позволяет легко собрать кросс-компиляторы под кучу платформ. Я компилирую под Win32/Win64, macOS и Linux (оба под x86_64 и aarch64) не покидая винды.
C Delphi и FMX опыт отрицательный, правда я пробовал еще лет 5 назад. Глюков в FMX много, компиляторы все разные, под линукс ГУЙ с костылями, в общем не понравилось.
Здравствуйте, dsorokin, Вы писали:
D>Вот где взять хороший GUI? Я серьезно спрашиваю. Не вижу пока такого, чтобы везде и сразу. Прямо какая-то нерешаемая проблема. Либо везде писать отдельно под платформу с общим ядром, но реально ли это?
Кажется, что wxWidgets — это как раз и есть общая надстройка над нативным GUI под каждую платформу, что выгодно отличает его от монструозного Qt.
Здравствуйте, Kocur, Вы писали:
K> R>Уж не про FGX ли ты, часом? (если про нее, то вообще мимо кассы)
K> что думаешь по поводу Ярослава Бровина?
Продуктивный товарищ Не знаю, чего мне про него еще думать FGX я только палочкой потыкал, исходников не видел (да он, кажется, полные исходники и не дает).
Здравствуйте, rudzuk, Вы писали:
r> з.ы. Поверь, даже если Embarcadero выкупит права на этут библиотеку и будет ее поддерживать в дальнейшем, перевести VCL-приложение на FMX будет очень не просто.
R>Продуктивный товарищ Не знаю, чего мне про него еще думать FGX я только палочкой потыкал, исходников не видел (да он, кажется, полные исходники и не дает).
Здравствуйте, Kocur, Вы писали:
K> R>Продуктивный товарищ Не знаю, чего мне про него еще думать FGX я только палочкой потыкал, исходников не видел (да он, кажется, полные исходники и не дает).
K> но сама идея такая же ерунда, как и FMX?
Насколько я могу судить, FGX отличается от FMX тем, что является оберточной библиотекой. То есть, она не занимается собственной реализацией контролов, как делает FMX, а предоставляет обертки к платформенным (FMX так тоже умеет, но количество поддерживаемых контролов сильно ограничено). Благодаря этому гуй более шустрый, с нативным поведением, но менее кастомизируемый (может сейчас что-то изменилось, я довольно давно ее смотрел). Еще помню, что для флекс-бокс лайаута они используют фейсбучную йогу (libyoga.so)
Здравствуйте, Nuzhny, Вы писали:
N>Кажется, что wxWidgets — это как раз и есть общая надстройка над нативным GUI под каждую платформу, что выгодно отличает его от монструозного Qt.
Спасибо! Что-то все время забываю об этом тулките. Его, кстати, используют в maxima. Как я только мог не вспомнить о нем!
Здравствуйте, Khimik, Вы писали: K>Я слышал что с Delphi12 можно скомпилировать FMX-приложение для Линукса. Кто-нибудь пробовал так делать? Может Лазарус в топку?
Мы переводим приложение с VCL на FMX и Линукс.
Ядро нашего комплекса (в т.ч. графический движок) собирается и на VCL и на FMX (Win и Линукс, в ближ время хочу собрать Андроид) и без GUI.
Формы приходится переделывать на FMX. При этом редизайним их в современном стиле, почти все заново.
Картинка
Что могу сказать. Приложение с тяжелой графикой переписанное с VCL на FMX под виндой работает и отлаживается очень неплохо.
Примерное наравне с VCL, есть свои плюсы и минусы у каждого.
ТО же самое приложение FMX для линукс (я сравниваю Win32 и Linux64)
— собирается раз в 10 медленнее. Для винды у меня около 50 проектов билдятся за 1 м 40 сек примерно, а для линукса 8-10 проектов за 5+ минут.
— объем скомпилированных промежуточных библиотек раз в 10 больше
— объем итоговых бинарников раз в 5 больше
— наше приложение при компиляции под линукс не помещается в память, поэтому пришлось разбивать и собирать из нескольких BPL
— графика работает в несколько раз медленнее (используются дефолтные движки для винды Direct2D а Для линукса свой кажется LinuxCanvas называется)
пробовал запустить skia , под виндой работает примерное так же, а для линукса жутко тормозит, но может со временем удастся
разобраться и графика будет работать нормально.
— перерисовка окон в линуксе очень неторопливая, это не только в нашем приложении, как будто вернулся в 90-е
В результате разрабатываем основную функциональность на винде, в монолите, а потом геморроимся чтобы это заработало на линуксе,
это легче чем все делать на линуксе.
На удивление, отладчик через PAServer как-то работает.
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, rudzuk, Вы писали:
r>> з.ы. Поверь, даже если Embarcadero выкупит права на этут библиотеку и будет ее поддерживать в дальнейшем, перевести VCL-приложение на FMX будет очень не просто.
R>Свежие новости: Embarcadero решила вопрос с лицензированием FMXLinux. Жаль. Я надеялся, что сделают нативную поддержку без стороннего решения, которое таскает бинарь собранный фрипаскалем.
Плюс Для линукса необходимо 64 разрядное решение компилятора, память при компиляции в линукс жрет не в себя.
Здравствуйте, swame, Вы писали:
s> Плюс Для линукса необходимо 64 разрядное решение компилятора, память при компиляции в линукс жрет не в себя.
Это касается не только линукса, но любой платформы кроме Windows 32/64 т.к. для всего прочего используются медленные и жручие компиляторы на основе LLVM. Но вот 64-битные компиляторы (в смысле, сами компиляторы собраны под 64-бита) есть, пока, только для винды
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, swame, Вы писали:
s>> — перерисовка окон в линуксе очень неторопливая, это не только в нашем приложении, как будто вернулся в 90-е
R>На виртуалке?
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, swame, Вы писали:
s>> Плюс Для линукса необходимо 64 разрядное решение компилятора, память при компиляции в линукс жрет не в себя.
R>Это касается не только линукса, но любой платформы кроме Windows 32/64 т.к. для всего прочего используются медленные и жручие компиляторы на основе LLVM. Но вот 64-битные компиляторы (в смысле, сами компиляторы собраны под 64-бита) есть, пока, только для винды
Сборка для винды на 64 разряда тоже существенно медленнее чем для 32 разрядов.
Я полагал что там тоже LLVM.
Но не на порядок как для линукса.
Здравствуйте, swame, Вы писали:
S>Мы переводим приложение с VCL на FMX и Линукс.
Наверняка есть какие-то отчеты, печать таблиц, предпросмотры печати и т.п., а что используете для отчетов на FMX?
Я тоже переделываю одну программу. Все формы переделал с нуля, GUI на мой взгляд намного симпатичнее, чем у VCL. Но вот беда с отчетами, насколько я нашел, полноценное решение только фастрепорт дает. Но дороговато, особенно если программа бесплатная или для себя. Бесплатных решений нет в принципе. У меня предпросмотров нет, есть просто сохранение в эксель, использую Excel4Delphi-FMX (на базе ZEXMLSS)
Здравствуйте, temnik, Вы писали:
T>Здравствуйте, swame, Вы писали:
S>>Мы переводим приложение с VCL на FMX и Линукс.
T>Наверняка есть какие-то отчеты, печать таблиц, предпросмотры печати и т.п., а что используете для отчетов на FMX?
T>Я тоже переделываю одну программу. Все формы переделал с нуля, GUI на мой взгляд намного симпатичнее, чем у VCL. Но вот беда с отчетами, насколько я нашел, полноценное решение только фастрепорт дает. Но дороговато, особенно если программа бесплатная или для себя. Бесплатных решений нет в принципе. У меня предпросмотров нет, есть просто сохранение в эксель, использую Excel4Delphi-FMX (на базе ZEXMLSS)
До отчетов в FMX как таковых дело еще не дошло.
В любом случае есть свой слой абстрации для описания табличный форм и их последовательностей.
Из него можем сейчас выводить в эксель, PDF, HTML. В основном этим пользовались.
FastReport использовали раньше, но необходимости рисования каждого отчета со сложной версткой пользователя ручками нет,
зато часто нужно вывести что-то что пользователь может поредактировать, а уже потом распечатать или отправить.
поэтому используем более гибкие решения. Платное и бесплатное особо без разницы.
В пользу своих конструкторов, которые запросы преобразуют в табличную форму, а потом на нее накладывается верстка.
Если требуется фиксированная верстка, то обычно это эксель куда пихаются данные.
Для этого сейчас используются Flexcel, OExport
Здравствуйте, swame, Вы писали:
s> Сборка для винды на 64 разряда тоже существенно медленнее чем для 32 разрядов. s> Я полагал что там тоже LLVM. s> Но не на порядок как для линукса.
Здравствуйте, swame, Вы писали:
s> s>> — перерисовка окон в линуксе очень неторопливая, это не только в нашем приложении, как будто вернулся в 90-е
s> R>На виртуалке?
s> да.
K>Я слышал что с Delphi12 можно скомпилировать FMX-приложение для Линукса. Кто-нибудь пробовал так делать? Может Лазарус в топку?
Так Эмба в очередной раз сбежала из РФ. Зачем на них вообще рассчитывать в текущей ситуации, кроме Lazarus вообще нет альтернатив, если вся кодовая база на Паскале.
D>Вот где взять хороший GUI? Я серьезно спрашиваю. Не вижу пока такого, чтобы везде и сразу. Прямо какая-то нерешаемая проблема. Либо везде писать отдельно под платформу с общим ядром, но реально ли это?
Самый лучший кроссплатформенный богатый УЙ со сложными контролами и интеракциями, что я видел в этой жизни -- тот, что реализован с нуля в Blender'e. Хотите нетленку -- не разменивайтесь на мелочи и делайте так же. GL-контекст в зубы, и вперёд на мамонта, рисовать полностью свой, заточенный под задачу интерфейс.
D>Вы можете меня неправильно понять, но мне понравился LispWorks с его CAPI. Там есть минимальный набор, который на каждой системе выглядит как родной, и по сути является родным для каждой отдельной системы. Где надо, там GTK в линуксе, а для мака будет натуральная Cocoa. Они постарались, но количество компонентов весьма мало. Вот типа такого бы хотелось.
ИМХО этот подход хромой на все четыре лапы. Во-первых, как Вы и сами заметили, "общий знаменатель" у разнородных платформ очень мал и куц. А во-вторых мы с вами, здесь присутствующие, не какие-то твари дрожащие, чтобы подстраиваться под дегенеративные хотелки шизанутых вендоров ОС, а Звучащие-Гордо-Люди-Прямоходящие с поднятой головой Поэтому наши изделия должны иметь свой фирменный вид и стиль, под любой ОС одинаковый.
Возьмем ту же тележку, которой пользуется под миллиард человек. В ней же даже под мобильные платформы, где диктат вонючих гайдлайнов еще более силён, чем на десктопе, очень трудно понять, где ты находишься: в iOS или Андроид. Потому что у тележки свой UI/UX. Тележный, а не iOS'ный или андроидовский.
Теперь рассмотрим вроде бы тоже хорошую программулину: git-клиент SourceTree, авторы которого исповедуют подход нативных контролов. Пока ты на Маке, он вроде хорош. Но стоило мне только поставить его под винду, и приступы тошноты от убогого WPF не заставили себя ждать.
Не знаю, чего мне про него еще думать 
Поэтому наши изделия должны иметь свой фирменный вид и стиль, под любой ОС одинаковый.