Qt ненависти псто (3)

А вот, значит, еще про Qt.

Допустим, у нас есть QListView (с кастомными элементами, но это в данном случае несущественно). В нем мелко показаны фигульки.

Хотим: при клике на фигульку спрятать QListView и на его месте показать фигульку крупно (в QGraphicsView, хотя это тоже не так и важно).

Первые грабли зарыты в "спрятать-показать". Если запихнуть их, скажем, в один QLayout и делать  QListView->hide(); QGraphicsView->show(), то оно может валится. Не всегда. При некоторых размерах окна. Ну ладно, сначала show/hide, а потом открыл себе QStackedWidget, стало счастье. Но это - мелкая проблема.

Крупная (по времени) проблема оказалась вот в каком неожиданном месте. Вот у QListView есть signal: activated(), который присылается аккурат по дабл-клику (или Enter). Но. Следите за руками:

  1. Шлется он из MouseDoubleClickEvent(), что разумно, да? Но в этом эвенте внутри QAbstractItemView() запоминается элемент, на который кликнули.
  2. А дальше есть MouseReleaseEvent(), в котором проверяется, а на том же самом элементе отпустили.
  3. Но мы то по activated() позвали hide().
  4. И нет, не на том же. Виджет спрятан, естественно indexAt() ничего хорошего не вернет.
  5. После чего QListView входит в странный режим расширения selection (даже если selectionMode: NoSelection).
  6. На Windows это ни в чем не выражается, все работает.
  7. А на Маке - после возвращения QListView обратно - оно начинает менять активный (currentIndex) элемент не по одиночному (или двойному) клику, а просто по mouseOver. До следующего клика в виджет. Я уже, от отчаяния, хотел эмулировать таковой клик.

В сочетании с тем, что последние дни выспаться не удавалось - поиск проблемы занял ТРИ ДОЛБАНЫХ ДНЯ. Включая чтение всего QListView и QAbstractItemView.  То есть это я ее сейчас понял. Еще в обед сегодня не понимал.

Решение, понятно, оказалось тривиальным (работает, естественно):

  • завести свой сигнал на активацию (двойной клик)
  • И слать его из mouseReleaseEvent, проверив, естественно
    • Что отпускают тот же элемент, что кликнули
    • Что количество посадок равно числу взлетов. То есть Click/Release

Возможно, спас бы отложенный сигнал, или по таймеру. Но по таймеру оно явно стало бы вероятностным - отпустил юзер кнопку после второго клика, не отпустил....

Ну и хочу сказать, что Qt неисчерпаем как атом. Удивительно, что программы на нем, в среднем, таки работают.

Comments

Чего только люди не придумают, лишь бы GTK не использовать.

Я погуглил GTK OpenGL integration и понял, что я бы гарантированно потерял бы сильно больше времени на это место, тут бы не днями измерялось, а месяцами.

Не говоря о
"the OpenGL support inside GTK+ requires core GL profiles"

GTK уже научился выглядеть на винде не как говно, а как нативное приложение? Что-то когда я последний раз смотрел на что-то GTK'шное на винде, у меня кровавые слёзы текли.
QT тоже не идеален, но слёзы хотя бы обычные, не кровавые.

Даже если и научился, то опять же гугление gtk HiDPI Windows дает нам понять, что до этого места они еще не дошли.

Вот, например: http://forum.gtkd.org/groups/GtkD/post/330

Не ну есть еще wxWidgets если вот так хочется кроссплатвоменности и не QT, но там тоже не все хорошо.

Мне не хочется "не Qt"
Qt создает проблемы, конечно, но решает - больше.

OpenGL вот к примеру: такое количество особенностей от меня спрятано, что просто счастье же.

Да это понятно - я тоже QT использую в своих проэктах...

Пробовали жаловаться на это разработчикам?

Ну оно там явно purposely сделано так.
То есть или вообще всю логику itemviews переделывать, или не спасешься.

Т.е. это не минорный баг, а вот прямо концептуальный. На такие жаловаться в известной степени бессмысленно.

Add new comment