World: r3wp

buit need agreement on the changes, or have to keep a private version 
and repatch each release. which means i stick with vid.

stick for new styles. if i could use widgets in vid, i would do my 
styles with rebguii. (also need a bsmall version, a few 10 kb then. 
i guess without dictionary would be enough).

Is there a checkbox-list widget for RebGUI?  I'm looking for something 
like this:

http://www.jidesoft.com/images/checkboxlist.png

yes there is.

you can group them into check-groups

Ahh.. you wanted a list ...

Just add a scroller to scroll the checkgroup windows

OK... I see,  thanks.

Ashley, just wanted to ask and can't find rebdb group here ...

Isn't it possible to implement 'join? You once said that you will 
wait once RT adds RIF, but that will probably come who knows when 
- it is year and half late already. Do you think it would not be 
possible to proceed without RIF and switching to on-disk storage?

'join is really badly missing with rebdb and I am thinking switching 
to sqlite only because of that one feature. Once you have your data 
spread across many tables, it is difficult to work without it. Or 
how you do it?

Pekr. Join is relative easy to implement.

Just do a search on each table, and then create a new block by using 
the key that joins them.

foreach key table1 [
	values-table1: select key table1
	values-table2: select key table2
	append join-table reduce [values-table1 values-table2]
]

That is more or less the pseudo algorithm

Moving to !RebDB group and renaming this group to !RebGUI

Any time frame on updates ?

I've got quite a few minor fixes that I can wrap up into an 0.3.9 
release, so I'll look at doing that within a week.

is RebGUI area supposed to scroll automatically as-you-type? ... 
as it does not currently - scroller is being updated, but face does 
not scroll ...

Yes, and the area problems are well known (by Graham amongst others) 
and not easy to fix. ;)

I thought so .... :-)

http://polly.rebol.it/test/test/rebgui/download.rscrolls. Slider 
is not updated. but i prefer scroll-as-you-type.

hmm, what is the problem with slider? would we have to have something 
like hook to edit function and by each keypress to examine if we 
should redraw sliders? sounds complicated and would be slow probably?

IIRC there is some automatic in rebgui. but that automatic changes 
the text-offset back when the edit-function changes it.

SO while patching i guess i disabled it.

0.3.9 is out and it has a lot of fixes / enhancements. From a REBOL/View 
console:

	do http://www.dobeash.com/get-rebgui.r
	do view-root/public/www.dobeash.com/RebGUI/tour.r


The dictionary file has been removed from the distribution and the 
download path has been changed from:

	www.dobeash.com/files/rebgui -> www.dobeash.com/RebGUI


so you may want to delete view-root/public/www.dobeash.com in its 
entirety first to clean things up.


In addition to the large number of fixes ( http://www.dobeash.com/it/rebgui/issues.html#section-2.2
), a number of enhancements are documented here:

	http://www.dobeash.com/it/rebgui/display.html#section-2.1.7
	http://www.dobeash.com/it/rebgui/display.html#section-3.2.4
	http://www.dobeash.com/it/rebgui/display.html#section-3.2.5
	http://www.dobeash.com/it/rebgui/display.html#section-5.20

Also note the following:

	view-face is now activate-on-show by default

 Added a request-password requestor (its password widget problems 
 are known issues)
	group-box and tab-panel now auto-size

 Table column headings are now always left aligned and clicking the 
 arrow works

 Added an 'effects context (only window is present, but others like 
 'button, 'check, etc may be added in future)


And lastly, you will notice that %tour.r has a new "Appearance" tab 
where you can dynamically alter RebGUI's metrics, colors and effects. 
Note that some colors are still "hard-bound" at context creation 
and won't change - these will be made dynamic (via a set-colors func?) 
in the future. Apart from showing off RebGUI's dynamic scaling and 
display abilities, this lets you more easily prototype a unique look 
for your own apps if you want, and if you come up with a set of options 
that is truly fantastic then share it here and it may just become 
the new RebGUI default.

Enjoy!

Ashley, pretty neat on how you can dynamically change the appearance.

I note that the area box still has the same problems with the cursor 
jumping from the middle of a paragraph when word wrapping to the 
bottom of the screen.

I note requesters can now be dismissed with the escape key, but can 
keycode shortcuts be used for Yes and Now ?

Using CTRL+A in list doesn't mark all entries.

as usual great work ^^

can keycode shortcuts be used for Yes and Now

 ... I was going to map Enter to OK / Yes and just leave ESC mapping 
 to Close / Cancel / No. What keycodes were you thinking of ("Y" and 
 "N"?).

CTRL+A in list doesn't mark all entries
 ... good spot, I'll add it to the list.

Yes and No as well as Enter and Esc would be good.

Widget Designer's Guide updated: http://www.dobeash.com/it/rebgui/widgets.html

Good stuff, especially the optimization section. I see a lot of potential 
in my code :-))

Is there a way that we can add a RebGUI "verifier" that will check 
the use of VID words, etc.? IMO a good help.

For SDK users; rebface.exe, then:

do %path/gfx-colors.r
do %path/gfx-funcs.r
do %tour.r

So, it's simple to encap. That's good.

Haven't tried it yet.

Is there a simple way how we could seperate GUI code from application 
code, so that the application code can be used by a web-frontend 
as well? I just want to avoid to code things two-times.

Depends. You can structure your code so that all the displays are 
in one file and all the business rules / data / action logic in another 
by coding like this:

display "Test" compose/only [
	button (app/labels/save) (app/actions/save)
	drop-list data (app/options/save)
]


and using references to face (and face/parent-face) within your actions. 
This approach achieves a couple of things:

	1) Separation of display from process

 2) code / data reuse (i.e. you can share data / action blocks across 
 multiple displays)

 3) Can reduce the amount of code that is composed as app data / logic 
 can be composed independently of the display
	4) Code is more portable (as face references are generic)
	5) Probably easier to maintain and debug

Problems with this approach are:


 1) "f: field" is easier to reference than "face/parent-face/pane/2" 
 etc
	2) You have to really think about how you structure your code
	3) It's very different from the way we are used to (VID)

a thought: how about adding to vars instead of setting them? i imagine

 bt: context[rebgui: none cgi: none fill: [true] action: [alert value] 
 my-stuff: ..]
 display .. [
  bt: button
 ]
and now display would put its face in bt/rebgui

Sounds interesting.

My idea is to decouple it with one indirection. I have one GUI-action 
block, that collects all data from the GUI objects, creates a block/object 
and passes this further for processing. The CGI part, would collect 
all data from the CGI object and passes this further for processing. 
To the same function as the GUI.

Ashley, can we please add a way to display to either specify a starting 
size of the window that's not maximized. I want my app started with 
a size of 1024x768

Is there a way to re-use widgets like done with 'style in VID? For 
exampel: I have a drop-list specification, I need at several places 
but I don't want to copy the code. I tried it use a (my-drop-list) 
compose word but this doesn't work.

label-size etc.: If this was set in an outer object, the value should 
be used for group-box as well.

triggers: It seems that a on-unfocus function of a field is called 
even when I only switch tabs in a tab-panel.

triggers: This seems to be problem, if a RebGUI app is closed to 
the command line and than restarted. Seems like the triggers are 
somehow still active than.