World: r3wp

Good answer :)

But is that rebolish, available exhaustive docs?! :)

It isn't, shame on Ashley.

Wiki WidgetList updated and completed (finally): http://trac.geekisp.com/rebgui/wiki/WidgetList

Anton - as for the get-rebgui, if you are the author, you could check 
following - Bobik's situation was, that he used latest View, the 
script showed following:

connecting to: www.dobeash.com
Script: "RebGUI update system" (21-Feb-2006)
Local RebGUI version ==> none
Remote directory ======> http://www.dobeash.com/RebGUI/

Local directory =======> c:\documents and settings\user-name-here\data 
aplikací\rebol\public\www.dobeash.com\RebGUI
Downloading manifest ==> OK


the thing is - above directory does not exist, nor was it created 
by the get-rebgui script .... so the thing is, what happened then. 
It did not start downloading particular widgets though ...

I wonder where View took the above directory from? Does it rely on 
registry? Or does it ask just OS for the current user data directory? 
Or? .... strange ...

It's in the registry, and expressed as an environment variable APPDATA 
as well.

It gets it from view-root, which is the public sandbox directory, 
used by path-thru etc. as usual.

Yes, view-root gets its value from the registry.

Is there a no-wrap option for area?

At install time, the initial default value of view-root is set to 
%APPDATA%\REBOL

Pekr, was there no error message ? or was "Downloading manifest ==> 
OK" the last line of output ?

Ashley, can you add get-rebgui.r into SVN as well ?

ah, so .... so actually you can't know, if user has installed View 
or not .... but it should not mind .... maybe small check then would 
cure the situation? if view-root does not exist, create it ...

last line output ... no error ....

The other trick is telling whether a specific user has View set up 
on a multiuser system. There are still some multiuser-unfriendly 
bugs in the REBOL/View installer, mostly for backwards compatibility 
with View 1.2 registry settings. At least the file handling has been 
made multiuser safe - we'll see if REBOL 3 solves the rest of the 
problems.

the problems were described ... in general we should be able to have 
choice to install for a) all users b) one particular user .... and 
with uninstall to a) keep private data b) remove data .... uninstall 
is flawed though, as when you uninstall, the icon is removed from 
control panel and other user has no option to uninstall ... or you 
remove the rebol even when other user did not agree to :-)

The main problem is where in the registry REBOL stores its settings. 
There are per-user settings and per-machine settings, and REBOL stores 
many of both in the wrong places in the registry. The details of 
this are once again off topic, though.

Pekr, try running the script again. Are you launching it like this?

do http://www.dobeash.com/get-rebgui.r

By the way, Ashley, I think get-rebgui.r should be moved into RebGUI/ 
directory so everything is self-contained. It's not going to affect 
the end user, since they don't download it.

can you add get-rebgui.r into SVN
 ... done
should be moved into RebGUI/ directory
 ... on the list

Anton - posted to Bobik, I will let you know ...

Thankyou Ashley.

Robert, is the tree widget you've asked Cyphre to create near completion 
yet?  I think maybe it might be useful for the request-directory 
widget.

I'll second that.

.

A mind blank here ... what am I doing wrong ?

>> do %rebgui.r
Script: "Untitled" (none)
>> i: load %skype.png
== make image! [21x21 #{
FBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFB
FBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBF...
>> display "" [ image i ]
** Script Error: Cannot use path on none! value
** Where: init
** Near: size/x: image/size/x

image data i   ?

nope

display "" compose [image (logo.gif)]

works .. why should it need compose ?

That's rebgui -

the docs need changing then?

you tell me.

Yes, needs updating.

display "" [image %skype.png] also works


http://trac.geekisp.com/rebgui/wiki/WidgetList#imageis pretty clear 
(needs a file! or image! *not* a word!)

Hmm.  i, in the above example, is of type image!

How about creating an examples directory, and link to that for each 
widget?  This would remove any confusion that others may also have.

Probably better to provide a small example under each widget description. 
Updated the above Wiki entry. How about that?

It might be cleaner to do it the way I suggested, but anything that 
illuminates helps :)

Latest SVN change (Rev#16) now uses reduce/only to evaluate words 
/ paths without the need for compose. This allows code like:

display "" [
	image i
	bar my-width
	field my-data/field1
	...
]

to be written. It still does not allow inline expressions like:

display "" [
	text my-width - 3 form now/date
	text (my-width - 3) (form now/date)
]


although I'm working on adding support for the later(parenthesized) 
form. As a side note, this is a bit of a shift in my position. I 
used to be of the opinion that explicit declaration via compose was 
more efficient than implicit declaration; but it turns out to be 
less efficient in a number of ways:

	Coding: requires extensive use of compose/deep and parenthesis

 Obviousness: it's not obvious why code like "image my-image" doesn't 
 work

 Complexity: forcing use of compose/deep makes it harder to write 
 action blocks inline [that need themselves to use compose]
	Familiarity: It's not the way VID or other dialects work

 Speed: compose/deep is actually slower than reduce/only and a few 
 subsequent parenthesis reductions


You can thank Graham's comments above as the catalyst to change. 
;)

Ahhhggg...

I hope this doesn't require extensive changing of my code.

I think it does ...

I presume I can still keep using display "" compose/deep [ date: 
field (date-width) ]

Change has no effect on current display code and does not impact 
the use of compose/deep. It merely *allows* you to write:

	display "" compose/deep [date: field (date-width) ]

as:

	display "" [date: field date-width]

Ashley, I think it is a bad idea to use reduce/only in this context. 
It was basically designed for the draw dialect, so it disallows function 
and expression evaluations. I would recommend just processing the 
layout dialect similar to the way VID layout does it.

Why? The main dialect parser of RebGUI can now be expressed in one 
simple parse construct:

parse reduce/only spec words [
	any [
		opt [... evaluate () to return a REBOL value...]
		[
			parse rules to handle REBOL values
			...
		]
	]
]


compared to the relatively complex parsing logic in VID (which, to 
be fair, has to handle styles amongst other things).


The main functional difference between what this allows in VID and 
RebGUI is that you don't need to parenthesize your expressions in 
VID (and I kind of like the idea of having to parenthesize them anyway, 
it makes expressions stand out just like they do in compose).


Having said that, if someone can show me a RebGUI parser built along 
the lines of VID that is clean and lean I'll willing to be convinced 
otherwise. ;)

Mmm.. ok. Let's see how it goes.