World: r3wp

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.

P: multitasking necessary.

P: and I'm not talking about code. ;)

:-)

C: even MS removed multitasking from today's announced WinMobile 
7 .... where the world is going? :-)

I thought wikipedia supports page roll back ... but if that wasn't 
the case .. it's a lesson

H: I agree. I'm going to allow only a few uses like Henrik, etc. 
to edit at full control level.  Other uses can submit notes as comments.

I think that's better ... let users add comments and later on the 
person responsible can fold them back in

G: The problem is that the content was cut and pasted all over the 
place.  It's quite a nightmare as I look it over.

It's different when there is a large body of knowledgeable users 
..., we don't have that yet.

Guys, can we concentrate on the GUI? I think we really need to get 
something done. By that I mean finished to a 1.0 release.

P: As people used to tell me in 1985, "who needs this useless multitasking 
stuff?"

There are tons of questions and things to do around R3 but let's 
not fragment our time. Let us concentrate on it and get it done, 
than move on. All necessary side-effects that need to be fixed are 
in scope. All other things IMO not.

Robert, what needs to be done to the GUI from Carl's side?

Carl should imo write down notes about how he envisioned GUI 3.4 
to work, especially non finished things like events (still from Gab's 
VID), layers, guides, resizing, etc.

Carl, you posted a specs document to me some time ago regarding guides, 
layers and better layout capabilities. I lost it. :-) Can you post 
it again?

G: Before I can do anything, I need to be sure that we've got the 
basic design well stated in a document.  We can always add from there.

I'd like to integrate those specs with the wiki specs document.

H: I'll take a look around. Probably in R3-GUI world, no?

I posted Carl a list of main topics. IMO the goal is to sort our 
what Carl really can do only by himself. All the rest can be done 
by a group of people. The main effort will be to get the design right. 
If this is done, the rest is "only"  implementation

Carl, I can take a look again.

Yes, I think we have a good critical mass of skillful developers.

We need a good enough solution, that is open enough that we can drive 
it forward. At the end of the day, the GUI must fit the developer 
needs. I'm not seeking for perfection (Ok, I do) but for time-to-market 
(because I learned/know that it's more critical these days).

Real artists ship
 :-)

Well, Robert, I'm glad that you are pushing it !

Q: why does Control-C in an area halt R3 ?

Is that a GUI or a core issue?

A: Bug.

Event issue, so core.

Carl, looked twice now and only found a small document regarding 
tags (which are implemented now).

Ok, 1 min... searching....

seems you can't use reflection functions on events either.

but I found the window in focus to be inside event/window

so no issue now on dealing with untrapped keys?

well, the issue is whether the method is correct. now, when no focal 
face is there, the window on-key actor is used.

but, there is no limitation in the event system. the problem is just 
to shape the mezzanines correctly.