World: r3wp

I can say I have probably helped Cyphre into a few decisions, which 
are old requests of mine.

so if its done Like I think, using R3 elixir should be VERY interactive. 
 and if that doesn't work, well, I can just use OpenGL later on.

(well elixir is already pretty smooth... much more than I would have 
anticipated... especially with so little in the way of optimisation 
so far)

nice ....

(obviously, liquid's lazy computing goes a long way into that.)

I am curious, what Carl has in mind for View ... there were view 
plug-ins planned (dunno if it is the same concept as "rebol language 
plug-ins"?), which were supposed to provide you access to loaders, 
savers, and maybe even buffers?

it is good we saw some interview with Carl. It was talked on 3 forums. 
With R3 release, we could continue in that kind of "marketing", with 
some nice demos etc.

AFAICT the whole view will be opensource, so could probably retro 
fit a lot of !

are you sure it will be open-sourced?

its what I have read between the lines... only the core is said to 
be closed source.  and much of the reason for going open source IS 
view... many bugs would have been fixed ages ago.. I think Carl sees 
the advantage.

and I think he also understand the need for some of us to NOT be 
standard REBOL cause we are not writting small scriptlets.

If I decided to go ahead with OpenGL and Elixir, using GLASS as the 
design... what is left of REBOL but the syntax and the interpreter 
anyways?  I'd rather have the tool running on steroids without being 
tied to a chain.

I wonder if other languages could benefit from View? I know they 
have e.g. wxWidgets, but not sure how easy would it be to integrate? 
Maybe with R3 as a whole, pythonists can link/load "rebol library" 
to do so :-) View simply needs rebol interpreter ...

So you can imagine porting your concpets elsewhere, e.g. Python?

python uses tcl and litterally converts python calls into tcp script 
and applies them as strings through the tcp interpreter... its soooo 
lame.

the trouble with toolkits like wxWidgets imo is, that those allow 
mostly traditional widgets, kind of RebGUI ones. Not free form faces 
with draw facitilies etc.

Its always been the vision... in fact I am eagerly waiting R3 to 
see how much of liquid I can port as C++.

so I can make it hundreds of times faster.

think rebcode first :-)

I did a VID dialect in Python... worked exactly like GLayout with 
the proportional resizing.

same kind of list-based, free-form datatype and intutive.

what you used under the hood? wxWidgets? (PythonCard)

tcl/tk  directly .  not a single imported widget lib.

ended up with scroll panes, menues, tree views, all matter of buttons 
and fiels.

some very advanced GUIs where done with that engine... but alas, 
Its not my code, so I can't share it...

I don't even have a copy of it.

so continued from a discussion in VID+.

trying to help mario here grasp how to model a system using liquid.

I'd like to change the program to work with liquid but I have to 
be quick

The computer rooms ask for repairs is an old script I wrote for the 
cshool

now you see, since the structure of dependencies and synchronisation 
actually define the system... what you connect to what will basically 
define how  much flexibility you have in your system.

Now they want me to add proxy handling to the rooms but the proxy 
should be handled only by some users (that's why I plan to have a 
controll room and not an extra button in computer rooms)

so at some point, you will have to add some intermediate nodes (plugs 
in liquid) to control the states themselves. before sendin them to 
the actual dependent systems.

so the control room is only available for that user?

I've added flexybility putting the rooms in separate files and not 
in the script (as two school are using the same program), than I 
check the user of the LAN (I use the environment variables)

The xcript runs in a webpage with plugin so the user cannot change 
the envvars

Only some teachers will be able to have some buttons/nodes/handlers

is the gui an actual picture of the school's layout.

The plugin posts data to a CGI on the proxy and that's how I can 
control the proxy and store requests for repair

The gui has the rooms names as buttons. When you press the room name 
its layout (made of buttons) is shown along with a standard feedback 
layout (a form to send requests via CGI POST)

ok, so what do you have to manage about the proxy?

I can maybe put some user-data to buttons to contain attributes

The min goal with the proxy is to open a specific room at a specifica 
time up to a specific hour or up to a limit hour (when the school 
closes)

min=main

Asking more the "open" rooms should be coloured in a different way 
so all teachers know thet Internet is available.

It might be that a single computer should be opened instead of opening 
the whole room

hum... and the proxy configuration is handled by small cgi requests?

Are you thinking about security risks?

I compress the CGI request so it's not readable

I POST compressed data