World: r3wp

Only one layout needed as the compose would be within a func (i.e. 
dynamically built as opposed to static). nowrap option? Do you have 
a VID example, havn't used that VID option myself.

I think it's just 

area 200x40 nowrap

Not sure I understand what you mean about compose being within a 
func.

Perhaps you could allow this

radio "blah" data [ none "1" "2" "3" ]

to indicate no choice as an option.

currrently it creates an extra button labelled "none"

What's wrong with the current behaviour? e.g.:

	radio "blah" data [ "1" "2" "3" ]

Compose within a func:

	show-my-display: has [ blk ] [
		blk: load ...
		display "" compose/deep [
			...
		]
	]

So, what do you do if the user did not previously select an option 
in a radio group?

That  () within the data block has to be removed.

I see the problem. Perhaps radio-group should treat none and / or 
0 as "no selection" as well?

yes please.

nowrap option not supported as that would require a horizontal scroll 
bar. Of the many scroll areas I have looked at, especially online, 
only a small percentage are of the nowrap type. It has been my experience 
that users (especially those familiar with Office type products) 
expect wrap in these cases.

Ok, let me explain.

I have a table with one field ( the last one ) with approx 100 - 
1000 chars in it.  I only want to display the first x characters, 
but it displays with the field wrapped if there are any cr in the 
text.

I was thinking I was going to have to have a real table holding the 
data, and one for display purposes.

What if the table widget had a "flatten" type option that did a replace/all 
CR on your data?

yeah, that would be good.

no....!

I need the data as it is ...

I just want to not have it wrap inside a single line.

Let me rephrase: if it did a replace/all on the *displayed* data.

Ahh, well, that would be fine.

what determines the size of the bar ? Sometimes I see it go half 
way across a layout, and sometimes fully across.

As widgets are placed a max-width value is kept. At the point a bar 
is placed its width, unless otherwise specified, is assigned the 
"current" max-width. For the typical case, where a bar appears on 
a line by itself and further lines will not increase in width, this 
is fine. In other cases, like a bar in the middle of a line, you 
should give it an explicit width.

Just wondering if it would be useful to allow rebgui and vid to operate 
together.  So, you could do all the easy stuff that rebgui allows 
you to do, and when you needed something it couldn't do, then to 
use Vid instead.

Is the drop down list of a fixed size?  Can that be made proportional 
to the bounding functional group or window?

RebGUI and VID should work together as is. I've tried to avoid word 
name / context clashes for this very reason. Following should work:


 display "" [button "VID" [view/new layout [btn "Unview" [unview]]]]

request-dir ?
request-file ?

Ashley,  btw, I've been experimenting with RebGui for  project I'm 
working on and it is quite nice. Thanks for your efforts.

Drop-list height is currently set to "min 5 length? items" lines. 
This should probably by extended to include the bounding face and 
the 5 should probably be designer configurable.

Thanks for the feedback James. ;)

RebGui is very nice .. but we also want perfect :)

Agreed! Any other clashes / issues apart from request-* just list 
them here.

Ashley, did you see the ComLib stuff .. no need to interface with 
AbiWord !

I'm also coming around to your POV on table data format (each row 
being a block) as that allows non-displayable columns to be present. 
(I'll probably add a "blocked" type option to RebDB for my own purposes)

Has anyone tested it against AbiWord yet? Does it let you insert 
(and scale?) images into a new document?

I've got round that by using a column width of .001.  It doesn't 
even create a divider in the table heading.

if used as the first columns.  I.e. I stuff all the non displayed 
columns at the front of column definition, and make their widths 
.001

Interesting solution. ;)

Yeah, just changed all my sql statements :)

table/selected currently returns the data selected ?

That's right. Use picked for row numbers, selected for the actual 
values.

I find a frequent need in other applications to close down popup 
windows with the escape key.  So, perhaps an option like this for 
RebGui windows?

I have not looked into RebGUI styles in detail yet, but what are 
the options to "skin" them? Or to do them (styles) in different colors 
etc.?

none that i am aware of.

no global settings for hover color etc., right?

hover ?

hover (css language) = hilite/mouse-over ...

CTX-REBGUI/COLORS is an object of value:
	window          tuple!    236.233.216
	widget          tuple!    244.243.238
	edge            tuple!    127.157.185
	edit            tuple!    255.255.255
	over            tuple!    255.205.40
	menu            tuple!    49.106.197
	btn-up          tuple!    200.214.251
	btn-down        tuple!    216.232.255
	btn-text        tuple!    77.97.133

CTX-REBGUI/EDIT is an object of value:
	...
	tabbed          block!    length: 5
	hilight-on-focus block!   length: 2
	caret-on-focus  block!    length: 4
	action-on-enter block!    length: 3
	...

ctx-rebgui/widgets/set-sizes unit-size font-size


Plus many widgets have various option flags to control some aspect 
of their behavior.


Probably not skinning in the true sense but enough to change basic 
scale, colors and behaviors to cover the major use cases as they 
have been presented to me thus far. Skinning that lets you change 
"look & feel" to the extent that the GUI can mimic native Windows, 
OSX, C64, etc could be done but at what price in complexity and delivery 
time? And what percentage of folks would just stick with the default 
look & feel anyway. Another way of saying this is to ask whether 
it is a good idea to put 80% of your effort into satisfying the needs 
of 5% of your user-base?

function before looks please!