AltME groups: search

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.

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

Erroring out on size inconsistencies is a proper solution

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

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.

the basic question is, what is the meaning of pair! in layout? is 
it size that user wants or is it size that user wants to be used 
for some inner magic?

when a concept of default size is there, that is usually what you 
want the pair to be.  when it goes beyon min or max bounds, usually 
you want to push these to at least match the default size...   the 
developper is expressly asking for an adjustment to the default.


the thing is that when a widget is in an auto-resizing layout, asking 
for 100x100 might not actually give you that size, because all the 
widgets are subject to the layout in which they are displayed.  in 
row/columns, you will be subject to equalizing other lateral sizes 
in the list and may be given more space in the longitudinal size, 
such that in fact, your button may be larger than what you asked 
for.


the only way to force a 100x100 button is for the gui to support 
static sizing within a dynamic layout, or support max-size and set 
it to the exact same as default size effectively making it a static 
sized button.

You can write preprocessor that will convert every [button "text" 
100x100] into [button "text" [min-size: 100x100 init-size: 100x100 
max-size: 100x100] and that's all. But there's strong opposition 
to having this directly in dialect.

You can write preprocessor that will convert every [button 

text" 100x100] into [button "text" [min-size: 100x100 init-size: 
100x100 max-size: 100x100] and that's all. But there's strong opposition 
to having this directly in dialect." - it is certainly possible to 
have such "statically sized" style, but that is not what the majority 
of users would need

It is quite logical, as far as I remember, you told us, that Glass 
did not have the Max-size at all?

in GLayount, max-size is sort of automatic.  there are two sizing 
values, one for filling, one for stretching. 


its very effective in making sure that only things which benefit 
from extra size, actually get it, and makes everything neatly aligned 
with virtually no need for any manual sizing control in the layout.

though with static size you can get similar results to tabular sizing.

when I say static size in GLass, it just means that it doesn't fill 
the space.   things still align and stack up automatically within 
the frame.

Yes, the same here, when the inability to grow to fill the whole 
"cell size" means, that the alignment becomes visible (left, right, 
or center in the horiz. direction, top, bottom, middle in the vertical)

Panel resizing user poll:

Background information:


For resizing purposes, every graphic element (including panels) has:

INIT-SIZE, MIN-SIZE and MAX-SIZE dimensions:


* INIT-SIZE is the size that is being resized (magnified or minified),

* MIN-SIZE is the smallest possible size of the element after resize,

* MAX-SIZE is the largest possible size of the element after resize.


Until now, we used auto-sized panels, for which we always (after 
every content change, like insertion of a button, etc.) recomputed 
their INIT-SIZE, MIN-SIZE and MAX-SIZE based on the sizes of the 
elements the panel contained.


Currently it looks, that there are many reasons, why it may be better 
to *not automatically recompute* INIT-SIZE, MIN-SIZE and MAX-SIZE 
after at least some of the possible change types.


Therefore, we introduced a non-auto-sized panel, which auto-computes 
INIT-SIZE, MIN-SIZE and MAX-SIZE on-demand only.

Our questions:


* After inserting a button (or other contents), what do you think 
should be the default action - recompute all the above values, or 
not recompute any of the above values?

* How to specify a non-default behaviour? Cyphre came with a proposal 
to use a /UPDATE refinement accepting a WHAT block, so, e.g. /UPDATE 
[MIN-SIZE MAX-SIZE] is required to update just the specified dimensions. 
Would you find a different alternative more convenient?

The outcome of the case not recalculating INIT-SIZE, MIN-SIZE and 
MAX-SIZE would be, that the panel would try to occupy the same space 
as before the change. That may be what the user wanted, if he had 
a specific idea, how large the panel should be, regardless of the 
contents he might add into it later.


The outcome of recalculating INIT-SIZE, MIN-SIZE and MAX-SIZE (on 
the other hand) is, that the panel dimensions are auto-changed after 
almost every change. It looks especially "ugly" in case dividers 
are used to change panel dimensions, since if you change the X dimension, 
and later the Y dimension, due to INIT-SIZE recalculation, your former 
change may become totally ignored.

Thanks. Then, if I am thinking about this correctly, in the case 
where a user might increase the size of a window, would it be likelt 
he wants the interface to be larger or that he wants to see more 
of what is not visible. Am I off in thinking this is what you are 
asking?

Yes, I see that point as well. Most of time I resize something it 
is to either gain more real estate (Obviously shrinking the window) 
or to see what is being hidden, as with a large spreadsheet or to 
show me more as one might do with an email client.  In the latter 
case, the objects resize larger but not the fonts, etc. This ALTME 
window is a good example. If I want to see more messages I can increase 
the size but I don't expect everything to just get bigger.

Sounds exactly as my preferences are. I originally wanted it that 
way, but was somehow outvoted. Anyway, the current improvements I 
made (will be in the next release) look satisfactory to Cyphre. Therefore, 
I count your votes as votes to not recalculate the INIT-SIZE, MIN-SIZE 
or MAX-SIZE automatically, respecting the user setting as "higher 
authority", while allowing him to demand the (re)calculation whenever 
he feels like.

I have no preference, as I am not able to imagine all possible outcomes. 
I fear we might get in a weird situations, when someone adds a button, 
you will see part of the button, but panel will not be large enough. 
But otoh I am able to understand, that auto-adjusting what user thinks 
is the right size to the pane, might be unnerving too. Anyway - those 
questions are not for users, but for style programmers, no? Or where 
I am supposed to use /update refinement?

ok, so let's think what does it mean? Because - most of the time, 
I use maximized windows, so:


1) for maximized window, if there is an area - let's think above 
message pane in Altme for e.g., if I insert new button there, there 
is no place to enlarge the panel to, so what happens? Do panel scrollers 
appear? And if so - am I kept at the beginning (top-left) of the 
panel, or am I scrolled to the location of last inserted element? 
Please note, that those concept are relevant for grid/table navigation, 
etc., it is just similar


2) if the window is not maximized, and panel is about to be resized 
- is window enlarged automatically?



So PANEL ENLARGEMENT preferred behaviour (note - say nothing about 
auto or manual update preference though):


If I would be for the auto-update, what I would probably hate would 
be if the size/position (let's think of always centered window) of 
the window would be automatically moved.

PANEL SHRINKING:


So - what should happen, if you remove elements? The same as above 
apply? Does the whole window shrinks? Or just scrollers get eventually 
removed, or the panel is simply smaller, whereas the window remains 
to be sized as-is?


As you can see, I need an answer to above questions too. It is all 
about what is the most pleasan vs unnerving to use. And it relates 
to what happens to Window, not to panel, that is just secondary question, 
if it stretches automatically ....

I can see following possibilities:

PANEL ENLARGEMENT:

- panel is not enlarged, it adds scroller

- panel is enlarged, but it does not affect window - window adds 
scrollers

- panel causes enlargement of the window (hence window moves, and 
we should be carefull, because new size of the window does not need 
to fit to the screen - it is a special case)

PANEL SHRINKS (content removed):

- panel just stays as is, eventually removes scrollers

- panel shrinks, to fit its content, but window remains of the same 
size

- panel shrinks to fit the content, window shrinks to fit the panel

All above plus the combination of auto, vs manual

 if I insert new button there, there is no place to enlarge the panel 
 to, so what happens?

 - that is actually not true; when resizing, the algorithm resizes 
 proportionally to the INIT-SIZE, which means, that a change to INIT-SIZE 
 of an element changes the proportions of displayed parts, while no 
 change to the INIT-SIZE does not

example: if a (maximized) window contains two panels, and you enlarge 
the init-size of one of them, leaving the other as-is, the proportions 
change, and the panel with enlarged init-size will become greater

if the window is not maximized, and panel is about to be resized 
- is window enlarged automatically?

 - that depends - if the window INIT-SIZE does not change, its actual 
 size does not change as well

do-style window 'on-resize win-size

Any hints how the material system work? How do I "destylize" panel 
for e.g.? Let's say I want panel functionality, but without the visuals 
(if I enclose everything in panel, there's too many borders and gradients 
around, and I would like to have more relaxed design). Let's say 
I would like to create derived style, called panel-, panel-less, 
pure-panel, whatever. I can see following draw code:

draw: [
			plain: []
			gradient: [
				clip margin-box/top-left margin-box/bottom-right
				pen none
				line-width 0
				grad-pen linear 1x1 0 gob-size/y 90 area-fill
				box (margin-box/top-left + 1) (margin-box/bottom-right - 1) 1
			]
		] 

And following on-make code:

			on-make: [
				make-material face get-facet face 'material
				set-material face 'up
				all [
					get-facet face 'area-fill
					set-facet face 'draw-mode 'gradient
				]
				make-panel face 'panel
			] 

What I am supposed to do, to change the disign?

hmm, progressing slowly, but at least something:


>> view [p: hpanel [button do [print mold get-facet p 'materials]]]
make object! [

    up: [0.0.0.200 0.0 0.0.0.255 0.5 255.255.255.255 0.5 255.255.255.220 
    1.0]

    down: [0.0.0.200 0.0 0.0.0.255 0.5 255.255.255.255 0.5 255.255.255.220 
    1.0]

    over: [0.0.0.200 0.0 0.0.0.255 0.5 255.255.255.255 0.5 255.255.255.220 
    1.0]
]

== make gob! [offset: 566x379 size: 148x42 alpha: 0 text: "REBOL: 
untitled"]


>> view [p: hpanel [button do [print mold get-facet p 'material]]]
container-groove

== make gob! [offset: 566x379 size: 148x42 alpha: 0 text: "REBOL: 
untitled"]

How can I properly attach scroller to progress bar? Following code 
shows scroller at 100% value. Scroller accepts some initial size 
parameter, but not sure how to utilise it either ....

view [prog: progress sbar: scroller attach 'prog]

Ultimately a scroller and an item to scroll has many subtleties that 
you don't notice at first, such as step size, whether you want smooth 
or non-smooth scrolling, and the structure of the item to scroll, 
and whether you want separate behaviors for vertical and horizontal 
scrolling. Then there is also placement of the scroller. Do you want 
the scroller to automatically "sense" what direction it has to scroll 
in?


All this means that the scroller should treat each such case as a 
special case and you can't ask a style developer to meddle with attachment 
code inside the scroller style to deal with this issue. It's better 
and simpler to have a "dumb" scroller that will do your bidding for 
your style.


It "works" in Carl's demo, because he only has 1 or 2 cases to work 
with, but it doesn't really work that well. He never implemented 
tables, image-pans, icon lists, chat lists, maps, browser windows, 
etc.

Rebolek - I don't know if it works. I might work. The "trouble" is, 
that scroller itself displays itself with 100% knob size. So there 
is nothing to scroll :-) How do I cause the scroller to have smaller 
initial knob size?

Ah, I see. Then use this:


view [prog: progress sbar: scroller options [delta: 10%] attach 'prog] 
; DELTA will set knob size.

Rebolek - then there might be a difference to init knob size. I know 
it should be recalculated to the amount of data, but maybe by default 
it could be the minimal size, instead of 100%?

Usually when you work with IDEs, you are able to choose scroller, 
and the know size is at the minimal position, not at the maximal 
one, imo ...

Nope, slider is a value adjustment tool. It doesn't need knob size 
management.

What is the 'state object? I can see there is knob-size set to 100%. 
What is the purpose of this slot? I thought that parameters are stored 
in facets?

My secret plan is that SET(GET)-FACET should one day probably work 
as SET(GET)-FACE/FIELD but currently there's only one style that 
supports fields, so this will take time.
 - Sadly I have no idea what you are talking about here. 

GET-FACET FACE 'SIZE
vs
GET-FACE 'SIZE????

FIELDS are probably not part of the latest public release. Currently, 
[set-facet face 'size 10x10] is basically the same as [face/facets/size: 
10x10]. With fields you can have some code that will check the value 
for right datatype, boundaries, etc.

Rebolek - will it not complicate a bit design/syntax of style? so 
instead of facets [size: 10x10 color: blue  text: "test"] we will 
see maps? Or will it be hidden in some lower level?

There was very long discussion, towards if we should allow to change 
the size of the button to allow any size being set

 - did you really mean it? One can easily make sure, that the init-size 
 of the button is set as specified. The fact, that the result of the 
 resizing is different demonstrates, that the result of resizing depends 
 on other attributes as well.

So, nobody forbids you to set the INIT-SIZE as you see fit.

It is demonstrable, that frequently, it can be useful to have INIT-SIZE 
outside of the MIN-SIZE to MAX-SIZE range.

That being the case, it is necessary for the three dimensions to 
be independent, in that it has to be allowed to set the INIT-SIZE 
outside of the range, i.e. set all three dimensions independently.

current behaviour allows inlined set of init-set, which has no effect 
though, and hence causes user confusion 

 - that is not true again, since the user can examine the INIT-SIZE 
 attribute, he can easily find out, that it has been set as specified. 
 What was not set (and not specified) is just the MIN-SIZE and MAX-SIZE 
 values.

- allow max-size override. If user requests 400x400 button, which 
exceeds max size in x and y axis, set new max-size to that value. 
The argument that that might not be eventual max-size user might 
imagine does not hold any water. 

 - as said, MAX-SIZE shall be independent from INIT-SIZE. What I do 
 want to preserve is the independency between INIT-SIZE and MAX-SIZE, 
 since that *is* needed in reasonable cases.

To not be misunderstood:

- everybody is allowed to set INIT-SIZE howewer he likes
- everybody is allowed to set MAX-SIZE however he likes

- nobody is allowed to ask me to be more clever than him and to "correct" 
(read: "mess up") the MAX-SIZE for no reason, in fact

There was very long discussion, towards if we should allow to change 
the size of the button to allow any size being set" - did you really 
mean it? One can easily make sure, that the init-size of the button 
is set as specified." - Yes, I meant it, because IIRC there were 
opinions, trying to suggest here, that it should not be allowed at 
all :-)


All stuff you write - I know. It is just that I might not necessarily 
agree with the outcome. I am trying to think form user's point of 
view. I wonder to what points you would agree, and to what not:


- Let's assume I set button in bounds (between what min-size/max-size 
allows): I tried various scenarios, and I almost never got button 
of requested size. The reason is in how resizing system works. In 
fact, when inspecting various sizes - init-size, min-size, max-size, 
those don't contain actual button size. Actual size is in face/gob/size. 
Button gets different size due to resizing system cell alignment 
imo. From the resizing system point of view, it is correct behaviour, 
but from the user's perspective, it is questionable, if the result 
is OK?


- In regards to above point, I really wonder, if buttons should be 
resizable at all. I said - resizable, not settable. I wonder, if 
I would like buttons to be of consistent size. I might try with face/resizes?: 
false, if that would make the trick.


- Then, in regards to above - I might think of init-size setting 
the requested button size


- Maybe (and I am not sure about that one), we could allow some debug 
info - "out of bounds", if my init-size value does not fit in between 
the min-size, max-size, as style author defined it. I have heard 
that guys are working on some field accessor functions - those might 
be able to print some debug info to console, at least when in interactive 
mode.


Othere than that - this one is a minor issue for me, I e.g. care 
more about architecture, and so far I can see materials having real 
low benefit, for how complicated it turns out ...

Following is the CLICKER style FACETS definition:

	facets: [
		init-size: 28x28
		area-color: 80.100.120
		edge-color: 0.0.0.128

		pen-color: ; set by on-draw
		area-fill: ; set by on-draw
		material: 'chrome
		focus-color: red
		draw-mode: 'normal
		materials: none
	]


Too many colors around :-) Those are not part of material abstraction? 
I noticed that material basically defines area-fill ....

How on earth I define, in stylize level, how is options block mapped 
to facets?


Why do you want to do that? Let's say I want to write KNOB style. 
I can set for example it's value, color and size, so options would 
be something like:

options: [
	level: [percent!]
	knob-color: [tuple!]

 knob-size: [integer!]	; it's round, so diameter is enough for size
]


Then I can use knob-color, knob-size... in draw block without any 
manual mapping.

Let's assume I set button in bounds (between what min-size/max-size 
allows): I tried various scenarios, and I almost never got button 
of requested size.

 - yes, the size is always a result of resizing rules, as applied 
 in a specific style. There are two methods working quite differently, 
 the first one is used by vgroup/hgroup, the second one by vpanel/hpanel. 
 If none is what you like, then there is a possibility, that you would 
 like to have a completely different style, with different resizing 
 rules...

- In regards to above point, I really wonder, if buttons should be 
resizable at all. I said - resizable, not settable. I wonder, if 
I would like buttons to be of consistent size. I might try with face/resizes?: 
false, if that would make the trick.

 If you set the RESIZES attribute to OFF, you get a completely different 
 behaviour, than what you expect:


- the resizing algorithm will leave the button untouched, which means, 
that it does neither compute the position, nor the size, and the 
button would just "float" - the next version will contain more than 
20 different examples, Cyphre's visibility example manipulating the 
RESIZES attribute included


- if you just want the resizing algorithm to not change the size 
of an element, while allowing the resizing algorithm to compute the 
position of the element, you should do it differently. Just set the 
INIT-SIZE, MIN-SIZE and MAX-SIZE of the element all to the same pair. 
You will notice, that the size of the element will not change, no 
matter what, only the position may change.

yes, you shall find out, in general, "floating" means - the resizing 
algorithm influences neither the size nor the position in any way, 
i.e. the element "floats unnoticed by the resizing algorithm"

- if you just want the resizing algorithm to not change the size 
of an element, while allowing the resizing algorithm to compute the 
position of the element, you should do it differently. Just set the 
INIT-SIZE, MIN-SIZE and MAX-SIZE of the element all to the same pair

 - this is the worse solution from the two offered, while more usefull. 
 I can imagine I simply don't want buttons being resizable. Then 'resizes 
 field does not express the meaning of the word, as in fact it does 
 not resize, but it also floats, which is imo not that much usefull.


In order to prohibit e.g. button from resizing, I need to derive 
the styles, and remove the init-size options from being set.

Hmm, you don't have to forbid setting INIT-SIZE. As I mentioned, 
it suffices to make sure INIT-SIZE, MIN-SIZE and MAX-SIZE are all 
equal.

>> probe info? http://www.rm-asset.com/code/downloads/files/r3-gui.r3
connecting to: www.rm-asset.com
make object! [
    size: 263986
    date: 2-Feb-2011/9:31:04
    type: 'file
]

or 130% of the unselected tab size

Agree .. .maybe 1/3 of current size

a little problem (perhaps only with wine) it is the resize of the 
application with the left bottom corner. the app seem to not find 
a good size !!!! flashing !!!

Following few things:


- why is "custom" include needed? We should either user R3 native 
facilities, or include an include as a standard into R3 :-) (this 
is no real question, just a remark that if we find it usefull, then 
why notto make it part of R3?)

- RMA does not work with CureCode tickets. It would be good to either 
dismiss/close or resolve them? E.g. I find renaming of do-style and 
do-face to do-action, do-reaction a good tip to implement


- we should resolve the size of buttons vs scroller vs tabs. In Carl's 
GUI, button is 28 pixels tall, and it feels OK. Our's here is 22, 
I have no preference here, but could be those 28 pixels. Scroller 
is only 16pix - not acceptable imo. It should be of the size of the 
progress. Tabs are proportionally too tall.

- tabs should have line removed for actual tab. I suspect it might 
be more difficult to draw the container then.

- there seems to be someone at RMA liking Old aqua interface of MacOS. 
Tabs, buttons and scrollers are a good example ... of how to not 
do visuals anymore :-)

- area - enter few lines, go to bottom, and try to hilite the text 
by keyboard (shift plus arrow-up). It always hilites only actual 
line

- info areas, labes, etc., should prohibit display of caret, maybe 
allow hilighting, but allowing to have caret in "disabled" area is 
not looking nice

- text-table buttons are Excel filter inspired, but looking strange 
- some more thoughts needed
- select-an-option does not allow keyboard navigation

- text-list does not scroll, when navigated by keyboard, ditto text-table

- tabbing feels strange for text table. I alway said, that we need 
nested tabbing. I can imagine tab stopping on table, but next tab 
moving away, not actually going into tabbing in terms of the hilited 
widget. Enter should enter the more complex style, escape move away. 
That is not typical also at OS level, but then - everybody has it 
wrong :-)

- between the text-list and text-table, I have to press tab three 
times -visually I am not sure, "where" hilite disappears

- is text-table a compound style? What sense does it have to have 
buttons hilighted, not being able to enter the action? Why are not 
arrows tabbable? Table headers cells should be one style, not two.

- text-table is the weakest "grid" we ever had. Comparing to Cyphre's 
style pack, and rebgui grid. This is like 5% of functionality, not 
thought out style, useless for any serious data. I want to see the 
display of infiinte amount of data, proper caching.

- tab should be tabbable, ctrl-tab allowed to switch between the 
tabs  


I find the styles/gui inconsistent. There should be someone defining 
the styles, their behaviour to keyboard navigation, tabbing, etc. 
So far it seems like style being put together with no deeper thought 
about the end result of the whole GUI.

Is my understanding of box model correct? The GOB size is maximal 
size, and it contains content area, which is being called viewport, 
plus padding, plus edge, plus margin?

Also, the size of the face structure is not at question. It hardly 
eats any memory, a few bytes at worst.

e.g. look at button facets:

	facets: [
		init-size: 28x28
		bg-color: 80.100.120
		border-color: 0.0.0.128

		pen-color: ; set by on-draw
		area-fill: ; set by on-draw
		material: 'chrome
		focus-color: red
		draw-mode: 'normal
		materials: none
		face-width: none
	]

So you want to create additional contexts, such as SIZE? Then you 
would have size/init instead of facets/init-size. Is that what you 
mean?

By creating new contexts, we would have to have an advantage to using 
them. In a way, I don't mind it, as it could be used to apply particular 
groups of facets, in a standardized way, so you know that a particular 
context will have these items. But FACETS does technically not prevent 
this. From a technical perspective, I'm not sure I can find an advantage, 
since there is no difference from R3's perspective on speed or efficiency 
in accessing size, color or hinting information.

However, I can see the following groupings or contexts:

- color
- hint
- size

hint and size would be standardized map!s, as they are used by the 
system.

Pekr: 'btw - I am not sure "hint" is a good name?' - actually, yes, 
since the INIT-HINT is a hint (look up the word in the dictionary), 
how the algorithm should determine the INIT-SIZE value

The 'AUTO hint just tells the algorithm to calculate the panel INIT-SIZE 
"automatically" (= using an algorithm) taking into account the panel 
contents. This means, that you, as a user, do not have to specify 
the panel INIT-SIZE, which might seem less comfortable to you.

Of course, if you know, what is the INIT-SIZE you want to have, you 
can specify it as well using a different hint.

Hi, here is an R3-GUI poll once again:


For the resizing purposes, all elements have MIN-SIZE and MAX-SIZE 
specifying the limits of resizing. It is easy to see, that, unless 
MIN-SIZE <= MAX-SIZE in both coordinates, the requirements are contradictory. 
(For example, if we set MIN-SIZE: 100x100 and MAX-SIZE: 50x50 for 
the same object.) Currently, the code does not trigger an error in 
such case (not having a built-in test for it), giving the priority 
to the MIN-SIZE.

The poll question:


What do you prefer to happen in case object MIN-SIZE and MAX-SIZE 
dimensions are contradictory? Do you think the current behaviour 
is acceptable, or do you want the code to always trigger an error, 
if conflicting requirements are given?

the max of any x y should be used as max-size

I prefer that max-size have some meaning. So if the size is set outside 
of max-size, the size should be constrained to max-size. That is 
the whole point of having a max-size setting in the first place. 
If a style has a max-size setting below max-int/max-int it should 
be there for a reason, and max-size can be overriden explicitly in 
the layout so it doesn't constrain unnecessarily.

As for whether min-size should trump max-size or vice-versa, I prefer 
min-size to trump max-size, or maybe even push up max-size. The min-size 
setting is usually more important for styles, since it often has 
to do with making the face larger than the smallest size of its contents.

Screen size probably should trump min-size though.

So, currently it seems to me, that Graham's idea to set the MIN-SIZE 
to be the minimum of MIN-SIZE and MAX-SIZE and vice versa, to set 
the MAX-SIZE to be the maximum of the MIN-SIZE and MAX-SIZE is supported 
by BrianH as well, and, possibly, Max would support such a method 
too, based on the fact, that it does not "jam" the application. Count 
my vote too.

And the actual size should be constrained by min-size and max-size; 
setting the size outside that range should not push the limits outwards.

And the actual size should be constrained by min-size and max-size

 - the actual size is a result of the resizing algorithm, and it indeed 
 is clipped to the MIN-to-MAX range.

Are these size constraints set through accessor functions, or otherwise 
processed by standard code before they are applied? That would allow 
the min-size and max-size to be repaired before they are used, so 
the min constraints can be ensured to be <= the max constraints.

Are these size constraints set through accessor functions, or otherwise 
processed by standard code before they are applied? That would allow 
the min-size and max-size to be repaired before they are used
 - yes

in glayout I had a lot of these issues to manage, and generally, 
I always had some part of the setup func which would normalize all 
the values to layout function expected behaviour.


this allowed voluntary programmatic side-effects, but not thru the 
layout dialect.


for example, all sizing values where clipped to be at least as large 
as min-size as the first step.

I'm trying to change the font color and size in a button, and in 
a field ... need some help !

Something like this?


view layout [button "Help" with [font: [size: 16 colors/1: 255.0.0]]]

re 15) text-resizing was enabled, so DOC-browser can render documents 
properly, but it seems that it doesn't sem max-size properly. I will 
check it.

#[[Pekr

I think that worse problem for me is how currently resizing is behaving 
in above mentioned styles

Pekr]] - resizing is behaving as it should. The problem is just that 
Bolek specified that the vertical size of the text is "unlimited" 
for resizing purposes. That is causing the layout to look ugly.

We had a small discussion about MAX-SIZE this morning. In short, 
I don't like it and think it's not needed. Everyone else loves it, 
so it won't go away. Therefore I'm proposing a RESTRAIN facet (name 
not final). Without explaining what it is, can you guess what this 
does:

Before:

bar: box [
	facets: [
		init-size: 100x2
		min-size: 20x2
		max-size: 10000x2
	]
]

After:

bar: box [
	facets: [
		init-size: 20x2
		restrain: [vertical]
	]
]

for example, when I would use bar, what size it will have? 100x2, 
20x2 or max-widthx2?

For max-width you would use max-size: -1x2

Using max-size: -1x2 still requires you to know the Y value, if you 
are using it as an option in layout, so you need to study the style 
code to know it. Hence the need for RESTRAIN.

Rebolek, same issue: STYLIZE may be used by a third party person, 
not knowing the original style size or not wanting to depend on it, 
if the original style changes.

Hi, guys

Once again, congratulations for the excellent work done.

As Rebolek suggested in ALTME, I have some modifications to submit 
(of course, to check from your side) for the next r3-gui release.


I must first mention that I just realized this morning that the r3.exe 
 pre-compiled version of march 11th was not working properly, bugging 
with some very simple text displays (probably an old version). That's 
the reason why I did not update the demo with the most recent r3-gui 
file. By the way, the  build date displayed by the exe remains the 
same whatever the real building date. I don't know how we could have 
an automatic update of the build version.


Rebuilding from your sources (march 11th) allowed the demo to work 
properly apart from some appearence differences (I have even seen 
some bugs solved compared to my demo version). However, I will wait 
for your next weekly release ;-) to update my demo.

Coming back to the propositions of modifications :


It seems that there are definitions problems, or incompatibilities
in r3-gui (around line 66)        
;-- circle: [pair! | number! | number!]    
circle: [pair! | pair! |number! | number!]

in r3-gui (around line 1729) 
;-- scale: [decimal! decimal!]  
scale: [pair!]

also, I overload the drawing style by this code :
stylize [
    drawing: sensor [
        about: "Simple scalar vector draw block. Can be clicked."
        tags: [input tab]
        facets: [
            init-size: 100x100
        ]
        options: [
            drawing: [block!]
            init-size: [pair!]
        ]

        actors: [
            on-make: [
            ;    if block? drw: face/facets/drawing [
            ;       bind face/gob/draw: copy drw face/facets]

            ]
            ;-- JC
            on-draw: [face/facets/drawing]
        ]
    ]
]


Concerning the discussion of this morning on groups and panels, I 
would also prefer to have a default horizontal arrangement, and only 
precise when vertical: group, panel, vgroup, vpanel. A side effect 
is that it would remain compatible with Carl's doc.

By the way, it seems that tight is vtight. Logically, it should be 
htight.


That's all for the moment. When debugging the last demos, I may find 
other issues.

Everyone else loves it

 - I expect a little more objective statements than this. In fact, 
 I don't "love" MAX-SIZE at all. I just know (you have proven it), 
 that some relevant frameworks (like the OSX GUI) include it. I am 
 sure that is the reason, why Carl insists on it as well. So, if we 
 want Carl to "throw our changes to the R3-GUI to the basket", we 
 can remove the MAX-SIZE to achieve that goal.

Ladislav, Carl told me that MAX-SIZE was necessary so that buttons 
would not become unnecessarily wide, but it is the wrong way to solve 
such a problem, much like putting a rock under the gas pedal to prevent 
the kid from going more than 30 mph in dad's car. Nevertheless, when 
(hopefully) we get some parts automated here, I will never need to 
deal with MAX-SIZE again directly.

And OSX does not provide maximum size for widgets, only windows.

Henrik - two things - first you should consult Carl (if he is available 
to RMA), and second - Ladislav will probably state, if there is a 
way of how to adapt his alghoritm, so that we can work without the 
MAX-SIZE? I personally don't mind MAX-SIZE anymore, as I have to 
set xy things anyway - hints, init-size, min-size, as needed. And 
if I am a style authoer, then I can always set MAX-SIZE to some artificial 
value, so :-)

aha, counterproposal:


- make the current UPDATE-FACE/CONTENTS behaviour the default, and 
for the other variant use something like UPDATE-FACE/SIZE (looks 
better than /RESIZE) to me. The trouble is, that the exception is 
the UPDATE-FACE/CONTENTS variant, since it can be used only for hpanels, 
vpanels, hgroups, vgroups, etc., while the default behaviour can 
be used for all faces.

Two notes:

- update is not resize, but can provoke a resize as well

- if I call UPDATE-FACE/CONTENTS on a hpanel, then the hpanel is 
updated (row and column sizes are recalculated, the total panel size 
is recalculated), but the panels contained are not

I'm confused. :-)


I agree that /SIZE is a better name, and now see the problem with 
it.


What does the docstring say for the function? That is, can we approach 
it from the documentation side and see if the functionality is clear.

When I build R3A110 and use text in view, the text is invalid. It's 
valid only if I provide it as UCS2, like:  g_text: make gob! [size: 
100x20 text: "^(41)^(00)^(42)^(00)"]

Does anybody (except Cyphre, who is not here) know, what can be wrong? 
I build it with CodeBlocks.

fine... I've found that the text must be bound to the text extension 
context.. this works:
ext-text: import 'text
g_text: make gob! [size: 100x20 ]
g_text/text: bind [
	;bold true
	text "AB"
] ext-text


The question is, what is changed in RM's version that it works without 
such a hack.... I have no problem to hack just the official A110 
version so far as I'm trying to understand how the internals work, 
but I really think that we need synced source repository ASAP.

Yes... but AGG requires multibyte. Probably. At least I can display 
gob with non ansi string like:
	g_text: make gob! [size: 100x20 text: "èøž"]
but not:
	g_text: make gob! [size: 100x20 text: "crz"]

Hardware acceleration of graphics is a good idea. The APU thing cuts 
down on the posibilities of that because the graphics processors 
tend to be on the scale of integrated graphics, due to the size, 
but that won't be the case for long, and graphics acceleration is 
still a good idea.

Pushed a few of my straight-forward A110 patches, mostly about mildly 
re-structuring the build. to https://github.com/earl/R3A110.

Here's a chronological list of commit summaries:

8ed0b68 Rename about.txt to README
45bf64d Temporarily remove unmaintained build projects
f7237b4 Move libs to platform-specific subdirectories
f8eb7e6 Move makefile to platform-specific subdirectory
5072f47 Remove reb-to.h and pass TO_<target> as compiler flag
2401c40 Minor makefile cleanups
333edad Linux: fix bug#1658: link binaries against libdl
3f1fd7d Linux: improve linkage to libr3
635f228 Win32: add makefile

4f57323 Win32: raise the stack size limit in the resulting binaries
048678b OSX: add makefile for osx-intel (untested)

For more details, see the full commit messages, or just ask me :)