@all

colinw gives some interesting explanations here on Amigans.net.

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

@whose

Just because something is in AppDIR: doesn't maean you *must* access via AppDIR:!

I would never do AppDIR:Copy for example. AppDIR:mplayer though saves a lot of typing (instead of sys:utilities/mplayer/mplayer).

As to libraries etc, there are only a couple in my envarc:appdir, so I suspect that somthing has attempted to "run" them. (or some other non openlibrary access).

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Yeah, I know all that. But thats my point, the concept wasnt mature enough and invented too early. No developer can be sure about what ends up being in the cache of the AppDir: server thingie. There are lots of redundancies involved yet, that can be solved only by lots of additional work, which will certainly not be done in the end.

As happened to saimo, some application developers will start to abuse or circumvent this system, because they think this is useful for a purpose OS devs never saw in front of inventing it. That will lead to trouble, imagine some application that will become some sort of "standard" by luck and that abuses the AppDir: in any way you cant imagine yet. As soon as this possibilty to abuse the system will be removed, compatibility problems and user complaints will arise.

And for the "I will type AppDir:mplayer" thing: I dont believe that this was the real point for inventing AppDir:

For shell usage the AppDir: has disadvantages, other people here already told about. Path and assigns are much more useful for this.

Most users dont use the shell to start programs, they use the Workbench for this purpose. I see the advantages of AppDir: for this purpose, but nonetheless it has disadvantages now, that will show later on and will be reason for trouble and complaining.

First one is the thing others mentioned already, if the user moves (for whatever reason) any application to another path, he is forced to start it once manually to update the AppDir: entry. Second one is, that this "I will add anything that is somehow in the vincinity of me" behaviour will lead to confusion, e.g. if any not-so-experienced user searches for missing libraries.

Thats the biggest problem of unnecessary redundancies, they confuse.

I really dont believe that AppDir: will improve user friendlyness of the system yet. I might have improved it later on, but not in the state the system is now and I see much problems coming towards us with this.

I really hope that, in a joint effort, developers will come up with solutions everybody can live with, but I doubt it. Amigans are complicated sometimes

Edit: mixed up AppPath: and AppDir:, another confusion

Last edited by whose on 19-Jan-2010 at 02:40 PM.
Last edited by whose on 19-Jan-2010 at 02:38 PM.
Last edited by whose on 19-Jan-2010 at 02:36 PM.

@broadblues

Quote:

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.

Strictly speaking, you're right. And, actually, I was inadvertedly ignoring the fact that AppDir is mirrored in ENV: (which greatly reduces the disk accesses).

However, still, how often applications not in the command path are called indirectly? Whence? I can think of the following places:
* DefIcons - and, since that's a once-for-all setting, it's not a big problem specifying the full path, as said;
* DOS scripts - how many scripts actually invoke applications other than commands?
* launchers like AmiDock, WB menus, etc. - how many places is the same application in? Would specifying the full path a big issue?

Regarding the problem of locating the applications specified as default tools, there was an underlying line of thought I didn't express because I know it's a strong preference of mine that many would/do not share. It originates from the fact that I think that *real* icons are totally overused in Amigaland (in fact, one thing I always do after a full re-install of the OS is removing most of the icons).
Without taking a phylosophycal path, I'll just borrow the example provided by ChrisH, whereby he was talking about uploading videos with APPDIR:DvPlayer specified as default tool in its icon. My question is: why on Earth adding an icon at all? Let me open the video the way *I* prefer, let *my* system take care of it the way *I* want (another example: that's the main reason why I didn't provide icons for BOH's manuals, even if somebody asked for them).

Quote:

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.

Ah, yes. If the information window provided a way to set the default tool automatically to the same of the corresponding deficon would be definitely nice.

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

@whose

I wholeheartedly agree with you.
I'd just like to add a thing: this new feature should have come with full documentation and user/developer usage guidelines.

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

@saimo

Yeah, actually we have some big problems regarding documentation and detailed explanations of new OS functions and parts. I really hope that this will get better in the future.

And I hope that developer information and SDK updates will be released together with future updates that invent new functions. It is not very wise to include only special developers in a closed beta tester/developer program. Closed circles tend to ignore the world outside and often develop strange behaviours and understandings.

I really would like to see more transparency here, would be a great move towards the users, who are interested in costless software only (meant as soft irony, beware! ).

Regards

@whose
Quote:

First one is the thing others mentioned already, if the user moves (for whatever reason) any application to another path, he is forced to start it once manually to update the AppDir: entry.

This should be detectable using standard file notifications. Any exe that is moved should be checked to exist in appdir. If it does appdir could get updated automagically.

Like most features sometimes you don't really get a good feel for how they should work until real end-users hit them. Beta-test all you like but the larger circle of users often provide valuable feedback.

@gregthecanuck

Quote:

This should be detectable using standard file notifications. Any exe that is moved should be checked to exist in appdir. If it does appdir could get updated automagically.

Yes, but the point is: is it really worth it to have duplicate information, (potential) coherency problems and (more or less) complex mechanisms to cope with them? Is APPDIR: that useful? Aren't the other pre-existing mechanisms sufficient already, especially if used properly and effectively?
(I'm just asking: maybe somebody can/will devise some great use I can't think of.)

Quote:

Like most features sometimes you don't really get a good feel for how they should work until real end-users hit them. Beta-test all you like but the larger circle of users often provide valuable feedback.

Very true.

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

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

@gregthecanuck

Hm, AFAIK AmigaDOS file notifications work on a "watch specified Dir or File" basis, which means, that, if somebody e.g. copies an application using the Shell, every possible destination dir has to be watched for. Or the Shell has to check itself, if the given source path is somehow listed in the AppDir: cache and change it according to the destination path. Or you have to use a special "CopyApp" command in order to make sure the AppDir: cache is updated. Or, as it is done now, force the user to start the application manually, every time it is moved. But this is definetly not what users understand, when somebody talks about "user friendlyness".

This is why I said "lots of additional work has to be done, which will certainly not be done in the end". We are in trouble even right now. I dont believe that this is what the OS devs intended, but they did by accident, because they do their work in the background, hidden, without conversation with the users/free developers and without any transparency.

Your second point has to be rejected in a users point of view. The users are not the developers and as such are not intended to make the developers work in the end. Ok, some things simply cannot be avoided and are to be found by end users, but actually most things that happened could have been avoided, if users thoughts and habits would have been taken into account. This didnt happen, obviously.

@broadblues
Quote:

Just because something is in AppDIR: doesn't maean you *must* access via AppDIR:!

I'm just afraid that developers will start using it. I just found another example of duplicate filename problems. The OpenURL archive has a prefs program named "OpenURL" and a command named "OpenURL". If someone uploads a script that uses AppDir:OpenURL to AOS4Depot, the prefs program will open instead of the command if the prefs program was run prior to running the script. I argued unsuccessfully to have the OpenURL prefs program renamed but it was left the same so that old programs would not fail.

I keep my system partition write protected with the "lock" command to prevent programs from saving prefs, widow position etc. that I don't want to save. It also prevents installers from overwriting newer system files with older ones. As a result, none of the program names are saved to my ENVARC:AppDir directory and probably won't be found with APPDIR:name.

For various reasons, I think this concept is a bad idea and would like some prefs to disable it if I want to. Setting search paths & assignments gives the user control while the AppDir concept takes control away from the user (unless we get prefs to disable it or change it's operation).

Last edited by Xenic on 19-Jan-2010 at 04:13 PM.

_________________
X1000 with 2GB memory & OS4.1FE

@zerohero

Quote:

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

[/b]

Ok, I didn't realise that.
Can you explain the differences and the benefits of one over the other.
As a user, they appear to do the same thing, that's keep a track of installed program's.

How is AppDir made aware of a programs location?
Porgrams have to be made AmiUpdate aware to utilise AppPaths, is that the same with AppDir?

_________________
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."

@Xenic

Quote:

Xenic wrote: I just found another example of duplicate filename problems. The OpenURL archive has a prefs program named "OpenURL" and a command named "OpenURL". If someone uploads a script that uses AppDir:OpenURL to AOS4Depot, the prefs program will open instead of the command if the prefs program was run prior to running the script. I argued unsuccessfully to have the OpenURL prefs program renamed but it was left the same so that old programs would not fail.

In fact it's untrue if you remember well when I was sole in charge of OpenURL and after my first release of the OS4 port there was tons of people who did not understand that typing OpenURL in fact launched the preference program instead of actually opening the URL despite they correctly configured their system (it was because their SYS:Prefs was before C: in the search path, which tends to demonstrate average users won't understand nor play too much with search paths). After some private discussions with you (you have been key in instrumenting/debuging the few first releases I did) we choosed to rename the pref program to "Open URL" note the space. Unfortunately when the project was taken over by actual maintainers (who did much more work on it than I would have alone) they reversed this to the old name

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@Daedalus Quote:

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.

You are totally right, and AppDir was NEVER intended to cope with this situation. As I said, it is a big improvement, but not perfect.

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

@stone Quote:

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?

It will run the version of DvPlayer that you LAST ran. Which I think is going to be the correct choice in 99.9% of situations. And in the other 0.1%, well, as I said, AppDir is not perfect.

Last edited by ChrisH on 19-Jan-2010 at 05:40 PM.

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

@saimo Quote:

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);

I'm going to disagree with you here: Before AppDir the user has to KNOW (a) every single def icon that used a particular tool, and (b) know how to change it. After AppDir he doesn't need to know a thing - most of the time path changes will automagically be handled.

It's about making AmigaOS easier & more idiot proof again. And as for the situations where someone hasn't ran an app after moving it, well, they are no worse off than before . And as soon as they do the logical thing (start the app to open the problematic file) then AppDir will automatically be fixed.

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

@saimo Quote:

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

Do you seriously propose that every AmigaOS user manually creates & maintaines something like this to his user-startup file:
Quote:

Path Programs:Viewers ADD Path Programs:Viewers/WarpView ADD Path Programs:Players/DvPlayer ADD Path Programs:Players/MPlayer ADD Path Programs:Players/SWFplay ADD ... ... ...

(this would be a VERY long example if I included all likely programs)

And then of course it stops working when he decides that Viewers should be combined with Players, and has to manually modify lots of lines & lots of def icons...

Quote:

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

Example: I snapshot a video file's icon, then I change my prefered video player in Def Icons. The video file still uses the OLD player . AmigaOS has had this problem for YEARS. If we had a special tool which used DefIcons/etc to determine the correct tool, then it would work fine.

Another example: How many times have you downloaded something off Aminet (or even OS4Depot) when you tried to open the ReadMe file it complained about not being able to find More/MuchMore/Less/some-other-text-viewer? With a default tool this would be a non-problem.

Basically it allows you to have an icon, but not specify the specific tool.

Last edited by ChrisH on 19-Jan-2010 at 05:45 PM.
Last edited by ChrisH on 19-Jan-2010 at 05:42 PM.
Last edited by ChrisH on 19-Jan-2010 at 05:41 PM.

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

@saimo Quote:

colinw gives some interesting explanations here on Amigans.net.

I had trouble finding which post you meant, so I am quoting it here for other people:
Quote:

@saimo I read it, it's rather pointed and uninformed, plus, I really can't believe you would be so reckless as to create scripts to manupilate the path cache and upload it to the public already, especially for purposes that are not even required, and for something you basically don't understand how it works. Did you actually think that we would be stupid enough to create a bottomless pit of junk on your harddrive. ? I will take a moment to mention a couple of things for what it's worth, I usually don't get involved on these forums, but this is an exception, whether it's of any use or not, I really don't care. The APPDIR: server runs at a priority of -99 it does not affect normal operations, it operates asyncronously from the load process, so it does not cause any waits for the loader process, load events are sent as messages to the server for it to service when not much else is happening, besides, it only logs the path of applications when their data changes, not every time they are loadsegged. The reason there are some extraneous files in the cache is because something other than ramlib LoadSeg()'ed them, this may be as simple as running the 'version' command over it, but whatever loaded it, it gets added to the cache when it's not loaded by ramlib. The "hex" comment on the files in the cache are a quick 32 bit hashing value of the path string inside, the other number is the week number the last time it was used, this is so the APPDIR server can automatically flush dead entries after 6 months of no access, so dead entries won't build up. I should take this opportunity to also mention that if the cache is disabled, you're going to need a large bucket of luck getting any of the pre-configured software to work. None of the new URL: device settings will work, a bunch of extras on the CD won't either, nor will future automated update software work or anything that may use an installer script looking for the path of your application with; $(appdir/) Nevertheless, I understand it's your machine and you can cripple it anyway you see fit. Have fun....

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

@ChrisH

Quote:

I'm going to disagree with you here: Before AppDir the user has to KNOW (a) every single def icon that used a particular tool, and (b) know how to change it. After AppDir he doesn't need to know a thing - most of the time path changes will automagically be handled.

And Im going to disagree with you here, as reality shows that you are simply not right. Ok, the problem I will tell now arises from other problems I mentioned before, but it shows that we are indeed in deep trouble right from the start.

I looked after deficon for mp3, and guess what: NO AppDir: thing inside it. That means in the essence, that the user has to alter his deficons manually and has to know how to do it. I didnt look after other deficons, but I strongly believe that they are not set to anything useful, too. So, the system of AppDir: is useless, as long as the user doesnt interact with it himself.

Not user friendly at all.

Quote:

It's about making AmigaOS easier & more idiot proof again. And as for the situations where someone hasn't ran an app after moving it, well, they are no worse off than before . And as soon as they do the logical thing (start the app to open the problematic file) then AppDir will automatically be fixed.

You didnt get the point of a system being user friendly. IF the system is going to take control from the user, it should do this wholeheartedly or never at all. Something in-between will cause trouble in any case.

As you see, the trouble started already. Too many questions open, prepping the system for the release was, friendly spoken, bad, and developers are confused how to handle the system in their future programs.

Most of the critics here tell in the end, that this system was invented without deeper thought, but not that it is bad at all.

OS developers should finally learn to distinct between true critics and trolling to achieve better results and to have happier users in the end. It isnt that hard, believe me

Let me just quickly step in and state that I find the entire concept of APPDIR: totally retarded, a solution for a problem that never existed.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

You are not right here, too. The problem of using specific applications for specific data existed all the time. This is meant from the standpoint of an average user, not very experienced in doing things the CLI way. DefIcons was a step in the right direction, as it allowed the system to determine which default tool should be used for data files that do not have an own icon, which in turn would determine the default tool to use, if the files were saved by real AmigaOS applications (not the ported... uhm... things).

The AppDir: thing would have been the next step, to provide a way to tell the system the path to the default tool independend of Assigns or CLI path defines. With this the user would have been able to define and change default tools for certain data in a very easy way. But the invention was borked, thats the point. Now we have many several ways to define tools, paths, default icons, default handling... it became a mess.

To tidy up this mess will be a lot of work now. This could have been avoided, as I stated already. Lets take this as an example, how to do things not, and how to make it better next time.

Regards