Even with the 'cheese' in the commit message, that's great to see. Now that the raw functionality is there, I think it would be good to look at developer usability too, it's great that:
works, but I'd really love us to approach the C# level of syntactical sugar if we can get closer. The attach/detach looks like some corner-case thing that is infrequently used(?); I expect we should try to create JS wrappers for the things people use that get this closer to:
document.onFoo = dobaa();
And expose something much simpler at first then expand where needed.
From an API surface perspective using AWT is a bit of an issue too - we're currently moving towards doing a lot of work to try to ensure that key-presses can be handled JS-side without server round-trips to improve latency while this awt key-vetoing could ultimately fit into that world of eventual consistency - it will increasingly look ugly as/when we get to that place.
Is there some other event we could hook for the cheesy demo new-paragraph or something that can do something similarly fun ? I hope we plan to deprecate/replace most of the low-level awt stuff there.
Anyhow - that aside - great to see callbacks working
The main insight from the callback work so far is to use C++ objects (rather than JS ones) for the listeners, which frees us from some life cycle and threading concerns. The resulting JS surface syntax (with user-provided attach/detach/on JS snippets) owes to that, but indeed is not the most beautiful yet.
css.awt.XKeyHandler::keyPressed is one of the few existing listeners that has a non-void return type, so I picked that one to test and demo how these callbacks can round trip back. But most likely not something we’d want to put into the product, so that’s why it only ended up in the (ultimately to be thrown away) WIP cheesy demo commit.
The main insight from the callback work so far is to use C++ objects
(rather than JS ones) for the listeners, which frees us from some life
cycle and threading concerns.
Ah - nice :-) sounds sensible.
css.awt.XKeyHandler::keyPressed is one of the few existing listeners
that has a non-void return type
Ah :-) heh, that's an interesting fact in itself I guess.
But most likely not something we’d want to put into the product, so
that’s why it only ended up in the (ultimately to be thrown away)
WIP cheesy demo commit.
Makes sense; thanks for the background !
Good stuff,
Michael.
while this awt key-vetoing could ultimately fit into that world of eventual consistency - it will increasingly look ugly as/when we get to that place.