Apache OpenOffice (AOO) Bugzilla – Issue 78832
Context menu looks different than in native apps
Last modified: 2008-08-05 12:01:37 UTC
I have taken two screenshots of context menus - one from Ooo and the other from Terminal. There are several differences in them. Compare the border on the right side - there is a black line. Looks like there is some 3d-like border around the OOo context menu... Ismael: are you working on this too? Or is Eric working on context menu?
Created attachment 46208 [details] combined screenshot of OOo and Terminal context menus
pl added 3D effect for contextual menus, and this is maybe not a good idea to have different look. Philipp, what do you think ? BTW : contextual menus are *not* welcome for UI on Mac OS X : - too complicated for the user (lot of user don't think/know how to use them) - useless, because they duplicate the information : nly one place for one feature
We should not draw that additional border, that much is clear. But for context menus "bad" UI: every application has them, they can't be that bad.
In terms of bad UI. Any feature of the software should be accessible without the context menu. Basically some users find it very difficult to use context menus, so you should not force them to use them.
So we should fix those places where a feature is available only via context menu (if there is any), not abandon context menus.
Menus have no more 3D borders but native borders now. There's still a black pixel on two corners (top right and bottom left ones). The font used in OOo context menus is not yet the mac menu font. So letting issue as started.
Is it correct now ?
I notice two problems; first there are one or two black pixels on the lower left of the context menu, then there is a kind of clipping problem when dehighlighting an item (item text looks clipped a line afterwards).
ericb->pl About the clipping : If I have correctly understood, hdu explained me the layouting was done using font metrics, and the font metric depends on the resolution. Maybe I was wrong, but I thought to a (sort of) race between bitmap, font and control metrics. What about use the max of height of them to define the control height ? And yes, they are probably two issues in one.
removing me from the issue (I receive it twice)
the clipping issue is resolved in CWS aquavcl04
pl: confirmed. So remaining issues: - black pixel(s) on the bottom-left - black pixel(s) on the top-right - the last item in the context menu is not high enough OR there is no space below it (compare with the space above the first item)
- the triangle displayed on menu items with submenu is not the same is in other native apps
Small hint: - the highlight on selected item is not aligned with the border of the context menu Maybe this is the reason for the black pixels in bottom-left.
pl->fne: you're working on native context menus, that should fix this.
implemented in aquavcl07
please verify in CWS aquavcl07
Verified in CWS aquavcl07
fixed in master closing issue