World: r3wp

if 'face in the do-block refers to the layout, how to get this inside 
a button action block?

I want button [ unview/only parent-face ]

unview/only face/parent-face

Hi Graham, in my example-2 the the right-most text-lists keep their 
widths, and the lower text-lists keep their height, and the upper 
left text-list is maximized to fill the size of the window.
I would like to have equal sizes for all text-lists.

I am creating templates which I load up and display.  These templates 
contain some variables for label widths etc.  I have to bind the 
template to the variables, but then if I do that, operators such 
as '- have no context.  do I have to redefine '- and '+ etc?

Ingo:


is there a reason, that display opens the windows, but does not start 
do-events?

 ... we can't assume the "first" window automatically needs to start 
 the event loop. Perhaps the display is being assigned to a word and 
 cached for later use? Or the display is done early in the script 
 for lots of subsequent initialization and *then* needs to fire up 
 the event loop. I personally like having to code it explicitly as 
 it then stands out - "We are starting the event loop HERE".

Is it possible to get the window size?
 ... display [button do [ws: face/size]]

Is it possible to set an own resizer function?

 ... No, you'd have to change a lot of code to implement your own.

I would like to have equal sizes for all text-lists.

 The RebGUI resizing model is pretty basic, it supports one resizeable 
 widget in each axis (horizonal and vertical) with any number of offset 
 adjustments (the #XY directives). More advanced schemes (such as 
 proportional or percentage based) are possible, but significantly 
 harder to implement (and require size/state information to be retained).

Graham, I'd thought using () in the template would enable RebGUI 
to evaluate the expressions automatically for you. Do you have a 
small example of what you're trying to do?

Robert: Your rev#21 changes to rebgui-edit.r nuked my rev#19 and 
rev#20 changes ... but the good news is that they collectively constituted 
the following line in the insert-char function:


 unless any [insert? tail? view*/caret newline = first view*/caret] 
 [remove view*/caret]


Should I put that line back in a new rev or do you want to bundle 
that in with any additional changes you are working on?

Ashley, an imperfect example ...

do %rebgui.r


test: {label "This is a label" (width) radio-group data [ "-" "+" 
] return label "Another label" (width - 5)}

go: func [ template [string!] 
	/local width
][
	width: 20
	template: compose bind to-block template 'width
?? template 
	display "testing ..." [
		(template)
	]
]


go test

do-events

it comes a cropper on the "-" ... ** Script Error: - word has no 
context
** Where: go
** Near: width - 5

test: {label "This is a label" (width) radio-group 24x4 data [ "-" 
"+" ] return label "Another label" (width - 5)}

go: func [ template [string!] 
	/local width
][
	width: 30
	template: compose bind to-block template 'width
	display "testing ..." compose/deep [
		(template)
	]
]

go test
do-events

Always a problem when working with string representations of a dialect. 
Try:

go: func [ template [string!]][
	width: 30
	display "testing ..." load template
]


Although this depends on width being global. But since you're working 
with strings anyway, why not forget binding and go with simple variable 
substitution as in:

	...
	replace/all template "%width%" 30
	...


with appropriate markers to prevent accidental partial replacements.

what's the safest way to allow users to create templates in rebgui 
and not allow them to put executeable code in it?

which is why i was not using 'load

Safest way is to put a front-end on that precludes free-form string 
entry! ;)

I know that you do that - with a gui layout editor.

seems a lot of hardwork though!

reset: func [ value /local type ][
    foreach f face/parent-face/pane [
        if f/type = 'group-box [    
            foreach widget f/pane [    
                type: form widget/type
                switch type [
                    "field" [ show-text widget copy "" ]
                    "area" [show-text widget copy "" ]
                    "edit-list" [ show-text widget copy "" ]

                    "radio-group" [ widget/select-item value]                
                ]
            ]    
        ]
    ]
]

this is a function to reset some of the widgets inside a group-box 
.. doesn't work though

** Script Error: Cannot use path on none! value
** Where: reset
** Near: foreach f face/parent-face/pane [
    if f/type = 'group-box [
        foreach widget f/pane [
            type: form wi...

this function is an action for a button inside the same layout

this code though works if included as is inside the button action 
.. but not when used as a function

radio-group/select-item 0 doesn't work ... doesn't allow you to set 
the radio-group to a state where none is selected

rebgui-edit.r: We have merged it and IIRC Cyphre wanted to sync it. 
But I check the repository.

what's the safest way to allow users to create templates in rebgui 
and not allow them to put executeable code in it?
 http://polly.rebol.it/test/test/game/use/game/unbind.r

(needs testing)

exactly how does it work?

makes an empty context for all known words and binds the loaded block 
to it. including words inside objects and functions.

and could be extended to keep some words bound.

in a way like to-block with hooks.

actually the way it works now, since I have to bind the block to 
my local variables, doesn't that mean I have adequate protection?

Is there a way to control the sort display for a table?

programatically?

yeah

no, not that I know.

so, have to simulate mouse clicks on the table header I guess

Take a look at the source. I think it's a flag and if you than do 
a /redraw it should be sorted.

Ok.

I had a very quick glance at RebGUI widgets. Would it be possible/easier 
to implement LIST-VIEW as a widget?

You're welcome to try ...

Henrik, I suggest first convert your list-view from being based on 
BOX to being based on FACE. Then it's slightly less work to port 
to rebgui.

alrighty then

also, I don't think it's any easier to create a list style using 
VID or REBGUI - the same basic issues are there, but porting to rebgui 
is fairly straightforward. Just keep the rebgui source handy as you 
will need to dip into it a few times.

http://home.wilddsl.net.au/anton/rebol/rebgui/differences-from-VID.txt

Henrik, looking forward to see your first version of the list-view 
widget.

please don't hold your breath :-) I've barely played with the RebGUI 
demo

That's the soft way of community pressure ;-)) I'm quite sure it's 
not that hard to get into RebGUI development.

Is tree-view planned Robert?

It's mostly done (90%) as there is a complete tree in the drop-tree 
widget. We just didn't extract the code into a stand-alone widget 
as I don't need it at the moment. Feel free to go for it.