GoldenDict Forum

Тут буду задавать вопросы по коду, когда мне что-то совсем не понятно.

Вот первый:

В editdictionaries.hh oпределен метод void on_tabs_currentChanged( int index ). Очевидно, его кто-то где-то дергает. Но я хоть убей не могу понять - кто и где! В коде, судя по git grep'у, никто этим не занимается. Мистика!

ikm wrote:http://doc.qt.nokia.com/latest/designer-using-a-ui-file.html#widgets-and-dialogs-with-auto-connect

Ух ты, magic! Пойду все же дочитаю сначала книжку про Qt GUI, чтобы не задавать больше глупых вопросов!

Есть предложение завернуть отладочный вывод в коде, который сейчас реализован через printf и fprintf( stderr,...), в макросы. Чтобы можно было его легко включить/выключить при компиляции, а в перспективе и в файл перенаправить, если потребуется. А то под Widows без консоли в текущем виде он всё равно бесполезен и излишен.

Собственно, для себя я это уже сделал. Стоит это кинуть на GitHub?

Согласен. Но прошу оформить в виде pull-реквеста, чтобы обсудить детали.

Сделал. Собственно макросы запихнул в dprintf.hh. И добавил в goldendict.pro define для отключения отладочного вывода для Win-релиза.

Решил добавить отмену запросов в ArticleRequest::cancel() - сразу посыпались вылеты. Покопавшись поглубже, с некоторым удивлением обнаружил, что сигналы finished() от работающих по идее в отдельных потоках xxxRunnable дёргают соответствующие слоты в ArticleRequest прямо в процессе выполнения ArticleRequest::cancel(), если им прямо не задать тип соединения Qt::QueuedConnection. Так и должно быть, или я что-то не понимаю в логике работы?

Тип соединения сигнал-слотов по умолчанию - Qt::AutoConnection. В этом режиме сигнал вызывается напрямую из текущего потока, если это тот же поток, в котором было создано соединение - если же он вызывается из другого треда, он встает в очередь. Это решение принимается в момент вызова сигнала. Скорее всего, в данном случае finished() вызываются сразу из cancel() соответствующих объектов, что и приводит к из непосредственному вызову прямо из ArticleRequest::cancel().

Нет, из cancel() объектов не вызывается ничего. Там лишь выставляется флаг сброса - isCancelled.ref(). И всё, сразу возврат. А этот флаг проверяется в run(), которая вызвана из xxxRunnable.run(), то бишь работает в другом потоке. И обнаружив уже в своём потоке такой флаг, run() прерывает обработку и зовёт finish(), которая и дёргает finished(). Потому я и говорю, что был удивлён таким поведением - по уму вызов из другого потока должен был сам встать в очередь, без прямого на то указания.

Upd.
Хотя сейчас я ещё раз посмотрел - mediawiki (да и programs) действительно вызывает finish() из cancel(). Так что это оттуда мог прийти такой неприятный сюрприз.

ikm
Среди исходников лежат два файла, не включённые в проект - xdxf.hh и xdxf.cc. Получается, что поддержка формата xdxf поначалу была задумана, но потом не доведена до ума и отключена. Это принципиальное решение или просто руки не дошли?