World: r3wp

No, it was exactly against this.

He calls it mind reading.

we should change the button init code so it changes max-size if user 
specifies the inline pair!

 - I am against that change, you don't know (not being able to read 
 mind) what is the Max-size user wants to have anyway"


My take is - if the max size is lower than requested size, then let 
be requested size be the max size. What could be the harm? Or do 
you think that in such a case, user could complain, that his button 
does not resize to being even bigger?

I do not expect that every user that will write [button "text" 100x100] 
has studied source or documentation to understand how resizing works 
and what max-size mean, they probably just want to have their button's 
size to be 100x100.

So either the code should set all size to 100x100 or it should throw 
error and not allow setting size like this at all.

nothing else makes sense IMO

agreed.

I think I will survive it ...., I am just "Figting" for the average 
future user ...   :-)

While Cyphre and I are fighting for that same user a few minutes 
later when they need to make a change :)

I don't understand how you can fight for something other than Pekr 
when he just repeated your suggestion.

And skipped over what I wrote earlier, and later.

Ok, so I see only two options here:
1) remove all 'inline pairs' from all the styles definitions

2) define 'generic rule' during the style initialization: max-size 
= max(init-size, max-size)

great,so now we're back to exactly what I wrote half an our earlier 
:)

and the winner is?

and because Ladislav doesn't like #2, we should probably go with 
#1.

if we do #1 we don't solve this case:
button options [init-size: 50x50]

Rebolek - I am not sure Ladislav does not like #2

I would rather hear it from him though. He might have a really good 
reason to choose one or the other.

button options [init-size: 50x50 max-size: 50x50]

solved!

We should remember that one of the goals is to minimize the number 
of times we see sizes specified in layouts though.

Yes, so when we remove that option, we minimize that number to zero.

Rebolek, but every 'average user' will be hit by this no? That's 
the same as the question "why button 50x50 doesn't work?"

Not zero because it can be in the options block as you wrote above.

To be fair, we could say, that if I specify button 5x5, what to do 
then? Should min-size be set to min(init-size, min-size)? What if 
user is an idiot, and sets the size to -5x-5? :-)

I still don't understand the difference between these two:
button 50x50 options [max-size: 50x50]
and
button options [init-size: 50x50 max-size: 50x50]

Cyphre, when somebody's fiddling with options block, they must understand 
at least facets. When writing code like [button 100x100], you do 
not need to know anything about style internals.

The only thing which is clear is, that it can't stay the way it is 
....

why is the first 'worse'  than the second?

first, it's some mixed style that really looks strange

second, it somehow suggest that [button 50x50] alone is useful

Guys, I just read through all this and I'm confused a bit why it's 
so complicated.

which is not

init-size: 130x24
max-size: 230x24
min-size: 80x24

When this is on style level, just writting button should give me 
a button with these facets.

Bolek ,ok, then let's remove all the inline pairs! and tell the 'average 
user' there are no sizes. Do you think it will be better for him?

definitely better than setting size to 50x50 and having button whose 
size is not 50x50

If I write: button 50x50 and don't violate min-size, max-size OK. 
If I violate one, we can throw an error: "Hey, please explicitly 
override the master-mind of the style-creator for min-size / max-size. 
And know what you do.

Robert - and? :-) I started with an argument, that when I was porting 
the demo, button 50x50 is allowed, but does not deliver what user 
expects, so we either remove it, or adapt to allow it, which might 
not be so easy to stay consistent.

min / max-size are IMO for style writers first. And can be overrided, 
with a not so easy syntax, by programmers.

ah, yes, that might be good way - simply put, user could be warned, 
something is not optimal ...

init-size is mostly what 95% of all users want to set without caring 
about the rest.

I am OK with min-size and max-size being a little harder limits, 
if the reason they are in the style is because of hard visual limits 
(size of contents and such). The limits on the size of button seem 
a little arbitrary at the moment though. Then again, I keep reading 
articles about applicatons and web sites not working on different 
form factors because of hardcoded limits in their layouts, when their 
styles should be adaptable to match the form factor. This is why 
we are trying to cut down on this stuff in the layout dialect.

The limits on the size of button...

 - Well, Lad, gave the 2^32-1 values that mean no-limit. Needs to 
 be specified by style writer than.

Robert, I agree...the question is should we remove the iniline pairs! 
? I don't care but Pekr insists it is a problem.

I surely don't want min/max limits to be removed - they are imo usefull, 
and needed for resizing model to work ... I wanted to solve the case 
when you specify init-size out of bounds ... Robert's solution looks 
ok to me ....

the question is should we remove the iniline pairs! ?

 - I don't understand what is exactly mean by "inline pair"? The ones 
 I can write in the dialect?

Think of the layout dialect as HTML with no formatting, and all of 
the formatting in the CSS. Does that make sense?

I want to be able to write: button 50x50

Cyphre - you misinterpret me a bit - on one hand, yes, I think those 
are usefull to have for occassional GUI hackers, for the fun factor. 
If user is an idiot, and wants to define each button differently, 
so be it - there is analogy with inline CSS style. But if we allow 
it, the behaviour should deliver it ...

this sets init-size without touching min/max-size.

yes, I meant now you can write: button 50x50 but Pekr doesn't like 
it won't deliver the 50x50 size...I don't care here.