тогда даже кеды их не юзали при этом же

например

с qml в кути ваще жопа, если хочешь свой С++ компонент от QML сделать, там без привата никак

у них там вообще сотонина, _p_p есть даже

вот сейчас листаю, они ругались на беды с созданием кастомных контролов

Когда-нибудь я таки осилю этот уебанский API tdlib и сделаю свой клиент. Когда-нибудь.

На самом деле неочевидно. Если ты хочешь аппаратно ускоренный графон в кросс-платформенном десктоп-приложении, то это как будто или электрон или qml.

(если няшный UI хочешь)

И примеров прям няшных десктопных софтин на qml с хорошей поддержкой в том числе на винде и маке чёт не видно. Популярных кажется нет ни одной.

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

м.. это отстой.

но его присутствие на маке и винде гораздо важнее.

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

Это не даст мне хорошей гарантии его работы на винде.

последнее сообщение exactly про кеды

это все из tdesktop contributions таки, а не из группы кепки

В QML всё ещё нет некоторых базовых для Desktop вещей. Например — нет событий context menu requested.
Задача для Qt Quick Controls 2 висит с низким приоритетом.

На практике отсутствие базового API для ContextMenu оборачивается плохим UX для macOS — там привыкли на touch pad тапать с зажатым Control для вызова контекстного.

(Я на работе пилю мессенджер на QML для Desktop, но пока получается... куда хуже, чем Telegram Desktop 😁)

Вот-вот. У QML вообще нет приоритета на десктопе, в результате на нём делать популярный софт тупо страшновато. Электрон сто% гораздо лучше там поддержан.

На виджетах чуть менее страшно, их и хакать и отлаживать проще, если лагает (и это приходится делать время от времени), но там хоть можно отладить и запатчить, в плюсах.