World: r3wp

I think I remember being able to change the order of faces in system/view/screen-face/pane 
to do that

not certain, though

but I can't seem to get the rebol window's in front of other application 
windows...  I'll try using hide/show...


 I'm thinking there was a view option that allowed us to tell the 
 engine that any show on a window would force it back to the top.. 
 but its sooo far away in my memory, I might be in error.

aaahhh found it... when you open the window... you specify the activate-on-show 
option   :-D

thanks for that one

this is an advanced question for View master:

as very few know, there is an easy way to get pretty fast face scrolling 
in View, and that is by using the changes attribute of a face.


this works fine in my scrollpanes and such.. but when I use it on 
a window face, it corrupts the window content.
I have to use show twice, which actually is pointless.

anyone know how to prevent view from corrupting the window face when 
I use 

window/offset: new-offset
window/changes: 'offset
show window

did you try without setting changes?

yes biut then it redraws the gui so its really slow.


I finally cornered it unfortunately this is a work around to a bug, 
and it slows down the process.


basically, you need to set the old-offset so its totally beyond the 
size of your window at current offset, this way, the redraw func 
doesn't try to reuse the saved area (it should have to since its 
a window, and its offset isnt affecting the display).  the draw back 
is that it has to reblit all the window, but it still doesn't have 
to redraw it, so its still faster than not using changes at all, 
the bigger the more complex the window, the bigger the gain.  but 
large windows will be affected by the slowness of view blitting.

I want to use parent-face correctly during INIT, instead of having 
it set during VIEW. I know that INIT is run during layout, but there 
may not be enough information available to correctly specify parent-face 
at that point. Has anyone worked on this?

My first retort is "of course there is!" (enough information for 
layout to set parent-face). Layout first makes the panel face it 
will return, referred to by 'new-face, near the beginning of its 
code body. It subsequently populates the pane of new-face with new 
subfaces built from the spec block. At this time, layout has the 
great opportunity to set parent-face for each one, but it doesn't. 
So, there exists the possibility for us to patch layout to do so.

The patch will be small, but of course, complicated to figure out.

the parent-face is set on a call to show.  AFAIK.  the reason is 
simple, when you build your layout, you can potentially change the 
face you put the layout into before showing it.

you can include it within the with block facet if you know it at 
that time.  init is called after the layout is done (all calls to 
facet words and multi are done).

I normally have a different solution for setting parent-face on any 
layout before SHOW, but it still happens some time after LAYOUT. 
I wanted it to be set earlier here, as an inspiration from VID3.4, 
where you can find a previous face during initialization, such as 
to attach a scroller to a panel without having the user needing to 
specify it directly in the layout.


I made some changes to LAYOUT, added a refinement to specify which 
parent-face exists for the pane. This is possible, because LAYOUT 
is not recursive and is called whenever one pane needs to be laid 
out. The idea was then to set parent-face before INIT.


This worked well for faces that are not at the base level for the 
window, but how do you specify the parent-face for base level faces, 
as the window face does not yet exist? I have dropped the idea again, 
because the solution is too convoluted. Besides it wouldn't be possible 
to attach to faces that come after the scroller, so you have exceptions, 
which is not good.


Scroller attachment now happens on first use of the scroller instead.

glayout solves all of that  ;-) and its all running over VID and 
does very few hacks...

really, you should look into glayout, you are the kind of user which 
would "get" it very quickly and you'd be very happy about it.

your advanced styles work in glayout... I've converted the toolbar 
in 15 minutes last time I tried...

I'll see what can be used, thanks.

Glayout is a complete system though... its hard to take things out 
since its takes charge of VID and expects all of it to be there. 
 the layout depends on the api, which depends on the few patches, 
etc.

but it still use the normal VID stylesheet for example for changing 
your styles... I like to see it like an invisible drop-in for VId 
which replace the layout engine and adds A LOT of needed functionality.

your glayout-demo.r in rebol.org has no author listed

really? that is strange...

Glayout has been updated a few times... I really should update the 
version on rebol.org.   a few little layout tweaks and many new features 
added since that version...

good idea. I have a hard time finding it via google.

you have trouble finding glayout?

Henrik: "This worked well for faces that are not at the base level 
for the window, but how do you specify the parent-face for base level 
faces, as the window face does not yet exist?"

-- Yes it does. It is called new-face, and is created right near 
the top of layout, and returned (of course) at the bottom.

but my current version has a display bug in the button looks when 
pressed... I keep changing the looks for every application, so it 
doesn't get fixed in the main lib.

A quick search on "rebol glayout" reveals the rebol.org version, 
the docs for REBOL's own LAYOUT and some mailing list posts about 
glayout.

There is a single link to STEEL which gives me a 404.

which is why it hasn't  been updated for a while.  the one on rebol.org 
is the last official release.

its just old, but works with the rebol demo, (also on rebol.org)

it works well, it just doesn't have some of the latest features and 
very specific layout fixes.

rebol demo
 I meant  "glayout demo"

if you download the glayout demo, it will download the glayout and 
slim, for you..

(when you run it, of course)

Anton, I think I tried that, but that screws up other things: Parent-face 
in LAYOUT is set to none for some reason, and I'm betting it's because 
VIEW does something here. Anyhow, setting parent-face separately 
works perfectly, so I'm keeping that for a while.

Maxim, does glayout.r contain a complete style set or is it separate?

it includes many of the basic VID styles as default...   near the 
end of the file, you will will see a big style block.  which basically 
adds the glayout framework on top of the previous master VID stylesheet.

it has group styles, including scrollpane which automatically adds 
V/H scrollbars for nested content.

you will be amazed at how similar it is to R3 view... (by what I 
have seen of it.)

if not in looks, in layout engine capabilities.

Henrik, oh well. But I figured out a clever hack you can place in 
init to set parent-face.

window: layout [my-face: box with [append init [parent-face: does 
[parent-face: does [get last second :layout] none] none]]]
my-face/parent-face = window ;== true

maxim, Are you close to revealing your new website?

Anton, it looks like I'll have to try setting parent-face again. 
I have another situation with the resize engine that really requires 
init to have parent-face set. Grr...

nope... no good. reverted to different strategy. it gives more overhead, 
but it will have to do.

Henrik, what strategy are you using?

I was thinking you could redefine layout, since you have collected 
a fair few GUI functions and styles together. When it comes down 
to it, it layout doesn't do what you want, redefine it. (And I am 
guilty of not doing this for so many years too.)

Anton, I've not had the energy to take a look at what can be changed 
with LAYOUT, so what I do is try to stay within reasonable limits 
of what it can do and stay away from radical changes.


One thing to change, if it were, would be that INIT would be less 
limited, if it was run as a separate pass after initial layout instead 
of right when the face is created, but this may cause problems for 
styles that use INIT to alter the size and offset for the face, as 
well as produce subfaces that need to be initialized first. Also 
LAYOUT is not recursive and INIT may be run at very different times. 
At this time, INIT is limited, but you have a pretty good idea of 
when it's run.


In VID3.4 this is not a problem, since there is both an init and 
post-init action possible, so if I were to get rid of this problem 
in the right way, I might end up rewriting over 100 kb of well-functioning 
code.

Hmm.. well why not add a post-init to layout ? This would not affect 
any existing code, so you could migrate to it at your leisure.