World: r3wp

Here's another issue:
rebgui 0.2.4 defines a new global word 'edit

  This interfered with my custom edit function, which I use to launch 
  my favourite editor.
  I'm not changing it for you ! :)

  This is an example of the problem of adding words to the global context 
  without doing
  an environmental impact study first.

  The user should be given the choice whether to export your words 
  to the global context or not.
  But probably most of them don't need to be out there at all.

  My advice is to add only these words to the global context: [

 ctx-rebgui display show-text show-data show-title splash request-color 
 request-date request-file
  ]
  
  --- rebgui.r ---
  
	CTX-REBGUI: context [

		...

		edit: none
		widgets: none
		requestors: none
		display: none

		foreach [word file][
			edit		%rebgui-edit.r
			widgets		%rebgui-widgets.r
			requestors	%rebgui-requestors.r
			display		%rebgui-display.r
		][
			if none? word [set word do file]
		]
	]

	;if not value? 'edit [do %rebgui-edit.r]
	;if not value? 'widgets [do %rebgui-widgets.r]
	;if not value? 'requestors [do %rebgui-requestors.r]
	;if not value? 'display [do %rebgui-display.r]

	; export DISPLAY and the accessor functions to global context
	foreach word [display show-text show-data show-title splash][
		set word get in ctx-rebgui word
	]


  And each file no longer has a *named* context:

  --- edit.r ---

	REBOL [...]
	
	context [...]


  The above changes should mean few changes to the rebgui code. For 
  example, the body

  of the display function refers to the widgets context, but this is 
  still accessible
  because both DISPLAY and WIDGETS are inside ctx-rebgui.

ChristianE

 1) LED color / design choices. Agreed. Can anyone point me to where 
 this has been solved? Or suggest a design alternative?

 2) Red, Green, Blue. These were example LED titles (much like the 
 previous "One Two Three" example) *not* a statement about the actual 
 LED colors. ;) If the example's that confusing I'll change it.

 3) Sliders / Scrollers. Agreed. The priority has been to get a complete 
 set of widgets, *then* ensure each is functionally complete, and 
 *then* ensure they are aesthetically pleasing as a whole and in their 
 own right. As I'm no graphics artist, I've taken the easy approach 
 at first by mimicking what I'm familiar with: Windows XP.

The words I don't think need to be global are: [sld slm slc slw edit 
widgets requestors]
(and even the ones I have set out above I would scrutinize more.)

Excellent suggestion and far better than the approach I was going 
to use to solve this problem! ;) I'll incorporate it in the next 
build.

cool :)

One consideration though; how would this scheme be extended to handle 
SDK use of #include's (as folks using the SDK won't want to ship 
rebgui-*.r files with their executables)? Oh for a #do-include command! 
;)

edit:
#include %edit.r

? dunno, don't have SDK myself.

I think this may work (not sure, can't test):
sdk?: is-this-sdk? ; <--- need to find out a real flag

set 'edit	do #either [sdk?][#include %rebgui-edit.r][%reb-gui-edit.r]

set 'widgets	do #either [sdk?][#include %rebgui-widgets.r][%rebgui-widgets.r]

set 'requestors do #either [sdk?][#include %rebgui-requestors.r][%rebgui-requestors.r]

set 'display	do #either [sdk?][#include %rebgui-display.r][%rebgui-display.r]

sdk?: #do [true] false

Ashley, you may have a look at this modified LED stuff:

ah heck, that won't work....

;	15-Mar-2005 Pascal Lefevre
	;	27-Apr-2005 Pascal Lefevre

    ;    4-Jun-2005 Christian Ensel (minor color and shape suggestions)
	led: make face [
		size:	-1x4

  effect:	[draw [pen edge-color fill-pen window-color box 0x0 0x0]]
		font:	default-font
		para:	make default-para [origin: as-pair base-size 2]
		feel:	make default-feel [
			redraw: func [face act pos /local colors] [
				if act = 'show [
                    colors: reduce case [
						any [face/data = 1 face/data = true]  [
                            [btn-text-color btn-text-color]
                        ]
                        any [face/data = 0 face/data = false] [
                            [edge-color btn-up-color]
                        ]
                        true [
                            [edge-color white]
                        ]
                    ]
                    face/effect/draw/2: colors/1
                    face/effect/draw/4: colors/2
				]
			]
		]
		init:	does [
			if word? data [data: to logic! data]

   if negative? size/x [size/x: 1000000 size/x: 4 + para/origin/x + 
   first size-text self]
			effect/draw/6/y: unit-size 
			effect/draw/7: as-pair unit-size * 3 unit-size * 2,5
		]
	]

I gave the LEDs a slightly different shape to make them look different 
from the check boxes, to make it clearer that they are informative 
only and not meant to accept user interaction.

I dropped my previous color suggestions in favour of using only colors 
you've allready featured.

The "one color - different shades" approach really should do for 
most users, I think.

CTX-REBGUI: context [

	...

	edit: none
	widgets: none
	requestors: none
	display: none
		
	#do [edit: do #include %rebgui-edit.r]
	if none? edit [edit: do %rebgui-edit.r]
	#do [widgets: do #include %rebgui-widgets.r]
	if none? widgets [widgets: do %rebgui-widgets.r]
	#do [requestors: do #include %rebgui-requestors.r]
	if none? requestors [requestors: do %rebgui-requestors.r]
	#do [display: do #include %rebgui-display.r]
	if none? display [display: do %rebgui-display.r]
	...

]


CTX-REBGUI: context [

	...

	edit: none
	widgets: none
	requestors: none
	display: none
		
	smart-do: func ["helper function to reduce repetition"
		ignored [issue!] block [block!]
	][
		if none? get first block [do replace copy block [#include][]]
	]
	smart-do #do [edit: do #include %rebgui-edit.r]
	smart-do #do [widgets: do #include %rebgui-widgets.r]
	smart-do #do [requestors: do #include %rebgui-requestors.r]
	smart-do #do [display: do #include %rebgui-display.r]
	...

]

Oops! I think smart-do will not work (because preprocessor lines 
are removed ?) Ugg.. Anyway try the first way...

The preprocessor is freely available, even to those that don't license 
the SDK. You could just have everybody use it whether they use the 
SDK or not, and have one code base.

Very impressive demo. When I run it from rebview1247031.exe, then 
I fill the  Field\Password box, like just type in lots of characters, 
as I move the cursor over the field labels, they disappear. I can 
do this to all the tab field labels.  The words wont reappear until 
I start deleting the password characters and I move the cursor over 
the labels again.

Is there any reason why the text in a password field can not be selected 
with the mouse?

Nor, can it be restored with ctrl-z

Where's this memory leak arising from?

Running latest view .. and tour.r reports 6766kbs when I start it 
.. and doing nothing at all, memory use keeps climbing.  HIt 10000kbs 
at 30 mins or so before I killed it.

jumps up 8 or 9 kbs each time

not related to this leak is it .. http://www.rebol.net/cgi-bin/rambo.r?id=3593&
 which is apparently fixed in the latest releases ( according to 
Gab )

though I still see it as per  this http://www.rebol.net/cgi-bin/rambo.r?id=3557&

Earlier builds of RebGUI used the following code to minimise the 
problem:

	context [
		show*: :show
		set 'show func [face [object! block!]] [show* face recycle]
	]

which kind of points to the GC as the problem.

I see.. so if you wait long enough, it gets collected

On GC/memory leak : the events system allocates this memory - disabling 
events stop this leak, and changing the timers rate change the allocation 
rate. The trigger to release the memory is quite high, so it's takes 
a long time to be collected. Regardless of 'stats memory usage indication, 
it seems that Windows only gets the memory back when the REBOL windows 
are minimized.

So, unattended, this could crash windows?

With regards to #includes (from Anton's examples above), the following 
is about the best workable solution I can come up with at the moment:

	ctx: #include %include.r
	if issue? ctx [ctx: do %include.r]

Not a memory leak. Typical gc-behavior to improve performance. you 
would not going to empty your trashcan everytime you throw something 
in, you collect only once a day, no? expect some mb to be allocated 
that way, if it goes more then 5-8mb over initial value something 
is wrong. should maybe stated in a FAQ somewhere, confuses all people.

switch on recycle/torture, thats what happens if you empty the trashcan 
immediate.

4mb seems a lot just doing "nothing" ...

gains speed. have a look on how much your os spends to file-buffering 
in comparison.

its <5% of typical memory, <100% of minimal footprint, <30% of 15mb-app.

but maybe we could have a switch to set that size, for stealth-mode.

Question for the bind experts out there. Given two files (named %include.r 
and %test.r respectively):

	REBOL []

	context [
		a: "A"
		b: does [print reform ["Value:" a]]
		c: does [print reform ["Value:" d]]
	]

	REBOL []

	RebGUI: context [
		d: "D"
		ctx: #include %include.r
		if issue? ctx [ctx: do %include.r]
	]

	RebGUI/ctx/b
	RebGUI/ctx/c


How do I bind %include.r to the RebGUI context such that it can see 
'd (as the #include successfully allows).

ctx: do bind load %include.r 'self

another option is to embedd a smaller and faster "prebol" in rebgui 
and build everything on startup, then doing it altogether.

; Here's a solution to the dual-use 'load:

load-include: func [include [any-block!]][

    either parse inlcude reduce [to-issue 'include file!][load include/2][include]
]


; It acts like 'load, except returns a prebolled block, or loads 
a prebol file:

load-include [#include %include.r]

REBOL []

load-include: func [include [any-block!]][

    either parse inlcude reduce [to-issue 'include file!][load include/2][include]
]

RebGUI: context [
	d: "D"
	ctx: do bind load-include [#include %include.r] 'self
]

RebGUI/ctx/b
RebGUI/ctx/c

And yes, there are typos there, Windows doesn't seem to keep up with 
my keyboard.

prebol: func [code "changes code" /local p f] [
	parse code rule: [
		any [
			p: #include set f file! (
				p: change/part p load f 2
			) :p
			| into rule
			| skip
		]
	]
	code
]
; changes code, use copy/deep if needed

t1: now/precise
save %test.r [The embedded stuff]
p: prebol [Hello [World #include %test.r here] we are ]
print[difference now/precise t1]

can you benchmark this? seems to be fast enough. than you can use
do prebol [ .. ]
as main-script

(remove the "changes code" in header, moved to comment..)

has bug, does not prebol subfiles correctly.

prebol: func [code /local p f rule] [
	if file? code [code: load code]
	parse code rule: [
		any [
			p: #include set f file! (
				p: change/part p prebol load f 2
			) :p
			| into rule
			| skip
		]
	]
	code
]
; changes code, use copy/deep if needed

t1: now/precise
save %test.r [The embedded and #include %test2.r stuff]
save %test2.r [Subembedded]
p: prebol probe [Hello [World #include %test.r here] we are]
print [difference now/precise t1 newline mold p]

then in sdk
 prebol: func[code][code]
and you are done too. (not tested)

last version in %short-prebol.r on developer