World: r3wp

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

Just be careful to make it as simple as possible, because it's already 
a complex concept in itself

Kaj, yes that is correct. My own idea is to simply have behavioral 
variants of ordinary windows with slightly different keyboard navigation. 
With any luck, it can also be usable as a generic window manager 
for a general desktop. Each style can present its own layout mechanism, 
and I expect that the window management style simply provides that.

Oldes, I suppose PNG24 loading are done with media loaders/types 
(?). We need Carl to finish those, but those are not as high priority 
yet for the apps that RM Asset are building. Perhaps they will be.

I know... I just do what I can.. to point out that we are missing 
something, what I consider as a basic functionality.. http://issue.cc/r3/1812

We cannot expect many people starting to use R3 View when they will 
not be able to load basic image.

But the missing doc for the gui is also big issue for me (but it 
was already promised by Cyphre to provide it)

I think this is on its way. It's very much needed.

We will provide a developer guide for styles to get you started and 
some styles are included in the current release as well.

The thing is, the more speed we gain, the faster all this stuff will 
become useable by all of us. And, it's the necessary basics that 
need to be done to make R3 useable for GUI development.

And don't forget to make builds for platforms other than Windows 
available as well.

Yep, we will do as well. OSX and than Linux.

New http://94.145.78.91/files/r3/gui/r3-gui-src.zip


This one seems not to be as stable with the tests, and the style 
browser won't run, but offering it anyway.

The old version from 24-dec-2010 for diff is available at:

http://94.145.78.91/files/r3/gui/r3-gui-src-002.zip

Henrik, could you start a page on DocBase with you plan for R3GUI. 
It will soon be lost if it remain on AltME.

Also - there was plan to release docs, could those be placed somewhere 
too?

if ready, of course ...

Plan: The plan at first is to prioritize what styles mentioned above 
should be written first. It's not a complex roadmap.


Docs: will have to update the status on those, but some are available 
in the r3-gui-src.zip file.

First of all you should sync the host-kit imho.

I've requested it (not my decision).

The host kit should be synced at reasonably stable checkpoints. That 
way the GUI people are free to experiment, and people who are working 
on hosts that don't need a GUI or are using a different one can have 
a base that doesn't change as often and is a little more reliable.

As I can see it, the Carl's A110 is very different from RM's version... 
you can even display image gob in Carl's version.

(can = cannot)

[I also wish Cyphre could comment his code... so far he was probably 
the only one who was reading it, but we should change it if we want 
go faster.]

Right. Carl has been focusing on core issues for the last 3 releases, 
while the mostly unrelated GUI issues have been worked on by RMA. 
This was the best approach for 108-110, but we are due to make one 
of those checkpoints soon IMO.

btw... many host-kit fixes are pretty easy if you know where to look... 
for example to enable image gobs in Carl's host-kit, one must just 
remove the temp_remove and replace:
	int gobw = GOB_CONTENT(gob)->size & 65535;
	int gobh = GOB_CONTENT(gob)->size >> 16;
to:
	int gobw = GOB_W(gob);
	int gobh = GOB_H(gob);

https://github.com/rebolsource/r3-hostkit/blob/4d3bdeaa77cf1ec7c5d97738509ecec4fdf4b7e7/src/agg/agg_compo.cpp#L594


And that's all... I really wonder why you keep the host-kit updates 
hidden. Even Carl was able to put it on github:/