Opening apps (by mimetype?) need to prioritise system installation

[jessicah]

I have a problem where I'm doing development on a query-enabled BFS partition, building a 64-bit Haiku installation on a gcc2hybrid install.

But when Haiku tries to open apps, e.g. say in QupZilla, choosing to open a zip file (with Expander) rather than save it; or double-clicking an image file that should open with ShowImage, the query-based search for the app signature ends up finding the copies of the apps in my development tree first.

Since these apps are 64-bit, rather than native, launching the app fails:

Could not open "refind-bin-0.9.0.zip" with application "Expander" (Not an executable). Would you like to find some other suitable application?

Clicking on Find produces a query result with 2-3 copies of all apps that can handle the filetype, e.g.:

• ~/projects/haiku/generated/objects/haiku/x86_64/release/apps/expander/Expander
• ~/projects/haiku/generated/objects/haiku/x86_64/packaging/packages_build/regular/hpkg_-haiku.hpkg/contents/apps/Expander
• /boot/system/apps/Expander

Tracker needs to prioritise the system apps, rather than blindly selecting the first matching entry of the query.

[bonefish]

The logic for finding an app is in BRoster. ​can_app_be_used() could be enhanced to rule out running programs for the wrong architecture. The functions from <Architecture.h> can help. That would at least allow to avoid trying to run x86_64 executables on a gcc2 hybrid build.

That aside, there is also logic to select the best fitting from the queried applications (​compare_queried_apps()). It prefers newer app versions and executables modified later. And for some reason, executables in the system server directory.

I'm pretty sure the newer/later comparisons mimic BeOS's behavior and I guess they seriously suck for (Haiku system) developers. A better strategy might be to prefer apps installed in the standard directories (~/config[/non-packaged]/apps, /system[/non-packaged]/apps) over ones that live elsewhere.

[pulkomandy]

IIRC, BeOS only looked in the boot drive.

Related to https://dev.haiku-os.org/ticket/8799.

[jessicah]

Replying to bonefish:

The logic for finding an app is in BRoster. ​can_app_be_used() could be enhanced to rule out running programs for the wrong architecture. The functions from <Architecture.h> can help. That would at least allow to avoid trying to run x86_64 executables on a gcc2 hybrid build.

Ah yes, I did eventually find this.

That aside, there is also logic to select the best fitting from the queried applications (​compare_queried_apps()). It prefers newer app versions and executables modified later. And for some reason, executables in the system server directory.

Actually, I just realised tonight that what we fail to consider is that there are no apps installed on the boot partition. When I was debugging, I noticed that in the query code, there were no entries returned in /boot/system/... in query_for_app, it stops as soon as the first queriable volume finds one or more apps. This is likely the actual cause for all the problems I'm having.

I'm pretty sure the newer/later comparisons mimic BeOS's behavior and I guess they seriously suck for (Haiku system) developers. A better strategy might be to prefer apps installed in the standard directories (~/config[/non-packaged]/apps, /system[/non-packaged]/apps) over ones that live elsewhere.

This may help after the item above is rectified... :-)

Replying to pulkomandy:

IIRC, BeOS only looked in the boot drive.

And there are no (system) apps there! This is one of those cases where my idea in an old ticket (#10040) of transparently passing the query on down to the packagefs volumes, and marking the packagefs volumes as ephemeral (so that they wouldn't show up) would avoid all of these headaches... rather than hacking around the issue, as was done for DiskUsage as yet another example.

[bonefish]

Replying to jessicah:

Actually, I just realised tonight that what we fail to consider is that there are no apps installed on the boot partition. When I was debugging, I noticed that in the query code, there were no entries returned in /boot/system/... in query_for_app, it stops as soon as the first queriable volume finds one or more apps. This is likely the actual cause for all the problems I'm having.

Good catch. Sounds very plausible that this could have been overlooked.

And there are no (system) apps there! This is one of those cases where my idea in an old ticket (#10040) of transparently passing the query on down to the packagefs volumes, and marking the packagefs volumes as ephemeral (so that they wouldn't show up) would avoid all of these headaches... rather than hacking around the issue, as was done for DiskUsage as yet another example.

As discussed in #10040 it is not that simple, as there are use cases in which one wants to include the packagefs volumes and some in which one doesn't. So, if there was some API performing complex queries, whether to include "embedded" volumes should be specified by a parameter (a volume filter callback interface (with a good default implementation) to be passed to the class would be even better).

Alas, there is no such API. Tracker's ​QueryEntryListCollection is the closest we have, but ATM it is very specific to the needs of Tracker and, living in libtracker, it isn't available to the BRoster implementation anyway.