World: r3wp

Yeah, maybe I should repost it here? I put it here, because it was 
a reply to something written here.

repost it *there* :-)

I know :-) It is just that such discussion might turn into advocacy 
rather easily :-)

And as for Max, he is a bit fanboying here :-) I see absolutly no 
reason to not coordinate with Carl, and it was already taken care 
for :-)

Graham, keyboard strokes are lost, when the focal face is not set. 
The culprit is this function in event handling:

key: key-up: context [
	do-event: func [event /local win face] [
		if face: guie/focal-face [
			; bubble up if necessary
			until [
				event: do-style face 'on-key event
				not all [face: parent-face? face event? event]
			]
		]
	]
]


Ideas on how best to solve this? We want keyboard events always to 
be captured and responded to in the correct window regardless of 
focal-face.

I guess I need to capture which window is active, store it in guie/window-face 
and add that to the 'key and 'key-up context to handle the event 
there.

Can't we send the event first to the focal-face, if not handled, 
bubble up (using the traversal functions) until someone handled it? 
The last instance to handle the key-event would be the window.

sometimes we don't have a focal face

than it should bubble up directly.

yes... need to figure out a way to capture which window is active.

On tooltips, we can call them something else, but the functionality 
is important. It's not just about where the mouse is hovering, but 
things like syntax completion, context aware help, etc. touch and 
multitouch apps may use them differently, just as they have evolved 
from simple yellow boxes to rich content.

Hello everyone.... Robert has invited me to be involved in the GUI 
project.


I thought about it for a few weeks, and decided that I would like 
to do so (become involved)... because Robert is not the only one 
asking for this.  There seems to be other interested persons, no? 


(And, just a note, I am not ignoring the other comments posted above, 
but my desire is to stay on topic here.)

Henrik, isn't the active window always known?

G: Yes.

So, doesn't this mean that the active window can process keystrokes 
that are not captured by any focal face ?

Yes.

That's a requirement, otherwise you can't do a lot of important key 
functions.

I believe we are talking about keyboard navigation of the gui so 
that's good

What are the thoughts about alternative input devices such as multi-touch 
and styluses ?

Thoughts, or goals?  I think we need to support them.

Hello Carl ... nice to see you on the surface again :-)

At the expense of breaking the goal of running the same code on all 
platforms?

Hi Pekr. Good to be here.

G: I'm hoping there are mappings for it... to some fair degree.

For example, the primary multitouch I miss in VID on OS X is 2-finger 
scroll, but it can be packaged as a scroll event, so should map. 
 (The issues we face will also be faced by all web browsers, so we're 
in good company.)

Many recent operating systems support multitouch, including Mac OS 
X, Windows 7, Windows Vista, Windows XP Tablet PC Edition and Ubuntu 
(since version 7.10), Google's Android, Palm's webOS and Xandros. 
Application frameworks such as MT4j (Multi-touch for Java) and PyMT, 
a Python module that supports multitouch, have also been developed.

Firefox supports multitouch on windows ...

Right, so to continue my comment from above...  


I went to review the main documents... however, the GUI docs on DocBase 
seem pretty "messed up" to me.  Am I the only one who thinks that?

They are messed up

Anyway, I'm going to take a crack at cleaning that up.  I need good 
docs thesedays, just to keep my head straight.... I rely on docs 
more then ever these days.

No, you are right. There was one user who's name I forgot, something 
like Dr. Bacon, who tried to reorganise docs. Good intention, but 
he mixed VID and VID3.4 docs, and he thrown it also into pieces ....

The parts with actors which I wrote seems intact.

basically Gabriele's and your docs got all mixed up together ...

Kr Bacon. Yes, good intention, but the result was fragmented.

as well as the R2 VID

One question I have that I did not see in reading all the docs .. 
how does one generate a GUI event ( to be used inside network code 
) ... since one can't use a wait to allow the gui to update?

G: Not documented.

Ok, so from here, I'm going to take a "timeout" and sort out the 
docs.  I'm also going to move them to where we have tighter control 
over who and how they get edited.

How long to take to document?  5 mins :)

Graham, active window being known: If Carl says yes, then I just 
need to know that. BUT: I'm presently needing to be sure the method 
would be correct for capturing key events everywhere. Currently it 
just looks like you can only do that for focal-face, which is not 
enough.

I have to tell you... I feel like the way-open-wiki was a bit of 
a failure.

What some of us wonder about is since it is a wiki .. why were all 
these changes not just rolled bacak

Carl - I hope that joining the GUI effort will not distract you much 
from HostKit/Extensions work :-)

WIP wiki is better - only ranked persons can contribute ....

H: yes, to be looked at.

G: code needed too.

Carl, the wiki should be downgraded to simply a repository of documents 
to be collected later for permanent storage in the WIP wiki.

G: he made extensive format and new page changes.

Can we actually generate events?

G: so, a rollback could lose actual contributions from valid authors.