I don't want to break anything.
Therefore I suggest we have some decent options:
1) make them equivalent in both the bridge and docs, and then also
deprecate one of them. For example, if one is true the bridge would
always make the other true.
or
2) make them equivalent in just the docs, but tel
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
Note however that ANY change will break stuff. For instance some ATs
are using ENABLED, others SENSITIVE, some both. Real back-compatibility
requires that we keep them all working.
Bill
Willie Walker wrote:
> I definitely agree it would be a good thing to deprecate unused and
> confusing sta
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 a
I definitely agree it would be a good thing to deprecate unused and
confusing states. It would save everyone a lot of head scratching, and
I have no problem with upsetting that apple cart. Believe me, I've been
down this path before and I still scratch my head.
The particular apple cart I'm talk
Hi Will, I'm glad you are using your expertise here :-)
FWIW I'm glad Aaron is kicking at the apple cart... we really should
make sure it is solid.
Apples do grow on trees after all.. :-P
D
Willie Walker wrote:
> Here's the Javadoc from AccessibleState in the Swing toolkit:
>
> http://java.s
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
>
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
>
Here's the Javadoc from AccessibleState in the Swing toolkit:
http://java.sun.com/j2se/1.4.2/docs/api/javax/accessibility/AccessibleState.html#ENABLED
If I recall correctly from when I helped define/write the Java
Accessibility API almost 10 years ago(!), it corresponds directly to the
value set
Thanks Bill.
- Aaron
Bill Haneman wrote:
> David Bolter wrote:
>
>> sigh... make that "shouldn't have"... ever had one of those days?
>>
>> D
>>
>>
>>
> Yes :-)
>
> Folks, the truth is I just don't know/remember at the moment, without
> digging deep into the toolkits. I'm on leave
David Bolter wrote:
> sigh... make that "shouldn't have"... ever had one of those days?
>
> D
>
>
Yes :-)
Folks, the truth is I just don't know/remember at the moment, without
digging deep into the toolkits. I'm on leave today and this weekend, so
can't be all that useful until Monday. I'l
sigh... make that "shouldn't have"... ever had one of those days?
D
David Bolter wrote:
> hmmm probably should have written "default action" there... hope that
> doesn't add to the confusion... i mean just a stub.
> D
>
>> enabled == the button triggers application logic (if even only a
>>
hmmm probably should have written "default action" there... hope that
doesn't add to the confusion... i mean just a stub.
D
>
> enabled == the button triggers application logic (if even only a
> default action stub).
___
Gnome-accessibility-devel maili
I think in gtk land (from earlier in the thread) it sounds like:
enabled == useful
sensitive == useable
So in the case of a button
enabled == the button triggers application logic (if even only a default
action stub).
sensitive == the button can be "pushed".
If my understand above is correct the
Perhaps ENABLED is sensitive items that have a default action (action
#0), and would respond to a click.
From Will's explanation:
>>> ENABLED means that if the thing is SENSITIVE, manipulating it will
>>> actually cause some sort of action in the application. I'm not sure,
>>> but I think it is
> If sensitive is True the widget will be sensitive and the user can interact
> with it. An insensitive
> widget appears "grayed out" and the user can't interact with it.
> /*Insensitive widgets are known as "inactive", "disabled", or "ghosted" in
> some other toolkits.*/
There you have it. Sensi
[ Willie Walker, Fr., 19. Jan. 2007 16:15 ]
> IMO, the main cause for confusion is that the use of the word
> 'enabled' in the AT-SPI and how its meaning there differs from how
> enabled might be used in other toolkits.
Indeed. In Qt, "enabled" seems to mean exactly what is defined as "sensitive"
Will, that's the best explanation I've heard yet but I'm still confused.
First, I've never seen something grayed out that responds to user action.
So I would hope that ENABLED is the subset of SENSITIVE items that
actually do something.
Still don't really see the need for two states, but if the
> So Orca does not care about STATE_ENABLED? In gok we accept either
> sensitive _or_ enabled as worthy of providing access to for our users.
> In gok we have to err on that side though... as we are a different
> animal (non-aquatic actually).
Well...just like you, we tend to look at both. T
I agree that choice of wording by GUI toolkit developers is sometimes
fraught with ambiguity and apparent conflict, especially when the same
words have different meaning across toolkits. This does indeed cause
trouble with an API like AT-SPI that is trying to sit on top of multiple
toolkits.
In
Hi Will,
Willie Walker wrote:
>>> I don't believe any of the users of IA2 or ATK or using STATE_SENSITIVE
>>> to mean anything other than STATE_ENABLED.
>>> For one, no one understands it. Second, it's not actually useful because
>>> if somethings greyed out it should not react to user input. As D
Well I think you would need to give IA2 implementers *very* clear
guidelines on how to use these states and how to map to the APIs and
concepts that they use. For example my view that ENABLED means the
user can interact (and implies a non-greyed visual style) comes from
using EnableWindow() to cont
Bill I agree we should involve key folks from JFC and GTK+. Even if it
isn't a discussion about what to keep, it would be great to have some
help making the documentation clearer.
cheers,
David
Bill Haneman wrote:
> Aaron Leventhal wrote:
>
>> In that case I'd say the buzzer is presentationa
> > I don't believe any of the users of IA2 or ATK or using STATE_SENSITIVE
> > to mean anything other than STATE_ENABLED.
> > For one, no one understands it. Second, it's not actually useful because
> > if somethings greyed out it should not react to user input. As David
> > Bolter says, the UI de
Aaron Leventhal wrote:
> In that case I'd say the buzzer is presentational just like the greyed
> out color.
>
> I don't believe any of the users of IA2 or ATK or using STATE_SENSITIVE
> to mean anything other than STATE_ENABLED.
> For one, no one understands it. Second, it's not actually useful
25 matches
Mail list logo
