World: r3wp

engage: func [f a e] [
					; A click event has happened.
					if a = 'down [
						; Is it on a valid element?
						if cnt > length? slf/data [exit]
						; If not extended selection, clear other selections:
						if not e/control [f/state: cnt clear picked]
						; Set selection and call the action function:
						alter picked f/text
						do :act slf f/text
					]
					if a = 'up [f/state: none]
					show pane
				]

Can I lock FIELD ? (something like field/edit?: no)

Rebolek - use label instead? uh, hard to change when layout is out 
already .... I have disable/enable functions, but it works only for 
mouse sadly, you can still tab to the field ...

Pekr: that may be enough for me, I'm using just one field, so probably 
no problem with tab.

you will have to unfocus it somehow though ...

ok, will look for the code ...

thanks

sent you an email right now - mine, not sure how actual version, 
but also found Volker's version on rebol org - I would probably better 
trust Volker's code :-)

great, I'll check it, thanks

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?