World: r3wp

Note, I am not saying that's what I expect, but rather it's to visualize 
how the orientation affects the order. 


Something else to think about is whether you can, or should be able 
to, invert H and V and have the layout still work.

invert H and V and have the layout still work

 - that is generally not impossible, of course, but it is against 
 the readability requirement Cyphre mentioned as his reason why he 
 proposed Hpanel and Vpanel styles instead of having panel #H panel 
 #V

In order to transpose the grid, you need to know the number of items 
in the opposite axis of the panel.

In order to be able to show the grid you need to know the number 
of items in both axes, but that is not the problem to compute

This is more a dialect design problem, i.e. what will be more "intuitive" 
for the user

I don' t know how the row/col value overrides, or avoids conflicting 
with, the width of the face, or if the parent' panel is sized as 
a layout, based on sub-faces and you can't change it. A pair! would 
have the same problem, if used to explicity state both the number 
of rows and columns.

Yes, and I think the grouping of the data in the code layout is the 
driving force there. The number tells you how many "groups" (H or 
V) and then you enter items so they are contextually related in the 
code.

A pair! has two more problems, actually:


1) it is redundant, since knowing the number of cells, and just one 
of the dimensions, you can easily compute the other one; such a data 
redundancy is, in databases, called "denormalized data" and is undesirable

2) the user frequently wants to give just one number, assuming, that 
the other is computed every time some cells are added or removed, 
thus, not wishing to give the value for both dimensions

1) Eliminating redundancy is not the same as normalization. 

2) "the user frequently wants to..." This is speculation, isn't it? 
:-) 


I could just as easily say that the normal case is that I know how 
I want my canonical grid laid out, and I may want to specify some 
cells to be empty.

the user frequently wants to...

 - that it is not a speculation, I was told by Cyphre that there are 
 at least two users frequently wanting that

And while we can say that normalization's goal is to eliminate redundancy 
in storage, we can also say that it doesn't solve the redundancy 
problem at all levels (e.g. when joining data). There are also reasons 
to denormalize. It's interesting to think about though.

specify some cells to be empty

 - the number of cells is given by specifying the graphical objects 
 in the layout; the software can count them and know the number of 
 cells; if you want to obtain "empty cells" just put in some Pads

...that there are at least two users frequently wanting that

I stand corrected. :-)

Pads - Yes, Gabriele's design had an elegant solution for this IIRC.

the last time I worked on a grid, the sizing values where autocomputed 
and shared accross rows and columns.

when one cell changed a single X or Y value, all the other cells 
of the same row or column where aware and could update on their own.

Please, keep in mind, that this discussion is not about computation! 
This is about the dialect, which must not be redundant to not allow 
to specify impossible combinations

the overall sizing algorithm took care of "collateral" effects.

but the *design* of the layout engine provides logical clues into 
how it should be expressed in terms of a dialect.

Max - Which brings up the point of what controls the size. Do the 
sub-faces control the size of the panel, or does the panel control 
the size of the sub-faces?

Ladislav - Yes.

if the system uses the whole column to resize things horizontally 
(width affecting word-wrap and thus controls height indirectly) then 
the height should be automatic.

should
 == "could"

to me a lot of this discussion resembles HTML table box model discussion... 
maybe you should look into how they solved the various issues.


for example, cells can "span", which is an elegent way to solve the 
gaps in cell data.

Yes, I think tables are key here (tbl did spanning long before HTML 
I believe :-). Do H and V panels help that much, e.g. to reduce clutter? 
I imagine the team talked about that, and whether just a TABLE would 
be enough.

Gregg: regarding the difference between Vpanel and Hpanel. Pekr wrote 
something that makes sense to me, showing how a layout should look. 
You wrote a "source code", which does not allow me to "see the look 
you want", in fact.

Do you want in Vpanel the second element to be below the first one, 
or to the right of it?

(assuming both positions are available)

My example was not to show what I want (thought I said that), but 
to show that the orientation affects how you might lay out your code, 
to group things contextually, and how that relates to making it easy 
to add new items.

Aha, so you want the layout to be always related to the source, i.e. 
the second graphic object to be to the right of the first one? (assuming 
that the position below the first one as well as the position to 
the right of the first one are both available)

I'm trying to think of a good scenario where I would use Vpanel. 
The first thing that comes to mind is a multi-column file or directory 
listing. Is there a particular need it's meant to fill?

Yes, sort of. Like switching between across and below today so I 
can group related things together in the code.

Myabe it's on my mind because I had to do some SQL recently, where 
the insert statement was one col per line, and lots of lines, followed 
by the values to insert, also one per line. :-\

Hmm, but that does not lay e.g. the multi-column listing in the expected 
order, where the second one is usually below the first one, not to 
the right of it

Yes, sorry, don't look at my example for that, look at Daniel's (Izkata). 
Mine was not done to show that.

Aha, OK, Cyphre and I were wondering...

Right now, my mind wants to say vpanel = below, hpanel= across.

Regarding Graham's note about RebGUI - Cyphre checked it, and there 
we can use just a PANEL (which corresponds to the above proposed 
HPANEL, as it looks), and an AFTER X value, which corresponds to 
HPANEL X specifying the number of columns, not the number of rows, 
as Gregg/Izkata seem to propose for HPANEL

New R3 GUI which fixes a few styles, like text list, although text 
list will eventually be rewritten:

http://94.145.78.91/files/r3/gui/r3-gui.r3


Style browser now shows style options, alphabetic sorting of style 
names, face debug option (currently broken in the R3 GUI):

http://94.145.78.91/files/r3/gui/style-browser.r3

I think that having VPANEL and HPANEL is very helpful. I have buiilt 
a few screen layouts with Flex which has VBox and HBox which layout 
the elements they contain vertically and horizontally respectively.


Typically, I have used VBox as the "outside" container to enclose 
a number of HBox.


In Flex, both VBox and HBox are descendants of  Box which includes 
a direction property, the default of which is horizontal.

I find it much clearer to write:
 <VBox>
  <HBox>
  </HBox>
  <HBox>
  </HBox>
</VBox>

than

<Box direction="vertical">
  <Box>
  </Box>
  <Box>
  </Box>
</Box>

Just to throw another idea in .. yahoo grids - they analysed common 
grid useage and then you specify which grid pattern you want to use 
but of course you have to know what those patterns are.

So, what's the outcome? :-)

Peter - thanks for mentioning the approach, I think, that in REBOL 
we can define it analogically

Pekr, if noone can come with something better that HPANEL, VPANEL, 
HGROUP and VGROUP it's going to stay this way.

I'm going to rephrase my idea: In general it could be possible to 
use blocks of blocks inside the layout. This would make it easier 
to generate layouts and not care about style argument lengths:

view [[button button] [field field]]


Of course you can't split a style in two blocks, but this wouldn't 
be needed anyway:

view [[button] [do [something]]]


This is similar to how gradients can be put in blocks inside DRAW. 
Is there anything that would conflict with that?

Yes, Henrik, your idea looks interesting as well

Henrik, good point. We need to consider "generate by script" in all 
dialects etc. IMO being able to use even more abstract descriptional 
approach and generate on the fly is a key pattern.

yes, but ads lots of visual clutter, especially if the code is short.

Pekr, no it doesn't, because you are free not to use it. The point 
is that auto-generated layouts would be much easier to make and rearrange.

When Cyphre did the grid for RebGUI for me, that is what I suggested 
to him - to enclose column VID description into block, so that you 
can reorganise it easily .... so I am OK with that ...

Status:


Not much new. We are discussing how to formalize actors, as this 
is only half-done. Other than that, it's simply bug grinding of styles.