World: r3wp

Ashley how can we set global event system processing for a display 
?

1) dokuwiki link: will add.

2) spanish.dat: thanks, excellent work. Added to next build and roadmap. 
Anyone for German? Robert?
3) tabpanel with scrollable header: low priority.

4) global event system: more information; what is the requirement?

2) German: Yes, no problem. Does the current .DAT contain everything 
that needs to be translated?

run trhu on-line translators and you are done :-)

Ashley, you found the issue way too. :) Chris' function looks very 
good.
Here's another way:

 edit: do either any [#do [false]] [%rebgui-edit.r][#include %rebgui-edit.r] 
 ; (false is actually not needed)

(*possible* way, I should say. I haven't tested that, and it needs 
bind in ctx-rebgui 'self.)

I eventually solved it with:

	ctx-rebgui: context [
		...
		edit: #include %rebgui-edit.r
		if issue? edit [edit: do bind load %rebgui-edit.r 'self]
		...
	]

it's two lines as opposed to one, but *much* clearer! ;)

Robert: go with the current .DAT. Don't forget system/locale/colors 
if you feel that is important too (or are folks used to English color 
names?).


Pekr: on-line translators are good for Months / Days, but many computing 
words / phrases don't have a one-for-one literal translation

Ashley, I was trying to reduce the number of variable references, 
eg. in my last (possible) way, there is one instance of EDIT and 
two instances of the filename. In your last way, there are three 
instances of EDIT, and two instances of the filename. Anyway, I agree 
it's easier to understand.

Yep, that was my goal too -- to simulate 'load that it might be easier 
to read when going back to it.

Fixed the problem (disappearing label text after a field scroll) 
that Colin identified. Just needed to change "para: default-para" 
to "para: make default-para []" for editable widgets (as the new 
edit feel changes "para/scroll" values).

Also fixed display/popup to work with latest view betas by adding 
"feel: make object! []" to the popup face prior to display.

on older views you need to define 'within

'within?

what about lists, and clicking anywhere else - it should close opened 
list, but it does not, only escape works ...

list/menu imo has to disappear that way ....

Graham: Next RebGUI build, 0.3.0, requires View 1.2.124 or higher.

Pekr: difficult without a global event system (as shadwolf asked 
about before). If I can achieve the same effect (i.e. close when 
mouse leaves widget) without it then I'll implement it that way instead 
(global event handling is just too expensive for the few cases it 
is required).

Ashley, I just encapped tour to try it out, and noticed the lack 
of a 'within?

but it simply is not correct, but you probably know it. I think that 
once ppl are used to close menu branch, or list by clicking outside 
of it, it can become pretty annoying, as the only chance to leave 
such menu is to select some item, or press escape.

I don't know how Cyphre did it with his menu, maybe he really changed 
pop-up function, even if expensive. Once again - imo ppl can stand 
different look of UI, but not different behavior on certain platform 
- it is a big mistake to think that they can. Other thing is we don't 
have rich-text, so we can't display accelerator keys. Dunno even 
if alt key works ...

Ashley - I am not flaming here, just raising my concern about UI 
usability issues. We should not definitely depreciate it ...

I agree on 'drop-list / 'edit-list usability problem : the list should 
be at least closeable when clicking on the arrow button again - escape 
key isn't enough, as it's a mouse driven GUI.

Graham: RebGUI encap needs:
	#include %gfx-colors.r
	#include %gfx-funcs.r
I've added these to the next build.


Pekr: I've updated the choose func (used by drop-list / edit-list) 
to issue a hide-popup when the mouse leaves it. Feels pretty intuitive 
to me, but I'll see what folks think once the next build is out. 
;)

Vincent: Agree, I'll see about adding that for 0.3.0 as well.

I've also added a simple text-list widget (Robert) and fixed the 
strange table render problem (which you can see be increasing the 
horizontal width of the window *before* going to the "Table" tab 
for the first time).

is the text-list selectable yet?

Yes, even has a scroller. It is a much simpler widget than table 
(being only one column).

are alerts going to be part of rebgui?

display/popup "Alert" [button "OK" [hide-popup]]

does the "OK" have focus for the keyboard?

Not yet. My priority is getting everything working with the mouse 
first before ensuring everything can be driven keyboard only (which 
for complex widgets / actions is nigh impossible anyway - how does 
one resize table columns with the keyboard?).

action select key and cursor key ?

Anyway, my pet peeve is not being able to use the space bar to activate 
an "okay" button on a rebol requester.

How about an ok-button which has "Space" and "Return" keys mapped 
to it (assuming nothing else has focus), and a cancel-button / close-button 
widget which has "ESC" mapped to it (assuming nothing else has focus)?

sounds good

keyboard support is really important. RT will have to be supportive 
here though, and improve keyboard handlers. I don't agree with what 
Holger stated in the past, that they need to allow only keyboard 
events, which are cross-platform. We want key-down, key-up, alt, 
ctrl tab and other events too ...

as for more complex styles - they need to work. I can imagine even 
"focus nesting". Imagine few fields, grid and buttons on screen. 
You e.g. press arrow down to move to next fields, and once you reach 
grid, I would like e.g. by pressing enter, the focus to be treated 
in terms of the grid, so that arrows, page-up, down, etc. work in 
terms of grid only ... ESC would "break" and return focus to "global" 
level, etc.

I have one recomandation to do for the menu widget http://www.rebol.org/library/scripts/menu-system-demo.r

this one is perfect well my port of cyphre menu was good too ;)

ashkey: are you using show-popup and hide-popup? if so, just use 
the /away refinement, and don't provide a custom feel (so that the 
default one is used).

petr: key down and up are not that easy as you might imply. the rest 
is supported already.

ctrl tab is supported? From when?

ctrl is a separate field of the ecent

event

can simultaneous keypresses be identified?

and - why is better keyboard handler a problem?

1) no, that's a hw problem most of the times 2) rebol does not operate 
at such a low level.

ctrl-tab is catched by windows (like alt-tab)

win: layout [Text "Hello"]

win/feel: make win/feel [detect: func [f event] [if event/type = 
'key [print [event/control event/shift event/key]]]]
view win

but we need ctrl-tab - other apps have it - it is necessary for manually 
navigating via tabs :-)

windows does that, not the apps