[REBOL] Re: Portals?
From: petr:krenzelok:trz:cz at: 14-May-2001 20:17
> > > > Hi cyphre :-)
> > >
> > > Hi PeKr =)
> >
> > ;-) heh, what a fun, switching dialect:
> >
> > [kdy zajdem na pivo? 8-)]
> [tak co, kdy zase budes v Brne? rad bych te konecne poznal LIVE;-)]
[ah, Brno, no tak to doufejme ze se potkame nez mi bude 40 :-))]
> > > -system programmable keyboard handler (will be added later)
> >
> > how is it going to be done? How do you want to process all the ongoing
> > events? I assume it will be wery difficult to achieve. Maybe you could
use
> > any kind of batch mode and send you events in groups?
>
> developer will be able to simple program for example shortcut-keys for
each
> fa apply but this is just my first idea...
ah, I commented wrong section. I mean - how do you want to distribute GUI
stuff? I just wonder if it would be possible to hook even port and send it
to other machine and do "insert" into its own event port :-) Distributed
drawing :-)
>>
> > btw: what about /Core? Do you think (as I do :-) the /Core deserves
event
> > system to have too? :-)
> >
>
> Sure ;-) The REBOL/view event mechanism is really cool...it can be used
not
> just for refreshing graphics in /View.I believe RT will add possibility to
> make custom events, redirect them etc. soon.
would be cool!
> > > -pseudo-multitasking(threading) driven by system task/schedule
priotity
> > > manager (you don't have to run separate rebol interpreter for each
> >
> > is it based upon sterling's proxy script mechanism?
>
> I was thinking about it but I still believe that there is better
solution...
but it is a little bit difficult with one event queue. Maybe async protocols
will help a bit ...
> > > aplication-the whole system is just one rebol process!) (in progress -
> I'm
> > > not sure if I can manage it without more asynchronous behavior of
> REBOL -
> >
> > what do you mean by "more asynchronous behavior of REBOL"?
> >
>
> When I've been experimented with WAIT command I've hit the REBOL barier
> regarding rebol internal structure. I have little chat with Jeff about it
> and here is his answer(I hope Jeff or RT don't kill me for this
> publication):
ha, I remember the statements - it was not Jeff imo, but Holger who said it
:-)
> ---snip---
> "If REBOL had real threads then wait would simply suspend the thread for
the
> indicated time. That would allow "flattening" of nested waits to allow
> parallel timeouts. With the non-threaded stack machine we currently have
> this is not possible though."
> ---snip---
>
> This is not something bad against REBOL. It is just a fact how Rebol
> probably works. Most of us can live without it. But I still believe
someday
> this will be solved. I very appreciate RT's first step(asynchronous
> protocols) to achieve multi-threaded REBOL. I'm looking for a new detailed
> documentation about the asynchronous features in REBOL. BTW have anyone
more
> information about it?
No info available yet, but IIRC Holger said something about Rebol 3.0? But
maybe I am wrong ...
> > heh, my friend, you completly left DID :-) How is it going? Have you (or
> > Rebolek) already started implementation?
> >
>
> Well, REBOLek have something done. He showed me his own dynamic styles but
I
> think it is a lot of work for one person to make lots of styles. I would
> prefer to construct basic dynamic positioning mechanism with editor and
let
> people to make some cool styles. Maybe I will become more active in this
> field...
could you allign here please, what is dynamic on your dynamic system? In
what ways it differs from VID?
>>> While waiting try to imagine transparent
> > > smoked-glass SWIS windows with great design on your SWIS screen ;-)
> >
> > Ah, well, but be carefull - you already use hw scrolling. So what about
> > moving window content? I hope next version of SWIS will not require me
to
> > upgrade to 2GHz Pentium machine :-)
>
> ok,ok ... I was playing with transparency in SWIS on my [Celeron--533] box
with
> VERY interesting results so watch the new release ;-)
transparency is very nice, especially glass effects ... but I assume some
gradiented glass effect background is going to be very CPU hungry ...
> see ya,
ciao :-)
-pekr-
PS: looking at our mail exchange I think it would make for good interview
:-)) pekr - former Amiga Review magazine columnist :-)