Rewrite eventing architecture

[Updownquark]

I thought through the current eventing architecture for a long time during my initial design of what is now MUIS many years ago, but since I've actually been using it, it kind of just sucks. You have to know where the event type objects are located and then to get full utility out of the events, you have to know what subtype an event is (e.g. the mouse event's strong type is Void, so you just have to know that all events propagated for the mouse type are of type MouseEvent, but this is not type-enforced and must be filtered by a responsible listener).

Also, the events being propagated through the tree by the elements themselves hasn't worked out as well as I'd thought back then and I believe that functionality is no longer used. This feature is what the local flag on the listeners is for, but it's not well documented or intuitive. This feature probably just needs to be removed and verified that it's not used anywhere.

In addition, I'd like to move listeners out of the MuisElement class itself and into a separate attribute, like all the other managers. The more I think about it, the more I like the standard addXXXListener approach, but this needs to be extensible by subtypes.

[Updownquark]

The one big problem I've encountered so far is that the child list on an element natively supported adding listeners to all children on the list, dynamically. This more difficult when the events are not propagated through the elements themselves. Need to think of a clever solution to this.

[Updownquark]

I have just noticed that the child list is not really thread safe. The list is not locked while events are firing (by design), so the list's contents could change while the event is firing. I think the solution to this is to put more information in the event itself, e.g. the elements in the child list before and after the call. This way listeners can inspect the event itself and not be dependent upon the list for information during event firing.

[Updownquark]

Thinking over things again, having the (mostly) unified eventing architecture was kind of nice. It would be even nicer if it did things more than just fire events piecewise. I've been thinking of some things the event architecture should have that would justify the unification: Some of these may be pipe dreams.

• Better typed: Maybe the generic type could be the event type instead off the event's "value" which is not even used half the time
• Event batching. Maybe we could have a mechanism that allows grouping of listeners and events. For example:
  • An attribute is accepted with a starting value. This fires 2 events--one signifying that the attribute is now accepted on the element, and the other that the value has changed. This is 2 events that are fired out of only one logical operation. What if some piece of code added a listener group with 2 listeners, one for each of these types of events. But when the event group is fired, the first listener in that group could inspect the set of events, see the value change event, perform an operation and mark both of the events as accomplished by that group. This could have the affect of making smarter, more efficient listeners easier to implement. Stupid listeners as exist now should be just as easy to implement.
  • Another instance where this might be useful is in child events. The child lists have addAll, removeAll and retainAll methods that have the potential to cause multiple events if each event represents a single child. When the first event gets propagated, listeners that need to know about the set of events may be deceived since the set has been changed more than the single event indicates. I added some complicated lists to the child events to deal with this problem, but maybe event batching would be a more efficient and elegant solution to this and related problems.
• Vetoing system. Not at all sure this would be a good idea, but here it is. A veto exception could be thrown by any listener. This listener would be caught by the eventing architecture and interpreted as saying that the action that caused the event is illegal and should be reverted. All listeners that have seen the event before the veto would be re-notified with a reverse event somehow. If I did this I'd need to handle the case where an event is double-vetoed. E.g. an event fires through listener A fine, then is vetoed by listener B, then the reverse event is vetoed by A. Again, this is more just writing down the idea. Right now I'm leaning toward this wouldn't be very helpful or elegant.
• I've seen problems with listener systems where there will be 2 listeners: one which receives an event and in response modifies some data; another which receives the event and renders it. If the first listener happens to be registered or invoked after the second, What is rendered ends up being invalid because it was not updated by the first listener. Very possibly this situation does not apply to MUIS because of the way paint events, layout events, etc are asynchronous and non-duplicative.
• Infinite listener loops. I've seen this more with properties (which will apply here sometimes since properties like attributes will fire their events through here), but an event is fired to listener A which causes a change that causes an event to fire to listener B which causes an event to listener A and so on. Would be nice to have a lightweight mechanism to detect this.

I think I'm flip-flopping. Maybe the unified eventing could be a good thing if it can be made feature-full.

[Updownquark]

My flip-flopping is complete. I think having a central eventing service on the element is better than a bunch of fractured eventing services on each thing that does eventing. I will move the eventing out of the element itself into a new manager though. Regarding the previous ideas, I've done some thinking...

• Better typing: I think I hit the nail on the head here. The new generic type for the eventing system will be the type of the event itself. This type could potentially include a sub type for typed events like attributes.
• Batching: This is too complicated for little benefit. I think the listeners would have to be too smart to take advantage of this and the consequences of their not taking advantage of it should be pretty small. The really expensive operations like layouts and painting are filtered at the end so that no more of them happen than need to.
• Vetoing: This is just not a good idea. The listeners would have to be too smart.
• Racing listeners: I think I was right--this situation won't apply to me because any time listeners modify data, it will create another appropriate event.
• Infinite loops: My listener system isn't queued, so the java system will throw a stack overflow in this case--don't think it's necessary or very helpful for me to do it.

[Updownquark]

As mentioned in the commit, it works!! Mostly. Most of the tests work fine. A couple things I've noticed that are wrong:

• In the text test, text selection doesn't work right at all. This probably applies to text selection in general.
• In the text field test, selecting text in one of the text fields causes the text to wrap over to a new line. This is not right, but also, when it wraps the text field doesn't grow to show all the text. This may just be because it hasn't been well designed for multiple rows of text.

Also, I need to think about firing state events through the new architecture instead of through the state engine itself. I might think of a few more things, but I think this can be closed out pretty soon.

[Updownquark]

I think just bugfixes now. As soon as all the tests function just like they should, this can be closed.

[Updownquark]

This is done now. I need to reset the feature-BaseWidgets branch to this head and drop the two feature-EventRefactor branches and then I'll close this.