AltME groups: search

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

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.

Hmm, but then we would probably loose flexibility of different layout 
model if those two were identical ...

I simply need to make a block with layout elements a face. Trying 
with make-face, but make-face accepts two arguments - style name, 
and options, I don't know what should I submit for the name ...

hmm, I go the wrong way ... make-face serves different purpose, not 
to insert layout into panel ....

the interface was really nice:

make-panel: funct [
	"Create a panel from layout dialect block and options block."
	style [word! none!]
	content [block! none!] "Contents of the panel"
	options [object! block! map! none!] "Options of the panel"
][

and you made it:

make-panel: func [
	face [object!]
	layout-type [word!]
][

not commented, func instead of funct, removed options, reversed arguments, 
and made it accept face instead of the layout block. You should not 
excuse something by just stating - don't use it, it is just internal 
function ... what if I want to use make-panel?

My question still persist - how do I easily create a panel from a 
layout block? :-) Instead of one nice funcitons, which served well, 
I need to study  different concept, and make-panel is generally not 
usefull to average mortal :-)

MIN/MAX-SIZE: I'm not fond of the idea of having the ability to set 
certain style variables in too many places. That said, setting them 
in styles rather than in layout is a decision that is hard to predict 
the outcome of, when using the styles in different layouts. I never 
really liked MAX-SIZE, but I suppose we can't get rid of it.

Why I'm not fond of it: We return to face hacking like VID, which 
encourages poor layout design.

none of my algorithms have max-size and its never been a problem 
in any layout I wanted to do.

(for a layout fragment)

the problem with max size is scaling the extra-space.  it never ends 
up scaling, quite right.  its better to have some of the things static 
which leaves space for the "space benefiting" areas.


then, whatever would need a max-size, should have a manual resize 
bar (which might be blocked so  but doesn't require support in the 
actual layout)

I've never, ever found MAX-SIZE useful for anything, because it doesn't 
fit intuitively in a layout situation, where there are much simpler 
means to produce a similar result. I suppose it makes sense for Carl 
in his old resize system, where MAX-SIZE was (shudder) tied to weighting, 
which produced some completely unpredictable results.

Ladislav - did not read all your posts here, but as you are here, 
and for me to proceed - how do I "easily" create panel, if I have 
layout stored in a block? Carl's demo uses:

view-sub-panel: funct [
	index
	main-pan
	desc
][
	set 'current-panel index
	set-face desc form pick test-notes index
	pan: pick test-panels index
	unless pan [
		pan: make-panel 'group pick test-blocks index [columns: 1]
		poke test-panels index pan
	]
	switch-panel main-pan pan 'fly-right
]

his

 make-panel used three values. OK, options block is not needed, nor 
 supported right now. Function attributes are now reversed (dunno 
 why, the argument order is not compatible with make-face for e.g.). 
 That is still easily fixable. But now "rma's" make-panel accepts 
 face, not dialect block. I tried to use make-face on a dialect block, 
 but no luck ....

And he told me, that fields should not be long, or it does not look 
nice anyway.

 The problem is that you can't solve the maximum size restriction 
 issue of a nice-looking interface, by using a MAX-SIZE at the style 
 level. Such a problem would be at a higher layout level and much 
 easier for the UI designer to solve at the layout level. There is 
 simply no reason to have it.

btw - I expect that you guys surely know what you do, and so far 
my gui understanding is still minimal :-) But anyway - was there 
really a need to make make-panel internal? Except for the options 
block, I found it nice, that you can easily create panel from the 
stored layout block, just by one function ....

regarding your layout containing the WHEN and CLICKER elements, they 
look like still being incompatible with the current resizing

You can see what I have got resizing such a layout: http://xidys.com/pekr/rebol/messy-resizing.jpg

I think that the trouble is in make-face and how the panel is preconstructed 
.... because when I use the same layout submitted just to view, it 
works correctly ...

so what, when I comment the two incompatible parts of the layout 
out, it looks normal doesn't it?

OK, just try very simple layout:

lay: [button "OK"]

child: make-face 'hpanel [break-after: 1]
set-panel-content/no-show child lay
view child

by resize the view, I mean refresh the layout iteslf.

Yes, it was a test, to isolate the example form layout from the demo 
....

So in your case the example should look like:

lay: [
	backdrop [
		<your layout here>
	]
]
okno: make-face 'window reduce/no-set [content: lay]
view okno

If WINDOW would be just a panel there won't be need for that WINDOW 
style no? :) Anyway, the WINDOW is the base style which controls 
all the content.
The structure looks like:
WINDOW [	; this is the main container GOB
	BACKDROP [ ;renders solid background under the content
		<your layout>
	]
]

re "was told that 'when style is not adapted" - it's not adapted 
to use it with the dynamicc  *-panel-content functions but works 
well if  used in normal layout handling.

As Cyphre explained one concept to me, and because I have some questions, 
I post it publicly, so that others might benefit from the info. I 
was not properly understanding the structure of the panel. Cyphre 
was kind of surprised why do I need to know it, and that I might 
not eventually need it for the layout work, but the truth is, that 
I would like to understand system internals.


In R2, the structure of the face was mostly the same IIRC. And you 
put your elements into face/pane. I found out, that structure of 
face might be different for various styles. I hope I am not wrong. 
And in such a case, I suggest to document particular style fields, 
so that one does know, what does it serve for. That might be really 
good for programmers ...

Now I have following points to think about:


1) in REBOL we often don't user conventional naming, but if we would 
use it, then probably 'locals? would be a better name?
2) it is a logic value, why 'names, and not 'names? ?

3) for the instance locals, we use name 'intern during the style 
creation, so why not 'intern?

4) I was really so used to the 'pane (or container in other environments), 
that so far I don't like 'content, and I don't like referring to 
the name referenced faces by style/names/a. So, if my understanding 
is correct, and /content just stores the dialect (not reduced?), 
then why not:

face/intern?: true
face/pane/a, face/pane/b
face/facets/layout?


The thing is, that it is still difficult for me to understand the 
role of a gob! Because gob has a pane, and the concept of gob, multiple 
gobs, and faces organising gobs, made the concept messy in my head 
:-(

what is actually being stored in panel/gob? And what is panel/draw-result? 
And is face/facets/content just a layout dialect stored, or already 
reduced?

sorry, but having built "large apps" and for clients, this freedom 
is very necessary.  


if you don't use it that will make the gui generally better, but 
there is always a time when its required and it has to be possible.


what VID lacked had nothing to do with styles and looks.  it was 
the fact that everything under it was insufficient at best... layout 
sucks, event system sucks, dynamicity sucks, no way to switch stylesheets 
on the fly, no locale, etc.

the best VID users built stylesheets as a lib and then used that 
directly with the least inline styling possible.  but you always 
require to tweak things here and there.  even when the layout resizes 
on its own

When it becomes possible, people use it and then over-use it. Thereby 
we get incorrect methods for building proper layouts and we can't 
go beyond where we are in intelligent handling of a layout.

The current design is supposed to allow non-GUI-designer programmers 
to specify layouts. Even if you are both the layout programmer and 
the style designer, the work is supposed to be separated. For that 
matter, a proper layout dialect for the types of apps that the R3 
GUI is made for (not games) should be portable to other device form 
factors, accessible, etc. So if you need to be a theme designer, 
do it in the theme section of the app, not the layout. And if you 
need to be picky about the styles, do it in the style section of 
the app, not the layout.

Or more direct question - how does button, with its border and gradient, 
differ from e.g. even more complicated style as panel for e.g.? And 
panel has border, and gradients too. While panel can be sized in 
a layout as an option, button can't

The current design is supposed to allow non-GUI-designer programmers 
to specify layout

 - no, it is apparently not. Layout user wants 50x50 button, and can't 
 have it.

Layout user, is not probably going to do his own styles.

aha, that is another thing to understand. When I looked into button 
source, I found there 'options. I thought that those options describe, 
what parameters I can set inlined. And it may be correct. But - now 
we have layout level word 'options, which is completly different 
thing :-(

From the following code - what is in the 'options block, can be inlined 
in the layout, right? But basically using 'options in a layout means, 
you can set any 'facets?

	facets: [
		init-size: 130x24
		text-body: "Button"
		text-style: 'button
		max-size: 230x24
		min-size: 80x24
	]

	options: [
		text-body: [string! block!]
		area-color: [tuple!]
		init-size: [pair!]
		wide: [percent!]
	]

discrepancy in the naming

 - you're right, most of the names are from old R3GUI and may not 
 be descriptive enough. I hope we can change it with your help. OPTIONS 
 in layout is used to override FACETS which may seem confusing.

exactly. But the tricky part is as follows - I like having 'options 
in the dialect level, and I am kind of used to have to call style 
attributes a 'facets ..... I would have to think for a while, if 
we can accept following convetions:


- options - used to set style properties, either in the style itself, 
or in the layout dialect

- facets - special purpose properties, which can be used inline in 
the layout level


I think that it would work for me, and that we would have it aligned 
nicely that way. I am just not sure Carl or other guys are ready 
to give-up on facets name being a general attribute/property of the 
style :-)

The difference is applying meaning at the correct level, the layout, 
dimensions, colors, skin information at the style level, where it 
belongs.

Oldes, for layout, span, etc. This is covered by the resizing engine.

I think that basic DOC style can be really simple and that it just 
will parse makedoc format to R3GUI layout.

Now there is init-size, and my opinion is, that it is confusing, 
if the init-size is possible, yet it does nothing obvious. In such 
a case, I prefer to error-out at layout level, not allowing even 
init-size being specified inline ...

So as Bolek said..either make own 'fat-button' style or change the 
size related facets inline in your layout definiton.

it's the size user specified in layout dialect

it's the size user specified in layout dialect

 - if the user specifies Max-size, then I do agree, if not, then there 
 is no reason why to "read his mind"

Right. So it looks like Pekr wants to be a style maker, but for some 
reason is doing it in the layout block instead of with stylize (or 
whatever it's called)?

I am OK with min-size and max-size being a little harder limits, 
if the reason they are in the style is because of hard visual limits 
(size of contents and such). The limits on the size of button seem 
a little arbitrary at the moment though. Then again, I keep reading 
articles about applicatons and web sites not working on different 
form factors because of hardcoded limits in their layouts, when their 
styles should be adaptable to match the form factor. This is why 
we are trying to cut down on this stuff in the layout dialect.

Think of the layout dialect as HTML with no formatting, and all of 
the formatting in the CSS. Does that make sense?

if min-size: 1x1 and max-size: 21177172727x217722172727

 ....then your button will have tendency to resize to monstruous sizes 
 in the layout.

There was also one proposal, to rename options/facets:


- the naming is reversed - in style, you use options for inline parameters, 
whereas in a layout, you use options to set facets


- I understand Carl and maybe others would not like to give up on 
facets being a name for properties/attributes, but ....


- I proposed to rename it, so that options in a layout = options 
in a style, and for inlined style definition we could use facets, 
or inlined name.

What do you think about it?

I mean overriding the style in the layout, what you have been discussing 
for a day

when a concept of default size is there, that is usually what you 
want the pair to be.  when it goes beyon min or max bounds, usually 
you want to push these to at least match the default size...   the 
developper is expressly asking for an adjustment to the default.


the thing is that when a widget is in an auto-resizing layout, asking 
for 100x100 might not actually give you that size, because all the 
widgets are subject to the layout in which they are displayed.  in 
row/columns, you will be subject to equalizing other lateral sizes 
in the list and may be given more space in the longitudinal size, 
such that in fact, your button may be larger than what you asked 
for.


the only way to force a 100x100 button is for the gui to support 
static sizing within a dynamic layout, or support max-size and set 
it to the exact same as default size effectively making it a static 
sized button.

just sharing my 15 years of experience building/analysing dynamic 
resizing layout engines.

in GLayount, max-size is sort of automatic.  there are two sizing 
values, one for filling, one for stretching. 


its very effective in making sure that only things which benefit 
from extra size, actually get it, and makes everything neatly aligned 
with virtually no need for any manual sizing control in the layout.

because all the layout is a network of nodes, you can really do funky 
stuff... I plan on making a demo of such things as snapping overlays 
to edges of other widgets.

Does the Frame resizing model use a kind of "tabular layout", or, 
is it more like the hgroup/vgroup styles, where only the rows/columns 
are maintained, but not both at the same time?

I would also like style 'options block handling formalized, moving 
it to the style level too. We have on-* actors there. The more stuff 
we move there, the better. That way it will be easier to build the 
visual IDE tool imo ....

I am talking about the following code, hopefully it is that:

	append panel/facets reduce/no-set switch layout-type [
		panel [
			[
				break-after: any [
					all [
						in panel/facets 'break-after panel/facets/break-after
					]
					0
				]
				pane-align: any [
					all [in panel/facets 'pane-align panel/facets/pane-align]
					'left
				]

Pekr, values that are specifiedin OPTIONS field in layout by user 
are set in the face/facets context.

Pekr, regarding your OPTIONS vs. FACETS naming. I don't see any problem 
here. It's normal, especially in Rebol, that  word symbols can be 
used differently in different contexts:
in style context - the OPTIONS means 'inline options'
in layout context - the OPTIONS means 'face options'

Also from the beginner POV...it is easier to understand word OPTIONS 
in the layout dialect than FACETS no?

I think I understand the difference, but I was not easily able to 
see what is what, unless I studied it more deeply, and unless Ladislav 
told me during our meeting, that layout level 'options does not necessarily 
directly map to face/facets ....

Pekr, you said "layout level 'options does not necessarily directly 
map to face/facets"...that's why I don't want to rename OPTIONS to 
FACETS in the layout block. Also so far you are the only one who 
has problem understanding the 'options in layout vs. 'options in 
style definition and in fact you haven't proposed any concrete solution 
(evenin your CC ticket).

I'm not saying I'm against reasonable change here but since there 
is no good viable solution(and noone except you cares) we should 
 either wait until it pops out from someones head or just let it 
be as it is now.

pekr, short story: you want the OPTIONS word in the layout block 
to be FACETS instead?

IMHO, if OPTIONS in layout were to go, I would replace it with WITH.

I'm not sure if the direction is possible other than by simply doing 
it with layout, where you can flow faces in a particular direction, 
but ordering by specifying a number should be possible.

what about left-to-right guis? But dunno if we should care about 
those rare countries to support? :-) Or does layout allow already 
different than left-to-right setups?

in R2, I just do:

stylize [lab: label right]

view layout [across lab "name: " field return lab "last name: " field 
return button button button]

BTW, you can make a similar layout using hpanel as well. Are you 
able to do it, Pekr?

a similar layout
 = "a layout similar to the one I described above using HGROUP"

I think we should be rather careful about adding skin options directly 
in layout. It is really not meant to be there. Once we go there, 
we can't go back and we'll be back in the old VID face hacking mess.

Henrik - it is not about adding them into layout. You can as well 
add it to the options block, which is part of the layout too. It 
is simply about following aspect - are we able to have just ONE style, 
which draws borders, or it does not? Does not it create many variants 
for draw blocks, or other complication for material system, etc.?

To Pekr - here is a layout you might not know how to lay out:

stylize [lab: label [align: 'right]]

view/options [
	hpanel 2 [
		lab "name: " field
		lab "last name: " field
	]
	hpanel [button button button]
][break-after: 1]

The reason why I might be interested in inmplementation detail is, 
that maybe I will be style author too, and hence I would like to 
know, how things get complicated in the low level. So in your above 
example - what does stylize do? Does it create internally named label 
style, to keep its visual configuration somewhere? And then during 
the layout phase, you would have to check on nesting, and use  those 
internal styles in the low-level?

I think (and maybe I am wrong), that even with VID we kind of had 
cascaded styles. If you needed different style configuration, you 
used stylize, and stored new config under different name, e.g. H1, 
H2, H3, LAB in above example, etc.


While CSS allows you to use just one name, and multiple styling set-ups. 
The question is here, how you identify it in the layout flow, what 
set-up should you use, and if it would be obvious. In CSS, you have 
ID, CLASS helpers ...

I mean "if it would be obvious looking into the layout source code"

CSS is clearly much more flexible in setups. You use tree of definitions, 
which are then applied in particular cases in document hierarchy. 
 If I am not mistaken, right now we don't have no easy way, of how 
to make e.g. first button in a last row of the panel e.g. red, unless 
you first define red button, and use it in the source of the layout 
:-)

Cyphre - I can simply imagine, how we extend stylize to allow such 
definitions. But - in terms of html, you have IDs, CLASSes, and you 
have also the document tree, so you might know, where to apply which 
part of an CSS. What I can't imagine is - we have layout flow ... 
and no ID, CLASS definitions, we also don't keep tree information 
of the layout (faces), or do we? So how do you instruct, in your 
layout, that first button in the panel should use button-red definition? 
Just curious about what possibilities there are :-)

Henrik - ok, so to be clear - show me possible stylize definition 
of a button variant, and how you refer to it in the layout code?

There is a slight discrepancy in the syntax of stylize and view. 
Not saying, that they should be identical, just a food for thought:

stylize [my-button: button [facets: [text: "Pekr!"]]]

view [
   b1: my-button
   b2: button options [text: "Henrik!"]
]


1) 'Stylize could theoretically use the same syntax as 'view? So 
the code above could just be:

stylize [my-button: button options [text: "Pekr!"]


That would make it more (almost) compatible with the layout definition


2) Currently set-word inside the stylize defines a new style (class), 
whereas a set-word inside of 'view, defines a face name = ID. There 
is no simple way, of how to resolve that, maybe something like:

stylize [
   my-button: button options [text: "Pekr!"]

   button options [text: "Henrik!" name: b1] ; no set-word, so probably 
   a problem syntaxwise. We simply can't style particular named face?
]


view [ my-button b1: button] ; b1 kind of simulates ID, inherits 
from stylize definition


Of course, it all depends how far do we want to go. We can introduce 
completly different semantics to the stylize function, even a complete 
selector behaviour from CSS, if there is a need ....

the method I posted is exactly what you need to do in order to allow 
such a change

. Not sure - my idea was to use only "Button" name in the layout, 
not my-button, and diversify upon e.g. where the button is placed 
... but otoh even  in CSS/html, in most cases, you have to specify 
class or id, and hence my-button is kind of equivalent - you have 
to declare the special case. But - not sure all aspects of CSS are 
usefull to us.

Cyphre - what will layout be good in next version? To preconstruct 
GUI, not displaying it?

yes, mostlt...but you should be able to pass LAYOUT result  to VEW 
function as well without any problem

so we are going back to view layout [], or not necessarily, and layout 
is just a helper to prebuild a gui?

it doesn't matter what way you use...even if you use view [...] the 
equivalent of 'layout function must be called internally

so to clarify: you will be able to  write  view layout [...] OR view 
[...] , depends on you.

I prefer that max-size have some meaning. So if the size is set outside 
of max-size, the size should be constrained to max-size. That is 
the whole point of having a max-size setting in the first place. 
If a style has a max-size setting below max-int/max-int it should 
be there for a reason, and max-size can be overriden explicitly in 
the layout so it doesn't constrain unnecessarily.

it shoudn't be an error.  popping errors in gui code is generally 
pretty evil if it can be prevented...  its better for the gui to 
look weird than the interpreter to jam for an unknown reason.   the 
possible layout screw-up will be incentive enough for the bug to 
be fixed.


a logging system could help us identify where the engine "thinks" 
there might be problems...

a debug switch which compiles warnings like this would be nice.

in glayout I had a lot of these issues to manage, and generally, 
I always had some part of the setup func which would normalize all 
the values to layout function expected behaviour.


this allowed voluntary programmatic side-effects, but not thru the 
layout dialect.


for example, all sizing values where clipped to be at least as large 
as min-size as the first step.

Something like this?


view layout [button "Help" with [font: [size: 16 colors/1: 255.0.0]]]

but how would you define, what layout engine should be used? We have 
two, no? panel, and group ... and their respective vertical vs horizontal 
variants ...

Pekr, by only allowing a single face (with any number of subfaces) 
inside such a frame style, layout would not be an issue.

#[[Pekr

I think that worse problem for me is how currently resizing is behaving 
in above mentioned styles

Pekr]] - resizing is behaving as it should. The problem is just that 
Bolek specified that the vertical size of the text is "unlimited" 
for resizing purposes. That is causing the layout to look ugly.

Some comments:

-the TEXT style in the release has incorrect resizing settings so 
it makes layouts that are being resized ugly. We'll fix that.


-regarding the introduced and discussed:  options [box-model: 'some-word] 

The defined word! symbol should specifiy box-model preset. By 'box-model 
preset' we mean group of facets attributes that affect the box-model 
settings of the specific face/style. So this option is IMO correctly 
named.

Currently the box-model option was added as temporary solution to 
the PANEL style only. But in the next release it will be possible 
to set it on any face in the layout or style definiton. Also we'll 
add basic set of such box-model presets that will be part of the 
system by default.


-ALIGN vs. HALIGN: yes, we borrowed the terms ALIGN/VALIGN from HTML(but 
note, it is used also in R2 font object and in R3 para object) . 
As people today are familliar with it and have it 'wired' in their 
heads using the same name could avoid silly bugs in their code.

I presonally don't think this must be consistent with names of styles 
but if majority people insist of such kind of consistency we would 
probably need to unify also the align word in the PARA object as 
well.

Why not leave panel and hpanel as synonyms, and group/hgroup ?


It's entirely possible, but would that not make layout code harder 
to read/understand?

Dunno where to chat about Jocko's demo, but as Henrik suggested to 
move here:

- some parts are sluggish


- for Rebolek - you can look at Demo/To-Do section - Jocko outlined 
some changes he made to some styles. His demo does not work with 
current RMA release if I am not wrong.


- we should generally start to think, about how to "unload" certain 
GUI parts from memory. By just clicking here or there I got from 
11MB to 38MB of memory usage. In some old GUI I used, it kept track 
of windows, and those were GC'ed when closed. In REBOL, if I am not 
mistaken, after the layout, faces objects are defined, and there 
is no automatic way of how to "undefine" them and free the memory. 
So my question is - will that be addressed, or is user responsible 
for the resource tracking? And is it even adressable?

Rebolek, yes, I was just teasing. Perhaps it's not a bad idea. VID 
itself also has a default direction that it lays out in, which can't 
be seen in layout code.

Using max-size: -1x2 still requires you to know the Y value, if you 
are using it as an option in layout, so you need to study the style 
code to know it. Hence the need for RESTRAIN.