Well, title says it all....

Are assigns still needed and do they still work ? Are they only needed for assigning everyting but applications ? Can I move around apps and will they still work ?

Martin

_________________
Theres a time to live and a time to die
When its time to meet the maker
Theres a time to live but isnt it strange
That as soon as you're born you're dying

@Metalheart
AppDir has NOTHING to do with assignments, so forget that. What AppDir does is remember where particular applications are stored (by seeing where they were last run from), so that you can then do something like this from the Shell:

AppDir:TuneNet

By magic, this will run TuneNet, where-ever it is located! Even more useful for apps like OWB or DvPlayer, as you can open files just by typing:

AppDir:OWB someWebpage.html
AppDir:DvPlayer someVideo.avi

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Ok, so you still HAVE to assign programs that need it, but when once run you can start them without typing in the complete path. Right ?

_________________
Theres a time to live and a time to die
When its time to meet the maker
Theres a time to live but isnt it strange
That as soon as you're born you're dying

@Metalheart
Yes!

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Ok, then

Thanks for the explaination !

Martin

_________________
Theres a time to live and a time to die
When its time to meet the maker
Theres a time to live but isnt it strange
That as soon as you're born you're dying

@ChrisH

Isn't AppDir just the same as AppPaths for AmiUpdate?

_________________
Peter Swallow.
A1XEG3-800 [IBM 750FX PowerPC], running OS4.1FE, using ac97 onboard sound.

"There are 10 types of people in the world: those who understand binary, and those who don't."

@Swoop

No! AppDir: is a new DOS device, AppPaths for AmiUpdate is a path in ENV: where application paths are stored. Very different things.

_________________
Common sense - So rare it's almost like a super power

@zerohero

It works the same way though, the difference is the OS handles the new APPDIR: and you can launch apps with APPDIR:appname. AppPath is a manual process. The data structure in ENVARC: is identical bar the directory name.

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

@Chris_Y

AppPaths is used by one application only. AppDir: is a system device. While they might store their data in almost the same way, as of now, they're used very differently.

I admit, that from a developers point of view, they're quite the same. From a user perspective though, they are not to be confused.

_________________
Common sense - So rare it's almost like a super power

@zerohero

Yes, APPDIR: is much more useful, I wasn't disputing that!

It also makes command search paths pretty much redundant, which is quite an achievement.

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

@Chris_Y
Quote:

Yes, APPDIR: is much more useful, I wasn't disputing that! It also makes command search paths pretty much redundant, which is quite an achievement.

I'm not so sure I like it that much. It assumes that all commands have unique names. If, for example, you have the SDK installed; there are duplicate command names. If you used APPDIR:Cut in a script and accidently used SDK:Local/C/cut before running the script, you might not get the expected result. Command like cut, echo, join and others exist in C: and the SDK. I also have several programs for which I have 2 copies in seperate directories with different prefs. Snoopy is a good example. You can save the prefs but not load them so I have copies in 2 directories with a different set of prefs for each. I'd never know which one I would get if I used APPDIR:Snoopy as a command. Your ENVARC:AppDir directory is also permanently filling with every command you have used; even if some were programs that you didn't like or crashed and you removed. Try dir ENVARC:AppDir to see all the commands, libs etc. you have used since installing OS 4.1u1.

Last edited by Xenic on 19-Jan-2010 at 12:26 AM.
Last edited by Xenic on 19-Jan-2010 at 12:25 AM.

_________________
X1000 with 2GB memory & OS4.1FE

@Xenic

Quote:

I'm not so sure I like it that much.

Same here. With more work it could be better, but still, personally, I don't think it's a really useful feature (more below).

Quote:

It assumes that all commands have unique names.

Bad thing, agreed. I wonder if the hex comments of the files in ENVARC:AppDir have anything to do with this.

Quote:

Your ENVARC:AppDir directory is also permanently filling with every command you have used; even if some were programs that you didn't like or crashed and you removed. Try dir ENVARC:AppDir to see all the commands, libs etc. you have used since installing OS 4.1u1.

Yes, that's another thing I don't like - in fact, yesterday I wrote (and uploaded to OS4Depot) a little tool that removes the invalid entries.

Other things I don't like are:
* everything gets stored, not just commands/applications that the user launched (even things like Popupmenu.class, for example);
* managing APPDIR: doesn't come for free: every time an executable is run, the device checks whether an entry already exists (open file, read file, check content, check comment, close file) and if not/wrong, creates a new one (create file, write path, write comment, close file); these operations involve disk/filesystem accesses and while they aren't much of a problem when launching a single application, they might cause severe slowdown during the execution of scripts (and, besides, I personally prefer the disk to be accessed as little as possible and possibly only when strictly necessary);
* since there is no guarantee that the paths stored in ENVARC:AppDir are correct, APPDIR: isn't reliable (and, no, I'm not suggesting it should be made reliable) and so its usefulness is reduced a lot - f.ex., let's say one has put "APPDIR:MultiView" as default tool of a deficon, but then MultiView gets moved: the next time around a project with that deficon is opened, opening fails and so one has to manually launch MultiView to refresh its entry in ENVARC:AppDir.

So, what would I propose? Well, first and foremost, I'd like an option to disable APPDIR: forever (I'd use it). Then, it would be nice if there was an option that allowed to specify which applications/commands should / should not be tracked.

Overall, I really wonder: how useful such feature is? How often one needs to check/set paths manually? How often that isn't easily accomplished by means of the command Which or manually? If I add also the downsides discussed above, I come to the conclusion that I don't like this feature, neither I'd use a more refined version of it (which, in general would be welcome, of course, but I wouldn't use it anyway because its toll on my system would be too much compared to the benefits I'd get).

EDIT 1
Forgot to say: applications launched from APPDIR: can't read their icon tooltypes (maybe they aren't passed PROGDIR: correctly?).

EDIT 2
Found a way to "disable" APPDIR: manually: I replaced ENVARC:AppDir with a dummy file. The APPDIR: device doesn't replace the file with a proper directory and, hopefully, handles the failed access nicely (for now, everything seems to work fine - it would be nice if a/the developer confirmed this).

EDIT 3
I didn't think about specifying that most of the above is just guesswork by me (and, in fact, some of the things I say are wrong): information about the actual functioning of the device can be found here.

Last edited by saimo on 19-Jan-2010 at 05:01 PM.
Last edited by saimo on 19-Jan-2010 at 05:00 PM.
Last edited by saimo on 19-Jan-2010 at 02:49 PM.
Last edited by saimo on 19-Jan-2010 at 11:37 AM.
Last edited by saimo on 19-Jan-2010 at 11:08 AM.
Last edited by saimo on 19-Jan-2010 at 09:39 AM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo Quote:

I really wonder: how useful such feature is? How often one needs to check/set paths manually? How often that isn't easily accomplished by means of the command Which or manually?

AppDir's fantatic usefulness will only become apparent after some time. But some examples:

* We can have DefIcons which actually specify tools, and it will work where-ever the user stores their programs, and even if he moves them.

* If I upload an archive which contains videos, then video icon's "Default tool" can be "AppDir:DvPlayer" and it will work on every user's installation (that has Update 1). Same for music (AppDir:TuneNet). No more tools with wrong paths stored in the icon. Suddenly "Default tool" becomes actually useful again!

* If I write a script that uses some program, I don't need to make the user edit (or otherwise specify) the location of the program, because I can just use AppDir to automagically find it.


Is AppDir a perfect or ultimate solution? No! But it does bring us one big step closer to AmigaOS being simpler & more idiot-proof again.

IMHO, what we need now is a tool which uses DefIcons (or similar) to find the default tool for that file type. Then we could simply specify "default" as the tool for most data files (pictures, videos, music, documents, etc) and expect that this will use the user's preferred tool (e.g. MPlayer vs DVplayer, e.g. the many picture viewers). This would bring us back up to the level of other OSes (and beyond!), where they know that double-clicking on an AVI file or MP3 will always work.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Quote:

ChrisH wrote: AppDir's fantatic usefulness will only become apparent after some time. But some examples:

I agree, I think it's a good idea in principle, though as were highlighted, there are some issues with the implementation.

Quote:

* We can have DefIcons which actually specify tools, and it will work where-ever the user stores their programs, and even if he moves them.

I haven't tried it, but what it for example, AppDir:TuneNet is set in the deficon settings for MP3 files, and then you move TuneNet to another folder. My guess is that the deficon won't work then until you launch TuneNet by hand to update its location. I don't think this is an obvious step for a newbie to take if faced with the problem...

Quote:

* If I upload an archive which contains videos, then video icon's "Default tool" can be "AppDir:DvPlayer" and it will work on every user's installation (that has Update 1). Same for music (AppDir:TuneNet). No more tools with wrong paths stored in the icon. Suddenly "Default tool" becomes actually useful again! * If I write a script that uses some program, I don't need to make the user edit (or otherwise specify) the location of the program, because I can just use AppDir to automagically find it.

Yes, these are excellent features to have indeed, though what if someone deosn't have TuneNet installed anywhere? I guess you're still no worse off than you were previous to the update, so that's ok.

Last edited by Daedalus on 19-Jan-2010 at 01:12 PM.

_________________
RobTheNerd.com | InstallerGen | SMBMounter | Atoms-X

@ChrisH
Quote:

ChrisH wrote: * If I upload an archive which contains videos, then video icon's "Default tool" can be "AppDir:DvPlayer" and it will work on every user's installation (that has Update 1). Same for music (AppDir:TuneNet). No more tools with wrong paths stored in the icon. Suddenly "Default tool" becomes actually useful again!

and what if you have two versions of dvplayer installed? lets say an old backup stored somewhere and the newest version somewhere else?
which version is actually run?
if you cant guarantee that the "wanted" version is run and you risk running an unwanted version, then the tool is entirely useless- not to mention outright dangerous.

now, i havnt tired using it so i wouldnt know how the system handles it, if at all.

/stone

@ChrisH

Quote:

* We can have DefIcons which actually specify tools, and it will work where-ever the user stores their programs, and even if he moves them.

I had already tried this and it worked, but that's not much of an advantage because:
* nobody is going to change the location of their default tools all the time (meaning that setting the default tool of deficons the old way instead of using APPDIR: isn't that demanding);
* as already said (and as also Daedalus correctly noted), if one changes the location of a default tool he'd break the deficon setting until the tool is run again (meaning that still the user might required to perform a manual operation, only that this is more indirect and less obvious).

Quote:

* If I upload an archive which contains videos, then video icon's "Default tool" can be "AppDir:DvPlayer" and it will work on every user's installation (that has Update 1). Same for music (AppDir:TuneNet). No more tools with wrong paths stored in the icon. Suddenly "Default tool" becomes actually useful again!

Yes, this would be a good use, although, since APPDIR: is intrinsically unreliable, it does not solve the wrong default tool problem. The only real solution (besides that of having a strictly coherent registry of the installed applications - which I do *not* want) is that people stops specifying full paths into their icons - f.ex. "installer" is sufficient, no need to add "SYS:Utilities/" or whatever. The "command path" concept already exists, it just needs to be used properly.

Quote:

* If I write a script that uses some program, I don't need to make the user edit (or otherwise specify) the location of the program, because I can just use AppDir to automagically find it.

Again, nothing that the good ol' path can't handle


Quote:

IMHO, what we need now is a tool which uses DefIcons (or similar) to find the default tool for that file type. Then we could simply specify "default" as the tool for most data files (pictures, videos, music, documents, etc) and expect that this will use the user's preferred tool (e.g. MPlayer vs DVplayer, e.g. the many picture viewers). This would bring us back up to the level of other OSes (and beyond!), where they know that double-clicking on an AVI file or MP3 will always work.

I might be missing something but I can't see the advantage over (or, well, the difference with) deficons

Last edited by saimo on 19-Jan-2010 at 01:50 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

Hmm... I had a look at the AppDir: stuff, and I have the urgent feeling that there was a concept incorporated into the OS, which was not really matured until then.

I will ask some simple questions and hope to get really senseful answers to them, but in the end I know none of the OS devs could give me one. Lets see...

1. Why are even system libraries listed in AppDir?
1.1 Are they apps?
1.2 What about the two standard locations libraries are normally find at, were they not sufficient?

2. same for CLI commands

3. What about standard installation default icons?
3.1 As this new concept is incorporated, why it isnt used for the default icons yet?

Well, for moving applications, other people said ´nuff about it.

I dont think that it was a very wise move to invest time and work into this to get it out for Update 1 release. Devs will face new problems with compatibility later on, because the concept wasnt matured enough and will be abused by some future programs, bet it. At first glance, the concept is nice, but it was invented too early and will lead to trouble.

Just my two Euro cent...

Last edited by whose on 19-Jan-2010 at 01:53 PM.

@whose

Quote:

1.1 Are they apps?

In AmigaOS: handlers, libraries and other resources are seen as "executables".

_________________
OpenWindows Initiative. Port PS3 hardware to bananas. For free. Join today and receive expired $50 cupon from AI!

@opi

I asked "are they applications" in the sense if they are programs used to do some work with user data, apps that may need a system wide path for being found. I know that all these things are executables in the end, but this is not the point.

Another absolutely senseless answer then

Last edited by whose on 19-Jan-2010 at 02:00 PM.

@saimo

Quote:

Yes, this would be a good use, although, since APPDIR: is intrinsically unreliable, it does not solve the wrong default tool problem. The only real solution (besides that of having a strictly coherent registry of the installed applications - which I do *not* want) is that people stops specifying full paths into their icons - f.ex. "installer" is sufficient, no need to add "SYS:Utilities/" or whatever. The "command path" concept already exists, it just needs to be used properly. Quote: * If I write a script that uses some program, I don't need to make the user edit (or otherwise specify) the location of the program, because I can just use AppDir to automagically find it. Again, nothing that the good ol' path can't handle

But were talking about "apps" not 'commands'. in one sense there's no difference I know, but many "apps" exist in their own directory not on the command path. Is Tunenet, dvPlayer, AWeb. OWB on your path? If so you must have such a long complex search path that it takes ages to find anything on it.

This also counters your efficiency argument, calling a command via the path requires a search of each directory on that path until found, calling via AppDir: only needs to check the envvar associated with it. swings and roundabout here I think.


Quote:

I might be missing something but I can't see the advantage over (or, well, the difference with) deficons

Not sure, but doesn't deficons only work for a "deficon" not a "real icon" so I think Chris means he's like deficons to be able to find the default tool for a "real icon" not just a generated one.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad