World: r3wp

They are important to discuss and you will not get every wish granted, 
but it's only a matter of seeing the big picture of things.

Brian...I don't have multiple screens so I personally have no high 
priority in this. But this is open to anyone..things to do:

1. do a research of the multi-screen handling under different OSes 
(win, linux, mac)
2. define proper abstracted interface
3. implement specific code for each platform

Cyphre: I thought I am able to initialise the size in terms of min-max 
bounds? But all following buttons are of the same size?

view [button "1" button 180x23 "2" button 230x230 "3"]

So, instead of on an individual control basis (like old Delphi) sizing 
is done on a grid model (like new Delphi), the change coming about 
for the same reason Delphi changed that: Ease of development and 
maintainability?

Half the computers I use are connected to 2 screens: the main one 
and an HDTV. Ususally not the same resolution. And some of the connections 
are occasional rather than persistent.

grid model: Yes, that is a nice thing. But IMO can be done later 
anyway. Not sure we should add this complexity yet. Let's get the 
simple basics clear first.

Panels implement something like a grid model.

BrianH: Henrik explained that reason easily, using MS Word analogy. 
Some users, by tweaking local text, are able to completly ruin the 
styling. So later on, when you want to change something globally, 
you can't. BUT! - properties of buttons are NOT shared yet. All instances 
are separate, so no easy way of how to change all buttons by just 
adjusting one central setting. We have new facility for that, called 
'intern, but it is not much used in the styles. So what is the deal 
with no ability to change all displayed butotns at once? :-)

Isn't following a bug? All three buttons are of the same size, even 
if with different init values? Is that intentional, e.g. resizing 
model adjust them? 


view [b1: button "b1" do [print b1/facets/init-size] b2: button 180x23 
"b2" do [print b2/facets/init-size] b3: button 230x230 "b3" do [print 
b3/facets/init-size]]

130x24
180x23
230x230

OK, so leaving to meet Ladislav in an hour. If one of us does not 
survive, think well about that one :-)

better leave him alive, because he has work for me to do :-)

Cyphre: "In HTML you can also specify values that are not reflected 
in the resulting page so what?" -- which one? What I know, if you 
use propper CSS, you have exactly what you want.

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