World: r3wp

Luisc: its ok im a newbie too

Ashley: got it working thanks

Ashley, I've also come across the need to use width keywords.  I'm 
still not sure what the best method may be, but I'm leaning toward 
devising a generic UI grid.  At its simplest, it'd be like a 2-cell 
(four guideline) html table with labels on the left, controls on 
the right.  But this could also broken and repeated across the width 
of a form, with keywords/parameters used to position elements across 
the guidelines.  This is a thought in progress, unfleshed.

Somewhat in the mold of a Wordprocessor, but with form elements instead 
of paragraphs...

How to clear a field ?  This doesn't work without screwing up the 
text cursor...

 display "" [ f: field 30 [ show-text f copy "" ]] do-events

don't mind me...I'm going to ask all the newbie questions so no one 
else has to!

does clear-face <face> work?

don't mind me... I'm going to post the wrong things in the wrong 
groups so no one else has to! (sorry)

Graham,

	display "" [field [show-text face "" rebfocus face]]


but wrapping this in a 'clear-face func is the way to go. Thanks, 
added to the list.

Ahh. so I needed the rebfocus face to set the text cursor correctly.

Shouldn't that be part of show-text ?  If you're going to preset 
a number of fields eg. to reset some defaults, you don't really want 
to rebfocus face on each one as well as do a show-text ?

Depends. Take the following code:

display "" [
	a: field "A"
	b: field "B"
	c: field "C"
	button "Clear" [
		show-text a ""
		show-text b ""
		show-text c ""
	]
]


Clicking "Clear" first behaves as we expect, but clicking in a field 
then "Clear" is problematic. The solution, as in VID, is to unfocus 
whenever soemthing else is clicked on. Added to the list.

Pekr, the RebGUI resizing model is simple and works well. The "problems" 
you are now seeing are caused by the fact that the latest build prevents 
widgets being assigned negative size values (which prevents one class 
of errors (sporadic crashes) but can cause anomalies when windows 
are resized below a certain point). RebGUI assumes that if you allow 
widgets to be resized you will *also* specify a window min-size that 
can comfortably hold all widgets. The next build will include an 
updated %tour.r and documentation that addresses this.

Could rebgui calculate a minimal size for a layout?

Go here for a list of all other issues: http://www.dobeash.com/it/rebgui/issues.html

Volker; difficult as min-size includes OS-specific title-bar and 
borders, and RebGUI displays can be dynamically extended *after* 
the window they appear in is displayed (I don't believe that min-size 
can be changed / reset after the face has been viewed).

But you could prevent the layout from beeing smaller, even if not 
fully visible? Instead of having negative offsets or this 0-thing?

Certainly, and indeed that was how it was handled before I "discovered" 
min-size ... but handling this non-natively (i.e. not via min-size) 
looks and feels a bit crude as well as being inconsistent with how 
other [non-REBOL] apps handle resize.

i would use a combination, window with min-size, but if min-size 
is smaller than min-layout-size, dont shrink layout further. keeps 
at least layout intact and user can resize back.

since users (or Pekr;) see a destroyed layout the current way.

But this allows you to resize a window below an invisible threshold 
only to have your resize [partially] ignored when the layout jumps 
back to it's minimum size. I still maintain that setting a realistic 
min-size is not only subjective but the role of the GUI designer 
... if RebGUI tries to infer this setting it will invariably get 
it wrong ("why did it let my title field shrink to less than three 
characters ... everyone knows a one-char field is useless" type of 
issues).

No, this allows the layout to jump back to a bigger size if the designer 
made a mistake with min-size.

would work too if you keep negative sizes. but you dont, you turn 
them to 0, thus losing information. thus not beeing able to react 
to re-increasing correctly. or maybe i understand something wrong?

Correct, the code in question prior to latest build was:

	if find face/span #"W" [face/size/x: face/size/x + delta/x]
	if find face/span #"H" [face/size/y: face/size/y + delta/y]


which works well except that negative sizes seem to cause downstream 
problems. Suffice it to say that I'm now leaning towards a layout-min-size 
model to at least prevent negative sizes in the first place! ;) Good 
discussion.

Graham, are you sure the disappearing text-list slider problem wasn't 
just the fact that all rows fit? Try the following code:

b: copy []
repeat i 1000 [insert tail b i]

display "Test" compose/deep [
	text-list #H data [1 2 3 4 5 6 7 8 9 10]
	text-list #H data [(b)]
]


When you maximize the window you'll see that the sliders only appear 
if needed.

sure .. but I'll check.

Yep, my demo has 6 or so items in the text-list, and when you max 
the window, only 3 show with loss of the sliders.

And in your example, the right hand text list demonstrates this point 
for me losing it's sliders as well as another problem - a tiny square 
widget.

rather, a wafer thin widget.

Perhaps you're using a fixed version of rebgui?

Yep, chalk that up as another thing fixed in 0.3.5. ;) The wafer 
thin dragger is still a problem though.

display "" [ area 50x20 #WH slider 5x20 #H data [arrows]] do-events


This doesn't resize properly in that the slider keeps its absolute 
x position.

When items are placed at absolute positions, they don't resize.  

So, how about we do a 

at 50%x30%  ??

or 

at 50x20 #H to indicate vertical resizing ?

First problem is fixed easily enough:


 display "" [ area 50x20 #WH slider 5x20 #XH data [arrows]]	; note 
 the #X directive

Not sure what the second issue is as:


 display "" [at 20x20 area 50x20 #WH slider 5x20 #XH data [arrows]]

seems to work well enough.

but not if u do this 


display "" [at 20x20 area 50x20 #WH slider 5x20 #XH data [arrows] 
at 20x5
0 area 50x5 #WH ] do-events

#X directive noted .. thanks.

And #Y directive seems to fix my other problems :)

Not so much an absolute positioning problem as a by-product of RebGUI's 
simplistic resizing model. Compare:

	display "" [field #WH field #WH return field #WH field #WH]

with:

	display "" [field #H field #WH return field #Y field #YW]


This limitation is by design so won't be changing any time soon (I 
tend to design GUIs that conform to it naturally ... but that may 
be just me ;) )

In this example I can't get vertical positioning working 

display "" [  
    at 0x150
    

    text-list 30x15 #YH data [ "Joe" "Adam" "Bill" "Artur" "Phil" "Simone" 
    ] [ show-text chattofld pick face/data first face/picked ]

        chatarea: area 150x10 #YWH "Intra office chat appears here" slider 
        5x10 #YXH data [arrows]
 
    at 32x160
    chattofld: field 15 #Y chatfld: field 140 #YW [ 

            show-text chatarea rejoin [ chatarea/text newline chattofld/text 
            ": " chatfld/text] 
            show-text chatfld "" rebfocus chatfld
    ]

    ] do-events

neat. got my very simple gui app working in View, and I'm suddenly 
overwhelmed by the urge to try it with RebGUI instead.

How do I right-align the text in a field?

right

field font [align: 'right]
should work

perfect, thanks

Graham, best you can do is remove #Y directive from first 3 widgets. 
To make things even clearer, revert the span-resize function to its 
pre-0.3.4 definition (i.e. replace the following:

			;	protect against negative sizes
			if find face/span #"W" [
				...
			]
			if find face/span #"H" [
				...
			]

with:

			if find face/span #"W" [face/size/x: face/size/x + delta/x]
			if find face/span #"H" [face/size/y: face/size/y + delta/y]

in %rebgui.r (as has been done in the next build).

ok.

I've got to keep the #Y as otherwise the top three widgets don't 
move down on resizing ( there are widgets not shown above them ).

that change doesn't seem to have helped :(

Oh, and how do I scroll the text in the chatarea using the slider?