AltME groups: search

Well, empty rows in the source code are just means to organize the 
text anyway ;-)


Regarding your MIN-SIZE and MAX-SIZE - those aren't shared, since 
I thougth (and still think), that it is necessary to allow for every 
face to have individual MIN-SIZE and MAX-SIZE

Example: it is expectable, that two panels have different MIN-SIZE 
and MAX-SIZE, especially if their contents differ

Of course, some styles might "prefer" to use the same MIN-SIZE/MAX-SIZE 
for all their faces, but it is not a general property.

re min/max-size, here's my take. I don't mind having both, not a 
big deal for me. But - when I tried Carl's examples back then,I tried 
on my nice Samsung FullHD TV. I maximised the screen, and wondered, 
why the heck fields don't resize properly. Then I found out, that 
their max size was set to 900 pixels. I asked Carl - why? And he 
told me, that fields should not be long, or it does not look nice 
anyway. So - as I know myself, my intention for max-size for the 
years to come will always be to cover FullHD displays. But as you 
can see, then it is artificial - I will simply use values, just to 
avoid effect I had with Carl's example.


As for min-size - I was negatively surprised by its removal, because 
I wanted panel of certain min-size to be displayed. But - I found 
there is new item, called initial-size, which fixed the situation 
for me ...

And he told me, that fields should not be long, or it does not look 
nice anyway.

 The problem is that you can't solve the maximum size restriction 
 issue of a nice-looking interface, by using a MAX-SIZE at the style 
 level. Such a problem would be at a higher layout level and much 
 easier for the UI designer to solve at the layout level. There is 
 simply no reason to have it.

Then I found out, that their max size was set to 900 pixels. I asked 
Carl - why? And he told me, that fields should not be long, or it 
does not look nice anyway.

 - This is the main problem I have with VID and the "official" GUI 
 stuff. If I want it that way, I want it. I don't need a framework 
 that makes my life hard. There are zillions of things people want, 
 and others don't like. For commercial apps, we need to deliver what 
 the customer wants, not what we think is best.

And, to do this, all parts of the GUI must be accessible and able 
to describe. Hence, MIN-SIZE & MAX-SIZE make sense on a face level. 
If I need to specify it, at least I can.

Hmm, so I did some tests, and here's my observation:


- I still have to complain, that in order to MAKE PANEL, I have to 
use function MAKE FACE, even if function of corresponding name exists, 
and was made useless for such purpose :-( Easy things SHOULD be easy 
to do


- The suggested code of pan: make-face 'hpanel [columns: 1] is self-explanatory, 
but then SWITCH-PANEL function does not work. And the possibilities 
are:
                     - this function is obsolete
                     - this function was not adapted to new stuff

                     - make-face does not create sufficient/expected output


The problem is in the following code - I have two panels - m = main, 
p = child:


view [m: hpanel [text "test"] options [init-size: 200x200] button 
"switch" do [switch-panel m p 'fly-right]] 

p: make-face 'hpanel [columns: 1]
insert-panel-content p [button "hello"]
view p ;- check it ....

It crashes on switch-panel, because:

>> p/gob/offset
== 571x384

>> margin: get-facet m 'margin
== [0x0 0x0]

>> p/gob/offset: get-facet m 'margin
** Script error: cannot set offset in path p/gob/offset:


So - does make-face create incompatible structure? Is 'switch-panel 
supposed to work? And if not, how do I support those fly effect for 
switching panels? Just don't push me to manually use insert-panel-content 
and tonnes of similar functions?

Could you try following code? You can eventually replace 'vpanel 
by 'hpanel [break-after: 1]. With vpanel, it just causes stack overflow, 
with hpanel, it kind of displays panel, but try to resize the window 
and see the mes ...


REBOL []

do %r3-gui.r3

lay: [

		when [load] do [print "Load trigger!"]
		clicker
		button "Do" alert "Button pressed!"

  button "Big Quit Button" maroon options [max-size: 2000x50] quit
		bar
		text "Toggle button..."
		t1: toggle "Toggle" of 'tog
		button "Set False" set 't1 false
		button "Set True"  set 't1 true
		toggle "Mirror" attach 't1
		toggle "Mutex" of 'tog
		bar
		text "Radios and check boxes"
		radio "Set above toggle on"  set 't1 true
		radio "Set above toggle off" set 't1 false
		bar
		check "Checkbox attached to above toggle" attach 't1


]

child: make-face 'vpanel []
set-panel-content child lay
view child

Is it possible some styles are not adapted well to resizing? When 
I removed 'when style, the space at the top of the panel is not there 
anymore. Then I removed clicker too, upon your suggestion. But - 
when I lower the size of the window, the display is still corrupted 
...

To get that, you need to try xy times. Most of the time I am holding 
down the bottom-right corner, moving randomly the mouse (I remember 
REBOL in the past did not receive updated info about about size, 
unless mouse button is released), and it accidentally can end like 
that. Dunno if any such info is helpfull ...

yep.  but in R3, I can actually see that the window resize events 
are being triggered while we drag the window size.. but for some 
reason they are not being pushed to the handler.

Pekr, regarding your

lay: [

		when [load] do [print "Load trigger!"]
		clicker
		button "Do" alert "Button pressed!"

  button "Big Quit Button" maroon options [max-size: 2000x50] quit
		bar
		text "Toggle button..."
		t1: toggle "Toggle" of 'tog
		button "Set False" set 't1 false
		button "Set True"  set 't1 true
		toggle "Mirror" attach 't1
		toggle "Mutex" of 'tog
		bar
		text "Radios and check boxes"
		radio "Set above toggle on"  set 't1 true
		radio "Set above toggle off" set 't1 false
		bar
		check "Checkbox attached to above toggle" attach 't1


]

child: make-face 'vpanel []
set-panel-content child lay
view child


example - it is incorrect, since you try to give VIEW a HPANEL instead 
of a WINDOW, I suppose, that it was just a test, how it would look?

How is now R2's face/pane, and earlier face/faces replaced? I can't 
see it in the structure. Is that a gob!?

>> help main-pan
MAIN-PAN is an object of value:
   style           word!     vpanel

   facets          object!   [init-size min-size max-size align valign 
   res...
   state           object!   [mode over value]
   gob             gob!      offset: 3x46 size: 572x503
   options         object!   [content]
   tags            map!      make map! [ panel true ]
   draw-result     block!    length: 45
   intern          none!     none
   name            word!     main-pan
   names           object!   [t1]


I really miss the simple aproach of R2 guys. I wish I had a /pane, 
a simple block of stored subelements, accessible via normal rebol 
series functions, so no need for me to investigate the special purpose 
functions. That's what I call simplicity.

Or I have something wrong in the demo code, not yet fully adapted:

view-sub-panel: funct [
	index
	main-pan
	desc
][
	set 'current-panel index
	set-face desc form pick test-notes index
	pan: pick test-panels index
	unless pan [

  pan: make-face 'vpanel [columns: 1 content: pick test-blocks index]
;		insert-panel-content pan pick test-blocks index
		poke test-panels index pan
	]

	set-panel-content main-pan pan
;	switch-panel main-pan pan 'fly-right
]

view [
	title "R3 GUI Tests"
	text (reform ["R3 V" system/version "of" system/build])
	bar
	hgroup [

		; List of test sections:
		text-list test-sections do [view-sub-panel value main-pan desc]

		; Panel for showing test results:
		vgroup  [
			desc: text-area "Please read the instructions below."
			options [
				max-size: 2000x40
				text-style: 'bold
			]

			main-pan: vpanel [
				text "test" ;doc instructions
			] options [columns: 1 init-size: 280x380]

			hgroup [
				button "Source" do [
					either current-panel [
						view-code trim/head mold/only pick test-blocks 
current-panel
					][
						request "Note:" "Pick a test first."
					]
				]
				button "Halt" leaf close halt
				button "Quit" maroon quit
				check "Debug"  do [guie/debug: if value [[all]]]
				check "Remind" guie/remind do [guie/remind: value]
			]
		]
	]
;	when [enter] do [
;		if quick-start [
;			if spot: find test-sections quick-start [

;				view-sub-panel index? spot main-pan desc  ; for faster testing
;			]
;		]
;		;[request "Alert" instructions]
;	]
]
;[reactors: [[moved [save %win-xy.r face/gob/offset]]]]

We can't easily make 50x50 button for e.g.? With Carl's GUI, it was 
really easy - button "50x50" 50x50, but with new gui, even if initial 
size is valid parameter of an option block, the requested size is 
not prserved, as can be seen by simple: view [button 50x50 "test"]


I hope we are not back to nonsense of being more clever than what 
user wants, limiting the size of a button?

I don't agree, and I've also built large apps, both with the VID 
Extension Kit, which supports the philosophy of restrained access 
to faces and RebGUI, where face hacking is necessary. The former 
is significantly easier to work with, than the latter due to not 
needing to be explicit on every single twist and turn. The lack of 
proper uniformity does not leave room for an intelligence beyond 
the style level, and you will not unveil the potential for reducing 
code size, testing times and greater overall consistency and stability.

This is rudiculous - so you have init-size as an option, yet it is 
ignored,or totally twisted, in that regard, that only X axis gets 
adjusted. That simply does NOT work as expected, and if you guys 
refuse to understand, that the freedom of expression is what ppl 
are interested in, then you are building completly different GUI. 
It is supposed to be easily used.

You have min-size and max-size still, right? To support resizing, 
you need to support sizing. But that doesn't mean the syntax is the 
same as in R2's VID or Carl's GUI.

BrianH: the strange thing is, that different color is actually supported. 
It was not with Gab's GUI IIRC, that was even more strict. I can 
imagine the trouble with mateiral system, when you allow simple color 
override. But - how is button's size influencing  or limiting the 
skin system? It has nothing in common imo with Carl's or other's 
version imo, it is just one developer applying his idea. How does 
new system differ to Car's version in that regard? Carl's version 
was supposed to use skinning too, so?

And even worse - if button is not supposed to react to the sizing, 
the size option should definitely be removed, and it should DEFINITELY 
error-out in the dialect level. Why am I supposed to loose my time 
trying to adjust button, seeing the option there, if it is not supposed 
to work?

When I expressed my opinion on Gab's GUI to Carl, I told him, that 
I miss some aspects from easy of use of VID. I can understand, that 
when things get more complex, you have to put some limitations here 
or there. But - it stopped to be a fun. I need a system, which I 
LIKE to use, which is NOT BORING to use. If I want to use boring 
business GUI, I can go to Delphi with its boring the same buttons, 
and I even believe, that in the end it is Delhi, which allows me 
to shape the button WHATEVER size I want.

The worst thing we can do is to let the option there, while not acting 
upon the override. So - if we REALLY want button's size to be fixed, 
the option really has to be removed, and it has to fail on GUI parse 
...

Pekr, if you want ridiculously obese button, just override max-size.

view [button "ok" options [max-size: 200x200]] - does not work. Simply 
imo max-size is not part of the options block, only the init-size 
is ... And - I want it being part of the options, so that I can set 
it inlined, or in options [] block. If not there, it is more complex 
hack we wanted to avoid imo ...

Nothing in R3GUI is one sized. There is max-size (and min-size) limit 
and we can debate if the max-size is big enough or not, but you cannot 
say that big red button is not possible in R3GUI, because that's 
simply not true.

Just changing max-size is not enough, that limits maximum size when 
resizing. What you want is this:


view [button "big" options [init-size: 100x100 max-size: 100x100]]

From the following code - what is in the 'options block, can be inlined 
in the layout, right? But basically using 'options in a layout means, 
you can set any 'facets?

	facets: [
		init-size: 130x24
		text-body: "Button"
		text-style: 'button
		max-size: 230x24
		min-size: 80x24
	]

	options: [
		text-body: [string! block!]
		area-color: [tuple!]
		init-size: [pair!]
		wide: [percent!]
	]

To have it aligned, we would have to have:

view [button "big" facets [init-size: 100x100 max-size: 100x100]]

Or just reverse the meaning in the style:

options: [
		init-size: 130x24
		text-body: "Button"
		text-style: 'button
		max-size: 230x24
		min-size: 80x24
]

facets: [
		text-body: [string! block!]
		area-color: [tuple!]
		init-size: [pair!]
		wide: [percent!]
]


Simply calling style attributes 'options, and inlined settable parameters 
calling 'facets ....

Henrik - what is the difference in not not providing option to set 
a button size, yet like Rebolek showed us, it can be done in the 
options block? I mean - what is the difference for the skinning system? 
And also - button is a rather promitive widget, we don't allow its 
sizing, yet more complex styles as panels can be sized, skinned most 
probably too?

I don't want to hack styles in the R2 way, going style/path way. 
I can see, that those layers are wisely designed, but not allowing 
any size button is imo oversight, and it does not imo break the rules 
you describe in your MS Word TOC example. User is simply not hacking 
it. All I wanted was to "export" max-size, not the init-size.

That's right. But I think it can hardly be much easier than it's 
right now:


>> stylize [big-button: button [facets: [init-size: 100x100 max-size: 
100x100]]]
>> view [big-button "BIG"]

So, I had a look at BUTTON source and button has init-size in options, 
so this is bug and [button "BIG" 100x100] should work. I will fix 
it.

I just have to make my notes to the "button size" thread:


- "We can't easily make 50x50 button for e.g.?" - you can, just respect 
the fact, that every face has got a Max-size, and if you want to 
make something bigger, you need to specify the Max-size

- "you have init-size as an option, yet it is ignored,or totally 
twisted" - it is a resizing rule, that you can resize everything 
only to the Max-size limit; of course, you can make the Max-size 
bigger, but, if you forget, nobody can be cleverer than you are knowing, 
what is the Max-size you want to use

- '   view [button "ok" options [max-size: 200x200]]' - of course 
it works, allowing you to resize the button as specified

- 'So, I had a look at BUTTON source and button has init-size in 
options, so this is bug and [button "BIG" 100x100] should work. I 
will fix it.' - only over my dead body, the basic resizing rule is 
to respect the Max-size

Ladislav - maybe what Rebol thought about was to actually exposing 
max-size in an options block? Is that possible?

Now there is init-size, and my opinion is, that it is confusing, 
if the init-size is possible, yet it does nothing obvious. In such 
a case, I prefer to error-out at layout level, not allowing even 
init-size being specified inline ...

Bolek, I don't understad what 'bug' you found in button??? The init-size 
in options is OK

That is the basic resizing rule - no error, just resize respecting 
the Max-size. The resizing algorithm shall not be cleverer than you 
are, changing the Max-size sometimes, reading your mind.

It is correct that you can't do button 50x50 because the button definition 
is:
	facets: [
		init-size: 130x24
		max-size: 230x24
		min-size: 80x24
		....
	]

So as Bolek said..either make own 'fat-button' style or change the 
size related facets inline in your layout definiton.

init-size should be removed from the options, if it does nothing 
usefull imo ...

without init-size in the options definition you won't be able to 
set the size like: button XxY

On the other hand, Max-size says, what the resizing limits are.

That is the property of resizing - you can resize, but resizing *always* 
respects Max-size

also another possibility is to change also the max-size if user forces 
to change the size using the inline pair!

BTW, if you don't want to have any Max-size limit, you can just tell 
something like:

    max-size: 2147483647x2147483647

, which is exactly as good as "no limit"

facets: [
		init-size: 130x24
		max-size: 230x24
		min-size: 80x24
		....
	]


In above code, I thought, that we could allow setting of init-size, 
which would readjust the max-size .....

Does a style have to have a max-size? I am worried about scaling 
to large screens. I remember that was a weakness of Carl's GUI. I 
know you guys changed the resizing algorithm, but I didn't catch 
what the new algorithm was.

No mind reading, if you want to change the Max-size, you need to 
know, what do *you* want it to be.

Are faces still scaled proportionally relative to their max-size?

by default every style has the max-size set to the 2147483647x2147483647 
value so I think that is enough

Brian: re the "does a style have to have a max-size?" - see my above 
note, how to arrange a Max-size as good as "no limit"

Re: "Are faces still scaled proportionally relative to their max-size?" 
- not at all

Cyphre - without init-size in the options definition you won't be 
able to set the size like: button XxY

You cannot do that right now, so what's the point.

the trouble is, that the max-size for a button is lower, than what 
user might want as an init-size? The "fix" is to allow much larger 
buttons, no? Why does henrik want to prevent that?

Rebolek, my point was we should change the button init code so it 
changes max-size if user specifies the inline pair!

Are faces still scaled proportionally relative to their max-size?

 - no ,this was too confusing in the Carls version...max-size is just 
 simple limit no magic here.

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

it's the size user specified in layout dialect

it's the size user specified in layout dialect

 - if the user specifies Max-size, then I do agree, if not, then there 
 is no reason why to "read his mind"

init-size min-size max-size?

Here are my two proposals:


1) [button "text" 100x100] is equivalent of [button "text" [min-size: 
100x100 init-size: 100x100 max-size: 100x100]


2) [button "text" 100x100] is error, because size cannot be specified 
in dialect.

options: [
		text-body: [string! block!]
		area-color: [tuple!]
		init-size: [pair!]
		wide: [percent!]
	] 


you may specifiy only one pair for a button - init-size, inlined, 
that is ...

So my proposal is:
remove init-size [pair!] from Options

add [init-width [number!]] and use it for changing the init-size/x 
value only

Can't init-size when specified (especially inline) push out max-size 
in both dimensions if it's larger?

Cyphre, so your POV changed from 11:48 where you proposed that init 
code for button should set max-size if user sets size in dialect?

Rebolek - ok, decided - please adjust according to brianH's suggestion 
:-) If init-size exceeds the max size, just adjust the max size, 
easy as that, fixed, not breaking anything :-)

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.

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)

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

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

solved!

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]

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

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.

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

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.

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

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?

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 :-)

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?

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.

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.

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

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

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.

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"]

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