In 10.5, context menus have rounded corners. We should have the same.
I don't want to "fake" that stuff with translucent windows. The rounded corners should be a window API option in 10.5, a switch we can flip. If that isn't the case we need to file an urgent bug with Apple to fix that. Removing the dependency until we're sure these two are tied together.
No longer depends on: 307204
filed a request for rounded corners on NSWindow as rdar://problem/5430472
Got a response from Apple in the bug: We need to set the window to transparent, and then use HITHemeDrawMenuBackround to draw the background, with kThemeMenuTypePopUp as the menuType param for the MenuDrawInfo. Should be a piece of cake.
Adding CGContextClearRect() (which is what Apple suggested we use) in NS_THEME_MENUPOP and NS_THEME_MENUITEM seemed to do *something* on my 10.4 machine (added additional transparency). Tried it earlier today while sheriffing.
With the window set to .95 opacity following the steps in comments 4 and 5 leads to this (screenshot).
josh do you want to take back this bug, per our discussion a few days ago?
With all the work we've done to on controls it would be a shame if this bug got lost in the shuffle. Nominating for blocking so we don't forget about it (p5 would be an appropriate priority, imo)
I assume this will also take care of the blurring that appears to go on behind menus on leopard? how about the fading out of menus as they close?
(In reply to comment #10) > I assume this will also take care of the blurring that appears to go on behind > menus on leopard? how about the fading out of menus as they close? Probably to the first, no to the second.
Filed bug 406997 for the second.
This is a purely aesthetic issue and not a regression. blocking1.9-
Priority: P5 → --
Any update on the status of the radar bug? I tried the steps in comment #4 and comment #5 on 10.5.2, but no rounded corners :-/
I can't imagine blocking on this but we want it for sure.
Assignee: joshmoz → mstange
I'll work on this when bug 418454 lands (it changes some stuff about frame transparency).
Status: NEW → ASSIGNED
This patch is on top of those in bug 450939 and bug 450944. I haven't tested in on 10.4 yet, it might mess things up.
The patch works on 10.4, too. Even there, HIThemeDrawMenuBackground draws outside the frame (i.e. the drawn rect extends 4px above and below the requested rect).
Do we really want it on 10.4?
The patch doesn't result in rounded corners on 10.4, HIThemeDrawMenuBackground does its job quite well. :-) In comment 19 I meant to say that it doesn't break 10.4, i.e. it doesn't change the context menu's size there, although we make the drawRect smaller.
(In reply to comment #10) > I assume this will also take care of the blurring that appears to go on behind > menus on leopard? It won't. And there's no way of doing that without using private, undocumented methods. :-(
Comment on attachment 343058 [details] [diff] [review] patch v1 + if (aTransparencyMode) + *aTransparencyMode = theme->GetWidgetTransparency(aDisp->mAppearance); braces arond this non-control-flow statement
Attachment #343058 - Flags: superreview?(roc) → superreview+
Comment on attachment 343058 [details] [diff] [review] patch v1 This patch isn't ready. :( I just tested it again and noticed that it eats the shadow of XUL popup menus...
(In reply to comment #22) > (In reply to comment #10) > > I assume this will also take care of the blurring that appeas to go on behind > > menus on leopard? > > It won't. And there's no way of doing that without using private, undocumented > methods. :-( If aero glass was possible, maybe this is possible too ? As i look at latest iTerm.app code (with has abbility to set blur for transparent background) in cocoa you need only set prepared window filter with blur radious.
Attachment #343058 - Attachment is obsolete: false
For some reason, mIsTransparent isn't set correctly on the view. I need to find out why that's the case, but for now this patch works.
(In reply to comment #26) iTerm.app uses CGSAddWindowFilter; that's the private function I was referring to.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Attachment #349939 - Flags: approval1.9.1+
pushed to mozilla-1.9.1: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/55582aea3232
Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090129 Shiretoko/3.1b3pre Ubiquity/0.1.5 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090129 Minefield/3.2a1pre 10.4 builds still show square corners as expected.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090218 Minefield/3.2a1pre My PPC machines have square corners under Leopard.
Whiteboard: [radar:5430472] → [radar:5430472][polish-hard][polish-visual]
This bug's priority relative to the set of other polish bugs is: P2 - Polish issue that is in a secondary interface, occasionally encountered, and is easily identifiable. Context menus are a secondary interface, however this issue was widely reported on OS X as a polish problem.
Whiteboard: [radar:5430472][polish-hard][polish-visual] → [radar:5430472][polish-hard][polish-visual][polish-p2]
You need to log in before you can comment on or make changes to this bug.