Кроссплатформенное программирование под Unix-ы
Модератор: Olej
Кроссплатформенное программирование под Unix-ы
Добрый день,
Про существование 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-ах, эти файлы могут храниться в разных папках, что совсем не радует. Как решается проблема с определением этого пути для общего случая ?
Про существование 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-ы
Motif - это такая же библиотека (фреймворк) графических примитивов, как и GTK+ или Qt, альтернатива им, в некотором роде (была )...
Motif:
Я ещё помню времена, когда Motif была популярной графической системой, и задавала тон, например, Open Solaris от Sun Microsystems ... но на сегодня Motif, наверное, там же где и сама Sun MicrosystemsMotif — библиотека элементов интерфейса и набор спецификаций для разработки графических интерфейсов под X Window System. Библиотека Motif появилась в конце 1980-х и на данный момент считается устаревшей[1].
...
... к тому времени, когда The Open Group выпустила бесплатную Open Motif, более современные и удобные библиотеки элементов интерфейса (GTK+ и Qt) успели набрать популярность[2].
Не заморачивайтесь.
Это не совсем так... в Unix (точнее в like Unix) намного больше различных возможностей для одних и тех же целей, чем это имеет место в Windows. Поэтому самое первейшее - отсечь те альтернативы, которые вам не подходят.
Совет для этого: первейшим делом в любой публикации, документации, инструменте, проекте и пакете - смотрите на дату (или дату последнего обновления). Используйте только то, что датировано, максимум, 3-мя последними годами. Остальное - в топку...
Это сразу уменьшит число альтернатив и ваши колебания в 10 раз.
- Olej
- Писатель
- Сообщения: 21338
- Зарегистрирован: 24 сен 2011, 14:22
- Откуда: Харьков
- Контактная информация:
Re: Кроссплатформенное программирование под Unix-ы
Во-первых ... Откажитесь от терминологии "Unix" и смотрите только то, что относится к рубрике "Linux" - ещё лет 5 назад я бы вам советовал обратное, но на сегодня реальным остаётся только Linux. Это сразу упростит.Odin_KG писал(а): ↑10 фев 2021, 02:24Другая оставшаяся у меня проблема - это иконки для файлов и регистрация расширений, чтобы заставить файлы определенного расширения открываться в нужной программе. Нашел, что для этого делаются xml-файлы с описанием нужных действий, но... у меня создается впечатление, что в разных Unix-ах, эти файлы могут храниться в разных папках, что совсем не радует. Как решается проблема с определением этого пути для общего случая ?
Во-вторых, в Unix/Linux ассоциациям файлов с их расширениями придаётся гораздо меньше значения (а то и совсем не-... ), чем это имеет место в Windows. В частности, из-за того, что в POSIX стандартах давно (изначально) допускаются многокомпонентные имена в файловой системе, например: 12345.dat.tgz.jpg.pcx ... что вы здесь будете считать "расширением"?
В-третьих, как я это представляю (или как помню ) в Linux (давайте дальше говорить только про Linux?) ассоциации файлов (расширение - предназначение) увязывается не с операционной системой, а с конкретным приложением, использующим файлы ... например "ассоциации mc", или "ассоциации Nautilus"...
- Olej
- Писатель
- Сообщения: 21338
- Зарегистрирован: 24 сен 2011, 14:22
- Откуда: Харьков
- Контактная информация:
Re: Кроссплатформенное программирование под Unix-ы
Не очень понятно что такое "из смежной области" и зачем это надо... Вот Motif, о котором речь выше - это и был продукт " из смежной области" ... вот, например, wxWindow - тоже "продукт из смежной области".
Опишите конкретней что хотите, какие цели себе ставите - разберёмся...
- Olej
- Писатель
- Сообщения: 21338
- Зарегистрирован: 24 сен 2011, 14:22
- Откуда: Харьков
- Контактная информация:
Re: Кроссплатформенное программирование под Unix-ы
Я могу вам помочь в вашей задаче ... не спеша, по мере свободного времени...
Эта, и любая программистская задача, решается примерно в такой последовательности, так:
- вы точно и строго формулируете постановку - что и для чего хотите получить, какая цель (и выкладываете эти формулировки сюда - может на этом этапе уже уточняемся);
- формулируете модельную задачу - максимально упрощённый прототип, который показывает применение выбранного инструментария...
- выясняете какой язык программирования (т его инструментальные средства) вас интересует в 1-ю очередь (потом сможете расшириться): C API, C++ (C++11, C++14, C++17, ... Boost ...), Python, Java ... ещё чего ...
- выкладываете код прототипа сюда ... (со всеми к нему командами gcc, Makefile, Cmake, Ninja и т.д. - сразу определяетесь с технологией сборки которую будете использовать - это в Windows зашёл в Visual Studio, и сам не знаешь чего "оно соберёт")
- начинаем рассматривать код, обсуждать, улучшать...
- начинаете думать как и насколько вам обеспечить мультиплатформенность прототипа (здесь в форуме были, в своё время, аактивные обсуждения на эту тему).
Re: Кроссплатформенное программирование под Unix-ы
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 мне явно не нравится.
Благодарю за такой обширный ответ!
Хорошо, давайте пойдем со сторон задачи. Я пытаюсь сделать свою среду разработки приложений. Визуально продукт чем-то похож на 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-ы
Для того, чтобы определиться с инструментарием и его возможностями (особенно если мульти-OS) - вместо возни с целым проектом сделайте минимальный (минимальный - это значит 30-50 строк на всё про всё) макет, прототип, только под изучаемую возможность (пусть в вашем случае это будет Drag & Drop) и на ней отработайте возможности того и иного инструментария.
Если у вас несколько возможностей вызывают сомнения - то сделайте несколько прототипов, под каждую изучаемую возможность отдельно, ... а не крутить это в рамках одного развиваемого проекта.
Когда определитесь с выбором того или иного tools под возможности - перенесёте его в проект.
Это очень нездоровая идея - искать в Linux/POSIX/MacOS аналоги возможностям и инструментам из Windows, ... в Linux гораздо более разнообразие разных инструментов чем в Windows. Нужно искать общие приемлемые идеи, а не аналоги для переноса.
- Olej
- Писатель
- Сообщения: 21338
- Зарегистрирован: 24 сен 2011, 14:22
- Откуда: Харьков
- Контактная информация:
Re: Кроссплатформенное программирование под Unix-ы
Вообще то говоря, в любой инсталляции любого дистрибутива 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.
А с лицензиями - это вы разбирайтесь сами (тем более что даже профессиональные юристы не до конца разбираются в разнообразных лицензиях).
- Olej
- Писатель
- Сообщения: 21338
- Зарегистрирован: 24 сен 2011, 14:22
- Откуда: Харьков
- Контактная информация:
Re: Кроссплатформенное программирование под Unix-ы
Вообще то, это не совсем правильное понимание кроссплатформенности: "пользователь выбирает OS".Odin_KG писал(а): ↑10 фев 2021, 11:05Практически, это такая библиотека, у которой имеется визуальный редактор на большинство возможностей. Далее пользователь выбирает OS и среду разработки, в которой он желает работать (или которая присутствует в настоящий момент в возможностях программы), и выполняет Экспорт.
Обычно проект с одной и той же кодовой базой собирается в разные законченные проекты (бинарники в простейшем случае) под разные OS - хорошие примеры тому: Eclipse, Geany, IntelliJ IDEA от JetBrains.
Это ещё один пункт "марлизонского балета" который вам предстоит пройти: выбрать ту систему сборки для своего кода проекта, которая будет кроссплатформенной.
Для этого определённо не годится Visual Studio со своей системой "проектов", и, очевидно, мало годится make ... а что-то нужно изобретать (выбирать) из области Cmake или Ninja (которую Google предложили для тех же целей, на сборке Chrome/Chromium).
P.S. Или вы хотели бы иметь возможность кросс-компиляции? ... но это совсем другой чем кросс-платформенность, типа такого: садимся мы за Windows 32-бит и "заказываем" компилировать свой код под Linux 64-бит? ... а то ещё и ARM?
Садится Моцарт за рояль ... и играет Генделя.
Re: Кроссплатформенное программирование под Unix-ы
Вовсе нет. Я вообще не собираюсь ничего компилировать, так как этот этап сейчас я просто не вытяну. Кроме того, как таковая "компиляция" сама по себе никому не нужна, так как там куда важнее хороший отладчик, который позволяет ошибки искать. Именно поэтому я принял решение Экспортировать результат в какую-нибудь среду разработки, где есть и компилятор и отладчик.
Не... мне вообще не нужна никакая система сборки. Я просто открываю файл проекта той же Visaul Studio в "блокноте" и визуально определяю, как там всё устроено, а потом генерирую эту структуру из своей программы, подставляя свои файлы и другие настройки. То же самое касается и code::blocks-а. В результате пользователь получает готовый проект напрямую без всяких посредников. Более того, пользователь обязательно будет в настройках проекта делать какие-то личные действия, которые я не могу предугадать, типа включать оптимизацию или свои файлы добавлять. Со своей стороны я могу в существующий файл проекта вносить лишь те изменения, которые касаются лично моей программы, т.е. я могу не трогать изменения пользователя. А это очень полезно. Я вообще процесс работы со своей программой рассматривал как взаимодействие со средой разработки пользователя, когда можно менять исходник или там или у меня, а потом переключаться между программами и сделанные изменения должны ловиться текстовым редактором. Т.е. тут всё должно быть удобно и без всяких ненужных посредников в виде системы сборки.Это ещё один пункт "марлизонского балета" который вам предстоит пройти: выбрать ту систему сборки для своего кода проекта, которая будет кроссплатформенной.
И как раз вот тут у меня вопрос. Допустим я выбрал GTK.И допустим я Экспортировал проект в code::blocks для Linux-а с использованием этого GTK. Предположим, что пользователь не имеет установленный GTK на своем ПК. Как я понимаю - это не является для программиста проблемой и он просто установит этот GTK. А теперь самый важный момент. Допустим программист собрал в code::blocks готовое приложение, которое я сгенерировал. Так как у него был GTK, то сборка прошла успешно. Но дальше теперь этот программист залил приложение на сайта и его начали скачивать уже не программисты, а обычные пользователи. И у некоторых из них этот GTK не установлен. Вопрос: у них будет работать это приложение без установленного GTK ? Практически, я спрашиваю, будет ли GTK полностью содержаться внутри уже собранного программистом приложения ? Если конечному пользователю GTK в установленном виде уже не нужен, то это вполне приемлемый вариант.Вообще то говоря, в любой инсталляции любого дистрибутива Linux (ну, исключая глубоко серверные инсталляции ) у вас уже будет присутствовать, по дефаулту, вся поддержка одного из 2-х фреймворков: GTK+ или Qt
Всегда что-то берется за основу, а остальное подгоняется под эту основу. В Windows функция Drag & Drop работает как "необходимо и достаточно". Эти возможности я и закладываю в "требования", а все остальные мне просто не нужны, даже если они и будут где-то присутствовать.Это очень нездоровая идея - искать в Linux/POSIX/MacOS аналоги возможностям и инструментам из Windows, ... в Linux гораздо более разнообразие разных инструментов чем в Windows. Нужно искать общие приемлемые идеи, а не аналоги для переноса.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 0 гостей