AltME groups: search

Resizing news: the latest state is, that there are two "container 
styles", the first one being a group - a layout in which graphic 
objects are arranged into either rows or columns, not necessarily 
into *both rows and columns* at the same time, the second one is 
a panel - a layout in which graphic objects are arranged into both 
rows and columns at the same time.

The style uses a LAYOUT-MODE attribute, which determines the preferred 
orientation.

The http://rebol.hmkdesign.dk/files/r3/gui/214.pnghas LAYOUT-MODE 
set to columns, while the http://rebol.hmkdesign.dk/files/r3/gui/225.png
has LAYOUT-MODE set to rows.

(depending on LAYOUT-MODE)

The columns or rows are "internally" implemented as lines, and if 
you switch the LAYOUT-MODE you just tell the resizing algo to handle 
the lines as rows or as columns

It may sound a bit cryptic, but LAY simply exactly states that we 
are going to somehow layout the elements

Summary: in a group, objects are arranged into lines, that are handled 
depending on the LAYOUT-MODE as either rows or columns

It does not probably matter. What is being shown in those images 
is probably the layout mechanism of the group style, right?

Well, group style layouts things in either rows, or columns, depending 
upon layout-mode argument. The panel style layouts styles in both 
directions?

that is, not "layouts styles" - the panel layout lays the objects 
so, that you always *see* both the columns as well as the rows

Not Board though, it focuses too much on the flatness and not any 
more on the layout.

Remember, whatever name we choose will be written out a lot. The 
two main layout styles will show up a lot in user layouts. So short 
is good.

Yes, you can make your own styles. But most code sill be just layouts 
and behavior, which are separate from style creation. You don't do 
derived styles in the layout itself.

I agree.
But I have some ideas for making a very general layout mechanism.

It looks to me that the layouts above can be expressed by two nested 
levels of arrangement.

Remember, the goal is to be able to write layouts with as little 
style information as possible, just the style names, data and options. 
Keep the need to specify sizes to a minimum, colors never. The layout 
dialect is for app programmers, not graphic designers.

To give you an example, I would be the target market of the layout 
dialect. I am not a graphic designer, nor should I have to be. And 
you don't want me picking colors.

(It seems dubious to me that a graphic designer wouldn't be interested 
in layout, but I can understand the merit of separating the specifications 
for colours and the specifications for layout.)

Here's the notes I tried to post before when you were discussing 
LAYOUT-MODE:

HTML refers to this as "inline" (and the line may wrap).
I used 
grid-face/LAYOUT-DIRECTION: 1x1  and  
grid-face/MOVE-FIRST: 'horizontal
in my old GRID style.
	do http://anton.wildit.net.au/rebol/gui/demo-grid.r

But the parameters needs to be clarified some more.

Academic papers published as PDFs often have two columns of text.

That means a single line of text wraps horizontally, vertically, 
and horizontally again.

Eg. The line of text first wraps (horizontal) when the right hand 
edge of the first column is reached,

then, after many rows are similarly wrapped, when the bottom of the 
first column is reached (vertical wrap).

All of that occurs again for the second column (and perhaps more 
columns) until there is no more room on the page,
so the final level of wrapping is horizontal. 

So I would have 
	face/WRAP: [horiz vert horiz]

which specifies three levels of wrapping, horizontal for chars, vertical 
for lines of text, horizontal again for columns (so that the next 
page is underneath the first one).

To put pages horizontally, you would just have 
	face/WRAP: [horiz vert vert]


Or you could specify an extra level of wrapping, eg. so that you 
could have groups of two pages shown horizontally
	face/WRAP: [horiz vert vert horiz]


The direction for each level of layout should be specified to correspond, 
eg.
	face/LAYOUT-DIRECTION: [1 1 1 1]
which would give left-to-right and top-to-bottom.
(Use -1 for right-to-left  and bottom-to-top directions.)

Keep in mind that is the layout dialect that shouldn't have colors. 
Styles are specified with a different dialect, and they can have 
colors in their draw blocks.

So I apologise. I'd prefer to get back to the layout discussion above.

I had actually wanted it to be even more strict, that styles should 
not be possible to set appearances for in layout at all. But I can 
see that colors have snuck in, anyway.

If it is in the layout dialect, I mean.

Carl (who has many other fine qualities) sucks at color choice (sorry). 
So I have him (and me) in mind with the layout dialect not specifying 
colors :)

I remember that the solution we came up with during the initial design 
phase was to have colors in the layout dialect be specified functionally, 
like window-background and such. This was not implemented at the 
time (we never got around to it). Was it forgotten?

On naming, I think PANEL is too general and doesn't describe the 
layout behavior. I could live with it though. 


I agree that TABLE should be saved as that is the common term for 
the spreadsheet model. GRID was used for that for a long time, and 
still is sometimes, but GRID could also be good when thought of as 
a canonical grid layout. GRID-LAY, CANON-LAY, or TABLET aren't too 
inspiring either.

Of an interesting note, the new Google Images uses exactly the layout 
being discussed above.

its almost impossible to reverse layout when it is expected (and 
much easier to compose) going down.

cause that is how layout is performed.

top down for layout and bottom up for draw

Top down for layout and text gobs, bottom up for draw? That confusion 
is the declarative overhead I mentioned earlier.

So IMO in both case there needs to be done some additional changes 
so images/fill-patterns, vectorial text etc. will be rendered correctly. 
And I feel such changes fit more to some 'layout code functionality' 
than being part of low level rendering.

In other words it is much easier to write simple coordinate conversion 
function in REBOL for such needs.

The reason is simple: if we add that at low-level we'll slow-down 
the whole code even if you use the default coordinate system.

Just a quick thoughs so I'm open to any better ideas.

however the context privacy feature should be kept. it's very useful 
with multiple instances of the same layout.

inside the layout, you are fine:

view [f: field button do [set-face f "boo"]]


Outside, you need to go through the GUIE context, but I don't recall 
the path.

an alternative, probably a more sensible one for large GUIs is to 
reference the faces from within the layout and then using functions 
externally:

boo: func [face] [print get-face face]

view [f: field button submit 'f boo]

fortunately we can set a large number of faces at once, if your layout 
is properly arranged.

a discussion we had yesterday about how to produce that layout. the 
SPACING parameter would produce a space around all red squares equal 
in size to the spacing between the squares. this has been changed, 
so that space is not produced and one must use PADDING instead.

PAD is a style, so it produces an object which then moves the next 
faces one grid place forward, just like any other style.

This layout:

view [panel 2 [button pad pad button]]

...produces this:

http://rebol.hmkdesign.dk/files/r3/gui/235.png

Yes, and this none could be skipped by the layout parser.

I misunderstood your suggestion, Robert. I thought you were talking 
about adding an IF command to the layout dialect, not to the code 
in the ().

but since none can be used sometimes for part of the layout I thought 
it would be easier to parse if we used something else

The IF command in the dialect would get rid of the COMPOSE and do 
this: view [button if (condition) button button]

That is what I meant by a Parse-like IF. Possibly not doable in the 
layout dialect, due to overhead.

I don't like it though. It you add conditions to the dialect it will 
make it too easy to put semantic code into a layout that is just 
supposed to be for display.

In fact why don't we consider using parens to switch out of the layout 
dialect instead of making us use compose'deep

Again, there should be no DO dialect code in the layout dialect. 
Unless actions are called, the layout dialect should be declarative, 
not procedural. That is what makes it safe.

It's a DO action. The code in its argument only gets called as a 
result of the action, not at layout time.

view layout [
	button 
	do [ this at layout time [
]

Oh, you meant do [ this at layout time ]. It doesn't do it at layout 
time, only when the button is clicked.

the dialect word 'do switches the layout parser to the do dialect

Likely not in the R3 GUI. We did a lot of work to separate layout 
and behavior.

Not unless it has been changed recently. According to the design 
of the R3 GUI, DO doesn't switch the layout dialect into DO dialect 
mode, it declares an action for the button (in your example) to perform 
when clicked.

The code performed by that action is evaluated by the DO dialect, 
but it is evaluated at runtime in response to the action being triggered, 
not at layout time.

My example is for R2 ...  there is no 'layout word for R3

Ah, wrong group then. The layout dialect is implicit in R3's VIEW 
function now, not implemented by a separate LAYOUT function.

What does this do ?

view layout [ button "test Brian" do [print now ]]

Get rid of the call to LAYOUT, and it will create and show a layout 
with a button titled "test Brian". When that button is clicked, the 
button's action will be triggered, and the result of NOW will be 
printed to the console.

The parens don't affect the layout, just the data that the layout 
contains. No control flow.

anyway, Vid has the ability to switch dialects at gui layout ... 
but as r3gui .. i don't know...

Actually there are several changes by Bolek and Cyphre, that I've 
not yet studied, but much of the work that was handled by LAYOUT 
before is now relegated to PANEL and GROUP, which is why we talk 
so much about them and not a central LAYOUT function. They call various 
subfunctions that specifically focus on creating faces and laying 
them out and resizing them.


So the styles themselves are capable of custom layouts and resizing 
mechanisms and also mechanisms such as face init and triggers. So 
that means you are no longer a "slave" of the LAYOUT function.

That's also why:


1. I was talking a while ago about that you can build a style that 
emulates VID, complete with a dialect, or replace the layout mechanism 
with your own, by rewriting PANEL or GROUP or adding new panel styles.

2. That whenever you want to do a new thing, you should make it as 
a style. That's where you start.

** GUI ERROR: Unknown parent style for: LAYOUT-USER

scroller: I'm not sure it makes sense to attach scroller to various 
styles inside the layout. You may not realize it, but that code is 
very complex to write and also difficult for the style writer to 
use. It's easier to write styles with scrollers attached in a fixed 
way and much easier to maintain.

Patrick, can you post the layout you are using?

There are some more details: The reason would be to no longer have 
it be unclear from source what the layout direction is. Prepending 
V and H removes that doubt. Also you would no longer need to write:

panel 0 [...

to get a horizontal panel with an infinite amount of columns.

just write:

hpanel [...

Just thinking loud: What if, since as you say, panels use a grid 
layout, you just name them GRID? With ROWs and COLUMNS being horizontal 
and vertical subtypes of GRIDs. Like PILE and LINE could be subtypes 
of GROUPS. GOUPS and GRIDS finally being subtypes of PANEL. I don't 
think the behavioural difference between "your" groups and panels 
is communicated very well by these names inherited from Carl's work.

Originally, GROUP and PANEL were same styles with different orientation. 
That has changed and now GROUP and PANEL are two different layout 
engines. So we need to come up with names for horizontal and vertical 
variations of GROUP and PANEL. So far we've got H*/V*, but if there 
are better names, it can be changed.

Also the names GROUP and PANEL can be changed if someone can come 
up with a better word to describe the layout engine (like GRID for 
PANEL, but I think GRID should be reserved for true GRID style).

The problem is we are trying to eliminate the need for using column 
definitions in case of one row/one column layout.

Currently you would write:
view [
	panel 1 [
		panel [
			button
			button
		]
		panel 1 [
			button
			button
		]
	]
]

or in case of 'inverted defaults' for panel without any number:

view [
	panel [
		panel 2 [
			button
			button
		]
		panel [
			button
			button
		]
	]
]




Which would make two panels in one column. First panel would have 
2 buttons in one row and second panel 2 buttons in one column.


I personally think this description of the same layout would be more 
readable:

view [
	vpanel [
		hpanel [
			button
			button
		]
		vpanel [
			button
			button
		]
	]
]


So the key is to improve readablility of the layout definition in 
cases that will be used from 99% IMO.

Anyone have better solution?

Well, Pekr, if writtent this way, I wonder whether COLUMNS 1 could 
be understood as "a layout having 1 column", instead of "a layout 
having 1 row"?

we still talk mostly about naming in regards to orientation. But 
what about GROUP or TIGHT (if TIGHT style still exists), which use 
different layout mechanism? If we would user COLUMNS/ROWS, it would 
not work as far as naming is concerned ....

Back to ACROSS and BELOW, then? Those have never been misleading, 
they just weren't styles in R2/VID but layout directives which were 
lost after the layout phase finished. And make the difference between 
PANEL, GROUP, TIGHT behaviour an attribute to them, with reasonable 
defaults. Would that even work?

layout [
	below [
		across [ ... ]
		below [ ... ]
		below 'tight [		; TIGHT behaviour
			button
			button
		]
	]
	across [
		...
	]
]

Izkata: understood, and how about the Hpanel? There you want the 
layout proposed by Pekr?

The number for rows/cols still isn't intuitive to me ("2 columns" 
or "2 rows" would be clear). As far as ordering, it would be nice 
if you could lay out your code so it "maps" visually to the layout.

Not his layout, but the idea of "I have n groups".

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

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.

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

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

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.

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 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>

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?

it's potentially a rat's nest to stick our fingers into, but from 
a simple developer's starting point, it should work without doing 
anything to the style or the layout. that's where I think the design 
should start.

Current list of tags (subject to change):

; set at stylize time
style-tags: [
	internal		; the style is intended for internal use
	panel			; the style is panel of other faces
	compound		; the style is a compound of part styles
	field			; the style is a field with editable text
	state			; the style is a user interactive state changing item
	action			; the style is a user interactive action item
	info			; the style is an indicator
	tab			; the style is part of tab navigtion

 auto-tab		; the style automatically tabs away on a specific event
	select			; the style contains user selectable text

 keep			; the style retains highlighting and caret after unfocusing
]

; set at layout and any other time
face-tags: [
	default			; the face is the window default
	focus			; the face is in focus
	disabled		; the face is disabled
	frozen			; the face is frozen
	dirty			; the face is dirty
]

; set at window creation time
window-tags: [

 form			; windows containing a validatable form or other field or 
 state faces

 inform			; windows containing only text or images and no validatable 
 faces

 popup			; windows containing a menu or selection, which when interacted 
 with, results in immediate return of a value
]

Pekr, does it work with the spacebar? There could be a collision 
when using Enter, because it may be used to confirm the default button, 
which may not be the same one as the one in focus. That depends on 
keyboard shortcut layout, though.

I'm not saying is should be same as above. I'm just trying to find 
out the layout dialect based initialization for all the 'modes' so 
it is easy to use for people. I understand the SHOW-FACE function 
is not a problem to use in both variants once the layout is already 
'running'. I worry about the init part though...

well, we don't need to do it that way...it could be just used as 
'gob/offset setter' duirng the layout parsing...no need to ster the 
value afterwards.

I didn't mean that. Of course you hide something when it is set to 
0x0 size. I was asking if that was how you set something to be hidden: 
setting it to 0x0 size. That might have interesting effects on the 
layout of its contents when it is unhidden, while a hidden property 
would not.

So my and Ladislav's decission so far:

-use SHOW? hidden | visible | ignored and optional GOB-OFFSET in 
OPTIONS block during layout initialization only (after the face is 
build the valueas are unaccessible in this form)

-use SHOW-FACE face hidden | visible | ignored function in all other 
cases when layout is already initialized.

About showing faces: In R2 I found it quite annoying not to be able 
to create an image of a layout without viewing it on screen first.

If I did things like set the face size to 0x0 or move the faces outside 
the window bounds, clipping would introduce artefacts (black regions 
not supposed to be there) in the image created by TO-IMAGE.

So, in R3 at least, I'd like to be able to create an image of a panel 
layout in R3 without first viewing on screen.

I think I thought that an UPDATE FACE function, being similar to 
SHOW FACE, except without the final copy to the window buffer, might 
be what's needed.

I don't agree with having 0x0 as hidden. It is an implied state, 
that would occur any time the X or Y size becomes zero. There are 
behavioral issues to consider, such as, whether you want to obtain 
data from the face, using GET-PANEL, or how tabbing and disabling 
behaves with a zero sized face. If the layout is dynamically created, 
so that a face is inadvertently presented as zero-sized, you will 
get topological side-effects.


For animation, you would have a start and end position. Animations 
should not express anything about face states. Only dimensions, offsets, 
transparency, colors, easing are relevant with animations.

that a face is inadvertently presented as zero-sized

 - this may occur, should a style implement its own layout engine, 
 which is possible to do.

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?

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.

What does it mean?:

- Embedded GOB containers in text
- Gob - Renders GOB embedded in text


I can't imagine, how this stuff works, and is organised. However 
- i am buying a book on text typography and layout, but so far from 
what I have read, you basically divide page into columns or boxes 
section, you can link them, those columns/rows have those typical 
margins, origings, etc. set, but we are talking DTP tools here :-) 
Are we getting something similar here?:


It is possible to have multiple paragraphs defined in one Rich Text 
block. Paragraphs are positioned one ofter another vertically. Vertical 
space between pargraphs is defined by PARA/INDENT/Y values. Use COLUMNS 
command(see below) to define how many paragraph columns should be 
used for paragraph layout.


... some wireframe model showing the terms on the image would be 
usefull ... but maybe others will understand, what's your idea ...

Pekr, sorry, I forgot to upload the paragraph layout example image. 
Just reload the page it should be there.

yes, text selection should work in multi-paragraph layout

Oldes, imagine you have gob of 200x300 size but you want to have 
layout of two paras in total size of 400x600. In such case you'll 
set MARGIN 400x600 to ensure the paragraph layout is filled inside 
this space. And then you can use SCROLL to move the content inside 
the gob.

CSS is VERY bad at text layout.  I would not want use that model 
for a rich text editor... really it would be aggravating.

It's not the final location. It's a test, to get feedback on the 
layout of the source files before we release to the final location.