World: r3wp

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.

Latest SVN change (Rev#17) now evaluates parenthesis without the 
need for compose. This allows code like:

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


and the following widgets now reduce their data block: anim, check-group, 
led-group, radio-group ... which allows:

display "" [
	anim data [image-1 image-2]
	radio-group data [idx "One" "Two"]
]


These changes shouldn't impact existing RebGUI apps (i.e. they are 
backwardly compatible).

That's probably more comfortable.

.

Couple of minor administrative fixes:


 - Examples added for every widget in http://trac.geekisp.com/rebgui/wiki/WidgetList
  

 - http://www.dobeash.com/RebGUI/display.htmlupdated to reflect latest 
 changes (and have information duplicated in WidgetList removed)

 - Updated site with latest build and corrected path to: "do http://www.dobeash.com/RebGUI/get-rebgui.r"

Tree: The code for the tree is mostly complete. Even an API to change 
the tree at runtime exists. The code isn't splitted out into a standalone 
tree-widget yet. It's included in the drop-tree widget.

As we have made several, IMO useful changes to RebGUI, now to submit 
them? Is there something like a development branch in SVN? Or should 
I diff the changes and post here or mail Ashley?

I think just commit the changes, and we'll examine the differences.

A development branch sounds good .. so we can test before it gets 
committed to main branch.

The project isn't big enough to justify multiple source trees at 
present, so as long as what gets committed works and is functionally 
complete we should be fine (and get-rebgui.r is based on stable snapshots 
so we can handle temporary breakages). Just make sure the committed 
changes include those made in rev#16 and rev#17, and a point form 
summary of changes posted here. Thanks.

Question: If you create several data-forms that can loaded with different 
records, I always need a way to reset those fields/drop-lists etc. 
that are not loaded to default values or empty values.

I think something like a /reset function would be nice. Either the 
reset value is set by using the TEXT/DATA values present at the time 
the layout is created or I can specify a value within the OPTIONS 
block. What do you think?

How about adding a refinement to the display function that does something 
similar to the load-form-data function we discussed a while back. 
We could then populate forms at creation with:

	display/load-data "" [..] block-of-values

and reset them with:

	load-form-data my-form block-of-values


I think it's a lot cleaner to do this on a form basis than trying 
to do it at the widget level.

It must be dynamic, so not only at creation time. And, I only store 
values wehre the user did enter something. Hence it's necessary to 
iterate over every form element and either set a value if available 
or reset to a default value.

show-data: Why does this function doesn't have a /no-show refinement?

How about a clear-data function? For example: I'm using fields in 
that TEXT contains the visual representation of the DATA field. As 
both might be different (1000s seperators etc.)

Why does this function doesn't have a /no-show refinement?
 same could be said for show-color and show-text.

How about a clear-data function?
 Could be useful.


I'm thinking one function could handle all these permutations: a 
set-attribute function like:

	set-attribute: make function! [
		face [object!]
		attribute [word!]
		value [any-type!]
		/no-show
		/focus
	] [
		...
	]


where a value of none! meant clear (which is the case anyway for 
widgets where none! is a legal value).

Sometimes the clear value is 0 or 0.0 for numeric input fields.

First cut attempt at set- functions to replace various show- functions:

set-attribute: make function! [
	face [object!] "Window dialog face"
	attribute [word!] "Attribute to set"
	value [any-type!]
	/no-show "Don't show"
	/focus
] [
	face/:attribute: case [
		string? value		[
			face/line-list: none

   all [face/type = 'area face/para face/para/scroll: 0x0 face/pane/data: 
   0]
			form value
		]
		series? value		[copy value]
		attribute = 'color	[either word? value [get value] [value]]
		true				[value]
	]
	unless no-show [
		either focus [ctx-rebgui/edit/focus face] [show face]
	]
]

set-attributes: make function! [
	face [object!] "Window dialog face"
	attributes [block!] "Block of attribute/value pairs to set"
	/no-show "Don't show"
] [
	foreach [attribute value] attributes [
		set-attribute/no-show face attribute value
	]
	any [no-show show face]
]

Used like this:

	display "" [
		b: box
		button "A" [set-attribute b 'color red]
		button "B" [set-attributes b [color blue effect arrow]]
		button "Clear" [set-attributes b [color none effect none]]
	]

Just to inform you, we are going to publish all our RebGUI changes 
today. Those will fixe and enhance quite a lot of things. Further 
a new widget "drop-tree" will be published as well.

nice and cool. So the table widget is the last stopper ....

Robert, are  you going to update tour.r with your changes?
\