World: r3wp

In VID you would just assign a key to the window face:

view layout [key #"^t" [print system/view/focal-face/var] my-field: 
field do [focus my-field] fld2: field]

(with some difficulty getting F1 to work maybe)

Does anyone use function keys in their applications these days?

My apps are generally small, and I consider function keys as an optimization, 
which means my apps usually reach a usable state before I get round 
to adding function keys, and so I never get round to adding them. 
:) I have one or two apps which use them, I think.

If Ashley couple pipe in here as to how this might be done, that 
would be appreciated.

Well, the event arrives first in the window feel, so look in there:
>> win: display "" [] ; now press escape
>> probe win/feel
make object! [
    redraw: none
    detect: func [face event][
        switch event/type [
            key [edit/process-keystroke face event]
            move [mouse-offset: event/offset] ...

hence
>> probe get in ctx-rebgui/edit 'process-keystroke

So, the bottom of process-keystroke handles all other keys than tab 
or space, and it looks in the keycodes facet of the window to cause 
an action.

This is a bit hacky but it works:

win: display "" [text "hello" #"t" [print "hi"]]   win/keycodes/1: 
'f1   do-events

display is obviously creating the keycodes block (of key face pairs), 
so I've just changed the first character #"t" into 'f1 and it magically 
works.

Hey, that's great.

I remember cloning the feel of the area face so I could process Control 
keys but thought it might be more complicated for a global handler.

So, I can alter the process-keystrokes function to handle the function 
keys in a global fashion.

Yes.

Nice hack Anton, and you've pretty much nailed how the whole thing 
hangs together.


Graham, I used to use F1 (for help) in my apps extensively but I've 
replaced them with buttons / icons recently (bit hard to press F1 
on a TabletPC). For that reason I was never worried about providing 
a "Global Keystrokes" block handler or similiar (apart from the fact 
that you then run into issues like, "I want this keystroke handled 
globally except for these cases ...").

Enhancement request posted to trac: there should be a setting to 
switch the drop down and edit lists to popup rather than drop down 
if there is no space below the widget.

I've got an M200 tablet ... no problems using the F1 key there.

Unless the screen is turned over so that they keys are not accessible 
.. but then no keys are accessible in that case.

:)

I'm setting up a preferences screen for users to assign functions 
to the function keys .. no space at the bottom of the screen for 
the drop down lists :(

Ideally, and this is similiar to what you stated above, drop/edit 
lists that can't otherwise fit their contents by drop-down should 
then drop-up if the space above the widget is greater than the space 
below. This should be the default behaviour (i.e. display as many 
lines as possible, with a preference for 'below').

Since we define the layout ourselves, we can manually set that at 
definition time, yes?

Another option is to have a list popup that covers the whole of the 
space above and below.

Why limit yourself in one direction?

should the arrow then point up?

Interested to see Carl is suggesting RebGUi as a possibility for 
R3.

Just a note to all of you: I contracted Cyphre to develop some RebGUI 
widgets. In the next couple of weeks you will see two new widgets:
1. drop-tree: Is a mix of a drop-list with a tree view.
2. tree widget as we can derive this from the drop-tree

I will provide this code to RebGUI and hope others can make use of 
it too and maybe helpt to extend it.

And those quirks as mentioned by Graham are on my list as well. So, 
we will improve existing widgets as well.

Thanks Robert.

Much appreciated. Tree widget is a requirement for an improved directory 
requestor.

area getting a face lift. Any objections to scroll-wheel support 
?

too late.

Ok, committed new area widget with scroll-wheel. Graham, you should 
find it quite comfortable now. Many hours of concentration, hope 
you appreciate it.

Anton - I will check it today, and give you my feedback :)

First report - it seems to work!!

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.

Many hours of concentration
 ... appreciate the effort, works well here.

Updated %create-distribution.r to remove prebol.r and prerebol.r 
dependencies.

Thankyou. Just one thing about scroll-page (ctrl + scroll wheel) 
handling: it could be used for changing the font-size instead of 
being equivalent to page-up/down.

Would it be possible to get assign an action to each column of table? 
 Rather than share the same action as at present?

Is there a way to PAD vertically?

why do we need the DATA keyword for group-box? IMO this should be 
OK:
	group-box "MyBox" [
		label "..."
	]

1) Vertical pad. No such concept in RebGUI as its layout engine is 
purely left to right carriage return (although you can often achieve 
the desired result by ending a line with a box of the appropriate 
height)


2) group-box and DATA keyword: this is required as a block without 
a keyword is taken to be an action (even though for some widgets 
like tool-bar, tab-panel, group-box, etc it doesn't make as much 
sense ... but I think consistency is more important than concise 
expression for a subset of widgets).

1) Ok, how about a RETURN 5 or so?
2) Ok, I agree.

Q: How can I change the number of columns of a table at run-time? 
I want to use three tables and change semantics depending on user 
action. Sometimes table 2 has 2 columns, sometimes 4.

Table widget wasn't designed to be that dynamic. I normaly have a 
dedicated function for more complex displays, structured like:

show-my-display: make function! [
	...
	
	display "Title" compose [
		...
		button "Redo" [
			unview/only face/parent-face
			show-my-display
		]
	]
	...
]


Not ideal, but works well when the 'refresh' is tied to an action 
at the end of the work-flow such as save, commit, next, prev, etc

I guess a grid widget would do this.

Yes, but we don't have one ;-)) So trying to get along with what 
I have.