World: r3wp

Robert, I want to stay inside the area

No reason why it can't be supported as the following shows:

display "" [
	a: area
	button [insert tail a/text tab]
]

but which widgets should support it? area? text? others?


If Tab is redefined for these widgets then how does one navigate 
to other widgets apart from mouse clicks? Or should we have a special 
key combination for "hard-tabs"?

Just area I think.

or have an option like it is done in VID

Maybe it's best to support SHIFT-TAB as TAB inside an area. Using 
TAB to navigate between fields is very common to a lot of users. 
And in other programs (like Excel) you have to use ALT-RETURN to 
insert a hard line break in a cell. Just RETURN leaves the cell.

Shift-Tab is already mapped to Backtab. How about Ctrl-Tab instead?

Ok

I don't think you can trap ctrl-tab.

ALT-TAB?

make it optional...

I spend most of my time inside area fields ...

Graham, that caret insert question you had before can be easily solved 
with something like:

display "" [
	a: area "12345"
	button [
		all [
			system/view/caret
			insert at a/text index? system/view/caret "-"
			show a
		]
	]
]


More complex variations (to handle keyboard focus change, multiple 
area targets etc) can be built with code like:

	...
	area on-unfocus [i: index? system/view/caret true]
	...


but the first example handles simple "click within area, click on 
button" type scenarios pretty well as is.

Also committed rev#26 with support for Ctrl-Enter hard tabs, and 
removed references to drop-tree/number-field so create-distribution 
works correctly.

Thanks Ashley, I'll give that a go.

Hmm. Your demo works, but in my program, it always inserts at the 
head of the area field ie. index? system/view/caret is 1

You should check if the caret is in your area/text :
button [all [
	same? head system/view/caret head a/text
	insert ...

Oh no, sorry I misunderstood. Once the caret has left the area and 
moved to another widget the index it was at is completely lost. You 
would need to store the index on each key press, or trap the loss 
of focus and store the index then. Pressing the button would refer 
to that stored index.

as in http://polly.rebol.it/test/test/rebgui/../../test/rebgui/edit-area.r

** Internal Error: Stack overflow
** Where: into-widget
** Near: unless find [object! block!] type?/word get
** Press enter to quit...

Got this error again on tabbing out of a field :(

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

click on the button, and then type in the first field, enter,  click 
the button.

you can now tab between the two fields but can not type as the window 
"0" has focus.
Odd ....

Is Rebgui not tracking the windows correctly? Or something?

Could be that after a button-action the focus is removed, so show-focus 
does nothing.

Except I do have some type of focus as the tab still works correctly.

Just can't type.  And the window is not highlighted as though it 
does not have focus.

Hmm. how about activating it first?

how?

IIRC, basically: win/changes: 'activate show win

but does not help on linux

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 
                        win: find-window g 
                        g/changes: 'activate 
                        show win
                    ]
                ]
            ] 
            return 
            label "I can tab to here but can I type?" g: field ""
        ]
    ]
]

win/changes: 'activate;but still nothing

better ..

I see that VID doesn't have this problem.

I guess it's rebgui bug?

any documents about rebguis patches? AFAIK it has some to events 
and hotkeys and such.

don't remember ..

that stack-overflow, do you have an example?

I can't reproduce it.

But I thought it was due to some lack of focus problem

Which I was exploring focus problems

that 'into-widget goes recursively thru the panes.

so either you have a parent pane as child-pane, or it has a bug.

or the error-messsage is misleading.

but that should be reproducible.

I'm not setting any panes manually.

Just using rebgui in vanilla fashion

so, I think it's a rebgui bug

i agree. 'show would throw an error otherwise.

what would you consider the next most important style missing in 
RebGUI? Is that Menu, or Tree-view? Or other? As for me, it might 
be Tree-view, as it allows to display hierarchies ....

I think WRT widgets we are mostly complete. What I see as the next 
big step is to add runtime APIs to the widgets like: changing the 
buttons in a radio-group, selecting a button programmatically.