World: r3wp

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.

All styles are potentially containers - whether or not they are actually 
containers depends on the style.

You can create your own layout manager styles with little difficulty. 
Or you can create container styles that layout their children in 
a specific way for a specific purpose, like a scroller pane with 
scrollbars. You don't need separate layout manager functionality 
since laying out stuff in a custom way is an inherent feature.

IE9 preview 3 adds support for WOFF (Web Open Font Format). I wonder 
if there is something usefull in such standards, what we could possibly 
integrate to improve fonts?

http://hacks.mozilla.org/2009/10/woff/

my god could it be? we will FINALLY fucking be able to use fonts 
on the web?

AdrianS: as I said in my last message here, "-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 ;))"

By this I meant there will be two default 'layout generator' styles 
GROUP and PANEL but you can create own styles that will generate 
their content differently.

I suppose I just had the expectation that REBOL styles would only 
concern themselves with look and behaviour (group acting as a tab 
group, for example) and that layout would be handled by other types 
of constructs in the dialect, the way I'm used to. As for needing 
hierarchies in Java, these are there in the GUI component declaration 
to match the visual hierarchical arrangement and to make control 
of child visibility, event passing  and layout match what you would 
expect to see coming from such a visual arrangement. If similar control 
can be achieved by REBOL in a different way, so be it.

We are now going to replace VID resizing code with our version and 
adopt some styles to use it. Than some more tests and if all went 
good, we are soon back to style development.

http://rebol.hmkdesign.dk/files/r3/gui/219.gif


Carl's drawing of the R3 GUI/graphics pipeline (posted with his permission).

link broken, here

works for me

henrik's link broken too here ...

I'll cut and paste it here ...

graphic pipeline like ... hum  the rendrering pipeline in my GPU 
?  or just a software like pipeline wich havec pipeline only the 
name....???

http://a-browsertests.s3.amazonaws.com/219.gif

hope that works guys

Did Denmark lose to France in the worldcup?? Is that why you're being 
blocked??

yes, thx

like amount of processing in my rebol ok but one thing ... now in 
day grphical cards are hella weak in 2D rendering and espacially 
under windows 7 they are even slower than a 3DFX voodoo 3 back in 
the days ...

SOOOOOOOOOOOOOOOOO

what i like with carl implementation is that he shows with better 
source code algorithm you improve the rendering queue even if you 
don"t  access the hardware specific accelartion part wich will be 
a pain to handle anyway...