LINUX.ORG.RU

Кроссплатформенное приложение на C#

 


1

4

Всем здравия!

Нуждаюсь в совете разработчиков в решении одной задачи. Не так давно я присоеденился к разработке одного спец.девайса, который управляется с компьютера через USB (CDC). Весь софт написан на C# + IronPython и крутится на Windows.

С недавнего времени стоит задача портирования софта на Linux.

На данный момент есть одна C# DLL, через которую GUI общается с основной программой. Заставить стабильно работать GUI на Linux через Mono нам так и не удалось, хотя сам код включая IronPython прекрасно работает. То есть застряли именно на GUI.

Поэтому мы ищем возможность написания кроссплатформенного GUI, который сможет «общаться» с нашей DLL.

Посоветуйте фрэймворк, который позволяет такое. Пока в планах десктопное приложение для Windows/Linux. Но поддержка Android/iOS на будущее тоже не помешает.


Я предлагаю использовать Gtk+

ну и оттуда создавать mono runtime - https://www.mono-project.com/docs/advanced/embedding/

вам сейчас скажут, что нет разницы, из какого Gui вызывать mono, и предложат Qt.

Einstok_Fair ★★☆
()
Последнее исправление: Einstok_Fair (всего исправлений: 3)
Ответ на: комментарий от Einstok_Fair

на Qt мы тоже заглядывались, но пока отложили в сторону из-за непоняток с лицензиями. Девайс для тестирования при производстве и используется только для нужд фирмы. Теоретически, на лицензию можно было бы и плюнуть, но хочется «правильного» пути.

amidos
() автор топика
Ответ на: комментарий от amidos

на Qt мы тоже заглядывались, но пока отложили в сторону из-за непоняток с лицензиями

Ну и сколько же лет этот бред будет вылезать раз за разом??? Всё там нормально, некоторые даже оспаривают ограничения LGPL, что типа их можно обойти как-то и статически линковать. Но повторяюсь - динамическая линковка с либами Qt, которые поставляются с Qt SDK или скомпилированы из исходников (OE/Yocto/BuildRoot) - не составляет никаких проблем с коммерческим софтом с закрытым кодом.

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

не составляет никаких проблем с коммерческим софтом с закрытым кодом

До тех пор, пока целевые платформы ограничены десктопом и не надо распространять приложение через магазины типа App Store

annulen ★★★★★
()
Последнее исправление: annulen (всего исправлений: 1)
Ответ на: комментарий от annulen

1) гейстор не нужен 2) можно подумать, что фреймфорки для того же C# не ограничены лишь мобайл+десктоп, если уже вебня - то уже дестоп и мобайл не так хорош

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

гейстор не нужен

Есть дофига всяких магазинов, я сначала написал Steam, но не знаю точно, какие там условия распространения (вангую, что проблемы с соблюдением LGPL такие возникнут же)

можно подумать, что фреймфорки для того же C# не ограничены лишь мобайл+десктоп, если уже вебня - то уже дестоп и мобайл не так хорош

А причем тут ограничения, кьют можно гонять почти на любой практически значимой платформе (кроме микроконтроллеров разве что), проблема в соблюдении условий LGPLv3, касающихся т.н. «тивоизации»

annulen ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Ну значит завтра обсудим с коллегами. Тем более с Qt я немного знаком.

Кстати, а как на счет Node.js + Electron? Просто сегодня рекламировали мне его немного. Подходит для подобных проектов?

amidos
() автор топика
Ответ на: комментарий от peregrine

А кому-то нужны. Раскрутить коммерческий продукт через популярный магазин тупо проще, сначала проплачиваешь рекламу в магазине, а потом уже кому-то в рекомендации вылезет, кто-то поиском найдет, увидит хороший рейтинг и тоже купит. С триалами все проще, пользователю не надо платить деньги сразу, он может поставить ограниченную версию и разблокировать недостающие фичи за деньги через покупки внутри приложения. А если говорить про тот же Steam, то там не только магазин, но и готовая инфраструктура для создания сетевых игр

annulen ★★★★★
()

Заставить стабильно работать GUI на Linux через Mono нам так и не удалось

Да, там есть много подводных камней. Вернее, было, как сейчас - не знаю. Когда-то давно мне доводилось участвовать в одном проекте под .NET ( http://www.artisteer.com/ ) и его релиз под Mac как раз провалился по причине того, что в недрах недр эмуляции GDI+ через пень-колоду, код регулярно, но непредсказуемо валился, тот тут то там. Я успел уйти из той конторы, но, по-видимому, народ ещё долго пытался отловить ошибки, и, по-видимому, безрезультатно.

MetalBeaver
()
Ответ на: комментарий от annulen

Какой еще GDI+, там же есть биндинги к Cocoa

Ну, блин, я не помню всех нюансов, уже столько лет прошло. Понятно, что под капотом не GDI+. У меня из головы вылетело, что именно. Но снаружи же используются всё те же классы для отрисовки графики, что и под виндой, из System.Drawing и прочего: Graphics, Bitmap, etc., которые под виндой юзают именно GDI+, а под маком/*nix гоняются через какие-то прокси.

MetalBeaver
()
Ответ на: комментарий от MetalBeaver

Я к тому, что надо было UI отдельный делать под макось, а не экномить. Если это конечно был не специализированный софт, где юзерам насрать как оно выглядит от слова совсем

annulen ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Всё там нормально, некоторые даже оспаривают ограничения LGPL, что типа их можно обойти как-то и статически линковать.

Так собственно, LGPL и не запрещает статическую линковку. LGPL требует только, чтобы у пользователя была возможность пересобрать полученный продукт с другой версией LGPLной библиотеки. А для этого можно предоставить, например, объектные файлы продукта. Но в большинстве случаев да — проще скомпоновать динамически и не забивать себе чердак.

Ну и патченье самой Qt требует, чтобы патченые файлы (Qt, не прикладной программы) тоже распространялись под LGPL.

hobbit ★★★★★
()

Avalonia как вариант, но оно вроде как вечная бета.

http://avaloniaui.net/

GTK# непонятно насколько живой.

Под мобильные платформы Xamarin, но он не сочетается с десктопом.

По всему выходит, что самый кроссплатформенный вариант - веб гуй (внезапно, да), в каком-нибудь варианте реализации (electron, как сейчас модно, или selfhosted aspnet приложение через кестрел, но для последнего нужно .net core, а не моно)

Midael ★★★★★
()
Ответ на: комментарий от annulen

Я к тому, что надо было UI отдельный делать под макось, а не экномить.

Я в проекте ничего не решал от слова «совсем». Может и надо было.

MetalBeaver
()
Ответ на: комментарий от Midael

Он мертвый, решили 3 версию не делать.

ТС, бери Qt, линкуй динамически и не парься.

ArkaDOSik ★★
()

Вантузятник, ты здесь не нужен!

anonymous
()
Ответ на: комментарий от hobbit

А для этого можно предоставить, например, объектные файлы продукта.

Это а)гемор и б)сильно упрощает реверс-инжиниринг

annulen ★★★★★
()

Поэтому мы ищем возможность написания кроссплатформенного GUI, который сможет «общаться» с нашей DLL.

В каком смысле «общаться» с DLL? Обычно под общением с библиотекой подразумевают линковку, и тут варианты ограничены тем, что может работать в Mono или как оно там сейчас называется. У Qt с этим не все гладко, был раньше биндинг для C#, да его давно забросили, насколько мне известно. А вот если предполагается IPC, тогда можно использовать что угодно, но фактически «общаться» гуй будет уже не с DLL, а с процессом-воркером

annulen ★★★★★
()

Кроссплатформенное приложение на C#
C#

если берёте вендорлокнутые языки программирования типа сишарпа и свифта, то о кроссплатформенности можете забыть, надо было раньше думать

anonymous
()
Ответ на: комментарий от anonymous

Проект разрабатывается уже семь лет, и всё написано на шарпе. Переписывать всё с нуля не вариант, очень много кода.

Изначально был проект с использованием WindowsForms + MetroUI, но в таком виде оно было вообще неработоспособно под линуксом. В итоге был написан «wrapper», который полностью отделил код от GUI. В таком виде сам код 100% работоспособен на Linux под Mono (даже на Raspberry Pi запустили). Поэтому основной код переписывать никто не будет.

amidos
() автор топика

Приложение на моно (тот самый экзешник) будет рабоать в линуксе через нативную моно. Просто пишите без привязки к вендоспецифичным виджетам (которые не поставляются с моной). Правда я не знаю зачем использовать дотнет, он же такое тормозное ненужно... Берите лучше джаву, больше толку будет (конечно постоянно дёргать нативный код всё равно придётся, но та хотя бы не создаёт видимости нормальной производительности).

anonymous
()
Ответ на: комментарий от anonymous

Согласен, биндинги к GTK+ и Qt для Свифта и C# выглядят мертвыми...

ИМХО для гуйни лучше всего питон, даже если кого-то расстраивает 59 fps, то есть cython или pypy (пока с ним работает только pygobject). Я вот вообще тыкаю мышкой в Glade, а потом просто логику пишу в питоне. И цеплять потом этот GUI можно куда угодно.

ArkaDOSik ★★
()
Ответ на: комментарий от anonymous

надо было раньше думать

Надо было еще раньше думать: когда геймер начал считать, что он — программист!

Кто ж под вантузом-то разрабатывает? Писали бы сразу под линуксом, появилось бы уйма идей, как это на прошивку для игровых приставок портировать (только зачем?)

anonymous
()

Покажусь оригинальным, но сделайте его запускаемым в WINE.

Artificial_Thought ★★★★
()

http://webserver2.tecgraf.puc-rio.br/iup/

using System;
using System.Runtime.InteropServices;

namespace IUPHello
{
    class Program
    {
        const String iup_lib = "iup.dll";

            [DllImport(iup_lib)]
            public static extern void IupOpen();

            [DllImport(iup_lib)]
            public static extern void IupClose();

            [DllImport(iup_lib)]
            public static extern void IupMessage(string title,string message);

        static void Main(string[] args)
        {
            IupOpen();
            IupMessage("Hello World", "Hello world from IUP.");
            IupClose();
        }
    }
}

https://github.com/filcuc/DOtherSide

using System;
using System.Runtime.InteropServices;

namespace ConsoleApplication
{
    public class Program
    {
    const String dotherside_lib = "DOtherSide.dll";

    [DllImport(dotherside_lib)]
    public static extern void dos_qapplication_create();

    [DllImport(dotherside_lib)]
    public static extern IntPtr dos_qqmlapplicationengine_create();

    [DllImport(dotherside_lib)]
    public static extern void dos_qqmlapplicationengine_load_data(IntPtr engine, String app);

    [DllImport(dotherside_lib)]
    public static extern void dos_qapplication_exec();

    [DllImport(dotherside_lib)]
    public static extern void dos_qqmlapplicationengine_delete(IntPtr engine);

    [DllImport(dotherside_lib)]
    public static extern void dos_qapplication_delete();

    const String app = @"
        import QtQuick 2.2
        import QtQuick.Controls 1.2
        import QtQuick.Layouts 1.1
        import QtQuick.Window 2.1

        ApplicationWindow {
            width: 800
            height: 600
            title: ""Hello World""
            Component.onCompleted: visible = true
        }
    ";

        public static void Main(string[] args)
        {
            dos_qapplication_create();
            dos_qqmlapplicationengine_create();
            IntPtr engine = dos_qqmlapplicationengine_create();
            dos_qqmlapplicationengine_load_data(engine, app);
            dos_qapplication_exec();
            dos_qqmlapplicationengine_delete(engine);
            dos_qapplication_delete();
        }
    }
}

Deleted
()

GTK#, Avalonia все на для С#.

anonymous
()
Ответ на: комментарий от Deleted

Спасибо! Будем посмотреть.

Я обязательно напишу в этой теме на чем мы остановили свой выбор.

p.S. Сегодня пробовал связку Python + Python.Net + PyQt5. Под Windows заработало. Пол линуксом на днях погоняем. Коллега завтра засядет за Electron.net и Proton Native.

amidos
() автор топика
Ответ на: комментарий от amidos

Python + Python.Net + PyQt5

Ну и жесть!

Что ж сразу на жабке не накалякали свою поделку?

anonymous
()

Было из чего выбирать... Тут либо Qt ,либо gtk, но на Винде гтк не удобен от слова сильно ... Так что выбор очевиден

jo_b1ack ★★★★★
()
Ответ на: комментарий от anonymous

если берёте вендорлокнутые языки программирования типа сишарпа и свифта, то о кроссплатформенности можете забыть, надо было раньше думать

кококие ИТТ незамутненные вскукареки от кукаретиков.

slackwarrior ★★★★★
()
Ответ на: комментарий от amidos

Лицензия требует раскрытия всех ваших изменений в исходном коде Qt (если вы решите перепилить что-то в нём под себя, наследование не считается, речь именно о модификации исходного кода стандартных классов Qt) + нельзя статически линковаться с вашим кодом (нужно обязательно использовать системную либу, либо таскать с собой все so-шники от Qt). Если вы не собираетесь копаться в потрохах Qt и вам не нужно распространять приложение в виде «один статически слинкованный бинарник, а не каталог с кучей файлов», то вы можете использовать Qt как обычную LGPL либу. Также не следует забывать, что GPL/LGPL требует раскрытия изменений и обеспечения прочих прав для ПОЛЬЗОВАТЕЛЕЙ ПО. То есть в случае софта внутри организации ваши патчи для Qt вам необходимо предоставлять только своим же сотрудникам (и можно делать это только по письменному запросу). Вам не нужно это делать для левых людей с улицы (но сотрудники будут иметь право распространить ваши патчи для Qt дальше).

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 3)
Ответ на: комментарий от anonymous

Приложение на моно (тот самый экзешник) будет рабоать в линуксе через нативную моно.

без вендоспецифичных сборок оно чаще всего и без перекомпиляции «для моно» будет работать (и даже с винформз) собранное под сам .Net и тупоскопированное на онтопик :) Раньше утилита МоМа удостоверяла отсутствие гвоздей явно прибивающих прогу к венде (типа маршалингов к нативным dll), но погромисты которые сами пишут это все должны и сами знать, где у них что прибито.

Еще в 2011-м году прекрасно завелся без перекомпиляции под онтопиком набор давно написанных под оффтопик WCF и Rest сервисов (что там было тогда обозначено как «унсуппортет» и под оффтопиком не особо кто юзал, т.к. конфигурация его со всеми SOAP приблудами представляла собой дикую кашу из XML даже под вендой, которую кашу отламывали в первую очередь, заменяя конфиги на простой XML, и при первой возможности переделывали SOAP на RESTful, потому что можно просто через браузер дергать :)). Имеющуюся гуйню под винформз вообще не переделывали никогда «специально под моно». (Демку в виде «астероидного» игоря, собранного под .Net в MSVS 2010 и запущенного под слакой я постил примерно тогда, только ее «удолили как оффтопик» тупые ограниченные фанатики :))

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)

ТС, а ты пробовал C# dll с кодом на крестах под виндой подружить? Думается, что под Linux-ом и подавно не получится. Ну или с дружбой между процессами колдовать.

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от peregrine

ТС, а ты пробовал C# dll с кодом на крестах под виндой подружить?

чотакога-то? :) «C# dll» с кодом на крестах или даже на дельфях дружится через... dll с кодом на managed крестах, который помогает делать экспорты из C# сборок, в которых экспортов нет бай дизаен (другой путь — IL-хаки прям руками или утилиты, которые патчат сборки). А так можно лехко делать .Net-плагины для нативных прог, которые не знают что такое .Net или C#, но у которых есть интерфейс плагинов.

slackwarrior ★★★★★
()
Ответ на: комментарий от peregrine

Твой вопрос был про «ты пробовал C# dll с кодом на крестах под виндой подружить?». Под виндой дружили уже много раз в разных позах. Все способы подбиты тут: https://stackoverflow.com/questions/778590/calling-c-sharp-code-from-c (их больше трех :))

slackwarrior ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.