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

[Aaron Leventhal <aaronlev moonset net>]

One use for STALE might be if an object is waiting for the network or 
device, or an asynchronous calculation.
For example, might an AJAX calendar view be considered STALE after a 
user hits the "next month" key until it finishes loading the next month. 
In that case it might also be BUSY.

So, to me,
STALE = temporarily dead, but it might become useful again. The app 
should fire a state change event for STALE if it comes back alive.
DEFUNCT = totally dead. forget about using this object ever again
TRANSIENT = ???? I'm still a little lost on that one. The definition in 
the docs is still self referential.

- Aaron

Bill Haneman wrote:
> 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
> >