World: r3wp

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'.

Kaj, well, Pekr took up the challenge to rebuild the GUI demo (to 
great effect as we can see), so I don't think it hurts to simply 
ask if there is interest in the community to perform certain tasks.

Biran, re multiple screens...there is no support for that in R3 yet.

Henrik - I can't see a great effect here yet :-)

OK. Darn.

Pekr, there is talk, you report bugs and there is response. That's 
the effect I wanted to see.

Yes, but I fear that some of my requirements, questions, questioning, 
is felt as controversial at least :-)

But generally you are right - I decided to start using the system, 
or there would be no response at all.

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