AltME groups: search

Our GUI will not be a toy. It's not for people just starting to play 
around. R3 needs a full blown commercial & enterprise app enabled 
GUI framework. Otherwise it will stay a toy no one cares about.

Robert - agreed - as much as there is a way to override some "defaults" 
by the stuff I want, I am mostly OK. Of course I still care for things 
being easily useable, if possible ...

Once again - simple things should be simple to do, and simple even 
in my code - when I make-panel, I make panel, not a face. When I 
switch-panels, I just switch panels, so no need for user to care 
about panel content handling funcitons imo ....

OK, I will adapt ... the intention is to make demo working on RMA's 
GUI. We will see, how it turns out down the road ... I am slow, because 
I still have little knowledge of GUI itself, pluse I am really not 
a programmer :-)

Carl's comment after a "preliminary peek": "It seems that the design 
is going well, and this team is very REBOLish in their methods and 
concepts.  So, I am not worried."

I am still probably not understanding, how to properly use panel-content 
functions. Second consecutive run of following code causes a stack 
overflow ...

lay: [button "OK"]

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

Err, that [columns: 1] is an anachronism, we replaced it by [break-after: 
1] (for a hpanel, break-after specifies, how long the rows are, while 
for a vpanel, how long the columns are)

Ladisla - thank, that was it. I mean - break-after fixed it.  With 
above - columns, to simply reproduce it, just view child, close the 
window, and call view child once again ... it breaks to console after 
a while with stack overflow. Well, now I know that 'columns is not 
used anymore, but you might try to look at it, if you have time, 
to see why it causes stack overflow ...

Well, I stop my tries to port a demo now. My take is, that following 
primitive code should work easily, when repeated for the second time, 
but it does not:

lay: [button "OK"]

child: make-face 'hpanel [break-after: 1]
set-panel-content/no-show child lay
view child


My take is, that either make-face is not creating a structure needed 
later, or 'parse-panel is buggy, or I don't know what :-)

** Internal error: stack overflow

** Where: reduce switch parse to-text reduce parse to-draw all update-subgobs 
fo

reach update-subgobs show-native show-native show-native show-native 
show-native

 show-native show-native show-native show-native show-native show-native 
 show-na

tive show-native show-native show-native show-native show-native 
show-native sho

w-native show-native show-native show-native show-native show-native 
show-native

 show-native show-native show-native show-native show-native show-native 
 show-na

tive show-native show-native show-native show-native show-native 
show-native sho
w-native show-native show-native show-native s...

I am just wondering - it will cause a stack overflow at each show 
call. I wonder - show is not called the first time? How is that it 
crashes the second time?

Petr, do you have a screenshot?

We have the box-model like CSS, so there are a lot of different spacing 
things that can be defined.

this is just first prototype of first section. I have problem making 
a panel, to work reliably ... I don't understand the space at the 
top of the panel, that is still probably buggy on my part ...

(that was a note to Pekr)

You can see what I have got resizing such a layout: http://xidys.com/pekr/rebol/messy-resizing.jpg

that may not help, I probably have a bit newer code

or, maybe I use a different system

stackoverflow: We are taking care of this with Carl at the moment. 
We have a test-case where I can reproduce the problem.

This is the code:

code: view [
    title "Opinion Survey"
    text "Do you want programs to be easy to build?"
    hpanel 2 [
        label "Answer:"
        hgroup [
            radio "Agree"
            radio "Disagree"
            radio "Not sure"
        ]
        pad
        check "I'm a programmer."
        pad
        check "I am also a REBOL expert."
        label "Name:"
        field
        label "Comment:"
        area
    ]
    hgroup [
        button "Submit" submit http://www.rebol.net/cgi/submit.r
        button "Reset"  reset
        button "Cancel" close
    ]
]

loop 10 [
	do code
]
print "all code passed - no crashes"
halt

regarding the above Show-native issue - that is a do-once-only-code, 
as I see it. If you run it only once in the console, you don't get 
any stack overflow

aha, you see? my wrong understanding :-) I thought calling such a 
show causes infinite loop :-)

as a temporary measure, you could replace the

show-native: :show

by

unless any-function? :show-native [show-native: :show]

It works. But it was not enough to just change the view-show.r3 code, 
and call it after do %r3-gui.r3, as the initial redirection will 
remain. A bit tricky, as there is no script to build new r3-gui.r3 
from sources, and sources are collapsed, but I managed it to change 
:-)

afaik, its within the port mechanism, when events are created, for 
some reason, the resize events don't end up at the port handler.


I remember trying to fix this in the host-kit and didn't find the 
solution.  I tried a few things but nothing worked... so I moved 
on but that's like 3 months ago already so the details are fuzzy 
in my mind.

Pekr, if you want to make e.g. a HPANEL with a given content, you 
can use the MAKE-FACE function anyway:

child: make-face 'hpanel [break-after: 1 content: [button "OK"]]
view child

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?

Yes, it was a test, to isolate the example form layout from the demo 
....

Is 'window type just a panel? Or special window gob?

If WINDOW would be just a panel there won't be need for that WINDOW 
style no? :) Anyway, the WINDOW is the base style which controls 
all the content.
The structure looks like:
WINDOW [	; this is the main container GOB
	BACKDROP [ ;renders solid background under the content
		<your layout>
	]
]

and if I don't specify backdrop? Aha, so window is not just anonymous 
parameter to make-face, but a regular style?

yes, window is a style

btw - I don't like the name make-face, to make a window, which is 
a special style. We have:

make-panel
make-face
make-style


in the above case, window, is a widget for me. I really don't know, 
if we have terminology OK here. I simply don't regard instantiated 
style, being a face? Or is it aligned correctly?

You do have just MAKE-FACE, which makes a face for you, as specified

I simply don't regard instantiated style, being a face?

 - why not, if we "borrow" the class-based OOP terminology, then styles 
 may be considered analogies of classes, and faces may be considered 
 analogies of instances (objects) of their styles

Pekr, using only the MAKE-FACE for making faces was a step for simplifiing 
things. No need to know any other functions for that.

the style has to be specified as a word, if that is what your question 
was about

it was the data argument, instead of fiddling with composing a block.

Aha, you meant options? They can be supplied as #[none] meaning "no 
options supplied", or as a map! as well

you should use a map when you don't like a block

The reason we didn't allow object! for options was the 'inconsistency' 
of:
make object! object!
vs.
make object! [block! | map! | none]


in R3. We might add support for object!s but it will make the function 
a bit more complex.

I have a question to 'when style - is that adapted? Well, it basically 
works, in a simple panel example:


lay: [button "OK" do [print "OK"] when [load] do [print "screen on-load"]]
view lay

But when I simulate the demo, it is not triggered:


lay: [button "OK" do [print "OK"] when [load] do [print "screen on-load"]]

panel: make-face 'vpanel [columns: 1] 
set-panel-content panel lay

win: make-face 'window []
set-panel-content win panel

view win

OK, leaving for a business trip, but one other question:


when I click toggle, it crashes. It seems to me, that the 'of reactor 
and namely exclude panel is not handled properly, but I will try 
later ...

Cyphre's "as usually" most probably means "on Friday", and I bet 
Cyphre will put a note to the announcement group when the update 
will be available.

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.

'of reactor does not work. It calls 'exclude-faces function, which 
crashes on trying to access panel/faces, which does not exist, as 
shown above.


I have also some difficulcy to understand, what is 'of good for. 
I am not sure I like the name, as I was not able to understand the 
code like:


t1: toggle "Toggle" of 'tog      .... where 'tog is not part of the 
panel. The help string says: "Mutual exclusion of logic SET on other 
faces (radio buttons)"


I suggest alternate names - mute, mutual, invert ... that's just 
a suggestion, simply put reading 'of in the code does not make the 
functionality obvious enough for me, unless I look into docs ...

It contains the following code:

	content: either block? content [
		apply :parse-panel [
			content all [in panel/facets 'names panel/facets/names]
		]


So, when I submit a block to set(insert)-panel-content, it tries 
to parse the dialect. But, there is no panel/facets/names.

re "R3 is highly unstable..." - we know about a case where R3 crashes. 
We were able to isolate the problem so it can be reproduced. Carl 
is now investigating this issue. It is possible that all the crashes 
you see are because of this one problem. Let's see once this one 
is fixed.

Cyphre - simply put - in a demo I am porting, I am not able to get 
the subpanel to work - it displays, but  don't perform actions. E.g. 
single button press causes:


** GUI ERROR: Cannot parse the GUI dialect at: panel 240.100.80 title 
Alert grou
p doc Button pressed! scroller

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

yes, sorry, wait a little bit, I am at our subsidiary. But maybe 
I could discuss it personally with Ladislav, as I am in Turnov, some 
20 km from Liberec :-)

:-) I don't know if I will have time for that. Still at Aminostar, 
today 3 hours I will write a project doc, tomorrow ditto Aminostar, 
and I should leave for Prague in teh evening. So - if I would be 
supposed to visit Liberec, it would be sometimes after the luch, 
having some 1-2 hours at max ....

As Cyphre explained one concept to me, and because I have some questions, 
I post it publicly, so that others might benefit from the info. I 
was not properly understanding the structure of the panel. Cyphre 
was kind of surprised why do I need to know it, and that I might 
not eventually need it for the layout work, but the truth is, that 
I would like to understand system internals.


In R2, the structure of the face was mostly the same IIRC. And you 
put your elements into face/pane. I found out, that structure of 
face might be different for various styles. I hope I am not wrong. 
And in such a case, I suggest to document particular style fields, 
so that one does know, what does it serve for. That might be really 
good for programmers ...

style/facets/names is a logic value, which you can set to true, and 
it is usefull for compound styles. Sub-faces referenced by name is 
then style local, and does not leak to globals, does not get rewritten 
by new instance of the style ....

example:

stylize [
container: hpanel [
	content: [a: button "A" b: button "B"]
	facets: [names: true]
]

style/names/a, style/names/b is example for the access to the above 
....

Now I have following points to think about:


1) in REBOL we often don't user conventional naming, but if we would 
use it, then probably 'locals? would be a better name?
2) it is a logic value, why 'names, and not 'names? ?

3) for the instance locals, we use name 'intern during the style 
creation, so why not 'intern?

4) I was really so used to the 'pane (or container in other environments), 
that so far I don't like 'content, and I don't like referring to 
the name referenced faces by style/names/a. So, if my understanding 
is correct, and /content just stores the dialect (not reduced?), 
then why not:

face/intern?: true
face/pane/a, face/pane/b
face/facets/layout?


The thing is, that it is still difficult for me to understand the 
role of a gob! Because gob has a pane, and the concept of gob, multiple 
gobs, and faces organising gobs, made the concept messy in my head 
:-(

in above - one correction - face/facets/intern?, as a replacement 
for face/facets/names .....

what is actually being stored in panel/gob? And what is panel/draw-result? 
And is face/facets/content just a layout dialect stored, or already 
reduced?

That gob structure does not comply with faces. I need to see some 
drawing, or it is a mess, which noone will ever understand. And I 
assure you, that programmers will require to understand that ...

akorat to proste neni potreba ... a vlastne mozna nepostavime - muselo 
by se zpocitat, kolik by z toho jednoho panelu byl prouzek

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?

no. having an engine which provides great GUI defaults is essential, 
but not at the cost of being able to tweak a widget .


skins/themes/stylesheets provide usefull defaults,  but having access 
to overide any of this is absolutely necessary.

I don't want to rely on the fact that   'red-button-which-doesnt-resize-aligns-right-bold-with-larger-white-font 
  is a style   ;-)

I have already explained why before, so I'm not going to do that 
again. But suffice it to say, that it's my personal opinion and may 
be overridden. I just think it's a shame to be blinded by apparent 
"freedom" by having the ability to meddle with faces directly. When 
building large apps, this is a mistake, an illusion of freedom.

sorry, but having built "large apps" and for clients, this freedom 
is very necessary.  


if you don't use it that will make the gui generally better, but 
there is always a time when its required and it has to be possible.


what VID lacked had nothing to do with styles and looks.  it was 
the fact that everything under it was insufficient at best... layout 
sucks, event system sucks, dynamicity sucks, no way to switch stylesheets 
on the fly, no locale, etc.

the best VID users built stylesheets as a lib and then used that 
directly with the least inline styling possible.  but you always 
require to tweak things here and there.  even when the layout resizes 
on its own

When it becomes possible, people use it and then over-use it. Thereby 
we get incorrect methods for building proper layouts and we can't 
go beyond where we are in intelligent handling of a layout.

Henrik - don't even try the old crap on me again :-( The reason why 
Carl started new GUI was because of Gab's GUI was not all that easy. 
If I want 50x50 button, don't even dare to dictate me, that I can't 
easily have it. If I can't, I almost refuse to use such a system 
period.

Specifying color is a different matter though. You need abstract 
functional colors at most in styles and layouts to support skinning, 
not real colors.

but when a client tells me, I want this banner red, this one navy 
and this one black... I've stopped trying to convince them that its 
ugly, it just irritates them, and it inevitably leads to bad relations. 
   I will convey my experience and state that its not something professional, 
but in the end, the client writes the check, and I need to be able 
to push the bytes out the door.


there is no philosophy or ideology when you need to deliver and a 
tool can't turn around and be flexible.


I don't want to post stuff from other engines here since its not 
a comparison game, but I've used many APIs from prbably 20 different 
dev platforms, and everytime I use one which has an "unwielding" 
ideology where you can't modify things to make them do what you want... 
as a user, I get frustrated and I just look for something else to 
do and/or work on.   


good defaults, decent properties and backbone, clean style.  all 
the rest, open and hack.  I woudn't be a Reboler otherwise.

that's just my 2 cents.

The current design is supposed to allow non-GUI-designer programmers 
to specify layouts. Even if you are both the layout programmer and 
the style designer, the work is supposed to be separated. For that 
matter, a proper layout dialect for the types of apps that the R3 
GUI is made for (not games) should be portable to other device form 
factors, accessible, etc. So if you need to be a theme designer, 
do it in the theme section of the app, not the layout. And if you 
need to be picky about the styles, do it in the style section of 
the app, not the layout.

in theory yes... in practice no.    exactly like OOP... on paper 
and in theory its all rose and perfect.  in practice its a nightmare.

Or more direct question - how does button, with its border and gradient, 
differ from e.g. even more complicated style as panel for e.g.? And 
panel has border, and gradients too. While panel can be sized in 
a layout as an option, button can't

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.

From Max: "I don't want to post stuff from other engines here since 
its not a comparison game, but I've used many APIs from prbably 20 
different dev platforms, and everytime I use one which has an "unwielding" 
ideology where you can't modify things to make them do what you want... 
as a user, I get frustrated and I just look for something else to 
do and/or work on."


And I say - Amen. Set it into stone, and you might wonder in the 
end, why you have no following. It is exactly the same reason most 
ppl are not able to understand, that no matter how logical it is 
to have the skin done as a last, R3 GUI did not get any following, 
because of the first look experience simply get's users not interested 
at all. And it was said here not jus by me. You can protest, but 
that is all you can do about it.

will give it a try ...

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

If so, that is a discrepancy in the naming then, sadly.

exactly. But the tricky part is as follows - I like having 'options 
in the dialect level, and I am kind of used to have to call style 
attributes a 'facets ..... I would have to think for a while, if 
we can accept following convetions:


- options - used to set style properties, either in the style itself, 
or in the layout dialect

- facets - special purpose properties, which can be used inline in 
the layout level


I think that it would work for me, and that we would have it aligned 
nicely that way. I am just not sure Carl or other guys are ready 
to give-up on facets name being a general attribute/property of the 
style :-)

My opinion is, that 'options as a term is more accessible to the 
ppl, than facets, so I would go for the change ...

Henrik - don't even try the old crap on me again :-( The reason why 
Carl started new GUI was because of Gab's GUI was not all that easy.


Henrik - I believe you will fail explain technical reason, why it 
prevents proper skinning


An exact failure in understanding why face hacking is not welcome. 
Gab's GUI was not easy due to a number of layers needed to describe 
the look and feel separately, as well as requiring you to handle 
GOBs manually. But it supported applying proper meaning of styles, 
because Gabriele had the same goal as me. Carls does too and RM Asset's 
does this even more. We just have to take advantage of it.


Have you never had to fix someone's MS Word document, so that TOC 
generation, links, indexes, headlines, etc. could be understood by 
Word, because they had resorted to manipulating the words directly 
with colors and style, instead of using Word's style system? This 
is exactly the same problem. You will be teaching beginners that 
their layouts won't scale properly for exactly the same reasons. 
Many people therefore never really learn to create correctly formatted 
Word documents.

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?

that's rather easy, but not easy enough. Still a different concept. 
You guys act like button is a text, and it is not :-) If I will have 
whole screen of the same buttons, I might use stylize, e.g. for the 
calculator widget, as an example, becuase constantly repeat button 
30x30 is not convenient for me. But it still does not mean, that 
ocassionally wanting to have button a bit differently sized does 
a damage. Do you think users are crazy and will make each button 
differently sized, just because they can? :-) (Well, as for MS Word 
files, some users are able to create completly twisted texts, bu 
still - that is a text, difficult to restyle ... while we are talking 
GUI here.

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.

That looks more like a job for the resize engine than the button 
itself.

Rebolek, thanks for confirming it is a bug :-)

REBOL - maybe a simple bug, did not investigate it yet, but you might 
missed my report, as there is lot of a chatter here lately:

 view [doc "test"]

- doubles the content ...

I would like that the finished doc style supports images, tables 
and enough features to allow direct rendering of MakeDoc documents. 
This should simplify creating a documentation system, where we don't 
need to rely on browsers, when using browser-less platforms.

(This could be a third party project?)

Henrik - there's no why imo yet :-) From my POV it is very preliminary, 
and I would orientiate myself to:

- adapting existing styles to new R3 GUI engine

- adding styles most commercial guis will need - table, tree, tabs

- be sure all styles behave in a platform compatible way (especially 
area)
- reskinning/respacing the elements

- add support for ctrl-tab at low level to switch between the tabs
- fix all hard R3 crashes

later:

- add support for accelerator keys, but visually, and in the code 
(requires rich-text, most probably autogenerated, to underline the 
letter, but it could be done a different way to - e.g. displaying 
boxes with accelerator keys upon the styles and Alt key press)

- improve the text quality, that is NOT ACCEPTABLE for the 21st century!

even later:

- add some funky styles as Doc to make documentations, wikis, etc. 
:-)
- HW acceleration support where possible.

A system that you let someone else write is never large. Yet I would 
say a documentation system is a large task

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

only over my dead body

 - that should not be a problem, we meet today personally, no? :-))) 
 ... just a joke :-)

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

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.

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.

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"

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?

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

That approach would make sense if there was a good reason for the 
limit, like a larger limit would screw up the draw blocks or something. 
Cyphre, is that the case with the button style?