World: r3wp

I do want to execute resize to 100x100, which is done respecting 
rule #2

Yes, so you don't want to draw a 100x100 item

I do want to draw the item resized to 100x100, using the established 
rules

Yes, so you don't want to draw a 100x100 item

see above

Yes, so you don't want to draw a 100x100 item

see above

Yes, so you don't want to draw a 100x100 item

User deadlock

Could you please repeat for somebody not able to remember what he 
read 1 second before?

No

Thanks

hahhaha

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?

Yes

If it is not used in a userfriendly way, it shouldn't be there at 
all

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.

Yes, Max.

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.

just sharing my 15 years of experience building/analysing dynamic 
resizing layout engines.

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

Glass, for example,  just makes you get *at least* that space and 
won't change the resizing model of the style on its own... you have 
to ask it manually to become static by using other switches.

and frames use pairs for margins.

maybe it can be done using some kind of option, for example [button 
"test" 100x100 #and-i-really-mean-it]

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

no it doesn't.   Glass still doesn't have the multi-layered sizing 
model of GLayout though, which makes it currently harder to manage 
than it should.

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.

Do you have different panel styles, using different resizing, or 
just one resizing algorithm?

There currently is only one Frame resizing model (which works in 
X or Y).   though in fact, one can tweak the frame's default decisions 
in substyles.


this has been done in the scrollframe which uses a sub frame dynamically 
and renders a bitmap then uses the bitmap in the display.

because all the layout is a network of nodes, you can really do funky 
stuff... I plan on making a demo of such things as snapping overlays 
to edges of other widgets.

Does the Frame resizing model use a kind of "tabular layout", or, 
is it more like the hgroup/vgroup styles, where only the rows/columns 
are maintained, but not both at the same time?

row/column

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

yes, sure, the results frequently look the same

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)

I am still busy on my business trip, returning home tomorrow. I am 
thinking about producing Wiki article about what I find non optimal, 
or what I don't understand. So far I have gripes with 'options block, 
which does not map directly to facets, but is - artificial. That 
part has to move to declarative style definition, as it influences 
how you use the dialect ....

it may have scrolled out of the way, but there is an R3 GUI project 
in Curecode now.

the screen flashes if we expanded the window - i try hello-worl.r3

ubuntu 10.10

A quick question: is proper alignment along font baselines planned 
for the GUI?

I would first welcome fixing the quality of font display, which is 
really 80ties quality :-)

Not that I understand anything about GUI implementation, but font 
rendering sounds like a mere technicality for me.

actually it's late 90s :-)

Proper alignment of elements along font baselines sounds like it 
_could_ have a deeper impact and requires some planning.

But no idea, really. Maybe it's just a technicality as well :)

I agree that precise use of the baseline should be doable.  its the 
only way to properly handle multi-font display.  it would also be 
nice to be able to inspect the font so that we can measure the different 
metrics of a font.


x-height, descent, ascent, cap height, linegap (leading), H space 
width, etc.


On the Amiga, I used to align text with these values in code and 
it seemed to be much better.

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?

Default action: What would be the outcome of one or the other option?

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.