World: r3wp

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.

So you are referring to what happens when the faces are first rendered 
or when a user manipulates the GUI manually or both?

The above is not related to what happens when the Panels are first 
rendered. It refers to the case, when somehow, a panel changes somehow, 
e.g. whan a new button is inserted into a panel, or a divider in 
a panel is moved, ....

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?

I personally don't like any automatic sizing... when I design a gui, 
I know exactly how I want the components large with pixel precision.

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.

How about the interface allowing the programmer to specifically request 
the update - do you think the /UPDATE [...] looks fine?

Ladislav, how will it work across multiple windows?

Hmm, it should not matter how many windows there are.

ok, I guess it depends on the model for how to do manual updates

I think /update [...] is good.

Oldes, if you want R3GUI won't resize anything.

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?

Yes, mainly when programming a style, you nailed it

But, OTOH, if you use the INSERT-PANEL-CONTENT function, you will 
be able to tell, what shall happen to the panel dimensions

(until now, the panel autosized without you being able to suggest 
you wanted to keep its dimensions)

so, Pekr, if you consider just the case of the INSERT-PANEL-CONTENT 
function, what would you want to be the default behaviour?

%trunk/r3-gui/source/panel-make.r3 and %panel-sizing.r3 committed. 
Changes:

- SPACING initialization moved to the INIT-PANEL function

sorry, crying right, but on a wrong toom here ;-)

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

Sorry for the color, but the latest message is as I can see the possible 
scenarios, just wanted to distinguish it. Leaving for work now, online 
back in 40 minutes ...

So - one more note - if above would be wisely implemented, I am for 
auto-update with manual override not to update for the style author. 
But if I would get unexpected results, I prefer not to auto-resize 
probably (but not 100% sure, unless giving it a try for a while)

 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

(at the expense of the other panel, which becomes smaller)

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

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.

 - frankly, you can at least try the examples provided and see what 
 happens now; and, eventually, present your observations here

Ladislav - I might be too dumb to understand :-) What should I actually 
try? Do you suggest some panel test scripts, which are in the distro? 
Or what do you mean by "examples provided"?

I still miss simple style to group things. I always wanted a panel, 
with border, gradient, etc., but then also exactly the same style, 
but with zero visuals ...


IIRC, in Carl's GUI, it was panel vs group - except the fact, that 
it group used opposite coordinate system - very unwise btw


In RMA's GUI, if I am not mistaken, group is internally completly 
different - it is here for those users, used to VID2 - you have to 
use RETURN keyword, it does not align in grid cells, etc.


So - how do I easily define inline style, which removes panel visuals? 
I don't want to create new style for such a simple and usefull thing. 
And I start to think, that 'group style is here just to confuse users 
...

Per, look at TIGHT, it's variant of PANEL that serves some of purposes 
you want and it's done using just redefining some facets, so you 
can make your PANEL variant based on it.

Pekr: looks, that you will get more examples from Cyphre, who promised 
to pack some and make them available. So, I am afraid, that at the 
time being, you only have the examples from the gui-panels.html text 
available.

Andreas: "A quick question: is proper alignment along font baselines 
planned for the GUI?" - no, it is not, since the understanding is, 
that it has already been implemented... In case you see some quirks, 
please, let us know.

I haven't kept up .. how does the GUI event model work ... is it 
comparable to DOM 2 event handling?

Yes, it can be compared, events are handled by event-handler and 
on-* actors are called in appropriate face(s).

So can you have multipe listeners for each event?

I'm not sure what do you mean by that. By design, every event must 
have some unique face where it should end. But if you want run multiple 
actions with one event, that's possible.

In the original DOM 0 model, each event had one handler attached 
to it.  In DOM 2, you instead have listeners, as many as you want, 
listening for an event.  Each of those are triggered by the event. 
 So, it's like have 10 actions on a button, each of which are triggered 
on a mouse click.