Concerning the purposes that I need, I wouldn't mind having a separate message bus which is unconnected to the event system - as long as it gets implemented before 0.7 comes out. I am interested in *events* only as far as I use them to dispatch global messages carrying data with them. I can easily switch the qxtransformer code to use a separate message bus system instead of "global events". Maybe this would indeed be a cleaner solution.
Christian Sebastian Werner wrote: > Am 18.05.2007 um 14:11 schrieb [EMAIL PROTECTED]: > > >> Sebastian Werner <[EMAIL PROTECTED]> writes: >> >> >>> I don't like the solution to be integrated in qx.core.Target. I would >>> like it better to add specific events to a special event router which >>> then informs registered objects about any of these events. This is a >>> lot cleaner than exclude tables and a deep integration in >>> core.Target. The overhead of many events would be to dramatic. I can >>> imagine of something like a widget monitor which reacts on all >>> widgets relevant stuff and for example a IO monitor which monitors >>> all IO related things. >>> >>> What do you think? >>> >> Hi Sebastian, >> >> That concept sounds fine. I'm not sure I follow where you'd add >> it, though, >> if not in Target. If one wants to monitor all, or some very large >> subset of >> events, where else could you put it that has access to the >> information? >> >> I expect that in the implementation I checked in last night, the >> overhead is >> quite small since it effects only events with listeners if the >> variant isn't >> enabled. I am concerned about the overhead when the variant _is_ >> enabled. >> > > Derrell, > > Each overhead even if really really little is to much in my opinion > because it also sits on time critical stuff. The whole idea for the > message bus is instead to use it only for not-so time crititcal > information. > > I would say, that a first step, before implementing something is, to > get a clear view of which currently existing events are interesting. > I think a whitelist is better than a blacklist in this case. A > message bus listener which reacts on all the possible events of > different areas e.g. io, widgets, focus, whatever is not quite often > - if it exist at all. > > >> I'd definitely like to hear more about how you would implement the >> special >> event router. Sounds quite interesting! >> > > OK, lets continue our discussion on Monday. > > Sebastian > > >> Cheers, >> >> Derrell >> >> ---------------------------------------------------------------------- >> --- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> qooxdoo-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
