Re: [g-a-devel] Understanding ATK_STATE_TRANSIENT, ATK_STATE_STALE, ATK_STATE_DEFUNCT

[Bill Haneman <Bill Haneman Sun COM>]

Aaron Leventhal wrote:
> Both ATK and AT-SPI say -- STATE_TRANSIENT 
> Indicates this object is
> transient
> -> Not sure what that means
>
> My colleague Peter Parente says:
>   
> > i think stale occurs on transients which are left lying around, but 
> > might be reused
> > for instance, you empty an item in a tree temporarily, and then 
> > repopulate it later
> > usually accompanied by showing=False, visible=False I'd say
> >  gaim does this I think, when buddies log in and out
> >  the item for a buddy doesn't get deleted right away
> >  if the buddy comes back on within a certain time period, the same 
> > accessible is re-used for the person logging in
> >     
> So do STALE and TRANSIENT always go hand in hand?
> ATK says -- ATK_STATE_STALE    Indicates that the 
> index associated with
> this object has changed since the user accessed 
> the object.
> STATE_STALE -- Indicates that the information 
> returned for this object
> may no longer be synchronized with the application 
> state. This can occur
> if the object has STATE_TRANSIENT, and can also 
> occur towards the end of
> the object peer's lifecycle.
> -> These definitions completely disagree and 
> neither really explain it well
>   
However I think both are true and valid.  I'd at least make the docs a 
union of those two explanations.
> ATK says ATK_STATE_DEFUNCT  -- Indicates the user 
> interface object
> corresponding to this object no longer exists
> AT-SPI says STATE_DEFUNCT  -- Indicates that this 
> object no longer has a
> valid backing widget (for instance, if its peer 
> object has been destroyed)
> -> These agree (although unfortunately use 
> different wording), but I
> want to ask if a DEFUNCT object is also STALE.
>   
No, defunct != STALE.  Defunct means the object's peer is dead, whereas 
STALE just means "out of date/out of sync", the peer could be, and 
likely is, still alive.

TRANSIENT objects don't guarantee that they will emit DEFUNCT events BTW.

The case Peter Parente mentions is a very interesting use case for STALE 
- it means the object is no longer 'live', but might be woken from its 
zombie like slumber later.  Not sure how useful that is, but bear in 
mind that some of these state differences are there because making the 
toolkit elements always do the same thing may be untenable, i.e. it may 
be unfeasible to use VISIBLE as the toggle for the gaim case even though 
from the user's POV visibility would be mostly equivalent.
> Do we really need two separate states for DEFUNCT 
> and STALE? 
Yes.
> I suppose
> we need to find out what STALE really means first, 
> and if it's just part
> of some interesting architecture we can use with 
> TRANSIENT. Do STALE and
> TRANSIENT always go together?
Not sure.  In theory no, but in practice yes so far.  I don't think we 
should make the linkage explicit.

I think non-TRANSIENT objects can become stale - for instance if the 
index in the parent changes.  The question to ask ourselves here, I 
think, is whether we want to fire index-in-parent-change property events 
for non-TRANSIENTS.  If 'yes', then STALE is unnecessary for 
non-TRANSIENTS.  If 'no', then STALE has a use for non-transients (in 
the sense mentioned in the ATK docs).
>  Do those always go 
> with MANAGESDESCENDANTS?
>   
No. (in theory)
> - Aaron
>
>
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>