Summary: | Cannot add submenu in Qt Designer Menu Editor when run in Oxygen style | ||
---|---|---|---|
Product: | [Plasma] Oxygen | Reporter: | Friedemann Kleint <Friedemann.Kleint> |
Component: | style | Assignee: | Hugo Pereira Da Costa <hugo.pereira.da.costa> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | cfeck, hugo.pereira.da.costa, rdieter |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
Screenshot
Qt designer + oxygen + submenu selection |
Description
Friedemann Kleint
2010-08-13 16:42:22 UTC
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.
|