Кроссплатформенное программирование под Unix-ы

Вопросы написания собственного программного кода (на любых языках)

Модератор: Olej

Odin_KG
Активист
Сообщения: 13
Зарегистрирован: 10 фев 2021, 01:52
Контактная информация:

Кроссплатформенное программирование под Unix-ы

Непрочитанное сообщение Odin_KG » 10 фев 2021, 02:24

Добрый день,

Про существование Qt и GTK мне известно, но проблема в том, что я пытаюсь сделать продукт из смежной области, и использование подобных решений выглядит как "масло масляное". Кроме того моя программа самостоятельно заполняет поверхность в ОЗУ нужным изображением и потом лишь выбрасывает это изображение на экран целиком, а таким образом мне от всех больших возможностей Qt и GTK нужно только создание одного окна и всё. В результате я пошел через стандарт POSIX + SDL2 и основную часть кода смог заставить работать на Windows, Mac и Unix (по крайней мере, этого хватает для простых игрушек с софт-рендером). Но возникла большая проблема с Drag & Drop, который мне очень нужен для режима приложений. В интернете нашел про стандарт xdnd, но я подозреваю, что не всё так просто. Во-первых, вижу, что этих xdnd существует много версий, а, во-вторых, замечаю, что еще есть некий motif. Так как в жизни я пользуюсь исключительно Windows (немного использовал только Fedora и Ubuntu для сборки), то всё это мне очень не нравится, так как я предвижу, что в плане стандартизации Drag & Drop в Unix-а происходит настоящая каша. И именно поэтому практически нет примеров кода на данную тему, а все сразу советую брать GTK. В связи с этим вопрос: если я-таки разберусь с этим xdnd, то будет ли этого достаточно для реализации моей задачи ? Меня устроит даже, чтобы работало не в 100% случаев, а почти всегда, так как я понимаю, что количество Unixов-ых систем велико, и они любят ставить разные дисплейные менеджеры. В идеале, мне бы хотелось использовать какую-нибудь узкоспециализированную библиотеку, которая позволит переложить на себя универсальное решение по Drag & Drop.

Другая оставшаяся у меня проблема - это иконки для файлов и регистрация расширений, чтобы заставить файлы определенного расширения открываться в нужной программе. Нашел, что для этого делаются xml-файлы с описанием нужных действий, но... у меня создается впечатление, что в разных Unix-ах, эти файлы могут храниться в разных папках, что совсем не радует. Как решается проблема с определением этого пути для общего случая ?

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: Кроссплатформенное программирование под Unix-ы

Непрочитанное сообщение Olej » 10 фев 2021, 08:30

Odin_KG писал(а):
10 фев 2021, 02:24
что еще есть некий motif
Motif - это такая же библиотека (фреймворк) графических примитивов, как и GTK+ или Qt, альтернатива им, в некотором роде (была :-? )...
Motif:
Motif — библиотека элементов интерфейса и набор спецификаций для разработки графических интерфейсов под X Window System. Библиотека Motif появилась в конце 1980-х и на данный момент считается устаревшей[1].
...
... к тому времени, когда The Open Group выпустила бесплатную Open Motif, более современные и удобные библиотеки элементов интерфейса (GTK+ и Qt) успели набрать популярность[2].
Я ещё помню времена, когда Motif была популярной графической системой, и задавала тон, например, Open Solaris от Sun Microsystems ... но на сегодня Motif, наверное, там же где и сама Sun Microsystems ;-)
Не заморачивайтесь.
Odin_KG писал(а):
10 фев 2021, 02:24
то всё это мне очень не нравится, так как я предвижу, что в плане стандартизации Drag & Drop в Unix-а происходит настоящая каша.
Это не совсем так... в Unix (точнее в like Unix) намного больше различных возможностей для одних и тех же целей, чем это имеет место в Windows. Поэтому самое первейшее - отсечь те альтернативы, которые вам не подходят.
Совет для этого: первейшим делом в любой публикации, документации, инструменте, проекте и пакете - смотрите на дату (или дату последнего обновления). Используйте только то, что датировано, максимум, 3-мя последними годами. Остальное - в топку... :lol:
Это сразу уменьшит число альтернатив и ваши колебания в 10 раз.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: Кроссплатформенное программирование под Unix-ы

Непрочитанное сообщение Olej » 10 фев 2021, 08:32

Odin_KG писал(а):
10 фев 2021, 02:24
Другая оставшаяся у меня проблема - это иконки для файлов и регистрация расширений, чтобы заставить файлы определенного расширения открываться в нужной программе. Нашел, что для этого делаются xml-файлы с описанием нужных действий, но... у меня создается впечатление, что в разных Unix-ах, эти файлы могут храниться в разных папках, что совсем не радует. Как решается проблема с определением этого пути для общего случая ?
Во-первых ... Откажитесь от терминологии "Unix" и смотрите только то, что относится к рубрике "Linux" - ещё лет 5 назад я бы вам советовал обратное, но на сегодня реальным остаётся только Linux. Это сразу упростит.

Во-вторых, в Unix/Linux ассоциациям файлов с их расширениями придаётся гораздо меньше значения (а то и совсем не-... :lol: ), чем это имеет место в Windows. В частности, из-за того, что в POSIX стандартах давно (изначально) допускаются многокомпонентные имена в файловой системе, например: 12345.dat.tgz.jpg.pcx :-o ... что вы здесь будете считать "расширением"? ;-)

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

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: Кроссплатформенное программирование под Unix-ы

Непрочитанное сообщение Olej » 10 фев 2021, 08:56

Odin_KG писал(а):
10 фев 2021, 02:24
Про существование Qt и GTK мне известно, но проблема в том, что я пытаюсь сделать продукт из смежной области, и использование подобных решений выглядит как "масло масляное".
Не очень понятно что такое "из смежной области" и зачем это надо... Вот Motif, о котором речь выше - это и был продукт " из смежной области" ... вот, например, wxWindow - тоже "продукт из смежной области".

Опишите конкретней что хотите, какие цели себе ставите - разберёмся...

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: Кроссплатформенное программирование под Unix-ы

Непрочитанное сообщение Olej » 10 фев 2021, 09:08

Odin_KG писал(а):
10 фев 2021, 02:24
В связи с этим вопрос: если я-таки разберусь с этим xdnd, то будет ли этого достаточно для реализации моей задачи ?
Я могу вам помочь в вашей задаче ... не спеша, по мере свободного времени...

Эта, и любая программистская задача, решается примерно в такой последовательности, так:
- вы точно и строго формулируете постановку - что и для чего хотите получить, какая цель (и выкладываете эти формулировки сюда - может на этом этапе уже уточняемся);
- формулируете модельную задачу - максимально упрощённый прототип, который показывает применение выбранного инструментария...
- выясняете какой язык программирования (т его инструментальные средства) вас интересует в 1-ю очередь (потом сможете расшириться): C API, C++ (C++11, C++14, C++17, ... Boost ...), Python, Java ... ещё чего ...
- выкладываете код прототипа сюда ... (со всеми к нему командами gcc, Makefile, Cmake, Ninja и т.д. - сразу определяетесь с технологией сборки которую будете использовать - это в Windows зашёл в Visual Studio, и сам не знаешь чего "оно соберёт")
- начинаем рассматривать код, обсуждать, улучшать...
- начинаете думать как и насколько вам обеспечить мультиплатформенность прототипа (здесь в форуме были, в своё время, аактивные обсуждения на эту тему).

Odin_KG
Активист
Сообщения: 13
Зарегистрирован: 10 фев 2021, 01:52
Контактная информация:

Re: Кроссплатформенное программирование под Unix-ы

Непрочитанное сообщение Odin_KG » 10 фев 2021, 11:05

Olej
Благодарю за такой обширный ответ!

Хорошо, давайте пойдем со сторон задачи. Я пытаюсь сделать свою среду разработки приложений. Визуально продукт чем-то похож на Delphi или Borland C++ Builder (что тот же самый Delphi, только на C++). Смысл в том, что большая часть операций по созданию приложения может быть выполнена визуально в редакторе (вплоть до назначения иконок к расширениям файлов, создания Splash-скрина, автосейва и прочих мелочей, которые обычно все сваливают на пользователя). Практически, это такая библиотека, у которой имеется визуальный редактор на большинство возможностей. Далее пользователь выбирает OS и среду разработки, в которой он желает работать (или которая присутствует в настоящий момент в возможностях программы), и выполняет Экспорт. После чего программа формирует проект для указанной среды разработки и соответствующей OS, где пользователь уже будет делать с результатом, что ему вздумается. Например, можно указать, что Экспортировать нужно на Windows в Visual Studio 2008 и пользователь получит готовый проект под указанную среду, который уже можно будет собирать, дорабатывать и отлаживать. Также сейчас имеется экспорт в Code::blocks, но вот OS пока только Windows. Мне же в идеале нужно, чтобы был Mac+XCode и Linux+Code::blocks. Ядро программы общается с внешним миров через виртуальные функции и, практически, мне нужно переопределить оставшиеся функции под Linux-ы и Mac.
Изначально этот проект начинался из моей старой игры, где я вынужден был добавлять свой GUI-интерфейс. Поэтому исторически получилось так, что сейчас стыковка с MAC-ом и Linux-ами выполняет SDL2, которого как сейчас выяснилось, мне недостаточно. Однако SDL2+POSIX у меня покрыл почти всё,что нужно - практически, из серьезного остался только Drag & Drop. Но без него я тоже не могу обойтись.
Опишу требования к Drag & Drop:
По сути, меня интересует аналог из Windows, так как я ориентировался именно на него. Моё приложение должно уметь принимать внешние операции Drag & Drop, а также инициировать такие операции самостоятельно как для внешнего, так и для внутреннего применения. Обязательна возможность использовать собственный формат данных, а не только стандартные Текст и Список файлов. Курсор должен реагировать на возможность/невозможность операции Drag & Drop для текущей цели, а также добавлять символ "+" при копировании (курсоры для своей операции Drag & Drop я генерирую сам, исходя из содержимого операции). У меня есть рабочий вариант под Windows, но вот как подступиться к Linux-ам я пока вообще не знаю.
Язык разработки только старый C++, хотя никто не мешает использовать и более новые стандарты типа C++11, но лично я там заинтересовался только атомарными операциями. В любом случае, компилировать свой продукт пользователь будет сам и в своей среде, так что это его дело, насколько новый C++ использовать.

В идеале, я бы вообще хотел избавится от SDL, но, вероятно, на его место тогда влезет GTK, что, на мой взгляд, не особенно лучше. Кроме того, я до сих пор не очень понимаю, можно ли этот GTK таскать с собой в программе в виде либы. По-крайней мере, требовать от пользователя установку этого GTK мне явно не нравится.
Я могу вам помочь в вашей задаче ... не спеша, по мере свободного времени...
Это было бы очень здорово! Единственное что, мне бы не хотелось, чтобы всё это затянулось до бесконечности. Поэтому готов рассмотреть вариант с оплатой за помощь, но без затягивания на неопределенный срок. Мне нужен рабочий Drag & Drop на Linux-ах, а в идеале и на MAC-е, так как там тоже сразу вылезет аналогичная проблема. Могу рассмотреть вариант с полным переходом на какой-нибудь фрэймворк типа GTK, только мне нельзя, чтобы там лицензия требовала полностью открывать мой исходник или была бы платной, да и мне хотелось бы таскать такой фреймворк прямо внутри программы, чтобы пользователь не думал об его установке.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: Кроссплатформенное программирование под Unix-ы

Непрочитанное сообщение Olej » 11 фев 2021, 16:26

Odin_KG писал(а):
10 фев 2021, 11:05
Я пытаюсь сделать свою среду разработки приложений. Визуально продукт чем-то похож на Delphi или Borland C++ Builder (что тот же самый Delphi, только на C++).
Для того, чтобы определиться с инструментарием и его возможностями (особенно если мульти-OS) - вместо возни с целым проектом сделайте минимальный (минимальный - это значит 30-50 строк на всё про всё) макет, прототип, только под изучаемую возможность (пусть в вашем случае это будет Drag & Drop) и на ней отработайте возможности того и иного инструментария.
Если у вас несколько возможностей вызывают сомнения - то сделайте несколько прототипов, под каждую изучаемую возможность отдельно, ... а не крутить это в рамках одного развиваемого проекта.
Когда определитесь с выбором того или иного tools под возможности - перенесёте его в проект.
Odin_KG писал(а):
10 фев 2021, 11:05
По сути, меня интересует аналог из Windows, так как я ориентировался именно на него. Моё приложение должно уметь принимать внешние операции Drag & Drop, а также инициировать такие операции самостоятельно как для внешнего, так и для внутреннего применения.
Это очень нездоровая идея - искать в Linux/POSIX/MacOS аналоги возможностям и инструментам из Windows, ... в Linux гораздо более разнообразие разных инструментов чем в Windows. Нужно искать общие приемлемые идеи, а не аналоги для переноса.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: Кроссплатформенное программирование под Unix-ы

Непрочитанное сообщение Olej » 11 фев 2021, 16:40

Odin_KG писал(а):
10 фев 2021, 11:05
Могу рассмотреть вариант с полным переходом на какой-нибудь фрэймворк типа GTK,
Вообще то говоря, в любой инсталляции любого дистрибутива Linux (ну, исключая глубоко серверные инсталляции ;-) ) у вас уже будет присутствовать, по дефаулту, вся поддержка одного из 2-х фреймворков: GTK+ или Qt - потому что на них собрана та или иная (их много) графическая система рабочего стола DE (или оконного менеджера WM) ... в DE Cinnamon, Mate, и др. это будет GTK+, в KDE - Qt.
Более того, в DE построенных на GTK+ часто инсталлируют пакетно приложения использующие Qt и наоборот.

Это не очень разумно (если я правильно понял намерение) "изобретать велосипед", имея всё равно под ногами, по дефаулту, установленную ту или иную графическую систему.

Как мне помнится, и в Windows (по наслышке - совершенно не работаю и не знаю что там в Windows ;-) ) там точно также есть слой поддержки GTK+ и Qt точно есть. Только там они работают над (на нижнем уровне) нативной оконной системой (WinAPI), а в Linux - над Xorg или Wayland (Wayland vs X11). MacOS же куда ближе к Linux (POSIX) чем к Windows.
Odin_KG писал(а):
10 фев 2021, 11:05
только мне нельзя, чтобы там лицензия требовала полностью открывать мой исходник или была бы платной,
А с лицензиями - это вы разбирайтесь сами :lol: (тем более что даже профессиональные юристы не до конца разбираются в разнообразных лицензиях).

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: Кроссплатформенное программирование под Unix-ы

Непрочитанное сообщение Olej » 11 фев 2021, 16:49

Odin_KG писал(а):
10 фев 2021, 11:05
Практически, это такая библиотека, у которой имеется визуальный редактор на большинство возможностей. Далее пользователь выбирает OS и среду разработки, в которой он желает работать (или которая присутствует в настоящий момент в возможностях программы), и выполняет Экспорт.
Вообще то, это не совсем правильное понимание кроссплатформенности: "пользователь выбирает OS".
Обычно проект с одной и той же кодовой базой собирается в разные законченные проекты (бинарники в простейшем случае) под разные OS - хорошие примеры тому: Eclipse, Geany, IntelliJ IDEA от JetBrains.

Это ещё один пункт "марлизонского балета" который вам предстоит пройти: выбрать ту систему сборки для своего кода проекта, которая будет кроссплатформенной.
Для этого определённо не годится Visual Studio со своей системой "проектов", и, очевидно, мало годится make ... а что-то нужно изобретать (выбирать) из области Cmake или Ninja (которую Google предложили для тех же целей, на сборке Chrome/Chromium).

P.S. Или вы хотели бы иметь возможность кросс-компиляции? ... но это совсем другой чем кросс-платформенность, типа такого: садимся мы за Windows 32-бит и "заказываем" компилировать свой код под Linux 64-бит? ... а то ещё и ARM?
Садится Моцарт за рояль ... и играет Генделя.

:lol:

Odin_KG
Активист
Сообщения: 13
Зарегистрирован: 10 фев 2021, 01:52
Контактная информация:

Re: Кроссплатформенное программирование под Unix-ы

Непрочитанное сообщение Odin_KG » 11 фев 2021, 21:20

Olej писал(а):
11 фев 2021, 16:49
P.S. Или вы хотели бы иметь возможность кросс-компиляции? ... но это совсем другой чем кросс-платформенность, типа такого: садимся мы за Windows 32-бит и "заказываем" компилировать свой код под Linux 64-бит? ... а то ещё и ARM?
Вовсе нет. Я вообще не собираюсь ничего компилировать, так как этот этап сейчас я просто не вытяну. Кроме того, как таковая "компиляция" сама по себе никому не нужна, так как там куда важнее хороший отладчик, который позволяет ошибки искать. Именно поэтому я принял решение Экспортировать результат в какую-нибудь среду разработки, где есть и компилятор и отладчик.
Это ещё один пункт "марлизонского балета" который вам предстоит пройти: выбрать ту систему сборки для своего кода проекта, которая будет кроссплатформенной.
Не... мне вообще не нужна никакая система сборки. Я просто открываю файл проекта той же Visaul Studio в "блокноте" и визуально определяю, как там всё устроено, а потом генерирую эту структуру из своей программы, подставляя свои файлы и другие настройки. То же самое касается и code::blocks-а. В результате пользователь получает готовый проект напрямую без всяких посредников. Более того, пользователь обязательно будет в настройках проекта делать какие-то личные действия, которые я не могу предугадать, типа включать оптимизацию или свои файлы добавлять. Со своей стороны я могу в существующий файл проекта вносить лишь те изменения, которые касаются лично моей программы, т.е. я могу не трогать изменения пользователя. А это очень полезно. Я вообще процесс работы со своей программой рассматривал как взаимодействие со средой разработки пользователя, когда можно менять исходник или там или у меня, а потом переключаться между программами и сделанные изменения должны ловиться текстовым редактором. Т.е. тут всё должно быть удобно и без всяких ненужных посредников в виде системы сборки.
Вообще то говоря, в любой инсталляции любого дистрибутива Linux (ну, исключая глубоко серверные инсталляции ;-) ) у вас уже будет присутствовать, по дефаулту, вся поддержка одного из 2-х фреймворков: GTK+ или Qt
И как раз вот тут у меня вопрос. Допустим я выбрал GTK.И допустим я Экспортировал проект в code::blocks для Linux-а с использованием этого GTK. Предположим, что пользователь не имеет установленный GTK на своем ПК. Как я понимаю - это не является для программиста проблемой и он просто установит этот GTK. А теперь самый важный момент. Допустим программист собрал в code::blocks готовое приложение, которое я сгенерировал. Так как у него был GTK, то сборка прошла успешно. Но дальше теперь этот программист залил приложение на сайта и его начали скачивать уже не программисты, а обычные пользователи. И у некоторых из них этот GTK не установлен. Вопрос: у них будет работать это приложение без установленного GTK ? Практически, я спрашиваю, будет ли GTK полностью содержаться внутри уже собранного программистом приложения ? Если конечному пользователю GTK в установленном виде уже не нужен, то это вполне приемлемый вариант.
Это очень нездоровая идея - искать в Linux/POSIX/MacOS аналоги возможностям и инструментам из Windows, ... в Linux гораздо более разнообразие разных инструментов чем в Windows. Нужно искать общие приемлемые идеи, а не аналоги для переноса.
Всегда что-то берется за основу, а остальное подгоняется под эту основу. В Windows функция Drag & Drop работает как "необходимо и достаточно". Эти возможности я и закладываю в "требования", а все остальные мне просто не нужны, даже если они и будут где-то присутствовать.

Ответить

Вернуться в «Программирование»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 3 гостя