World: r3wp

What was always missing in R2 was the ability for a programmer to 
get system information in easy to use way.

user-name (actuall real login of running task)
user home and related dirs

things like that which should be in the next release, especially 
if you are going to rummage through all of this.


I used routines to get to some of this, but I think it would be nice 
if this was built-in.

Andreas, corresponding concepts:
- The place where the program is installed/located.

- The place where the installed program version is listed, so you 
can know whether an update is needed.

- The place where user files, particularly the view-root and desktop 
files, needs to go.

- The place where machine-specific user settings should go (console 
layout on Windows).

- File associations, where possible. Not assuming that these are 
possible on platforms other than Windows.


Where these go depends on the installation profile. Yes, not installing 
at all is one of those profiles.

Ah, so the scripts you were talking about are installer scripts.

No, I mean scripts at runtime. Installer scripts are platform-specific, 
but once things are installed, the scripts at runtime should be platform-agnostic.

That's nothing to do with an installer then, has it?

Adrian, "so it executes"  I meant installing rebol in the OS via 
file extensions so it always uses the -qs arguments over and above 
those it gets from the explorer.


also can shortcuts have arguments in win7?  this was removed in vista.

So every one of these concepts needs a runtime setting that tells 
user scripts where stuff goes.

What was always missing in R2 was the ability for a programmer to 
get system information in easy to use way....I used routines to get 
to some of this, but I think it would be nice if this was built-in.


So every one of these concepts needs a runtime setting that tells 
user scripts where stuff goes.

Agree++

Andreas, the installer determines these things at install time, and 
sets things up for the runtime. but the runtime has to look for stuff 
where the installer puts it, and previously R2's runtime looked in 
the wrong places.

Installing REBOL/View on Linux consists of putting a binary in the 
right place

For that, only one of the things you listed is needed: information 
about where to put the binary.

and its a different place in many linuxes now.  :-(

And then where are the user files, such as the view desktop placed? 
And how does the runtime determine that?

That's the runtime's problem

Most likely even an app-specific installation problem

That is part of the installer project.

another thing which is missing is explicit font path.   The Os might 
not know, but at least if we could configure it manually then we 
could script independently of linux install.

View is the app that we are specificly discussing now.

viewtop is the app you are discussing

nope its /view.

If i right a view app... where do I put my config files?

that's a third party app, maxim

this sort of thing right now is pretty hard to determine.

/view: a binary, viewtop: an app that needs additional settings

/View has Viewtop built in, so it's a built-in app.

yes, but it's still only a view app

I really don't see what viewtop has to do with it.

right now, when we write REBOL apps, we are running blind.  its very 
complicated, and something most script coders will not put the time 
to learn.

rebol/view binary does not need to know about a location where to 
place viewtop files

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.