Viewing the package contents of any file in Tracker

[humdinger]

This is hrev48567.

On the haikuports list (sadly without archive currently: "[HaikuPorts-devs] Installation directories"), there's a short discussion on install locations of apps and all the files they come with (readmes, documentation, libs, data, templates, localization files etc.).
Never mind, if you think apps and their files should be self-contained in their folder in "apps" or sorted to various folders "apps", "data", "lib", "documentation" etc, this might be a good idea to always get to any file of a package:

Tracker's context menu could get a new top level item "Packaged in >" that opens into a next level. At the top of that menu is the name of the package that the file that's being examined is part of. Clicking that will open the package in HaikuDepot. The rest of the context menu works like drill-down-navigation in Tracker, i.e. you can navigate through the package. The path to the examined file could be made italic, so you can find it easier when it's tucked away deeply.

That way, you could e.g. easily right-click onto a program in the apps folder and open its documentation/english/turtorials/index.html without needing to know, where the documentation is: in the app's folder or in the general documentation location. Or the other way around, opening from the tutorial file the app itself.

[luroh]

A file could potentially be present in many packages (e.g. a license file). What would happen if you right-click such a file?

[humdinger]

Replying to luroh:

A file could potentially be present in many packages (e.g. a license file). What would happen if you right-click such a file?

In the top hierarchy of the context-menu would not be the contents of a single package, but another top level with all the packages that include that e.g. license file.

[anevilyak]

Except that information isn't actually accessible from an already mounted packagefs. The only copy of a given file that's visible to Tracker is whichever one has the most recent timestamp of all the packages, or indeterminate if they're all equal. Regardless, the file's sys:package attribute will only list whichever one was decided upon.

[humdinger]

That's probably right, but it's a more unusual use case, isn't it. Normally, you'd start from the app itself or maybe it's documentation. I'm not sure if it not working 100% on every file disqualifies the idea completely. It's quite an annoying fly in the ointment, I concede...:\

[anevilyak]

I'm simply pointing out that as implemented right now, what you're suggesting is simply not technically possible in the case of a file that resides in multiple packages, short of exhaustively walking through all active packages looking for every one that might contain the matching path (which would be rather slow).

Edit: That's not to say it wouldn't work for the normal case of the file coming from a single package, simply that for conflicts it wouldn't be able to tell you all packages the file could've come from.

[waddlesplash]

Moving Tracker enhancement tickets out of R1 milestone -- Tracker's source code comes from BeOS R5, so it already has all the features it did on R5.