Closed Bug 377037 Opened 18 years ago Closed 18 years ago

get rid of StateChange struct

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: surkov, Assigned: surkov)

References

Details

Attachments

(3 files, 3 obsolete files)

Attached patch patch 1.1 (deleted) — Splinter Review
1) remove accdoc from arguments of event object constructor 2) rename nsAccessibleEventData -> nsAccEvent
Attachment #261141 - Flags: review?(aaronleventhal)
Attachment #261141 - Flags: review?(aaronleventhal) → review+
Comment on attachment 261141 [details] [diff] [review] patch 1.1 checked in
Summary: get rid StateChange struct → get rid of StateChange struct
Attached patch patch 2.1 (obsolete) (deleted) — Splinter Review
Attachment #261162 - Flags: review?(aaronleventhal)
Comment on attachment 261162 [details] [diff] [review] patch 2.1 Ginn, may I ask you to check this on linux?
Attachment #261162 - Flags: review?(ginn.chen)
Status: NEW → ASSIGNED
Should the following code use NS_NOTREACHED? if (!stateChangeEvent) { // XXX: It means we processed another events in FireToolkitEvent() // (see bug 377022). return NS_OK; } I'd like to know what the bigger plan is. - Will we eventually get rid of FireToolkitEvent()? Right now it seems strange to have both FireAccessibleEvent() (only for some events) and FireToolkitEvent(). It doesn't seem obvious why there are 2 separate systems. I don't like the idea of checking this in without fixing it very soon. - How will you deal with FireDelayedToolkitEvent() for state change events, which we need for the attribute changes. We need that because the attribute is not actually changed yet. We want to make sure if they call back and get the state it's already set to what it should be. - Will every event type need it's own interface derived from nsIAccessibleEvent? (I don't think so, just the few that use some kind of event data).
(In reply to comment #5) > Should the following code use NS_NOTREACHED? > if (!stateChangeEvent) { > // XXX: It means we processed another events in FireToolkitEvent() > // (see bug 377022). > return NS_OK; > } Not sure, what is better. But in any way it's temporary state. > I'd like to know what the bigger plan is. > - Will we eventually get rid of FireToolkitEvent()? Right now it seems strange > to have both FireAccessibleEvent() (only for some events) and > FireToolkitEvent(). It doesn't seem obvious why there are 2 separate systems. Late we should have FireAccessibleEvent() only. > I > don't like the idea of checking this in without fixing it very soon. If you will approve then it's not a problem to fix it soon. > - How will you deal with FireDelayedToolkitEvent() for state change events, > which we need for the attribute changes. We need that because the attribute is > not actually changed yet. We want to make sure if they call back and get the > state it's already set to what it should be. The problem of the bug 374711 approach is StateChange is deleted before event is processed. In this case it won't be because we use nsCOMPtr. Are there something else? > - Will every event type need it's own interface derived from > nsIAccessibleEvent? (I don't think so, just the few that use some kind of event > data). > Yes, not for every type, but every event that has specific data.
> If you will approve then it's not a problem to fix it soon. Okay, let's do it all now. It won't take too long for you, since you're fast. Everything else makes sense.
Comment on attachment 261162 [details] [diff] [review] patch 2.1 I approve the idea but can't look at the patch in detail right now. Ginn, can you review?
Attachment #261162 - Flags: review?(aaronleventhal)
Attached patch patch 2.2 (updated) (obsolete) (deleted) — Splinter Review
Attachment #261162 - Attachment is obsolete: true
Attachment #261215 - Flags: review?(ginn.chen)
Attachment #261162 - Flags: review?(ginn.chen)
Comment on attachment 261215 [details] [diff] [review] patch 2.2 (updated) some work need to be done for accessible/src/atk/nsDocAccessibleWrap.cpp stateChangeEvent and atkObj are not defined. also NS_IMETHODIMP nsDocAccessibleWrap::FireAccessibleEvent(nsIAccessibleEvent *aEvent) is not declared.
Attachment #261215 - Flags: review?(ginn.chen) → review-
Attached patch patch 2.3 (deleted) — Splinter Review
with ginn comments
Attachment #261215 - Attachment is obsolete: true
Attachment #261373 - Flags: review?(ginn.chen)
Attachment #261373 - Flags: review?(ginn.chen) → review+
Comment on attachment 261373 [details] [diff] [review] patch 2.3 checked in
Comment on attachment 261373 [details] [diff] [review] patch 2.3 >+nsAccStateChangeEvent:: >+ nsAccStateChangeEvent(nsIAccessible *aAccessible, >+ PRUint32 aState, PRBool aIsExtraState, >+ PRBool aIsEnabled): >+ nsAccEvent(nsIAccessibleEvent::EVENT_STATE_CHANGE, aAccessible, nsnull), >+ mState(aState), mIsExtraState(aIsExtraState), mIsEnabled(aIsEnabled) >+{ >+} Note that VC6 won't compile this because it can't resolve the nsIAccessibleEvent ambiguity, although ::nsIAccessibleEvent:: works.
Attached patch neil's comment patch (obsolete) (deleted) — Splinter Review
Attachment #261642 - Flags: review?(neil)
Comment on attachment 261642 [details] [diff] [review] neil's comment patch Assuming that's why you requested my review, VC6 doesn't like this either.
Attachment #261642 - Flags: review?(neil) → review-
Attached patch neil's comment patch2 (deleted) — Splinter Review
Attachment #261642 - Attachment is obsolete: true
Attachment #261647 - Flags: review?(neil)
Attachment #261647 - Flags: review?(neil) → review+
(In reply to comment #16) > Created an attachment (id=261647) [details] > neil's comment patch2 > checked in
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: