812968 - densify nsEventShell

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[alexander :surkov (:asurkov)]

I started to think that 'shell' might be not a best name. EventDispatcher is better but it seems too long. A while ago David suggested EventGun which is short but funny a bit. Suggestions?

Comment 1

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #0)
> I started to think that 'shell' might be not a best name. EventDispatcher is
> better but it seems too long. A while ago David suggested EventGun which is
> short but funny a bit. Suggestions?

I'd sort of like to just get rid of it.

It seems like the state it keeps while event is fired should be in windows specific code since that is the only place it can be used afaict.

Then once that happens its really just a wrapper around accessible->HandleAccEvent() so why not just get rid of it.

otherwise EventGun doesn't seem that strange atleast when compared to ion::canon() and js::JaegerShot()

Comment 2

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #1)

> It seems like the state it keeps while event is fired should be in windows
> specific code since that is the only place it can be used afaict.

it's a cross platform code

> Then once that happens its really just a wrapper around
> accessible->HandleAccEvent() so why not just get rid of it.

well we could merge it with Accessible class but I think I like that wrapper. It should be inline though.

> otherwise EventGun doesn't seem that strange atleast when compared to
> ion::canon() and js::JaegerShot()

those are crazy :) So you like EventGun, prefer it to other names?

Comment 3

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #2)
> (In reply to Trevor Saunders (:tbsaunde) from comment #1)
> 
> > It seems like the state it keeps while event is fired should be in windows
> > specific code since that is the only place it can be used afaict.
> 
> it's a cross platform code

Sure, but for it to be useful the event observer needs to get the evnet sync which I believe only happens on windows no?

> > Then once that happens its really just a wrapper around
> > accessible->HandleAccEvent() so why not just get rid of it.
> 
> well we could merge it with Accessible class but I think I like that
> wrapper. It should be inline though.

or we could merge it with DocAccessible and have
DocAccessible::FireEvent()

> > otherwise EventGun doesn't seem that strange atleast when compared to
> > ion::canon() and js::JaegerShot()
> 
> those are crazy :) So you like EventGun, prefer it to other names?

Well, it sort of describes what it does and I can't think of anything better.

Comment 4

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #3)
> (In reply to alexander :surkov from comment #2)
> > (In reply to Trevor Saunders (:tbsaunde) from comment #1)
> > 
> > > It seems like the state it keeps while event is fired should be in windows
> > > specific code since that is the only place it can be used afaict.
> > 
> > it's a cross platform code
> 
> Sure, but for it to be useful the event observer needs to get the evnet sync
> which I believe only happens on windows no?

so you suggest to not expose 'event-from-user' object attribute on linux and for xpcom since it's not used there. Ok, it seems reasonable.

> > > Then once that happens its really just a wrapper around
> > > accessible->HandleAccEvent() so why not just get rid of it.
> > 
> > well we could merge it with Accessible class but I think I like that
> > wrapper. It should be inline though.
> 
> or we could merge it with DocAccessible and have
> DocAccessible::FireEvent()

details, how does it work?

Comment 5

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #4)
> (In reply to Trevor Saunders (:tbsaunde) from comment #3)
> > (In reply to alexander :surkov from comment #2)
> > > (In reply to Trevor Saunders (:tbsaunde) from comment #1)
> > > 
> > > > It seems like the state it keeps while event is fired should be in windows
> > > > specific code since that is the only place it can be used afaict.
> > > 
> > > it's a cross platform code
> > 
> > Sure, but for it to be useful the event observer needs to get the evnet sync
> > which I believe only happens on windows no?
> 
> so you suggest to not expose 'event-from-user' object attribute on linux and
> for xpcom since it's not used there. Ok, it seems reasonable.

yeah, I'm pretty sure its impossible to notice in atk because HandleAccEvent() returns before at gets event.

> > > > Then once that happens its really just a wrapper around
> > > > accessible->HandleAccEvent() so why not just get rid of it.
> > > 
> > > well we could merge it with Accessible class but I think I like that
> > > wrapper. It should be inline though.
> > 
> > or we could merge it with DocAccessible and have
> > DocAccessible::FireEvent()
> 
> details, how does it work?

it'd probably just end up being athin wrapper aaround accessible->HandleAccEvent()  but if it were me I'd worry about this after I'd moved out the windows stuff and could see what ws left.

Comment 6

[alexander :surkov (:asurkov)]

isn't the fact that DocAccessible is not needed to fire an event confusing?