World: r3wp

Maybe the disconnect here is that you are getting distracted by the 
word "installer" and not realizing is that what we are discussing 
is determining the places where stuff is put, both files and settings. 
And that the runtime needs to look for the same stuff in the same 
place where it is put. And that for Linux, it might be put there 
manually, but it still needs to find stuff at runtime.

The "runtime" is an app, no :) ?

some of it is view internals, some of it is for the script, so it 
can comply as well.

The runtime is /View doing something other than installing itself. 
And it needs settings, cross-platform settings that are made available 
inside /View without any script needing to check the registry of 
call GET-ENV, for scripts to know where to put or look for the stuff 
they need to run.

one of the problems of the current R2 is that some of that information 
is either not known at all or cannot be changed even internally by 
view.


so it assumes (pretty badly) to use the current-dir for some things.

so we end up with folders being created everywhere on disk, even 
on your desktop...

Well, I guess you need to refine system/options then.

The biggest problem with /View on Windows is that it puts its runtime 
settings in the wrong place, almost every time. Global stuff in user-specific 
places, user-specific stuff in global places.

I once again assume you mean the viewtop.

They fixed this a little for the files, but the registry settings 
are still all wrong.

No, I mean /View.

and you cannot overide how IT wants to install in cases where you 
know exactly what YOU want it to do.  for rebol it wouldn't be too 
bad, but for scripts which are more than your little 100 line reblet, 
this gets VERY annoying real fast.

What files does /View create?

And what registry settings does it write?

Well, nevermind.

File associations. A setting saying which version is installed. A 
setting saying where the program is installed.

They make a global install, but save the global settings in the user-specific 
locations, and the use-specific stuff in global locations.

What would you call a REBOL binary that comes with GUI capabilities 
on Windows?

It depends. If it has all of View, with the viewtop, I would call 
it /View (or /View/Pro with library support). If it has none of that 
I would call it /Face. If it has all of that plus /Command stuff, 
I would call it /Command/View. There are 3 graphics builds on Windows, 
license depending.

All of them except /Face use the same registry settings, the wrong 
ones.

On Linux, there's two versions of REBOL immediately available: /Core 
and /View. /Core is a REBOL binary w/o GUI capabilities, /View is 
a REBOL binary with GUI capabilities (and beyond that, it comes bundled 
with a self-installer and the Viewtop app).

as a reboler, I don't want to write system specific and environment 
 resolving code.  


my script should be able to ply itself to whatever system its installed 
on and still read/write its files in proper OS expected places.


This is what we are talking about Andreas... viewtop specifically 
has nothing to do with this.  this is for ALL scripts to be compliant.


if I had a command which allowed me to build a system-compliant "application 
data path" then it would write stuff in ~/application/ on linux and 
whatever profile/app data/application   path is being used by your 
flavour of windows.


right now, I'd have to write a library which determines this and 
it probably will screw up on ubuntu, or Mac Or the latest windows.

Nope, /Face uses the wrong registry settings too, just less of them.

things like user names and user folders have to be extracted within 
a routine using proper OS calls, either WinAPi or Env values if that 
is what your OS uses.

though Env values are a security risk since they can easily be highjacked.

maxim, i totally understand this. but it's this kind of cross-plattform 
stuff is a pipe dream in the general case.

I have had to build such tools in the past, so no, it can really 
be done... just look at view itself... it abstracts all of the windowing 
/event etc into a common layer.

And that is stuff the runtime should be doing, so that scripts can 
be cross-platform. Platform-specific stuff has no business being 
in scripts, or the mezzanine code for that matter.

the only sensible solution is to be mostly platform ignorant and 
build a rebol-specific packaging and distribution system. which, 
iirc, you did a few times in R2.

Maxim, see this about passing arguments to apps started by file association:


http://stackoverflow.com/questions/444388/how-can-i-pass-command-line-arguments-via-file-association-in-vista-64


Re. shortcuts having arguments, yes they can - Vista shortcuts could 
as well, though.

Then the runtime would still need to look stuff up from the platform, 
and put the answers in nice, cross-platform REBOL settings in system/options, 
system/user, etc.

That is the runtime's job, to gloss over all of those pesky platform-specific 
differences.

Good luck with that :)

It's the same job performed by the host code in R3.

adrian, when I edited the shortcut on vista, and added the arguments 
it wouldn't save it, telling me the path to the executable didn't 
exist  :-(

Works just fine on 7.

Are you using .lnk format shortcuts?

and yes... you have to manually change the command-line arguments, 
but then the OS' editors break up in what I can't remember, I think 
rebol disapeared from the "installed applications" list, although 
the file association still worked.

I don't have vista installed anymore... but i'd just go on the desktop 
and right-click, create shortcut.

(using XP for as long as I can)

cool if it works on win7

is the read-only file property bug fixed in win7

Depends, which bug?

if you try to change the read-only property of files/folders they 
aren't actually applied, it was listed as a bug on severl IT sits 
on the net.  

basically, many applications suddendly coudn't write to folders anymore. 
 I had problems with rebol in SOME paths.

I even had issues with xcopy!  


looking at the files in a shell, they where all listed as read-only 
and couldn't be set to anything else... (this wasn't within windows 
folders, but on a data disk, before you ask ;-)

Haven't seen that yet. But I almost never use Vista, and rarely XP 
for that matter now, just 7.

I've bumped into the read only bug on Win 7 - pretty annoying.

not sure it was just a cosmetic thing, because in the end I managed 
to do whatever it was that I needed to do

folders are always read only ...

That doesn't affect how you write to the folder itself

maybe that's what I saw