World: r3wp

I want resizing for the desktop, and scaling for devices like Android-based 
phones where you can't necessarily know the resolution/size ahead 
of time.

People can code around the other cases hopefully

These phones are changing screen sizes every release

Babylonians had base-60 numbers, indeed, but the evidence exists, 
that they founded our positional system

Graham, it may work for the desktop, but it's not working for mobile 
devices.

Brain, exactly.

the invention of zero was a considerable breakthrough, taking into 
account, that even nowadays there are people hesitating to call zero 
"a number"

it's a bit, actually :-)

Just read a new Droid review - larger screen than a iPhone 4, less 
resolution. I'm starting to want a device-independent coordinate 
system :(

But iPhone is very consistent. It had the same resolution and now 
it doubled it. Android is almost unpredictable in that manner. Unfortuately.

well, there is the iPad too. I imagine there will be more different 
screensizes in the future.

also now that Microsoft seem to be releasing a new mobile OS per 
week...

Nope, just new form factors. They still only have the 2 mobile OSes.

Plus legacy versions of those two of course.

so do faces adjust for text size automatically??  anyone know?

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.