World: r3wp

Graham, they do not. Right now.

UI still needs lot of work.

oh ...

Just keep it in mind please guys!

Actually, it's one of my favourite features :)

Motorola Droid X

Anyone know if one can update the GUI from a network event?

I'd like to know, inter alia, if one can build a progress meter for 
downloads

As for resizing - how much I can influence the scaling aspects? I 
mean - e.g. I have simple reblet, a calculator. Now while it resizes 
buttons etc., what if I want it also to properly scale on large display? 
I mean - making the UI element just bigger, including borders, font 
metrics, etc.?

Does R3Gui have scaleable fonts?

Graham, all your questions: yes.

Henrik - so what happens next? Resizing model is incorporated into 
GUI, and then we can see some beta? Or is it still too early?

Too early I think. I haven't seen the dialect yet.

Henrik, how?

Graham, don't know, but if it wasn't possible, I wouldn't use R3 
at all.

since it's a very basic function

Does anyone know ?

Ladislav - I do understand the need for having vertical vs horizontal 
arrangement (panel vs group). But it is hardly "acceptable", if those 
two differe visually, because then we can't say, that one is the 
opposite of the other :-)

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.