Hyperion Entertainment Message Boards

I don't mean to side-track this debate, but it might help decide on a solution:

With the issue of how ENVARC: is or isn't copied to RAM:ENV, where is the preferred place to save your program's preferences file? I have always used ENVARC:, but maybe PROGDIR: should be the place. If PROGDIR: is the place to save, then ENV: would be the temp location for Use.

mritter0 wrote:I don't mean to side-track this debate, but it might help decide on a solution:

With the issue of how ENVARC: is or isn't copied to RAM:ENV, where is the preferred place to save your program's preferences file? I have always used ENVARC:, but maybe PROGDIR: should be the place. If PROGDIR: is the place to save, then ENV: would be the temp location for Use.

The Style Guide says PROGDIR: should be preferred, then ENV/ENVARC if that isn't writable.

The advantage of using ENV/ENVARC for program settings is any future multi-user ability will most likely work automatically. Sticking the prefs in PROGDIR: scuppers the expected way that a multi-user AmigaOS might work in the future.

chris wrote:The advantage of using ENV/ENVARC for program settings is any future multi-user ability will most likely work automatically. Sticking the prefs in PROGDIR: scuppers the expected way that a multi-user AmigaOS might work in the future.

The key words in your statement are "expected" and "might". As long as we want or need to use older 68k software and newer OS4 native software that is no longer supported, I can't imagine how a multi-user OS4 could be implemented. We're all accustomed to copying and moving our files any way we want (expecially those of us using file managers like Dopus) and restricting that is unlikely to be popular. However, who knows what the future holds for Amiga.

@trixie
Sorry about pushing your topic so far off topic. Application "use" settings does deserve some discussion and possible changes.

chris wrote:Sticking the prefs in PROGDIR: scuppers the expected way that a multi-user AmigaOS might work in the future.

Just a thought (and I know nothing more than you guys about any plans the core developers might or might not have for this):

What if PROGDIR: was set up at a multi-assign, one part specific for the user who is logged on, another common for the program's own, global resources. The part specific for the user could physically live in subdirectories of a "home" directory each user would have (the concept of a home directory seems to me to be an almost indispensable part of almost any thinkable multi user scheme anyway).

Best regards,

Niels

colinw wrote:You would be much better just doing: "info env: >>ram:temp" preceeded with a marker number and followed by a wait 1.
The log will show when ENV: got substantially bigger, if you can call ~170K big, that will be enough to determine when
something scanned the ENV: root dir. If you want to make it really obvious, put a temp file in ENVARC: that's a meg or so in size.

Good idea, I might try that (when I get time again in some days).

I still think it not worth all this bother trying to fix something that isn't broken, just to save a hundred K of RAM.

You're probably right, except that this has become a bit of a quest now, finding out what causes it. It's not about the hundred kilobytes (at least not to me), but about being able to explain things correctly to the next person who wonders.

Best regards,

Niels

To continue our discussion:

Based on the arguments presented here, I can now see that it is fairly logical that the lifetime of Use-d settings should equal the runtime of the application, not the runtime of the OS session. In that respect my original question has been answered.

However, a few related questions have cropped up in the meantime:

1. If there's no need to keep Use-d settings after the program quits, the program will store them internally, in memory. So why would Application Library, or anybody, want to save them into ENV: (which is the library's default behaviour) at all?

2. If you say ENV(ARC): is not suitable for storing application settings, fine with me. But where do they belong? The prog dir is OK in that the settings go with the program - but then again, in the prog dir your settings can easily get lost/overwritten when upgrading/reinstalling the app. I can definitely see advantages in having a shared directory for application settings. And as Chris says, in a future multiuser OS it can even be a requirement.

I'm sure opinions will vary, so a standard will have to be proposed and enforced.

trixie wrote:To continue our discussion:

Based on the arguments presented here, I can now see that it is fairly logical that the lifetime of Use-d settings should equal the runtime of the application, not the runtime of the OS session.

I don't think I completely agree with that. There are cases where you would want Use settings to remain in effect after an application is closed. For example, when all the indicators in the lower right of the Odyssey window turn blue, there is little choice but to quit and restart Odyssey. Odyssey and other browsers can get stuck on a bad WEB page and need to be restarted. In those kinds of cases, it's handy to have the Use settings in ENV: so you can reopen an application with the Use settings. Personally, I see the use of ENVARC: and ENV: as two different issues. I think applications could use ENV: for Use settings but that settings should be permanently stored in PROGDIR: and not ENVARC:

trixie wrote:1. If there's no need to keep Use-d settings after the program quits, the program will store them internally, in memory. So why would Application Library, or anybody, want to save them into ENV: (which is the library's default behaviour) at all?

As long as applications have a Load Settings menu or button to reload saved settings, I see no reason why the Use settings can't be in ENV: instead of internal. On the other hand, MUI has per-application settings for window positions that can be not stored, stored until reboot or stored permanently. Perhaps we need similar per-application "System" and/or "Application Library" settings.

trixie wrote:2. If you say ENV(ARC): is not suitable for storing application settings, fine with me. But where do they belong? The prog dir is OK in that the settings go with the program - but then again, in the prog dir your settings can easily get lost/overwritten when upgrading/reinstalling the app.

The same can be said for major OS4 updates like the upcoming OS4.1 FE. Unless you have your system set up with assign adds like I do (assign add C: SYS:MyC, assign add LIBS: SYS:MyLibs, etc.) to keep 3rd party stuff seperated from system stuff, you will probably end up searching through your previous install to copy over 3rd party apps and settings. Granted, that's a less frequent occurance since we started using AmiUpdate but it will still happen occasionally.

trixie wrote:I can definitely see advantages in having a shared directory for application settings.

True, but it doesn't need to be the ENVARC: directory. We can introduce a new shared directory for 3rd party applications such as "APPARC:" or simarly named assignment.

trixie wrote:And as Chris says, in a future multiuser OS it can even be a requirement.

That's a pipe-dream in my opinion. Dream on Chris

trixie wrote:I'm sure opinions will vary, so a standard will have to be proposed and enforced.

It's good to have standards for people who want to follow them but enforcing them will be almost impossible. Can we enforce the standards for MUI apps, AmiCygnix apps, Hollywood Apps, QT apps or Linux ports? No, we can only complain and hope somebody listens.

xenic wrote:

trixie wrote:And as Chris says, in a future multiuser OS it can even be a requirement.

That's a pipe-dream in my opinion. Dream on Chris

A pipe dream, yes, but one that is worth considering to avoid disruption later, should it actually happen.
It's not worth defining standards that might need to be torn up later, or just get in the way of future changes.

chris wrote: A pipe dream, yes, but one that is worth considering to avoid disruption later, should it actually happen.
It's not worth defining standards that might need to be torn up later, or just get in the way of future changes.

I think a new system-wide location like the APPARC: assignment I mentioned would meet the needs of a multiuser system. Copying settings/variables to ENV: might speed up settings access on old classic Amiga systems, but today's hard disks are fast and loading/saving settings from disk is just as fast (or faster) than loading them from a ram-drive (or device) like ENV: . Therefore, a new system-wide storage location would be simple to implement. It would also make it easier to copy 3rd party application settings to a fresh OS4 installation. You would simply copy the APPARC: directory over to the newly installed OS. In the past, I've always had to find and copy application prefs from my old ENVARC: directory with to a newly installed ENVARC: directory with Dopus4.

When you refer to "multiuser" are you referring to a Linux style system that will control what applications a user has access to or just identifying application settings with a user?