@ChrisH

Quote:

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

My words "here on Amigans.net" were a link to the post, so maybe your browser (settings) are fooling you.
(To people reading the quoted post: please follow the link and read also the rest of the discussion - if you're interested, of course).

As for the points you raise, I had already indirectly answered in my replies to broadblues, so I'll avoid polluting the thread with repeated stuff

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

@whose

Quote:

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.

Well said. Can't stress it enough.
And, I'd add: sometimes it's also a good thing to let users decide when the system is allowed to take over.

Quote:

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

Totally agreed. Unfortunately, this important functionality has been highly hampered by the overuse of real icons.

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

@whose Quote:

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.

I never meant to imply that was how it was set-up NOW. Rather, I was discussing how AppDir will be used in the FUTURE.

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

@ChrisH

Quote:

ChrisH wrote: 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.

doesnt matter that 99percent of the time is right, when that last percent can lead to difficult to track issues, system stability, is a severe security risk and file integrity risk - not to mention the simple annoyance that the system will simply fail altogether if you have two similar named files.

/stone

@whose Quote:

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.

Sorry? HOW does AppDir "take control away from the user"??? Seems to me that AppDir is giving the user extra options! They can either specify the full path (good luck!), or they can just use AppDir.

You also failed to answer how a solution that improves the situation in the majority of case, AND MAKES IT NO WORSE IN THE OTHER CASES, is bad...

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

Quote:

Xenic wrote: 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.

To be fair, that's a problem with search paths too.

Quote:

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

Nonsense. I tested with Wet and it read the tooltypes with no problems. Remember that if you call APPDIR:Wet in the Shell, it will call it as a Shell command - so the icon details won't be passed. You need to use WBRun APPDIR:Wet to fool the OS into thinking you have opened it from Workbench.

Also: PROGDIR: is created at program launch time by the OS, it always points to the dir the program is in. If you launch it via APPDIR: or with a full path makes no difference.

Quote:

Saimo wrote: 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).

I agee to an extent. ChrisH's example probably doesn't need any icons in the archive. However, BOH is a different kettle of 'nanas - Amiga software should have icons for the files that the users interact with via Workbench, anything the user doesn't normally need to use (program data, config files that have an editor, etc) should have no icon. The whole drawer should then be snapshotted in "Show Only Icons" mode. You then get a neat application launch area which has the main program, documentation showing and none of the program's data files. Contrast this to Windows where the old program manager or start menu is needed because of the inability to only show these important files to the user - or even at a lower level, a Windows application installation is often a load of compressed files that are in full view because there's no way of hiding them, and the setup program (and then often more than one icon marked "setup" because of the default config to horribly hide file extensions). The user doesn't need to see everything, and doesn't want to have useful files hidden. BOH should have an icon for the main program, installer and documentation. Everything else should be hidden by default.

Last edited by Chris_Y on 19-Jan-2010 at 07:53 PM.

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

@whose

Quote:

whose wrote: 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.

How is it borked? It's just not there yet.

APPDIR: could (and should) be extended to be able to specify different classes of apps. You could have APPDIR:Default/VideoPlayer for example. A corresponding Prefs program would allow these defaults to be set, and the default tool on def_MPG, def_AVI etc would be APPDIR:Default/VideoPlayer by default. User sets the video player in Prefs (the Prefs program could handle checking/writing the path initially to ENVARC:AppDir to avoid the user having to run it once), all the video files automagically now open in the newly specified player.

This could be extended further, integrating MIME types into the OS (which needs doing anyway tbh). Filetypes set in DefIcons would also have an associated MIME type, and MIME prefs would specify the default application for video/*, video/mpeg etc. The equivalent APPDIR: path would be APPDIR:MIME/video/mpeg - if this isn't found, APPDIR:MIME/video/default would be used, if that isn't found the global MIME default APPDIR:MIME/default would be used.

Extending still more, launch-handler's FILE protocol handler is rather weak at the moment. URL:file=somefileorother defaults to loading in a web browser. Firstly, shouldn't that be MultiView? Secondly, an extension could either check the filetype on-the-fly, or allow an application to specify the short filetype name or the MIME type. launch-handler would then use APPDIR:MIME/mime-type to open the file (APPDIR: performing the usual fallbacks)

Just some random ideas.

Chris

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

@stone and all against it...

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? 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.

"Entirely useless" is a complete exaggeration. If you are in a state where you could potentially loose a great amount of data in a possible crash you wouldn't use any automatic system.

The latest used version of DvPlayer is run of course. That's the whole point.

Of course such a system can never be perfect and will cause a mismatch or be unpractical now and then. No automatic system is good in all situations. Just imagine yourself in an automatic car and trying to wiggle yourself out of a pile of snow or mud puddle. Impossible since you can't wiggle with an automatic car because it has no clutch, and cannot shift fast enough between drive and reverse.

I still believe the pros will outweigh the cons with this new thing. And if you don't like it - don't use it!

Those who say it will become horrible in scripts, calling the wrong commands, DON'T use it!

Performance-wise I would assume it caches just executed commands and places them in a most-recently-used queue for optimal performance and of course only writes to disk when a program never run before is run, or when it is run from a different location. Even then it may delay the write to prevent lots of frequent writes. I mean, it's not the end of the world if you switch off the computer, or a crash happened just after a new program is run before it wrote it's cache...

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

Quote:

whose wrote: 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.

Typical - blame it on "most users", well I have news for you - "most users" dont use AmigaOS and never will.

Quote:

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

No, DefIcons allows _me_, the _user_ to determine which default tool should be used.

Quote:

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

I just see that AmigaOS is losing it's characterstics and turning something I dont want at all,
I'm saddened by all this crap. AmigaOS was one of those OSes where I felt that _I_ was in control, but now "most users" has infected this system as well.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Chris_Y

Do you know how it feels when you write a post and then you lose it and have to re-write it? Well, that's how I'm feeling *now*

Quote:

Nonsense. I tested with Wet and it read the tooltypes with no problems. Remember that if you call APPDIR:Wet in the Shell, it will call it as a Shell command - so the icon details won't be passed. You need to use WBRun APPDIR:Wet to fool the OS into thinking you have opened it from Workbench.

You're right. But I did experience the problem and a quick test revealed that it's related to DefIcons - f.ex., if you specify APPDIR:UnArc for archives, the application is launched, but it doesn't use the tooltypes (check DESTINATION).

Quote:

I agee to an extent. ChrisH's example probably doesn't need any icons in the archive. However, BOH is a different kettle of 'nanas - Amiga software should have icons for the files that the users interact with via Workbench, anything the user doesn't normally need to use (program data, config files that have an editor, etc) should have no icon. The whole drawer should then be snapshotted in "Show Only Icons" mode. You then get a neat application launch area which has the main program, documentation showing and none of the program's data files. Contrast this to Windows where the old program manager or start menu is needed because of the inability to only show these important files to the user - or even at a lower level, a Windows application installation is often a load of compressed files that are in full view because there's no way of hiding them, and the setup program (and then often more than one icon marked "setup" because of the default config to horribly hide file extensions). The user doesn't need to see everything, and doesn't want to have useful files hidden. BOH should have an icon for the main program, installer and documentation. Everything else should be hidden by default.

I agree. But, at the same time, I still think the tools used to open files should be those specified by the end user, not those "hard-coded" by who associated the icons to the files. The problem originates from the fact that both the visibility and the default tool depend on the same thing: the icon.
An elegant and simple solution would be having a specific tool (let's call it DefaultViewer) that opens any file according to the DefIcons settings: with it, the default tool of real icons could (and, for good practice, should) be simply set to "DefaultViewer" by who prepares files for distribution. It would be even better if such tool/concept was integrated in the system so that the icon options had a "use default viewer" tick box besides the default tool. What do you say?

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

@Chris_Y

Quote:

APPDIR: could (and should) be extended to be able to specify different classes of apps. You could have APPDIR:Default/VideoPlayer for example. A corresponding Prefs program would allow these defaults to be set, and the default tool on def_MPG, def_AVI etc would be APPDIR:Default/VideoPlayer by default. User sets the video player in Prefs (the Prefs program could handle checking/writing the path initially to ENVARC:AppDir to avoid the user having to run it once), all the video files automagically now open in the newly specified player. This could be extended further, integrating MIME types into the OS (which needs doing anyway tbh). Filetypes set in DefIcons would also have an associated MIME type, and MIME prefs would specify the default application for video/*, video/mpeg etc. The equivalent APPDIR: path would be APPDIR:MIME/video/mpeg - if this isn't found, APPDIR:MIME/video/default would be used, if that isn't found the global MIME default APPDIR:MIME/default would be used. Extending still more, launch-handler's FILE protocol handler is rather weak at the moment. URL:file=somefileorother defaults to loading in a web browser. Firstly, shouldn't that be MultiView? Secondly, an extension could either check the filetype on-the-fly, or allow an application to specify the short filetype name or the MIME type. launch-handler would then use APPDIR:MIME/mime-type to open the file (APPDIR: performing the usual fallbacks) Just some random ideas.

It looks like you're mixing two different concepts here: commands path (in a broad sense) and file type recognition. And that's a bad thing, IMHO. Sure, let's improve file types recognition (f.ex., let's add MIME types, let's make the most of the datatypes + DefIcons union, let's integrate DefIcons more in the system), but let's not use APPDIR: for file types handling

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

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

@all

I honestly don't understand the fuss about this feature. It's a shortcut to programs for those that want it, and the server runs with priority -99, so it's not slowing anything else down.

EDIT: Just tried adding APPDIR to the path, and it doesn't work. Nevermind.

Hans

Last edited by Hans on 20-Jan-2010 at 12:59 AM.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Deniil715

Quote:

Deniil715 wrote: @stone and all against it... "Entirely useless" is a complete exaggeration. [..] Of course such a system can never be perfect and will cause a mismatch or be unpractical now and then. [..] And if you don't like it - don't use it!

im not per say again the system- im just raising concerns- and yes, for an operating system it does equal "entirely useless"

you cant have the system executing ambiguous commands. it needs to be definite. even worse, executing the wrong program for a file can result in data loss and its an open invitation for malware and harmful software.

imagine the number of problems this thing can cause if amigaos actually gets widespread- its something that will fuel massive frustrations when file integrity is at state and debugging is obfuscated so the user cant tell exactly which program or version is run.

besides, i can not choose to not use it, if the applications i install uses the system.

/stone

Last edited by stone on 19-Jan-2010 at 10:38 PM.

@kolla

Youre shooting at the wrong aim... its not "typical - most users", its "typical - experienced users like YOU". I only pointed at the fact, that there are still users that dont share YOUR and MY experience, and that it would be a nice move to support them as good as we can, too.

With DefIcons, you are simply not right. DefIcons allow you to determine the used Apps in forefront, but for actually OPENING the apps it gives you no control. If you did something wrong, DefIcons will execute it wrong. And it will execute wrong, if any unexperienced user will do something wrong by accident. See the difference between YOU having full control over the used default tools and DefIcons having control over the used default tools?

Quote:

I just see that AmigaOS is losing it's characterstics and turning something I dont want at all, I'm saddened by all this crap. AmigaOS was one of those OSes where I felt that _I_ was in control, but now "most users" has infected this system as well.

And this one is a really good sign of not understanding the topic and being selfish. YOU as experienced user shouldnt judge about, what other, not so experienced, users have to wish or not have to wish.

You could make a point in saying "ok, but it should still been made in a way that I could disable it, as I want to have full control myself". Just like saimo says. And, if some "experienced users" werent so overly fast in decision making, this would have been possible to do.

@Chris_Y

Quote:

How is it borked? It's just not there yet.

It IS there and it is borked in the respect to how the default tools system was handled before. It forces users to start a default tool by hand in order to make it known again to the system after copy, move, system rescue actions etc. It is not able to change the default tool used by deficons. Up to now its just a shortcut to applications, and it will behave as an obstacle later, if somebody wants to change something.

Simply imagine a partial reinstall of all the deficons. There is no way yet to make them all obey the "AppDir:" concept. Any user who does an exchange of deficons has to re-enter "AppDir:blah" for every DefIcon again. But this is only one obstacle, and its momentary. For later obstacles, see my former posts about development practices.

The DefIcons example shows, that it was released way too early and will destroy user friendlyness for an unknown time. There are tools missing for users who want to change a number of DefIcons. Some people try out new DefIcon sets, all supplied with different default tools. And it is NOT sufficient to use the AppDir: thingie then, as some users might prefer a totally different default tool! How would an unexperienced user change the default tool then? He has to ask, why his system doesnt do what he wants anymore. And he will be told that hes a dumb one and that he should adapt the DefIcons according to his needs. We all know such threads...

I repeat: Im not totally against this system, I see potential there. But it was invented with insufficient preparation and it was borked right in the beginning. It was not wise to make it so general in taking control, that it even includes libraries into its cache. It will lead to confusion of the beginners, it will make mad developers abuse or circumvent it (because right now this is very easy to do and even better, documented! AppDir: usage and related development is actually not!), and if this happens, it will give compatibility problems, which will confuse beginners, which will lead mad devs into even more abuse and circumvents, which... should I continue?

Not the system itself is the problem here (ok, the performance guys and some from the vaults, but it was said enough about this topic, that it will not have big impact on performance etc.), its the preparation of its release and the missing in-depth thoughts about its impact to new/unexperienced users.

Btw., why do we need MIME types for the OS such badly? I dont see the point, really. If you want to transform AmigaOS with its DefIcons/Datatypes system etc. into some win/lin kind of thing, ok, but this is not what most Amigans want. I warned you!

Edit: Aaah, now I got what you meant with MIME types have to be integrated... well, IMHO this would become another, absolutely unneccessary, redundancy, just in favour of porting programs that doesnt really fit to the meaning of "portable". And pls, dont tell me that the MIME system would be easier to use. It isnt. Its just more well documented, thats all. I never saw another system that lets you open a blackbox object with such few lines as the Datatypes system does. Lets face it: Its a great system, but it would require more work for modernization than a quick-done port of a more-or-less-working MIME link library or shared object. That is the only reason for supporting MIME, isnt it?

Last edited by whose on 19-Jan-2010 at 11:31 PM.
Last edited by whose on 19-Jan-2010 at 11:29 PM.

@saimo

Quote:

saimo wrote: I agree. But, at the same time, I still think the tools used to open files should be those specified by the end user, not those "hard-coded" by who associated the icons to the files. The problem originates from the fact that both the visibility and the default tool depend on the same thing: the icon. An elegant and simple solution would be having a specific tool (let's call it DefaultViewer) that opens any file according to the DefIcons settings: with it, the default tool of real icons could (and, for good practice, should) be simply set to "DefaultViewer" by who prepares files for distribution. It would be even better if such tool/concept was integrated in the system so that the icon options had a "use default viewer" tick box besides the default tool. What do you say?

Yes, that's kind of what I was getting at in my reply to ChrisH.

Quote:

It looks like you're mixing two different concepts here: commands path (in a broad sense) and file type recognition. And that's a bad thing, IMHO. Sure, let's improve file types recognition (f.ex., let's add MIME types, let's make the most of the datatypes + DefIcons union, let's integrate DefIcons more in the system), but let's not use APPDIR: for file types handling

I wasn't suggesting will use APPDIR: for filetypes handling, I was suggesting certain default viewers could be defined within APPDIR: that the deficons' default tools could be set to by default.

@whose

The MIME stuff was just an example, the actual integration is needed for email clients and web browsers when attaching/uploading files - these apps need to look up a filetype and find out what the MIME type is. Vice versa is necessary also for determining the correct icon for a MIME type in email attachments. MIME doesn't need integrating any more than that, I was just suggesting it may be beneficial.

Merging of DataTypes and DefIcons for determining file types is necessary - personally I'm not keen on the DefIcons editor, it means we have DataTypes descriptors and manually defined rules performing pretty much the same task. DefIcons should at the very least have an option to "Use DataTypes" and scan files through that before resorting to its own rules.

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

@Chris_Y

Ah, ok, now I understand fully. Sry for being offensive here, its because Im fed up with ports at all

Hm, wouldnt this be a job for the Datatypes system, too? I mean, it determines the file type of any given data file, so the actual Datatype (not the superclass) could tell via object properties, what the MIME type of the loaded data file is. Ok, Datatypes have to be updated then, but I think this is necessary in the future anyways...

Regards

@Chris_Y

Quote:

Chris_Y wrote: @saimo Quote: saimo wrote: I agree. But, at the same time, I still think the tools used to open files should be those specified by the end user, not those "hard-coded" by who associated the icons to the files. The problem originates from the fact that both the visibility and the default tool depend on the same thing: the icon. An elegant and simple solution would be having a specific tool (let's call it DefaultViewer) that opens any file according to the DefIcons settings: with it, the default tool of real icons could (and, for good practice, should) be simply set to "DefaultViewer" by who prepares files for distribution. It would be even better if such tool/concept was integrated in the system so that the icon options had a "use default viewer" tick box besides the default tool. What do you say? Yes, that's kind of what I was getting at in my reply to ChrisH.

By the way, here's a quick proof-of-concept script:

***

.key FILE/A
.bra {
.ket }

Rename "{FILE}.info" "{FILE}.info_"
WBRun "{FILE}"
Rename "{FILE}.info_" "{FILE}.info"

***
It works nicely and now I wish each and every real icon used it as default tool

Last edited by saimo on 20-Jan-2010 at 12:25 PM.

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

How often is this APPDIR: stuff updated in envarc:? If every time something is executed, then it's really bad. But if it's only updated when program with name X is executed for the first time, or from different path, in which case it's likely totally unrelated program or older version (Try APPDIR:a.out if you are a developer).
Anyway, if information in envarc: is updated too often (and if user is using SFS for where envarc is stored), then it will fill up .recycled pretty fast. Even if it doesn't take space from bigger (potentially accidentally) deleted files, it can be annoying to look through long list of filenames, especially if they can have practically any name, as with appdir.

Long ago someone updated Ambient (MorphOS's default desktop) to be "more user friendly" so, that the traditional use/save was removed, and instead settings were saved each time user changed anything (and reverted back if "revert" selected from menu) - and THAT did fill up .recycled pretty fast, and made it practically impossible to hunt down that "one good prefs setting" (or any other file from seemingly endless list of deleted prefs files) - luckily that change was reverted really fast

Anyway, I assume (and definitely hope) my second guess is the right one.

@Jupp3
I am in high interest about techical deep details of how all of this done. Hope someone from os4devel team can explain that for us ..

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites