World: r3wp

--->> Chat group.

view-root is the base-dir for /view-related files. originally that 
was where the exe is, due to multi-user it is now somewhere in the 
users home. important things there: %public/ for the cache, %user.r 
(not sure if it is the only place where it looks for it), %desktop/ 
for desktop-icons etc, %local/ for local index.r . basically if i 
want to install something view-related, i use view-root at base.

What do you mean by " IOS clients "? it does not allow multiple exes, 
but it uses a subfolder for each server. so you can have multiple 
ios-acounts.

but you develop view apps in view-root too? because once you want 
to move something to some other user on othe machine, you can easily 
forget about some stuff which is in your cache already but other 
user may not have it available and it may not become obvious to you 
imediatelly the app will crash because of missing of some script 
:-)

for usb i once provided a solution. an encap which changed the registry-entry 
to point somewhere else, eg the place it was called from. if you 
call that from usb, usb is the link-root for new starts.

about registry making sense - some people may put it somewhere and 
forget about it, and then, where are the files. with registry, they 
launch ios, it knows.

Volker - new server you have to put into different dir, as you can't 
extend your selection list with new server entry. dunno right now, 
license.key related or something like that ....

about power-users see hack. :)

No, run server-provided exe one time. then you have the right entries 
in %accounts.r / %servers.r and can copypaste.

you need to run that exe as it has some special key, which it then 
stores in %accounts.r

once key is there, every ios-exe can connect.

(I dont defend that way, just explain)

You may (or may not) be interested with VIDpatch. VIDpatch adds bubble-help 
and drag'n'drop support to classic VID. Now you can write >> button 
"Save" bubble-help "Saves file"

do http://krutek.info/rebol/VIDpatch.r

kru fun work  ^^

Hm, this version has some bugs, I have newer one somewhere.

i worked on tooltips those last days i posted to rebol.org my script

well i think those codes are good for research of the best and cheaper 
solution but it  would  be better to add them one day to rebGUI  
to get a centralized way for user to get all optimised kind of widgets 
and not to have to endless browse internet to search the needed script 
in the better version

shadwolf: I have no experience with RebGUI but I think it can make 
use of VIDPatch. It's just a model how to expand VID. This can be 
implemented into RebGUI natively.

Kru: nice!

After looking quickly at the code, I see you patch each face feel, 
and text editing function...

Does using insert-event-feel is not enough to handle the tooltips 
stuff (Also I know that it's hard to know witch is the face that 
is the final destination of the event) ?


Also, there is a 'help facet in VID-face and VID styles that is use 
nowhere. I though it could be used for handling tooltips strings. 
Then just have something in the global event handling that check 
the 'help of the face under the mouse and flash tooltips if any.

DiceC: Hm I have to try it. Most of patching is due to drag'n'drop 
I think. Haven't seen the code in a while...

I know that it's hard to know witch is the face that is the final 
destination of the event

 ... RAMBO Ticket #3867 is the answer to this, and hopefully it'll 
 make it into 1.3.3. ;)

Mmm.. I don't know if it would be so soon. That change would break 
a lot of code.

Shock, horror ... you mean scripts *rely* on a bug?! ;) Better to 
fix it sooner than later then.

Oh sorry, on review of the report, I think it's not so hard to implement 
it. But I seem to remember some other complex aspect...

I prefer to fix code writen to patch a Rebol error, than to let the 
bug in Rebol like this.

Don't know where to post it:


could someone please add this fix to the word-browser in the ViewTop 
?

pick-next: has [f] [
	f: all [f-funcs/picked f-funcs/picked/1]
	either none? f [
		if empty? f-funcs/data [return]
		f-funcs/picked: reduce [first f: head f-funcs/data]
	][
		f: find f-funcs/data f
		if tail? next f [exit]
		f-funcs/picked: reduce [first f: next f]
	]

	if f [	
		sync-funcs-list index? f
		show-word first f-funcs/picked
		show f-funcs
	]
]

pick-back: has [f] [
	f: all [f-funcs/picked f-funcs/picked/1]
	either none? f [
		if empty? f-funcs/data [return]		
		f-funcs/picked: reduce [first f: head f-funcs/data]
	][
		f: find f-funcs/data f
		f-funcs/picked: reduce [first f: back f]
	]
	if f [
		sync-funcs-list index? f
		show-word first f-funcs/picked
		show f-funcs
	]
]


This fixes the annoying bug, if one presses the up or down buttons 
when not in the function-list, causes the application to crash.

Thanks Michael. I'll submit it.

There's actually an old patch in there already, it just hasn't made 
it into a release yet. Thanks.

would reports on these tools fit in RAMBO?

Could go either way. RAMBO is the place for bugs. Carl says things 
have the best chance of being seen there. Could get more polluted 
if we report everything for all apps there though.

there's a filter isn't there for sorting out code from application 
problems?

I don't understand "code from application problems".

maybe it's rebol vs. application problems

Yes, that's it.

I don't know of a filter just for that. You could probably use the 
"Other" category for those kinds of entries, to break them out a 
bit.

in windows...  just cause its making me mad... how does REBOL/view 
1.3.2 go about sourcing the damned user.r and rebol.r files... cause 
right now, I once again have some icons which source them and some 
which don't.    :-(


basically if you double click an *.r file it does not work, but if 
you launch rebol.exe or a shortcut to it... it works.

ARRGH ! and I though  v1.3 was about keeping install simple   :-(


I have set both HKEY registry entries to the same dir... but why 
are there different reactions depending on the way you launch rebol?

Have you edited the filetype association ?

try doing a clean install. note that uninstalling may leave some 
registry keys (in particular, it will leave them if they have been 
customized).

after about an hour of fidling around...  I realised that the user.r 
is now ALWAYS sourced from the actual windows's user dir.  This is 
a good step forwards.

the issue is that the window's user "home" path is just freakish 
and very innaccessible from a dumb user's point ot vue...

can we CHANGE this path?  even if this means setting an environment 
variable...

heck even I hate looking for this :  

C:\Documents and Settings\user.machine\Application Data\rebol

its got spaces and all...   :-(

But it is the right place to put it.

not for me... my prefered home directory for tools is much simpler 
and works across linux much nicer...

at least the user.r does work consistently across different launch 
patterns now...

run desktop, open local/info.txt, open ../user.r :)

I'm not addressing "you" and M$ does not care about Linux.  But what 
they did do was make a system that allows multiple people to use 
the same computer and keep their date apart.  It is wrong, and badly 
done, but the "correct" way to do it for thier system.



As to Carl allowing other ways to do it, that is the real question 
I assume you are asking.

yep.

as I said, at least it works now, when it used to be pretty random...