World: r3wp

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 ...)

* Open rebol console and type :

print next lowercase mold checksum/method "mon-password" 'md5

    * Then send an email to [webmaster-:-rebolfrance-:-info] :
          o Utilisateur:  nickname (registred one)

          o Password: {9c3f8c1d181f8d7c4d2919d801943c51} (can be the raw password 
          too)
          o Nom complet: Real Name
          o Email: [mon-email-:-mon-serveur-:-com]

That's all ;)

see the bottom of this page to have this information http://www.rebolfrance.info/utiliser_ce_site

I  completed the page I added the pending widgets  ;)

in the roadmap we have the overall widgets  informations in the dokuwiki 
we have the on cooking widgets  :)

Ashely you can make a link betwin the roadmap and the dokuwiki wiki 
this way you give too people the complete information ;)

dokuwiki  can collect the codes too ;) like I made for list-view 
 :)

Ashely if you have any widget need in plus of those yet listed just 
add them to the table  in the dokuwiki ;)

Ashley I make the spanish.dat for rebgui  you can find it there http://shadwolf.free.fr/spanish.dat

Ashley I have one little ask why the tabpanel with scrollable header 
Have not been inserted to rebgui until now  ?

Ashley how can we set global event system processing for a display 
?

1) dokuwiki link: will add.

2) spanish.dat: thanks, excellent work. Added to next build and roadmap. 
Anyone for German? Robert?
3) tabpanel with scrollable header: low priority.

4) global event system: more information; what is the requirement?

2) German: Yes, no problem. Does the current .DAT contain everything 
that needs to be translated?

run trhu on-line translators and you are done :-)

Ashley, you found the issue way too. :) Chris' function looks very 
good.
Here's another way:

 edit: do either any [#do [false]] [%rebgui-edit.r][#include %rebgui-edit.r] 
 ; (false is actually not needed)

(*possible* way, I should say. I haven't tested that, and it needs 
bind in ctx-rebgui 'self.)

I eventually solved it with:

	ctx-rebgui: context [
		...
		edit: #include %rebgui-edit.r
		if issue? edit [edit: do bind load %rebgui-edit.r 'self]
		...
	]

it's two lines as opposed to one, but *much* clearer! ;)

Robert: go with the current .DAT. Don't forget system/locale/colors 
if you feel that is important too (or are folks used to English color 
names?).


Pekr: on-line translators are good for Months / Days, but many computing 
words / phrases don't have a one-for-one literal translation

Ashley, I was trying to reduce the number of variable references, 
eg. in my last (possible) way, there is one instance of EDIT and 
two instances of the filename. In your last way, there are three 
instances of EDIT, and two instances of the filename. Anyway, I agree 
it's easier to understand.

Yep, that was my goal too -- to simulate 'load that it might be easier 
to read when going back to it.

Fixed the problem (disappearing label text after a field scroll) 
that Colin identified. Just needed to change "para: default-para" 
to "para: make default-para []" for editable widgets (as the new 
edit feel changes "para/scroll" values).

Also fixed display/popup to work with latest view betas by adding 
"feel: make object! []" to the popup face prior to display.

on older views you need to define 'within

'within?

what about lists, and clicking anywhere else - it should close opened 
list, but it does not, only escape works ...

list/menu imo has to disappear that way ....

Graham: Next RebGUI build, 0.3.0, requires View 1.2.124 or higher.

Pekr: difficult without a global event system (as shadwolf asked 
about before). If I can achieve the same effect (i.e. close when 
mouse leaves widget) without it then I'll implement it that way instead 
(global event handling is just too expensive for the few cases it 
is required).

Ashley, I just encapped tour to try it out, and noticed the lack 
of a 'within?

but it simply is not correct, but you probably know it. I think that 
once ppl are used to close menu branch, or list by clicking outside 
of it, it can become pretty annoying, as the only chance to leave 
such menu is to select some item, or press escape.

I don't know how Cyphre did it with his menu, maybe he really changed 
pop-up function, even if expensive. Once again - imo ppl can stand 
different look of UI, but not different behavior on certain platform 
- it is a big mistake to think that they can. Other thing is we don't 
have rich-text, so we can't display accelerator keys. Dunno even 
if alt key works ...

Ashley - I am not flaming here, just raising my concern about UI 
usability issues. We should not definitely depreciate it ...