AltME groups: search

BTW, what changes are you having to add back in every time you do 
an SVN sync? I'll look at incorporating the more generic ones.

I also redefined spellchecker ... to do other things

I'm getting a 5 second delay on using the "close" button in the spell 
checker, or on the final "add".  I wonder if it's better to close 
the spell checker window down first and then do the file maintenance.

Do you have a utility for us to build our own dictionaries?  Or is 
it just a collection of unique words?

The dictionary files are just a collection of sorted unique space 
separated words (all on one line, no carriage returns). I extracted 
them from the latest Abiword dictionary files. No utility as such, 
but the trick to generating them in REBOL is to get a block of strings 
then do a:

	write %my-dict.dat form sort unique my-block-of-strings


As for the button disabling question, I thought it was specifically 
related to the spellcheck taking 5 seconds. But, more generally, 
I'm against that type of thing. Far better to pop up an alert or 
progress bar for actions that will take time. Pressing a button should 
provide *immediate* feedback or results.

It's more work, but only the widget really knows how to do these 
things properly.

Agreed, but it's not high on my list of things to do.

Ashely - as you mentioned "to do", what is your prioritisation towards 
RebGUI? Just curious ...

Like RebDB and the SQLite Driver I want to get it to the point where 
"it just works", and fixes/enhancements are rarely required. Currently 
it does most of what *I* need it to do, so I'm focusing on nailing 
the few remaining bugs and getting the documentation up to scratch 
for a 1.0 release. I'm envisaging a lot of changes once R3 is released 
so this won't happen until after that.

If I resize a window containing a chat widget, it corrupts the widget. 
 Can I link to the resize event to do a show on the chat widget?

Graham - why e.g. Chat widget appeared? Do you use it? I will have 
to look, how it communicates :-) btw - why there is the distortion 
to initial display of the widget?

Designer's Guide

 updated with a few minor corrections & clarifications (mostly to 
 do with Beta 2 changes).

If you have a large left box, how do you then align the following 
widgets so that 'return aligns to the left large widget?
In VID you set a ruler thingy ...

That's okay about the alignment .. I just used a panel to do what 
I wanted.

I suspect it would not be particularly overkill to track the caret 
on every keystroke ... editors do it all the time.

Or do you expect the cursor to be positioned between the letters 
"X" and "b"?

Couple of deep design questions. Run the following code:

display "A" [
	button [
		display "B" [
			f: field on-unfocus [false]
			button [print "Click"]
			do [set-focus f]
		]
	]
]


1) Click the button to open display "B" ... type some text, then 
click the OS close button ... then try the same thing again.


What you should see is that you can't enter any text the 2nd time. 
This is due to the fact that the 2nd time set-focus is called it 
fails to unfocus so is left in limbo. Not sure what to do about this 
case.


2) Run the sample again. Click button to open display "B" and click 
the button.


Note that the button's action fired as clicking a button does not 
shift focus (i.e. you can click a button and continue typing in a 
field). The question is: even though we are not tabbing out of the 
field, should the button's action have fired. This question becomes 
even more relevant when the button action does something like open 
a new display (or close the existing one) ... should this action 
be allowed to proceed even though there is a failed unfocus action 
pending?

Ah, you fix one problem only to discover a bigger one! Anyway I've 
uploaded build#89 which addresses the two specific issues above:


1) Clicking the close button on a window now forces an unfocus but 
*without* triggering the on-unfocus action (or a show).


The /close refinement of display must now return true or false to 
proceed or not with the close operation.


2) Clicking a button only fires its action if it is not the current 
focal face and the focal face's on-unfocus action returns true


Try these with the test code posted above. You should see that it 
now behaves as you would expect. But now try the following code:

	display "" [
		field
		calendar
	]


Click on the field and start to type, then click on the calendar 
and continue typing! Why does this happen? It happens because when 
we detect the 'down event we have no way of knowing whether it originated 
from the field or the calendar. %display.r *should* be able to have 
a detect function that (among other things) does a:

	if all [
		find [down up alt-down alt-up] event/type
		face <> view*/focal-face
	][
		code to check on-unfocus
		code to do an unfocus
	]


but this will not work because of a view bug that causes face to 
be the window face *not* the face that originated the event. Urrgh. 
At this time I can't see how to trap and process mouse click focal 
changes. Might have to delve into the VID sources again to see how 
(if) it was solved there.

What do you need to merge, I thought I'd inlined all your changes 
by now?

so, this way I guess I'll have to add to the user's form the do block

Is there a way I can make it so that escape always closes the current 
window?  Or, do I have to put a widget with escape as the key ?

Build#91 uploaded to SVN with inbuilt ESC handling. The processing 
 logic is:


1) If a widget has focus (e.g. an area or field) let it handle the 
ESC
2) If it's assigned to a widget then do the associated action

3) If a popup (including choose: drop-list, edit-list, menu) is active 
close it

4) Otherwise, treat the ESC as a close event (i.e. invoke close handler, 
check for app exit, etc)

who makes ctrl tab, and ctrl shift tab working

 ... easy enough to trap these keystrokes. Figuring out what to do 
 with them then is the tough part!

Also, cursor key to change focus on buttons

 ... yep, keyboard focus control is one of those long-standing issues 
 I'd like resolved. But mouse issues come first for me (i.e. until 
 the focus/caret/mouse system is 100% I'm not interested in enhancing 
 the keyboard focus system beyond basic tab support.

word you were checking used to remain high lighted

 ... by virtue of a focal-face bug. I eventually want to do the highlighting 
 with draw.

what to do is easy - at least in Windows (but I would expect mac 
and linux too), you switch tab focus ... ctrl shift tab goes in reverse 
order ....

But I think you're right, the fastest thing to do is derive your 
own drop-list widget.

Another way of achieving the same effect is to simply populate %locale.dat 
with the required language/domain specific substitutions and let 
layout do its thing. e.g.:

	words: [
		"AAA" "My-AAA"
		"BBB" "My-BBB"
	]

then:

	drop-list data ["AAA" "BBB"]


I just don't see how changing radio-group and drop-list [only] solves 
anything. What about text-list, table, drop-list or any other widget 
that display's a value or values?

Fonts: I want to get some text / labels in "Arial Narrow" on the 
screen. How do I do this? I tried but don't know what I need to do.

We do need a directory selector that can access directories across 
the network.  At present i have to resort to using request-file,and 
selecting a file in the target directory.

if face: focal-face [
            if flag-face? face hide [
                unlight-text 
                insert/dup clear face/data "*" length? face/text 
                do swap-text
            ] 

            tmp: any [caret-to-offset face caret caret-to-offset face caret: 
            tail face/text] 
            tmp: tmp - (face-edge / 2) 
            tmp2: face/para/scroll 

            all [tmp/x < 0 tmp2/x < 0 face/para/scroll/x: tmp2/x - tmp/x] 

            all [tmp/y < 0 tmp2/y < 0 face/para/scroll/y: tmp2/y - tmp/y] 
            action: face-size - tmp - face/para/margin 

            if action/x < 5 [face/para/scroll/x: tmp2/x + action/x - 5] 

            if action/y < liney [face/para/scroll/y: tmp2/y + action/y - liney] 
            show face
        ]

After looking at all of the various UI for Rebol that's currently 
available, and although they are all great in their own right, I 
can't help but think there's something missing.  I've found the rebol 
mashups I've done using Javascript, HTML, CSS and Flash.. to be so 
much more flexible, and of a higher quality... perhaps not in things 
like speed etc., but when it comes to eye-candy, View, and all of 
it's GUI libs come in third at best.


If you're running windows.. take a look at RASH.. a simple blue button 
that floats on top of all your other windows.. click it, and a panel 
pops up.. 

It uses Flash as the UI.. and it's really quite easy to tie Rebol 
into Flash..  and you can do it with core. Why there isn't more Flash 
/ Rebol mashups is weird

I'm of the "don't tell me about it unless I can do it camp" here. 
Nothing worse than hunting through a complex menu to work out what 
I can and can't do. 80% of what I want to do or see should be no 
more than one click away IMHO.

Trick is to remember that the do block is evaluated prior to the 
display being shown, so you just have to use:

	display "" [
		p: panel green data [] false
		f: field false
		do [p/show?: f/show?: true]
	]
	do-events

Is it feasible to do the same for area widget?

The reason most UI's dont do this is you either have to reserve space 
for the slider, leaving an empty area, or dynamically readjust the 
text to fit ... which annoys users as the number of lines changes 
on them. So, no. ;)

How do you get a slider to react to the mouse wheel?

You have to do it indirectly, as in:

display "" [
	p: panel data [slider] on-scroll [
		var: face/pane/1
		var/data: var/data + either negative? scroll/y [-.1][.1]
		show var
	]
	do [system/view/focal-face: p]
]

I hope it should not be a problem to adapt. IMO Cyphre would do it 
in one day, but let him work on R3 :-)

I found grid.r on trac.geekisp. How do I download the script from 
here? I've tried to cut and paste but hte line numbers come along 
with it. And how do I use it with rebgui?

I'm running he test app with grid.r and rebgui in same directory. 
Do  I need to "Do" grid.r?

I used nVidia cards exclusively, hating ATI. So, I had defined accelerator 
keys for moving windows from one monitor to other, typicall ctrl 
alt num1 (or num2). That worked with AltME and other View based apps. 
I have also some Win32 wrappers to do so - resizing, window z-axis 
positioning, setting window position, etc.

Curl: Do you mean Curl as basic system or transforming to Curl? IIRC 
there system is quite fat and requires special servers etc. They 
have a complicated licensing scheme etc.

So, I agree with Petr, why use Curl if we have Rebol?

And I guarantee you,that REBOL plug-in, if done right, is a killer 
product. Let's show that html monkeys trying to do stupid grids slow 
as mollasses that REBOL can be light years faster. Web should never 
get past static page displays :-)

Graham - Cyphre's styles pack contains tabs with arrows, so that 
you can have more than is visible space. Horizontal only though ... 
You could contract Cyphre to do it for RebGUI ....

Is there something I can do to trap the error at the widget level 
so it doesn't propagate upwards?

Build#99 uploaded with fix to above. You can now do:

	rg/select-item 0

or:

	rg/select-item none

That's not a trivial thing to do with the current design ... and 
then add the complexity of action types (single, double or alt-clicks; 
combined with various on-* triggers ... it gets messy very quickly).

Hmm, I'm sure it never used to do that ... I think a bug has been 
introduced along the way. Need to fix that one.

In the following script I would like to be able to click on a row 
of the table to populate the data entry fields, so that I can edit 
the data for the record displayed in that row. How do I do that? 
 

rebol []
do %sqlite.r
do %rebgui.r
unless value? 'ctx-rebgui [

    either exists? %rebgui-ctx.r [do %rebgui-ctx.r] [do %rebgui.r]
]
set-colors
tab-size: 120x55

fonts: reduce [font-sans-serif font-fixed font-serif "Courier New"]
if not exists? %id.txt [write %id.txt 1]
either not exists? %indodex.db [
    CONNECT/create %indodex.db

    SQL "create table base (ID, Title, Nama, Alamat, Kota, Propinsi, 
    Telefon, Handfon, Fax, Email, URL, Tgl_Nikah, Nota)"

    SQL "create table birthdays (ID, Nama, Jenis, Hubungan, Tgl_Lahir, 
    Agama, Nota)"
][
    CONNECT/flat %indodex.db
]

do show-cc: make function! [] [
set-colors
(i: to-integer read %id.txt)
label-width: 19
f-width: 59
display "IndoDex Ver. 1.0.1" compose/only [
            button-size 16x8
            margin 1x1
            space 1x1
            ;image %roladex.jpg 
            ;return
            label 7 "ID:" id: text (to-string i) 7
            pad 17
            ;label 13 "Nama:" 

            title: drop-list 30 #W "Pak" data ["Pak" "Ibu" "Sdr." "Sdri." "Drs." 
            "Dr." "Tuan" "Nyonya" "Nona" "Pdt."] 17x5
            nama: field f-width
            label label-width "Telefon:" 
            telefon: field f-width
            label label-width "Handfon:" 
            handfon: field f-width
            return
            pad 31
            label label-width "Fax:" 
            fax: fax: field f-width
            label label-width "E-Mail:" 
            email: field f-width
            label label-width "URL:" 
            url: field f-width
            return
            pad 31
            label label-width "Alamat:" 
            alamat: field f-width
            label label-width "Kota:"
            kota: field f-width
            label label-width "Propinsi:"
            propinsi: field f-width
            return
            pad 31
            label label-width "TglNikah:" 
            tgl_nikah: field f-width
            label label-width "Nota:" 
            nota: field 139
            return
            return

            t: table options ["ID" left .03 "Title" left .04 "Nama" left .2 "Telefon" 
            left .16 "Handfon" left .14 "Fax" left .14 "E-mail" left .15 "URL" 
            left .15] data (sql "select id, title, nama, telefon, handfon, fax, 
            email, url from base") 270x150 
            return
            button "Add" [
                either all [nama/text <> "" nama/text <> none][

                    SQL reduce ["insert into base values (?, ?, ?, ?, ?, ?, ?, ?, ?, 
                    ?, ?, ?, ?)" id/text title/text nama/text alamat/text kota/text propinsi/text 
                    telefon/text handfon/text fax/text email/text URL/text tgl_nikah/text 
                    nota/text]

                    insert t/data SQL "select id title nama alamat kota propinsi telefon 
                    handfon fax email URL tgl_nikah nota from base"

                    ;a: sql/flat "select id/text title/text nama/text alamat/text kota/text 
                    propinsi/text telefon/text handfon/text fax/text email/text URL/text 
                    tgl_nikah/text nota/text from base"
                    ;sql reduce [insert table/data a]
                    id/text: form i: i + 1
                    save %id.txt i
                    clear-text nama
                    clear-text alamat
                    clear-text kota
                    clear-text propinsi
                    clear-text telefon
                    clear-text handfon
                    clear-text fax
                    clear-text email
                    clear-text url
                    clear-text tgl_nikah
                    clear-text nota
                    ;show id
                    t/redraw
                    return
                ][
                    alert {Cannot save if "Nama" field is empty.}
                ]
            ]
            button "Update" []
            button "GUI Info" [

                print [id/text " " title/text " " nama/text " " alamat/text newline]
            ]
            button "DB Info" [
                print [TABLES newline]
                SQLite/col-info?: true
                newline
                print [SQL "select * from base" newline]
                print [SQLite/columns newline]
                print [ROWS "base" newline]
            ]
            button "Halt" [
                halt
            ]
            button "Quit" [
                quit
            ]
]
]
do-events

Ashley, we talked about this before.  I  am looking for a way to 
spell check in a popup or static window attached to the area that 
is being checked, and to double click on the choice, have it replace 
the highlighted text, and then move on to the next text which is 
then highlighted.  I got it working except for the part of highlighting 
the next word that is suspect.  It highlights and then immediately 
loses the highlight .. perhaps something to do with the double click 
and focus system?

I remember looking at this and concluding that ctx-edit.r would have 
to be changed rather dramatically to allow this ... it has to do 
with the order in which set-focus and show are called. Several minor 
hacks I experimented with (mainly in set-focus) just didn't cut it. 
I put it in the "too hard" basket but may revisit this now that the 
long-running (for me at least) pick-list bug has been fixed; and 
I also have a few users asking about this as well.

You need an async version of ftp, or spawn another process to do 
this.

I always use display/dialog for requestors. Works well; not a whole 
bunch of code to write.  If you do %rebgui.r (and don't encap an 
app) you still have access to view's request-text.

REBOL [
	title: "Weird error in area"
	Date: 04-Dec-2007
	File: %areaerror.r
	Author: "Johan Aires Rasten"
	Version: 0.1.0
]

do %rebgui.r


; Values of 25 or less doesn't produce the error, but larger ones 
do
max-info-lines: 26


display system/script/title [
	panel sky data [
		after 1
		button-size 30
		button "Status" [print-info "status"]
		button "Archive" [print-info "archive"]
		button "test" [
			loop 30 [print-info "status"]
			loop max-info-lines - 4 [print-info "archive"]
		] 
		button "crash!" [print 1 / 0]
	]

 info-area: "To see error: Press test button, then Status once" area 
 80x40 #HW options[info] data []
]

info-area-list: make list! []

print-info: make function! [
	info
][
;	Add the line to the buffer
	append info-area-list rejoin [info "^/"]
	if max-info-lines < length? head info-area-list [
		remove head info-area-list
	]

; set-text works, but it moves the scrolling area to the top
;	set-text info-area rejoin make block! head info-area-list

; This produces weird errors:
	info-area/text: rejoin make block! head info-area-list
	show info-area
]

do-events

So, to use list-view as an example, you can now write:

do %list-view.r

display "" [
	area 60x40
	vid 60x40 data [list-view with [data: [a b c]]]
]

Magic, huh?

Ashley ~ contratry to what you state in the User Guide, multiple 
returns do not seem to work at all - can you confirm tthis? Anything 
I am missing?

Ashley - what is the method of choice to temporarily disable/re-enable 
input widgets (fields, drop-lists, checks)  in code ?  Disable as 
in: do not allow focus or content manipulation.

There isn't. These things are set when the widget is created. In 
the rare cases I've had to do this I just unview and redisplay ... 
not elegant but it works.

Umm, re disable;  Doesn't  on-focus [false]  do what Kaj wants here 
- kinda - mostly?   The widget is still on screen but you can't click 
on or tab to it.

Not soon. This is a hack to support common editable widgets, whereas 
a proper solution should support every widget that is editable *and* 
selectable (e.g. tab-panel, table, drop-list, check, radio-group, 
etc). It means adding 'info support to a lot of widgets that currently 
do not have it.

Ashley, Is there a simple way to get this version, or do I have to 
download & install a SVN client?

Just wondering if the tree might return more information than just 
the face text. Say you want to retrieve stuff from a database but 
only want to do so if it is a level below a node.  At present you 
don't know if you're at a node of a leaf.

Robert, yes. Your tree-view widget is a superset of what I need / 
want (and is 21Kb vs my 3Kb).


Ideally, I'd like every widget to be 5kb or under, with 10kb a max. 
After developing and merging over 40 widgets I've come to the following 
conclusions:

1) 90% of the basic usage cases can be coded in under 5kb
2) Double the code size to increase this to 95%
3) Quadruple this size to get it to 99%

4) Time required to maintain / fix and document a widget increases 
exponentially as code size increases

5) A widget that tries to do many things is no longer a widget ... 
it is an app (list-view and grid fall into this category)

6) While developing the sheet and tree widgets I came to the realization 
that the scroller logic could be externalized in another widget (scroll-panel) 
thus removing much of the duplicated scroller handing code found 
in a number of widgets


Where does this leave grid? Near as I can figure it's a combination 
of table and sheet, but supporting cell types other than plain old 
field. I can see how folks want to pull data from a DB and put it 
into a grid, so does that mean we have 'typed' columns or can every 
cell be different. If the later, then aren't we just talking about 
a sheet with support for more datatypes?


And now for the accessors. We obviously want functions to load and 
save data, put and get cells, and add / delete rows; but do we really 
need functions to move columns around? Or hide and reveal columns? 
It's very easy (and tempting) to over-engineer ... but keeping things 
as simple as possible (but no simpler) makes for a stable system 
that is easily fixed, extended, maintained and documented.

Yep, a lot of that code is app / context specific; although the widget 
should allow you to extend its functionality via APIs rather than 
having to "roll your own" every time you need a bit of extra functionality. 
scroll-panel is a move in that direction; "I'd like a spreadsheet 
here, and I'll put that in a scroll-panel because I want to scroll 
a large sheet; and I'll add left-click and right-click handlers to 
handle load and save; and assign a screen dump routine to F3, etc". 
All that is currently possible. "I'd like to move this cell from 
here to here" is not currently possible, and I doubt anyone could 
create an API that could let you do *everything*. (take something 
simple like alternating row colors; I had someone ask if the *number* 
of alternating colors could also be specified!)

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

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

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

RebGUI Core

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

request-dir function has lost the 

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

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

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

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


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

Would be cool if you think of it in terms of simply clicking inside 
the center of a printed checkbox, and the widget-checkbox simply 
scales (expands) until it hits the edges, and then some (several 
more pixels).


In theory you could do the same thing for areas where you are meant 
to fill in hand written items as well.  Basically looking at where 
the cursor was clicked, "falling" down until you hit a line, then 
expanding left and right until you hit stuff.


I designed a cool tool about 20 years ago called Snarfit that allowed 
artist to just draw where ever they wanted, and then it would grab 
everything on the page and save them out as separate objects.  It 
basically looked for blank space, and sucked up to the objects.


~ sad when we have to be compatible with printed technology.  We 
are about to undertake a huge project of making Qtask a Content Management 
system for scanned images.  I plan to make it just like Google maps, 
where the images are scalable (in chunks) and then you can draw on 
them, add tasks (as PostIts), etc.

I looked at the RegGUI logo and...well

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


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


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

I'm open in all ways.  Meaning, when you have some feedback, I will 
do up a bunch (differnt colours, etc.), use or don't use what you 
like.  It takes me just minutes to pop one out.  I have a system 
set up to make such art...

Exactly.  There is also the concept of having widgets remember from 
session to session.  We are working on this for tabs in Qtask (we 
already do some of it).  

Each person wants something different, so we focus on it first doing 
what you expect it to do.


I have an idea for something that could be really cool, or really 
suck.  The good news is it is completely passive, so it won't annoy 
anyone.  The concept is this:


A magic mode you can jump into on any application or service (ASP).


In this mode, everything does NOT behave as expected, but rather 
become more abstract and detached.  So if you click on a button, 
for example the [Send] button here in AltME, a menu pops up:

---------------
Send
What is this?
Options
Rename
Translate
Shortcut key(s)
---------------

For each of these


Send - simply does what ever the button is actually meant to do (in 
this case "Send"

What is this? - Jumps to help, and has a bi-directional unique ID.

Options - Things you can set about the behavior of this button, for 
example, with "Send", you might want to know about the multi-line 
feature.
Rename - Rename this button in the current language.

Translate - Change or give this a name in another language (superset 
of Rename)

Shortcut key(s) - Se the shortcut for this, and also see all the 
others so there are no conflicts.  Allows for mode hierarchy of keys.



Would be really cool to make this a framework of its own, so that 
it is automatic.

are we replacing the tab, or the panel?

 We're replacing the panel, which in this context is refereed to as 
 a tab. Same logic applies to the 'select-tab accessor.

Are we sure widgets should 

remember" their state?" ... with regards to the RHS of the display; 
it can be argued either way. If I want to look at the usage text 
of each widget then it's nice to be able to scroll to the bottom 
and then remember this state as I click on each new widget ... but 
then again, if I want to "start afresh" with each entry it'd be nice 
if the scroller reset. As discussed, I'll add this as an option.


re: Magic modes. In one of my apps I had "programmable" buttons that 
you could right-click to bring up a menu of what the button should 
say (it's text) and what it should do (it's functionality). Only 
a small number of these buttons existed and they were colored differently. 
This one simple feature saved a lot of screen real-estate, was easy 
to explain to end-users; and most importantly, was the "killer" feature 
for those using the app.

What color does it use for borders?
 ... none, it's transparent.

will sheet and tree-view support at least keyboard basics?

 sheet already supports tab, tree at present has no keyboard support. 
 These are on the "things I'd like to improve one day if I have nothing 
 better to do" list. ;)

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

Providing keyboard support for inherently graphical controls (e.g. 
radio-group, spinner, etc) is IMHO a waste of time. All the main 
input widgets (field, edit-list, area, sheet, etc) should and do 
have proper keyboard support. If you're designing an application 
for fast data entry then you should confine your widgets to those 
that accept keyboard input (i.e. data entry forms). If you want a 
rich GUI with a full set of graphical widgets then I don't think 
it's too much to ask that users have a pointing device. I mean, you 
don't expect users to use Windows without a mouse? Or Office type 
applications?


But, list away as I'm currently doing major code fixes (better scroll-wheel 
support for one) anyway; if it's relatively straight-forward to do 
I'll do it.

Should RebUI do anything that Windows and Mac don't?  Seems there 
are going to be places where a cool widget would save space, or allow 
for a neat trick, but............it also means something most people 
won't know or understand.

Uploaded build#112 with extensive changes.


1) scroll-wheel support added to scroll-panel (CTRL+Scroll to scroll 
the horizontal scroller)

2) set-values and get-values fixed (added support for scroll-panel 
and fixed a few bugs)

3) Added a new widget, pill, that is basically a box with rounded 
corners

4) Changed the look of tab-panel so that the current tab is same 
as page background and remaining tabs have a solid color

5) splash requestor now accepts a file! or image! (so you're not 
forced to provide a spec block if you already have an image)
6) Experimental new logo

7) Color management is being totally overhauled (I'll post separately 
on this topic)


*** Do not sync this build if you want to retain the "old" look & 
feel ***

RebGUI color management.


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


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


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

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


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


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

	http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines

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

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


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

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


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


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

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

and widgets such as sheet which might have:

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

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

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


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

Ok, here are some other examples, and considerations when sized.


For example, when you get small, the "hand" looks like the REAL hand 
on the screen, which could confuse people.  So while it is fun at 
larger sized, it won't work once the pixels drop to less than 4x4 
each (my guess).


I think you might like the one in the lower right.  It is very RACEY, 
the italics make it look "fast" and the black and red were something 
I think you requested.

If you want me to try something special, or do a treatment like something 
else you have seen out there, just say the word.


This one is a Qtask syndicated Folder.  So any file we put in this 
folder from inside Qtask can be accessed by people outside of Qtask


http://www.qtask.com/files.cgi?tab=sFolderList&uuid=YG82XF3CFW8AQ6W5NYTXV9NKE3QT


So for example, since this came from the "REBOL SIG" project inside 
Qtask, Ashley, you can go into that project, and delete this file, 
which will effectively put it in the Trashcan, and this link will 
then point to an empty folder for people.

Just wondering how hard it would be to do a predictive text like 
widget

I think they do it that way to avoid having to use the mouse ...unless 
you can make the selection without using the mouse, choosing will 
be slower than typing.

I see how I can "talk" to , say, a text in a group by doing   set-text 
group/pane/1  but how  do I set the caption of a text in a group 
on the second tab of a tabgroup?

do you have to be on the tab panel you are replacing to use tab-panel/replace-tab 
?  I see the new layout appear on the current tab.

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

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

Click the button then tab "B".

... Was this related to the new look?

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

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

Daniel; Check out http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=layout-1.8.r
for a what you see is kinda what you get layout editor.   The tricks 
will be buried in the code, but it has to do with ordering the face/pane 
entries.  Also see http://rebol.com/docs/view-system.html#section-3
for a description of face/pane.

display "" [ area 100x100 options [ info ] on-click [ print "You 
clicked me"]] do-events

- the area does not respond to the on-click action whereas


view layout [ info 40x40 [ print "You clicked me" ]] works fine in 
VID

There seems to be a problem in 2.7.6 on WIn XP
start  rebvire them go to console
do %rebui.r
editor %some_file_not_yet_existing.r

; now hit Save as : concole returns and both console and editor are 
locked up
; TEST

; REpeat without load of rebgui.r ; warning so such file and then 
Save As will save as that file no problem

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


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

Alternative is to use CALL and launch an external editor.

Is it possible to display a modal window, without using dialog? My 
program gets screwed up if display calls do-events and disables tooltips, 
but I don't want users mucking about with the main window while another 
window is open.


And speaking of which.. Is disabled tooltips in dialogs a new feature? 
I suspect it's the reason my tooltips stopped working a while ago 
:\

Maybe what i need to do is keep a record of all the active windows, 
unview/all and later on view them all again.
So, need a view/all windows [block!]

I've got a tab-panel next to a panel - where the panel is on the 
right.  I wish to hide the panel ( set the width to zero, and hide 
it ), and shrink the whole window by the space previously occupied 
by the panel.   But if I do this, the tab panel also resizes.  Is 
there a way I disable resizing temporarily?

An odd error .. if I do this on a table ... face/remove-row I get 
an error complaining of an invalid path.  I have to use the table 
name

What do I need to "include", when doing rebface + rebgui? rebface.exe 
tour.r does not work ...

Robert - there still has to be a leak in REBOL! Even if you try primitive 
hello world example, you start with 6MB of RAM, you do nothing, and 
after do-events it grows 3 - 4 MB, slowly, but constantly!

I've got some custom panels that I have a resizing routine written 
for them.  how do I trigger that to run when the main window resizes?

the MS demo expands in-situ which would be nice to do ... but I recreate 
the whole thing

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

this works 


do %rebgui.r

display "" [

label "Publication : "   

  publication: field  100x8   font  [  size: 18 color: black  shadow: 
  none  ]
					on-unfocus [ uppercase publication/text 
							     ; I'd like to jump to "page" field here
									
							   ]
		label "Date :"     

  date: field  30x8  font  [  size: 18 color: black  shadow: none  
  ]
		on-focus [ set-focus page false ]
		
		label "Page: "  

  page: field  20x8  font  [  size: 18 color: black  shadow: none  
  ]
		return
] do-events

Mmm ! Your code sort of does the job, but your forcing the field 
Date to be skipped by it own on-focus trap
which would skip Date always,
what I'm trying to do is have Description

control the next field to 'visit' depending on what ever test I code 
in the on-unfocus
 attached to Description field.

for eg: ( pseudo code )

label "Publication : "

  publication: field  100x8   font  [  size: 18 color: black  shadow: 
  none  ]

  on-unfocus [ if desc-flag = 1 [ set-focus new-description ] [ set-focus 
  old-description ] ]

====

Your observation of 'reseting' focus back to Description field is 
an interesting one which I had not considered.

well, until Ashley tells us how to do it, you could hide a dummy 
field behind the date field to take the focus from the tab, and then 
make the decision from that.