World: r3wp

Do you mean I suggested I was against allowing the user to set his 
preferred limits?

I thought you are against effecting them fully?

No, I was just against breaking the resizing rule #2

That is about effecting user preferences fully

How?

What you are effectively saying is that a userfriendly dialect is 
impossible. I don't think that's acceptable

User can either use the limits, or define different, if he wishes 
so

When a user specifies 100x100 you don't want to execute that

For me "user friendly" means "following simple rules, that a user 
can know"

For me userfriendly means easily discoverable

I do want to execute resize to 100x100, which is done respecting 
rule #2

Yes, so you don't want to draw a 100x100 item

I do want to draw the item resized to 100x100, using the established 
rules

Yes, so you don't want to draw a 100x100 item

see above

Yes, so you don't want to draw a 100x100 item

see above

Yes, so you don't want to draw a 100x100 item

User deadlock

Could you please repeat for somebody not able to remember what he 
read 1 second before?

No

Thanks

hahhaha

the basic question is, what is the meaning of pair! in layout? is 
it size that user wants or is it size that user wants to be used 
for some inner magic?

Yes

If it is not used in a userfriendly way, it shouldn't be there at 
all

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.

Yes, Max.

You can write preprocessor that will convert every [button "text" 
100x100] into [button "text" [min-size: 100x100 init-size: 100x100 
max-size: 100x100] and that's all. But there's strong opposition 
to having this directly in dialect.

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

You can write preprocessor that will convert every [button 

text" 100x100] into [button "text" [min-size: 100x100 init-size: 
100x100 max-size: 100x100] and that's all. But there's strong opposition 
to having this directly in dialect." - it is certainly possible to 
have such "statically sized" style, but that is not what the majority 
of users would need

Glass, for example,  just makes you get *at least* that space and 
won't change the resizing model of the style on its own... you have 
to ask it manually to become static by using other switches.

and frames use pairs for margins.

maybe it can be done using some kind of option, for example [button 
"test" 100x100 #and-i-really-mean-it]

It is quite logical, as far as I remember, you told us, that Glass 
did not have the Max-size at all?

no it doesn't.   Glass still doesn't have the multi-layered sizing 
model of GLayout though, which makes it currently harder to manage 
than it should.

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.

Do you have different panel styles, using different resizing, or 
just one resizing algorithm?

There currently is only one Frame resizing model (which works in 
X or Y).   though in fact, one can tweak the frame's default decisions 
in substyles.


this has been done in the scrollframe which uses a sub frame dynamically 
and renders a bitmap then uses the bitmap in the display.

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?

row/column

though with static size you can get similar results to tabular sizing.

yes, sure, the results frequently look the same

when I say static size in GLass, it just means that it doesn't fill 
the space.   things still align and stack up automatically within 
the frame.

Yes, the same here, when the inability to grow to fill the whole 
"cell size" means, that the alignment becomes visible (left, right, 
or center in the horiz. direction, top, bottom, middle in the vertical)

I am still busy on my business trip, returning home tomorrow. I am 
thinking about producing Wiki article about what I find non optimal, 
or what I don't understand. So far I have gripes with 'options block, 
which does not map directly to facets, but is - artificial. That 
part has to move to declarative style definition, as it influences 
how you use the dialect ....

it may have scrolled out of the way, but there is an R3 GUI project 
in Curecode now.

the screen flashes if we expanded the window - i try hello-worl.r3

ubuntu 10.10