World: r3wp

Interested to see Carl is suggesting RebGUi as a possibility for 
R3.

Just a note to all of you: I contracted Cyphre to develop some RebGUI 
widgets. In the next couple of weeks you will see two new widgets:
1. drop-tree: Is a mix of a drop-list with a tree view.
2. tree widget as we can derive this from the drop-tree

I will provide this code to RebGUI and hope others can make use of 
it too and maybe helpt to extend it.

And those quirks as mentioned by Graham are on my list as well. So, 
we will improve existing widgets as well.

Thanks Robert.

Much appreciated. Tree widget is a requirement for an improved directory 
requestor.

area getting a face lift. Any objections to scroll-wheel support 
?

too late.

Ok, committed new area widget with scroll-wheel. Graham, you should 
find it quite comfortable now. Many hours of concentration, hope 
you appreciate it.

Anton - I will check it today, and give you my feedback :)

First report - it seems to work!!

I'll have to do more extensive testing with editing etc, but it no 
longer jumps when I place the cursor at the bottom of an area field 
which has first been scrolled to the end.

Many hours of concentration
 ... appreciate the effort, works well here.

Updated %create-distribution.r to remove prebol.r and prerebol.r 
dependencies.

Thankyou. Just one thing about scroll-page (ctrl + scroll wheel) 
handling: it could be used for changing the font-size instead of 
being equivalent to page-up/down.

Would it be possible to get assign an action to each column of table? 
 Rather than share the same action as at present?

Is there a way to PAD vertically?

why do we need the DATA keyword for group-box? IMO this should be 
OK:
	group-box "MyBox" [
		label "..."
	]

1) Vertical pad. No such concept in RebGUI as its layout engine is 
purely left to right carriage return (although you can often achieve 
the desired result by ending a line with a box of the appropriate 
height)


2) group-box and DATA keyword: this is required as a block without 
a keyword is taken to be an action (even though for some widgets 
like tool-bar, tab-panel, group-box, etc it doesn't make as much 
sense ... but I think consistency is more important than concise 
expression for a subset of widgets).

1) Ok, how about a RETURN 5 or so?
2) Ok, I agree.

Q: How can I change the number of columns of a table at run-time? 
I want to use three tables and change semantics depending on user 
action. Sometimes table 2 has 2 columns, sometimes 4.

Table widget wasn't designed to be that dynamic. I normaly have a 
dedicated function for more complex displays, structured like:

show-my-display: make function! [
	...
	
	display "Title" compose [
		...
		button "Redo" [
			unview/only face/parent-face
			show-my-display
		]
	]
	...
]


Not ideal, but works well when the 'refresh' is tied to an action 
at the end of the work-flow such as save, commit, next, prev, etc

I guess a grid widget would do this.

Yes, but we don't have one ;-)) So trying to get along with what 
I have.

Could I specify a table with the maximum required number of columns 
and than set the sizes of not required columns to 0?

radio-group: What's the best way to create a readio group (vertical) 
and get fields aligned to each radio on the same line? At the moment 
the only solution I see is to use asbolut positioning for the fields.

That or have a group-box beside it. Which gets me to thinking that 
a place-holder widget (based on group-box but with no borders) might 
be a good thing.

That's a good idea to keep the layout engine comfortable.

.

I'm getting this error now occasionally with the changes to area


** Script Error: max expected value1 argument of type: number pair 
char money date time tuple series
** Where: action
** Near: system/view/caret: offset-to-caret parent-face min max
** Press enter to quit...

I'm going to try wrapping that around an error block	

							either error? try [

        parent-face/size - (face/size * 1x0) ; max <- should also subtract 
        height of one line of text
							][
								0x0
							][
								parent-face/size - (face/size * 1x0)
							]

That comment "should also ..."  is old and I do not have it in the 
latest version, which hasn't changed since I said I committed it. 
 I believe you should just update your SVN tree.

That error used to happen in initial versions because I didn't check 
to see if there was a caret. The latest code does check.

Ok.  Odd .. I'm sure I downloaded lastest versions as the area bug 
was fixed.

Try again.

Any reason why this doesn't clear on ESC

popup-search: has [ qs ] [
    display "Quick Search"  [
        label "Enter name" return
        qs: field 80 [ ] return
        reverse button "Close" #"^[" [ unview ]
        do [ show-focus qs ]
    ]
]

ie. the window does not close on ESC, unless I use display/dialog

The 'edit-text func (in %rebgui-edit.r) traps ESC. Comment out the 
show-focus and it works. /dialog "works" as ESC is trapped at the 
window level and does a hide-popup.

Hmm. I tried out commenting out the ESC mapping in rebgui-edit.r 
without much luck.

on-focus / unfocus glitch: If you CLICK outside a field or into an 
other field, the unfocus action isn't triggered. That's a bit weired 
because it can break control logic for things like: show form A if 
field get's entered, hide form A if field is left.

Can this be simply fixed?

I just want to inform you that Cyphre will work on some RebGUI fixes. 
We will do the fixes first against an internal version and test them. 
As soon as the changes are stable we promote them into the publicj 
repository.

Good news. ;-)

Excellent. If he can also have a quick look at SVG Renderer (SVG 
-> AGG) that would be good (scaleable icons / tool-bar have been 
blocked on this for a long time).

Yes, but don't expect it in the near future as this isn't high on 
my priority list. I need other stuff fixed first.

I would prefer Cyphre bringing decent table/grid style :-)

Step by step. With List-View we have a very good implementation that 
"just" needs to be made RebGUI compliant.

if anyone wants to help with the port of LIST-VIEW... I know nothing 
of RebGUI.

I'll have a look at it over the weekend. Is the current version stable? 
(i.e. are further changes pending)

I expect more changes to come, but I think it would be a good idea 
anyway to figure out a method to quickly update for both VID and 
RebGUI, maybe with separate code sections and a small build script.