World: r3wp

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.

Why doesn't it deliver the 50x50 size if the init-size is set to 
the value?

In HTML you can also specify values that are not reflected in the 
resulting page so what?

Robert - the problem was with the demo - I ported button, specifying 
50x50, but it gets not used, as the max size is 24 on Y axis. So 
I was confused, and though that something does not work. The result 
is in agreement with how the system is implemented, but anyway - 
we will get "huh, what?" and ppl being confused, if we don't adress 
it somehow ...

Why doesn't it deliver the 50x50 size
 because the button is limited by min/max-size values.

Should that 50x50 be cut down to 50x24 then, Robert, or should max-size 
be changed to 230x50?

And if min-size: 1x1 and max-size: 21177172727x217722172727

Max size changed. Or warning printed to the console :-)

I don't see a problem.

if min-size: 1x1 and max-size: 21177172727x217722172727

 ....then your button will have tendency to resize to monstruous sizes 
 in the layout.

I agree with Robert - style defines init-size, max-size, min-size. 
Just predefine max size to cover at least fullHD resolution, and 
be it :-) The button will still be properly sized by init-size, if 
user does not override it?

the style-writer of button needs to specify min & max values as they 
are meant: absolut minimum this style will work. IMO for a button 
with 1 clikc areas it is 1 pixel.

I thought there is a strategy to the sizing, and that styles somehow 
have some sizing tendencies ... I remember some spacers, etc., but 
dunno how new resizing is implemented ...

Cyphre, yes, this is the default property of buttons: Resizes to 
the maximum you can imagine. If you don't like it: stop it by giving 
you own max-size

As said, the style writer can specify these. For a button the max-size 
is most likely less: 1980x1024 for example.

Robert - Cyphre probably meant that button will overtake your screen 
area :-) But it can't no? There are some rules, how particular styles 
divide the spacing/sizing during the resizing?

The goal must be that style writers select min / max-size values 
that will cover 99% of all use-cases. For the 1% rest, I can override 
it anyway.

I think the button have to have lmmited it's height as it is now. 
The 1% is exactly what Pekr is doing :)

How are multiple screens handled?

I agree with the heigth for buttons, maybe double heigth than default 
height.

Anything else is exotic and should be explicitly overriden by programmer.

There was also one proposal, to rename options/facets:


- the naming is reversed - in style, you use options for inline parameters, 
whereas in a layout, you use options to set facets


- I understand Carl and maybe others would not like to give up on 
facets being a name for properties/attributes, but ....


- I proposed to rename it, so that options in a layout = options 
in a style, and for inlined style definition we could use facets, 
or inlined name.

What do you think about it?

Kaj, perhaps this is the same misunderstanding as for host kit work. 
It seems that many times, when Carl or RM Asset offers a task to 
the community, the response is negative.

Yes, that's what I mean: it's unreasonable to expect this

And IMO this approach fits with Henrik's wish to restrict things 
(which would be through the default values) to save you time and 
hassles. If you override it, well do it, and take the whole responsibility 
on your own.

I still don't understad why is this soo big issue here. Simply if 
you don't like what you get with the current button just do:
stylize [my-button: button []]

view [
	my-button ...
]

Yes, no problem. But just to get a different init-size it's a bit 
overkill, or am I missing something?

Cyphre - now you replied to yourself - what is the difference to 
button vs my-button? The only one is, that what I wish is now covered 
by my-button. But what was the basic refusal to allow buttons being 
freely sized? Some MS Word like analogy of later on having to change 
each button separately in your app, if we allow user each button 
to be completly differently sized.

this is not because of different init size but because of different 
size limits.

It seems that buttons can be freely sized within their limits. So 
the question is what are the default limits and why?

Would it not be better to focus on flow and how a style will fit 
in a cell, rather than impose the size of the button on the button 
itself? We are used to assigning size to the button directly instead 
of posing restrictions on its surroundings, because that concept 
did not exist in VID.

Right, that is exactly what I was talking about.

Brian, correct. Pekr, either you as user will understand and agree 
the rules or you need to lear a bit more and become 'style tweaker'.