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 tell the users of ATK to expose them both with the same value. Tell the users of AT-SPI to use one of them. or 3) come up with an explanation for ENABLED vs. SENSITIVE that makes sense, such as: SENSITIVE = not disabled ENABLED = sensitive and has at least one action associated with it
- Aaron Bill Haneman wrote: > 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 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 talking about is whether or not we change >> the semantics of ENABLED to be that of SENSITIVE and then get rid of >> SENSITIVE. >> >> IMO, making an incompatible change solely for the purposes of this >> particular word choice is a change I'd rather not have to deal with. >> I'd rather just ditch ENABLED and live with the word choice of >> SENSITIVE. However, that's only my "path of least impact" opinion >> (e.g., it wouldn't require potentially error prone changes to GAIL, OOo, >> and other implementations that may have already gotten it right), and I >> can acquiesce to the purification from naming pundits if so >> desired. ;-) >> >> Will >> >> On Fri, 2007-01-19 at 11:59 -0500, David Bolter wrote: >> >> >>> 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.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 here: >>>> >>>> http://java.sun.com/j2se/1.4.2/docs/api/java/awt/Component.html#setEnabled(boolean) >>>> >>>> When I look at the Java access bridge for GNOME, however, I see that >>>> perhaps my interpretation of SENSITIVE and ENABLED seems to be different >>>> from the interpretation made by the author of the bridge: >>>> >>>> http://svn.gnome.org/viewcvs/*checkout*/java-access-bridge/trunk/bridge/org/GNOME/Accessibility/StateTypeAdapter.java?content-type=text%2Fplain >>>> >>>> In any case, it looks like the Java API's use 'enabled' as their word. >>>> The word 'sensitive' seems to be a GTK-ism, and I'm guessing the whole >>>> enabled/sensitive state thing was invented with the AT-SPI. At this >>>> point in time, however, I'm not sure of the value in upsetting the apple >>>> cart -- the best thing would be to make the docs better. >>>> >>>> Will >>>> >>>> On Fri, 2007-01-19 at 16:06 +0000, 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 today and this weekend, so >>>>> can't be all that useful until Monday. I'll try to figure out, among >>>>> other things, what this was supposed to mean in Java-land, because a >>>>> number of states including the ones under current discussion were a >>>>> legacy inherited from javax.accessibility. Maybe Peter K. knows? >>>>> >>>>> I agree that we shouldn't drag useless stuff around forever, but my >>>>> concern is that just because something doesn't make sense to myself and >>>>> you guys at this moment, it doesn't mean that it wasn't useful and >>>>> sensible when originally mooted. Now seems like a good time to nail it >>>>> down (and document it better than it was apparently documented before). >>>>> >>>>> Bill >>>>> >>>>> _______________________________________________ >>>>> Gnome-accessibility-devel mailing list >>>>> [email protected] >>>>> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Gnome-accessibility-devel mailing list >>>> [email protected] >>>> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel >>>> >>>> >>>> >> _______________________________________________ >> Gnome-accessibility-devel mailing list >> [email protected] >> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel >> >> > > _______________________________________________ > Gnome-accessibility-devel mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel > > _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
