AltME groups: search

I played with Graham's ERM program, and although he seems Tab-happy, 
it also shows off how cool RebGUI is (and fast)

Maybe, but did not much with rebgui. What was the question?

the action would be selecting the next row in a table widget. i cant 
solve that either but its more possible that i can solve it by myself 
than figuring out how do the keybindings work in rebgui

http://polly.rebol.it/test/test/nextgen/www/../../../test/nextgen/../rebgui/../extend-engage.r

http://polly.rebol.it/test/test/rebgui/../../test/nextgen/../rebgui/rebgui-widgets.r
area: make rebface [

Problem is the face/text-y. if that is different than current size-text, 
its adjusted. if you add a line, size-text changes. if size-text 
changes, next show jumps.

hmm.. ive tried to use this rebgui stuff for the 1st time for a real 
problem, but it look buggy. a table cant be focused by tab (in spite 
of append ctx-rebgui/edit/tabbed 'table), a row in a table cant b 
focused by the program in an obvious way. the dropdown list doesnt 
rolls up after dropping down and it doesnt drops down if i click 
on its text.

rebgui-widgets.r and also rebgui-edit.r ?

Yes. But needed is only the line in rebgui-edit.r

using the original files from rebgui, I need to only make one change 
in rebgui-edit.r ?

Hmm, maybe i changed something else too. IIRC there was some problem 
with offset-to-caret somewhere. The fix to my fix is that one line, 
and defixing my change in %rebgui-widgets.r

http://polly.rebol.it/test/test/rebgui/index.r

There where to lines outcommented in %rebgui-edit.r . keeps caret 
visible now. (do not know if that has sideeffects.)

How would one get the layout for a window?  In VID, the layout can 
be assigned to a variable, but in Rebgui, that information is lost.

I'm sure it is, but that defeats the purpose of rebgui which is to 
build a complete gui toolkit without having to know the internals.

Another problem - RT's request-dir traps when you try to access a 
directory that is not available, but RebGui's crashes.  And it can't 
be trapped with a try block at the request-dir level.

Added Czech dictionary file (see http://www.dobeash.com/it/rebgui/roadmap.html) 
and dat files provided by Bobik (see http://www.dobeash.com/files/CzechWin.dat
and http://www.dobeash.com/files/CzechLinux.datfor different char 
encodings - win-1250 & ISO-8859-2 respectively).

1) display mod - just by adding "view-face" at the end of the function 
I presume? Does that give you what you need? (I was thinking of adding 
a "no-show" type refinement for folks who wanted display to return 
a face *without* doing a view - to-image being the main usage case)


2) Window options - needing to set these implies a new widget is 
required or you need more control than RebGUI was designed for


3) Group-box is a functional grouping, tabbing between widgets within 
the same group-box is normal behaviour - what is missing is *another* 
mechanism to tab into and out of group boxes

Just wondering if it would be useful to allow rebgui and vid to operate 
together.  So, you could do all the easy stuff that rebgui allows 
you to do, and when you needed something it couldn't do, then to 
use Vid instead.

RebGUI and VID should work together as is. I've tried to avoid word 
name / context clashes for this very reason. Following should work:


 display "" [button "VID" [view/new layout [btn "Unview" [unview]]]]

Ashley,  btw, I've been experimenting with RebGui for  project I'm 
working on and it is quite nice. Thanks for your efforts.

RebGui is very nice .. but we also want perfect :)

I find a frequent need in other applications to close down popup 
windows with the escape key.  So, perhaps an option like this for 
RebGui windows?

I have not looked into RebGUI styles in detail yet, but what are 
the options to "skin" them? Or to do them (styles) in different colors 
etc.?

CTX-REBGUI/COLORS is an object of value:
	window          tuple!    236.233.216
	widget          tuple!    244.243.238
	edge            tuple!    127.157.185
	edit            tuple!    255.255.255
	over            tuple!    255.205.40
	menu            tuple!    49.106.197
	btn-up          tuple!    200.214.251
	btn-down        tuple!    216.232.255
	btn-text        tuple!    77.97.133

CTX-REBGUI/EDIT is an object of value:
	...
	tabbed          block!    length: 5
	hilight-on-focus block!   length: 2
	caret-on-focus  block!    length: 4
	action-on-enter block!    length: 3
	...

ctx-rebgui/widgets/set-sizes unit-size font-size


Plus many widgets have various option flags to control some aspect 
of their behavior.


Probably not skinning in the true sense but enough to change basic 
scale, colors and behaviors to cover the major use cases as they 
have been presented to me thus far. Skinning that lets you change 
"look & feel" to the extent that the GUI can mimic native Windows, 
OSX, C64, etc could be done but at what price in complexity and delivery 
time? And what percentage of folks would just stick with the default 
look & feel anyway. Another way of saying this is to ask whether 
it is a good idea to put 80% of your effort into satisfying the needs 
of 5% of your user-base?

In fact I find it nicer than traditional OS look. and RebGUI tries 
to mimick OS a bit.

Right at the beginning of RebGUI I asked if anyone had good pointers 
to a consistent graphical style that we could follow (other than 
WindowsXP, Mac OSX, KDE, etc) ... in the ensuing silence I chose 
to go what I'm familiar with, XP. I'm still keen to have a modern 
looking REBOL style that doesn't look too out of place on Windows, 
Mac or Linux; but I'm not a gfx guy. Jaime's BEER interface (the 
GUI config front-end) is about the best I've seen far.

I've had good feedback on the GUI for my RebGUI application.

So, that's a direct compliment for RebGUI.

shadwolf
	tabpanel with scrollable header - being added to 0.3.8
	menu - see note below
	listview - being added to 0.3.8

 treeview – data structure should be simple & consistent with other 
 widgets ... sub-blocks are the obvious way to go but I'll leave the 
 implementation choices to you ;)

Menu Widget


I am of the opinion that a menu widget is more trouble that it is 
worth as:


1) Its use is being discouraged in modern UI design (toolbars have 
made them obsolete to a great extent) - they feel just so Win95 these 
days

2) Mac OS X does not use them at all (at least at the application 
window level)

3) A fully-fledged menu widget is practically a UI in its own right 
with menu entries having icons, toggles, key shortcuts and various 
other mini widgets

4) The underlying REBOL popup system needs fixing first (this also 
impacts the edit-list, drop-list and context-menu widgets)

5) It's just too complex to meet the definition of a simple RebGUI 
building block widget - our time is better spent on other widgets 
that are required

6) How many users clamour for menus these days? Most folks I've met 
prefer pressing a single button / icon and positively detest multi-level 
menu selection

All my opinion, so feel free to disagree.

UI Design


Chris / Pekr touch on very important points here ... we have to live 
with the fact that we are trying to create a cross-platform UI. This 
UI must:


1) Look & feel relatively familiar to users on Windows, Mac and Linux

2) Be internally consistent (e.g. RebGUI widgets behave in a consistent 
manner, have a similar look to each other, etc)

3) Be externally consistent where expected (e.g. scroll buttons at 
each end on Windows, grouped on Mac; tab-panel look, etc)

The way to achieve this, IMHO, is:


1) Don't try to mimic one particular OS too closely (i.e. try to 
pick a neutral look - I think users of an OS are more tolerant to 
something that looks different as opposed to something that looks 
like it belongs to another OS)

2) Adopt the lowest-level of common functionality across OS's where 
possible (e.g. down arrow functionality is pretty well defined)

3) Make allowances for minor, but common, differences (e.g. tab-panels 
are rendered quite differently between Windows and Mac, system fonts 
differ, buttons appear quite different)


So in practical terms I want to gradually move away from a WindowsXP 
look and start adding a few conditional look & feels depending upon 
OS. These will not fool anyone into believing a RebGUI app is native, 
but at least Windows users will not be left feeling it's a Mac / 
Linux app or vice versa.

I'm looking forward to see a tree-widget in RebGUI. This will make 
it mostly complete for a good bunch of applications.

I agree with Robert, that RebGUI is almost complete. That is still 
the main obstacle with VID, it is feature incomplete. Although there 
are some styles out there developer can use it, it simply does not 
come with standard rebol distribution. I am a bit disappointed, that 
Gabriele said in RT Q&A group, that we will at least know, WHAT actually 
is planned for VID and that we will know it "soon". But if "soon" 
means two months from conference just to tell what is planned, then 
how "soon" such plan can be realised, right?

just my 2cents regarding menus: what I really would like as well 
is what Robert told about, circle menus. They're far better than 
rectangular menus (in most cases anyway used for  context menus). 
The big advantage is, if done correctly that one can use them blind 
via forming a habit. This means of course that the content must not 
change (anyway a principle a good UI should obey). So one can simply 
right click (or whatever action to activate the menu) and go with 
the mouse in a certain direction and release, all in a fraction of 
a second and be sure to have selected the right item. For beginners 
the menu can appear and be visible, but for somebody who formed a 
habit it doesn't even have to be long enough visible to actually 
see it - because the whole item selection was faster than that it 
could appear.

One of the drawbacks is, that one can't put as many items as in a 
rectangular menu, best is 4, but maxium probably 8 items if there 
are 8 sectors for the circle. But I like to think about it in that 
way that one can form the mouse menus more levels (probably only 
two make sense), in that way that after selecting one item a second 
circle appears which can offer more choices. And because this can 
get habitual again it's very userfriendly for both experts and beginners 
without forceing either to something. For instance I think the useability 
of Operas mouse gestures is an example for tree menus which don't 
even appear. But in principle one could think that upon pressing 
the right mouse button a circle appears and moving to the item downward 
opens another menu so that moving again to the right selects the 
close window item. The only problem with submenus might be that it's 
kind of hard to find a good middle way for the distances the mouse 
cursor has to travel and error tolerance.

Wouldn't that be really something worth implementing in Rebgui ? 
:-)

Just cross-posting Geomol's styles: http://home.tiscali.dk/john.niclasen/canvas/newstyles.r
Might be a nice base for RebGUI.

yes ... currently there is in RebGui, but there is not with Geomol's 
styles. Or do I miss anything?

would be fun in rebGUI ^^

tab-panel: will investigate
min-size: from the display users guide:

2.1.2 Min-Size

Specify a minimum OS window resize size.

display/min-size "Example" [
    tight
    text 80 blue "Some text" #W
    return
    box 80x40 #WH
] 400x400

Note


The min-size limit will only be enforced upon a window resize, and 
the size is inclusive of an OS specific number of border / title 
pixels. Also note that if any widgets are resizeable (#H and #W) 
and min-size has not been specified then RebGUI will assign a default 
value equal to the initial window size.


table: Already noted by Graham (arrow does not share label feel) 
- will add to list

Graham - what RebGUI is your app based upon? It shows UI defects, 
which are way too much easily to get into - resizing destroys some 
parts of UI, table keyboard scrolling does not work - it moves hilight 
off of the screen, pop-up system is not fixed either, which is pretty 
annoying ...

Most of those issues are with RebGUI / View itself not Graham's application. 
Next release of RebGUI, which corrects a large number of outstanding 
issues, is waiting on the imminent release of View 1.3.2 (which among 
other things fixes the 'parent option).

Ashley - I know, that is why I posted reply in this group, to actually 
see the reaction of when next RebGUI release is planned, and what 
it will address :-)

Ashley my ask to see those widgets implemented in REbGUI retail as 
it is not to bother you on the contrary the return i get on those 
widget was pretty low... So i think adding them to  retail RebGUI 
 will allow all REGUI fans to see the code to learn some tricks and 
to propose some new things  or bug correcting  ^^ So my ask is more 
 to dynamise and  relaunch the RebGUI process than to be bad with 
you ^^

shadwolf, it's easier for us to see them integrated into the rebgui 
distro to try them out.

shadwolf, I'm having a bit of trouble integrating listview52. Copying 
the code and removing all "ctx-rebgui/widgets/" paths gives the following 
error:

** Script Error: Invalid path value: edge
** Where: view
** Near: show face/pane/1/pane


which is odd as your code never explicitly refers to edge. As you 
are more familiar with the code, could you have a quick look at merging 
it into your copy of %rebgui-widgets.r (v 0.3.7) and upload the working 
result.

Robert, in answer to your first question:

display "" [
	field 50x50
	return
	field 50x50
	return
	field 50x50
	at 52x0
	field 50x154
]

display "" [
	field 50x50
	field 50x154
	at 0x52
	field 50x50
	return
	field 50x50
]


(the later does not work correctly under 0.3.7 - adding a simple 
"max-height: 0" to the 'at rule in rebgui-layout.r fixes this under 
0.3.8).

Better than GPL:


RebGUI is a community project that is free for both commercial and 
non-commercial use. Dobeash Investments Pty Ltd retains copyright 
on the name RebGUI and the concepts embodied in the display function 
as well as all associated documentation other than that which covers 
REBOL/View Facets.

Code submissions, in particular widgets, will 
be accepted and credited to the author under the condition that they 
carry these same licence conditions.

how i understand this bug ashley RebGUI widget compositor expect 
to find a edge field in this object and as it doesn't it crash

events: IMO a very, very important thing to add to RebGUI. Think 
about your apps. I always need this feature and most frameworks etc. 
don't support it well. The problem is, that if you have to add it 
yourself, the code becomes hughe and complicated for maintenance.

Adding a focus / unfocus action sounds like a good way to do it.

How's this for focus / unfocus trigger logic?

1. Add two user-definable action handlers to ctx-rebgui

	app-focus-action: func [face] [true]
	app-unfocus-action: func [face] [true]

2.Modify the ctx-rebgui/edit focus and unfocus functions:

	unfocus: has [face][
		if face: view*/focal-face [
			unless face/unfocus-action face [return false]
		] 
	...

	focus: func [
		"Focuses key events on a specific face."
		face [object!]
	][
		unless unfocus [return]
		if face/show? [
			unless face/focus-action face [return false]
	...

3. Extend the standard rebface definition

4. Add the following to the layout function:


 focus-action: either attribute-focus-action [make function! [face 
 /local var] attribute-focus-action] [:app-focus-action]

 unfocus-action: either attribute-unfocus-action [make function! [face 
 /local var] attribute-unfocus-action] [:app-unfocus-action]

which would then let us write code like:


 ctx-rebgui/app-focus-action: func [face] [face/text: form random 
 1000]

	display "" [
		field
		field focus [face/text: form now/time/precise]
		field
	]


The logic is simple: "Execute the default focus / unfocus functions 
(which in turn default to true) *unless* a focus / unfocus function 
has been provided for the face. When a focus / unfocus event is called 
execute the assigned handler function *first* and only proceed if 
it returns true."

Does this meet the design requirement?

ctx-rebgui/app-focus-action: func [face] [face/text: form random 
1000]
; would this line change every face that receives focus?

Hi. Just looking through rebgui. A question and a comment. (1) In 
the readme.txt file there is a reference to Opera icons but no reference 
to the licensing of those icons. Where can I find the icon licensing 
information please?

(2) I like the table widget with it's sortable columns. But at first 
had problems with trying to sort in the reverse direction because 
I was targetting the sort indicator triangle which does not do anything.

1) These are provided as samples only (for %tour.r) and given that 
I could not find any reference to the licensing of them I added that 
note instead. If anyone has a source of good, free program icons 
then let me know and I'll get rid of the Opera ones.

2) Issue#44 at http://www.dobeash.com/it/rebgui/issues.html

Latest build available at: http://www.dobeash.com/files/RebGUI-038.zip

Issue log: http://www.dobeash.com/it/rebgui/issues.html


*** Unzip this file into your existing RebGUI 0.3.0 distribution. 
Requires View 1.3.1 (1.3.2 preferred) ***


This is mainly a bug-fix release with a new prototype event trigger 
system (see %"Demo - actions.r") and a very early proof of concept 
bubble-menu (see %"Demo - bubble-menu.r").


I'm particularly keen to see whether the event trigger system is 
flexible enough to remove [or reduce] the need for a dedicated (and 
hard to design / implement) one-size-fits-all "field validation" 
system as discussed previously. The bubble-menu demo shows how transparency 
and event detection within a non-square area *could* be done. The 
implementation is not perfect (or anywhere near usable) so I'm open 
to alternate design suggestions! ;)

- still - pop-up system non system friendly (not Rebgui issue, but 
rebol one's)

- I have some difficulcy with leds - If you would not provide me 
with text help, I would very hardly know, what those state means 
- I am not sure such style has place in standard pack ... or just 
- let it transparent for 'not-selected selection, green for 'on selection, 
red for 'off selection ...

- table - still you are able to scroll hilited row "under" the table 
style border - it should know it is at last displayed element and 
start scrolling, scrollers should reflect that. If there is no internal 
track of hilited row/cell, then it is not true grid system (I hope 
not)

- bug with text-list multi selection - there seem to be bug in math 
... press shift, hold it, hilite e.g. 6 rows. Still hold it, press 
some two rows below, it let's hilited only first two rows ...

Once try to fix that: http://polly.rebol.it/test/test/rebgui/.

complete version 0.38 can be grabed here http://shafwolf.free.fr/RebGUI-038-shad.zip

ashley  my ten seconds solution for edge  problem with listview integration 
to rebgui rebgui-wigets.r file

edge is said as invlaid path .... so thise  means  a  /edge is not 
good  and looking to rebgui widget code we found that  /edge is related 
to color/egde so i think the problem come from a prebuilded widget 
 onloading  this one have a problem or color/edge reference maybe 
try to dig this out please ashley...

i merged it to  rebGUI 038 ^ ___ ^ -----> grab  it from http://shafwolf.free.fr/RebGUI-038-shad.zip

http://shadwolf.free.fr/RebGUI-038-shad.zip

http://shadwolf.free.fr/RebGUI-038-shad.zip

REBGUI 0.38 Shadwolf version !!!


- FULL  retail files no need to merge them back  with previous REBUI 
version
- Didec-requestdir mini app 
- Listview as base object  
- Demo-listview.r shows how to use the listview widget.

lol nice... I plan on trying RebGUI for my next little project, but 
never downloaded it before...

yea rebgui is very very neat  it's growing in size but it's still 
pretty  cool  widget library . I recommand it to you as simple as 
Vid but mutch more sophisticated  ^^

http://www.lexicon.net/antonr/rebol/rebgui/add-remove-tab-panels.r

>> change-dir %../
== %/D/rebol/rebgui/

>> do http://www.lexicon.net/antonr/rebol/rebgui/add-remove-tab-panels.r
connecting to: www.lexicon.net
Script: "add/remove tab-panels" (8-Dec-2005)

** Access Error: Cannot open /D/rebol/rebgui/programs/rebgui/rebgui.r
** Near: do view-root/../programs/rebgui/rebgui.r
relayout: has [fenetre-cannibalisee]

I've been looking at alternate UI / icon resources recently and stumbled 
across Tango - the standards they propose might just be what RebGUI 
needs. Take a look at:

	http://tango-project.org/Tango_Icon_Library
	http://www.tigert.com/archives/2005/11/16/tango-ui-for-web/


and let me know what you think about making RebGUI tango complient.

Tango: Very interesting stuff, and looks like these guys thought 
a lot about doing it right. I vote for using it for RebGUI. Frees 
us to do invent the wheel again.

I think Tango is nice, but I really much would appreciate or like 
to sea some standard way to add a textual description to icons, like 
often used nowadays. I know almost nobody will want to give up icons 
or graphical objects, but in order to make RebGUI as good as possible 
I think to add such a textual description by design would be very 
very good.

I think of something like another parameter to a button in which 
the label is placed. The UI could then offer a simple way to activate 
or deactivate the labels, the icons or have both, side by side or 
on top or below. 

This way we get the best of two worlds (only some space needed) - 
people can choose for themself and with the text it will be almost 
always clear what a button means.

Of course the could be done externally by adding a second row or 
column to every button, but this would separate what belongs together.
What do you guys - especially Ashley think ?

Anton you have to set do %rebgui.r instead of  do  /D/rebol/rebgui/programs/rebgui/rebgui.r

now  i will rework on rkini my irc client and base it on RebGUI

I can't locate the user's installation of rebgui, unfortunately.

<devil's advocate>With a project like RebGUI I would expect to be 
able to find a URL that I could use to execute the source within 
my application.  Preferably the link would include a COMPATIBILITY 
number so that any updates to RebGUI would be executed seemlessly 
using 'load-thru but if at any point an update is known to break 
compatibility with a previous version then it's downloaded from a 
different URL and hence wouldn't screw with my application.  We have 
to be able to leverage the infrastructure of the internet in our 
applications.  Having to load the application on the user's computer 
means that I can't use RebGUI for anything other than an encapped 
application because I don't trust my users to install the RebGUI 
scripts on their system correctly and sorry, but I don't want to 
have to include so many files in my application and I'm not going 
to take the time to copy them all into my application either.</devil's 
advocate>

Remember that RebGUI is still alpha and we probably want to incorporate 
Reb/Services at some point ... but apart from that an excellent suggestion. 
If you, or someone else, writes the necessary code (or pseudo-code) 
post it here and I'll include it in the next build. ;)

Here is a rebgui in a single file. Hope that works. Not fully sure 
because %tour.r needs the rebgui around it for images, so maybe touches 
source too. http://polly.rebol.it/test/test/mixlib/libs/rebgui/rebgui38-full.r

I have issues with rebGUI demo 38 password field - go to Grouping 
tab, enlarge the screen, go to Password field, and try type something 
- at some point, this field stops working as a password field, it 
simply shows your letters you type ...

where in ctx-rebgui can I find and set main window's effect facet? 
I want to have e.g. gradient background ... ctx-rebgui/colors/window 
is not sufficient for me ...

i don't know if that's clear 1.2.8+ rebol/vie version create a public 
directory in the local directory where the script is launched and 
not using anymore the  global rebol/public directory.  libskin installaer 
was design to install all file in the global rebol/public directory. 
As this  system have been broken in  early betas  this produce to 
get as many install of libskins in local public directory that u 
have scripts running it. I fear an online distro system for rengui 
willl produce the same issue... and forcing us to install a rebgui 
version not once for all in rebol/public directory global but in 
local script directory ...

in order to centralize and keep going on the RebGUI project it would 
be cool to get the plugin system fr rebol/view witch carl have yet 
talked about some years later (it as for  binary library extension 
to rebol) to make easier the  over the net deploiement of rebgui 
(what was the topic of our discution on live deployement) Some thing 
like this from the rebol coder point of view would be pertty cool:

SAmple rebol code to check and get for script official plugins:
REBOL [

 "a project that use rebGUI"

]


check-plugin rebgui ; do a test if the rebgui package is installed 
on the rebol/view local install -> if not download it and install 
it

i know that the purpose of rebGui is in fact to be a replacement 
system for vid ( but keeping based on VID..) so maybe it would be 
easier to replace vid faces by rebGUI faces once RebGUI ill be as 
good as we expect ( it's pretty good this is not a critic ..)

Sorry, I wasn't referring to the actual RebGUI widget set, but implying 
that a general table widget should be able to handle any number of 
columns and rows. Such a widget would be used to do all the display 
work inside your chat client widget.

the rebgui table widget is not limited in this way.

Decided to go with a simple manifest / checksum approach. Long term 
we really need something like Anton outlined previously (multi-level 
caching with the option to control it on an app by app basis). Anyway, 
have a try of this:

	do http://www.dobeash.com/files/rebgui/get-rebgui.r


but be aware that it writes its files to the *current* directory 
(as determined by 'what-dir) and replaces any "base" files with a 
differing checksum (so make a copy of any local changes you have 
made and want to keep).


I've also updated the issues log at: http://www.dobeash.com/it/rebgui/issues.html

I do not properly understand the need for auto-updating facility, 
unless provided as general rebgui facility = functionality available 
to custom apps too using rebgui ...

otoh I prefer the get-rebgui, instead of having separate 0.3.0 plus 
the need to copy over newer stuff :-)

Ashley, great that you have made get-rebgui.r. I'm working on it 
to get it to use the public cache and show progress.

I've come against a strange problem. When I do this
	read http://www.dobeash.com/files/rebgui/dictionary/American.dat

it stops and gives a network timeout after reading 23% of the file.
bytes: 68432 of total: 293605 = 23.31 %

This is repeatable. I tried with read-thru/progress and a simple 
read.
Bizarre

Ashley, totally reworked your get-rebgui.r to use public cache:
http://www.lexicon.net/antonr/rebol/rebgui/get-rebgui.r

Works well (do http://www.dobeash.com/files/rebgui/get-rebgui.r) 
except that all the files retain their rebpress prefix! ;) What's 
the best/easiest way to correct that?

Check the contents of public/www.dobeash.com/files/rebgui

demo is at http://polly.rebol.it/cgi-bin/../test/test/rebgui/, http://polly.rebol.it/test/test/rebgui/download.r
. the building is in http://polly.rebol.it/test/test/rebgui/build-archive.r

idea is: load archive once, then load updates the get-rebgui-way.

How do I easily change a 'view-facet in RebGUI while creating a widget 
?

E.g. I want to change the font size of a few 'labels to 16pt, so 
I have to copy the font object. But the using do [] only the last 
do seams to get evaluated - actually nothing else is written in the 
doc - but how to do this without handstands ?

Why does the following not work ? Anamonitor shows that the engage 
got into place, but the rate doesn't work. I seam to forget something,
 
with rebgui:

do %rebgui.r
display "test" [
    text "hello"
    do [
        face/rate: 5
        face/feel: context [
            engage: func [f a e][
                print 'bla
            ]
            redraw: detect: over: none
        ]
    ]
]
do-events


with vid:

x: layout [button "hallo"]

x/rate: 5
x/feel: context [
    engage: func [f a e][
        print 'bla
    ]
    redraw: detect: over: none
]

view x
do-events

???any help :-)

I've seen this problem before as well, has something to do with the 
way 'rate is handled I think. Note that for the RebGUI example the 
'detect function is assigned by 'display, and if you want to debug 
the final result just add the following to the do block:

	do [a: face ...]

then you can examine the face post layout.

From my website: http://www.dobeash.com/it/rebgui/


RebGUI is a community project that is free for both commercial and 
non-commercial use. Dobeash Investments Pty Ltd retains copyright 
on the name RebGUI and the concepts embodied in the display function 
as well as all associated documentation other than that which covers 
REBOL/View Facets.

Code submissions, in particular widgets, will 
be accepted and credited to the author under the condition that they 
carry these same licence conditions.

cool be cool to provide an AGG  based logo to be display in the about 
of the application well rebgui look and widgets are enought "original" 
to be recognized on every project that use them for initiate ppl 
...  but could be cool to get some way to attract users to interrest 
some ho on the  back ground

having a logo in the about can help ppl to see  easly what application 
use rebgui and then maybe attract them to our philosophy  and all 
the background in their application

I'm going to move this over to the licensing group, since I think 
this is more about that than RebGUI.  Simply will be using Reb GUI 
as test subject.

Ashley: what about adding in a radio-group in the rebgui-widgets.r 
file the line

pf/action pf

below the line ca. 1340 

face/action face

in the init section where the engage feel is defined. 

I needed to be able to execute the 'action function when the radio 
buttons change, but in the current implemention only the local action 
functions of the single buttons get evaluated, not the sourounding 
group. But if I'm right only for the parent level the action block 
can be defined, as the layout function only sets this block (if found). 
So either I missed a way even to set the functions for the single 
buttons (via normal means - no hacking) or it would be good to add 
at least the above shown line.


secondly some improvements which would be nice, what's everybodys 
opinion about this:

1. in order to be able to get a reference to a window - display should 
return the window-face

2. it should be optional whether the first window will be the parent 
of all other subsequently opened windows, as this affects the behavior 
of the order of view of the windows, eg. I can't bring the other 
windows completely to the front


it's no big deal to insert it into the code right now, but maybe 
it makes sense to have some of these options in general.

How to actually supply so small changes to the project ? Just posting 
them here - I guess so ?

so the design for tootips on rebgui can be simple and proposed like 
this:  a field called tooltip on all meaning rebgui widget plus the 
insertion on those widgets to the event  timer / show/hide system 
for the over viewed text box of the tooltip