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

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

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

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

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

https://www.linux.org.ru/search.jsp?q=qt+%D0%BB%D0%B8%D1%86%D0%B5%D0%BD%D0%B7%D0%B8%D1%8F&range=ALL&interval=ALL&user=&_usertopic=on - вопросы лицензирования здесь уже разбирались, может будет полезным

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

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

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

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

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

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

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

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

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

Qt.

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

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

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

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

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

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

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

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

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

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

blog.qt.io/blog/2018/05/03/qt-microncontrollers-mcu/

Прикольно, не знал. Вангую что поддерживаются только 32-битные

Там нужна RTOS и дофига рамы, но тем не менее...

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

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

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

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

http://avaloniaui.net/

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

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

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

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

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

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

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

Какоето противоречие. В заголовке написано кросплатформенный. А в тексте Linux

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

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

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

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

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

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

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

Работоспособность под Windows должна сохраниться.

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

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

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

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

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

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

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

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

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

http://wxnet.sourceforge.net/

О да...

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();
        }
    }
}

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

Уверен что под windows оно не работает

https://youtu.be/61qmX5eAPwI?t=2874

https://github.com/SteveSandersonMS/BlazorElectronExperiment.Sample

https://blazor.net

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

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

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

Python + Python.Net + PyQt5

Ну и жесть!

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

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

https://build-system.fman.io/

https://github.com/pybee/toga

https://github.com/GoogleChromeLabs/carlo

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

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

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

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

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

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

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

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

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

managed крестах

А где managed кресты в Linux-е?

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