World: r3wp

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

you see, what I see here is that the actuall application data is 
on the server and your browser based plugins are just synchronised 
to it.

so using cgi for that kind of think (for liquid) is almost impossible, 
cause the viewers need to get the information BACK.

if someone else changes my setup, I have to be able to receive it.

so in reality, each time a computer opens up a view of the current 
state of each thing, it should have its own listener port.

When the gui starts I show servers state. As soon as a teacher clicks 
a button for a room he is changing the state...

but now you add the concept that "another" computer changes your 
state... you have to be made aware of that change.

so unless you can listen to someone, you will never know.