World: r3wp

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

Ashley roadmap: 1) set of widget complet (what widgets are in it 
?)  2) functionnality of this set (what they do how we use them ?) 
3) esthetic of the widgets is dicted by the low people working on 
RebGUI and the nececity to make a simplier set of widgets. The fact 
that AGG was not official have make diffucut to put in line a good 
estetical consept. As REbGUI philosophy is to be light and easy  
we can't make a lot of heavy imge insertion and image drawing

the table widget says one can select a row, but it doesn't do that 
for me.

Not implemented yet.

Here is a preview of what the roadmap will look like: http://www.dobeash.com/it/rebgui/roadmap


Not withstanding the fact that all the blanks need to be filled in, 
if there is anything else you believe should be covered / included 
then just holla.

request-dir

which I see is now implemented in the latest views

AS I propose to orgenise the devs we need as we are in stage one 
to have the overall list of the widgets that ashley wants to have 
in rebgui. We can make it on dokuiki rebolfrance.info a little table 
with widgets name | widget description | author that takes in charge 
the dev of this widget | dev stage % | integrated to rebgui |

for example for listview this will be: listview | multi column full 
resizable and multi widgets type support | Shadwolf | 98% | NO

Ashley if you want you post me here the list of remaining list you 
want to see in rebgui then I build a dedicated editable page in the 
dokuwiki rebolfrance.info  :)

the idea is that any programer taht are working on widgets can change 
the information related to his widget and for people to have a quick 
over view on the remaining dev effort and the progression of this 
work  ;)

Okay to take advance I yet created the page on the docuwiki ;)

http://www.rebolfrance.info/articles/regui-cooking-widgs

Roadmap updated. The only thing I have left to do is fill in all 
the "Features" and "To Do" entries, which I need to think on for 
a while.


shadwolf: Good work, you can get the complete widget set from the 
updated roadmap (table 3.4). With regards to the DokWiki ... build 
it and they will come, but you may want to refresh folks memory (mine 
included) with how to register / access (point form summary). Also, 
it's not just widgets that need more work ... localization could 
do with some native language assistance. ;)

No need to register to post .. Well it's better that's sure ... So 
to register go to this page http://www.rebolfrance.info/rebolfrance.info?do=register
you fill the form with login, Real Name and e-mail.

Once you have filled the form you need to send your password by mail 
to the administrator of the dokuwiki :) (register have some problems 
...so we make it manually ...)