World: r3wp

Still a beta release .. not a general release.

Mchean all you have to do is put a comment  ";" at the line and it 
should work =)

Other images referred to won't be found either though.

unfortunatelly you will have to do that on every release until you 
download those images

yes i think there are 3 images that need to be " ; "

but i think if you download the first beta release it has those images

Sorry Mchean by newbies i was referring to me =)

I guess this is more of a Rebol problem, but alerts don't stay infront 
of the parent window.

LEDs don't seem to be working properly in the tour.r
And also, you can't tab yet within any of the state widgets

Image accepts a file for the image, but not an image type.

No action block for fields?

Try this:


 field [show-text face now/time/precise]	; press enter in the field

Hmm.  Wonder why mine don't work.

If you type enough text to start text scrolling, this is what happens


>> display "" [ myfield: field 20 [show-text face now/time/precise 
print face/text] ] do-events
16:50:17.808
** Script Error: Cannot use path on none! value
** Where: edit-text

** Near: if all [tmp/x < 0 tmp2/x < 0] [face/para/scroll/x: tmp2/x 
- tmp/x]
tmp3:

When a window containing a text-list is maximised, the scrollers 
disappear.

from the text-list.

I thought I'd have a go at building an application with RebGUI, and 
I'm starting with an open source electronic medical record.
I'm just building the gui first off 

http://www.compkarori.com/emr/remr.exe
http://www.compkarori.com/emr/remr.r

Help appreciated :)

I'll intend to use Rugby + mysql/postgres unless RT brings out LNS 
in time.

Good first cut. I''d standardize label / field widths with composed 
words; eg.

window-size: NxN
tab-size: window-size - NxN
label-width: N
field-width: N

display "Test" compose [
	...
	label (label-width) ...
	field (field-width) ...
	...
]


This way you can globally experiment with different sizing layouts 
without too much effort.


If you come across anything that would make writing an app even easier 
(be it a RebGUI usage hint or enhancement request) then be sure to 
mention it here. Thanks. ;)

Hi, just few notes .... 


1) why new versions are not released as complete ones? The download 
is small already. I tried to point out my friend to it, and he missed 
0.3 version or so, which is required ...


2) box definitely does not resize properly. Still, so far, Romano's 
system was the most complete and the least errorless version I saw. 
Try to move resizing window here or there and you will get even cases 
as three lines of color boxes, no spacing, mixed together ...


3) lists - are we ready to overcome rebol limitation here? It works 
better, but still not flawlessly and not in system friendly manner: 
a) when moving "too fast" with mouse, it stays open b) in above and 
and other cases, ESC shoudl close it c) I understand we have use 
some "excuses" and workaraound for now, but that is not the way to 
go in future d) when moving away, it should stay open, last hilited 
item should stay hilited, close on esc, close on click-away, should 
be foxusable, ability to be driven by keyboard  - that is the only 
system friendly way


4) text-list multi mode - ctrl works, shift too, ctrl A too, but 
not in a system friendly way once again. Maybe I should check first, 
but IIRC, it should work following way - ctrl selects particular 
items. BUT - it should also deselect them - try ctrl A and then, 
holding Ctrl, press some item - it does not deselects them - that 
is imo wrong. Also - shift should mark all items between point of 
last press and active mouse position, deselecting all the rest, even 
if previsously selected ...

scaling - cool! But resizing works a bit strange sometimes, especially 
if you lower window size under some acceptable limit .... dunno if 
that one could be automatically calculated or not, but sometimes 
you get destructed (non-functional) gui

... e.g. with text-list, resizing up and down few times, and you 
get buttons over text-list, the same way bar over text-list, text-list 
not fully visible even if maximising window ....

I have to consider resizing as being too buggy ... maybe it uses 
some kind of simple mechanism, without features as anchoring etc., 
dunno, but imo Romano could help here - his system, although large, 
was pretty much consistent ...

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.