r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 GUI]

Pekr
12-Oct-2011
[7330]
So the GUI we can see in screenshots is modified RebGUI? Looks decent 
enough. Similar skin would be nice tohave for R3 too ....
Ladislav
12-Oct-2011
[7331]
So the GUI we can see in screenshots is modified RebGUI?
 - yes
GrahamC
16-Dec-2011
[7332x2]
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?
Henrik
16-Dec-2011
[7334]
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.
GrahamC
16-Dec-2011
[7335]
Has Carl promised to fix it?
Henrik
16-Dec-2011
[7336]
he has not responded on the bug at all.
GrahamC
16-Dec-2011
[7337]
Must be very frustrating ... and dangerous to base a business on 
such a situation
Henrik
16-Dec-2011
[7338]
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.
GrahamC
16-Dec-2011
[7339]
do you have any such issues as i experience?
Henrik
16-Dec-2011
[7340]
no, the app we build has about 12-15 windows, and we are using a 
different branch of RebGUI with our own fixes.
GrahamC
16-Dec-2011
[7341]
You wouldn't see issues with so few windows
Henrik
16-Dec-2011
[7342]
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.
GrahamC
16-Dec-2011
[7343]
most of them are ...
Henrik
16-Dec-2011
[7344]
do you destroy one when leaving it?
GrahamC
16-Dec-2011
[7345]
just close them ... and let rebol do GC on them
Endo
16-Dec-2011
[7346]
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?
GrahamC
16-Dec-2011
[7347]
the problem is that i may not see any benefit until I swtich a few 
100 windows across
Robert
17-Dec-2011
[7348]
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.
TomBon
17-Dec-2011
[7349]
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?
Robert
17-Dec-2011
[7350x2]
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
TomBon
17-Dec-2011
[7352x2]
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
Robert
17-Dec-2011
[7354x2]
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.
TomBon
17-Dec-2011
[7356]
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.
Pekr
17-Dec-2011
[7357]
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?
Henrik
17-Dec-2011
[7358]
It'll be a while, before I'm available to do any skinning work.
Pekr
17-Dec-2011
[7359]
well, skinning work is also dependant upon material systsem, etc., 
which was not done, last time I checked? Is it still so?
Robert
17-Dec-2011
[7360]
Yep. We do it in an non-intrusive way, so the things are decoupled 
from style development.
GrahamC
30-Jan-2012
[7361x2]
Robert says not spending time on R3GUI .. so is it now dead?
Or, waiting to see if Carl can fix show stoppers?
Henrik
30-Jan-2012
[7363x2]
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.
GrahamC
30-Jan-2012
[7365]
What are the things blocking progress?
Henrik
30-Jan-2012
[7366]
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" []]]
GrahamC
30-Jan-2012
[7367]
And the error lies in ... ?
Rebolek
31-Jan-2012
[7368]
R3GUI is not abandonned, but only required bugfixes will be done. 
If the situanion with R3 will improve, development will continue.
Henrik
31-Jan-2012
[7369]
GrahamC, I think the issue here is that the bug can't be found unless 
Carl provides a debugging version of R3, so we can find where the 
bug occurs, whether it's in the host kit or the core. I can't be 
sure as it's something that was discussed last over 6 months ago.
Pekr
31-Jan-2012
[7370]
Graham - there simply might be errors related to R3 Core, not View 
core, which are fixable only by Carl. I think that Carl could at 
least fix those eventual show stoppers, to allow others to continue 
with R3 usage ....
Cyphre
31-Jan-2012
[7371]
There is definitely 'something' in the R3 Core that crashes the interpreter. 
At the moment it is very hard to track it without the access to the 
sources or having the debug release of the R3 library. (ie. I was 
able to trace the crash using the debug release of hostkit exe but 
the trace ended in the 'hidden' dll part so the hostkit code seems 
to be most probably out of the game here)

 IMO it has nothing to with the graphics part(unless there are 2 separate 
 bugs ;)) as I was able to crash R3 when writing non graphical script 
 as well. The crash is very hard to reproduce as it occurs only with 
 specific form of the executed script. If you change some line or 
 even order of words etc. the script works just fine.

It looks to me  either some GC or other memory allocation leak issue 
and have suspicion it have something to do with the map! datatype 
(but this is just my feeling).
Oldes
31-Jan-2012
[7372]
I can confirm I've seen such a strange crash as well without any 
graphic involved.
PeterWood
31-Jan-2012
[7373]
Does it still crash with trace set on ?
Oldes
31-Jan-2012
[7374]
I don't know... it was after some heavy real job made in console. 
I'm using R2 instead.. it's a little bit slower, but stable.
PeterWood
31-Jan-2012
[7375]
I had a couple of crashes that went away when I set trace on ...they 
were both on OS X and I think are related to memory issues. They 
are still open in CureCode.
Oldes
31-Jan-2012
[7376]
I'm quite used to have several consoles opened which I use for multiple 
purposes and do not close them after each finished script. So I'm 
more affected by these possible GC bugs in R3.
PeterWood
31-Jan-2012
[7377]
Sadly, it doesn't help with debugging.
Oldes
31-Jan-2012
[7378]
Sadly, debugging does not help if nobody is interested.
PeterWood
31-Jan-2012
[7379]
True.