Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: sim085 on July 24, 2010, 11:40:36 AM
-
Something that personally annoys me in Workbench is that it requires .info file to display an icon and determine which program to use to open a target file. I always found the Windows way of doing more natural; that is that file extensions are used to determine the type of file.
However I am really intrested to know what others thing about it and if anyone favours the use of .info files over the use of file extentions.
-
Something that personally annoys me in Workbench is that it requires .info file to display an icon and determine which program to use to open a target file. I always found the Windows way of doing more natural; that is that file extensions are used to determine the type of file.
However I am really intrested to know what others thing about it and if anyone favours the use of .info files over the use of file extentions.
That's not strictly true. Workbench only shows files that have .info files by default. Choosing "show all files" will cause all the files that don't have dot info files to become visible.
Secondly, .info files only specify which action to take when the icon is opened. They aren't used to determine what the type the file is. That's the responsibility of tools like deficons. The latter use various rules, which can be as simple as matching the extension to checking for magic values within a file.
Showing file types based solely on their extension is not a good idea. It's fast, but it's also ambiguous, especially for the glut of three letter extensions that exist.
-
I think .info is brilliant, since it allows me to set different tooltypes and default tool for every single file, and not just for group of files, and it is done in an easy to understand and editable way. I'm quite confident that you cannot even do this on Windows.
Seriously, all the people who think Windows does everything so much better should just stick to Windows, and not whine about doing AmigaOS more like Windows - or you could just use Linux - KDE and Gnome are both busy doing everything as similar as Windows as they can :p
-
Seriously, all the people who think Windows does everything so much better should just stick to Windows, and not whine about doing AmigaOS more like Windows - or you could just use Linux - KDE and Gnome are both busy doing everything as similar as Windows as they can :p
I do not wish AmigaOS to be more like Windows and by this thread I am not suggesting or implying that .info files should be removed. I just know too little on these files and since I come from a different streem (i.e. - was very young when I last used Amiga and only did so for gaming and after that only used Windows) I thought of asking this question to see what others think about the subject ... and ofcourse to learn why these files may be important.
Your reply helped me to understand that more then one .info file can be sued with the same file to open it in different ways.
-
A little off topic maybe but XFCE is a nice desktop if you're using Linux, it has a certain Amiga-like lightweight feel that I find refreshing after Gnome and KDE.. it's quite nice :)
-
For example one of the problems I have is that I found several files from the old hard disk (i.e. - more then 15years have passed since the last time I used these files or my brother did). These files do not have any .info file and therefore I have no idea whit what program I can open these files. I do not know if these files are images or some save files from some game!
-
Something that personally annoys me in Workbench is that it requires .info file to display an icon and determine which program to use to open a target file. I always found the Windows way of doing more natural; that is that file extensions are used to determine the type of file.
However I am really intrested to know what others thing about it and if anyone favours the use of .info files over the use of file extentions.
I think it is exactly the opposite. The .info files are actually a very useful addition to AmigaOS I would miss. They are like Windows .ico files (which maybe you haven't seen because they are hidden), but instead of just containing graphics info for the icon, they also contain information about which tool should start the application, tooltypes information, etc.
I really like .info files!
And...like others have said, files without icons can be started by their extension (.jpeg, .tiff, .aiff, etc.) if you set up DefIcons in AmigaOS properly. It will even give those files a general icon related to that filetype.
-
The Amiga GUI is a work of art, made in a time when people were passionate about their work. Windows looks like a serving of prison slop in comparison.:(
-
For example one of the problems I have is that I found several files from the old hard disk (i.e. - more then 15years have passed since the last time I used these files or my brother did). These files do not have any .info file and therefore I have no idea whit what program I can open these files. I do not know if these files are images or some save files from some game!
You should install deficons which automatically gives an icon (if not one already) for known filetypes.
-
You should install deficons which automatically gives an icon (if not one already) for known filetypes.
Thanks for the info :) I will definitly do that.
-
I've never liked how .info files are only loosely coupled to the object they represent. It might have made sense in the 80's given the simplicity (and limitations) of the period object formats and file systems, but they could just as easily have defined a new hunk type and embedded the data directly in the object. On AmigaOS 4.x, I'm surprised the data hasn't been moved into an ELF section. It would still be possible for tools like Workbench to override embedded data using an .info file if one exists.
-
I find both AmigaOS .info and Windows executables (potentially containing icons) strange design choices. No further comment.
-
I've never liked how .info files are only loosely coupled to the object they represent.
It makes it easy to maintain your tooltypes when you are upgrading to a new version of e.g. OWB. If you are used to .info it certainly has some advantages.
-
I think .info files are absolutely brilliant. Tooltypes are great for storing and adjusting settings. You can position Amiga icons exactly where you want them and they'll never move unless you tell them to. Separate icons allow you to hide unnecessary files, reducing visual clutter throughout your drive. And if you rename a file, it will open with the program you told it to. Filename-based program association is one of the things I hate most about Windows - i.e., renaming file.jpg to file.jpg.old and then being unable to open file.jpg.old by double-clicking.
But, if you do like filename-based program association, you can configure Deficons to work that way. Can't go wrong with the Amiga's configurability. :)
-
I've never liked how .info files are only loosely coupled to the object they represent. It might have made sense in the 80's given the simplicity (and limitations) of the period object formats and file systems, but they could just as easily have defined a new hunk type and embedded the data directly in the object. On AmigaOS 4.x, I'm surprised the data hasn't been moved into an ELF section. It would still be possible for tools like Workbench to override embedded data using an .info file if one exists.
And what do you do with non-executable files?
-
@lsmart
What happens when an Installer script--not necessarily OWB's--overwrites your customized .info? That's not necessarily a drawback, but an installation routine should make an attempt to keep and upgrade a user's existing settings.
@mongo
Use IFF? That's not a good solution either. Deficons is the compromise solution, yes? It all depends on what--operating system or application--owns data. System designers are still looking for the holy grail of application agnostic storage containers.
There are some aspects of .info files, like tool types, that are pretty cool. The downside, I think, is having to write wrappers to combine ReadArgs(), FindToolType(), and generic command-line processing in a way that works with multiple releases of Workbench.
-
But, if you do like filename-based program association, you can configure Deficons to work that way. Can't go wrong with the Amiga's configurability. :)
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!
-
I think DefIcons comes pre-configured for most common filetypes, such as JPEG. Check in the prefs of DefIcons, look for JPEG and see what action it is set to carry out... Change that action to use whatever viewer you like on your system and it should work. Of course, JPEG files *with* an icon/.info file will use the default tool set in the .info file instead. This allows you to override the DefIcons settings for specific files.
I personally think the Amiga system is great once you get your head around it. And RaWBInfo makes handling them a lot easier, allowing you to drag 'n' drop tooltypes etc. in Workbench.
-
.info was an ok idea in 1985 when you only had small capacity devices but really makes little or no sense in these days of TB hard drives.
-
@persia
I don't really see how disc capacity is an issue. If the information was embedded in the file instead it would take roughly the same amount of disc space. The Mac system of data and resource forks was similar but less easy to manipulate, and the Windows & Linux systems are just a mess altogether, although I believe Windows 7 has the ability to specify specific applications to open specific files, overriding the filetype recognition...
-
I think DefIcons comes pre-configured for most common filetypes, such as JPEG.
Are you referring to this DefIcon?
http://aminet.net/package/util/cdity/DefIcon
-
Hmmm... I was actually thinking of the one that came with OS 3.9 - I was sure that was available separately for 3.0 users, but it's a different tool to the one you linked to...
-
Hmmm... I was actually thinking of the one that came with OS 3.9 - I was sure that was available separately for 3.0 users, but it's a different tool to the one you linked to...
I thought so! Does anyone know from where I can find the tool everyone seems to be referring to?
-
I think .info files are absolutely brilliant. Tooltypes are great for storing and adjusting settings. You can position Amiga icons exactly where you want them and they'll never move unless you tell them to. Separate icons allow you to hide unnecessary files, reducing visual clutter throughout your drive. And if you rename a file, it will open with the program you told it to. Filename-based program association is one of the things I hate most about Windows - i.e., renaming file.jpg to file.jpg.old and then being unable to open file.jpg.old by double-clicking.
But, if you do like filename-based program association, you can configure Deficons to work that way. Can't go wrong with the Amiga's configurability. :)
Why would you do something that would not work? Why not just rename the filename file.jpg to file-old.jpg? that way you know it is old and it still works. Trying to work outside the perimeters of the OS is not a valid complaint of it being broken.
-
NewIcons http://main.aminet.net/pub/aminet/util/wb/NewIcons46.lha has built-in deficons functionality if you don't use OS 3.5/3.9. But not so recommended for basic system as it uses some resources. I used it years before upgraded to 3.5/3.9.
-
NewIcons http://main.aminet.net/pub/aminet/util/wb/NewIcons46.lha has built-in deficons functionality if you don't use OS 3.5/3.9. But not so recommended for basic system as it uses some resources. I used it years before upgraded to 3.5/3.9.
So there isn't a version where you can actually determine which icon to associate with which file?
-
Trying to work outside the perimeters of the OS is not a valid complaint of it being broken.
Absolutly.
.info files do exist in Windows. They are shortcut (.lnk) files.
In the 80's, people were figuring things out, and had to work with limited resources. Today, there is really no reason not to take the best of all worlds. Today, an OS should first check for a .info/.lnk file to see if there is a file specific configuration, and if it doesn't find one, it should check the inside the file for a filetype to decide what to use to open it, and failing that, should drop down to using the file extension.
While that would have been a huge burden to the hardware of the 80's, in today's hardware, it would be trivial.
-
Absolutly.
.info files do exist in Windows. They are shortcut (.lnk) files.
.info is not synonymous with .lnk. In fact, .info has more in common with .pif than .lnk. .lnk are pointers to files in other locations.
Program Information File - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/.pif
Computer shortcut - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/.lnk
BTW, there is no .info entry for Amiga's icon files.
-
Why would you do something that would not work? Why not just rename the filename file.jpg to file-old.jpg? that way you know it is old and it still works. Trying to work outside the perimeters of the OS is not a valid complaint of it being broken.
Yeah, but then I need to move my cursor to the middle of the filename! :)
I guess I am trying to work outside the perimeter of the OS. My point is that said perimeter is unintuitive and dumb :)
-
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.
@persia
I don't really see how disc capacity is an issue. If the information was embedded in the file instead it would take roughly the same amount of disc space. The Mac system of data and resource forks was similar but less easy to manipulate, and the Windows & Linux systems are just a mess altogether, although I believe Windows 7 has the ability to specify specific applications to open specific files, overriding the filetype recognition...
-
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.
-
@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/library/bb776891(VS.85).aspx
-
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.
-
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.
-
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?
-
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.
-
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.
-
Yeah, so they are basicly the same thing. A .info file is basically a shortcut.
-
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)
-
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".
-
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.
-
@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.
-
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?
-
.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.
-
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.
-
.info is not synonymous with .lnk. In fact, .info has more in common with .pif than .lnk. .lnk are pointers to files in other locations.
Neither pif or lnk are that good a match. However .lnk files allow you to have icons on your desktop that specify an .exe and flags for a document, which is similar(ish) to .info.
Neither .lnk or .info are a good solution for documents.
.info is good for registry style information, though I can't remember if running from the shell picks them up.
People want to move documents between machines, the majority don't care that they can specify the coordinates of every one of their thousands of documents.
While it's annoying when a windows app steals a file extension you use for something else, encoding the type of file in the name is not a bad idea. It has to be stored somewhere & we are still reliant on 70's file system designs.
Windows also doesn't just support one open method. You can specify different programs for viewing, editing & printing (plus whatever you can think of).
My prediction is that .xml will eventually take over.
-
My prediction is that .xml will eventually take over.
Not in any meaningful way. Too many companies own patents on generic uses of XML.
-
@Bloodline
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.
I was thinking about this a bit this morning, and Windows 7 provides an easy way to emulate the basic launch behavior of Mac OS bundles. Create a directory, e.g. MyApp (or My App--spaces are OK), and put all of your application's goodies in that directory:
MyApp\
MyApp.exe
dependency1.dll
dependency2.dll
data1.dat
data2.dat
In MyApp, create a Desktop.ini text file with the following contents:
[.ShellClassInfo]
DirectoryClass=MyAppBundle
IconResource=MyApp.exe,0
You can add additional Desktop.ini values to further customize shell behavior. Strings in Desktop.ini can be localized. You can also set the read-only and system attributes on the Desktop.ini file to hide the file under Windows Explorer's default view settings, but it's not necessary.
Set the read-only attribute on the MyApp directory.
Add the following values to the registry (no snarky comments from the registry naysayers) ("@" is the key's default value):
[HKEY_CLASSES_ROOT\MyAppBundle]
@=""
"CanUseForDirectory"=""
[HKEY_CLASSES_ROOT\MyAppBundle\shell]
[HKEY_CLASSES_ROOT\MyAppBundle\shell\openDesktopIni]
@="Run" Note: This can be localized.
[HKEY_CLASSES_ROOT\MyAppBundle\shell\openDesktopIni\command]
@=
Where is of type REG_EXPAND_SZ and equal to:
rundll32.exe shell32.dll,ShellExec_RunDLL "%1\MyApp.exe"
You can any value you want in place of "MyAppBundle." Apple-style identifiers, e.g. com.Spacely.Sprocket, work just as well. It's nothing more than a unique text identifier.
The default action on the MyApp directory is now "Run," which runs MyApp.exe. The directory can be moved anywhere, and as a long as you've obeyed Windows guidelines for local execution and use of side-by-side components, everything will work just fine.
A more generalized approach to bundles could treat all directories with the .app extension as special, using shell extensions to manage behavior in ways mostly identical to Mac OS bundles. This approach would work on earlier versions of Windows.
(My primary reason for writing this was to have something useful show up when folks search for CanUseForDirectory, which is only very briefly mentioned in the Windows SDK documentation. The only Windows component on my system that makes use of CanUseForDirectory is Windows Backup and Restore.)
EDIT:
Questions re: Mac OS X bundles (which are complex and weighed down by legacy options--just like Windows--despite Apple's marketing hyperbole):
What happens to file type associations when a bundle is deleted? Does the operating system unregister associations automatically?
Are orphaned preferences files automatically removed, or are they left in place to be picked up again if the bundle is ever reinstalled?
-
The registry is actually a good idea implemented poorely. It could easily be fixed. All MS would need to do is have a batch import/export so that all settings are edited and preserved in local human readable configuration files. This makes maintaining configurations easier.
Using a database for running is more efficent from an execution standpoint, so a simple command could verify and rebuild the registry from the configuration files.
Windows runs an indexer anyway, so it could even keep it's database up to date in near real time.
-
Applications are free to control their own settings any way they like. .NET applications typically use local XML configuration files. (That bodes well for psxphill's prediction, but I suspect the OOXML lawsuit brought by i4i will only force Microsoft further away from standards, not closer to them. The lawsuit potentially affects all XML document implementations, including ODF. Standardization does not exempt users from patent claims.) EDIT: Of course, having well documented local configuration practices doesn't stop lazy, idiot developers from plowing over system-level settings.
Current versions of Windows support transaction-based changes to the registry, and it's a fairly simple process to perform bulk operations. A crude implementation might use 'regedit /e ...' to export and 'regedit /s ...' to import. If you wanted to use XML, you could write a fairly simple XSL transform to convert a registry-like XML schema to a normalized regedit file and vice versa.
Changes to the registry are written to a log before being committed, and most registry corruption is actually caused by disk faults, not a deficiency in the registry design. I'm not saying there aren't flaws, but most registry problems aren't effected by what most people seem to think are common sense root causes.
-
Something that personally annoys me in Workbench is that it requires .info file to display an icon and determine which program to use to open a target file. I always found the Windows way of doing more natural; that is that file extensions are used to determine the type of file.
However I am really intrested to know what others thing about it and if anyone favours the use of .info files over the use of file extentions.
You have seriously got to be kidding. You obviously haven`t used an Amiga very much. Windows icons are useless to the extreme and give very little control. If there is one thing I hate about Windows its the lack of functionality and customisation of the icon. The Amiga gives you so many options in respect of both the look and functionality of the icon. Thank goodness for the info file. It is so important to the way the Amiga functions.
-
Microsoft is the only company that tries to maintain a central repository for all system settings (aka the Registry), most other systems maintain them through multiple config files that are easier to check. You don't have to store everything in one place to control everything from one place.
That being said, what percentage of Mac users (for example) ever check their plist files or even know what the plist files are?
-
Most other systems are based on System V or BSD, and aside from the top-level etc directory sharing a common name, it's a free for all. I'm not convinced that's a strength. :-P
EDIT: Microsoft's biggest mistake regarding the registry, I think, was adding "serious problems might occur if you modify the registry incorrectly" to every knowledge base article with even a hint of registry. This is going to blow my point, but I'm reminded of a sign at Yosemite National Park that warns people against entering pools above the falls because "you WILL go over the falls, and you WILL die." Duh.
-
as the years roll on by, you realize that you can never have enough .info :)
(am I missing the point here...) :insane: