World: r3wp

http://issue.cc/r3/1837<- maybe you should add the GUI project to 
CC ASAP.

I asked dockimbel about this about a month ago.

Erroring out on size inconsistencies is a proper solution

Been away for a while. As the GUI documentation been produced ?

Regarding the relations between Init-size, Min-size and Max-size:


1) it is possible (using resizing) to specify any size at any time

2) the size specified is used for resizing, but, the Min-size and 
Max-size values (specified either by the style designer, or, eventually 
overridden by the user) are always respected, not triggering any 
error, if the user tried to resize "out of bounds"; instead, the 
limits are just used to keep the size "in bounds"
3) only the ones not knowing the resizing rules may be surprised

What I dislike about triggering an error is the fact, that it introduces 
an exception to the above set of rules.

In my opinion, using a style, the user "automatically" agrees to 
the Min-size and Max-size as specified by the style designer, unless 
he adjusts the values as he sees fit.

I might agree with Ladislav, it just needs to be docced ...

The problem is that a user doesn't see what he is agreeing to, as 
it is elsewhere in the style. *All* users will be surprised because 
they initially don't know the resizing rules, and not getting hints 
is not a good way to learn them

I agree that a system without errors is nice, but then the userfriendly 
alternative is to have true style overrides

Kaj, I agree but, well...

I know, Ladislav's death...

:-)

system without errors is nice

 - system without errors is necessary, I do not want the app to error 
 out always the user pulls the border too far

Then you need true style overrides

?

Logic

I am curious, what do you mean, do you mean, that such overrides 
are not possible?

You are against them

How?

I mean overriding the style in the layout, what you have been discussing 
for a day

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.