GNOME Bugzilla – Bug 104621
AtkHypertext needs link-selected signals
Last modified: 2004-12-22 21:47:04 UTC
AtkHypertext needs to emit signals indicating which link in a hypertext object is currently selected (or "focussed"). Focus technically stays on the AtkHypertext object, but clients need to know which link is currently selected both to track the user's onscreen logical position in a hypertext object, but also to know which link is currently selected and thus would be activated by various keybindings. There may also need to be a queryable property for selected-link, or a similar means of determining if a Hyperlink object is currently selected.
Created attachment 13906 [details] [review] Proposed patch
Patch looks good Padraig, thanks! How should we handle the case where a new Hypertext object is created with a 'selected' link? Do we assume there's no link selected initially , and emit the signal on AtkHyperlink creation if, in fact, a link is initially selected?
The interface does not mandate what should happen. My initial thoughts are that a signal would not be emitted. We do not emit a signal to indcate that an AtkObject has focus or is selected when it is created.
sounds reasonable... the case I had in mind was one where a big AtkHypertext object gets created with lots of links, one of which is selected initially. Without the generation of a signal in this case, would a listening client would have to call atk_hyperlink_is_selected() or whatever on every child in order to determine that state? Or would it just get the 'selected-link' property ? (I guess the latter, via standard GObject API).
atk_hypelink_is_selected_link() is just a convenience function for the property selected-link. Do you think that we need a function atk_hypertext_get_selected_link()?
Patch committed to CVS HEAD.
*** Bug 147116 has been marked as a duplicate of this bug. ***