Comments 13
А то вылили на нас ушат с этим кодом и что нам с ним делать?
Сам пробовал, портировать несложное приложение с UWP. В целом заработало, даже избавился от некоторых костылей. Но, есть и бочка дёгтя. Под Android запускается только Debug версия, при этом тормозит нещадно, реакция на действия десятки секунд. Под убунтой упомянутые файловые диалоги не открываются. А разработчики, похоже, сосредоточились на iOS. Жаль.
С диалогами был некоторый просчёт в проектировании API, когда буквально все требовали "как в WPF", ибо "на винде работает же". В итоге по дефолту ShowDialog не принимал родительского окна, что вызывало ряд спецэффектов с линуксовыми оконными менеджерами, имеющими особое мнение о том, где и как надо показывать свежепоявившиеся окна. Особенно странностями страдает третьегномовский Mutter, который окно может не показать вообще, ибо у GTKшного файлодиалога выставлен _NET_WM_STATE_SKIP_TASKBAR. Усугублялось это тем, что тестировалось всё обычно на Ubuntu+Unity, а Compiz подобной самодеятельностью не страдает, и всё работало.
Сейчас все диалоги в обязательном порядке требуют наличия родительского окна.
В общем, линуксозоопарк десктопных, о ряде особенностей которых можно узнать только по багрепортам. Особый смак — когда проблемы очередного WM не проявляются при запуске оного под Xephyr (приходится запускать отдельную сессию), либо дистрибутивозависимы (приходится запускать виртуалку, а там обычно ещё и llvmpipe в качестве драйвера), либо дистрибутиво- и драйверозависимы (проще повеситься). Как optirun ломает dlsym(dlopen("libdl.so.2", RTLD_NOW), "dlsym"), что делает невозможным использование dlsym через [DllImport] — вообще отдельная история.
Ещё имели кучу проблем с патчеными версиями GTK (привет, ElementalyOS), из-за которых ничего не работало. Сейчас, вроде, осилили бакэнд, работающий напрямую с libX11 и с GLX, стало немного полегче.
Примерно то же самое, что и с iOS — сделали экспериментальные бакэнды, чтобы понять, где лежат грабли, и какие вообще у платформ ограничения, после чего сосредоточились на самом фреймворке и поддержке десктопа. Вот тут я с месяц назад расписывал, чего не хватает для нормальной работы на мобилках.
С андройдом в частности главная проблема в том, что на нём очень много low-end девайсов, а моновский AOT-компилятор под эту платформу далеко не так хорош, как под iOS. Отсюда тормоза. А если по каким-то причинам OpenGLES не заведётся, будет совсем грустно (сейчас вот он там у нас после миграции на SkiaSharp выключен, например).
Я сейчас потихоньку делаю компилятор XAML в MSIL, что должно снять хотя бы часть проблем со временем загрузки, но в целом нормальную поддержку мобилок раньше конца года ожидать не стоит.
GTK уже научился в per-monitor DPI на X11? У них же иксы теперь "устарели" и все силы брошены на новый более лучший дисплейный сервер. Да и отрисовку из не-UI потока нормально не сделать.
В целом же "мешает" ими пользоваться неимоверная боль при попытке написать что-то сложнее хелловорлда привыкнув к XAML-фреймворкам, где есть нормальная человеческая поддержка MVVM.
Моя прошлая попытка изготовить что-то на GTK# закончилась переписыванием на C++/QtWebkit/JS (электрона в те годы не было)
Avalonia: первая встреча