World: r3wp

Oldes, there is lot of different quirks where the html definition 
doesn't work as it should, especialley between different browsers. 
Or do you want to argue about this? Just check all the html/css quirks 
related websites.

I think most of these quirks are gone with the new browsers. If I 
want clickable floating box of exact size, I will get it in HTML.

No, they aren't gone. If you rely on the implemented 'browser sizing' 
you'll see lot of problems. I don't talk about static pages.

I think the problem is, you are too focused on resizing. If someone 
wants button 50x50, why not to have it.

I really don't want to start it again :) You can have button 50x50 
if you use 'proper styling' if I may paraphrase your sentenca about 
CSS.

BTW our current decissions is:
- style writer sets min/max/init-size
- user can override init-size by specifying a pair!
- dialect errors out of min / max-size is violated

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