Проблема в том, что если модератор решает что пост рекламный, и «Хабр — не магазин на диване», то улетаешь в бессрочный бан. С возвращением через песочницу, да. Потому страшновато выкладывать ссылки в статьях. В комментариях вроде можно)
P.S. Было бы здорово, если бы кто-нибудь из администрации разъяснил политику партии — где проходит эта тонкая грань.
Обработка событий, на то и обработка событий, чтобы события обрабатывались…
Спасибо за информацию.
Если вы сразу этого не поняли, значит не до конца понимаете как устроены события в Qt.
Тут вы правы, мне еще учиться и учиться. Только вот согласно документации, работа с QNetworkAccessManager должна быть построена с использованием механизма слотов и сигналов, как и вся остальная система событий в Qt.
Насчёт msleep — я думал мы с товарищем midday рассматривали метод sendRequest.
Заблудились в двух собственных методах? Печально.
Лучше заменить его на… QEventLoop.
Хорошо хоть вы до конца понимаете как устроены события в Qt, и просветили нас новеллой с тремя вложенными QEventLoop в программе с тремя классами.
Тут вы не правы, что не удивительно — с таким извращением встречаешься не каждый день. Очередь событий общая для потока, и если запущен хоть один QEventLoop, события обрабатываться будут нормально, потому в данном случае вызывать QApplication::processEvents() смысла нет. Я так понимаю когда мы делаем что-нибудь вроде QDialog::exec() — применяется похожий подход.
Что по-вашему фризы? Вот мы без перерыва кликаем, например, в чекбокс во время этого действа, и он мгновенно меняет свое состояние сколько бы мы не кликали?
И в это время он ничего не делает, верно? Спит в ожидании события, хорошо.
Если бы вы использовали другую библиотеку, которая работает не асинхронно, то у вас и там главный поток «спал», пока не придёт ответ.
Давайте еще микроконтроллеры вспомним, ага. У нас ведь главный поток отвечает за отрисовку интерфейса пользователя, и если он спит пока идет запрос (максимум 2*n секунд) — UI не отвечает на внешние раздражители.
Работа с REST API в Qt, больная тема, конечно, приходится писать приличных размеров велосипеды — и все осложняется недостатком информации как правильно реализовывать нюансы этой работы.
Как уже писали выше, решение использовать QEventLoop выглядит странным, вследствии чего выполняется не менее странная проверка успешности выполнения в том же методе, без использования механизма сигналов/слотов. RequestError имеет всего два состояния, хватило бы возвращать bool. Хотя по сути ошибок может быть значительно больше, что в этой реализации не отлавливается в соответствующем слоте. Исключение как стандартный метод возврата результата в Qt — жуткий моветон, заставлять текущий (возможно главный) поток спать в бесконечном цикле, опять же без сигналов/слотов — быдлокод, и т.д.
Не хотелось бы отбить желание выкладывать код, но если честно, то Request выглядит не сильно полезнее стандартной связки QUrl + QUrlQuery, Network же с одной стороны примитивный, с другой стороны написан криво :/
Если детально, то читать вот по этой ссылке статьи снизу-вверх.
Если кратко, то вот код:
#ifdef Q_OS_ANDROID
// BUG with dpi on some androids: https://bugreports.qt-project.org/browse/QTBUG-35701
// Workaround:
QAndroidJniObject qtActivity = QAndroidJniObject::callStaticObjectMethod("org/qtproject/qt5/android/QtNative", "activity", "()Landroid/app/Activity;");
QAndroidJniObject resources = qtActivity.callObjectMethod("getResources", "()Landroid/content/res/Resources;");
QAndroidJniObject displayMetrics = resources.callObjectMethod("getDisplayMetrics", "()Landroid/util/DisplayMetrics;");
int density = displayMetrics.getField<int>("densityDpi");
#else
QScreen *screen = qApp->primaryScreen();
float density = screen->physicalDotsPerInch();
#endif
engine.rootContext()->setContextProperty("mm",density / 25.4);
engine.rootContext()->setContextProperty("pt", 1);
double scale = density < 180 ? 1 :
density < 270 ? 1.5 :
density < 360 ? 2 : 3;
engine.rootContext()->setContextProperty("dp", scale);
Тут размер в миллиметрах полностью надежен, в девайсонезависимых пикселах приблизителен, как и на Android (но надо бы потестить на соответствующих девайсах), pt для единообразия при указании размеров шрифта.
Использвать очень просто — умножаем размеры в любом месте QML кода:
Rectangle {
height: 20*mm;
width: 40*dp;
}
Все собираюсь написать статью по таким базовым вещам, но руки пока не доходят :/
К тому же я например не знаю как на десктопе симулировать различные dpi/ppi.
Симулировать нельзя, зато можно обеспечить одинаковый размер элементов на всех девайсах вне зависимости от dpi/ppi — хоть в миллиметрах, хоть в пикселах.
P.S. Было бы здорово, если бы кто-нибудь из администрации разъяснил политику партии — где проходит эта тонкая грань.
Тут вы правы, мне еще учиться и учиться. Только вот согласно документации, работа с QNetworkAccessManager должна быть построена с использованием механизма слотов и сигналов, как и вся остальная система событий в Qt.
Заблудились в двух собственных методах? Печально.
Хорошо хоть вы до конца понимаете как устроены события в Qt, и просветили нас новеллой с тремя вложенными QEventLoop в программе с тремя классами.
Как уже писали выше, решение использовать QEventLoop выглядит странным, вследствии чего выполняется не менее странная проверка успешности выполнения в том же методе, без использования механизма сигналов/слотов. RequestError имеет всего два состояния, хватило бы возвращать bool. Хотя по сути ошибок может быть значительно больше, что в этой реализации не отлавливается в соответствующем слоте. Исключение как стандартный метод возврата результата в Qt — жуткий моветон, заставлять текущий (возможно главный) поток спать в бесконечном цикле, опять же без сигналов/слотов — быдлокод, и т.д.
Не хотелось бы отбить желание выкладывать код, но если честно, то Request выглядит не сильно полезнее стандартной связки QUrl + QUrlQuery, Network же с одной стороны примитивный, с другой стороны написан криво :/
Если кратко, то вот код:
Тут размер в миллиметрах полностью надежен, в девайсонезависимых пикселах приблизителен, как и на Android (но надо бы потестить на соответствующих девайсах), pt для единообразия при указании размеров шрифта.
Использвать очень просто — умножаем размеры в любом месте QML кода:
Все собираюсь написать статью по таким базовым вещам, но руки пока не доходят :/
Симулировать нельзя, зато можно обеспечить одинаковый размер элементов на всех девайсах вне зависимости от dpi/ppi — хоть в миллиметрах, хоть в пикселах.
Отлаживаем платформозависимый код — значит нужна перекомпиляция. Если он уже отлажен, значит интерфейс пишем на десктопе.
2 пункт спорный, 4 схож с третьим.
Но, тем не менее, статья полезная, наверняка кому-нибудь пригодится.