Issue 46284 - menu / radio selection ...
Summary: menu / radio selection ...
Status: CONFIRMED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: 680m79
Hardware: All All
: P4 Trivial (vote)
Target Milestone: AOO Later
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: usability
: 92503 (view as issue list)
Depends on: 41005
Blocks: 17937
  Show dependency tree
 
Reported: 2005-03-30 11:59 UTC by mmeeks
Modified: 2013-08-15 20:22 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
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: ??