Bug 247664 - Cannot add submenu in Qt Designer Menu Editor when run in Oxygen style
Summary: Cannot add submenu in Qt Designer Menu Editor when run in Oxygen style
Status: RESOLVED FIXED
Alias: None
Product: Oxygen
Classification: Plasma
Component: style (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Hugo Pereira Da Costa
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-13 16:42 UTC by Friedemann Kleint
Modified: 2010-08-17 14:30 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot (5.04 KB, image/png)
2010-08-13 16:42 UTC, Friedemann Kleint
Details
Qt designer + oxygen + submenu selection (315.02 KB, image/png)
2010-08-14 03:57 UTC, Hugo Pereira Da Costa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Friedemann Kleint 2010-08-13 16:42:22 UTC
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.
Comment 1 Friedemann Kleint 2010-08-13 16:46:11 UTC
Seen in Designer 4.6/4.7
Comment 2 Hugo Pereira Da Costa 2010-08-14 03:57:59 UTC
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
Comment 3 Hugo Pereira Da Costa 2010-08-14 04:08:58 UTC
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.
Comment 4 Friedemann Kleint 2010-08-16 08:50:20 UTC
Ok, so, the bug will eventually go away - thanks for looking!
Comment 5 Hugo Pereira Da Costa 2010-08-16 14:31:55 UTC
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
Comment 6 Christoph Feck 2010-08-17 00:40:22 UTC
I can confirm the bug in todays trunk, using Qt from 4.7 branch.
Comment 7 Hugo Pereira Da Costa 2010-08-17 03:07:51 UTC
@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).
Comment 8 Hugo Pereira Da Costa 2010-08-17 03:56:50 UTC
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
Comment 9 Hugo Pereira Da Costa 2010-08-17 04:09:03 UTC
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
Comment 10 Hugo Pereira Da Costa 2010-08-17 04:10:53 UTC
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
Comment 11 Friedemann Kleint 2010-08-17 08:20:36 UTC
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 12 Hugo Pereira Da Costa 2010-08-17 14:30:39 UTC
> --- 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.