AltME groups: search

view layout [ button "Rebgui" [ display "" [ text "Rebgui from Vid" 
]]]

when I click on the "Rebgui" button .. nothing happens.

ie. RebGUI can display VID windows, but VID can't display RegGUI 
windows.

Ashley, I have modified RebGUi a little..so can you confirm the above 
?

Very odd... I have my main rebgui application .. which opens up a 
VID based chat client ( pluginchat.r ).  While the chat client is 
open, some of my rebgui windows using 'display, stop opening.  Close 
down the Vid window .. and it all starts working again.

since you confirmed that

view layout [ button "Rebgui" [ display "" [ text "Rebgui from Vid" 
]]]
works for you but not me... I think it's something else.

Remember it's just do http://www.dobeash.com/files/rebgui/get-rebgui.r
now, with the files going to public/dobeash/files/rebgui.

Minor website changes:

Licencing / Development


RebGUI is a community project that is free for both commercial and 
non-commercial use. Submissions, in particular widgets, will be accepted 
and credited to the author under the condition that they carry these 
same licence conditions.


Download

Enter the following command from the REBOL console:

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


To see all the widgets in action type the following from a REBOL/View 
1.3.1 (or later) console:

	do view-root/public/www.dobeash.com/files/rebgui/tour.r

%get-rebgui.r: tidied up display and added /update refinement to 
read-thru.

the most common packages, I have in root of my app, or system/ subdir 
... so e.g. cyphre-styles, reddb, mysql, rebgui .... or how guys 
you simply pack or distribute your app then? doing with cache aproach 
is imo oncorrect, especially if you don't distinguis version of rebgui 
in the path. What if I don't have time to adapt all my apps to new 
version? above aproach shares rebgui dir for all apps ... wrong imo 
....

Ok, I'm confused now.  I downloaded a new rebgui distro using the 
above link.
This still fails for me.


view layout [ button "Rebgui" [ display "" [ text "Rebgui from Vid" 
]]]

So, it opens up the RebGUI window on clicking the button?

Create a file called %test.r in view-root/public/www.dobeash.com/files/rebgui/ 
with the following:

	REBOL []

	do %rebgui.r


 view layout [text form system/version button "RebGUI" [display "" 
 [text "RebGUI from VID"]]]


and then run by double-clicking it. I see "1.3.2.3.1" in the text 
and clicking "RebGUI" displays the RebGUI window.

I see the "RebGUI from VID" popup.

do %rebgui.r
and then 

view layout [text form system/version button "RebGUI" [display "" 
[text "RebGUI from VID"]]]
does not work.

You're not alone:

REBOL/View 1.3.2.3.1 5-Dec-2005 Core 2.6.3
Copyright 2000-2005 REBOL Technologies.  All rights reserved.
REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM


Licensed to: Ashley Truter (commercial) <[atruter-:-netspace-:-net-:-au]>
License ID: 5-00170-1

Type desktop to start the Viewtop.
>> change-dir %public/www.dobeash.com/files/rebgui
== %/C/rebol/view/public/www.dobeash.com/files/rebgui/
>> do %rebgui.r
Script: "RebGUI system" (6-Dec-2005)

>> view layout [text form system/version button "RebGUI" [display 
"" [text "RebGUI
from VID"]]]

fails for me too!

do http://www.dobeash.com/files/rebgui/get-rebgui.r
change-dir view-root/public/www.dobeash.com/files/rebgui
do %tour.r

That works, it's the interaction of VID/RebGUI when REBOL is started 
in a certain way that's the problem.

view layout [text form system/version button "RebGUI" [display "!!!" 
[text "RebGUI from VID"]]]

btw if i vidify rebgui, is there a chance to get it accepted? or 
do you insist on the api-clashes?

do %rebgui.r
and then 

view layout [text form system/version button "RebGUI" [display "This 
is needed!!" [text "RebGUI from VID"]]]
works :)

BTW, good spot Volker. As for your two questions:

1) If i vidify rebgui, is there a chance to get it accepted?


I'll except anything that makes writing a REBOL GUI (View, VID, RebGUI, 
whatever) easier. ;)

2) Do you insist on the api-clashes?

Not sure what the issue is here, please elaborate.

No, argument-lists for actions, init is a block in vid (i suggest 
a rename, init: [rebgui-init] and both are happy.) maybe some others.

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

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

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

IIRC there is some automatic in rebgui. but that automatic changes 
the text-offset back when the edit-function changes 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!

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

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

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

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.

RebGUI goes Beta! With the fixing of some long running area / scroll 
/ slider bugs I've finally reached a stable enough release candidate 
for 0.4.0 Beta; so, from a REBOL/View console:

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


Also note that the demo directory includes a nifty new pie-chart 
widget demo (thanks Robert).


I've also separated the 0.3.x and 0.4.x issues into separate sections: 
http://www.dobeash.com/it/rebgui/issues.html#section-2.3

Changes in this release include:


 Scrolling fixed (all area scroll / slider problems should be fixed, 
 and a couple of minor field scrolling issues were also fixed)

 set-locale function to dynamically change locale files / dictionaries
	pie-chart widget added

 slider width reduced by 1/5 for area, table, text-list, drop-list, 
 edit-list (looks better)

 table column arrows made smaller and darkened, plus right-most arrow 
 moved to table boundary (more space for column heading text)


and an important one from 0.3.9 that I omitted to mention last release:


 drop-list / edit-list now size to the smaller of number of items 
 or available space in the bounding parent face (so no more lists 
 that disappear off the edge of a face / window)

Enjoy!

I can make a start now at rolling the new version of RebGUI into 
my EMR finally.

I added them back in 0.3.2. Note that case does not matter: #"a" 
will match both "a" and "A".


keycodes were a part of VID, which the source of 'display seems to 
use

 ... correct on the first count, but keycodes in VID are implemented 
 via the global events system which is not used in RebGUI (for those 
 who are interested and have the SDK sources; have a look at %view-vid.r 
 - Carl's comments make interesting reading).


RebGUI uses a much simpler (and dare I say more efficient) approach 
whereby the layout function (%rebgui-layout.r) collects keycode / 
face pairs and places them in a keycodes block at the window level 
(%rebgui-display.r). These keycodes are used by the 'process-keystroke 
function in %rebgui-edit.r. All this is very different from the way 
in which VID does this.

Doing it at the window level has a lot of advantages; namely:


 1) automatically supports / handles duplicate keycodes across multiple 
 windows

 2) scales well (a window without keycodes doesn't carry the same 
 overhead as one with lots)

 3) can have multiple keycodes referring to the same face (for efficiency, 
 RebGUI's layout function only uses the last one specified)

 4) can have a keycode that refers to multiple faces (for sanity's 
 sake, RebGUI only acts upon the first face referred to)

Robert: "... a way to specify a starting size of the window that's 
not maximized. I want my app started with a size of 1024x768" Is 
that inclusive or exclusive of:


1) OS Window title bar and borders (which varies not only between 
OS, but also OS version and what DPI settings are in force)

2) Taskbar size and position (Windows) or Dock size and position 
(Mac) or ... (Linux)

Also, what happens if:

1) My display is 800x600, or the more common 1280x1024
2) I use a TabletPC or have an LCD in 768x1024 portrait mode?
3) Someone wants to use my app on a small PDA (300x200)


These are hard issues for a GUI designer to address in a generic 
manner. RebGUI provides some generalized approaches:


1) margin, gap, slider width, cell and font sizes - so you can choose 
sizes appropriates for the target display device
2) colors - so you can cater for 256-color (or lower) devices

3) Auto-resize directives (#HWXY) combined with /maximize - so your 
displays can use all available space without having to know the resolution 
in advance

4) /position refinements that are generic (top, bottom, first, second) 
- so you can design layouts in terms of, "I want this display on 
the left and this one on the right"


So the long answer to this question is, wanting to set an explicit 
display size is the wrong approach unless you are targeting a specific 
resolution device - and in that case just design your displays to 
use /maximise and be done with it. ;)

Robert: "Is there a way to re-use widgets like done with 'style in 
VID? For example: I have a drop-list specification, I need at several 
places but I don't want to copy the code."

Short answer, no.


If you have a "style" that is sufficiently different from the base 
widget (that is used often) then consider:

1) modify the widget's defaults in %rebgui-widgets.r, or
2) modify them inline, as in:

	ctx-rebgui/widgets/<widget>/<facet>: <value>

3) derive a new widget that works exactly the way you want.

And more. In VID you can quite easily add a face to another face's 
pane, whereas in RebGUI you sometimes want to add (or replace) a 
particular widget in a display with another (there is little need 
in RebGUI to add faces to a pane as these low-level details are taken 
care of by the widgets themselves).

Not really. RebGUI can work out what widget currently has focus (if 
any) AND if it's a widget that has undo support enabled.

ESC can be fixed by changing the last few lines of 'process-keystroke 
(in %rebgui-edit.r) to read as follows:

;			#"^[" [
;				;	ESC
;				hide-popup
;			]
		][
			either all [
				event/key = #"^["
				find view*/pop-list view*/pop-face
			][
				hide-popup
			][
				;	if key is assigned to an action do it
				if any [
					not view*/focal-face
					find [button] view*/focal-face/type
				][
					if f: select face/keycodes event/key [f/action f exit]
				]
			]
		]


Only the last of multiple keystrokes provided is used; but note that 
SPC is already mapped to button (so specifying #"^M" would give it 
two mappings ... a keystroke mapping and it's base "SPC activated 
on focus" default).

Skinning: Is it possible ot skin RebGUI in a way that things like 
tabs look Mac like, or that I can add some eye-candy?

yes, Rebgui looks very vague :-)

but the answer in the past was that RebGUI was not meant to be that 
flexible .... so the chances of skinning system are imo limited ... 
but you can always go to 'tab style and change it yourself?

Yes, I know. IMO it makes sense to add a skinnig feature but a lightweight 
one. RebGUI is pure and minimalistic (which it isn't anyway) and 
in this sense should it be possible to add eye-candy stuff.

didec has some Vid fields for that .. but nothing yet for rebgui

Is there a way to set the ALL-OVER window-face option for RebGUI 
faces, too? I think I better ask this now instead of just assuming 
that it was deliberately omitted for the sake of UI responsiveness?

i would like to know why i (we) must transform a resultset avec database 
connexion to add it to table widget on rebgui ?

db: open odbc://user:[pass-:-server]
stm: first db

insert stm {select numutl, nom,station from dbo.users order by numutl}
res: copy[]
foreach row (copy stm) [
append res row/1
append res row/2
append res row/3
]
close stm
close db

unit-size: 4
font-size: 12
tab-size: 120x55

languages: copy []

foreach language sort read %./rebgui/language/ [
	insert tail languages form replace language %.dat ""
]


do show-tour: does [

	display "Widget Tour" compose/deep/only[

  ex-table: table  (tab-size - 48x18) #HW options ["ID" left .3 "Nom 
  Utilisateur" left .10 "Station de connexion" left .40] data (res)

The first issue is due to the fact that 'table expects its data to 
be flat, as in:

	["A" 1 "B" 2]

not blocked:

	[ ["A" 1] ["B" 2] ]


Graham (a long time back) requested that 'table optionaly accept 
data in this format. I'll add it to the list of issues.


Second one is a known issue (#26 at: http://www.dobeash.com/it/rebgui/issues.html#section-2.1
)

Here's a link to an experimental RebGUI widget TIME-PLAN I'm working 
on. It's starting to get useable, even though it's far from beeing 
useful yet (and since it's my first RebGUI widget ever, it's far 
from being very compliant to the RebGUI coding standards, too):

*Very* nice. I wouln't worry too much about how RebGUI complient 
you are at the moment as it looks like you are going to have to code 
a lot of it directly in View / AGG anyway! ;) Watch out Apple iCal 
...

Yes, that's great work! IMO it makes sense to get to a state where 
the widget is mostly feature-complete and than we do a peer review 
to get it optimized and RebGUI compliant.

tried to download rebgui via get-rebgui script and it installed into 
view-root .... the strange thing is, that HKCU\Software\Rebol\View\Sandbox 
says C:\REBOL\View\public .... I wonder where View is getting view-root 
from?

100th RebGUI issue logged: http://www.dobeash.com/it/rebgui/issues.html

Rebolek, is/could the tree-list be made RebGUI compliant? That would 
be really great!! Especially the idea with the VID tag and the SCRIP 
stuff.

Robert: I don't know, I'm not author of HyperNotes, Martin Johannesson 
is. However, he wrote to me, that current version of his list is 
little bit tricky and he's working on new version. So maybe the new 
version may be rewritten for RebGUI. If you like to have a look at 
my patched version of HyperNotes, just let me know.

;-) Issued the request to add this to rebgui.

Just had an unusual enhancement request from a customer of mine. 
As they fill in fields and areas on a form, they want the ability 
to press Ctrl+B to bold the contents of an entire field / area so 
as they can visually note and review what is important prior to clicking 
"Save" and moving to the next form. It would be fairly easy to add 
this to RebGUI (a Ctrl-B bold toggle), but would anyone else find 
this useful?

Need request-file/keep .. have to comment out rebgui's request-file 
because it lacks this.  Thanks.

If the mouse is a waste of time for your users, then they don't need 
a GUI. Just deliver data entry functionality via a console type application. 
My users [medical] make extensive use of TabletPCs so no mouse / 
pen is a bit of a deal-breaker for me. ;)

the mouse is waste of time, totally

 ... so you don't use a mouse for file management (File Explorer) 
 or browsing? And of course you don't need one for Paint type operations? 
 Not everyone who uses a computer is doing pure keyed data entry. 
 Different strokes for different folks.


Anyway, I'm gradually adding keyboard support to RebGUI as time and 
REBOL fixes permit; but it's not high on my list of priorities.

We have the Rebgui sources .. we can add support as needed if Ashley 
is too busy, or we can wait for his schedule.

is this relevant to RebGUI ??

Yesterday I had a phone call with Christian Ensel and we talked about 
how to add more eyecandy to RebGUI. As the RebGUI architecture is 
becoming more and more stable, how about thinking about a simple 
and lightweigth skinning system?

Our idea was to seperate the visual aspects of the widgets into something 
like an own LOOK context. We don't want to made the current widgets 
much more complex. Then RebGUI loads the rebgui-widgets.r and rebgui-look.r 
and you either get Mac, Win or whatevery style you want.

guys - but what about solving that event problem - I noticed that 
in VID, you are able to close pop-up menus by clicking elsewhere 
... in Rebgui not .... I thought it is View low level problem, but 
now it seems it is not ...

0.4.1 is out and is predominantly a maintenance release. From a REBOL/View 
console:

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

Main changes include:

	- set-sizes, set-colors, set-fonts added to global context
	- CTRL-A fires action in text-list / table 'multi mode
	- radio-group, led-group, check-group now auto-size vertically
	- layout now handles false (logic!) correctly

 - effects, sizes and colors can be loaded at startup via like-named 
 dat files (simple skinning system)
	- Minor documentation updates to reflect above changes

WRT to look'n'feel, yes, I think that since most RebGUI widget largely 
depend on draw blocks, it should be possible to put them in the LOOK 
context Robert already mentioned. And by splitting one draw block 
in up to a hand full at most even for complex widgets, with some 
luck you may also make code even more readable and maintainable than 
it is already by seperating e.g. init-only, redraw on every REDRAW 
and redraw on resize stuff into named blocks, which together build 
an effect as in [draw [...constant drawings ...] draw [... state 
dependend stuff ...] draw [...etc...]] I have this in some experimental 
widgets I build to examine and get used to RebGUI done this way without 
noticeable loss of performance. With the EFFECT/DRAW/17: BLACK and 
EFFECT/DRAW/31: 2 * UNIT-SIZE approach one has a hard time to understand 
what's going on a week after you wrote some widget and carves his 
widgets into stone since one will never be bold enough to make only 
modest changes to the drawing sequences later ...

On the draw block comments I agree 100% ... I'd like to refactor 
*all* draw block code into a central container where it can live 
side by side with SVG code [once we have RebGUI support for that].

next update - can we change request to rebgui-request-*

Looks like there's a start http://trac.geekisp.com/rebgui

Jaime has kindly agreed to host RebGUI as an SVN / Trac project and 
our intent is to open up both the code and documentation to full 
collaborative development and revision control (as a large number 
of people have requested in private correspondence to me). A fair 
bit of work is required before this can "go live" (I still need to 
familiarize myself with these "new" technologies), but I'd hope to 
have something in place within a week. Full details will then be 
announced.

Ashley (and others): As RebGUI is designed to stay short and clean, 
chances are, that users want to do own custom styles which aren't 
subject to become part of the standard distro but rather be added 
on a per project basis. With the latest change to e.g. SET-SIZES, 
I for now don't see how to do that in a compatible manner:


In case a user likes to have his widgets respond to unit- and font-size 
changes as the standard widgets do it looks like one has to patch 
SET-SIZES, or am I missing something? You reset all standard  widgets 
there in one central location, which is very elegant, but it looks 
as you have no chance of knowing about styles added later with 

        CTX-REBGUI/WIDGETS: MAKE CTX-REBGUI/WIDGETS [... new widgets here 
        ...] BIND IN CTX-REBGUI 'SELF


May I suggest some mechanism in the widgets FEEL, something like 
RESET or RESIZE, which simply get's triggered from within SET-SIZES 
for all widgets. A RESIZE feel function would have the benefit of 
keeping simply size-changing-related calculations out of the usual 
REDRAW which I'd prefer to be reserved for rapid state changes thru 
user interactions and content changes.


Then, in SET-SIZES you'd simply do some FOREACH WIDGET/WIDGETS [WIDGET/FEEL/RESIZE 
WDIGET NEW-SIZE WIDGET/FEEL/REFONT WIDGET NEW-FONT] 


On the other hand, I'm sure you had good arguments on why not to 
feature an explicit resize and refont mechanism. But me I never understood 
why e.g. RESIZE wasn't in VIEW/VIDs shared FEEL contexts, too, and 
now I'm facing kind of a deja vu with RebGUI ... ;-)

The first step to getting the collaborative documentation up is to 
migrate the widget specific documentation across; and this gives 
us the opportunity to reformat and expand upon the content. But what 
template to use? If you have an opinion on this then cruise along 
to http://trac.geekisp.com/rebgui/wiki/WidgetList#areaand click 
"Edit this page" to play around with the content and formating of 
this single entry (area). Once we are happy with the format I'll 
use it as a template to bring across all the other widget descriptions.

In the works. I've already restructured the source by removing each 
widget (from %rebgui-widgets.r) to its own <widget>.r file under 
a new %widgets/ directory. Next step is to create a link to each 
source file under its matching WidgetsList Wiki entry.


I've also created a monolithic script (striped output from prebol.r) 
which resides at: http://www.dobeash.com/RebGUI/rebgui.zip


The intention at this stage is to have multiple source files that 
can be collaboratively worked on, with a "build" every so often to 
merge them into a single script for easy access / deployment (not 
everyone will want to grab the source from SVN). The fact that each 
widget resides in its own source file now makes it very easy to "plugin" 
additional widgets.

this is a temporary "fix" for line 549 in rebgui-edit.r

if none? caret: caret-to-offset face view*/caret [ return ]

I put up some preliminary changes to the modal popup handling for 
RebGUI. By manually replacing the original files (but keep them in 
a safe place!) with


 http://www.diefettenjahresindvorbei.de/www/rebgui/rebgui-widgets.r

 http://www.diefettenjahresindvorbei.de/www/rebgui/rebgui-dialog.r


you should be able to try them. You'll notice a different and more 
common behaviour of drop- and edit-lists. For the existing styles 
as can be found in the tour script, I haven't experienced unexpected 
results so far. But I'm curious to hear if incompatibilities arise 
in more complex applications that need to be addressed.

line-list is the culprit. Replace the 'show-text and 'clear-text 
functions in %rebgui.r with the following:

show-text: make function! [
	"Sets a widget's text attribute."
	face [object!] "Widget"
	text [any-type!] "Text"
	/focus
][
	face/line-list: none
	insert clear face/text form text

 all [face/type = 'area face/para face/para/scroll: 0x0 face/pane/data: 
 0]
	either focus [ctx-rebgui/edit/focus face] [show face]
]

clear-text: make function! [
	"Clears a widget's text attribute."
	face [object!]
	/no-show "Don't show"
	/focus
][
	face/line-list: none
	clear face/text

 all [face/type = 'area face/para face/para/scroll: 0x0 face/pane/data: 
 0]
	unless no-show [
		either focus [ctx-rebgui/edit/focus face] [show face]
	]
]

Small question.  I try to insert a list from a select in Rebdb into 
the data block  of a rebgui table.  It does give me an error in RebGui 
: invalid data block.  I did try to call the variable (''do'' does 
not fit the bill here, is it?).  The same example from the rebgui 
tour would be a: [1 "One" a] and ex-table: table (tab-size - 48x18) 
#WH options ["ID" right .3 "Number" left .4 "Char" center .3] data 
:a.   From start I would like to populate the table from RebDB, and 
from there my block is valid.  I am trying to make an example of 
a small phone book using rebDB and RebGui, it could be usefull as 
an example working app.  But it has been some month I did not touch 
the keyboard.  I do get rusty.  Thanks for any help on this.

Is there a reason why if you use vid and rebgui together, and when 
you have windows from both open, if you open a rebgui window from 
a vid screen, it opens infront of the existing rebgui screen and 
not the screen that called it?

Graham, that's because all RebGUI windows displayed became children 
of the first RebGUI window opened after the splash screen automatically. 
Currently, there is no /PARENT refinement for DISPLAY, but that should 
be easy to add.

overlooked its rebgui. but works there too?

Rebol []
#include %rebgui.r
unless value? 'ctx-rebgui [do %rebgui.r]

display "ProspectGUI" compose/deep/only [

 ex-table: table 120x40  #HW options ["ID" left .2 "Nom" left .4 "Prenom" 
 left .4] data [1 "Vac" "Gus"] []

 button "Delete1" [ ex-table/data: [2 "Cah" "Sug"] ex-table/redraw 
 ]

 button "Delete2" [ show-data ex-table [2 "Cah" "Sug"] ex-table/redraw 
 show ex-table]
]
do-events

this is rebgui ...

I think Julia wants to do skinning, changing the look of the slider. 
Well, I programmed the slider/scroller, and I can say that it is 
not easy to reskin. You will have to get your hands dirty :)  When 
rebgui first came out, it was intended to be very lightweight, so 
I think Ashley only started to want to add fancier abilities like 
skinning later. When I wrote slider/scroller, I was trying to be 
as minimalist as possible, so it's quite "hard-wired" with respect 
to how it draws itself.

Thanks.


 "how's the splitting of widgets into separate files going?" Done, 
 it's all in SVN now: http://trac.geekisp.com/rebgui/browser


Anyone who wants dev access (both source and Wiki write access) just 
drop me a private message and I'll get you a username (same as REBOL3 
username) and password. A lot remains to be done before I open it 
up to full collaborative access, but having a few folks on it means 
we can test the infrastructure / process (in addition to getting 
some changes into RebGUI faster).

Changes like the above are good candidates to start with. ;)

Hi Ashley, I'd really like to be part of the trac RebGUI initiative, 
so, may I ask you to set up an account for me?

I'm currently working on compatible improvements for the tab handling 
to allow tabbing in and out of widgets grouped in e.g. group-boxes, 
which I'd like to see being part of the official distro.

Graham, you simply SET-SIZES MY-UNIT-SIZE and SET-FONTS/SIZE MY-FONT-SIZE, 
RebGUI does all the rest. If you then unview and redisplay you'll 
see the changes.

Ok, I got it now.
ctx-rebgui/widgets/set-sizes unit-size font-size

Outlook bar control would be a good addition to rebgui.

how can I avoid that the used words in a RebGUI layout are added 
to the global context?

The problem is in file: rebgui-widgets.r inside the choose function. 
I don't have a clue what I have changed in my app to trigger the 
problem.

Robert post the bug to the rebgui trac system. http://trac.geekisp.com/trac

BTW: That's the direct link http://trac.geekisp.com/rebgui

/rebgui

Here is a short example when it fails:
rebol []

;--- Startup
if system/product == 'Link [

 attempt [call reduce ["d:\rebol\view\rebol.exe" system/script/header/file] 
 quit]

 attempt [call reduce ["c:\programme\rebol\view\rebview.exe" system/script/header/file] 
 quit]

 attempt [call reduce ["c:\rebol\view\rebol.exe" system/script/header/file] 
 quit]
	quit
]

;-- use xpeers framework structure
link-root: first split-path system/script/path
link-root: copy/part link-root index? find link-root "/xpeers/"
append link-root %xpeers/
do link-root/framework/anamonitor300.r
do link-root/framework/slim.r

;-- RebGUI stuff

#include %rebgui.r unless value? 'ctx-rebgui [do link-root/framework/libraries/rebgui.r]

;-- SLIM stuff
slim/open 'debug none ; [mark-my-words]
; mark-my-words/init

unit-size: 4
font-size: 12
tab-size: 120x55

display/min-size "CalcIT" compose/deep [
	label "Land"
	drop-list 60 data ["A" "B"] return
] 1024x768
do-events
halt

this is strange...  here is a stupid first  test, try to call rebgui 
after slim... does that change anything?

it is also a pity, Henrik's grid does not work with RebGUI (although 
not supporting my favourite horizontal scroll :-)

Henrik's aim is to get it to work with rebgui eventually.

Ashley, just wondering how well RebGui runs on OSX  .. any reports?