Created attachment 50133 [details] Screenshot Version: unspecified (using KDE 4.4.2) OS: Linux In the menu editor, the '+' icon is not responsive on the dropdown entry. Technically speaking, it seems that QDesignerMenu::handleEvent() (qt:/tools/designer/src/lib/shared/qdesigner_menu.cpp) no longer receives mouse press events. I suppose this is caused by some event filter in the Oxygen style. To verify: Run designer with -style plastique and repeat. Reported to Nokia as http://bugreports.qt.nokia.com/browse/QTBUG-12589. Reproducible: Didn't try Steps to Reproduce: Run Qt Designer Create MainWindow form Add 'File' menu bar entry Add 'Recent' menu entry in dropdown Try to add submenu by clicking on '+' on the right Actual Results: No reaction Expected Results: Submenu opens Dragging menu items does not work either.
Seen in Designer 4.6/4.7
Created attachment 50513 [details] Qt designer + oxygen + submenu selection mmm. I cannot reproduce, using Qt 4.7.0, Kde 4.5.0, and oxygen from trunk, as illustrated on the screenshot. Clicking on the '+' icon on the left of the menu opens a submenu in which I can add elements. I also tried with oxygen from 4.5.0 branch with same result. I also tried with plastique and could see no difference in behavior. Am I missing something ? Christian ? Can you try reproduce the bug on your side ? Hugo
Ok: I see the bug was marked with kde4.4.2 So I got the oxygen sources from 4.4 branch, compiled and installed and ... could finally reproduce the issue. Somehow, the bug was fixed (by chance) in more recent versions of kde. Now, there have been (_many_) changes to oxygen from 4.4 to 4.5 which makes it hard to track what causes the difference. Friedemann, any chance you update to kde 4.5 :) ? In fact, I'll close the bug as fixed, because backporting to 4.4 would be useless, since there will be no other kde4.4 release.
Ok, so, the bug will eventually go away - thanks for looking!
Hope so. At least that's what I see here. Sorry for the trouble. Feel free to re-open if you do still see the bug after upgrading to KDE4.5
I can confirm the bug in todays trunk, using Qt from 4.7 branch.
@comment #6 So ... re-opening . However, really strange ... I can't. Are we talking about the same thing ? Namely: Clicking on the small icon with a + on it should open a submenu, with some 'type here' and some 'add separator' text in it ? And that does not work for you (namely, nothing happens when you press the icon) ? And with using oxygen ? From trunk ? Or am I missing something ? (btw: which font and font size are you using. Maybe it affects the hit-rects). If I am not missing anything, then I guess I'll try look in more details at which functions are called when clicking the icon (which again _does_ work for me, with trunk and QT4.7.0), and how it can possibly go wrong, but can't guaranty anything (since its always hard to fix a bug that you can't see).
allright. I (finally) can reproduce in trunk. You need the "fade" animation enabled for the Menus (I have 'follow mouse', for which the bug is not here). That also explains why it was visible in kde4.4 (for which follow-mouse was not present). I actually think I know where the problem comes from. Working on fixing it. With oxygen 4.4 you can work around this (temporarily) by disabling animations. In oxygen 4.5 by disabling the Menu animation, (using oxygen-settings) or using the 'follow-mouse' mode. More soon
SVN commit 1164520 by hpereiradacosta: Do not block other event filters when processing mouseButtonPress events. BUG: 247664 M +1 -2 oxygenmenubardata.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1164520
SVN commit 1164521 by hpereiradacosta: Backport r1164520 Do not block other event filters when processing mouseButtonPress events. CCBUG: 247664 M +1 -2 oxygenmenubardata.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1164521
From briefly looking at the code, I saw that there is a list of "blacklisted" applications. If I understand it correctly, it prevents special handling. Maybe you could just add "Designer" there? - given that it does a bit of, urm, special handling itself, it is more likely to break.
> --- Comment #11 from Friedemann Kleint <Friedemann Kleint nokia com> > 2010-08-17 08:20:36 --- From briefly looking at the code, I saw that there > is a list of "blacklisted" applications. If I understand it correctly, it > prevents special handling. Maybe you could just add "Designer" there? - > given that it does a bit of, urm, special handling itself, it is more > likely to break. No no. Blacklisting is for window grabbing, and as far as I know there is no issue with window grabbing (from empty areas) and designer. In general I'd rather get the blacklist as small as possible (if possible empty) and fix the reasons why apps have to be blacklisted rather than keep them here. Besides, the real issue for this bug was with widget animations, which is not covered by the blacklist.