Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||menu / radio selection ...|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P4||CC:||carsten.driesner, issues, strobbe|
|Target Milestone:||AOO Later|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:||41005|
Description mmeeks 2005-03-30 11:59:58 UTC
So - a number of menu items behave as radio buttons - but this data is missing from the markup we're using to construct the menu items; ie. they are not marked / rendered as a set of radio button item. eg. in calc Format->Alignment - should have two sets of radio options, but doesn't. Similarly View->'Normal' vs. 'Page Break Preview' has no radio distinction.
Comment 1 thorsten.martens 2005-04-06 10:15:38 UTC
Please specify single issues and send them to the appropiate section (eg. word processor, spreadsheet,...)
Comment 2 mmeeks 2005-04-06 10:27:59 UTC
Let me clarify - I'm not certain that it is even possible to mark up those items as members of a radio group - that would be a framework problem. I have a pending question of this type from Carsten ...
Comment 3 mci 2005-04-19 11:21:06 UTC
Hi mmeeks, I would like to treat this as an enhancement and not as a defect since AFAIK this works as designed ... ==> I change the type to ENHANCEMENT reassigned to cj mci -> cj: Hi cj, I think this would be more than just a "nice to have feature"... plese have a look at it, thanks...
Comment 4 matthias.mueller-prove 2005-05-10 14:11:38 UTC
the functionality in general will be implemented for OOo 2.0.1. In task i41005 this will be done for the View Menu. Regarding the Format>Align menu. This case is less severe. Tri-states need to be considered as well. owner: mmp target OfficeLater Prio P4
Comment 5 mmeeks 2005-05-10 15:27:38 UTC
So - IMHO we need this markup available across the board for menu items; I'm particularly interested wrt. accessibility - clearly it's best for an impaired user to be able to know if an item is toggle-able before they go toggling it [ or conversely - they may be more happy to try pressing it - if they think they can undo that easily by pressing it again :-] Also - I'm eager to do better at rendering the GUI in this regard; i#17937# was only 1/2 fixed in this regard, I'd love to be able to make this as crisp & intuitive as the rest of the Gnome menus :-) Thanks.
Comment 6 matthias.mueller-prove 2005-05-10 15:59:08 UTC
Hi Michael, it will be real bullets, like the Window menu offers today. Thanks for pointing out the accessibility issues. Matthias added dependenca to i41005
Comment 7 mmeeks 2005-05-10 18:04:18 UTC
of course, it's not just radio buttons, it's check-boxes too, but you knew that I'm sure :-) [ even though, unfortunately an un-patched OO.o doesn't have the double-case rendering for checkable items because of this chicken/egg problem ]. We have a patch for that in i#48965# for gtk+ at least.
Comment 8 michael.ruess 2008-08-06 08:16:02 UTC
*** Issue 92503 has been marked as a duplicate of this issue. ***
Comment 9 matthias.mueller-prove 2009-09-06 10:56:53 UTC
I am no longer officially active on OOo. Please take over.
Comment 10 Christophe Strobbe 2013-08-15 20:22:17 UTC
There are several examples of menu items that act like radio buttons, e.g.: * Calc: Format > Alignment has two such groups, with a menu separator between them. * Writer: in the context menu of a picture: Anchor. (Note: for the item Alignment and that same context menu, you can't see which alignment is active.) * Writer: in the context menu for text: Font, Size, Alignment, Line spacing. * Impress: View > Color/Grayscale; the group "Normal, Outline, Slide Sorter, Slide Show, Notes Page, Handout Page". There are several examples of menu items that act like check boxes, e.g.: * many items in the View menu (Calc: Formula Bar, Status Bar, Value Highlighting, ...; Writer: Status Bar, Rules, Hidden Paragraphs, ...; Impress: Task pane, ...); the submenu for selecting toolbars, ... * Writer & Calc: Edit > Changes > Record. * Impres: View > Grid. View > Guides. How should this issue be verified? This depends on what kind of issue it is. A. Is it mainly about the usability of the menu items, i.e. visually recognising that some menu items work like radio buttons or checkboxes? B. Is it an accessibility issue, i.e. the accessibility API does not tell assistive technologies that some menu items work like radio buttons or checkboxes? C. Is it an issue in the code that has different consequences than A and/or B? (If yes, what consequences?) If A: Do we need a better visual indication that a menu items is a check box or a radio button. (Currently, this is a process of exclusion: any menu item that has no pictogram to its left and no ellipsis or submenu arrow to its right.) If B: Is this something at the level of the UNO API or at the level of its mapping to ATK/AT-SPI (Linux), the Java Accessibility API (Windows), the Mac OS X accessibility API? If C: ??