»

[AmigaHeretic]

Originally Posted by sim085

How do you do that? because I cannot understand how from the .guide that comes with DefIcon. It would be helpfull for me if I could somewhere define a rule that all .jpg or .guide are always opened with some specific tool!

So there isn't a version where you can actually determine which icon to associate with which file?

Yeah, you can do exactly what you are asking for. Go to Prefs/DefIcons. Just open DefIcons and look for the filetype you want. (If it's not there you can add new filetypes) Using Jpeg for example. Just select JPEG, right click and choose Information, the default tool is what you want to change. It's probably set to Mutliview.

Now, any jpg file (that doesn't have it's own .info file) will open with the program you selected.

Deficons works on the MIME types embedded in the files. So unlike windows it doesn't matter if your JPG actually ends in ".jpg" If you have a file named waterfall.jpg and renamed it to waterfall.mp3, or just waterfall, it won't matter it will still open it as a jpg.

Now if your .jpg has it's own .info file, it will open with whatever program that .info files specifies.

[Trev]

@Belial6

Shortcuts (.lnk files) are shell links (instances of IShellLink persisted to disk) [1]. Shell links and the extended data they support are more similar to program information files than either is to .info files. Both shell links and program information files manage pointers to separate persistent objects and neither contains an icon bitmap.

EDIT: URL files, while managed by Windows Explorer's shortcut interface, are just text initialization files with a .url extension.

1. http://msdn.microsoft.com/en-us/libr...91(VS.85).aspx

[stefcep2]

The functionality was A Very Good Idea. The name .info was not. As a new Amiga user, I remember thinking it was some sort of help file, providing "INFOrmation" about the executable. Took me a while to work that it wasn't.

[sim085]

Originally Posted by AmigaHeretic

Go to Prefs/DefIcons.

The problem is that I do not have DefIcons under Prefs and nor do I know from where to download it.

[Belial6]

The implementation of .lnk and .info might be a little different, but unless the .info files do something different than what I remember, the functionality is basically the same. As far as I remember of .info files, they give you an icon on the screen that launches another file.

Is that not what an .info file is for?

[skurk]

Originally Posted by Belial6

The implementation of .lnk and .info might be a little different, but unless the .info files do something different than what I remember, the functionality is basically the same. As far as I remember of .info files, they give you an icon on the screen that launches another file.

Is that not what an .info file is for?

Icon and (optional) configuration settings. Everything the application needs.

Brilliant design, as opposed to embedding the icon in the exe file and storing the settings in some horrible registry.

[Daedalus]

Originally Posted by persia

The problem is multiplication of files. If I have six files and six dot info files it isn't bad, I can easily see things in a command line and it's all ver manageable. If I have 6000 it's a lot less clear, six thousand .info files to maintain is more than a bit daunting, I can't just do a global change for example. I have thousands of .doc files on my main machine and I recently changed the program associated with all of them from MS Word to Pages with a shift-click, a selection of Get Info and change the app associated with them. It was clean and now all .docs open Pages.

Using file extensions may not be the best solution but it's really the only one that works.

I understand where you're coming from here, but maybe improved OS handling would be better. For example, being able to open an Icon Information window for multiple selections meaning you can highlight all the files you want and change the default tool only once to have them all open with the same app. Same for the shell, perhaps it could have optional functionality to treat .info files as part of the main file or separately, the way Workbench 4.1 now does - just check a menu item and they're separate files; uncheck it and they're the same file and therefore are moved, renamed, copied and deleted just as their parent file is.

[Belial6]

Yeah, so they are basicly the same thing. A .info file is basically a shortcut.

[bloodline]

Originally Posted by Belial6

Yeah, so they are basicly the same thing. A .info file is basically a shortcut.

No, .info has nothing to do with links! .info file is meta data for the related file. It contains startup options and information, including human readable comments and a graphical representation of the file. It was a brilliant idea, and a similar (but more advanced) idea can be found in both nextstep and MacOSX with their bundles/packages respectively.

While the main file and the .info file are stored as separate entities within the file system, they are conceptually bound and the files should not be treated as separate (in the original 1.x amigaos, you couldn't see any separation)

[skurk]

Originally Posted by Belial6

Yeah, so they are basicly the same thing. A .info file is basically a shortcut.

You can't just make that conclusion without elaborating why.

Does a .info file point to another executable?
Does a .lnk file contain icons and settings?

In UNIX terms, a .lnk file is like a fake symbolic link, and a .info file is somewhat similar to the "dot-files".

[kolla]

Originally Posted by skurk

In UNIX terms, a .lnk file is like a fake symbolic link, and a .info file is somewhat similar to the "dot-files".

More specific, the .desktop files.

[Trev]

@bloodline

a similar (but more advanced) idea can be found in both nextstep and MacOSX with their bundles/packages respectively.

You can do something similar in Windows, but Windows users expect directories to behave like directories, regardless of what's in them or how they're managed. That's a drawback, but it is what it is.

@skurk

a .lnk file is like a fake symbolic link

That's not a great a analogy, as only Windows Explorer (the shell) knows what to do with shell links. An application that uses shell APIs to process files may be able to treat them like symbolic links, but not in all cases. Real symbolic links were added to NTFS with Windows Vista, although Windows Explorer treats them like second class citizens (the shell team not working with the file system team?).

@kolla

Yes, but .desktop (and .directory?) files are not part of UNIX or even Linux. If I understand their use correctly, they share a relationship with KDE and GNOME that's similar to a shell link's relationship with Windows Explorer.

[sim085]

Tools vs Project icons ... How did this work?

Hi again,

This thread has been very helpfull to me to understand better how .info files work. After reading the many comments I tried several experiments. I mostly concentrated on using .info files as shortcuts (which I thought was something missing in Workbench3.1).

In WBStartup I have some commodities. Before what I did was copy and paste these commodities to the WBStartup directory from the SYS:Tools/Commodities directory. Yesterday I deleted the commodity from the WBStartup (still have backup in Commodities directory). I then created a new icon of type project and changed the default tool to point to the ClickToFront in SYS:Tools/Commodities. This worked fine. I felt that like this I managed to create a shortcut.

However then I tried something else ...

I deleted the .info file from WBStartup and then using DirectoryOpus I copied the .info file of ClickToFront to WBStartup. This icon was of type tool. To my surprise this still worked fine!! In other words now in WBStartup I only have .info files and do not need to copy the associated files as well, these are still in SYS:Tools/Commodities.

So does this mean that tool icons still point to the original location of a file even when moved?

[bubblebobble]

.info are no shortcuts/links at all.

A Project Icon tells a "project" file (like an Image, Text, Productivity App Project etc.) with which tool it should be associated when doubleblicked, like Windows is doing with file extentions.

A Tool Icon starts a tool with the stored settings/comments/stack etc.

There are also Disk and Directory icons.

A .info should rarely be alone, almost always they have a corresponding underlying "real" file. I like this concept and prefere it a lot over embedding the icon image in the exe, for example. It is very compatible to other OSes, e.g. you can give certain filetypes an image without the file itself knowing about this image.

[sim085]

Originally Posted by bubblebobble

A .info should rarely be alone, almost always they have a corresponding underlying "real" file.

Yes, but what I managed to do is have two .info files (tools) in different locations pointing at the same program. I feel that is better at organising files rather then just copy paste both the .info & related file to any other location needed.