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 326516 - Add Accessibility::Collection
Add Accessibility::Collection
Product: at-spi
Classification: Platform
Component: api
Other Linux
: Normal enhancement
: ---
Assigned To: At-spi maintainer(s)
At-spi maintainer(s)
Depends on: 405774 407600 433011 437528 437958 496232
Blocks: 344422
Reported: 2006-01-10 20:50 UTC by George Kraft IV
Modified: 2013-08-14 16:33 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14

Collection IDL (3.36 KB, text/x-idl)
2007-02-02 16:06 UTC, Ariel Rios
First draft for collection work (26.89 KB, text/x-diff)
2007-09-17 15:26 UTC, Ariel Rios
More work on Collection (25.28 KB, patch)
2007-10-19 19:57 UTC, Ariel Rios
none Details | Review
Remove MATCH_RULE_PRIVATE. (26.19 KB, text/x-patch)
2007-11-12 08:42 UTC, Ariel Rios
Prevents memory leak when creating new mathrule. (27.14 KB, patch)
2007-11-15 15:33 UTC, Ariel Rios
needs-work Details | Review
Some small nits (26.23 KB, patch)
2007-11-30 09:55 UTC, Ariel Rios
none Details | Review
the patch will be committed (25.72 KB, patch)
2007-12-03 06:27 UTC, Li Yuan
committed Details | Review
patch to avoid build error (2.22 KB, patch)
2007-12-04 00:23 UTC, Li Yuan
committed Details | Review
patch to avoid crash (616 bytes, patch)
2008-02-15 07:04 UTC, Ginn Chen
none Details | Review

Description George Kraft IV 2006-01-10 20:50:16 UTC
Implement Accessibility::Collection per

Target Gnome 2.16 by the end of July 2006.
Comment 1 George Kraft IV 2006-06-28 15:56:37 UTC
Ariel and Bill to collaborate on the implementation of Collection for Document, and possibly Collection for Frame (to help debug).  Suggest implementing in the following order: createMatchRule, freeMatchRule, getChildren, getNextChildre, getPreviousChildren.  Get consensus on isAncestorOf and getActiveDescendant before implementing.
Comment 2 bill.haneman 2006-06-29 11:24:47 UTC
I believe we reached agreement/conclusion that getActiveDescendant should live in Collection, but only apply to objects with the MANAGES_DESCENDANTS property.  Thus, a non-NIL implementation of getActiveDescendant will have to depend on AtkCollection, since we can't practicably implement Collection on behalf of MANAGES_DESCENDANTS objects in the bridge.

isAncestorOf seems OK, it basically asks "is a given object part of this Collection container" ?  _possibly_ it should be placed in Accessible instead, along with getAncestors, but we've run out of bincompat/unimplemented "slots" there, and thus we might need something like an AccessibleContainer interface instead.

I suggest we leave getActiveDescendant out of the 'first rev' of Collection, and add it later when we have AtkCollection as well.  This would also allow us the alternate approach of AccessibleContainer (which would, I suppose, derive from Accessible) instead.

Comment 3 bill.haneman 2006-07-19 10:26:16 UTC
Bumping to Gnome 2.18, to allow ample time for implementation, testing, and review before the API gets frozen.
Comment 4 Ariel Rios 2007-02-02 16:06:23 UTC
Created attachment 81770 [details]
Collection IDL


I'm starting again on Collection. I am using
and fix a small typo (s/inOut/inout) but I'm sure you have a good one with docuemntation included.

Comment 5 Ariel Rios 2007-04-02 16:10:06 UTC

I was trying to add bugs 405774, 407600 to the block fields of this bug so we can have a nice dependency graph for references purposes but couldn't do so because I don't have enough permissioes. Could you please assign this bug to me?

Comment 6 Ariel Rios 2007-09-17 15:26:12 UTC
Created attachment 95739 [details]
First draft for collection work

This patch implements getMatches, getMatchesFrom and getMatchesTo using SORT_CANONICAL order. A brief sample script looks like this:

def run(acc):
    col = acc.queryInterface('IDL:Accessibility/Collection:1.0')	
    if col is None:						
       raise NotImplementedError('%s does not implement collection' %

    roles = [Accessibility.ROLE_PUSH_BUTTON,Accessibility.ROLE_FRAME]  
    rule = col.createMatchRule(None, col.MATCH_ANY ,
	                       "", col.MATCH_ALL,
			       "", col.MATCH_ANY,
                               "", col.MATCH_ALL,

    ls = col.getMatches (rule, col.SORT_ORDER_CANONICAL, True, 0)

I will be adding a bug to contain more usable scripts to test collection.
Comment 7 Ariel Rios 2007-10-19 19:57:01 UTC
Created attachment 97489 [details] [review]
More work on Collection

Cleanup work, memory improvements et al.
Comment 8 Li Yuan 2007-10-29 02:21:52 UTC
I have reviewed part of your patch but not finished yet. It looks good,
thanks for your hard working.

I have some questions about the patch:

1. I see you use G_TYPE_INSTANCE_GET_PRIVATE() to get the private
structure for SpiCollection. From : "This macro should only be used in type implementations." So I guess we need to find a replacement.

2. SpiCollection's private structure is named MatchRulePrivate which I
think SpiCollectionPrivate is better. Was MatchRulePrivate designed as
MatchRule's private structure originally? If so, why do we change it to

3. After apply the patch, in impl_createMatchRule, do we create a 
SpiMatchrule by spi_matchrule_interface_new, don't do anything, and
return it (by CORBA_Object_duplicate)? Because after apply the patch, we
get mrp from SpiCollection. Is there a reason for this?

4. How about there are 2 or more ATs running and all of them call a
particular object's createMatchRule (assume it implements collection
interface)? From my imagination, buffers created by impl_createMatchRule
may be leaked. example: 
1) AT1 calls createMatchRule
2) AT2 calls createMatchRule
3) AT1 calls freeMatchRule
4) AT2 calls freeMatchRule

I think after step 2, we will lose the buffers we created at step 1 and
cannot free them. What do you think?
Comment 9 Ariel Rios 2007-11-12 08:42:33 UTC
Created attachment 98964 [details]

Comment 10 Ariel Rios 2007-11-15 15:33:11 UTC
Created attachment 99144 [details] [review]
Prevents memory leak when creating new mathrule.
Comment 11 Willie Walker 2007-11-27 21:40:46 UTC
(In reply to comment #10)
> Created an attachment (id=99144) [edit]
> Prevents memory leak when creating new mathrule.

Li - does this patch look good to you?  If so, we should try to get it in for the 2.21.3 release coming up next week (tarballs due 03-Dec).
Comment 12 Li Yuan 2007-11-28 03:26:02 UTC
I still have some questions.

From the patch, we free the previous rule when another createMatchRule call comes in. Means if the first AT creates a rule, and the second creates another, and the first one is lost. Also an AT cannot create more than 2 rules at the same time. Is this the design? 
Comment 13 Ariel Rios 2007-11-28 06:28:36 UTC
So far I always had in mind that you can only have one matchrule being executed at a certain moment in time. Usually, you would need to create a new match rule to look on the results from a query. This could be changed as a future enhancement or  I can work on it now. Whatever you prefer. I would prefer to have it commited so people can start working and get feedback from AT implementors. In any case I will start looking into this.

Comment 14 Li Yuan 2007-11-30 06:43:01 UTC

Since we store MatchRulePrivate in collection now, what's your plan about SpiMatchrule? 
Comment 15 Li Yuan 2007-11-30 06:56:03 UTC
I found the answer from your mail before. Any update for this issue? (remove
Matchrule or make MatchRulePrivate to be bound withing MatchRule)

Is there any reason makes us wanna add collection interface to SpiApplication?
Comment 16 Ariel Rios 2007-11-30 08:10:27 UTC
I am working on removing MatchRulePrivate and bounding it to MatchRule. The change will be internal and the API is not going to be changed but we will be able to have several MatchRule objects declared. Could it be possible to include what we have in the next GNOME release(2.21.3) and work on this improvements for the next release?

THe first reason of adding collection to SpiApplication was to have a easy way to get collection although it might not be a good place and might only be needed or useful in things like frames. I added another bug for discussion of this point. I really have no point against or in favour.

Comment 17 Li Yuan 2007-11-30 08:22:43 UTC
If we don't add it to SpiApplication, the collection should still work right? If so, I suggest we don't add it to SpiApplication.
Comment 18 Ariel Rios 2007-11-30 09:07:27 UTC
Some changes might need to be done to the scripts but the rest should work just fine.

Comment 19 Ariel Rios 2007-11-30 09:55:24 UTC
Created attachment 99896 [details] [review]
Some small nits 

This one removes the bridge part the added the collection interface to Application and removes copyright notices as we are unsure what to do.
Comment 20 Li Yuan 2007-12-03 06:27:19 UTC
Created attachment 100094 [details] [review]
the patch will be committed
Comment 21 Li Yuan 2007-12-03 08:47:12 UTC
Ariel, we have a problem here. The patch can be compiled well on Linux, but it causes errors on Solaris.
I think it is because SUN Studio's CC treat "restrict" as a keyword, which seems gcc do not by default. We may need to change it to another word.
Comment 22 Li Yuan 2007-12-03 08:50:31 UTC
You can make the diff from the svn trunk now because I have committed your patch. And please submit the new diff today to catch up with today's release. Thanks.
Comment 23 Li Yuan 2007-12-04 00:23:04 UTC
Created attachment 100157 [details] [review]
patch to avoid build error
Comment 24 Ginn Chen 2008-02-15 07:02:35 UTC
(In reply to comment #10)
> Created an attachment (id=99144) [edit]
> Prevents memory leak when creating new mathrule.

But in freeMatchRule, spimatchrule->_mrp is not setting to NULL.
So it will crash, if AT does freeMatchRule before re-creating matchrule.
Comment 25 Ginn Chen 2008-02-15 07:04:31 UTC
Created attachment 105307 [details] [review]
patch to avoid crash
Comment 26 Ginn Chen 2008-02-15 07:07:12 UTC
forgot to mention the bug report in mozilla bugzilla
Comment 27 Ginn Chen 2008-02-25 10:40:10 UTC
Comment on attachment 105307 [details] [review]
patch to avoid crash

This patch was taken and committed by Bug 517250.
Comment 28 André Klapper 2012-02-26 10:44:23 UTC
[Resetting QA Contact to newly introduced "at-spi-maint@gnome.bugs". 
Reason: So far it was impossible to watch changes in at-spi bug reports without following all the specific persons (Li Yuan, Bill Haneman, Jeff Wai, ...) and also their activity outside of at-spi reports.

IMPORTANT: Anyone interested in following all bug activity (including all maintainers) must watch the "at-spi-maint@gnome.bugs" dummy user by adding it to the 'Users to watch' list under Preferences->Email preferences. This is also the default procedure nowadays in GNOME when setting up new products.]
Comment 29 André Klapper 2013-08-14 10:07:34 UTC
[Mass-resetting default assignee, see bug 705890. Please reclaim this bug report by setting the assignee to yourself if you still plan to work on this. Thanks!]
Comment 30 Ariel Rios 2013-08-14 16:15:34 UTC
I think this bug should be closed by now.