А теперь тонкий момент. Сколько нужно ожидать события от пользователя, что бы потом пойти продолжить исполнять колбэки, что бы гуй «не тормозил»?

Спать пора, извини :) Но я не думаю, что события от пользователя ожидаются. Думаю, если их нет, то они просто в очередь не попадут.

При пустой очереди тред дремлет в ожидании её заполнения.

А вообще ЕМНИП там ещё бывает приоритет, например, WM_CLOSE идёт out-of-band. И там делается (в tk) peekMessage с фильтрацией по типу WM_CLOSE (а не то, что его приоритет поддерживается самой очередью). Т.е., затормозить при забитой очереди есть где.

А скорее всего, я тебя просто не понял.

Python (kernel) + Qt (GUI) = PyQt

На плюсах писать боль - хочется что-то более человеческое. Допустим с Rust.
Но приложение будет GUI, а значит Qt.

Бери PyQt и пиши ядро на Python'е. Зачем тебе Rust?

Еще варианты:

• Perl + Qt = https://github.com/KDE/perlqt
• Lua (JIT) + Qt = https://github.com/tdzl2003/luaqt

Достаточно взглянуть на это, чтобы понять, что только псих будет использовать связку Rust/Qt.

https://github.com/rust-qt/cpp_to_rust/blob/master/qt_generator/qt_generator/...

Ох, ты ж е%?№*. И эти люди ругают С++.

Ну смотри, человеческий глаз, скажем геймерский различает люфт в миллисекунду (учитывая тёрки про кино, и про 25ый кадр, эта цифра сильно занижена). Остальное тело ещё медленнее.

Но, если раз в эту условную миллисекунду не обработать действие пользователя или не перерисовать изменившуюся картинку, будет заметно то, что в простанородье именуют «лаг».

Поэтому типовой gui поток (Qt тут 100% не исключение в их эвент луп я сравнительно недавно лазил в 5.6 версию вроде) - после обработки очередного колбэка (или 10 колбэков например), засыпает до наступления события от пользователя или истечения таймаута.

Отсюда, gui поток по определению проводит очень много времени во сне/обработке io, если не давать ему спать ui будет «тормозить».

Это я всё подвожу товарища TC, к мысли о том, что ни о каких гигантских потоках данных, распаковка/запаковка которых будет жечь проц на пропалую, речь идти не может, в силу того, что устройство ввода вывода не просто медленнее чем процессор, оно ещё и медленнее чем практически любое ipc (если не брать экзотические для такого сценария вещи типа Bluetooth или gpio или медленных сетевых соединений).

Другой вопрос, что в выбранным им подходе, ему придётся реализовать интерфейс mvc на rpc api, т.е. в случае Qt, повторить интерфейс QAbstractItemModel, ну и можно ещё обмазать всё это кэшированием.

Я тестил JSON-RPC. Тормоза были космические.

Хотелось бы знать, в сравнении с чем и на сколько процентов. И где тратилось время. И почему JSON, а не msgpack или CBOR (оба есть в serde, оба есть для Qt).

Ну а про профит - это личный проект. Что хочу - то и ворочу. Сроков нету.

Даже у личных проектов есть цель. Если цель - не писать на Си++, то я предлагаю GUI на libservo. Если же цель - получить что-то работающее, то... нужно минимизировать трудозатраты.

https://github.com/rust-qt/cpp_to_rust/blob/master/qt_generator/qt_generator/...

Ох, ты ж е%?№*. И эти люди ругают С++.

Пфф. Это не может напугать ни одного действующего Си++-программиста.

Пфф. Это не может напугать ни одного действующего Си++-программиста.

Не всех, но может. Впрочем думаю, что и многих rust-ев тоже.

Сталкивались. Потом подтянули скиллы и писать на плюсах перестало быть болью.

hsqml довольно неплох. Можешь сам для своего любимого язычка подобное запилить, если есть желание и время.

На плюсах писать боль - хочется что-то более человеческое.
Как решить данную задачу? Уверен, что кто-то с таким сталкивался.

Осилить, наконец, плюсы. Кстати, как раз Qt, сильно облегчает пользование плюсами. Во-первых, батарейки, во-вторых, сигнально-слотовый механизм, в-третьих какое-никакое RAII на parent элементах, в-четвёртых, совместимость с последними стандартами.

Но можно просто взять Qt4, там были биндинги к другим языкам.

Попробуй dqml. https://github.com/filcuc/dqml

Осилить, наконец, плюсы.

Не все могут достигнуть дзена уровня "ЛожкиГраблей нет".

Можно определиться с владельцем и пересылать только [CStr] в раст или const char*[] в C++.

Простой запрос на Rust GUI Выводит на http://relm.ml/relm-intro

Одна беда, он не может в цель x86_64-pc-windows-msvc.

А том, что ему нужен nightly - это не беда?

А этот фатальный недостаток я просмотрел.

ну так бери и пиши

Ну там либо писать boilerplate руками, либо использовать nightly.

В общем посмотри как реализуется основной цикл gui приложения

Я прекрасно это знаю. Заставить Qt тормозить можно только быдлокодом. Там всё хорошо оптимизировано.

Простой запрос на Rust GUI Выводит на

Ну уж про доступные обёртки для раста я в курсе.

Только указанный вами relm построен на GTK+, а значит не нужен.

Хотелось бы знать, в сравнении с чем и на сколько процентов.

В сравнении с забиранием данных напрямую. В процентах? Ну раза в 3-4 медленнее было. Всё время тратилось на «трансформацию». У меня в расте удобная структурка и в C++ удобная структурка. Перенос данных из одной в другую и был долгим.

Если цель - не писать на Си++, то я предлагаю GUI на libservo.

Мне нативный GUI нужен.

Цель - эксперимент.

qml и для раста есть. Только qml жирный и не умеет нативный гуй, с недавних пор.

Я на плюсах пишу 8 лет. Пока не осилил.

Так смысл мне от char*? В rust - utf8, в Qt - utf16.

Так смысл мне от char*? В rust - utf8, в Qt - utf16.

Ты в гуе собрался миллионы строк показывать и все сразу? Бери QString::fromUtf8 и вперед.

Тогда ты должен так же и понимать, что ни о каких объёмах данных способных хоть сколько то загрузить процессор на распаковку/упаковку в ui поток ты не подашь.

Ну и плевать, не? Тебе шашечки или ехать?

Наркоман? Мне нужен нативный GUI. QML тут вообще не при чём.

Зачем? Это какая-то реальная необходимость, или тебе просто так хочется? Я к тому, что выбор тут не то чтобы большой: qml, electron, tk. Можно ещё gtk покопать, но он вроде как убого выглядит везде кроме лялекса.

Те же Chromium и WebKit 2 работают на RPC, и производительность упирается совсем не в сериализацию

Что значит «зачем»? Мне нужен нативный гуй. ТЧК.

Знаю. Мне вот что-то подобное нужно. Но у них же один язык, а у меня два.

Но у них же один язык, а у меня два.

Один язык позволяет обойтись одним кодогенератором для RPC, если языки разные то нужно два. Вот и вся разница

На плюсах писать боль - хочется что-то более человеческое. Но приложение будет GUI, а значит Qt.
Допустим с Rust.

Хотелось бы для начала понять чем именно раст в данном контексте более человечен. В предыдущей твоей теме это так и осталось тайной Ищу нормальную инициализацию константных структур

На расте легче писать, чем на C++. Ваш КО.

Именно поэтому на расте так до сих пор и не написали ничего стоящего (даже библиотеку GUI)? Я серьёзно: раст по всей видимости не про лёгкость. В отличие от предлагавшегося Питона или, например, джаваскрипта (хотя и в этих случаях лёгкость может быть лишь относительной).

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

На динамических языках ничего сложнее hello world я не пишу и не собираюсь.

на расте не написали библиотеку GUI?
В отличие от Питона или джаваскрипта

Для питона и жабоскрипта появились библиотеки GUI?

На расте легче писать, чем на C++. Ваш КО.

Пока что примеры, указанные выше, для работы c гуйней показывают обратное, rust накладывает существенные ограничения и не выглядит выразительно.

Я тестил JSON-RPC. Тормоза были космические.

Хотелось бы знать, в сравнении с чем и на сколько процентов

В сравнении с забиранием данных напрямую

«Забирание напрямую» - это не ответ. Если имеется в виду передача бинарных данных без всякой сериализации, то 3-4 раза при сериализации в JSON - это вполне ожидаемое замедление скорости передачи данных. Но обычно приложение состоит не только из передачи данных, ну и JSON, как сказано выше, не самый эффективный формат.

У меня в расте удобная структурка и в C++ удобная структурка.

...но тем не менее ты передаешь данные через JSON. Так себе решение.

Но приложение будет GUI, а значит Qt

Мне нативный GUI нужен.
Цель - эксперимент.

В сравнении с забиранием данных напрямую. В процентах? Ну раза в 3-4 медленнее было. Всё время тратилось на «трансформацию». У меня в расте удобная структурка и в C++ удобная структурка. Перенос данных из одной в другую и был долгим.

Тот самый случай, когда ты страдаешь из-за того что авторы qt выбрали именно кресты. Точнее из-за того что у вас разные представления о том на каких языках писать. Хранить все данные без каких либо хитрых изменений и без переписывания кода не получится. Просто пора понять что придётся писать либо свою библиотеку(кажется ты там хотел кросплатформенность. не забудь поделится ^͜^) либо использовать прослойки.

Пробовал FFI (при использовании языка с GC - отпадает)

В qt(как в прочем и в куче других библиотеках) есть автоматическое управление памятью. При этом оно не на много лучше gc.

Также теряются все гарантии языка

Разве могут быть какие-то гарантии если в программе будет использоваться код в котором нет модели безопасной работы с памятью? Только вот пожалуй это касается всех гуи библиотек.

из-за того что авторы qt выбрали именно кресты

А у них был выбор?

Просто пора понять что придётся писать либо свою библиотеку

Аналог Qt? Это неподъёмная задача.

А у них был выбор?

Любой может начать создавать свой язык. Вопрос в том хватит ли у него знаний не создать второй c++ или паскаль, а создать что-то лучше. Влияние чтоб распространить свой язык у авторов qt наверняка есть

Аналог Qt?

А как иначе отойти от того что в разных языках данные хранятся в разных форматах? Если есть какой-то общепринятный формат для создания объектов, коллекций... Имхо таким могут похвастаться только языки для виртуальных машин.

Это неподъёмная задача.

Даже если реализовать часть из того что там есть?

Пример: есть база с кучей записей. Нужно отобразить их в проге. Ну пусть тысячу строк

Проблема в передачи больших объемов данных

Зачем брать все данные сразу? Ты уверен что запрос нельзя разбить на части, по крайней мере вывод на экран?

Любой может начать создавать свой язык.

Нет, не может.

Даже если реализовать часть из того что там есть?

Даже 1% не потянут. Посмотрите на кучу заброшенных биндингов к системному API, типа libui. GUI - это титаническая задача.

Ты уверен что запрос нельзя разбить на части, по крайней мере вывод на экран?

Если мне нужно отобразить 1000 строк, я не буду их разбивать на части.

Если мне нужно отобразить 1000 строк, я не буду их разбивать на части.

Что мешает передать первые 100 и продолжить обработку оставшихся 900?

Любой может начать создавать свой язык. Вопрос в том хватит ли у него знаний не создать второй c++ или паскаль, а создать что-то лучше. Влияние чтоб распространить свой язык у авторов qt наверняка есть

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

eao197, не сможешь? Тогда тебя вычеркну.

Тогда прокрутка в проге будет лагать. Не вариант.

Тогда прокрутка в проге будет лагать

Не будет. При загрузке rust будет по частям отдавать копию данных. Её как раз можно преобразовать средствами qt. Потом при изменении одного элемента qt будет передавать в rust что конкретно изменить. Прокрутка не изменяет данные, как следствие вызывать rust нет смысла

Лагать будет при запросе следующих данных.