World: r3wp

Andreas, you are not getting that /View is not installed until viewtop 
can run properly. And that needs user directories, and font paths.

well, that's open for discussion

hell even most C coders don't know where the files really go since 
that's all abstracted by the IDE APIs they use.

That is what installing /View means.

if i were to package /view for linux, it would certainly be two packages

view and viewtop

Andreas, even without viewtop, none of this would change.

Actually, that is not currently open for discussion, we already had 
that discussion. The no-install profile is the result of that discussion.

maxim, i totally understand your problem

as a /view programer, I cannot easily know where fonts are installed 
from within my script.

brianh: what you call "profile" i call "package"

the installer would just setup the values it can find, or leave some 
of these values as run-time functions (some which would rummage registry 
keys, or call routines)

All packages will need to be supported by the same executable then, 
in one package.

Hu?

its ironic because as much as REBOL istelf is abstracted internally 
(opening windows, loading fonts, events, etc), none of the abstraction 
is availble to the scripts so they can also abstract properly at 
their level.

Viewtop is built in to the executable. All we are placing is data 
files.

Using Debian packaging as an example: you'd just have a rebol-view.deb 
which installs the binary. And another rebol-viewtop.deb which installs 
a script to launch to viewtop and depends on rebol-view being installed.

Maybe the disconnect we have here is that "installers" in a Windows 
sense are absolutely atypical on Linux

If you want to build without viewtop, use the SDK. But you aren't 
building R2/View, you're building /Face. The no-install profile is 
just the /View executable not running viewtop.

We don't build anything, we're discussion how to sanely install /View 
on Linux.

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.