Russian Qt Forum

Всем хай!

Есть необходимость, в потоке, создавать GUI объекты. Но программа вываливается с сообщением типа сяго:
(http://pic.ipicture.ru/uploads/091128/1W52NQo15w.png) (http://ipicture.ru/)

Кто-то сталкивался с подобной нуждой? Ну вот позарез нужно создавать объекты в потоке. Вот :)

GUI можно создавать только в главном потоке. И нужды создавать их в другом потоке, все таки нету.

Юра, а мне нужно. И это не баловство/игрушки, реальная задача.
Хочу в цикле, создавать объекты типа QWebView. Чтоб страницы вебовские загружать, с поддержкой ява-скрипт.
Как это реализовать?

У меня похожая трабла. Нужно использовать QWebView (или QWebPage), загружать в него QUrl - и так во многих параллельных потоках для написания веб-сёрфера. Какие тут ещё альтернативы кроме многопоточности?
Я использую QT Jambi (java-фреймворк над QT), объекты QWebView и QUrl в отдельном потоке создаются (в отличие от сишного qt) и можно легко оперировать их методами, за исключением QWebView.load(QUrl), где выдаёт:
Весь инет перерыл в поисках, нашёл даже похожую проблему (http://labs.trolltech.com/forums/topic/1469?replies=1), но там ответ, думаю, будет не скоро.

Нельзя и точка! В ассистанте все написано. Даже в сообщении об ошибке об этом идет речь.

Можно попробовать сам QWebView создавать в главном потоке, а в дочерних потоках работать с объектами классов QWebPage/QWebFrame.

Ладно, нельзя. Но почему?! ???

Где можно почитать внятные разъяснения?
В сообщении об ошибке, сообщается ошибка, а не причина невозможности создания ГУИ объектов в потоке.

Ну если нельзя, то что тут сделаешь!

Я думаю что QWebView для загрузки сам создает поток в котором и грузит данные.
А создавать QWebView можно отправляя сигнал из второстепенного потока объекту в главном потоке, который его и создаст, так что это не проблема

Т.е. в основном потоке, создать слот, который будет создавать QWebView, и испускать сигнал с аргументом типа QWebView*, обратно в поток? А вас правильно понял?

Кажется это реально выполнимая задача ;)

Да.
А можно и поизвращаться. У меня была задачка:
При длительной обработке данных(исталляция пакаджа) в другом потоке в определенных случаях создавать дополнительные виджеты. Причем это было в некотором объекте который ничего не знает про то, в каком потоке работает и не должен знать! Мало того создание виджетов делалось где-то в цикле и соответственно даже если бы объект и знал про поток, то сделать посылку и получение сигнала было бы тяжело и сильно все портило бы.
Так что я сделал синхронизирующий вызов метода унаследовав свой QApplication и QThread.
Если интересно, посмотри тему:

http://www.prog.org.ru/index.php?topic=10041.msg59182#msg59182 (http://www.prog.org.ru/index.php?topic=10041.msg59182#msg59182)

Здесь все достаточно просто - сам OC это не держит (по крайней мере не все ОС). Например если просматривать те же ф-ции базовой графики/рисования то легко можно натолкнуться на "not thread-safe"
Так что это не вина Qt

Spectre
Огромное спасибо! По идее это то, что нужно.

Но один вопрос остается без ответа: Почему ГУИ объекты нельзя создавать в потоке? Где об этом можно почитать? Может какой костыль написать? ;D

п.с.
эх...Константина бы сюда...

Да, согласен. Но если объекту не указывать parent/paint_device, то он и рисоваться не будет. Что в этом случае мешает?

Написано в ассистанте, где точно не помню. Почему, никогда специально не разбирался, но в C++ Builder, точно так же.
Вот костыль и написал. :)
Если будешь юзать причитай тему до конца, там есть правки.
Там есть еще define для простого вызова viod методов для this:
MyClass::anyMethod(....)  {
...
// вместо
// this->methodforsync();
// вызываем
sb_synchronize_method(MyClass, methodforsync);
...
}
MyClass::methodforsync(void)  {
...
...
}

По идее - ничего, ведь можно же создавать QObject в любой нитке. Но гораздо проще (и лучше) сказать как сказано "GUI только в главном потоке" вместо того чтобы вдаваться в долгие объяснения. А вдруг рисование будет вызвано косвенно чем-то типа grabWidget? А вдруг виджету надо себя закешировать? И.т.д  и.т.п. В конце концов что это за элемент UI который не рисуется?

И вообще, нечего распускать пользователя обилием возможностей, он это не ценит. Не так уж давно ВСЕ обращения к ОС возможны были только в главной нитке - и ничего, работали.  

Spectre
Спасибо. Изучаю вашу тему по ссылке.

Igors
Вынужден согласиться. Так как написание правильного алгоритма, займет меньше времени чем ковыряние поднаготной Qt ;)

Да это скорее не ограничение Qt, а ограничение любого графического интерфейса.

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

Также при сложных интерфейсах (в которых виджеты могут перекрывать друг друга) необходима оптимизация обновляемых регионов. Например, перерисовывается виджет нижнего уровня, который на 90% перекрыт виджетами верхнего уровня, то целесообразно перерисовывать только видимую часть (10%) этого виждета. Такая оптимизация возможна только если рисование всего происходит в одном месте (главном потоке, например).

Не согласен

Пункт 1
Это обеспечивается операционкой, поскольку существует множество GUI процессов. И если бы это было так как ты написал, то проблема была бы на уровне главных потоков этих процессов.

Пункт 2
Примем:
Виджеты 1-го уровеня виджеты не прекрываемые другими виджетами и не содежащие другие виджеты
Виджеты 2-го уровня - могут содержать только виджеты 1-го уровеня или быть ими пререкрыты
Итд..

1 вариант) Пререрисовка в главном потоке.
Имеем виджет 2 уровня который перересовываем, соответственно виджеты 1-го уровня пресекающиеся с ним - будут ли они перерисовываться? - НЕТ. Прересовываятся только видимые регионы.
2 вариант) Пререрисовка в разных потоках.
Все тоже самое как и в пункте 1. Разница только в том что для получения регионов виджета(их несколько из-за перекрытий) требующих перерисовки может потребоваться Mutex




Предположим имеем виджет 2 уровня

Что обеспечивается операционкой?
В Qt операционка управляет только виджетами верхнего уровня. Все внутренние отрисовки производит сама Qt. Но не суть важно.
Операционка точно также перехватывает события PAINT и сама определяет момент перерисовки на экран. И делает она это в один момент для всех окон всех приложений.

Есть такие страшные слова:
Потокобезопасность
реентерабельность
Есть достаточно много людей которые с этими понятиями парятся и до конца их не понимают (я один из них).

Дак вот если ещё QWidget'ы сделать со всякой там реентерабельностью, то телефон службы техподдержки трольтеха отключила бы телефонная компания.

В Асистенте сказано:
тыц (http://www.doc.crossplatform.ru/qt/4.4.3/threads.html#qobject-reentrancy)

Ну а где противоречие с тем что я написал выше? Ты говорил что это не проблема библиотек и привел аргументы, я привел тебе примеры.
Не спорю, вполне вожможно что операционка делает перерисовку окон синхронно(синхронизированно) для разных процессов(их главных потоков) и это пример того что это возможно! => ничто не мешает сделать необходимую синхронизацию при отрисовки виджетов на уровне библиотеки!

там же, по ссылке, указаны и причины

Да сделать то все можно, только для чего, в чем будет выигрыш? Если все сведется к одному потоку, который и будет все отрисовывать.
Что даст эта возможность, кроме усложнения (и наверняка) замедлению библиотеки?

Наверное, поэтому это и не было сделано.

Абсолютно не связанные вещи, речь шла о проблемах пререисовки и что якобы это не ограничения библиотеки, с чем я не согласен!
На мой взгляд это именно ограничения библиотеки.

Мы говорили именно о перерисовке.
Выигрыш в том что удобнее использовать, я поскольку перерисовка делается, относительно медленно, то thread-save (через Mutex) не даст замедления.

Давай посмотрим на несколько моментов. Например:
В одном потоке (1) создается окно, в другом потоке (2) создается виджет, который должен располагаться на этом окне. На примере Qt, parent'ом для этого виджета нужно указать окно из потока 1. Поток 2 начинает что-то делать со своим виджетом, в середине работы происходит переключение на поток 1, который решает разрушить окно. Что делать библиотеке? Убить виджет вместе с окном, но тогда при переключении на поток 2 (где идет работа с этим виджетом) все ляжет. Отвязать этот виджет и не трогать, тогда кто будет удалять виджет и что с ним вообще дальше делать?

По поводу реентерабельности, вот почитай:
 Реентерабельность (http://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%B5%D0%BD%D1%82%D0%B5%D1%80%D0%B0%D0%B1%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C)

Короче это thread-save "Реентерабельность" для функций.
Для объекта thread-save:
- Все методы - реентерабельны
- нет непосредственного(не через методы) доступа к данным объекта
Вроде так


Это связано не только с виджетами, но и с кучей других классов. Я и не спорил о том что виджеты нельзя использовать многопоточно и не в главном потоке.
И  это естественно касается не только создания но и любого использования виджетов(вызова их методов) за пределами главного потока.
Но не понятны причины почему это так. Не thread-save предполагает использование объекта только в одном потоке, но это не занчит что в главном! Про поблемы синхронизации перерисовки я уже писал - это проблема библиотеки. неужели проблема только в этом?

====
Дока QT - это нечто! Я не верю что накосячили в переводе. Постоянно встречаю такие приколы!


Это как понимать!

Это проблема неправильного использования, неправильной сихронизации, т.е. проблема программиста.
С таким же успехом можно напортачить с любым объектом совместно используемым в нескольких потоках.

Библиотека здесь ни при чем. Представим себе что сейчас OS заполняет/заливает регион каким-то цветом (шлет 5-10Mb в видео). Понятно что если кто-то встрянет с др. рисованием - регион разрушен, crash. Значит надо как-то "держать и не пущать" остальных рисующих. А каким образом если 2 и более ниткам разрешено захватывать контекст, выкладывать окна и.т.п? Все хорошо если несколько процессов рисуют "одновременно" (якобы). OS все равно делает это последовательно (на слабом железе хорошо видно) - сначала пошлет paint/update одному окну/процессу, потом другому (а между этим проверит др. события). А вот если 2 нитки в 1 процессе прутся - как? Ставить мутекс на каждый чих? Не хуже меня знаете - удовольствие слишком дорогое для операций рисования.

Да так и понимать: они крутят EventLoop для каждой нитки. А обработчик объекта обычно делает "что-то сверху" и отдается на обработчик парента - а событие-то было послано в другом loop. Лучше сначала разобраться а потом горячиться  :)

Вот вы тут спорите про потоки... И ГУЙ в разных потоках... Я вот обдумал все, представил себя пользователем и пришел к выводу что я не могу смотреть в два разных ГУЯ одновременно. Только по очереди. А раз пользователь не может то зачем это реализовывать программисту? Тем более что это сложно реализовать. Ведь любая программа рассчитана на некоего пользователя. И я считаю это весьма логичным, даже не вдаваясь в потокобезопасность и прочее( хоть и имею представление об этом). Так что один пользователь смотрит в один ГУЙ, а что и когда появится в этом ГУЕ это уже дело программиста. И если у последнего возникает надобность в двух ГУЯх одновременно то что-то он напутал в разработке интерфейса.

Вы сначала ознакомились лучше бы ознакомились с сутью вопроса, прежде чем выдавать такие перлы.

Ты хоть сам понял что написал.

Понял, может не верно изложил. Во всей теме спорят про "теорию вопроса". Практического же увидел только "QWebView в цикле", инет браузер и намек на надобность показать окошко по событию из другого потока. Во всех этих задачах я не вижу смысла делать графический интерфейс в нескольких потоках. А зечем спорить почему этого нет и придумывать как это сделать если это не надо?

- Поскольку в OS одновременно работают много процессов, в том числе и имеющих графический интерфейс, то на уровне OS такой проблемы нет. Система сама устанавливает блокировки при обращении к ее определенным ресурсам, в том числе и к графическим контекстам! Так что проблема только на уровне библиотеки.
- По поводу накладности Mutex , для данного случая - абсолютно не согласен. Не тот случай!
  a) Операция прерисовки относительно редкая.
  b) Очень длительная операция по сравнению со временем создания блокировки - отношение много порядков

И к слову. Реализация Mutex в QT сделана не хорошо. Нормальный Mutex предполагает Spin Count(покрутиться заданное колличество раз 1000-100000 на атомарной операции в ожидании разблокировки прежде чем усыпить поток)! Таким образом, QT-й Mutex не позволяет без больших накладных расходов использовать его для межпоточной защиты очень частых, но очень коротких по времени последовательностей операций.
 

Перечитал в оригинале, понял прикол. Речь об отношении включения(родитель-дочерний объект), а не о наследовании. :)

>>а не о наследовании
да, надо будет поправить, "потомка" на "дочерний", а "предка" на "родительский". В новых переводах так и договорились делать. А то двояко звучит

Пример с тем же QWebView, насколько я понял он грузит данные в другом потоке. Но вот отрисовку он делает естественно в главном.
И я заметил(я это протестировал), если ему подать что-то очень тяжелое для отображения, то он замораживает интерфейс на некоторое время. Сам ощутил замараживание секунд на 5! Очень неприятно. А вот если бы можно было рисовать в другом потоке, то этого бы не происходило

>>если бы можно было рисовать в другом потоке, то этого бы не происходило
рисовать можно в другом потоке, рисуй на QImage, а в главном копируй его.

Ты уверен? Вроде painter это не позволяет???

Даже если это так, то ты не заставишь это делать тот-же QWebView!

Не путайте, OS никакой защиты не имеет, попробуйте painter.begin() без painter.end() или создавать QPainter не на стеке - и получите неприятности очень быстро. Для многих процессов OS просто проталкивает их последовательно но это не прокатит с 2 и более нитками 1 процесса.

имхо, это ограничение библиотеки и никакой костыль ненапишешь. Нестоит забывать, что Qt это кросплатформенный фреймворк, и, возможно, не все ОС поддерживают несколько GUI потоков в пределах процесса. Например, винда поддерживает несколько GUI потоков.

По потокам и процессам можно почитать в очень неплохой книге:

Джеффри Рихтер. Создание эффективных WIN32-приложений с учетом специфики 64-разрядной версии Windows

а именно главы 6, 26, 27.

Нитак. thread-save != reentrant

Функции, которые можно одновременно вызывать из разных потоков - tread safe. Если в классе все функции такие, то и класс называется tread safe. reentrant - функции, которые можно безопастно вызывать для одного и того же екземпляра класса только из одного потока - в котором он был создан.

Подробнее читаем в ассистанте - Thread Support in Qt

>>Ты уверен? Вроде painter это не позволяет???
для QImage можно, он специально создан для использования в разных потоках

QImage Class Reference


The Paint System



Иногда полезно заглядывать в ассистант.

Дело в том, что изначально речь шла не столько о ГУЕ, сколько о qwebview в частности. Задача (например в моём случае) состоит в том, чтобы эмитировать работу "нескольких браузеров" одновременно, вот и всё. Выводить на экран ничего не нужно, главное чтобы была прорисовка js, html, css, etc. "за кулисами". Т.е. тут, несмотря на то, что метод загрузки url'a load() асинхронный - этого мало. Будут "переходы" на другие сайты, поиск текста по страницам, все эти методы асинхронными не будут, чтобы делать всё в одном потоке.
Тут уже был дан вариант решения - слать сигнал на главный поток, чтобы он создал экземпляр qwebview и возвращал его назад в поток. Тут у меня один вопрос (наверное, ввиду моей неопытности при работе с сигналами/слотами): как указать слот, чтобы сигнал типа qwebview слался в run() дочернего потока??
Пробовал как вариант:
Тут код очень урезанный, его цель - просто использовать в другом потоке qwebview - пока всё. Если это заработает, другие вещи не проблема.
п.с. сил больше нет бороться с этим qwebview((

Я это уже предлагал, но повторюсь.
А ты не пробовал использовать вместо QWebView объекты классов QWebPage/QWebFrame.
Это не GUI-классы и думаю спокойно смогут работать в других потоках.

Смотри:
int QThread::exec ();

У QWebPage нет метода load()

А у QWebFrame есть.  :)

QWebFrame * QWebPage::currentFrame () const
Предаем его в другой поток
void QWebFrame::load ( const QUrl & url)

Видимо так.

Конкретную задачу решили, а общую - нет.

конкретную это какую?

Так делать нельзя. ВебВью создан в одном потоке, ты вызываешь его метод из другого потока. Шли ему сигнал:

C++ (Qt)
class RunThreads extends QSignalEmitter implements Runnable
{
 //сигнал для метода load(QUrl) -> QWebView
 public Signal1<QUrl> signalOut3 = new Signal1<QUrl>();
...
...
public void run()
 {
  for (int i = 0; i <= _thCount; i ++)
  {
   //при получении ответа от главного потока использовать объект QWebView в методе xxx2() этого класса
   _form.signalOut1.connect(this, "xxx2(QWebView)", ConnectionType.QueuedConnection); 
   //испустить сигнал, чтобы главный поток создал экземпляр QWebView 
   this.signalOut2.emit(1); /** политика сигнала(почему-то) QueuedConnection.
                                         это означает что сигнал будет класться в очередь.
                                         допустим(возможно это qt-jambi specific. т.к. в с++ этого аргумента указывать не нужно), 
                                         сигнал стоит в очереди, и еще не обработан.
                                         но код в цикле его не ждет. и при попытке использовать созданный объект
                                         (который еще не создался), краш.
   */
   /** а вот собственно и испускание сигнала */
   signalOut3.emit(this.url);
  }
 }
 
 public void xxx2(QWebView v)
 {
  this.wv = v;
  /** соединяем только что созданный объект с нашим сигналом */
  signalOut3.connect(this.wv, "load(QUrl)");
 }
 

Т.е. я это реализовал именно так. Один поток! Шлет сигналы на создание вьюшек, в слоте получает указатель на созданный объект. пихает его массив указателей.
Еще поправка. Так как все созданные объекты конектятся к одному сигналу, то при его испускании, они все получают один УРЛ. А этого нам не нужно ;) Чтоб этого избежать, я унаследовался от QWebView, добавил метод load(QWidget*, const QUrl&). В этом методе я проверяю, этому ли объекту предназначается посланный сигнал. Да, это кривой костыль, знаю. Но нужно написать QSignalMapper, только наоборот.
И еще в унаследованный класс добавил метод bool isFree() const. При получении СВОЕГО урл, этот флаг ставится в false. Когда же QWebView, заканчивает загрузку, этот флаг ставиться в true, и цикл, перебирающий объекты, видя что "этот" свободен, испускает сигнал.
Все.

Полез во внутренности QWebView, и заблудился.
Одно что я понял, это то, что QWebView создает отдельный поток. Так как когда я закачиваю файл, прогресс операции обновляется без задержек, и обработчики всяких кнопок работают.

Что к чему. Что-то намудрил.
Я согласен что как я написал нельзя, но это общая схема.
Чуть более подробно.

В главном потоке:
- QWebPage* WebPage = new QWebPage(NULL);
- QWebFrame* WebFrame = WebPage->mainFrame();
- Cоздаем новый поток и передаем ему WebFrame или предаем каким либо образом(можно и через сигнал)  WebFrame в уже существующий поток
Во второстепенном потоке:
- WebFrame::load (const QUrl & url)
- Испускаем сигнал после загрузки
В главном потоке:
WebView->setPage(WebPage)

============
Остальное технические детали, главное чтобы WebFrame::load (const QUrl & url) делался в другом потоке.
============
Но есть проблема!
Может этого и нельзя сделать!  ???

WebPage - обязан создаваться в главном потоке, поскольку его родителем будет QWebView


Родителем WebFrame является WebPage, все нормально.
Предаем его в другой поток, вызываем там WebFrame::load.
И наш WebFrame при загрузке создает у себя дочерние QWebFrame !!! Что недопустимо, они должны быть созданы в главном потоке!

это вопрос?

Жду пояснений.

так я не вас цитировал ;)

Что-то вы намудрили ;)

Ты привел какой-то абсрактный код, неизвестно что делающий. Он не работоспосбен поскольку повыдерганы куски. По нему ничего понять нельзя. Привел примерно такое же объяснение. Вот я и написал  - "Что к чему".
Если уж хочешь рассказать и показать свой вариант, делай это так что бы было понятно не только тебе. :)

Все нормально описал. Если не достаточно букав, вот, посмотрите: http://rghost.ru/655431

Описал нормально для себя! Что ты там описал понимаешь только ты.
Вообще даже не до конца понятно какую ты решал задачу, а без этого невозможно понять как ты ее решал.
Что реализавал, опиши задачу. Мы много чего обсуждали в данной теме.

Видео посмотрел. Чего-то там дергается и прыгает, весело так прыгает; :)

niXman, в run()'e у тебя только испускание сигналов и коннекты, это только частичная многопоточность. А то что на видео - просто демонстрация асинхронной работы load(), не многопоточность это. А ведь работать может понадобиться с каждой загруженной страницей отдельно и методы работы с ними будут разные, 100% не асинхронные грубо говоря.

C++ (Qt)
Видео посмотрел. Чего-то там дергается и прыгает, весело так прыгает

так это и решал. скучно было ;)

всё там прыгает как надо, но это только загрузка, она бесполезна, нужен отдельный поток, чтобы работать с каждой загруженной страницей (считывать правила работы со страницей например из файла, ставить задержки и т.п. и т.д.). Надо всё же попробовать WebPage и QWebFrame, вдруг покатит, завтра попробую, а то выходной всё-таки.

вот если бы я впихнул цикл распределения заданий в основной поток, то да, однопоточность. и ГУИ в этом случае практически не прорисовывается(понятно почему), проверено.

Это все хорошо.
Но я писал:


Никто на это ничего не ответил.
Либо я ошибаюсь, либо загружать в WebFrame можно только в главном потоке!

Это конечно плохо. Но лично я не ответил, т.к. не пробовал, попробую - отпишусь, другого варианта всё равно нет, что касается qt jambi конечно.

Я это только предположил, проверять не буду - лень/надоело, подожду результаты заинтересованных лиц.  :)

думаю это вполне выполнимо. но нужно ковыряться во внутренностях QWebView. чем и занимаюсь.

Кто-нибудь, подскажите, где есть диаграмма наследования Qt ?

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

см. Class Inheritance Hierarchy

Assistant:
Qt Reference Documentation->API Reference->Class Chart

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

А если алгоритм работы с содержимым вьюшек синхронный, значит его в поток. Но вьюшки пихать в тот же поток не за чем!

1. для каждой вьюшки отдельный поток в котором реализован алгоритм.
2. сигналы и слоты этого потока соединяются с этой вьюшкой.
3. так как каждый сценарий выполняется в отдельной потоке, нам нужно декларировать в нем один сигнал, и один слот.
3.1 signalRunScenarie(scenarie);
3.2 slotScenarieFinish(bool);

как-то так ;)

Spectre, pastor
спасибо.

Кстати в моем примере, на одном ядре 2.3 ггц, для 100% загрузки, нужно запустить 370 вьюшек. памяти съедает 690 метров. Что вполне нормально. Так что если распараллелить программу на несколько ядер, то даже гугл позавидует  ;D

Приятно видеть приличный объем :) Но на одном ядре есть подлянка: часто оно "работает" с нитками, все нормально. А когда запускаем там где физически 2 или более процессора - оно валится. Надо как-то отладить, приходится проситься к кому-то на машину - а это никому не приятно и.т.п.  Просто имейте ввиду.

Так это дело техники ;)
Кстати у меня 4 ядра, и ничего, работает ;)

Spectre, pastor, по всем ссылкам что я нашел, есть только чарты версии 4.3 а в ней нет упоминаний про WebKit.

Идеи?

>>Идеи?
просить тролей обновить PDF'ник

Каие же они ленивые эти тролли. :)

Надо посмотреть в Assistant. Есть надежда что там инфа соответствыет версии.

в новых версиях PDF'ника нету, только текстовая диаграмма
http://doc.trolltech.com/4.5/hierarchy.html

Граждане, ну и чем закончился разбор полётов?! QWebFrame->load() в отдельном потоке работает??? Я пробовал создать QWebPage в отдельном потоке, а потом передавать его в QWebVeiw через setPage() - валится. Может лучше как-то копую WebPage передавать в QWebView??? Как создать копию?

Вроде работает.