World: r3wp

what's the magic incantation to have a widget hidden by default in 
the layout?

display "" [field false]

Thanks .. I managed to work it out :)

The chat widget .. can we get it so that text is selectable?

and links active?

This is more of a general question on gui design... but should one 
keep all buttons on screen, or, provide buttons as required?

I'm of the "don't tell me about it unless I can do it camp" here. 
Nothing worse than hunting through a complex menu to work out what 
I can and can't do. 80% of what I want to do or see should be no 
more than one click away IMHO.

re: chat widget. I'm waiting on R3's rich text enhancements before 
I do much more with this widget.

I agree with Ashley, that user should be provied with valid option 
in particular context. But I don't agree with dynamically rearranging 
menus, or hiding buttons. It is imo confusing. That is why we should 
have ability to disable/enable some elements, but not to hide them 
....

I too would prefer to have visibly disabled buttons on screen .. 
but have to go with removing/adding buttons for the moment.

maybe we could hack in disable/enable functions? I did some, and 
Anton (or Volker) fixed it to work even with keyboard. The solution 
was to put transparent face with some effect into front of "disabled" 
element ...

table: We have extended TABLE to allow horizontal scrolling. You 
specify the number of visible columns and the rest can be scrolled.

it should be part of the widget

how about just adding a disable flag to the button and put a disable 
check in the engage event?

I wonder why noone picks-up on cool grid element :-) Pity API changed, 
so it does not probably work ....

but that doesn't change the visuals ...

Graham - it should, but as an interim solution I welcomed even such 
hack. I refuse to visually remove buttons, according to some conditions. 
That sounds scary, when once there is button, next time there is 
not button at certain position :-)

ghosting out the buttons etcs

well, if buttons are not functional in certain states ..

perhaps better to remove them both visually and functionally?

Well, I am going to try it both ways and see what the users say

Graham - http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=disable-face.r


i have not thought about RebGUI integration yet, not sure it is applicable 
...

Maybe Ashley could have quick look into it? It could be functions 
of RebGUI. But I agree that in fact it should be done in consistent 
way = adding such handlers to each style, so not sure Ashley would 
accept such "hack" into RebGUI ....

When you click in to a text area, the caret always appears at the 
end of the text.  Possible to have the caret to appear at the mouse 
pointer?

Otherwise have to double click

its in 'focus,
  if not caret [caret: tail face/text]
somethig with 'offset-to-caret. anyone? ;)

oops, its rebgui. may be diffferent there.

display "" [ p1: panel 20x20 green data [] false do [ show p1]] do-events

Why does this not show the panel ?

It looks like 'show does not work inside a 'do block

if the widget was hidden

This works showing text in a visible widget .. 


display "" [ p1: panel 20x20 green data [] false return f1: field 
do [ show p1 set-text f1 "panel should be the
re!" ]] do-events

Neither the field or box will display


display "" [ p1: box 20x20 green data [] false return f1: field false 
do [show [ p1 f1 ]]] do-events

Trick is to remember that the do block is evaluated prior to the 
display being shown, so you just have to use:

	display "" [
		p: panel green data [] false
		f: field false
		do [p/show?: f/show?: true]
	]
	do-events

Thanks

but isn't the layout constructed first otherwise the variable names 
would not be available?

Yes, but doing a show or hide prior to view doesn't work.

Ok.

in lists and tables, scroll bars appear dynamicallly

Is it feasible to do the same for area widget?

The reason most UI's dont do this is you either have to reserve space 
for the slider, leaving an empty area, or dynamically readjust the 
text to fit ... which annoys users as the number of lines changes 
on them. So, no. ;)

Ashley - well, how often there is the change of text size, so that 
there is, or is not the need for slider? ;-) Once?

How about using Chris' script to support input-patterns: http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=filtered-import.r

How do you get a slider to react to the mouse wheel?

move the wheel?

I'm pretty sure mouse wheel support is implemented.

Yeah, it's not reacting.  I've tried forcing focal-face, no effect. 
 ??

I've tried a custom widget with an  action: make default-action [ 
 but I might be missing
something simple but critical...

From what I can understand from other widget code, say area...the 
on-scroll is sent to

the area...I need it to go right to the slider for the scheme I'm 
attempting...  Umm, I think...

You have to do it indirectly, as in:

display "" [
	p: panel data [slider] on-scroll [
		var: face/pane/1
		var/data: var/data + either negative? scroll/y [-.1][.1]
		show var
	]
	do [system/view/focal-face: p]
]

Ashley;  Thanks.

Works nicely.  Need to build the boundary fences, but works nicely. 
 Thanks again.