Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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
> > any kind of batch mode and send you events in groups? > > developer will be able to simple program for example shortcut-keys for
> 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
> > system to have too? :-) > > > > Sure ;-) The REBOL/view event mechanism is really can be used
> 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
> > > 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
> 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
> 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
> 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
> 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
> 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
> > upgrade to 2GHz Pentium machine :-) > > ok,ok ... I was playing with transparency in SWIS on my [Celeron--533] box
> 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 :-)