World: r3wp

Thanks for the help.  I was still having trouble because I was taking 
the default  button color in the the init layout then trying to change 
it based on some click action. If you default the button color, you 
can not change it.

Here is my test-script, comments below

view/new layout [across
	toggle "Test" gold "Test Reset" red [
		probe value
	]
	button "Test" [
		face/text: "Text Reset"
		face/colors: reduce [white red]
		show face
	] feel [
		redraw: func [face act pos /local state] [
			if all [face/texts face/texts/2] [
				face/text: either face/state [face/texts/2] [face/texts/1]
			]
			either face/images [
				face/image: either face/state [face/images/2] [face/images/1]
				if all [face/colors face/effect find face/effect 'colorize] [

     change next find face/effect 'colorize pick face/colors not face/state
				]
			] [

    if face/edge [face/edge/effect: pick [ibevel bevel] face/state]
				state: either not face/state [face/blinker] [true]
				if probe face/colors [face/color: pick face/colors not state]

    if probe face/effects [face/effect: pick face/effects not state]
			]
		]
	]
]

one is, maybe you want a toggle instead of a button?

that 'redraw is copypasted from original source (probe get in get-style 
'button 'feel).

then instrumented with a few probes. so i can track what really happens 
on  redraw.

seems it has to do with the effect. if i clear effect (face/effects: 
face/effect: none) i get pure colors. but with effects on it mysteriously 
does not work. dont understand that yet.

because i am not a graphics person ;) with default colors an effect 
looks like this: [gradient 0x1 66.120.192 44.80.132] and without 
[gradient 0x-1 32.32.255 173] . in first case last value is a color, 
in second an integer. seems the integer filters face/color, while 
the color-tuple overrides it.

Thanks Volker et al.   I am using VID for a quiz for my kid's grade 
school studies - mostly history and science questions.  In this humble 
attempt, the button label is the answer to a multiple choice question. 
When an answer button is clicked it changes from a default color 
to green if it is a correct answer or red if it is a wrong answer. 
 This might offend UI experts but the button color change (when it 
works) gives immediate feedback.  Repeating the drill seems to bring 
the number of wrong clicks down until they get toward zero and grades 
seem to go up accordingly.

good idea :)

just as a side-effect i have discovered that buttons can blink. just 
set face/rate and show the face.

maybe thats feedback too? none stops, integer is "frames"/sec, a 
time the delay.

my friend who codes in View after some time would like to ask, what 
changed in "focus" system since 1.2.1 - were there any changes since 
then?

if you want to dig into making own behavior, you can start with this:

view/new layout [across
	button with [
		source init
		source feel
		init: [copy needed stuff from init]
		feel: [copy and edit functions from feel]
	]
]

He created his own grid and he would like to have more than one grid 
on-screen and would like to switch between them by tab. Can I make 
my own style being of 'tab-stop type? And how to let arrows etc. 
to works in terms of focused grid, not whole screen?

Volker - good point - I looked into new Doc and it does seem to be 
the most complete and nice doc ever! Maybe small section of how to 
start add own styles would fit it well?

well, although we are talking VID here, not View ... so maybe it 
should exist in terms of VID separate doc ...

and strip out all this "if color", since you know you if you have 
color or effect. May simplify code and give you better control. OTOH 
better come here and ask for special effects, if you need results 
instead of studying arcane view-magic :)

(sorry pekr, all this text was in my fingers pipeline ;)

doc - i think the combination of view/vid would be a good start. 

one thing to know is the facets. when you know them, all this magic 
in button-code suddenly looks lots simpler. all this ifs read like 
"turn on/off" in oops-doc then.

the other is how to get arguments from vid (that face/colors etc 
where they hide, and how to make face-specific words). when you can 
make a color-changing face and pass the colors thru vid that should 
give a cool feeling for the beginning :)

multi-grid - i have done that, but in a "hardwired" way. all the 
lists are in a global block, and tab knows about that.

then using hotkeys in the parent-face of the lists IIRC. Maybe you 
friend and me can start a thread somewhere to work on that? discussing 
ideas, me answering technical questions?

Thanks again... my plan on the VID quiz was to post it on the script 
library when I get it working in 1.3.  

Then if it is worthwhile some new special effects can be added like 
blinking or sound or some graphing of results and journalling of 
scores.   


The hard part is still looking at the subject material and extracting 
questions that lead to some understanding of the material.
     

But once that is done, a student can review  dozens or hundreds of 
questions repeatedly in a different order each time.  


And a new quiz can be added just using a text file in rebol block 
format.  

And of course, the VID script and the data files could be internet 
read instead of being local.

Cool :) And then we make a rebol-quiz? :)

Volker: I suggested my friend to use rebol community resources, so 
he promissed me to get GPRS card (as he is travelling) and join altme 
or ml later ...

re changing "non default" facets, we held that discussion some time 
ago. I am still used to old fashioned oop method of having accessors/handlers 
for lots of things ... not just set-face, get-face ... ;-)

I was used to change "private" to "public" in such frameworks first, 
to be allowed to change something. ok, that was years ago. Know i 
see cmplex things like swing, which allows to change anything, if 
you understand all the concepts. The docu is a few times bigger than 
the whole vid-source. But then, i am using rebol a few years now 
and swing or whatever a little. Though, such guis look so similar 
that i doubt they are really customisable ;)

I would prefer them being used as not only abstraction for setting-getting 
data, but also for other possible arguments! We admitted there was 
mess with obtaining data from style in unified way, and I say there 
is mess with other possible things, as colors etc. User should not 
be pushed to know, there is gradient effect, whatever, involved .... 
I would prefer set-face, get-face being extended for something like 
set-fac/extended 'back-color red .... nothing would happen, if such 
"handler, method", would not be exposed by style author ... or something 
like that :-)

In a way i agree. but my prefered way is a dialect, and there is 
one: vid. It would be muach easier if one could say
  set-face button-f[ blue green "you got it" ]
instead of

  bf/set-fore-color blue  bf/set-back-color green  bf/set-text "you 
  got it"

but re-layouting was rejected by Carl in the first 1.3-attempt, so..

I don't like those vid exposed functions :-) they are reverse means 
of encapsulation ;-)

I  mean functions like font-color etc. in VID  :.)

in your example it would be bf/set-face 'backcolor blue

limiting set-face, get-face, to simply only setting data arguments, 
was imo big mistake, as setting other arguments in unified way is 
imo also important ...

Or that. more to type, more code to read, and to learn two apis: 
vid for creation, whatever for changing later.

the data-thing is ok for me. I think its more like you often argue: 
there is a programmer and a designer. the designer chooses colors 
etc. In styles. the programmer provides values. and the interaction 
is done through set-face/get-face

of course the programmer has to make the styles too, together with 
the designer. but that is a different "role".

what two apis? set-style/get-style is cool api, I just say it should 
be extended. If designer asks me to expose change of backcolor, I 
will do internally to my style whatever is needed, and expose it 
via set-style 'back-color value. Facets are different thing - they 
are dialect related, you can (or don't need to) expose 'back-color 
as a facet to allow its usage directly via VID code ...

one api is vid. You knw i can face/text there, foreground, background 
etc already.

if i want to change that later, why leaning a different way to do 
it?

no, you imo can't, in unified way, can you? face/color, face/colors, 
different usage schemas with different styles ...

Yes. You can pass a vid-block to an existing face and update the 
face. the face then knows what to do with a string, a clolor etc. 
not yet, but would be doable.

ah, "not yet" is good point ... such things should be though about 
- newcomers could be confused that simple thing as   view layout 
[button "change color" [face/color: green show face]] does not work 
...

VID works like "customize at creation-time". thats enough for simple 
things. other guis even do not allow" more. If you could change the 
color of a button, they say about "user-guidelines" and "l&f", and 
that a red button is absolutely not discusable.

simple vid-styles are basically a wrapper around view-faces. they 
add a simple behaviour (pressed-flag and action/colors based on that) 
an some smartness about vid-args. if you want customisation, its 
nearly as easy to write an own style. surely docu, examples, vid-source 
with comments public would help.

most important are examples IMHO, where you can play with, add probing 
content and flow etc.

barebones of a button, one with behavior and simple look (two colors), 
another shows smart vid-arguments (all this "if color if effect" 
etc).

OK, then it really is question of documentation mainly, but still 
- if we can find good ways to make things more consistent, we should 
not hesitate to discuss them ...

Right. And it helps. If you say "i like the pure OO way because of 
..", i start saying "Noo, our way is better because of - because 
of - " and then i have to dig out something. Only that i always forget 
to make notes..

This is OK?