AltME groups: search

Hi Pekr, I don't understand, sorry. I think that even OSes are inconsistend 
there. My personal taste would be some event eating, but I have what 
others like. 

Actually, I'm used to one single OS Windows, forgotten how Intuition 
did such things on Amiga and know nothing about Unix, Mac and such. 
That's why I'am asking how OSes do it.

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 ... ;-)

Currently, every widget has to be prepared for window-, unit- and 
font-size changes at any time when redrawing. I'd expect them to 
be handled easier and even faster if they'd be slightly more explicit. 
But, as I've said, I may be missing the point here. Eventually you'd 
simply suggest to do 

	redraw: func [face action event] [
		if face/size <> face/old-size [face/feel/resize face]
		if face/old-sizes <> sizes [face/feel/rescale face]
		if any [
			face/font/old-font <> face/font
			face/font <> face/old-font
		][
			face/feel/rewrite font
		]
		:
	]

But it would be kind of boring to so in every single widget.

(Just thinking out loud)

title-group: show-text works with the body, while you can do a:

	insert clear tg/pane/text "New title"
	show tg


to change the title. Note that this will not cater for a change in 
number of lines.

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.

Question: How do you handle the case if you have an application that 
has hundreds of fields and you need to reference those in the GUI 
code to get values in and out.

Do you imagine a lot of names? Or is there a more systematic way 
to do it?

Robert:
	1) global words: they are not. Try the following:


  f: has [v] [display "Test" [v: field button [unview halt]] do-events]


 My normal approach is to wrap each display in its own function with 
 something like:


  display-account-summary: make function! [id [integer!] /local f1 
  f2 f3 f4 f5 f6] [
			...
			display "Account" [
				f1: field
				f2: field
				...
			]
			...
		]


 2) tab-panel: works, just take a look at how it is used in %tour.r. 
 Note that it defaults to "size: -1x-1". Maybe you need to make the 
 panel contents bigger?

Hmm.. you can do it many ways. What's the application to do and what 
will the window layout have in it ?

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.

hummm drop down list is a nightmare of coding ... this is typically 
(in my opinion) one of the easyly doable in C/C++ but tricky to do 
with rebol. Tricky but why ?? Mainly because of the speed when you 
have to redreaw the main pane and the scrolling interface

How can I access the SVN repository via a client? What URL do I have 
to use?

not sure ... how do you want to display hierarchical structures?

Yeah, all these points do need to be addressed.  I will hold him 
[Mr. C] down, you tickle him.

What do you mean exactly, and what interface to SVN do you use? (I'm 
sort of studying iCVS vs SVN right now).

Yes, I need to do a bit more to "sell" the whole collaborative dev 
idea; plus I think folks need a bit of hand-holding to use SVN. Perhaps 
a "5 easy steps to making a change" type guide?

RebGUI 0.4.2 is up. Grab it the usual way with:

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


You may want to delete view-root/public/www.dobeash.com/RebGUI first 
as a number of old files are now redundant.

This build is the latest snapshot of the repository and includes:


 - %rebgui.r is now a single monolithic (72Kb single line) script 
 (individual source files are in SVN)
	- Cyphre's drop-list change
	- Anton's quit [not] when only one pane remains
	- clear-text and show-text fixes
	- led widget fix (failed when encap'ed)
	- language file for Italian added
	- %tour.r Opera icons replaced with Tango Desktop equivalents


Also note that the RebGUI home page has moved to http://www.dobeash.com/RebGUI/
and that all active issues / tickets can now be found (and updated) 
at http://trac.geekisp.com/rebgui/report/1

How can we now make a change to rebgui.r? Do you have published the 
build-script that creates rebgui.r?

to get the face created by the rebgui 'display function ...

The last line of the display function is:

	view-face

so it should already do this without change.

Hang on, I'm just about to publish what I have, which is working. 
 In Tortoise, do I use the Import... menu option or SVN Checkout 
?

Yes, once you do an "SVN Checkout" the folders and files are displayed 
with a green tick. Editing a file causes it (and the folder it appears 
in) to be displayed with a red changed icon. Right clicking the root 
folder, RebGUI in my case, and selecting "SVN Commit" prompts for 
which changed scripts (and a comment) you wish to save back. Pretty 
straight forward once you've done it.

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

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

well, you can always state anything. Being a developer's tool does 
not tell anything how ppl are using Rebol to develop. I am not comfort 
with idea of installation, simple as that. I never use double-click 
to launch my scripts and never will do, untill we get one exe and 
components (file associations issue). And noone should explicitly 
tell, how do I use any tool.

I have my View\RebGui, View\whatever-project subirs. I do like to 
simply copy on my USB and go. With current aproach, while it follows 
OS customs, for me it is flawed. I can't even spell easily enough, 
where tour.r is located. I would welcome some "look-up" function 
to not care - simply if it is in my sandbox, wherever it is, just 
run it ....

I've also thought about splitting the code in more levels to achieve 
better abstraction. Whether this would help for a RebGUI version 
or not, I don't know. I do think that there would be a need to create 
automation for building both for VID and for RebGUI.

Having converted (or at least used as a starting base) a number of 
VID styles to RebGUI widgets I've observed that the final code is 
40%-60% smaller (YMMV) and easier to understand in that most of the 
logic resides in the widget itself (i.e. it is self-contained). But, 
once the code to be converted reaches a certain size where I can 
no longer 'grok' it in a single reading (about a hundred lines for 
me) I find it easier to code from scratch. ;)


I'd also break it into two separate widgets: grid and list-view, 
and look at the minimum function set each requires (KISS).


Simplest way to start is to read all the doco under 'RebGUI Documentation' 
at http://www.dobeash.com/RebGUI/then look at the source code of 
a few widgets (start with something simple like %button.r then move 
onto %table.r which shares a lot in common with list-view).


If you run into any brick walls (or find yourself asking, "why oh 
why did they do it that way?") just drop a note here. ;)

I'm going to test all those changes and than we are ready to publish 
them back to the official RebGUI repository.


Ashley, do you first want to take a look at the changes or should 
I just check them in?


What about the docs? Who is going to update them? Should the RebGUI 
docs be added to the repository as well?

how to do that type-change on creation?

Robert

 Docs: the 'Widgets' section of the 'RebGUI Display User's Guide' 
 is already in the Repository (the WidgetList Wiki entry) ... I'll 
 be removing that section from the guide once all the widget details 
 have been copied across. Feel free to update the Wiki with any widget 
 specific usage notes / instructions. Forward any other doc changes 
 to me and I'll put them in. I plan to eventually move all the docs 
 across to the Wiki, just haven't got around to doing it yet.

 "do you first want to take a look at the changes or should I just 
 check them in?" ... Just check them in thanks.
	screenshots: added to the ToDo list

 widget placement: I'm coming around to the idea that BELOW may be 
 unavoidable, even if undesirable from a design / complexity POV
	tabbing: Anton about summed it up

Volker
	Type: also used by accessor functions

It might be cleaner to do it the way I suggested, but anything that 
illuminates helps :)

Why? The main dialect parser of RebGUI can now be expressed in one 
simple parse construct:

parse reduce/only spec words [
	any [
		opt [... evaluate () to return a REBOL value...]
		[
			parse rules to handle REBOL values
			...
		]
	]
]


compared to the relatively complex parsing logic in VID (which, to 
be fair, has to handle styles amongst other things).


The main functional difference between what this allows in VID and 
RebGUI is that you don't need to parenthesize your expressions in 
VID (and I kind of like the idea of having to parenthesize them anyway, 
it makes expressions stand out just like they do in compose).


Having said that, if someone can show me a RebGUI parser built along 
the lines of VID that is clean and lean I'll willing to be convinced 
otherwise. ;)

Couple of minor administrative fixes:


 - Examples added for every widget in http://trac.geekisp.com/rebgui/wiki/WidgetList
  

 - http://www.dobeash.com/RebGUI/display.htmlupdated to reflect latest 
 changes (and have information duplicated in WidgetList removed)

 - Updated site with latest build and corrected path to: "do http://www.dobeash.com/RebGUI/get-rebgui.r"

How about adding a refinement to the display function that does something 
similar to the load-form-data function we discussed a while back. 
We could then populate forms at creation with:

	display/load-data "" [..] block-of-values

and reset them with:

	load-form-data my-form block-of-values


I think it's a lot cleaner to do this on a form basis than trying 
to do it at the widget level.

Sorry, guys didn't made it yet to publish all our changes. Hope to 
do this weekend.

Might not be a RebGUI related problem, but let's start here: I have 
the following problem from time to time on my system and always on 
the system of one of my testers.


On my system: I start my app, the gui comes up and I click the first 
widget and the app falls back to the console. Without an error. This 
happens as do-events returns.


The same problem is on the other system, but here I only can do one 
click on a widget.

ATTENTION: rebgui-edit.r was not yet merged. Latest revision doesn't 
include older changes. We will do this ASAP. But rebgui-edit.r is 
required in this version otherwise all other changes done by us might 
not work.



FIXED *rebgui/pad: Now only works for horizontal padding. Padding 
should happen depending on the layout direction left-to-right or 
top-to-down.
	Cyphre: now PAD works according to the AFTER settigns. Example:
	display "Test" [
		after 3
	    field
		pad 5
	    field
	    pad 5
	    field
	    pad 5
	    field
	    pad 5
	    field
	    pad 5
	    field
	]
	Robert,let me know if it works like you wanted.

FIXED *group-box: When setting a new title group-box/text: "new-title" 
the surounding frame needs to be adjusted to the new text-width.

FIXED *drop-tree: When selecting different quick-access buttons directly 
one after the other, the drop-tree shouldn't close

FIXED *drop-tree: Highlighting the pressed quick-access button with 
green, the hovered one as is in orange. To give user visial feedback.

FIXED *general: a way to sepcify "align ['left]" for all further 
widgets to avoide repeation. Idea: Add disaply keywords: left, right, 
center
	Cyphre: added keyword TEXT-ALIGN left/right/center. Example:
	display "Test" [
		text-align right
		after 3
	    t: text 20 "test 1"
	    field "test 2"
	    field "test 3"
	    text-align left
	    field "test 4"
	    field "test 5"
	    field "test 6"
	]

FIXED *drop-list: an option that will show the list layered above 
everything (like the tree list of drop-tree).
	Cyphre: added drop-list/popup-mode: 'inside(default) or 'outside
	note: the same works for drop-tree

FIXED *drop-tree: changing state of the drop-tree (a new entry was 
selected) should only be done if the ACTION code returns TRUE. Otherwise 
the old state is kept, the drop-tree is closed and nothing happens. 
This allows the code to check for some pre-conditions before changing 
the state, and give some feedback to the user. Much like the on-unfocus 
functionality of RebGUI.

FIXED *drop-tree: pressing the quick-access numbers doesn't work 
any more as the drop-tree closes now if the mouse is clicked outside 
the drop-tree

FIXED *table: table/selected returns NONE if the table is empty and 
no record is selected. If there was one recrod selected at any time, 
than table/selected returns [none none <repeated for number of columns>]. 
If not row is selected at any time, table/selected should just return 
NONE.

FIXED *table: If a table is re-used in that the table is reused with 
code like:
	insert clear table/data [...]
	people/redraw

and there was a row selected before, than the internal state is still 
in "row selected" but the new row isn't highlighted. Here internal 
state and GUI don't match.

FIXED *drop-tree: clicking a "+/-" in the tree only open/closes the 
tree without calling the action for the node

FIXED *drop-tree: Re-add whole line selection and hovering functionality 
(so that mouse does not have to be over text)

FIXED *drop-tree: Add an option to get big fast-selction keys aligned 
left-to-right
	Cyphre: added drop-tree/expander-mode: 'big(default) or 'small

FIXED *button: Add an option to disable a button my-button/active: 
true/false, if disabled the button is drawn greyed-out
	Cyphre: usage is my-button/active: true/false show my-button

FIXED *field: Support number datatypes for TEXT so that things like 
field-a/text + field-b/text can be used

 Cyphre: you need to set field/edit-mode: 'numbers to activate this 
 behaviour for field(othervise it works like a normal field)
	2nd implementation uses own styel: number-field

FIXED *radio-group: Add an API that allows to provide a new DATA 
specification block at runtime or a way to alter the text of the 
radio fields at runtime.

 Cyphre: now you can just change the data content and do show on the 
 radio-group like:
		my-radio-group/data: ["item1" "item2" "item3" "item4"]
		show my-radio-group

 Note that it won't react on change of number of items. Just change 
 of texts.

FIXED *radio-group: Add a way to select one radio field at run-time
	added accesor select-item item [integer!] usage:
		my-radio-group/select-item 2
		show my-radio-group

 note: you can get the selected item using my-radio-group/picked, 
 you can get the text of selected item using my-radio-group/selected

FIXED *drop-tree/grey-out: Can it be done in that we only show the 
text in a light grey instead of black? Like Windows does it.
	Cyphre: now the masked text is light grey

FIXED *on-focus / on-unfocus: If FALSE is return from the ACTION 
and the user clicked somewhere on the screen, the focus is still 
in the "field" but no cursor bar is visible

FIXED *drop-list: IIRC in your widgets it was possible to start typing 
and the selection list was filtered. A mandatory feature for the 
drop-list :-))

 Cyphre: added drop-list/editable? flag to enable/disable editing 
 of the drop-list field

 also added drop-list/auto-fill? flag which enables automatic text 
 filterin from the selection list

FIXED *general: add hover tooltip help option to every widget (global 
patch)

 Cyphre: added TOOL-TIP facet to rebface object. If TOOL-TIP is set 
 to string! value a tooltip is shown when mouseover such widget.
	example:
		display "test" [
			button "press me" tool-tip "press this button to continue"
		]

FIXED*drop-list: proivde a much better selection-list opening algorithm 
especially for long lists. Open upward, downward, middle like so 
that as much entries are shown for the given screen space. And an 
option that will show the list layered above everything (like the 
tree list of drop-tree).
	Cyphre:

 -added droplist/lines - can be 'auto (default) or integer! to force 
 number of shown lines in droplist

 -added droplist/droplist-mode - can be 'auto (default) 'upward, 'downward 
 or 'middle to force way how the list is popped up
	you can use various combination of those settings.
FIXED*table: Add an API that allows to select a row at run-time.
	Cyphre: Usage is for example:
		my-table/select-row 5
		show my-table

FIXED*table: Add an API to table that allows to change the columns 
layout at runtime: my-table/reset ["Column 1" left 0.25 "Column2" 
center 0.75]

 Cyphre: I added the functionality byt the API call is my-table/set-columns 
 ["Column 1" left 0.25 "Column2" center 0.75]

FIXED*drop-list: fire action only if selection was made/changed, 
at the moment action fires if clicked on field too

FIXED*general: on-un/focus should be fired if user clicks an other 
widget, not only if carets leaves the widget when TAB is pressed

FIXED*table: moving bar up/down with keyboard should fire click-action, 
alternativ: pressing RETURN can fire click action

FIXED*table: align header text like data (left, center, right) at 
the moment always left
FIXED*table: TRAC #21

FiXED*TRAC #5 Cyphre: should be fixed but please test it and let 
me know.
FIXED*TRAC #6

how do you guys use get-rebgui? do you download it to your rebol 
directory? Because - in other case, I still struggle with not remembering 
the url to run it ....

So please, could I ask for get-rebgui change, to place itself in 
rebol home dir, simply to allow ">> do %get-rebgui.r" with next usage? 
Thanks eventually ...

Cyphre: now you can just change the data content and do show on the 
radio-group like:
my-radio-group/data: ["item1" "item2" "item3" "item4"]
show my-radio-group

Note that it won't react on change of number of items. Just change 
of texts.

FIXED *radio-group: Add a way to select one radio field at run-time
added accesor select-item item [integer!] usage:
my-radio-group/select-item 2
show my-radio-group

note: you can get the selected item using my-radio-group/picked, 
you can get the text of selected item using my-radio-group/selected

I think it is imperative really as otherwise we are forced to delve 
into the internals of rebgui to do simple things.

I just tried rebgui, and I have a few questions ...

is there a reason, that display opens the windows, but does not start 
do-events? This seems a bit strange to me. When testing layouts in 
the console, I mostly end up with inactive windows.

And to restore the form contents, in the do block of the layout, 
I go thru the layout and restore the values.

How to reference the layout from within a do block ?

can't do ... users are allowed to create the forms

Why do you need to populate the form? crash-backups? defaults?

if 'face in the do-block refers to the layout, how to get this inside 
a button action block?

I am creating templates which I load up and display.  These templates 
contain some variables for label widths etc.  I have to bind the 
template to the variables, but then if I do that, operators such 
as '- have no context.  do I have to redefine '- and '+ etc?

Ingo:


is there a reason, that display opens the windows, but does not start 
do-events?

 ... we can't assume the "first" window automatically needs to start 
 the event loop. Perhaps the display is being assigned to a word and 
 cached for later use? Or the display is done early in the script 
 for lots of subsequent initialization and *then* needs to fire up 
 the event loop. I personally like having to code it explicitly as 
 it then stands out - "We are starting the event loop HERE".

Is it possible to get the window size?
 ... display [button do [ws: face/size]]

Is it possible to set an own resizer function?

 ... No, you'd have to change a lot of code to implement your own.

I would like to have equal sizes for all text-lists.

 The RebGUI resizing model is pretty basic, it supports one resizeable 
 widget in each axis (horizonal and vertical) with any number of offset 
 adjustments (the #XY directives). More advanced schemes (such as 
 proportional or percentage based) are possible, but significantly 
 harder to implement (and require size/state information to be retained).

Graham, I'd thought using () in the template would enable RebGUI 
to evaluate the expressions automatically for you. Do you have a 
small example of what you're trying to do?

Robert: Your rev#21 changes to rebgui-edit.r nuked my rev#19 and 
rev#20 changes ... but the good news is that they collectively constituted 
the following line in the insert-char function:


 unless any [insert? tail? view*/caret newline = first view*/caret] 
 [remove view*/caret]


Should I put that line back in a new rev or do you want to bundle 
that in with any additional changes you are working on?

do %rebgui.r


test: {label "This is a label" (width) radio-group data [ "-" "+" 
] return label "Another label" (width - 5)}

go: func [ template [string!] 
	/local width
][
	width: 20
	template: compose bind to-block template 'width
?? template 
	display "testing ..." [
		(template)
	]
]


go test

do-events

test: {label "This is a label" (width) radio-group 24x4 data [ "-" 
"+" ] return label "Another label" (width - 5)}

go: func [ template [string!] 
	/local width
][
	width: 30
	template: compose bind to-block template 'width
	display "testing ..." compose/deep [
		(template)
	]
]

go test
do-events

Ashley ...

[me] "is there a reason, that display opens the windows, but does 
not start do-events?" [ashley] ... we can't assume the "first" window 
automatically needs to start the event loop. Perhaps the display 
is being assigned to a word and cached for later use? Or the display 
is done early in the script for lots of subsequent initialization 
and *then* needs to fire up the event loop.

Right, that's it! 


As I see it, there are 3 distinct actions: layout, display, handle 
the events.


With view I can do the layout independently from display and event-handling. 
With rebgui I can't, because display does the layout _and_ display, 
and then I'm stuck with a dysfunctional window. So I can't do a layout 
to assign it to a subpane somewhere, it's instantly displayed as 
it's own window.

Is it possible to get the window size?
 ... display [button do [ws: face/size]]


this always returns 100x100, I guess it is run before the actual 
window size is really computed.

>> display "test" [text "hi" do [s: face/size f: face]]
>> s
== 100x100
>> f/size
== 48x52

display was supposed to return a layout and not display as an refinement. 
 It does not.  But it can be changed to do this.

gordon, because you need to add do-events at the end

I know - but if you want to have all in one exe file as a result? 
You have to somehow "include" your code, no? 'do is not enough, is 
it? (as it would expect it being placed in external .r file ...

I'm having trouble running the list-view.r demo.  The error message 
that comes up is:
list-view has no value
  where: layout  Near: list-view 100x80 data [[...

I've checked and found the list-view widget in rebgui-widgets.r so 
I added that to my test program as follows:

do %../rebgui-widgets.r

and I get the following error message:

Error: colors has no value  near: color: colors/edge


this latest error is happening during the execution of the "do rebgui-widgets.r" 
as the statement following this  is not being reached.

All other demos seem to work okay.

Pekr, the SDK trick we use in RebGUI is to have the following lines 
in your script:

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


These appeared in earlier versions of %tour.r but were [inadvertently] 
removed. I'll add them back in.

Gordon, the demo directory and scripts (bubble-menu, list-view & 
triggers) were part of earlier releases. The directory was removed 
when the source was migrated to SVN, and all non-stable widgets (including 
list-view, bubble-menu and a few others) were removed. There is no 
need to "do %rebgui-widgets.r" as this is included directly in the 
new merged %rebgui.r script (and invoked from %rebgui-ctx.r if you 
run from the SVN source direct). LIST-VIEW is an important widget 
which we are hoping Henrik will be able to port to RebGUI from the 
excellent work he has done on this already.

so when I install some CSV product, I will be able to reach it? What 
product do you suggest?

I used to remember how to do this!

I will have to do it anyway, once Cyphre's code comes, or someone 
else would have to do it for me ..

please post privately to me the most critical issues, you would eventually 
see fixed for RebGUI. I will look if there are any money left and 
eventually order Cyphre to do some work in that regars ...

Rebgui request-file is different from VID request-file. Do you mean 
to say you would like the /keep refinement added to Rebgui's requestor 
?

I am having a bug in a program interfacing RebGui to RebDB.

The problem is the following. The behaviour of RebGui'following commands 
having a strange effect on the data managed with RebDB:

my clear-UI function do clears a rebgui interface (simply a set of 
fields) to the RebDB data.

But clearing the 'text fields, it does also clears the values in 
the RebDB database.

At first I was using RebGui clear-text command, and tried the other 
View version just to check.
Both are doing the same thing.

Why clearing the interface fields does clears the data in the database. 
 clear-UI does not ask that.

And no instructions to do that appears in the clear-UI function, 
which is not calling any other function either.

It looks like the 'text field of the fields objects in RebGUI works 
as a direct reference to the database.

And nowhere my code calls by reference. I cannot explain that behaviour, 
nor find any hints in my code as to what causes that behaviour?

Any explanation or ideas on where to look for the cause of that behaviour?


UI-fields: [Funiqueid Fchristen-name Fsurname Fbirth Fname-prefix]
clear-UI: does [
	foreach f UI-fields [
		clear get in (get f) 'text
		show (get F)
	]
	ctx-rebgui/edit/focus (get 'Fchristen-name)
]

Isnt rebdb written by ashley? Then you can bet you have to do the 
'copy by yourself ;)

Not by default. i patched focus/unfocus to do that. maybe that could 
be put in rebgui?

When there is text in a field and we do the focus on it, then the 
text is shaded black.  Is there a command where, instead of shaded 
region, the focus is simply the insertion point placed before the 
string in the field.  The shaded region presumes that we will replace 
it all with a new value.  An insertion point suggest that we will 
correct the entry.  The difference is that we do not have to systematically 
hit a left arrow key first, to correct the field.

Here is a litle demo how to access the caret even if on-unfocus is 
called. eg a buton is pressed. or user edits in a find-area and wants 
to search in the edit-area. works by overriding on-unfocus and  saving 
caret in face. unfortunally i was not able to do it the other way 
around. i can restore the face-caret on on-focus, but something unfocusses 
later when i do that by a button. http://polly.rebol.it/test/test/rebgui/../../test/rebgui/edit-area.r.

I want to add some commands to the top window red "close" square 
button, so that I commit changes to the database and save some data 
before the close.  I can add a quit button on the interface, but 
it is still important that the top window close button do the same 
thing.  I dont see any instructions about that, neither in the RebGui 
display guide, nor the vid spec.  Can someone provide the code to 
do that, or where to find it explicitly?

Thank-you, it works.  It is not clear in my head, as to why 'insert 
clear' is better than 'TheObject/Data: "NewListOfValues"', but Ill 
try to remember it by hart.  I am nearing completion of a small example 
of RebGui+RebDB app.  Last glitches are show-focus and display/close.

As for the option in display to capture the close event, how do I 
state it?  As this does not work.
Contact: compose/deep/only [
; Gui definition
]
do show-contact: does [
	display/min-size "ContactDB" Contact 680x650
	do[show-first-rowid]
	display/close [] [shutdown] ; <-- Culprit
	]
do-events

display "0" [
	button "Click me" [
		display "1" compose/deep [
			f: field "Type here" [
				display "2" [
					button "Close" [show-text f "hello" show-focus g unview]
				]
			]
			return
			label "I can tab to here but can I type?" g: field ""
		]
	]
]
do-events

Pekr, the drop-list would have to be a window itself to do that.

(rebol would have to get the new layer from the OS so it could do 
that.)

guys, I would like to open some UI look chat .... not much, but a 
bit.... Cyphre will look for me to do some slight improvements, e.g. 
to allow gradients for tabs, etc.

Is there anyone else who thinks, that rounded tabs do not work? As 
well as rounded buttons? While we tried to stay WinXP look compatible 
as much as possible, in some situations, rounded buttons do not work 
- try to change tour.r background color to any of darker colors - 
those tabs look more like a leak, than real shape - simply disturbing 
a bit. I have such reaction independently confirmed by Bobik, and 
my brother objected too, without telling him what to judge ....

if there would be too much chat about that, I will ask Cyphre to 
do some changes just for my purposes, as everyone of us will have 
slightly different pov UI wise ...

There is something that people that are making frameworks on the 
web are doing that I actually really like.


They hide all the UI until your mouse is over it.  What I like about 
this is that it reduces the noise of buttons you know are there, 
like [Close], [Minimize], [Resize].  If all windows conform, and 
you can truly trust them all to allow you to do everything, then 
I think this will become the preferred state.

But it only works if the UI is 100% consistent.

1. Highlight the first text field
2. Click on the "server" button
3. Highlight the "type here" field to give focus
4. Click on the "OK" button
the rebgui no longer has focus.
Now do tab .. and it crashes with a stack overflow.

I want to add a row to a table but I don't want to keep a special 
block containing all the table values. How to do it? I only can get 
one entry added and than it's reused. Looks like some sharing is 
happening.

I do. Table is good for text-only multiple column rows where you 
don't need cell-level addressing. Grid will satisfy those who need 
something more complex ... but don't confuse functionality/complexity 
with "better". Table meets *my* needs, Grid meets *yours*; and folks 
can choose to use the most appropriate one for the task at hand. 
Choice is good.

I do not need cell level adressing. It could be even enought with 
simple list. It seems that in begginging I will use them and for 
statuss changes use just some part of text or some symbols:
F.ex:
Msg#1 2006-Jun-01 Unread
Msg#2 2006-Jun-01 Read


But any way -  what could you recoment to use for scrollable list 
with either changeable colors, font styles or including some small 
icon?

I need horizontal scrolling, not cell level adressing so much .... 
table is simply not of much use for most database driven apps ... 
not sure how you design your apps, but I tend to have more than one, 
two, or three columns to display. There is no solution for rebgui 
currently. I do agree, that choice is always good. Btw - the bug 
with scrolling hilite under the horizon is still present with table 
:-)

guys, those of you, working with databases - currently in new grid 
implementation, there are insert column, remove column, swap columns 
functions. Those do physically alter order in block of blocks (data) 
section. Apart from possible speed limitations, do you think it would 
be better to just virtually swap, insert (at the tail), remove (just 
make it invisible), or is it ok?

Hi, I would like to get some feedback on some rebgui-grid decision. 
The thing is, I need to do it till tomorrow, to stabilise a bit and 
go for more final version ....

what I am thinking about is to virtualise even things like insert-columns, 
remove-column (then hide-column becomes redundant), swap-columns, 
so that original data block would not be changed, which can be usefull 
for easy updates to sql directly from data block .... what do you 
think?

how do you solve possible change to amount of data? My friend working 
with SAP grid suggested to me simply keep index block, and assign 
each record a recno virtually, as with update, in multiuser system, 
there could come some new records, or some may disappear ....

At what "size" of array do you notice slow downs?  We are about to 
add a simple spreadsheet to Qtask.  We will be facing the same issues. 
 In our case we will be using Javascript on the front end, but the 
issues are similar, we have to decide which parts work on the client 
(virtual as you would say), or when we do a complete refresh.

Petr: IMO you need to decide, do you have all the data in memory 
or not. If it's up to 10.000 lines and 10 columns you shoul be able 
to do this. Than per line one block. Either have the block contain 
only values (that position matters) or use a name/value pair. Than 
it doesn't. Going for name/value pairs with hash! should be pretty 
fast.

And, I find it simpelst to have the data on the screen and in the 
program in sync. Sorting should alter the data block as well. If 
I pick the first line, I want to pick the first record. Of course 
using an API for indirection is OK too. But than do it always and 
for everything. No direct access to the record data.

Ashley is making the same point I am, "end user" vs. programmer (or 
tech).  Any time a programmer says "I do X all the time" all I think 
is that if "I can bottle the exact opposite of X I can make a billion 
dollars."


Hence I wrote above "The exception is when people are dumping databases, 
and those are not using formulas, but rather are for working out 
data.  This is done by programmers, not by users in general."


Never-the-less, if the goal here is the goal, which is for technical 
people to do this, we all still need a solve, which is speed to do 
it.


In Qtask we did part on the server, and part on the client.  So, 
we let you sort columns locally, but would send all the data to the 
server.  What we learned is:

The server would send down all the data.  Slow, but needed.
Then JS would arrange everything into a table.  Slow but needed.

Then JS would sort.  And we allowed 4 levels of sort… Slow, slow, 
slow, and turns out, not so needed.


It turns out that with anything more than about 20 lines it was better 
in the long run to just sort form the server side.


This is not to say this is how this will work where with Rebol.  
My point is more to the idea of playing with UI until you strike 
the right balance of speed and convenience.

Why does table/selected/n not work?  I have to do .. pick table/selected 
n

Graham - I mean - how do I know, what facets are exposed to 'display 
dialect level? My friend simply asked me, if there is alternative 
to VID's 'with keyword with raw access to widget internals ...

Cyphre and I have continued to fix bugs and enhance RebGUI. We still 
have some bugs to fix but than it's time for a new release. As new 
widgets we have done a CHART widget that lets you do bar, pie, torus 
charts.

Easy enough to do ... just change line 83 of %rebgui-display.r to 
read:

	... reduce ['parent last ...


Consequence of this change (in the example above) will be that closing 
window B will close C. I'm loath to introduce specific 'parent declarations 
... how about a refinement that overrides the default "parent is 
first" behaviour? e.g:

	display ...	-> the default, parent is first window

 display/parent	-> parent is last (usually previous/calling) window

radio-group: I think we need to enhance this widget by introducing 
an ID per selection option, that can be stored to a database. If 
you store the text, problems araise if the text is changed. If you 
store the selection poistion problems araise of the order is changed.

What do you think?

Ashley, how do you programmatically select a tab to display?

Hmm, I want to position the caret, by clicking in a text-list, which 
lists sections of the document.
The action in my text-list
[
         __picked: first face/picked
         show-focus ar-text

         system/view/caret: at ar-text/text sections/:__picked/pos
         show ar-text
      ]

now, when I click into the text-list, ar-text is focused, and the 
caret is shown in my ar-text, but when I release the mouse-key, the 
text-list is focused again.
What can I do here?