World: r3wp

down [
								pf: face/parent-face
								either all [ found? pf pf/data <> face/data ][
									;	deflag old
									old: pf/data
									if old [
										clear skip pf/pane/:old/effect/draw 7
										show pf/pane/:old
									]
									;	flag new
									pf/data: face/data

         insert tail face/effect/draw compose [pen (colors/true) fill-pen 
         (colors/true) circle (as-pair sizes/cell * 1.5 sizes/cell * 2.5) 
         (sizes/cell - 1)]
									show face
									pf/action pf
								][ ;; GC

          insert tail face/effect/draw [pen leaf fill-pen leaf circle (as-pair 
          sizes/cell * 1.5 sizes/cell * 2.5) (sizes/cell * 1.5)]
										show face
										face/action face
								]

I didn't make any notes, but it checks to see if pf is none or not, 
and if none, does the alternate action.

I didn't see a way of creating layouts with no borders, so, in rebgui-display.r, 
line 50, I added this to the list of refinements

/options

 opts [block!]	"Window options [no-title no-border resize] (must be: 
 block word)"

and at line 112, changed the block to read

either dialog [
		unless no-hide [
			hide-popup ; workaround until /away and parent options work
		]
		show-popup view-face
	][
		either options [
			view/new/options view-face opts
		][
			view/new view-face
		]
	]

Did you uploaded those patches as well?

No, I haven't sought an account.

I'd rather people vet my code first .. I'm just not too familiar 
with the rebgui internals.

does rebgui have a toolbar widget?

There is one in the tour.r so I guess so.

ok

How would one provide function keys that are globally accessible? 
 I want to make F1 a help key that is context sensitive ( sensitive 
to which pane has focus etc )

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!!