World: r3wp

for scripting purposes, having a script that works on all supported 
platforms is a reasonable aim.
I just don't see that it works for GUI based applications

If a particular linux distro doesn't support multitouch, what relevance 
is it to me working with Windows?

if a distribution of linux doesn't support multi touch you still 
have the oportunity to port the needed modules  to make it feet your 
distro that's less problematic than windows for example

linux is the most configurable and modular OS existing ...

Say you want to write a multiplatform gui app, well, then you make 
sure that what you do is supported.

and that flexibility is a part of a problem for setting up a small 
all in 1 VM like rebol ...

If you're not interested, you shouldn't be hindered by a philosophical 
view ( pun ) that everything should be the same.

graham yeah but in fact most of the time when you write a software 
you make it first to feel your need or the need of your client ... 
then you don't think out of the box if that guy will be able to run 
your script on his I-phone with the same posibilities that you initially 
planned

graham it's less evident than that ... things that are supposed to 
works on the 3 main OSes only works properly under Windows XP ... 
(i think area-tc shown that the portabilities in draw area is far 
from perferct in R2 )

and once again i'm not saying that's not to be done ... i'm saying 
if we take in charge unic specs according to a given documentaton 
then you have to provide a clear information mecanism explaining 
to the user why the technologies involved in the script he wants 
to use is not supported on the plateform he is under if that's the 
case

no multitouch wit threading  ( you can't have several sources of 
 event and treat them at the same time without threading system)

The OS detects the multitouch event and sends it View

I don't see why we need multithreading for that

cause you need to clip the actions to the event you receive

next issue is storing the tab face in the window face... this is 
necessary to store a tab navigation frame per window. I wonder how 
this is going to be done...

I thought that the whole point of Carl's GUI was to allow app developers 
ignore all of the little details about how the app looks and acts 
at runtime and just focus on the semantics. Let the stylist worry 
about the appearance, and let the infrastructre people worry about 
whether the input came from multitouch, mouse and keyboard, whatever. 
Separation of form and function.

people are so used to R2 VID, that it's hard to get out of that thought 
process that the GUI must be completely hackable. :-)

And I think it should be, by the GUI hackers. But those hacks should 
be able to be used by others who don't want to have to worry about 
that stuff (like me).

The challenge is to provide a GUI that you don't need to hack to 
make it do what you want. We can go much further with that in R3 
than we ever would be able to with R2.

The challenge is to make a GUI that ordinary users can hack :)

I'm more with Henrik here.

No, the challenge is to make a GUI that ordinary users won't have 
to hack. Ordinary users are terrible at making GUIs, and their attemps 
to hack them look terrible.

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.