World: r3wp

worse is that when GUIs scale up, you really don't want to do hacks. 
you want faces to be churned out smoothly, like a  modern car factory.

is stylus input being considered at all?

if not, can the design at least not make it diffucult to be added 
later?

for handwriting?

yes

I wish ...

I love my Tablet PC...

I have a Dell XT2 tablet with multitouch ... so yes, I would want 
that as well

hmm... it seems that the on-key actor requires keyboard focus for 
the specific face before it works. I figure that the tab navigation 
stuff would fit nicely in the window's on-key actor, but the focus 
requirement is a problem. Ideas?

So, what happens to the keyboard strokes??

I really like this line: 

he wants his last 15 years of life to mean something to more than 
himself"
I think of that every day."

Some ideas on focus:

- If REBOL should be feature rich, maybe concentrate on one platform 
reducing the work load.

- Make REBOL less feature rich, but make it work 100% the same on 
all platforms.

- Focus on defining the language, not on implementation. Like Kernighan 
and Ritchie defined C (and later ANSI C), Stroustrup defined C++, 
Meyer defined Eiffel, etc. Why don't we really see more implementation 
of REBOL? Because the language isn't well defined. Would it be ok 
to have it well defined and then see alternative implementations?

... belongs to advocacy :-)

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.