Ну, это смотря какая задумка у UI. Вообще немного замучался с GraphicsView.

Давайте представим задачу - колебания суточной температуры.
view это все показывает, пользователь не взаимодейтвует с GraphicsView напрямую (только в данном примере).

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

Конечно, вы можете сказать, что я переборщил с GraphicsView и рисуй ручками давай в painter. В данном случае это не проблема, но при добавлении интерактивности будут сложности.

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

Пошел извратом

i.e., a rectangle that grows when items are added to or moved in the scene, but never shrinks.
setSceneRect( QRectF() ); не поможет. Пробовал.

QEventLoop ожидает сигнал, но при этом все события обрабатываются.

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

QGraphicsScene::sceneRect растет при добавлении итемов, что логично. Но когда очищаем сцену (clear), она не думает уменьшать размер.
Возможно ли обнулить сцену, как будто её только-что создали?

Возможно, есть другие решение этой проблемы? itemsBoundingRect()?

Солгаситесь, странное поведение класса (объекта), если мы не можем вернуть его в первоночальное состояние.

Обалдеть. Спасибо за решение. Добавлю в коллекцию патернов.

Но особое спасибо за атач, это стОит гораздо большего (ваше время), чем даже само решение.

QueuedConnection не помогает, сигнал успевает проскочить до сигнала кнопки

У вас есть хоть один пример, где этот функционал отсутствует?

Я же не добавляю новую кнопку, не махаю флагом перед пользователем, даже не спрашиваю пользователя, хочет ли он выйти из программы (просто из нее нельзя выйти:)). Наоборот, делаю интерфейс найболее ненавязчивый. Скажем так, если всплывает меню - уже все привыкли, что оно само пропадет. Если окно, то нет. Но для контекстного меню то и кнопка не нужна, поэтому проблема отсутствует. Но, даже если забить на юзабилити, все равно что то нужно делать с поведением. Кнопка есть и её не может не быть. Если не заморачиватся с интерфейсом, то конечно, проще сделать его модальным (окно) с кнопочкой закрытия. Но мы не ищем лёгких путей.......Пример программы The BAT. Пруд пруди почтовых клиентов, однако популярность бата, по моему мнению, обусловленно именно юзабилити. И функционал здесь нипричем


Итак, сделал вариант с disable + Qt::QueuedConnection.Работает. Скажем так, в принципе пойдёт. Не совсем так уж чтобы красиво. Ну представте, вы нажимаете меню File, вываливается само меню, а File стал заблокированым...... Спасибо (это не сарказм).

Хех. Не. Не работает. Подсознание не позволяло нажать на кнопочку disabled чтобы протестировать. Если я нажимаю на нее (disabled), окно пропадает, она становится enable и срабатывает событие, окно опять появляется

Попробую. Потом отпишусь


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

Это и есть QToolButton с фейковым (пустым) меню - для того, чтобы стрелочку рисовало на кнопочке - мол появится что-то.
И второе: в меню весь функционал который мне нужен не влезет.
Можно также сравнить с ComboBox. Но отличие этих всех контролов от того, что мне нужно - их меню или списки встроены в тип. QToolButton знает о меню. Моя же кнопочка ничего ни о ком не знает и знать НЕ СОБИРАЕТСЯ.

Да, цирк в том, что нажатие на кнопку реально не происходит, но пользователь то об этом не знает.

Ну действительно, пользователь, который будет работать с тулузой, со временем перестанет обращать внимание на кнопочки, т.к. будет знать, что окно пропадет само  и не стоит тратить на него энергию.
Но разницу между вашим вариантом и своим я не вижу. Если кнопка станет disable, то сделать его enable должно само окно и мы приходим к тому же самому.
Ну и конечно же, это введет в ступор пользователя - как закрыть окно? (на секунду конечно, он автоматом начнет на все поряд тыкать)


Но это ничего не гарантирует


Не совсем понял. Условно (считайте), что я пишу Qt Creator - это инструмент, у которого все под рукой, и который не должен отвлекать. Окна, которые закрываются при потере фокуса - самое то, чтобы не отвлекать. И да, хоть он вместо окон использует меню, смысл тот же самый. Да, можно было бы использовать только онКлик..... Но как то некрасиво для самого себя. Не видел я такого поведения. Тем более, можно ж умом тронуться для неокрепших пользователей. Он тыкает, чтобы закрыть, на кнопку, а окно пропадает и сразу появляется.

Так и сделано. Но дело в том, что state изменит окно, когда закроется и кнопочка выпрямится. Т.е. событие закрытия окна (которое изменяет состояние кнопки) происходит раньше, чем клик на кнопку. Таким образом мы опять вызовем окно.

Есть всплывающее окно  - setWindowFlags(Qt::Popup) (окно скрывается, когда теряет фокус  - другими словами кляцнули на другом месте, оно скрылось).
Есть кнопочка, которая вызывает это окно. При активном окне кнопочка утоплена. Окно закрылось, кнопочка обратно выпрямилась.

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

Решено так:

Т.е. блокируем кнопку на пару милисекунд.
Может есть более нормальное решение?