There’s another Add method, passing an entry_ref, which gets the signature from the attribute or resource (whichever exists, it seems).
Notice those just add the signature to the list of recent apps, they don’t build a menu. When you call RecentApps::Get to know the latest ones, those signatures are visited to get a list of entry_ref. GetRefForApp checks the MIME database to get the path. No entry, no path, no result.
There are a pair of interesting comments there: “First the MIME database is checked […] If that fails, a query […]” and “We’ll use BMimeType to check for the app hint, since I’m lazy and Ingo’s on vacation :-)”. So maybe we totally forgot the query part that would make the item appear even without an entry in the mime db.
And then the deskbar itself checks the signature from the file among other things it does when building that menu.
This looks like fixing things downstream from where it should be done (and that explains why that would be badly documented: it’s touching the internals of things).
The upstream source for all this information, that is rather well documented, is the executable resources. If you have that (as madmax explained), the OS (through the registrar and MIME database, which in turn can be manually triggered by mimeset, the Identify menu in Tracker, or simply double clicking the app in Tracker) will cache all that info (in the MIMe database and in filesystem attributes on your application file).
That means you need to complete these two steps in that order:
Have a resource file
Have the app registered with the registrar
In particular, starting the app from the command line does not trigger the second step. Starting it from Tracker indirectly does (the file will be “identified” in the process of deciding if it is a runnable app).
You don’t actually need a BApplication for this part. That comes into play only later, when the app is running.
I will have to bear this resource file story in mind, as it isn’t normally something I think of.
The thing is, you don’t really need to have a resource file, so it’s easy to forget that you need it, if that makes sense. Yesterday I made some sample applications that worked with Recents with just a couple attributes attached directly to the file, xres -l showing no resources.
So … sure, that’s how it should be done, with the resource file, no argument there. But it doesn’t seem to verifiably explain the problem I encountered.
ressources are data appended to the ELF file in Haiku. You need these if you ever transfer your ELF files to any fa not supporting attributes, as they will be lost. But with it in the ressources the OS can just get them when needed. You should usually, if you are dealing with a compiled application, use the ressources and not worry about attributes for this that much.
The attributes are what is eventually used to locate the file (through queries), but in this case they are meant more as a cache and easier access to the data from the executable resources. Using queries will be much faster than scanning all executable resources each time the system is looking for an app.
Registrar reads the resources and rewrite some of them as attributes when the file is identified (either through mimeset or through the tracker code that does the same).
So, yes, you can populate the attributes directly manually by imitating what the registrar did for other applications, and you will eventually get it to work. But that’s not how you should do it, and that’s why this part is not very well documented. If you really want to get to the bottom of it, you have to get that info from the code in Registrar dealing with these attributes.
:-)”. So maybe we totally forgot the query part that would make the item appear even without an entry in the mime db.