World: r3wp

(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?

>> 334x252 > 300x300
** Script Error: Expected one of: pair! - not: pair!
** Near: 334x252 > 300x300

Such a comparision doesn't make sense. So > shouldn't work for pair! 
(more specific for two pair!)

So, the error message is a bit confusing.

Is there a way to hide the mouse pointer in view  when its over a 
face ?

No one except playing with Win32 API (good luck)

Maybe a good enhancement request.

mouse pointer handler was previously announced http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlZNLK

view center-face layout [
    space 0x0 across
    
    sample: box 200x200 "ABC"

        font [name: "Arial Black" size: 48 offset: 0x0 align: 'left valign: 
        'top color: black shadow: none]
        para [origin: 0x0 margin: 0x0]
        edge [size: 1x1 effect: none color: black]
        pad -200 

    origin: box 200x200 edge [size: 1x1 effect: none color: black] with 
    [color: none] pad -200 

    margin: box 200x200 edge [size: 1x1 effect: none color: black] with 
    [color: none] 
    return
    
    text 100 "font/offset:" sld_font.offset: slider 104x16 [

        inf_font.offset/text: form sld_font.offset/user-data: to integer! 
        100 * sld_font.offset/data
        sample/font/offset: 1x1 * sld_font.offset/user-data
        show [inf_font.offset sample]
    ] inf_font.offset: info 60 
    return
    
    text 100 "para/origin:" sld_para.origin: slider 104x16 [

        inf_para.origin/text: form sld_para.origin/user-data: to integer! 
        100 * sld_para.origin/data 
        sample/para/origin: 1x1 * sld_para.origin/user-data
        origin/offset: sample/offset + sample/para/origin
        origin/size:   sample/size   - sample/para/origin
        show [inf_para.origin sample origin]
    ] inf_para.origin: info 60 
    return
    
    text 100 "para/margin:" sld_para.margin: slider 104x16 [

        inf_para.margin/text: form sld_para.margin/user-data: to integer! 
        100 * sld_para.margin/data 
        sample/para/margin: 1x1 * sld_para.margin/user-data
        margin/size: sample/size - sample/para/margin
        show [inf_para.margin sample margin]
    ] inf_para.margin: info 60 
    return
    
    text 100 "para/wrap?:"  chk_para.wrap?: check on [
        sample/para/wrap?: chk_para.wrap?/data
        show sample
    ]
    return
    
]

Shouldn't changing FONT/OFFSET have an effect? I must be doing something 
seriously wrong, here ...

I don't think font/offset does anything since I can remember.

Hello y'all. Does anyone know how to correct the following? I have 
a "list" of toggle buttons in four columns. When I select one of 
them, any time I move my mouse, it will continue to select any button 
in the same column that the mouse pointer passes over. The same thing 
happens with text buttons.

show the code

my-list: list 247x300 [
        across space 1x0 origin 0x0
        style cell toggle 60x20 blue mint + 25 center middle [
       
       
        	either found? find selectedtimes face/text [

          remove at selectedtimes index? find selectedtimes face/text head 
          selectedtimes 
        	]
        	[append selectedtimes copy face/text ]
	
        ]
        
        
        c-1: cell cell cell cell
           ] supply [
	        count: count + ml-cnt
	        item: pick data count
	        face/text: either item [pick item index][none]
    	]
    	sld: scroller 16x300 [ 

        if ml-cnt <> (val: to-integer value * subtract length? data visible-rows) 
        [
            ml-cnt: val
            show my-list
        	]
        ]

hmm... now I'm learning again... what does 'supply do? :-)

It's supposed to fill in the face text data as View generates the 
buttons.

faces with state do not work with list. because all the displayed 
faces are the same face internally, and share that state. if you 
change state of one, say toggling, all toggles have that state.

Remember they are all one face, a face which is changing its position 
rapidly.
Now look at the cell face's feel:
	layout [toggle with [?? feel]]

In this code, if you see facets which are modified then those need 
to be stored and restored by the SUPPLY code. (ie. just like the 
list data goes to face/text.)
But wait, let me look for an iterated checkbox example.

if you need such toggles, its easier to make a big layout with a 
real face for each row.