Спасибо, это я и хотел услышать.

Нужный параметр - это, по большому счёту, ширина отрисовываемой области. (Возможно, в будущем понадобится и высота.)
Я ещё немного поэкспериментировал - в принципе, childrenRect() у QGraphicsView возвращает ту же самую ширину, что и viewport() у QPainter.

Наверное, я перекрою QGraphicsView::resizeEvent() и буду делать setPos дочерним элементам в нём. (Ну а для драг-н-дропа вызову обновление отдельно.) Это будет корректно?

Просто в примерах я действительно не видел, чтобы setPos вызывался напрямую в paint().
Если же это в принципе не криминал - разумеется, придётся сделать "программу из трёх строк", повторяющую эффект.

Добрый день.
Допустимо ли вызывать метод QGraphicsItem::setPos из метода paint() наследников этого самого QGraphicsItem? Мне перед отображением элемента надо рассчитать, где он будет выводиться, исходя из масштаба физических величин к ширине отображаемой области. А ширину эту, как я понимаю, я могу взять только из painter-а.

В предыдущей версии своего кода я совсем не пользовался setPos, отрисовывал все элементы в координатах сцены, размеры сцены брал из QPainter::viewport(), и всё, в общем-то, замечательно отрисовывалось. Но теперь мне понадобилось к некоторым элементам добавить перетаскивание, причём перетаскивание не совсем автоматическое - оно разрешено только по одной координате, и при этом надо ещё пересчитывать физическую величину. Первое, что пришлось сделать - это отказаться от координат сцены, иначе проблемы будут уже в boundingRect(). Теперь отрисовку я делаю в координатах самого элемента, а в начале paint() вызываю setPos, рассчитанный исходя из размера отображаемой области. В общем-то, отображение самого элемента работает. Но возникают странные артефакты, например, в процессе расширения окна другие элементы (другого класса, на который действие моего setPos не распространяется) могут исчезать и появляться обратно.

Проблема повторена на Qt 4.6 и 4.8.4, причём мне показалось, что на 4.8.4 глюки были реже, но совсем не исчезли.

Компактный кусок кода, который исчерпывающе иллюстрировал бы проблему, я постараюсь собрать, но сделать это будет нелегко: как-то слишком всё у меня пока размазано. Но может, он и не нужен? Если я действительно пытаюсь сделать то, чего в Qt в принципе делать нельзя - буду искать другие пути. Поэтому буду благодарен, если для начала кто-либо знающий ответит на "теоретический" вопрос, сформулированный в названии темы...

Добавил второй вариант в .pro-файл. Спасибо, помогло!

Мне кажется, способ достоин помещения в FAQ!

Есть ещё вариант. Поскольку перекачка данных - операция разовая, можно не геморроиться с драйверами, а сделать структурированный дамп в текстовые файлы, а потом уже его в постгресную базу и грузить.
Правда, по производительности этот вариант уступает: полученные файлы могут разрастись до сотен мегабайт, а то и больше. Соответственно, и работать выгрузка/загрузка будет дольше. Зато полная прозрачность.

linguist - это гуёвая программа для _редактирования_ .ts. А у меня задача в данном случае - тупо собрать проект с минимум телодвижений, допустим, из tar.bz2 с исходниками или из svn/hg/git. В общем случае править перевод может один человек, а собирать понадобится другому.
Помещать файлы .qm в tar.bz2 и уж тем более коммитить их в svn/hg/git я, естественно, не хочу. Ибо это вторичный продукт по отношению к .ts, да ещё и двоичный. Со всеми вытекающими. Стало быть, надо собирать. Мне показалось, что было бы естественно возложить это на make. Ибо какая разница, что ей вызывать - gcc, uic или lrelrase. Но похоже, что у qmake, которая делает Makefile, на этот счёт другое мнение.

P.S. Сейчас ещё раз погуглил - похоже, стандартно проблема не решается, надо добавлять свой скрипт. Авторы кутима так и сделали:
http://wiki.qutim.org/ru/how_to_translate
Хнык-хнык.

Здравствуйте.
Попрактиковался я в русификации с помощью linguist. Штука хорошая и надёжная.
Только вот что смущает. Если я собираю проект из исходников (qmake / make), всё равно для каждого .ts приходится вручную вызывать lrelease, чтоб получить из него .qm. Программа make этот процесс не автоматизирует. Думал, это у меня проект кривой - при сборке стандартных примеров из Qt та же самая ситуация.
Так и должно быть? Если да - непонятно, зачем вообще в файле проекта секция TRANSLATIONS. Да и вообще обидно как-то.
Если нет - где могла собака порыться?
Поиском на форуме нашёл обсуждение аналогичной проблемы для cmake, но я ей не пользуюсь, полагаюсь на стандартные для Qt средства. До последнего момента мне их хватало.

Сдаётся мне, что здесь проще текстовым редактором выкопировать необходимые теги. Это ж обычный XML.
Другой вопрос - "зачем".