Application Bundles

On Mac OS X, one of the nicest things is how applications are handled by the system. Unlike other operating systems available today, all applications are represented in the Finder (the Mac file browser interface) as a single file. In actual fact, this ‘file’ is actually a folder which contains all the data the application needs in order to run, unlike on Windows, were a single .exe file can only contain a limited number of resources and larger apps must usually rely on a vast network of .dlls and other library files to operate, or on any Linux distribution, where the files are spread out about the filesystem. In both these cases, the only humane way for the user to access their applications is through a shortcut file, which provides a confusing interface for users who may think that deleting the shortcut file is removing the program from their system altogether, which it is not.

Mac OS X bundles are of several different types and are very limited in their scope by what the Finder will recognise and do with them by default. My proposal is for a system similar to this for Haiku, but much more flexible. This would be easy to implement for applications as there is already a standard location in the file system which contains them. The proposed ‘.box’ files would be customisable by users and developers to do whatever they wanted to.

Anatomy of a '.box' folder

A .box folder contains any combination of files and folders that may be needed to open it. However, it also contains the following files:

.bundle_info

This, in addition to the '.box' extension of the folder name, identifies a folder to the Tracker as a bundle. It contains the information needed for the bundle in an XML format. It includes information such as what to do when a bundle icon is clicked on, the icon of the bundle, a description of it, etc.

The reason the information inside .bundle_info is not stored in the BFS metadata system is to aid the transmission of files across the Internet. Folder compression formats such as .tar and .zip files do not preserve the filesystem metadata and therefore it is more useful in this case to put the information inside a hidden file.

an icon

An icon in the Haiku standard icon format. It may have any name is it is referenced inside the .bundle_info file. If the icon is not present, a default icon should be displayed.

something to do

This is optional as a bundle may (through the .bundle_info file) have been set to act as a shortcut to another location on the filesystem and may not actually contain any data.

Conclusion

Introducing a bundle format to Haiku would make its interface friendlier by allowing users to manage their applications much more easily. They would require only minimal input from application developers, who would only need to distribute their files as bundles instead of plain folders. The bundles are also backwards-compatible with the original BeOS, because all bundles can be opened as folders in the Tracker and allow the application inside to be opened in the usual way.

Not requiring the use of filesystem metadata negates the need for a special compression mechanism for the folders to be transmitted across the Internet—industry-standard formats can be used for this to avoid work on a platform-specific format.

Hi dpkendal,

the idea of application bundles has come up a few times on the mailing lists. If you’re interested what others came up with, go to http://www.freelists.org/archive/haiku-development and search for “Bundles”.
Also, have a look at the Package Management Ideas in the wiki.

Regards,
Humdinger

I like the idea ,In particular, some regions, the use of Pkgman update package, easy to drop the line, this bundles is particularly suitable for

Thanks to explain haikus package management, we already have :).
The complete system is based on packages, every program in his own package (hpkg). Files who needed for more applications are in separate packages, so you need to install then only one time.
All hpkg file are like a compressed archive and hanging in at startup the system (virtual). If you install a new program it will be hanging in during system is running too.

We didn’t have it yet in 2009 when that forum message was written :slight_smile:

Please, check the date before replying to very old forum messages.

1 Like

Sorry, I didn’t notice the date.
But I think it’s a good proposition, bundles can resolve different versions of the same software installation, hpkg how to install different versions of the same software?
And also, when using Pkgman to install a large number of software in the /boot/system/packages/ directory, haiku startup slows down, and bundles can solve the problem of slow startup.

Would it be possible to lock discussion threads after one or two years inactivity?

Re-activating an old discussion thread occurs once in a while. I have done it a few times too.

The date of the last post on a thread is shown in the right-most column on the topic list in a format which is not consistent. For recent updates, it shows minutes, hours, or days since the last post. For older ones, it shows the month and last two digit of the year.

Locking of a discussion thread after a certain amount of time may be one way to prevent this.

Bringing attention to the format of the date of the last post in some ways or another for an old discussion thread may be another.

Some times a discusion is not ended and some time it will be part of discussions again. I see no problem with it.

2 Likes