World: r3wp

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

That's possible.

In JQuery, it's called bind() and unbiind()

GrahamC: well, as for browser, I recently looked into FF 4 featureset 
- video, audio, smooth fonts (open type), transitions effects via 
CSS 3, 4x faster JS ... we are somehow starting to lag behind :-)

Yeah ... I was thinking that maybe we should be using a similar event 
model to make it easier for us to learn both :)

GrahamC: the event does not necessarily have to be "consumed". In 
REBOL, we simply have events, and you can always return just the 
same event when processed by our handler. Remember insert-event-func 
from R2? You could create transparent event filters ...

It's much better than R2, because it's actually possible to work 
with events.

We need the ability to create events, and we should also be sure, 
that we are able to obtain modern events, as e.g. above mentioned 
FF4 can now handle multi-touch native Windows 7 event. And we are 
not even receiving such things as ctrl tab for tab handling. What 
I still don't understand is - the system port? Is that port still 
available in R3? And what was it good for? It would be e.g. nice, 
if by opening the system port, you would insert such a listener to 
the OS event model, registering for particular events. Well, that 
might be slow, if you are not carefull, but that way you might be 
able to receive any system event possible .... but not sure it is 
even possible :-)

Yeah, they also have event bubbling .. so a click can propagate outwards 
for other things to deal with

We need the ability to create events
 - so you should try make event!

event bubbling - that's part of R3GUI.

Rebolek - I know make event! is possible, but does it actully work? 
IIRC it was not fully working in early alphas? So you say I am able 
to simulate e.g. a keypress, mouse event, etc.?

is make event! attached to a particular GUI object?

Yes. I haven't got use for it yet, so I tested it only briefly. But 
I was able to create event!, send it to another face and process 
it.

Graham no. It's up to you what are you going to do with that event.

Graham - why should it be? I expect it being just a structure/object, 
you fill in the data, and it gets inserted into the event queue, 
then your objects react accordingly, like if the event would be generated 
by normal action.

So, how you would you simulate a mouse click on a button then?

a button that might be buried by another window on top of it?

I would simply call on-click for that particular button

graham - the gui has many nice features/handlers. There are things 
like do-face, do-style, not sure if cause-action is there (IIRC it 
was part of Gab's GUI)

resize on a window?

do-style window 'on-resize win-size

eventually we'll need the automated test system, so an "event machine 
gun" is needed.

and a way to record macros?

is there a way to enter characters into a field ?  Like the DEL, 
and Backspace ?

macros could be derived from the undo system

Is Pekr's port of the demo available yet?

I am going to work on it a bit today, and tomorrow, then I can release 
what I have ...

I am really nervous about things like removing the easy ability of 
changing the color of something easily, and if it will unnerve me 
in the future, I will fork it ... :-)

I want freaking to change the color of the scroller, the way Carl 
did it easily, via span-colors, easily changing the gradient. Material 
system is useless for me, if I can't do so easy things the esay way 
...