After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 344284 - Need Hyperlink interface e.g. AtkHyperlinkImplementor
Need Hyperlink interface e.g. AtkHyperlinkImplementor
Status: RESOLVED FIXED
Product: atk
Classification: Platform
Component: atk
git master
Other All
: Normal enhancement
: ---
Assigned To: bill.haneman
bill.haneman
Depends on:
Blocks:
 
 
Reported: 2006-06-08 13:45 UTC by Aaron Leventhal
Modified: 2006-07-20 22:16 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
patch to add this interface, needed by mozilla/firefox (4.02 KB, patch)
2006-06-29 17:18 UTC, bill.haneman
committed Details | Review

Description Aaron Leventhal 2006-06-08 13:45:02 UTC
The plan for Mozilla is to make Hyperlinks full-fledged ATK Objects. (Hyperlinks are not necessarily just for links, but for other objects embedded in text as well).

It is possible to get to the Hyperlink by going through the parent Hypertext. However, it would be useful to be able to just QI to the Hyperlink interface.

I may be misinformed here, but I believe it makes sense for AtkHyperlink to inherit from GInterface instead of GObject.
Comment 1 bill.haneman 2006-06-09 16:11:47 UTC
I don't think we can change the inheritance of AtkHyperlink.

Frankly don't think that it should be a queryable interface.  However I do agree that the consensus is to make AtkHyperlinks into full-fledged AtkObjects, which isn't what the old ATK docs say they should be.

Afraid we'll have to close this one as WILLNOTFIX, for technical reasons, anyhow.  
Comment 2 bill.haneman 2006-06-23 13:59:14 UTC
We can't change the inheritance of AtkHyperlink without breaking binary compatibility, but it seems we may need to create a new AtkHyperlinkImplementor interface in order to make AtkHyperlinks into 'full fledged AtkObjects' as proposed, since GObject only supports interface aggregation (AtkHyperlink doesn't inherit from AtkObject, nor is it an interface, ugh).

reopening with new summary
Comment 3 bill.haneman 2006-06-29 10:56:26 UTC
In at-spi, Accessibility::Hyperlink is an interface.  We can thus expose hyperlinks to the client as desired, but first we need to connect to some ATK backend hyperlink.  The proposed solutions are:

AtkHyperlinkIface, which deprecates AtkHyperlink's methods (replacing them), thus:
-> AtkHyperlink implements AtkHyperlinkIface, which becomes the preferred 
   mechanism for querying hyperlinks;

OR

AtkHyperlinkIface (same name), which has one method, getHyperlink, returning an instance of the existing AtkHyperlink object type.

The second solution probably involves slightly less code.
Comment 4 bill.haneman 2006-06-29 17:18:10 UTC
Created attachment 68176 [details] [review]
patch to add this interface, needed by mozilla/firefox
Comment 5 Neo Liu 2006-07-20 08:50:41 UTC
bill, several issues
1.i think there is an error in the patch. 
    AtkHyperlink  (* get_hyperlink) (AtkHyperlinkImpl *impl);
should be 
    AtkHyperlink*  (* get_hyperlink) (AtkHyperlinkImpl *impl);

2.i don't quite understand why & how this patch is good for firefox

3.what should i QI a AtkHyperlinkImpl in firefox side, nsIAccessibleHyperlink?

Comment 6 bill.haneman 2006-07-20 22:16:44 UTC
HI Neo:

yes, there was an error in the patch.  I have fixed it in cvs.

This patch is important since some firefox objects will be both hyperlinks (not anchors, but other objects embedded in text content) and also atkobjects.  The old AtkHyperlink interface does not allow this.

I don't know the answer to your question #3, we'll need to talk with Aaron.