World: r3wp

hehe, I told you - Volker's one even disables field content for keyboard 
:-)

great, I've checked Volker's code and it's exactly what I wanted, 
thanks!

great ...

have I told you I miss such things in View by default? :-)

Probably yes, but the list of things you're missing is long, as we 
all know ;o)))

I am not sure, just .... ah, let me think .... well, it is long, 
you are right :-)

But I agree this should be part of View, specially if the code takes 
only 20 lines

hmm, but maybe we should have higher concept - kind of methods? Well, 
not once again (I was thinking about accessors and their non-fully 
developed potential) ... the most difficult part for new View will 
be - consistent look ... and the look should count in things like 
disable/enable, display the widget has focus ...

having SET-FACE being implemented consistently across all faces would 
be a big step forward.

I voted for set-face 'attribute value - much more flexible than plain 
set-face value ....

you could rewrite other methods too

rewrite in the sense of rewriting engine = override :-)

view layout [f: field tog "enabled" "disabled" [either value [feel: 
f/feel f/feel: none][f/feel: feel]]]

Better...

view layout [f: field feel [] tog "enabled" "disabled" [f/feel/detect: 
all [value func [face event][none]]]]

should request-date/date 25-Jun-2006 bring me to that day? It does 
so for the first time only, consecutive invocation fails ... submitting 
to rambo ..

ah, it is there already ....

one question - is there already a group formed for new View? I would 
like to know, where should (could) we post our requirements. I would 
not like to see some fundamental UI design mistakes repeated, so 
I want to be sure, I voiced my ideas ....

pekr, matters are being taken care of :-)

well, it is not enough. I know that Carl wants to have focused group 
for that, but there should be place, where other could place their 
requirements

or .... such group should produce UI guidelines for others to see 
... that would be even better, so the rest of us - ready-to-test-hungry-rebol3-ers, 
could be sure, everything is under control :-))

well, currently it's not that far yet, but maybe it would be nice 
with an open brainstorming group which we could study and grab the 
good parts from.

hmm, many ideas is lost with lots of surrounding chat ... maybe docs 
plus chat ....

I want to be sure, new VID (Whatever it is called) will be fully 
keyboard ready, that widgets can be disabled/enabled, focused/unfocused 
and that all this is visually reflected ...

... so proper tabbing system is my high concern ....

everything you mention is part of the requirements

ok, I don't need to know more then :-)

.... maybe, if rich-text is part of the game, then underlined letters 
hor hot-keys :-)

at least from what I can see here, it addresses almost all aspects 
of what is currently missing from VID. whether all this will be implemented 
immediately or over a longer period I don't know.

better get back to work on it ;-)

I hope system is implemented from scratch upon new View kernel ....

take localisation into account (e.g. calendar does not use system/locale), 
and if you will implement set get for styles, it would be good to 
have it kind of rewrite methods .... set-face 'parameter value, not 
just set-face 'value - unnecessary limited :-)

well, I should stop talking .... the best of us are on the project, 
so .... otoh really, while it is closed project, it would be nice 
for others to see the proposal, to be sure, that it fits the idea 
of most ppl ...

yeah, well I'm not sure how much I can say about it. it would be 
inappropriate to say something that may not turn out to get implemented 
anyway :-) I'm pretty sure it'll kick ass though.

I am not sure it satisfies my hungry eyes :-) Well, maybe I could 
find Gnome UI guidelines? Or something like that?

I have to go, sorry :-)

http://developer.gnome.org/projects/gup/references.html

http://developer.gnome.org/projects/gup/hig/

those guys put really lots of work into it ....

For all you guys maintaining tutorials etc. Here is a couple of polished 
demos, a simpler one and a more advanced one, a couple of snapshots 
on the way to implementing your own list with drag-n-drop:

do http://home.wilddsl.net.au/anton/rebol/gui/iterated/iterated-face-drag.r

do http://home.wilddsl.net.au/anton/rebol/gui/iterated/iterated-face-drag-drop.r

huh, ha, looks nice :-) Is that your engine you worked on earlier, 
which would let you do your own grid?

no, simple demo.

Ah gosh! I just noticed that the official Rebsite index has changed 
from 
http://www.reboltech.com/index.r
to
http://www.rebol.net/reb/index.r


Anyone know when this happened or why it was changed ? (I seem to 
remember a server change a while back)

Anyone know who is currently maintaining the index ?

the quickest way imo is to contact Carl via feedback or Gabriele 
here to ask Carl ....

I think I will do that.

Is it actualy possible in view/pro to create a thread or a process 
when using the 'call command? Somehow its fully blocking under rebol 
using this... If anyone has a hint on how to detach a 'call process 
from rebol ;-) let me know...  Im seeking interaction from the an 
/output which should be put in an GUI window of /View...

try using Dockimbel's asyn call

/output implies /wait. you need to use CALL without refinements if 
you want it to be async, or use the ASYNC-CALL function in the Detective 
(which is based on Nenad's on Windows, and uses my implementation 
on Linux/Unix).

is KEY color for an image supposed to overwrite the key color in 
the image with transparency permanently? I need to load the image 
again to restore it to its original state.