World: r3wp

good work Ashley!

- changing the "foreach [style facets] spec" loop in display.r to 
something like "parse spec [any [opt [set varname set-word!] set 
style word! opt [set block block! (...)]]" would allow the use of 
"return" in place of "return none" and let users to define var names 
for faces in definition block.

- found the problem with /View 1.2.1 : i did define 'as-pair as func 
[x y][add 1x0 * x 0x1 * y], and it crashes here, but it works with 
as-pair: func [x y][to-pair reduce [to-integer x to-integer y]]

VID is great for prototyping, and for apps where saving a little 
memory and speed aren't critical. So, I think VID is still a valid 
prototyping tool because you don't know what you want to build the 
first time out (in many cases) and it allows you to play around more, 
with less effort. Now, there's no good reason you couldn't use the 
VID dialect, limit yourself to what REBGui can do, and use the VID 
spec to generate REBGui code. Best of both worlds.

RebGUI 0.1.1 released ( http://www.dobeash.com/files/RebGUI-011.zip
) and View facets documentation updated from feedback ( http://www.dobeash.com/it/rebgui/facets/
).

Anton

 1) VID working with RebGUI ... no reason why not (haven't tried it 
 yet though)
	2) display help cleaned up
	3) Minimum window size ... can be set to 0x0 with /limit

 4) Progress bar using effect ... agree. I want to emulate the WinXP 
 progress bar with image / effects

Graham

 1) Intent ... Ammon & Gregg answered this already; bottom line - 
 whatever folks feel more comfortable with

 2) Positional references were only meant to be for sub-faces of a 
 widget ... documentation corrected
	3) display now accepts set-words as per Vincent's code

Vincent

 1) Changed all occurences of as-pair to to-pair so your prob is fixed 
 (and RebGUI can now run from rebface)

 2) Change 'foreach to 'parse ... done (with the benefits you listed)

Shadwolf

 1) "Ashley is one of the few VID artist" ... thanks, but I defer 
 to Chris in all matters graphical! ;)

Gregg
	1) Agreed. (Need I say more? ;) )

Out of interest, I started rebface (REBOL/SDK) and did several recycles 
before looking at its process size under WinXP. Did the same thing 
again but after do'ing %styles.r and %display.r, and repeated the 
procedure for %view.r (the SDK func that pulls in VID). Results were:

	rebface	3,540 KB
	RebGUI	3,628 KB
	VID		5,224 KB


So I can say that (at this early stage) RebGUI seems to use 88 KB 
while VID uses 1,684!

I guess we will have to see what happens with the use of more complex 
faces

Ashley, I don't mean to undo your work, but perhaps it is easier 
to add a compatibility layer for functions missing from older releases? 
eg.
if not value? 'as-pair [as-pair:  <insert source as-pair here>]

That will shrink your code and user code down a bit.

I'm using the SDK rebview 1.2.10 as my baseline. The only three mezz 
funcs I have had to abandon so far are:


 as-pair		; better off using to-pair reduce [x y] as I'm dealing with 
 integer-based co-ords anyway

 center-face	; was used once in the 'display func and it's inline 
 representation is more efficient

 span?		; used in render-rich-text with a check as per your suggestion 
 (render-rich-text is used from REBOL/VIew more often than not)


It's only the RebGUI code that has to conform to these restrictions; 
user code can use whatever mezz funcs and run under whatever REBOL 
version they want. I used the same design philosophy with RebDB (if 
it runs under SDK/rebbase, it will run anywhere). In the majority 
of cases the extra mezz funcs are more usefull at the user code level 
anyway.

Once official version will came out all actual 1.2.X version will 
be deprecated ...

Agreed. But we have to work within the restrictions of today not 
the promises of tomorrow. ;)

Hum Maybe betting hardly on futur will show the yet hudge possibilities

Ammon, regarding your drop-down style.  Is it possible to also allow 
the field associated with the drop-dow to accept user data?  Such 
as a case where the provided drop-down contents does not contain 
the value the user needs to enter.   Of course it would be useful 
to also store that item into the drop-down for future reference, 
which is easily done dynamically by populating the drop-down with 
any value recorded in that field in the data file.

Hello, Long time no talk. Is there a way to tell the request-file 
to open up in a specific directory?

request-file/file %/c/mozillaFirefox/

Thanks Anton. That makes sense when I see it. I was thinking it had 
to be a file and not just a path. Cool. That will have me a lot of 
clicks. : ^)

Here's a scenario that has me puzzled, not sure if I am doing something 
wrong, or if I ran into a bug

rebol[]


last-sgrp: copy ""		;global used to keep track of last selected button 
in sgrp window

reset-toggles: does [

 t1/state: t2/state: t3/state: t4/state: t5/state: t6/state: t7/state: 
 t8/state: false
]

two-digits: func [num][
	either 10 > num [num: join "0" num][num]
]


get-report-date: function [/delim][report-day day rsd today s e day-diff][
	report-day: 6			; 6 = Saturday, start day of report
	today: now/weekday
	day-diff: report-day - now/weekday

 rsd: now + day-diff		;rsd = report start date		;'difference function 
 used to do date math
	either delim [

  s: join rsd/year ["/" two-digits rsd/month "/" two-digits rsd/day]
	][
		s: join rsd/year [two-digits rsd/month two-digits rsd/day]
	
	]
	e: rsd + 6
	either delim [
		e: join e/year ["/" two-digits e/month "/" two-digits e/day]
	][
		e: join e/year [two-digits e/month two-digits e/day]
	]
	report/text: join s [" - " e]
	show report
]

clear-entry: does [
	probe t1/text probe t2/text probe t3/text probe t4/text
	print "-------"

    clear-fields bx1			;;;;;;;;;;;; Error of disappearing toggle values 
    starts here
	probe t1/text probe t2/text probe t3/text probe t4/text
	print "======="
    ;clear-fields bx2			;;;;;;;;;;;;
    ;create-dt/text: form now
    ;update-dt/text: form now
    unfocus
    show dex
]

new-ticket: does [
    ;store-entry			;stores existing entry
    clear-entry			;clears fields for new entry
    if last-sgrp <> "" [application/text: last-sgrp]
    environment/text: copy "prod"
    show [application environment]
    focus application
]

dex-pane1: layout [
	across
	label "Support Group:"	application: field return
	label "Environment:" 	environment: field return
	label "Report Dates:"	report: field return
	btn "New Ticket" [new-ticket]
	pad 20 btn "Reset Toggles" [reset-toggles]
]

dex-pane2: layout [
	across
	label "Search Criteria:"

 t1: tog "o79" [write clipboard:// join "se sa**/" [last-sgrp: t1/text 
 "ca datp/" get-report-date/delim]]

 t2: tog "p23" [write clipboard:// join "se sa**/" [last-sgrp: t2/text 
 "ca datp/" get-report-date/delim]]

 t3: tog "o88" [write clipboard:// join "se sa**/" [last-sgrp: t3/text 
 "ca datp/" get-report-date/delim]]

 t4: tog "p11" [write clipboard:// join "se sa**/" [last-sgrp: t4/text 
 "ca datp/" get-report-date/delim]]
]

dex: layout[
	bx1: box dex-pane1/size
    bx2: box dex-pane2/size
]

bx1/pane: dex-pane1/pane
bx2/pane: dex-pane2/pane

view dex

Here is the scenario to replicate my problem where Toggle button 
labels are being removed....

1.	Select the 'New Ticket' button
2.	Select the first Toggle button
3.	Select the 'New Ticket' button
4.	Select the second Toggle button
5.	Select the 'New Ticket' button

At this point, the label for the first toggle button disappears.

The problem seems to be with the 'clear-fields' function in the Clear-Entry 
function I created.  Commenting out this line allows the buttons 
keep their label as expected.

>> help clear-fields
USAGE:
    CLEAR-FIELDS panel

DESCRIPTION:
     Clear all text fields faces of a layout.
     CLEAR-FIELDS is a function value.

ARGUMENTS:
     panel -- (Type: object)

So, I have either not defined the bx1 and bx2 faces correctly as 
panels, or the function is not limiting itself to only affect the 
panel provided as  the parameter to the function

By the way, if the code looks familiar, it's derived from code in 
Carl's Rebodex application

What's the purpose of the "local" folder in View/Desktop? I don't 
see any mention of it in http://www.rebol.com/docs/desktop.html

never mind.

Brain the size of a walnut, I swear.

Poking around a bit in the View executable (1.2.10.3.1) I "discovered" 
the following undocumented words (and have assumed they belong to 
the indicated facet based on the position of other known words). 
I've worked out what a few of them do, anyone care to comment on 
the others (or point to documentation if covered elsewhere).

Draw
--------
fill
font

Effect
--------
dither
alphamul
anti-alias
func
merge		; I know this was covered, just can't find where
chisel
	view layout [box 20x40 effect 'chisel box 40x20 effect 'chisel]
round
	view layout [box 20x40 effect 'round box 40x20 effect 'round]

Feel
--------
inactive
active

Options
--------
parent
	view/new a: layout [size 400x400]
	view/new/options layout [size 200x200] compose [parent (a)]
	do-events
min-size
	view/options layout [box blue 400x400] [resize min-size 200x200]
activate-on-show

window/feel: make window/feel [detect: func [face event][if find 
[active inactive] event/type [print event/type]]]

merge is something to do with combining with faces below. It allows 
partially transparent faces. I found I needed it a lot. Sorry, but 
I can't remember exactly its behaviour right now.

view/new layout [b: box effect [draw [font none text "hello"]]]
wait 2
b/effect/draw/font: make face/font [size: 40] show b

do http://www.lexicon.net/antonr/rebol/demo/demo-alpha-blend.r

; Yep, 'merge instructs the effects engine to compose effects using 
underlying faces:
dots: http://www.ross-gill.com/r/grid-teal.png
img: http://www.ross-gill.com/r/find-file.png
view center-face layout [
    backtile dots
    image img
    image img effect [blur blur blur]
    image img effect [merge blur blur blur]
]

'merge was added in 1.2.8 or 1.2.10. It was by default in 1.2.1 AFAIK

'fill : to fill a form

view layout [box 100x100 effect [draw [pen 255.0.0 fill-pen 0.0.255 
polygon 0x0 0x90 90x90 fill 50x50]]]

'activate-on-show : like the name said.

There is different behaviour with it. I notice that on Win2k, the 
window come to front but don't take the window focus. sometimes, 
the window stay behind and just the task button blink (the current 
active window remain active).

But on WinXP, the window become active and take the window focus. 
Very annoying when you are typing something.

I use it to bring a window to top when there is something new (lecture-forum 
script).
I don't w=know how it works on Linux.

merge (with Chris's example) behaves differently under 1.2.10 and 
1.2.48 (later is correct)

fill (DideC's example) dosen't seem to do anything (same result by 
removing the "fill 50x50" bit)

I know that fill is not working on AGG alpha version (problem due 
to antialias).
On what version did you found 'fill not working ?

what=witch

My example give different results :

on 1.2.1, 1.2.8 and 1.2.10, fill is OK, but there is not the red 
line.
on 1.2.48, it's ok

'min-size : I missed that. Nice thnigs to know :-)

Tried on both 1.2.10 and 1.2.48. Note that the lack of a red line 
on 1.2.10 is due to a known bug with polygon (fixed in 1.2.48).

On 1.2.48 I can't see a difference between:


a) view layout [box 100x100 effect [draw [pen 255.0.0 fill-pen 0.0.255 
polygon 0x0 0x90 90x90 fill 50x50]]]

b) view layout [box 100x100 effect [draw [pen 255.0.0 fill-pen 0.0.255 
polygon 0x0 0x90 90x90]]]

So I'm still not sure what 'fill is supposed to do. ;)

same on 1.2.1 - DideC, are you sure it's not 'flood? in your example, 
it's specifing the fill-pen who fills the 'polygon (by default, fill-pen: 
none)

Yes, I'm wrong. 'fill is ignored on 1.2.8 and 1.2.48 :

view layout [box 100x100 effect [draw [pen 255.0.0 fill-pen 0.0.255 
polygon 0x0 0x90 90x90 fill 90x0]]]

 view layout [box 100x100 effect [draw [pen 255.0.0 fill-pen 0.0.255 
 fill 0x0 0x90 90x90 90x0]]]

Not meaning to be a pest ;) , but I could really use some help with 
the problem I posted above (my latest posts).  It's a problem with 
button text disappearing when using a rebol function.

You're correct -- it is 'clear-fields.  When you set the text value 
for the 'application field, it comes directly from the face/text 
of the last clicked toggle button, ie. it is the same value.  When 
you 'clear-fields the application field, it does 'clear on that value 
clearing the field and the last clicked toggle.  A quick fix would 
be:
    if last-sgrp <> "" [application/text: copy last-sgrp]
or
    if last-sgrp <> "" [change clear application/text last-sgrp]

; the latter retains the same string value for the application field...

(I make that line 49...)

; A bonus tip -- each of the tog actions in dex-pane2 are essentially 
the same.  You could clean up as follows:
tog-action: [
    write clipboard:// join "se sa**/" [
        last-sgrp: face/text "ca datp/" get-report-date/delim
    ]
]

dex-pane2: layout [
    across
    label "Search Criteria:"
    t1: tog "o79" tog-action
    t2: tog "p23" tog-action
    t3: tog "o88" tog-action
    t4: tog "p11" tog-action
]

Brock, check out the source of CLEAR-FACE, and you will see that 
it tries to do  
	face/access/clear-face*

, therefore you should look at the access object to see what it really 
does:
	layout [text with [?? access]]

There, you will also see RESET-FACE, which would have also solved 
your problem

because it does a COPY as well. I think COPYing to start with as 
Chris showed is a safer way, though.

Chris and Anton, thanks for taking a look and making the above suggestions. 
 It looks like there is a simple solution mentioned by Chris and 
I will study the additional suggestions from Anton.  Thanks again.

I didn't get to code cleanup you suggested, but it was on my mind, 
I didn't want to post it that way - you caught me  ;)