World: r3wp

Hello guys, just few notes from my side regarding the layout sematics 
and min/max-size etc:
-the layout will be still as simple as in the current R3GUI

-most of the time only 'style maker' will need to handle min/max/init 
size of the specific style

-by default layout elements have to be organized either in PANEL 
or GROUP structures (though it is possible create your super special 
style for circular layouts or whatever ;))

-at the PANEL/GROUP layout level there will be only three kinds of 
elements:
1) style with absolute size (in any axis)
2) style with elastic size (in any axis)

3) optional RETURN keyword used for line breaking to create variable 
number of rows/cols(default ehaviour is to set fixed number of cols/rows 
for GROUP/PANEL)

-to achieve more complex layout user can redefine min/max sizes according 
his needs

Pekr: the new resizing model is not yet integrated to R3 GUI. We 
are finalizing the prototype so it is fine-tuned.  The integration 
to R3GUI part will start from the next week.

Cyphre ... do you know the answer to my question?

as for why min-max size totally sucks. Who tries to predict, what 
is the correct max-size? I linked my notebook to my LCD TV, and instantly 
the gui looked totally wrong, as the resolution went up to 1920x1080 
(FullHD), but field was set to max 900. Carl told me, that fields 
should not be so long. But - I don't want to discuss it with the 
style author. In such a case, I had to adapt the style to "fix" the 
case ...

min-max = max-size

... but otoh - max-size is something I can easily live with ....

Pekr: the MAX-SIZE is optional. That means it depends on designer 
of the UI element/layout if/how use that.

ok then. Then there's Graham's question towards font  or generally 
UI scaling :-) Will it be possible?

Cyphre, is the layout framework pluggable in any way? Could it be 
replaced with a different model? I'm just thinking how layouts are 
done in Java where there are quite a few different layout managers 
available and one size doesn't have to fit all. Here are some options:


http://leepoint.net/notes-java/GUI/layouts/90independent-managers.html

I think that it might be easier to replace whole VID with something 
different :-) .... or link Core to Qt, wxWidgets, or some other toolkit, 
replacing completly View  .....

well, this is what I was asking about - should the GUI elements be 
tied that closely to how they're laid out?

I am not sure I understand what you mean :-) GUI elements in our 
case are not something which is easily encapsulated in its source 
code and hence can be used with different engine, at least I think. 
But maybe I just don't sufficiently undersand, what "layout manager" 
means, so I will let the question to be answered by others ...

Does the declaration of REBOL GUI elements need to be so different 
from how other toolkits handle them? It just seems that needing to 
have only one way (one layout engine) of laying things out is a lot 
to ask of both the layout framework designers and the users of that 
layout engine.

The only thing I can do right now is to point you to new GUI docs, 
maybe by reading the docs you will understand, how things are layered 
....

http://www.rebol.com/r3/docs/gui/gui.html

It seems from reading:

http://www.rebol.com/r3/docs/gui/faces.html


that you might be able to define a new "layout" function implementing 
a different layout description dialect to achieve a new layout. Am 
I understanding it correctly? Is this layout description dialect 
specifically what the gang is working on?

Apart from the fact that I can't properly answer your question, my 
understanding is, that the team is working on all aspects of GUI, 
in following areas:


- low-level (in C) - new GUI is based mostly on AGG, some fixes and 
enhancements are going to be done. Carl, and Cyphre probably too, 
is also working on HostKit GUI isolation, so that the GUI can be 
fully open-sourced, becomes part of Host environment, and can be 
eventually replaced


- various GUI subsystems are being worked on - layout, resizing, 
keyboard navigation/tabbing/accelerator keys, skinning/themes/materials, 
GUI transition effects, etc.


- GUI styles - new VID is supposed to be released with some advanced 
styles, as e.g. tabs, grid, hopefully tree too, maybe a menu (dunno 
about that one) 


- some other things come to my mind - browser plugins, video codecs 
etc. - good times ahead once we are there, but first things first 
:-)

Sure, I was aware there are other things being worked on, but I was 
asking if the resizing functionality that was discussed earlier is 
specifically part of defining a "layout description dialect" (as 
mentioned in the docs), and, if this is so, do I understand correctly 
that if you want a new layout engine, than it is "just" this dialect 
that needs to be redifined.

'I was asking if the resizing functionality that was discussed earlier 
is specifically part of defining a "layout description dialect"' 
- actually not, the resizing functionality affects the functionality 
at a lower level, the "layout specification dialect" is a layer above 
that

Ok, but does this mean that a new "layout specification dialect" 
would not be able to redefine sizing? It seems that it should be 
able to do so as the sizing of GUI elements is intimately part of 
laying things out.

What do you mean by "redefine sizing"? You want to have the ability 
to redefine (whatever it means) sizing from within the layout = VID 
dialect?

In RebGUI, there were some keywords available, so that you could 
influence things. The same I remember for Romano's sizing model I 
personally tested for him ...

I would think that a GUI element's size is relative to the layout 
model defined by a particular layout implementation - that is, GUI 
elements that are being managed by a grid/table-like layout manager 
would resize differently than those being laid out by a layout implementation 
that "flows" it's managed elements or fixes their positions to absolute 
coordinates.

If you want to do it right, resizing is a fundamental concept. That's 
why we take care that early. It will be used by all styles. Hence 
if you want to replace it, you have to touch the code. The GOB objects 
might look differently, the dialect needs adjustments etc. So, a 
lot of ripple-effects.

IMO making resizing that abstract that you can swap it, doesn't make 
a lot of sense. If it works, I don't see any value in supporting 
several different resizing systems.

We have one prototype resizing 6364 GOBs:

Script: "Resizing prototype" Version: none Date: 25-Jun-2010/16:08:26+2:0
building GOBS 0:00:00.256341
updating gobs 0:00:00.417243
resizing gobs 0:00:00.288457
number of resized GOBs: 6364
resizing time: 0:00:00.283141
rendering time: 0:00:00.693365
resizing time: 0:00:00.315615
rendering time: 0:00:00.726654
resizing time: 0:00:00.289055
rendering time: 0:00:00.676646

Together with Carl the

It's not the idea that resizing is separate from the layout implementation 
that I'm wondering about, it's that the layout implementation is 
swappable. My assertion earlier, that resizing is intimately tied 
to a particular layout implementation, still stands, though. Are 
you saying that you can vary the "layout specification dialect", 
but not have to have a resizing implementation that takes this changed 
layout engine into account?

AGG interface is speeded up. Current gain about 280% faster. As you 
can see the drawing time is about 3 times the resizing time. These 
numbers should become more equal.

What do you mean by "layout implementation"? The VID layout dialect?

Yes, the layout implementation is the code that is behind the function 
"layout" in a face, for example. See:

http://www.rebol.com/r3/docs/gui/faces.html


The dialect parsed by this code is specifically called "layout description 
dialect" in the docs. This is different, as I understand, than VID, 
is it not?

The current VIEW dialect is not changed. So I see both parts as de-coupled.

Within the VIEW part the resizing is a simple call:

handler: func [event] [
			switch event/type [
				down [
				]
				up [
				]
				move [
				]
				resize [
					print [
						"resizing time:"
						dt [
							do-resize win event/offset
							;reflect the window gob boundaries
							win/parent/size: win/size
						]
					]
					print ["rendering time:" dt [show win/parent]]
				]
				close [
					quit
				]
			]
			none
		]

The way I understand it, VID is a superset of the layout description 
dialect. So, to reiterate, if there is such a thing as a "layut description 
dialect" and there could be more than one defined, how come you are 
saying that resizing of GUI elements managed by any number of layout 
implementations is independent of these implementations when, as 
I tried to describe above, the resizing that you should get for a 
GUI element should take into account the "bounds" set by a particular 
layout implementation.

AdrianS: this is REBOL, and it is possible to redefine everything. 
Therefore, your question, whether you can redefine somethig is trivially 
true, whatever that something may be.

VID is a superset
 - VID is a layout description dialect, no superset

Hmm, well words in VID that declare the GUI elements, button, text, 
for example, are not layout specific. If I were to change the layout 
dialect, would these not stay the same? Doesn't this mean that the 
VID is a superset of any layout dialect in that it includes words 
for defining layout and words for declaring GUI elements?

My assertion earlier, that resizing is intimately tied to a particular 
layout implementation, still stands, though.

 - you can assert whatever you like, but it is beyond my understanding 
 why. Certainly, a layout dialect implementation may be "tied to" 
 a particular resizing method, since for different methods you may 
 need different data structures, so what? You can always use different 
 resizing, and if the respective layout dialect is not able to specify 
 all options the resizing algorithm offers (quite unlikely), you are 
 free to change the dialect.

Nevertheless, that does not mean, that if a different underlying 
data structure/interface is needed, you are not forced to modify 
the dialect implementation to be able to couple it with a different 
resizing algorithm, but, that is again a trivial information, that 
everybody understands/knows.

Hmm, well words in VID that declare the GUI elements, button, text, 
for example, are not layout specific. If I were to change the layout 
dialect, would these not stay the same? Doesn't this mean that the 
VID is a superset of any layout dialect in that it includes words 
for defining layout and words for declaring GUI elements?

 - no, this is REBOL, and you can define a totally different dialect 
 than VID, and such a dialect surely does not have to be a subset 
 of VID in any sense of the word

As I see it, your goal is actually different: you would like to have 
a VID-replacement dialect compatible with VID in properties you call 
"non layout specific". Yes, that is possible too, of course.

'Are you saying that you can vary the "layout specification dialect", 
but not have to have a resizing implementation that takes this changed 
layout engine into account?' - certainly, we can do whatever we like, 
especially create two different layout dialects using the same resizing 
implementation, if that is what we wish

yes, this is what I'm getting at - if I were to define a new layout 
dialect could I re-use/take advantage of the code that is already 
written behind the parsing and behaviour of those elements that are 
not layout specific

surely you can, if you want to do that

thanks for bearing with me Ladislav, I keep forgetting that there 
are no sacred words in REBOL

AdrianS, I've worked with Swing and know what you are talking about. 
The equivalent to a Java swappable layout model in the R3 GUI (when 
last I worked on it) is a group style. The "group" and "panel" styles 
are two such grouping styles. More group styles and other composite 
styles can be added. What you request is built into the model already.

If we wanted to, I'm sure VID from R2 could be "emulated" in an R3 
VID face.

Brian, what you're saying though is that a containing GUI element 
is responsible for the layout of it's children as opposed to delegating 
that functionality to a layout manager. In Java, each GUI component 
that can be a parent can have a different layout manager added to 
it,but it doesn't manage the layout itself.

The way that Java does it is unnecessary in R3GUI: For Java, they 
have to maintain an object hierarchy; REBOL doesn't need to do that, 
so even the layout managers are styles. The group and panel styles, 
for instance, are only layout managers and have no inherent appearance 
of their own.