World: r3wp

Henrik: I get crashes of R3 when doing following:

>> do %r3-gui.r3

>> do %panels-21.r3 ; close a window, and do the same example again 
- it takes 2-3 runs to crash the R3

Crashes = R3 process disappears?

exactly ...

Win Vista, 32-bit. RMA A110 build, tried with downloaded and also 
on-line r3-gui.r3 populated using load-gui function. Do the script 
once, press some button, close it, do the script the second time, 
press the button - crash ...

stack problem, I suppose.

when I close the window, I expect all objects do exist defined in 
the guie structure? The question is, what does consecutive run of 
the script do to the system then :-)

That is a problem that Ladislav, Cyphre and Bolek are attempting 
to clarify and fix right now.

It seems that the memory can't be recalled back. I just watch task 
list, and I can see that running R3 takes some 2.4 MB, doing an %R3-gui.r3 
goes to some 4.8 MB, doing %panels-21.r3 starts at 7.9, but slowly 
grows to 8.8 MB, pressing some buttons/tabbing/resizing, grows the 
memory consumption to 11.2MB (why? ), closing the window does not 
return the memory back (maybe correct, as the window is just "hidden", 
but still interanlly exists?)


I wonder, if there would be any possibility to "unload" window (layout) 
and/or even to unload the gui?

Is that a resizing bug? I tried to lower the Y size of panels-21.r3 
test window, and got following:

http://xidys.com/rebol/resizing-bug.jpg

Why some buttons got thinner?

so, what? you think, that the buttons are too small?

no, just that on the left-top, and bottom-right are OK, but left-down 
and top-right are thinner ...

And botton-left is vpanel, and top-right is hpanel style ... so I 
wonder how it is calculated :-) If you say it is OK, then it is OK, 
it was just an observation ....

unload" window (layout)" - possibly just by setting the window face 
to NONE. Most of the time, you don't want to do that, so I don't 
think any special functions are needed.

Henrik: OK, noted ...

Pekr, thinner buttons: Good catch. I'm not sure why the height would 
be different for VPANEL and HPANEL, but IMHO, they should not be 
different for any reason.

of course there could be different cell heights for VPANEL and HPANEL 
that I did not notice.

Ok, I see now what it means. That looks like correct behavior to 
me, as you are in the child VPANELs adjusting the vertical min/max 
size of the button. The demo inadvertently uses both child VPANELs 
to define the maximum vertical sizes of the parent VPANEL cells. 
This overlaps the resizing behavior of the child VPANELs, so I can't 
tell from this test, what is causing the buttons to be squashed. 
A child HPANEL that takes up the entire vertical size of the parent 
VPANEL should display identical behavior to a child VPANEL.

Just tested it, and it does, so behavior is correct.

On a side-note: Faces like buttons should not have any flexibility 
in the vertical size. That makes the UI less consistent to look at. 
The smaller the elements are in a direction, the less you want them 
to resize. A horizontal SPLITTER face or a horizontal BAR does not 
resize in its vertical direction.

My problem : solved in A96 by doing 'load-gui first !

Just tested it, and it does, so behavior is correct.

 - Henrik, I don't like any cryptic explanations to what apparently 
 looks like buggy behaviour?

If I read your above explanations, I feel completly lost :-)

The parent "vpanel2" contains 2x vpanel, 2x hpanel. And one of vpanels 
and one of hpanels gets the Y size of button stretched ...

Is there any "debugging" mode, which would allow panel cells being 
displayed? (something as chess-board, or grid-lines, to see the boundaries?)

Sorry, I mistook the third panel for a VPANEL, but that just simplifies 
the explanation that this is not a bug:


1. The button can vertically resize, as its min/max size is not the 
same. This is correct behavior according to the specs of the style. 
This is not the same as saying that this is esthetically sensible 
behavior in the button style.

2. The panel in which the buttons reside can also resize vertically, 
because the button can resize vertically. This is correct behavior.

3. The parent VPANEL, when resized vertically, can resize its inner 
faces to their limits, like an accordion. The limits are defined 
by min/max size. The second and the third panel, which both display 
squashed buttons do this, because their vertical size define the 
vertical size of the two cells of the parent VPANEL. This is correct 
behavior.


To get rid of the problem the button should have vertical min/max 
size being the same. That's all.

A simpler way to show exactly the same behavior is:

view [vpanel 2 [hpanel [button "1" button "2" button "3"]]]

btw: +1 for not allowing buttons being vertically resized as a default 
:-)

btw - I seem to have problem understanding v/h group/panel wrapping, 
when accompanied with integers:

view [hgroup 2 [button "1" button "2" button "3"]]

... I would expect button 3 to be placed under button 1?

possibly a bug, but I don't know. in the code, I can see that HGROUP 
does not use the BREAK-AFTER integer for anything.

while HPANEL does.

vgroup/hgroup are ignoring the wrapping

yes, correct.

to wrap lines in groups, you need to use the RETURN keyword

(documented)

ok, then behavior for HGROUP and VGROUP is also correct.

why is it so? I thought that RETRUN might be here to actually force 
the wrap, but not a requirement, when integer specifying the wrapping 
column/row is specified as part of vgroup/hgroup specification? OK, 
I'll wait for docs to see the explanation ....

force wrap
 - not for HPANEL- there no "wrap forcing" works

while for the HGROUP, you need to use RETURN to wrap lines

That is the difference between HGROUP and HPANEL.

I thought that the difference is in the visuals. OK, so if hgroup 
wrapping is supposed to be done using RETURN keyword, what is the 
purpose of following code?

view [hgroup 2 [button "1" button "2" button "3"]] 


Or is that some left-over from previous implementations, and "hgroup 
2" does not make sense?

the integer is accepted as an option for VGROUP/HGROUP. perhaps that 
is a bug.

I am curious about the docs, as I miss main purpose in difference 
between panel and group. In the past, IIRC, panel and group differed 
visually, and also in default layout orientation, and if it would 
be the case, I don't understand, why group differs in using RETURN 
keyword instead of using integer as an option ...

Well, it's evident from what you say at the end. The flow control 
is the difference between the two. It makes more sense to have two 
general purpose types of mechanisms for grouping faces and afterwards, 
make derivative styles for particular appearances.

OK, so the option parameter of group styles is an ommision?

yes, it does not appear to be used.

iew [hgroup 2 [button 
1" button "2" button "3"]]" - where did you find that?

It is most probably an old version

Guys, time to crank up the volume and build a concrete roadmap for 
the GUI. I have a suggestion to further accelerate the development 
of the GUI: RM Asset will over time require some specific, but complex 
styles, that the community will need as well. We are developing a 
SCRUM tool, which you will need to use as a basis for discussions 
and development of these styles. Consider it also training to become 
a good style developer. For any needs, Cyphre, Bolek, Ladislav and 
I will be available to extend the UI base as needed to create the 
styles mentioned below. We also provide examples, training and help.


Many of these styles are focused for development of particular types 
of applications that open many, small windows inside a large work 
area for flexible construction of data analysis tools and other traditional 
Windows or Linux applications.


It could be a combination of how graphics shader networks are built 
(though without the need for zooming), to regular multi-document 
management. The ultimate goal is to build styles that allow a highly 
user configurable multi-document GUI to be described, using only 
the R3 GUI dialect and some helper functions that we already have.

These styles are generic enough to be usable in plenty of apps.

Inspirations for window arrangements:


http://houdini.dreamerzstudio.net/wp-content/uploads/2010/05/reflectiveShaderNetwork.jpg
http://www.codeproject.com/KB/docview/TabbedMDI/TabbedMDI.gif

Inspiration for segmented area management:


http://www.solidsmack.com/wp-content/uploads/2010/12/modo_501_RayGL_sample_002.jpg
http://jedit.sourceforge.net/jedit-snap-12.png

A list of general styles that definitely are needed:


- Style for doing multi-document window management, using various 
arrangements, window linking features, as borrowed from apps like 
Photoshop.

- Style for segmented area management, editable by users, for arranging 
tool areas, view areas. Segments are adjustable in size. Inspiration 
is JEdit and Modo.
- Multi-document window style, for use in window management style
- Tool window style, for use in window management style

- Tear-off style for toolbars and tool windows, for use in window 
management style

- Regular Windows-style menu bar with submenus, also for right-click 
popup menus.

More specific styles that will be needed later:


- High-performance style for graphing points and curves in a coordinate 
system, with zooming and panning.
- Gannt chart style: http://en.wikipedia.org/wiki/Gannt_Chart
- Harvey Ball style: http://en.wikipedia.org/wiki/Harvey_Balls
- Year calendar style
- Month calendar style
- Week calendar style
- Day calendar style

- MacOSX style tag field: http://kitara.nl/wp-content/uploads/2010/05/31.png

- Console style for input and listing results. This could eventually 
grow into the base for a View based R3 console.

- Highly ergonomic numeric input styles, that support unit conversion, 
inline math.

The question is where to start and what fits with you.


The time table is simply ASAP, and preferrably want some results 
within the next 2 months.


If you are planning R3 apps soon, it would be a good idea to have 
a look at the list to see where you may be able to contribute, as 
the GUI moves to beta status. RM Asset needs to spend time building 
end-user apps for R3 and the GUI is becoming ready, except for the 
above mentioned styles.

First of all you should provide a doc how to stylize basic gui items 
like button, slider, etc.

Btw... the main problem I see is, that current R3 is not able load 
PNG24 image. If I would like to do own GUI, and or game in Rebol, 
I would like to use semitransparent images. (I know that there is 
a lot of people who don't like bitmaps, but I see bitmap usage useful). 
I can load any image to Rebol using ImageMagick, but that is not 
a way we want to go... IM is too large to be used as common Rebol 
way how to deal with basic images.

Good thing on embracing a superwindows concept. I've wanted that 
for many years