Exactly, That's why you will get event-driven behaviour with Rugby on *all* Rebol versions. You can even implement this quite simple on top of /deferred in Rugby now yourself.
--Maarten > > ->> read clipboard:// > > ** Access Error: Invalid port spec: clipboard:// > > ** Near: read clipboard:// > > ->> help event > > Found these words: > > event! (datatype) > > event? (action) > > to-event (function) > > ->> evt-port: open [scheme: 'event] > > ** Access Error: Invalid port spec: scheme event > > ** Near: evt-port: open [scheme: 'event] > > > > The same kind of output will come from /Command console. As you can see, > > even clipboard:// is blocked for both Core and Command. > > That's because on some platforms the clipboard is tied to the GUI engine. > On Unix, e.g., the clipboard required X11, so a REBOL version with > clipboard support can only be used on platforms with X11 libraries > installed. Having that kind of limitation in Core or Command would make > it impossible to use them for CGI purposes on platforms that do not have > the X11 libraries installed. > > > I think that RT could > > rethink the issue and definitely move event system into core language, > > not just View module. GUI events are just one of possible area of usage. > > I think e.g. timers (just another example of event) belong definitely to > > Core ... > > The event! datatype is for GUI (input) events only, not for other types of > system events. The universal i/o and signalling mechanism in REBOL > consists of ports and 'wait. Timers would be implemented using ports as > well. An "event" in its abstract notion is simply "something that > happens asynchronously". In REBOL this concept is captured by data > arriving at a port and that port signalling the arrival to a pending > 'wait call. > > "Event-driven programming" has nothing to do with the event! > datatype. It simply describes a style in which the program waits > in a single, central place most of the time, and the program flow is > driven by external influences. In REBOL you do this by using ports > and 'wait. If you want to handle GUI events as well then ONE of the > ports you wait for is the global event-port, but other than that there > is no impact on your event loop, and it is certainly not necessary > to use the event-port to write event-driven programs. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
