World: r3wp

I'm probably going to write a game basedon it

Here is fun script from Bo (with help of Anton) - plese add it to 
Desktop demo folder :-) http://www.rebol.org/library/scripts-download/swintro.r

does text-list supports multi-column?

Allen had mentioned using rate to handle forever loops in action 
blocks but my problem is that i have a while loop that executes a 
lengthy amount of functions before it even loops again.  I almost 
believe I need a multi-threading way of doing this.   I thought about 
it for awhile and think an enhancement would be nice where you can 
for example use launch function for executing additional threads 
but have a memory space for passing data between the threads.  Any 
of the REBOL gurus involved with RT know if something like this is 
capable?

dunno, probably not a bug, but at least a cache headache - imagine 
following scenario. Today I did small script for my friend. I created 
C:\app-name-here directory and put it inside, along with rebol/view. 
I then decided to install View, to get .r association, so that my 
small scripts could be put directly onto Window desktop (I don't 
need yet another desktop - View one, If I can't parametrise it further 
- buttons, removal of rebol.com etc.). So, after installation, I 
filled in network info, saved, and exited view. Then I could see, 
dirs like 'public, 'local 'desktop were created.  So I deleted them, 
to remove additional clutter they caused in my directory. To my surprise, 
View ignores the fact it is already installed, I choosed to not use 
desktop, yet I was brought to desktop once again.

I can understand that I should not probably put cache location into 
my preferred app directory directly, but I wanted to have it self-contained 
- not Rebol scattered around my hd. Sadly, settings for desktop are 
in Desktop directory, so once I delete it, rebol starts to desktop 
once again. Imo we need desktop?: no setting in user.r

After all - wasn't there any such setting in the past?

desktop: false was in prefs.r in View 1.2.1 (I have 5 versions of 
Rebol saved for some reason...)

desktop: none in user.r could work. would replace 'desktop-func with 
a nop. not tried.

;umm am I using Toggle wrong or is there a glitch in it?  This is 
View 1.3.1..


view layout [Tog1: toggle {First} Tog2: toggle {Second} btn {Pop} 
[Tog1/Data: Tog2/Data: false show [Tog1 Tog2]]]

oops I started looking for more and toggle and forgot to say the 
problem  XD


Pop is just supposed to.. well.. pop the buttons up, but it won't...

use face/state, not face/data (all styles should use /data... but 
they don't...)

Thank you  =^)

Hi Gabriele, Is there a possibility of putting aliases put in place 
so View has that consistency across all the styles?  I think we also 
have /value and for a text face /text when I think it could always 
be /data

set-face and get-face are the answer to this problem. accessors still 
need to be written for some styles though.

A puzzle this brings up; where is the 'value referred to by this 
function
>> layout [text-list with [print mold :update]]
func [/local item value][
    sld/redrag lc / max 1 length? data
    if item: find data picked/1 [
        sld/data: min 1 (index? item) / (max 1 lc)
        sn: max 0 to-integer sld/data * ((1 + length? data) - lc)
    ] [
        sld/value: 0.0    ; <----------- ?
        pane/offset: 0x0
    ]
    self
]
>> layout [scroller with [?? value]]
** Script Error: value has no value
** Where: ??
** Near: mold name: get name

that's face/sld/value, not face/value

yes, I know.

ah, also, you're comparing text-list and scroller. mmm.

sld is a scroller

but if you do:
>> find mold svv/vid-styles/scroller "value:"
== none

that's most likely a bug. should be sld/data

i think /value is the remains of a very old scroller style :)

Yes, If you examine
 write clipboard:// mold svv/vid-styles/text-list

then you cannot see any reference to "value:"  (ie. the text-list's 
scroller is not extended with the 'value facet either).

I agree. So maybe the text-list/update function is not used much 
any more ?

submit to rambo (if not already there)

well, /update should be used by users. maybe noone found the bug 
so far.

OK.

I'm too tired right now to do a more full analysis unfortunately.. 
but I'll submit at least.

yes, just a reminder about this problem. replacing that with data 
will fix it.

layout [t: text-list]
t/update   ; <--- what is strange is this doesn't cause any error
t/sld/value
;** Script Error: Invalid path value: value
;** Near: t/sld/value

anyway...

hehe, it's not strange. but, i had to look at it very closely to 
see why :)

oh.. :-/ ok.. c'mon brain...

and, this explains why noone noticed it so far.

(submitted ticket)

there's an if instead of an 'either too.

so looks like someone changed that code while being a bit distracted 
:)

oh my god ! I just fixed a bug of mine like that earlier today. :) 
It survived a couple of days before I noticed it.

you might want to update the ticket with that bug fix too..

actually i changed my local version of teh code already, so i'm sure 
not to forget about this. that pane/offset: 0x0 seems pointless too, 
but i'll need to investigate.

if you look closer at the code, you also note that there is an 'if 
instead of an 'either, so its death code. IIRC update was somewhat 
broken, maybe not cleanly fixed?

View 1.3 bug!?:

>> img: to-image layout [slider with [data: 0.5]]
>> view layout [image img]


I see a black square at the top of the slider. Can others confirm 
this?

Confirmed. I think something similar (a problem rendering without 
diplsaying) came up recently.

I've made a quick list of the VID-styles found in REBOL/View 1.3. 
Some are explained with a definition, some by an image showing the 
style in use. The list can be found here:
http://home.tiscali.dk/john.niclasen/

Geomol, I think the problem is because the dragger is only correctly 
positioned in feel/redraw. See the feel:
	layout [slider with [?? feel]]

This means that the dragger is only set in the correct position when 
there is a redraw event, and the face must be viewed in order to 
receive events. The initial position ( layout [slider with [?? init]] 
) does not take into account that DATA may be non-zero.

This could be fixed by modifying INIT, I am pretty sure.

Indeed:

view layout [image to-image layout [slider with [append init [feel/redraw 
self 'draw none] data: 0.5]]]

OK, submitted this bug and fix to RAMBO.