Comments 82
Если в статье не упоминается какая то библиотека, значит она не умеет в кроссплатформу либо не имеет нативного интерфейса. Я так же пробовал смотреть tcl/tk аналоги переписанные на go например. И многие либы переписанные с C/C++. В любом случае все что имеет хоть какой то вес, упомянуто в статье.
Tcl/Tk пробовали?
да, под iOS приложение пока например собрать проблемно плюс тач работать не будет, собственно здесь например об этом явно говорится: https://wiki.tcl-lang.org/page/iOS
Как это "... и почему из тысяч языков программирования он выбрал Delhi"?
Теперь мы знаем почему :-)
p.s.: лично я Delphi уважаю,и регулярно использую.
Ещё есть отдельная тема в кроссплатформе это единый бинарник для разных платформ. Можете посмотреть в сторону Cosmopolitan libc библиотеки.
И тут встает вопрос, зачем тогда все это может просто использовать web?
Зависит от постановки задачи же? При подходе кросс-платформенности и не зависимости от ОС — достаточно браузера
Но что будет, если Вы захотите как-то начать взаимодействовать с ОС? Записать/изменить файлик в файловой системе, поменять реестр, пообщаться с консолью? Даст ли Вам это браузер с его конскими ограничениями? (Я не считаю их неправильным, просто ограничения там наоборот делаются для безопасности)
UPD: не касаясь мобильных устройств, возможно еще можно было бы взглянуть на sciter
Вы реально считаете Лазарус более подходящим для кроссплатформенной разработки, чем Flutter или Qt?
Delphi тоже позволяет создавать полноценный кроссплатформенный софт под основные платформы (Windows, macOS, Linux, iOS, Android). Имеет куда большие возможности (сравнение идет с Лазарусом) по работе с GUI и даже кодом (инлайн, анонимки и т.д.)
Преимущество у Лазарус заключается в том, о чем вы в абзаце с ним даже не упомянули.
В Лазарусе "нативная GUI кроссплатформенность". Т.е. все основные контролы берутся из ОС (для Win, Mac, Linux (Qt или GTK). Т.е. вид приложения полностью зависит от версии ОС (или от версии ДЕ). Это главное преимущество, помимо OpenSource.
В Делфи же GUI работает на GPU (DirectX, OpenGL, OpenGLES, Metal, Skia, ...) и следовательно контролы там полностью рисуются самим фреймворком (хотя есть возможности использовать нативные контролы, частично). В Delphi, касательно кроссплатформы используется похожий на CSS подход. Когда есть код, есть представление в виде контрола и есть визуальное представление этого контрола. При этом, визуальное представление контрола, в отличие от CSS, создается тоже визуально (из других контролов).
Например, так может выглядеть стиль для отдельного элемента списка
А так, стиль кнопки
При этом стиль любого контрола можно поменять в любой момент в рантайме
я искал кроссплатформменую либу именно нативно отрисовывающую интерфейс, об этом говорится почти в каждом абзаце... именно поэтому откидывал все остальные либы.
Увы, это вас и сгубило.
Кстати, если вы таки возьмётесь за C/C++, или через обёртку на Python или чего там ещё, то Qt Вам явно не зайдёт, а вот wxWidgets окажется весьма.
ну вообще QT я поковырял, у них очень странные лицензии на мой взгляд и очень конский ценник если брать полноценную версию. QT на сайте бесплатынй что бы скачать надо постатраться, но даже не только в этом дело. C/C++ я очень люблю, но писать на них сейчас после того как избалован современными языками мне просто влом, тем более делать кросскомпиляцию под все 100500 платформ. Но, даже если закрыть на это глаза и сделать подвязку к QT тогоже Go, от тех же проблем это не избавит, для Go придется делать cgo, со всеми вытекающими и т.д... на мой взгляд это просто костыль.
Далее если смотреть на сам QT он выглядит как буд-то только что из 86 года, такой же интерфейс, такое же юзабилити... Я ничего не хочу сказать плохого или обидеть, но после Xcode он просто ужасен 😁 Lazarus оказался намного более современным нежели QT, как это не пародоксально звучит.
А как насчёт JavaFX? Не могу ничего сказать насчёт мобильных ОС, но на трёх основных десктопных (WIndows, Linux, MacOS) работает прекрасно.
Очень странно слышать что java скорее мертва, чем жива с учётом того, как она развивается последние лет 5 и как много проектов и компаний её используют)
это только десктопы... ну и в профильных чатах говорят что да java скорее мертва чем жива при котлине, многие проекты потихоньку переводят на котлин, он совместим целиком и т.д.
А что - не плохо. Не идеально - но не плохо, даже понравилось :)
Расскажу свой опыт.
Нет у меня даже не было нужды сделать мультиплатформенно. Я хотел на golang для Linux, но что бы это был индикатор в панели, а не полноценное GUI приложение.
И вот когда я копнул в эту тему (в 2017), то нашел только две разной меры кривости библиотеки для GTK и QT. Для QT там был жутковатый байндинг и собиралось это с С/С++ (т.е.забудьте про быструю компиляцию golang). Для GTK тоже был касок кода на C, но там хотябы объем был небольшой (сборка заметно медленне golang но всеже за разумное время). Проблема была только в том, что там в 2017 не было подменю в том меню, что может показать индикатор. А мне оно надо было. Пришлось самому дописывать в форке.
Но вот в прошлом году я глянул, а оказалось не только подменю появились в той библиотеке, что я для GTK использовал, но она вообще переползла на использование интерфейса индикаторов через D-bus. С одной стороны это дало возможность всю кодовую базу держать в go (быстрая сборка), а с другой - в теории это полная отвязка от GUI библиотек.
Я конечно загорелся, переполз на новую версию либы..... и погряз в куче косяков, с которыми реализуются те самые приложения, что обеспечивают серверную часть сервиса D-bus (т.е. те, тто отвечают за отрисовку GUI).
А к чему я это?
Да к тому что даже на таком, казалось бы маленьком месте (иконка в панели) и даже при наличии "универсалной" шины доступа (доспной практически в любом linux с GUI), но даже тут - косяк на косяке и косяком погонят.
С одной стороны кажется, что такие шины типа D-bus как раз и могли бы позволить MULTI (в моем случае MULTI_DE всего). Но когда за реализацию серверной части отвечают несколько компаний/команд/или вообще никто, вся эа заммечательная концепция разваливается.
У меня был некоторый опыт с десктопными приложениями под Delphi/Lazarus которые успешно переделывались под различные версии Windows и Linux. Но когда я попытался переделать их под смартфон с Android, то тут сразу встал вопрос с интерфейсом. Принципы его построения отличаются от того, что было при выводе на монитор. Отношение сторон может сильно отличаться, да ещё и положение экрана может быть как вертикальное, так и горизонтальное. Так что по поводу «не создавая новую отдельную версию» - не особо получается. Кроме того, версия Lazarus для Android выглядит пока достаточно «сырой».
ну в защиту могу сказать, что конечно адаптация интерфейса будет нужна, как же без этого, но сам факт что это будет нативно и это соберется из твоего кода без доработок это дорогого стоит...
Например у меня есть в AppStore несколько приложений, они чудесным образом работают на macOS/iPadOS/iOS, как? Очень просто такая же адаптация интерфейса, для айфона левая менюшка выступает в качестве основного меню, при нажатии на пункт показывается окно выбранного меню. На macOS же меню слева всегда есть, ну и правое окно с результатом тоже.
А как Вы сайты под мобильные и десктопы делаете? Точно так же - разные стили и даже возможно разметка. Ничего страшного. Во многих проектах сам GUI занимает много меньше, чем сама бизнес-логика, которую при наличии реального кроссплатформенного фреймворка переписывать не требуется.
Лазарь под андроид это попытки что то сделать на коленке авось запустится ну и интерес пропал у разработчика. Лазарь под Андроид в данное время можно даже не рассматривать. Из паскаля только файрманки и все. Но интерфейс на нем уступает в скорости нативным приложениям. Лазарь только десктопы сейчас. А то что файрманки рисует свои элементы так это и плюс, можно своих наделать кучу.
Тоже страдал от отсутствия норм web, desktop GUI, только еще и не хотел учить новый gui фреймворк для каждого языка. понял, что надо сделать самому, чтобы меньше кушать гуаны.
разработал протокол, по которому без привязки к языку работает GUI, фронт, который сначала был универсальный на flutter, бэки для Python и Go. flutter фронт пришлось закопать, Web поддержка была отвратительной. написал на VUE-quasar , отчего стал у меня чистый web.
Go не поддерживаю, потому как основное для меня AI, так что универсальный мой фреймворк счас только под Python.)
Hidden text
Изучал Lazarus на 2 курсе колледжа, никогда не задумывался о его потенциале в кросс платформенность, спасибо за статью!
c++ и wxwidgets. но он не может мобильные ос. а так цитата:
wxWidgets is a C++ library that lets developers create applications for Windows, macOS, Linux and other platforms with a single code base. It has popular language bindings for Python, Ruby, Lua, Perl and several other languages, and unlike other cross-platform toolkits, wxWidgets gives applications a truly native look and feel because it uses the platform's native API rather than emulating the GUI. It's also extensive, free, open-source and mature.
И то не все так просто в дизайне интерфейса для кроссплатформенности если приложение сложное. нужно накладывать на себя ограничения в полете фантазии.
PC: это включает в себя операционные системы, такие как Windows, macOS и Linux.
Мобильные устройства: это включает в себя Android (на большинстве смартфонов и планшетов) и iOS (на iPhone, iPad).
Веб: это интернет-браузеры, такие как Chrome, Firefox, Safari и другие.
Носимые устройства: такие как умные часы на базе Wear OS (от Google) или watchOS (от Apple).
Телевизоры и приставки: например, Android TV или Apple TV.
А зачем нужна такая мультиплатформенность? Это же принципально разные аппаратные платформы. У разных классов устройств разное предназначение, разные аппаратные интерфейсы, и совершенно отличающиеся способы использования. Я понимаю кроссплатформенность для конкретного типа аппаратных платформ с разными операционными системами - это да, полезно. Десктоп для Windows/Linux/MacOS. Мобильное приложение для Android и iOS. Веб для любого браузера (впрочем в вебе это уже давно стандарт). Но вот зачем все это смешивать? Чтобы получить нечто формально запускающееся, но неюзабельное ни на какой платформе? ИМХО даже планшеты с десктопами смешивать нельзя. Кнопка для нажатия пальцем и кнопка для нажатия мышью - это две разные кнопки, и сам дизайн приложений должен быть совершенно разным. А если унифицировать - оно конечно заработает, но вот выглядеть будет совершенно неэстетично.
ну как бы в статье речь как раз об этом... что кроссплатформенность нужна именно с нативным интерфейсом
Приложение для десктопа и для часов, из одного сорца, и чтобы нативно интерфейс показывался? Наверное Вы что-то перепутали.
Адаптивный интерфейс, есть такая штука... например сайты с адаптивным интерфейсом, или например все мои приложения в сторе, которые как на айфоне, так и на планшете и на десктопе выглядят нативно.
Каждый нативный интерфейс имеет свои нативные приколы. Хотите разрабатывать действительно нативное приложение -- пишите на нативных средствах отдельно под каждую платформу. При этом будут учитываться куча ньюансов каждой платформы по-отдельности. Именно так люди и делают.
Хотите кроссплатформ, это значит что у вас приложение будет выглядеть и вести себя абсолютно одинаково на любой платформе.
Вот простой пример, который работает на Win, Linux, MacOS, iOS, Android. Работает и на десктопе и на планшетах и на мобилках одновременно.
Десктоп
Мобилки
На планшетах скрины не нашёл у себя. Но работает и выглядит примерно как на десктопе, однако меню слева можно скрывать
это всё хорошо на максимально простых интерфейса типа "текстовое поле и кнопка".
Нет, это не совсем так. Я не спорю, что существуют некоторые уникальные и привычные для конкретной платформы (а точнее для форм-фактора) элементы управления. К которым все привыкли, да и в целом оправдано имеют место быть на той или иной платформе, однако это довольно редкие случаи. Действительно редкие.
Попробуйте сами предложить пример приложения, который удобен только на мобильных или наоборот, такое приложение, которое имеет место быть на мобилках, но не возможно реализовать его почти так же как на десктоп.
А пока, вот вам ещё пример.
Приложение для просмотра панорам.
Прошу прощения, Хабр забаговал и не дает вставить картинку в спойлер.
Это одно и то же приложение. На телефоне 2к, на десктоп FHD.
Десктоп для этого приложения, на самом деле, не был целевой платформой. Целью были планшеты, которые находятся в торговых центрах Леруа. Но как видно, приложение отлично работает и на мобилках, и на десктоп. И само-собой на планшетах.
Собственно пример работы
На интерфейсах где ресайз везде все хорошо обычно везде и всюду уже подход уже другой, а вот как отобразить там танцы с бубном размерностей вагон
Вот да. Зачем натягивать кроссплатформенность там, где она не нужна? Все эти платформы имеют большие различия - как в плане интерфейса так и в плане внешних сенсоров (тач скрин к примеру один из них). Запиливая кроссплатформенное приложение под все платформы сразу - ты получаешь пересечение множеств возможностей и тебе надо либо пользоваться ограниченным набором (который есть везде) либо подпиливать костыли под каждый конкретный девайс.
Как видица кроссплатформенность между носимыми устройствами (часами) и PC? У них кардинально разные подходы к UI, несовместимые друг с другом, просто потому что это очень разные кейсы использования.
Кроссплатформенность может быть между сходными по возможностям и кейсами использования устройствами - планшет/телефон (разные ОС), телевизор/приставка, с натяжкой - планшет/PC. Вот тут можно подумать над кроссплатформой между Android/iOS например.
вот уж проблем адаптации интерфейса под телефон/планшет/десктоп давно нет...
На самом деле, различия между мобильными и десктоп устройствами минимальные. Основное отличие - ориентация экрана по умолчанию. Мульти тач, сенсоры есть не только в мобильных устройствах и всё это прекрасно укладывается в абстракции в фреймворке. Т.е. реализовать работу с мультитачем, движениями или сложными жестами можно и там и там. Адаптировать отображение меню в зависимости от размера приложения - тоже (при чем, это полезно не только на мобилках).
Запиливая кроссплатформенное приложение под все платформы сразу - ты получаешь пересечение множеств возможностей и тебе надо либо пользоваться ограниченным набором (который есть везде) либо подпиливать костыли под каждый конкретный девайс.
Не нужно забывать, что всё это зависит от того, как реализован фреймворк. Платформа может или не может поддерживать ту или иную функцию, и если её нужно использовать, если она есть, то можно проверить, имеется ли такая поддержка или нет.
Например, работа с буфером обмена. (далее будут примеры на Delphi + FMX)
Код
var ClipBoard: IFMXClipboardService;
if TPlatformServices.Current.SupportsPlatformService(IFMXClipboardService, ClipBoard) then
begin
ClipBoard.SetClipboard(MemoCode.Text);
ShowUIMessage('Coppied');
end
else
ShowUIMessage('Clipboard error');Мы просто спрашиваем, поддерживает ли наша платформа работу с буфером обмена. Да - копируем текст, нет - выводим ошибку.
Либо работа с заставкой (IFMXScreenService), либо работа с Drag&Drop (IFMXDragDropService) и так далее. Всё это легко обрабатывается, а большая часть вещей вообще уже имеет обертку, которая позволяет избежать подобного кода на проверку.
При запуске или вообще при сборке мы может разграничить те или иные визуальные части, которые не подходят для платформы. В этом нет сложности.
Сейчас в Делфи имеется бесшовная работа на всех платформах с мультитачем, геолокацией, ориентацией, блютузом, биометрией
Камерой, микрофоном, звуком, встроенными картами, платежами, адресной книгой и т.д.
Есть специальные контролы, которые адаптируются сами под платформу, например, то же меню (на винде оно слева, на андроид и иос оно плавающее). Комобоксы на винде выпадают вниз, а на мобилках нативное модальное окно со списком. Поля ввода на мобилках имеют точки выделения текста и окно с увеличением того, что под пальцем. Списки по умолчанию имеют жесты смахивания элементов.
И всегда есть возможность обратиться напрямую к API платформы и обработать действительно нестандартное действие.
Всё это я к тому, что нужно найти подходящий для вас инструмент, который реализует всё более менее удобно и не ограничит вас.
Ну и посмотрите на сайты. Они зачастую не имеют отдельную мобильную версию. Хотя, тут пример так себе. Большинство "адаптивных" сайтов не удобны для десктоп с их огромными пустыми пространствами и элементами управления. Но так или иначе, нужен подходящий инструмент.
Что касается разработки под часы или телевизор, то тут всё просто. Как правило, точно такой же функционал для часов не требуется, а для телевизора просто следует хорошо подойти к работе с клавиатурой и управлением стрелками, это тоже может быть реализовано ко всем платформам сразу (он же Tab/Shift+Tab). Однако, и для разработки одновременно под часы может тоже быть реализована механика.
На этом скрине показан механизм, позволяющий реализовать разный вид "окна" для разных форм-факторов. Т.е. чисто технически, можно без проблем адаптировать форму под часы независимо от формы для десктопа или телефона. Или просто посмотреть как она будет выглядеть или скрыть, переместить элементы управления.
Ну, сайты для разных платформ делают разные и не плачут (почти). Почему софт нельзя делать так же?
PC: это включает в себя операционные системы, такие как Windows, macOS и Linux.
Скорее всего имелось ввиду Desktop, а не PC.
У тебя PC, а у меня Mac, так обычно говорят.
Программисты писали свои приложения для тех платформ где платят
Дофига, конечно, платят за какой-нибудь DosBox, а также там, где у людей есть ностальгия и своя собственная мотивация.
MAUI.NET тут был?
Приложения пользовательского интерфейса мультиплатформенных приложений .NET (.NET MAUI) можно создавать на следующих платформах:
Android 5.0 (API 21) или более поздней версии.
iOS 10 или более поздней версии.
macOS 10.15 или более поздней версии с помощью Mac Catalyst.
Windows 11 и Windows 10 версии 1809 или более поздней с помощью библиотеки пользовательского интерфейса Windows (WinUI) 3.
А к черту до JavaES кастуемся и не паримя вон кофеварка в дум на нем умеет
Таки шо вы так все боитесь, что C/C++ из-коробки не собирается под все платформы? Избалованы golang GOOS/GOARCH опцией?
Я под маком собираю под.. мак (нативный clang, или самый современный clang 16.0.6, или самый современный gcc 13.1.0), под вин (MinGW-64bit 13.2.0), или под линукс (gcc 13.2.0).
Ещё под маком я могу какой-нибудь flutter собрать подо всё, но это отдельная тема.
можно и пешком весь мир обойти, но на самолете быстрее... весь вопрос в том сколько своего времени вы готовы потратить
весь вопрос в том сколько своего времени вы готовы потратить
На установку кросс компиляторов? Я ставил всё командой brew install на Маке. На Убунте это всё apt-get install.
На разную кросс-компиляцию? Мои проекты собираются с помощью Cmake, только подсовывай описание тулчейна. В CLion у меня тулчейны прописаны, и все таргеты и юниттесты делают одной кнопкой.
А есть достойные библиотеки gRPC для Lazarus ?
Я правильно понял что единственная претензия к джаве это то, что некое комьюнити в большинстве своем перешло на котлин?
Они скорее всего до этого на скалу переходили все повально.
Сомневаюсь что джава (даже якобы мертвая) намного менее поддерживаемая чем избраный автором Free Pascal.
Проекты на джаве прекрасно собираются в андроид студии, а целевой уровень апи как был, так и остался (скорее всего) девятнадцатым - киткат. То есть спокойно можно писать приложения так же, как это делали еще до появления котлина.
Другое дело что писать на джаве может просто не нравиться, и товарищ автор искал повод от нее отказаться. Но если цель найти такой язык, на котором можно написать кучу логики и адаптировать под тучу платформ - кажется что лучше и мощнее чем джава ничего найти не получится.
Вот что действительно умерло - так это джава апплеты, так что для браузера писать gui на джаве уже не получится. А так бы был полный фарш.
Ну для начала если внимательно почитать, то на Java я писал и раньше, и была идея даже взять именно его в основу со сборкой в бинарники (хотя это уже и устарело). И была идея расширять SWT библиотеку самостоятельно. Но, как мне объяснили в профильном чате, есть решние посвежее в виде Котлина. И на нем я тоже посмотрел все что есть на данный момент, включая компиляцию в бинарник и GUI библиотеки. Никто не спорит что Oracle пытается держаться на плаву, но против Google им стоять сложно. Старые проекты переводят по тихоньку на Котлин например.
А как вам такое, Илон Маск: Go + Lazarus = GoVCL от лучших китайских производителей.
Покрываются десктопные платформы, а мобильные никак.
Это имхо больше, чем другие умеют...
Из более широкого применения у меня получилось собрать только NuxUI. Правда странное описание UI у них - CSS in JS напоминает...
Какой-то брошенный проект этот NuxUI? Для golang стандартный более-менее GUI будет Fyne.
Кстати, вот тема реальная. Если принять за основу Flutter, но не хочется вникать в очередной ЯП Dart, то (я видел) начили пилить Golang обёртку над Flutter.
The Wails Project | Wails Go + react ?
"... Линукс пока держится на плаву..."
Пока? Пока что?))
Мультиплатформенность приложений в 2023