World: r3wp

Exactly.

ah, so it might be just a separate package,like RebGUI is to VID 
... yes, that's possible too ... we just did not want to have many 
GUIs available. But R3 GUI is in limbo anyway, so ....

we just did not want to have many GUIs available

 - that is pure theory. Currently, R3GUI is the only available alternative 
 working with the present interpreter version.

and: Than you need to take action and change it. It's not a "musical 
request programm" where you want something and it will happen.

No, not a musical request program, just whole REBOL ecosystem being 
 a hilarious parody ....

...And, R3GUI is not in limbo, it is being developed

I know ...

Will your planning app (which abbreviation I forgot - NNLP?) version 
2 be done in R3?

No, NLPP 2.0 is already being tested, and adjusted (finishing touches), 
in R2

BTW, it is not a "plannig app"

Rather it can be called a "Performace pricing" program, i.e. a program 
implementing a performance pricing methodology.

So the GUI we can see in screenshots is modified RebGUI? Looks decent 
enough. Similar skin would be nice tohave for R3 too ....

So the GUI we can see in screenshots is modified RebGUI?
 - yes

How goes the GUI?

I have a RebGUI application of some hundreds of screens and sadly 
it is not very brisk these days presumably due to GC occurring at 
inconvenient times, or just using too much ram.  Any stress testing 
down with R3GUI with hundreds to screens?

it's not easy to do stress testing, due to a specific bug not yet 
fixed by Carl, which prevents the creation of complex layouts without 
crashes.

Has Carl promised to fix it?

he has not responded on the bug at all.

Must be very frustrating ... and dangerous to base a business on 
such a situation

Saphirion's main app is built in R2, and is a very large project, 
so the issue is currently "just" frustrating. Some R3 apps are being 
built, though.

do you have any such issues as i experience?

no, the app we build has about 12-15 windows, and we are using a 
different branch of RebGUI with our own fixes.

You wouldn't see issues with so few windows

if you have that many, it's probably a good idea to build each screen 
on the fly, rather than keeping them all in memory.

most of them are ...

do you destroy one when leaving it?

just close them ... and let rebol do GC on them

You may try to put each windows into separate objects to make all 
the set-words are local. Then set them none manually when the window 
closed then call recycle. This may work?

the problem is that i may not see any benefit until I swtich a few 
100 windows across

jsut a short update: We build our first real-life R3-GUI based tool. 
It's a little thing but needed in a lot of companies. It's a tool 
you can interactively create things like heat-maps with. Heat-maps 
for how your IT system landscape looks like, organizational things 
etc. It's a nested layout created with color-mapping for visualization.

robert, can you post a screenshot from a sample headmap?

nested layout means you are arranging small gobs as grid and color 
them or is it a pixelbased image created on the fly?

We will, screenshot mode not yet working. It's a nested container 
structure and each container either layouts left-right or top-down 
in 1,2,3, ... lines / rows.

It generates pictures like this: http://www.mindtree.com/node/657

ahh, ok grid/cell approach. how many containers in avarage do you 
create for a big headmap?
running fluent?

ok, organigram... thought something like this -> http://www.mathworks.com/matlabcentral/fx_files/24253/1/heatmap.png

The number of levels depend on the stuff you want to visualize. IMO 
for quite complex real-life situations you have about 7 levels.

Than you can color, vary line thick-ness etc. to indicate different 
information.

looking for solution to create a very fine grained heapmap (500X100) 
elements. the only solution for this resolution I have tested is 
pixelbased so far.

a gob apprach would have many advantages but think it's will overload 
R3.

Screenshot of the UI? Your last Twitter message towards the gui was 
related to creating new skin? I expect it was not high priority on 
your list though?

It'll be a while, before I'm available to do any skinning work.

well, skinning work is also dependant upon material systsem, etc., 
which was not done, last time I checked? Is it still so?

Yep. We do it in an non-intrusive way, so the things are decoupled 
from style development.

Robert says not spending time on R3GUI .. so is it now dead?

Or, waiting to see if Carl can fix show stoppers?

That didn't come out quite right. The R3GUI is needed for an inventory 
application, so development will continue for it.

But it sure would help, if Carl just started again.

What are the things blocking progress?

I had mentioned earlier that it would crash due to complex layouts, 
but this is not the case. The layouts can be very simple. For example 
this one:

1. run graphical version of r3.exe

2. load following R3GUI release from web:

do http://www.rm-asset.com/code/downloads/files/r3-gui.r3

3. execute  this simple layout example:


view [tab-box ["tab1" [] "tab2" [] "tab3" [] "tab4" [] "tab5" []]]

And the error lies in ... ?

R3GUI is not abandonned, but only required bugfixes will be done. 
If the situanion with R3 will improve, development will continue.