AltME groups: search

Ashley, please confirm what I am understandig: when I will release 
a commercial application I will have to include VID, RebGUI, LIST-VIEW 
source (and SQL-Lite one) inside the application but everything will 
work flawlessy.

http://trac.geekisp.com/rebgui

This code shows how to implement dynamic 'info for 'field and 'area:

display "" [
	a: field
	b: field
	button [
		alter b/options 'info
		b/color: either find b/options 'info [
			b/action: make b/action [
				on-focus: make function! [face] [false]
			]
			ctx-rebgui/colors/widget
		][
			b/action: make b/action [
				on-focus: make function! [face] [true]
			]
			ctx-rebgui/colors/edit
		]
		show b
	]
]

Ashley - any news on Robert's RebGUI enhancements integration?

write %rebgui.r read http://trac.geekisp.com/rebgui/browser/rebgui.r

write %tour.r read http://trac.geekisp.com/rebgui/browser/tour.r

this is for rebgui screens .. or perhaps better still, a way to capture 
the shift-print scr on any rebgui window

Ashley, I read that request-dir uses the new tree-view, but when 
I tried it out on a few checkout, and clicked on the "Home" button, 
rebgui froze on me. Reproducibly.

Ah, I had to revert request-dir but forgot to revert read-dir in 
%rebgui-functions.r ... will fix this later tonight.


re: Print support ... I'll look at adding a handler that you can 
assign to an FKey of your choice.

Uploaded build#109 with above fix. Handler is as simple as:

ctx-rebgui/on-fkey/f3: make function! [face event] [
	save/png %screen.png to image! face
	browse %screen.png
]


Just click on the window you wish to print and press F3. I'll add 
this as a cookbook entry.

Ashley - by your aproach though, RebGUI will be first class REBOL 
gui toolkit for some time, but always second league to any normal 
toolkit. I can't agree to ANY kind of simplification, it is just 
does not deliver what normal OS user is used to. It is surely fine 
to keep simplicity and maintainability in mind, but we should be 
real - who cares if widget has 1 or 100KB? I don't, and what end 
users will judge is only comfort of usage.

only end user experience counts, really. RebGUI is much better than 
VID, although any REBOL based UI really lacks proper behavior (mystly 
keyboard). But discounting style like grid is imo fatal mistake. 
I have never seen any db app with such weak grid as table is ...

svn://svn.geekisp.com/rebgui - is the correct address. All I need 
to do is to go up to see RebGUI dir, click on it, and select Update 
from right context menu in my file manager. Works here ...

If you add ?format=raw to the url Ashley gave, it is working
So just 

write %tour.r read http://trac.geekisp.com/rebgui/browser/tour.r?format=raw

Agreed, and it seems time (and a good move) to simply offer RebGUI 
Core, and RebGUI Robust, no?

Well, if everything is factored like it is now, we can just include 
other widgets in rebgui-widgets.r as we need them.

There is something nice though about making it clear in the name 
what you have, and why it is where it is.

I agree with Ashley completely in that RebGUI should remain small, 
and simple.
This seems like a way that everyone can be pretty happy.

was it deliberate decision to remove the functions tab from tour.r

 Yes, RebDOC now covers the same ground. My goal is to pull the content 
 across from %tour.r into RebDOC and then obsolete it (%tour.r that 
 is). In RebDOC the examples will become stand-alone scripts.

RebGUI Core

 ... I like it, and it means we can distinguish general RebGUI app 
 issues from RebGUI Core issues (e.g. keyboard navigation is a core 
 issue, lack of a domain specific "bells & whistle" widget a RebGUI 
 app issue). For me the line is quite simple: if it is an issue that 
 can be fixed by creating a new widget (either from scratch or based 
 on an existing one) then it is probably an app issue; if it is an 
 issue that effects most if not all widgets and / or the fix is to 
 the RebGUI engine itself (e.g. a %rebgui-* script) then it is probably 
 a core issue.

request-dir function has lost the 

home" button" ... yep. The old request-dir function was dynamic and 
only read dirs as needed. The new one, due to the "static" nature 
of tree, pre-reads all dirs. It's also lost the "make dir" button. 
These features maybe important to us as developers, but if users 
need to navigate the entire file system or create dirs to use an 
app then the native request-file is probably a better choice. The 
[new] request-dir is really intended for the simple "which of these 
directories or sub-directories do you want to use" case, and assumes 
the developer will use the /path refinement to start in the relevant 
directory. These changes were requested by one of my clients who 
didn't want their staff "seeing stuff they shouldn't and creating 
directories everywhere".

neat scroll-panel now means I can have enormously wide tab-panels

 ... I had that in mind when I created it! Note that the horizontal 
 and vertical sliders only appear as needed and the space they occupy 
 is given back to the child widget. Also note that the button on the 
 extreme bottom right of scroll-panel toggles between "home" and "end".

RebGUI core - Agreed.

Also, would it feasible to include in rebgui/core a way to size check 
boxes ?  I am trying to overlay some widgets on a PNG of a PDF so 
that users can take existing PDF forms and overlay the correct widgets 
for data entry.

I've had to do something similar and you really need pixel-level 
precision with a domain specific app (or widget). Isn't that hard 
as the number of form elements is limited. The version I was doing 
was trying to automatically place and size fields after filtering 
the form to create a B&W image (for element placement purposes). 
Another approach might be to create a widget that lets you easily 
move and size boxes, then save the face offsets and sizes and apply 
them to a RebGUI display that has the same number of widgets in the 
same order.


I'll take a look at check, led and radio-group sizing later this 
week. All these widgets *should* be able to scale without a problem 
(much like symbol does). In fact I was contemplating using webding 
symbols (for the tick and cross) in lieu of draw.

RebGUI/Core - Forking: I agree with you. I have talked about this 
with Cyphre too. I think developing a simple but layerable toolkit 
is the way to go. But it's hard, because there are a lot of different 
requirements coming up when doing an appplication.


I think I will provide my RebGUI fork on my web-site and try to document 
all the differences.

pixel perfect

 ... not so much perfect, but more the fact that RebGUI deals in units 
 (default of 4 pixels per unit) which probably is a bit course if 
 you're just going to use straight displays without manually setting 
 offsets and sizes.

Much in the spirit of the once discussed RPC (Rebol Professional 
Community). Focusing our efforts should help us all to move forward 
much faster. And since RebGUI is really a nice piece I'm more than 
commited to help it evolve.

rebgui's trac/svn is being sponsored by Jaime.

I looked at the RegGUI logo and...well

 ... yeah, I'm not a graphics guy and there is only so much you can 
 do with MS Comic font ;)


New one looks polished and I'd like to adopt something new for 2008 
as I plan to release Beta 3 (last one prior to a 1.0 release) soon. 
I'm open to suggestions on color (my preference is for red but I 
think that's taken by ruby :( ) ... also, I'm not sure about the 
X-Internet bit; REBOL and various RebGUI apps may be, but RebGUI 
itself isn't. Perhaps the word "Core" instead.


Let's get a few suggestions / comments in before you do another one.

The X-Internet bit did get me thinking again about RebGUI server 
applications. Here's my basic thoughts.


We create a server-side RebGUI engine (branded as, say, "RebGUI Server") 
which accepts events other than mouse movements from a RebGUI client. 
The server is responsible for generating displays (as a face object) 
and "running" the app, whilst the client merely displays the faces 
it receives and sends events back.


Is there any value in this idea? (and, "so and so already does this 
so why bother" is a fair call).

= RebGUI

Graham, re your tab-panel question:

display "" [
	t: tab-panel data [
		"P1" [field]
		"P2" [field]
	]
	button [
		d: 1
		var: t/pane
		var/:d: ctx-rebgui/layout/only [field red]
		var/:d/offset: as-pair 0 ctx-rebgui/sizes/line
		var/:d/edge: ctx-rebgui/widgets/default-edge
		var/:d/color: ctx-rebgui/colors/widget
		either t/data = d [show t] [var/:d/show?: false]
	]
]

Uploaded build#111.
	- Split requestors off into %rebgui-requestors.r 

 - Requestors and functions now appear in their respective parent 
 objects 
	- Added new on-resize handler 
	- tab-panel.r and chat.r fixes 
	- RebDOC.r enhancements

http://www.xidys.com/rebol-screenshots/rebgui-config.jpg

OK, a couple of items of business first.


New logo - I like the new logo Reichart proposed (including the X-Internet 
text) and given I've heard nothing to the contrary I'd ask Reichart 
to prepare a few different color samples and we can vote for the 
one we like best ... and then I'll choose the one I like best anyway. 
;)


UI Look - The RebGUI look is too Windozy and is starting to show 
its age. I've decided to try for a simpler, whiter web look with 
fewer colors (I experimented with a B&W look but that's too harsh). 
My first thoughts are, with Reichart's permission, to revisit Quilt 
and mimic its look; but if someone has a link to an extensive set 
of online widgets (with a unified look) that they feel is appropriate 
then post away.


Radio-group - And now a minor implementation question (mostly for 
Graham I suspect). After looking at http://www.useit.com/alertbox/20040927.html
I note their comments in point 9:


Always offer a default selection for radio button lists. By definition, 
radio buttons always have exactly one option selected, and you therefore 
shouldn't display them without a default selection. (Checkboxes, 
in contrast, often default to having none of the options selected.)

If 
users might need to refrain from making a selection, you should provide 
a radio button for this choice, such as one labeled 

None." Offering users an explicit, neutral option to click is better 
than requiring the implicit act of not selecting from the list, especially 
because doing the latter violates the rule of always having exactly 
one option chosen."


Is it time to disallow null radio-group selections? (at present radio-group 
allows a 0 or none! selection)

You know, Ashley, there are several measures to UI and its usability. 
I noticed that ppl really warry, some do most of the things using 
mouse, and then RebGUI is 98% correct (no scroll-wheel support here 
or there, area not being able to auto-scroll when hiliting). But 
those used to keyboard, are suffering much more pain. And believe 
me - although I can understand minimalistic aproach to RebGUI (and 
it really feels better than VID2 in almost all aspects), in the end, 
if widget "missbehaves", I really don't care that, if it is 6KB or 
12KB - all I care is - does it behave as expected?

List of some inefficiencies of RebGUI - decide what could be fixed 
with no significatn effort (e.g. widget redesign or particular subsystem 
redesign (tabbing))

1) no keyboard navigation to swith between the tabs (ctrl + tab)

2) no default focus on page? (maybe just not defined in tour.r), 
but if there is e.g. table, I would expect it being in-focus, so 
that keyboard immediatelly works without the need to click the table

3) are othere elements tabbable? I noticed that e.g. on tab with 
sheet demo, buttons are tabbable. IMO there should be also one primary 
element selected as being "in-focus", it should be reflected in UI, 
or I regard it being faulty.

4) sheet widget - define ENTER action doing the same as TAB action. 
Enhancement request (not necessarily needed) - ability to define 
tab/enter movement direction - vertical vs horizontal.

5) menu - when mouse moves, menu should collapse/expand upon the 
movement, not needing 2 clicks (to collapse old position menu, and 
another click to open one - please reduce at least to one click)
6) tree-view - add arrow support
7) area - hilite by mouse or keyboard should auto-scroll area

8) state elements - add tabbing support with visual reflection - 
imo you are wrongly assuming, that users might not use keyboard here 
(space selects)

RebGUI color management.


The "old" RebGUI color management system evolved by adding new colors 
to ctx-rebgui/colors as and when a new color was selected. Many of 
these colors (e.g. button, tooltip*, btn*) were widget specific. 
In all, 15 colors were defined. In addition to this, a number of 
hard-coded colors such as white, black, coal, red and blue were scattered 
throughout the system.


The effect of all this was to provide a means whereby *most* colors 
could be changed, but the design of a "theme" other than the default 
WinXP scheme was problematic.


The new color management system rationalizes these colors down to 
a base set of 8, being:

	page
	text
	theme-light
	theme-dark
	state-light
	state-dark
	outline-light
	outline-dark


with all existing "old" color references being converted to the "new" 
ones. page and text will usually be white and black (high contrast), 
with outlines being grey, and theme and state being variations on 
the same color. The updated request-ui shows how these themes can 
more easily be chosen (there is a drop-list beneath each of the theme 
and state groups that sets both light and dark to a similar color).


This is still a work in progress, and I am basing the model (and 
color selections) largely on those described in the "Quilt design 
style guide"; and colors / ideas from:

	http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines

 http://library.gnome.org/devel/gtk/unstable/gtk-Resource-Files.html
 (styles section)

A number of things have to come together to make this work:


 1) Conceptual model: do we have the right tokens to reflect all color 
 configurable aspects of the UI (e.g. is there a color word appropriate 
 for a highlight selection, a heading, etc)

 2) Are they named appropriately (e.g. is selected better than state-light?)
	3) What colors should be used in what context?


This last one is very tough. As a general rule I've followed the 
Quilt model and used outline-light for non-edit edges, theme-dark 
for edit edges and heading backgrounds, etc (you can find a crude 
list of usage cases under the new "Colors" tab of RebDOC).


But what about a widget like button? It potentially has the following 
color states:

	Unselected	theme-dark
	Focus		theme-light
	Button-down	?

and widgets such as sheet which might have:

	Headings	theme-dark with page font/color text
	Cells		page
	Edges		outline-light
	Selected cell	theme-light
	Forumla cell	theme-light
	Cell that cursor is currently over

and there are a number of ways of denoting this with color:

	as a background color change
	as a font color change
	as an edge color change
	as a combination of the above


In short, there are a lot of ways of implementing this. What I want 
needs to be simple and consistent with as few colors as possible. 
Any suggestions (including links to good color management techniques 
/ approaches) greatly appreciated.

Can you point me to some screen shots of the newest RebGUI, perhaps 
a few examples from some applications using it?  Anyone...

Also, I will be finishing those logo examples today.

Correct, the look and feel is a work in progress at the moment.

screen shots of the newest RebGUI

 ... I've created a snapshot release here: http://www.dobeash.com/RebGUI/rebgui112.zip


Just unzip and run %tour.r and %RebDOC.r to get a feel for where 
things are at.

Looks that I have to backport a lot of stuff to a new RebGUI.

I don't know how easily this can be fixed, but in VID if you highlight 
a text field by dragging across it and move outside the field, the 
highlight stays.  But in Rebgui .. it is lost.

do you have to be on the tab panel you are replacing to use tab-panel/replace-tab?
 ... No, see the following test case:

	t: tab-panel data [
		"A" [field]
		"B" [field]
	]
	button [t/replace-tab 2 [button]]

Click the button then tab "B".

... Was this related to the new look?

 ... yes, the new look is an extensive WIP that "breaks" build 112.

Are the function keys accessible under Linux?
 ... http://www.dobeash.com/RebGUI/user-guide.html#section-4.4

This seems to work in lInux.  In display.r, change

							find [f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 f11 f12] event/key
to 

       find [ console listen tcp udp icmp dns local odbc oracle mysql crypt 
       compress ] event/key

and redefine on-fkey in rebgui-ctx.r

	on-fkey: make object! [

   console: listen: tcp: udp: icmp: dns: local: odbc: oracle: mysql: 
   crypt: compress: none
	]

HI, I'm new to Rebgui. Is it possible to use Draw or AGG in Rebgui 
personnal widgets ?

I try to use RebGui with Q-Plot but the plot is in a separate window 
instead of to be inserted intto rebgui  display.

print "bugz"
do %script/rebgui.r

maingui: [
	text "Hello" return
	button "Start!" [ display-next-word	]
]

count: 0

secondgui: does [
	compose [
		text (join "popup nr " count: count + 1) return
		button "next" [ display-next-word ]
	]
]

display-next-word: make function! [] [
	hide-popup
	display/dialog "Go!" secondgui
]

display "word!" maingui
do-events
halt

My bad.  Just noticed this is RebGUI ...  although the same principles 
apply.

Would be a cool RebGUI project: http://www.colorflip.com/

is there an option to set editor to a func which is rebgui compatible? 
 i.e. a rebgui text editor ?

I tried once.  But it was more an exercise in linking RebGUI menu 
Find/Replace to area ... too many hacks to keep caret in synch, so 
instead of tarnish Dobeash with my lousy code ... I just didn't. 
  But a quick RebGUI display of an area isn't too hard to pull off, 
but you need to rely on the built in key handlers.  Sadly Find/Replace 
is not in the list, but you do get a spell checker 'for free'.  ;) 
  In Ashley's defence, it is not the design intent of RebGUI to be 
an editor.


I've not tried, but Anton has been pumping out a new editor ... may 
conflict less than  editor  dunno, but I kinda doubt it will work 
without the same types of problems.

Alternative is to use CALL and launch an external editor.

I think you might be able to use the editor within rebgui .. just 
not at the console like you did.

there is a grid widget, where you can put any style inside. It was 
not updated to latest RebGUI API though ...

Not sure if 'choose works well with Rebgui.  What I am seeing is 
that if I release the RMB, the menu disappears, and if the field 
is close to the bottom of the container eg. group-box, then the menu 
appears inside the field.

Note that layout and ctx-rebgui/layout are different funcs ;)

indeed :) It's the latter I'm calling, to get the neat rebgui look. 
just can't figure out the internal workings of #XY though

there is a widget, which is quite cool by its functionality, but 
it was never adapted to one architecture change in RebGUI

Maybe it would be more consistant if rebgui loaded ui.dat and request-ui 
saved the file in the same dir? request-ui saves in current script 
dir, while the main script loads from it's own dir?

Ashley, the tree widget is not indexed here http://trac.geekisp.com/rebgui/wiki/WidgetList
though it appears in the source code list

Hi, folks.  I am getting back to an application I developped with 
RebGui in 2006.  I did download the last one from SVN, but the app 
no longer works under the current version of RebGui.  I get a lot 
of error messages about show-text, even the most simple ones, like 
--> show-text Fmsg "Warning --  Unable to read Products, Phone&Meet 
and Notes.  No file to read." <--.  Looking at docs, I still see 
the show-text function; there is still some appearances in some docs, 
but there are not much.  Maybe it is deprecated now?  I see set-text, 
but it talks about attributes of text, not its content.  So not shure 
it is the one to use now.  I would need to show the app soon, but 
hesitate to retarget the code, seing the frequency of the error message 
** Script Error: show-text has no value.  Inexistant function, bad 
assignement (for unknown reasons), or something else.  For me, hard 
to know now. From the 2006 epoch, is there a lot of change.  The 
app still get drawn a bit, though.  Thanks for an answer that would 
me out of problem.

Hello. One of my friends, not even a probrammer, jut Perl user, was 
asked to prepare solution for their production line. They will need 
to cover more than 100 Terminals with touch screens. He is a friend 
of Bobik and mine, so Perl, Python, and REBOL alternatives were possible. 
I have the pleasure to aanoucne, that REBOL + RebGUI was choosen.


While app is rather primitive - few fields on the left, numeric + 
few alphabetic keys on the right, connecting to mySQL, the environment 
is also very restrictive - Terminals (don't remember the model) are 
older ones, 24MB of RAM, no hardisk, P300 performance. The solution 
boots Linux from network and RebGUI app is loaded ... only 1MB or 
RAM is left, so the solution is so so ...


I would like to ask, if RAM consumption could be improved with encapping 
app with rebface for e.g.?

probably a little bit, since you can select what to include. I suppose 
VID can be removed if RebGUI is going to be the GUI for the application.

Pekr, using rebface instead of rebview will make a big difference 
as rebface excludes VID and all help text is stripped out. On OS/X 
I get the following:

REBFACE
>> stats

== 2085621
>> recycle
>> stats
== 1911437

REBVIEW
>> stats
== 6260880
>> recycle
>> stats

== 4810174


You can also create a custom RebGUI build that excludes widgets you 
don't intend using (see http://trac.geekisp.com/rebgui/browser/create-distribution.r
) which will save a few more bytes. Lastly, make sure your app does 
not use any unneeded images (e.g. a background image when a simple 
draw effect might suffice).


Even with these measures you'll only be left with about 3MB free 
... but 3MB is better than 1MB.

LOL - RTFM :-) http://www.dobeash.com/RebGUI/cookbook.html#section-2

Pekr, try the following (after the do/#include of %rebgui.r):

	ctx-rebgui/layout [text "?"]

so, after some testing, which I am confused a bit about, it seems 
that RebGUI is not all that memory savy. For simple hello world example 
based upon rebface, it consumed even more memory than VID.

IIRC RebGUI was supposed to be more memory savy, which does not seem 
to be the case. What is also interesting is, that rebol 1.2.47 consumed 
less memory ...

Because Rebgui uses a  default pixel size that can be eg. 4, you 
can't easily get pixel precision in layouts.

Out of interest, the memory figures on OS/X using rebface are:

	rebface	1.8Mb
	VID		3.2Mb after loading %view.r
	RebGUI	3.5Mb after loading %rebgui.r


but these are for the respective defaults (VID apps often require 
additional patches/fixes and styles, RebGUI apps rarely use *all* 
the default widgets). I should also add that RebGUI (or indeed VID) 
have ever been fully profiled and optimized.

Is there a way we can "robustify" rebgui so that we trap all errors??

make object! [
   code: 312
   type: 'script
   id: 'cannot-use
   arg1: 'multiply
   arg2: 'decimal!
   arg3: none
   near: [freedom * face/data]
   where: 'wake-event
]

ie. they are trapped inside the rebgui code and dealt with there.

I don't know.  I just remember he had the style.  Don't know how 
well it works as I've never used it, let alone with RebGUI

Anybody out there using RebGUI ?  I'm just starting to use REBOL 
and have delivered a small app using VID  to a volunteer group who 
are collecting local history articles. And I'd like feedback on any 
gotchas with RebGUI vrs VID. Thanks

http://www.dobeash.com/rebgui.html-> docs etc...

to get rebGUI  you simply write those lines into a ".r" file or you 
go into the rebol/desktop in the REBOL/DEMOS folder

REBOL [Title: "RebGUI Demo"]

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

I'm trying to do some 'field navigation' within a rebgui form and 
cannot figure out how to get teh filed cursor to 'goto field'

Correct ... the set-focus "eats" the return state.


set-focus was intended more for use either within a display's do 
func or from outside the display. Tab order cannot be set programmatically, 
although it should be noted that tab order is the same as the widget 
specification order so you can at least sequence your widgets in 
the desired order. There is no easy way to conditionally skip widgets, 
although build#106 added the set-state func which lets you toggle 
a widget's info state. As for this being an "obvious" programming 
need, it depends on the type of GUIs you wish to write ... you are 
the first person in over two years to have hit this issue (or at 
least report it) ... although I'll freely admit that keyboard navigation 
is not RebGUI's strong point ;)

2.7.6 Demo of RebGUI.  If you try the spinner, Ctrl-MouseWheel then 
later try Functions/Requestors request-ui it fails with
** Script Error: Invalid argument: $10.00
** Where: init
** Near: all [not empty? text data: to type? first options text]
para/margin/x: size/y
p:

Where the invalid argument is the same data as the last Ctrl-Mousewheel. 
 So it could be 9:00, 18:00, $10.00 etc.
I haven't tracked through any of the code yet, being a lazy git.

Can RebGUI table or sheet style contain check boxes? I need small 
util, which will allow ppl to choose multiple items from the catalog 
at the same time.

Where can I find more info about API changes of RebGUI, which happened 
some time ago? I would like to get Cyphre's grid working, as it is 
many times better than table available, even without column resizing 
....

Pekr I can give you a rebGUI table widget I done long ago that handles 
it ... -> http://shadwolf.free.fr/rebgui-list52.r

I didn't tested it with new version of rebgui but it should still 
work

rebgui installed

it was designed to be a rebgui widget  that was the prototype for 
table widget long time ago and a play for me on an amazing and very 
VID Topic " widget auto compositing subwidgets" widgetwriting widgets 
that's so neat  ^^

I tried it but got an error...
** Script Error: Invalid path value: rebface
** Near: listview: make ctx-rebgui/rebface [
    size: 400x300
    data: []
    pane: []
    cols: none
    rows: none
    l...
I believe REbGUI version: 112

ctx-rebgui/rebface -> internal object .... hum let me see

ctx-rebgui/rebface replace this by  : listview: make rebface [

i'm trying to find a solution rebgui moved more than I expected

but this provide a temporary solution i'm not sure there is no other 
rebgui interfaces that diseapear

hum as I  thought all the widgets interface in rebgui completly changed

http://shadwolf.free.fr/rebgui-list2.jpg^^

if you can put your hand on a rebgui 0.38 that widget should work

ana  button call for anamonitor wich helps me to debugging and no 
my list-view don't works anymore with recent rebgi version (it was 
done with rebgui 0.36 ... )

I just used the tour.r on the latest rebgui.

There you can select a color for a button, but as soon as the mouse 
hovers over the button, the colors switches to the defaults.

Is this by intent or is there a way to keep the selected color(s) 
?

The culprit is the face-iterator function in %rebgui-widgets.r ... 
the engage function is doing a 'show *after* the on-click action 
is fired. I won't have access to my dev box until the weekend, but 
at first glance it looks like moving the show may be all that is 
required. Other widgets, such as button, typically have an engage 
function like:

	...

 upÊ Ê Ê Ê Ê Ê Ê Ê Ê Ê Ê [set-color face colors/theme-dark face/action/on-click 
 face]
	...


for this very reason (i.e. always perform the action last to avoid 
focus loss).

I'm not seeing this ... http://trac.geekisp.com/rebgui/browser/rebgui-widgets.r#L438
the show is before the action is called ?

Does RebGUI have anything like roam.r or will roam.r work with RebGUI?

Found it, and fixed in build #114. Basic rule in RebGUI is to fire 
actions on 'up and 'alt-up (to ensure they occur after unfocus) ... 
face-iterator was firing actions on 'down and 'alt-down. A nasty 
bug that's been there for a long time (and explains why I had trouble 
getting some requestors working in the past!).

Ashley, RebGUI is really a great toolkit. Many thanks for making 
it freely available.

shadwolf do you have a compatible widget table-list with rebgui-bluid 
114 thank you in advance ?

amacleod ----> http://shadwolf.free.fr/RebGUI-038-shad.ziphere is 
a working version of rebgui + my list list-view

hi, i have a problem with rebgui build 116 on table or field widget. 
i post a file here could some explain to me what append when i want 
to do a update of a row ......