Успешно использовал либу QJoysticks для джойстиков

Очень приятно блять.

thrust использовали на реальном проекте, работает норм, могу рекомендовать. Что быстрее - считать на цпу или передать данные (или создать) на гпу - решай сам, замерь, какие проблемы.

GPU без "головняка":
https://thrust.github.io/

в каких случаях и чем лучше stl?

а инт на сервере это сколько байт и как лежат?

огонь!

добрый день,

Прога на виджетах, без qml. Виджеты стилизуются CSS/QSS. Можно ли указывать разные растровые картинки и разные значения паддингов, маргинов для стандартного dpi и двойного (как для дислпея ретины на маке). Или надо иметь 2 разных qss для каждого виджета?

Про винду с ее несколькими вероятными коэфициентами dpi вообще думать грустно сколько надо иметь разных картинок и qss'ов..

Qt 5.10/5.11

Имхо, для тестов нужно посылать события кликов мыши и нажатия клавиш окну. Т.е. эмулировать то, что делает пользователь.

P.S. UI сделан в дизайнере или в С++ коде, private/public - это все неважно.

Посмотрел исходники Qt и Creator'a...

API не публичное, поэтому и в доках его нету. Вообще для моих целей слишком усложнено. Мне надо всего лишь чтобы JS-код выполнялся по шагам типа line by line, ну и может значения переменных чтоб можно было посмотреть из кода.

Пока заюзаю видимо старый добрый QtScript. Пусть JS-движок его медленнее, но лишь бы работало.

P.S. Да, вижу что QQmlDebugService и прочие классы, работают теперь с QJSEngine, а не с наследованным от него QQmlEngine. Но все равно привязок к QML там во всех этих debug-related классах дохренища, недаром оно не стало QJSDebugService'ом.

GreatSnake,

Отлично, спасибо. Только вот ассистант отстает, не вижу инфы там про это нифига.

Есть ли какая-то возможность выполнять JS-код построчно (трассировать) кроме как с использованием старого и deprecated QtScript модуля и старого JS-движка из него?

И тот же вопрос насчет дебага JS-кода. Какие планы у Qt-шников на этот счет?

QML - это типа чтобы снизить порог вхождения и ускорить разработку. Если знаешь С++/QtWidgets, то смысла в QML я виже не много. Например, мне кажется, проще делать анимации интерфейса (если они нужны). QtQuick Controls 2.0 сделали реально быстрыми.

Сам пишу на виджетах и не вижу для себя смысла в QML вообще.

Купить винт побольше или даже два!

1. Plugins can be linked statically into your application. If you build the static version of Qt, this is the only option for including Qt's predefined plugins. Using static plugins makes the deployment less error-prone, but has the disadvantage that no functionality from plugins can be added without a complete rebuild and redistribution of the application.

2. Смысл инсталлера/анинсталлера в удобстве для конечного юзверя. Куда при этом устанавливаются файлы - вопрос параллельный. (Конечно из-за всех этих dll-хеллов, sxs-херни (side-by-side что-то там), манифестов с версиями внутри просто не хочется возиться с этим говном, проще все носить с собой. Времена, когда десятки/сотни мегабайт были значительной частью винчестера, уже прошли.) Продвинутый юзер может предпочесть и, например, portable app вместо инсталлируемой - можно предлагать такую опцию.

3. При динамической сборке можно легко подменить Qt-шные дллки на модифицированные свои, где логируется вся активность внутри QObject'-наследованных классов, и т.о. легко* реверс-инжинирится логика программы

Очевидно, где-то утечка памяти. Сделайте минимальный пример, где воспроизводится проблема и покажите код. А так можно только тыкать пальцем в небо (например, при fetchMore данные у вас должны откуда-то загружаться и, вероятно, храниться в памяти, может у вас данных на 20Mb загрузилось)

Еще можно заюзать тулзы, определяющие утечки. (Например, если проект под Visual Studio, то можно Visual Leak Detector)

P.S. Qt-шные делегаты не создаются/уничтожаются постоянно, если вы их имели в виду