GNOME Bugzilla – Bug 696302
Objects should be able to indicate which of their data can be cached
Last modified: 2021-06-10 11:26:00 UTC
Filing this in response to an IRC discussion. It would be nice if ATK objects could notify AT-SPI whether particular properties can be cached. ATK has ATK_STATE_TRANSIENT, and AT-SPI will not cache properties if an object has this state set, but sometimes caching an object's state/role/parent should be fine, but an object's name may change without a notification. I'm not sure how best to handle this. Maybe something like void atk_object_enable_cache (AtkObject *accessible, const gchar *property, gboolean enabled); Or does glib have something similar, or should it?
(In reply to comment #0) > Filing this in response to an IRC discussion. And I think that I lack some of the background of this proposal. Could it possible to paste the relevant part of that discussion on this bug? > It would be nice if ATK objects could notify AT-SPI whether particular > properties can be cached. ATK has ATK_STATE_TRANSIENT, and AT-SPI will not > cache properties if an object has this state set, but sometimes caching an > object's state/role/parent should be fine, but an object's name may change > without a notification. FWIW, a change like that seems to go in the opposite direction of having ATK as abstract as possible (I know that this is not the current case right now, but thats the objective) unless I'm understanding wrongly the proposal. > I'm not sure how best to handle this. Maybe something like > void atk_object_enable_cache (AtkObject *accessible, const gchar *property, > gboolean enabled); I'm also not sure, and I think that it is part of that lack of background. My main concern is about adding too much burden to ATK implementors (like GTK, etc). When ATK implementors would use it? When they would know that a property or element are a good candidate to be cached or not? Probably this can be solved by a proper documentation, so what Im saying is that we should have a clear idea of those preconditions and how-tos before adding the featured. > Or does glib have something similar, or should it? Although my answer to this question is "don't know", this sounds too specific to have listed on glib, so I would found it really unlikely.
(In reply to comment #1) > (In reply to comment #0) > > Filing this in response to an IRC discussion. > > And I think that I lack some of the background of this proposal. Could it > possible to paste the relevant part of that discussion on this bug? probably doesn't help much but < tbsaunde> mgorse: can things implementing atkobject instruct so, or just the libatspi user? < mgorse> Hmm. Just a libatspi user right now < tbsaunde> mgorse: ok, would probably be a nice thing to have < tbsaunde> for cases where applications know they can't do events < clown> mgorse: I have newbie question about at-spi events: are there any menu-related events? < mgorse> clown: You'll probably see focus and object:state-changed:selected when a menu item gets focused < tbsaunde> mgorse: thoughts on adding such a thing? < clown> mgorse: thanks. but, there is nothing specific for "menu", right? By contrast MSAA emits EVENT_SYSTEM_MENUPOPUPSTART when a popup is made visible, and an "END" when it disappears. < clown> tbsaunde: good question. :-) < tbsaunde> clown: I was sking about caching not menu stuff :) < clown> tbsaunde: Ah, okay. < clown> Still, a good question. < mgorse> clown: Interesting. No, ATK/AT-SPI doesn't have anything like that; you'd need to look at the role of the item that gained focus, to determine that it's a menu < clown> mgorse: thanks for the info. good to know. -!- shaunm [~shaunm@208.102.162.148] has joined #a11y < mgorse> tbsaunde: Would it make sense to set ATK_STATE_TRANSIENT on the objects? Data for objects set as transient is also not cached; it is intended for objects which may not emit events when their state changes < mgorse> Or do you think that we should have something more fine-grained? If so, then I think we should file a bug for now, so that we don't forget about it < tbsaunde> mgorse: probably more fine grained < tbsaunde> mgorse: caching states / role / parent should all be fine < mgorse> tbsaunde: I've filed bug 696302. I'm not sure how best to handle it at the moment <@Services> Bug http://bugzilla.gnome.org/show_bug.cgi?id=696302 enhancement, Normal, ---, atk-maint, UNCONFIRMED, Objects should be able to indicate which of their data can be cached > > It would be nice if ATK objects could notify AT-SPI whether particular > > properties can be cached. ATK has ATK_STATE_TRANSIENT, and AT-SPI will not > > cache properties if an object has this state set, but sometimes caching an > > object's state/role/parent should be fine, but an object's name may change > > without a notification. > > FWIW, a change like that seems to go in the opposite direction of having ATK as > abstract as possible (I know that this is not the current case right now, but > thats the objective) unless I'm understanding wrongly the proposal. I think its really just making the transient state more finely grained. That makes API a little more complicated yes, but it lets you out of the choice between being really slow because nothing is cached and incorrect because stuff that can't be updated is cached. > > I'm not sure how best to handle this. Maybe something like > > void atk_object_enable_cache (AtkObject *accessible, const gchar *property, > > gboolean enabled); > > I'm also not sure, and I think that it is part of that lack of background. My > main concern is about adding too much burden to ATK implementors (like GTK, > etc). When ATK implementors would use it? When they would know that a property > or element are a good candidate to be cached or not? Probably this can be > solved by a proper documentation, so what Im saying is that we should have a > clear idea of those preconditions and how-tos before adding the featured. So, the problem I want solved is that as an implementor I want to be able to say "I can't promise that I will always fire events when this property changes therefore you should not rely on me doing so". > It would be nice if ATK objects could notify AT-SPI whether particular > properties can be cached. ATK has ATK_STATE_TRANSIENT, and AT-SPI will not > cache properties if an object has this state set, but sometimes caching an > object's state/role/parent should be fine, but an object's name may change > without a notification. > > I'm not sure how best to handle this. Maybe something like > void atk_object_enable_cache (AtkObject *accessible, const gchar *property, > gboolean enabled); if its simpler I'd be happy if this was the level that you can only set it for a particular type inheriting from atkobject not every atkobject itself, or even process wide, but per object is probably the most flexible.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of atk, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a ticket at https://gitlab.gnome.org/GNOME/atk/-/issues/ Thank you for your understanding and your help.