Qt ненависти псто (3)
А вот, значит, еще про Qt.
Допустим, у нас есть QListView (с кастомными элементами, но это в данном случае несущественно). В нем мелко показаны фигульки.
Хотим: при клике на фигульку спрятать QListView и на его месте показать фигульку крупно (в QGraphicsView, хотя это тоже не так и важно).
Первые грабли зарыты в "спрятать-показать". Если запихнуть их, скажем, в один QLayout и делать QListView->hide(); QGraphicsView->show(), то оно может валится. Не всегда. При некоторых размерах окна. Ну ладно, сначала show/hide, а потом открыл себе QStackedWidget, стало счастье. Но это - мелкая проблема.
Крупная (по времени) проблема оказалась вот в каком неожиданном месте. Вот у QListView есть signal: activated(), который присылается аккурат по дабл-клику (или Enter). Но. Следите за руками:
- Шлется он из MouseDoubleClickEvent(), что разумно, да? Но в этом эвенте внутри QAbstractItemView() запоминается элемент, на который кликнули.
- А дальше есть MouseReleaseEvent(), в котором проверяется, а на том же самом элементе отпустили.
- Но мы то по activated() позвали hide().
- И нет, не на том же. Виджет спрятан, естественно indexAt() ничего хорошего не вернет.
- После чего QListView входит в странный режим расширения selection (даже если selectionMode: NoSelection).
- На Windows это ни в чем не выражается, все работает.
- А на Маке - после возвращения QListView обратно - оно начинает менять активный (currentIndex) элемент не по одиночному (или двойному) клику, а просто по mouseOver. До следующего клика в виджет. Я уже, от отчаяния, хотел эмулировать таковой клик.
В сочетании с тем, что последние дни выспаться не удавалось - поиск проблемы занял ТРИ ДОЛБАНЫХ ДНЯ. Включая чтение всего QListView и QAbstractItemView. То есть это я ее сейчас понял. Еще в обед сегодня не понимал.
Решение, понятно, оказалось тривиальным (работает, естественно):
- завести свой сигнал на активацию (двойной клик)
- И слать его из mouseReleaseEvent, проверив, естественно
- Что отпускают тот же элемент, что кликнули
- Что количество посадок равно числу взлетов. То есть Click/Release
Возможно, спас бы отложенный сигнал, или по таймеру. Но по таймеру оно явно стало бы вероятностным - отпустил юзер кнопку после второго клика, не отпустил....
Ну и хочу сказать, что Qt неисчерпаем как атом. Удивительно, что программы на нем, в среднем, таки работают.
Comments
Чего только люди не придумают
Чего только люди не придумают, лишь бы GTK не использовать.
Я погуглил GTK OpenGL
Я погуглил GTK OpenGL integration и понял, что я бы гарантированно потерял бы сильно больше времени на это место, тут бы не днями измерялось, а месяцами.
Не говоря о
"the OpenGL support inside GTK+ requires core GL profiles"
GTK уже научился выглядеть на
GTK уже научился выглядеть на винде не как говно, а как нативное приложение? Что-то когда я последний раз смотрел на что-то GTK'шное на винде, у меня кровавые слёзы текли.
QT тоже не идеален, но слёзы хотя бы обычные, не кровавые.
Даже если и научился, то
Даже если и научился, то опять же гугление gtk HiDPI Windows дает нам понять, что до этого места они еще не дошли.
Вот, например: http://forum.gtkd.org/groups/GtkD/post/330
Не ну есть еще wxWidgets если
Не ну есть еще wxWidgets если вот так хочется кроссплатвоменности и не QT, но там тоже не все хорошо.
Мне не хочется "не Qt"
Мне не хочется "не Qt"
Qt создает проблемы, конечно, но решает - больше.
OpenGL вот к примеру: такое количество особенностей от меня спрятано, что просто счастье же.
Да это понятно - я тоже QT
Да это понятно - я тоже QT использую в своих проэктах...
Пробовали жаловаться на это
Пробовали жаловаться на это разработчикам?
Ну оно там явно purposely
Ну оно там явно purposely сделано так.
То есть или вообще всю логику itemviews переделывать, или не спасешься.
Т.е. это не минорный баг, а вот прямо концептуальный. На такие жаловаться в известной степени бессмысленно.