Nexela wrote:
Most data-library branch changes will be backwards compatible with master (except for today where I said screw it and local'ed all the things. So with the exception of Event/Gui local whatever = require("stdlib.modname") is pretty much mandatory).
As for console stuff, that should be working just fine (the example usage was incorrect).
Hm... well I have been playing with this again but I'm still completely striking out (in the data-library branch).
A few things seem to be going on.
First, the console, event and gui modules appear to be in some kind of load-ordering gordian knot that I can't seem to unravel. I'm pretty sure the remaining Event.Gui reference in Gui.register is just a missed substitution from commit 536e9a77. So, OK, I change that. Even still things seem to be load-order sensitive. It's kind of like those modules are mad at me for using, i.e., local Gui = require('stdlib/event/gui') because it hides globals they wind up expecting to be floating around. This may have to do with the recent "local all the things" tip commit in the branch.
The end result is the same as before. I can bring up the console gui but the event code associated with the buttons does not fire when I press them.
To me it seems like Gui is doing it all wrong. It takes over the global handler for the events its interested in (but only if Event doesn't already consume them), and jams its own non-Event-registry-format entries into that the Event registry, relying on I'm-not-exactly-sure-what-but-probably-some-kind-of-subtle-side-effect to avoid breaking the primary Event dispatcher, meaning there is a 2x2 matrix of possible outcomes: events dispatched solely by Event or Gui in one dimension, and event-handler-registry entries in standard Event format or extended Gui format. All apparently must all be supported which seems pretty cray cray.
Why doesn't Gui just consume the conveniently multiplexable Event API like any other consumer, and handle them with it's own secondary dispatcher, using a
private event_id={ pattern_spec = { <array of handlers> } } } registry to dispatch to tertiary listeners? Are we worried about the performance impact of hierarchical dispatch? That's the wrong place to get all optimiz-ey imo, it's just creating a muddle.
Maybe I'm missing some important reason for it to be this way?
)
