Recent applications menu

Development
1

I managed to get my application into the Applications menu, by adding a link to the apps/ file from data/deskbar/menu/Applications/.

How do applications get into “Recent applications”? (once they have been recently invoked of course.)

2

By being one of the X applications being most recently launched by the user, simply.

3

To be sure it has to have been launched, but I’m wondering why this does not apply to the application I installed?

To look at it another way, “application” seems to be defined for this purpose, in a way that excludes what I’m launching from the Applications menu, and I’m trying to figure out what I missed.

4

Does your application have a proper signature?

5

Filetype says it’s “application/x-vnd.Ruml” - proper?

Application flags set to single or multiple launch, makes no difference.

6

Is it a C++ program using the Haiku native API?

7

Sort of. It’s a Rust program, but it uses the C++ API.

But of course any program can do that. The question implies, I think, that some specific part of the API gets an application into the “Recent applications” menu. I’d like to know what it is, because it’s possible that this program isn’t using that part of the API.

8

I’m unfamiliar with Rust and with non-Haiku development in general…
Does it instantiate a BApplication? I suppose that would be neeeded for the Roster to be aware of the app.

9

Yup, I’ve written applications in C via BaCON, also in FreeBASIC, that run perfectly, but never see the inside of Recent Applications. Even FreePascal/Lazarus apps can be iffy on that issue.

10

Sure. With the same signature (I just looked to verify that - wonder who would care if the file’s BEOS:APP_SIG attribute and the BApplication signature were different?)

Anyway, I can construct a BMessenger to the running application, using the signature, from a separate program. So the basic mechanisms there are working.

But of course that C++ scripting tool doesn’t show up in Recent applications, either, now that I think of it, nor do plenty of other odds and ends that have been launched as BApplications.

11

I think I sort of have it: add a SYS:NAME attribute to the file.

I did look in the source, but didn’t find any clue there. It’s just that other applications have this attribute, so I tried adding it, and now it gets shown in Recent applications.

1 Like
12

That’s for the messages catalog, I think.

The little apps I write when testing something appear in the recent apps menu the very moment I add a signature as a resource, not as an attribute, even when they have no attributes:

xres -o test -a 'MIMS:1:BEOS:APP_SIG' -s 'application/x-vnd.example-noname'

If you are not aware of having done so, maybe you opened it with FileTypes to edit the app flags or something. That would also update the resources.

13

I guess that’s a quite common question and that would deserve to appear somewhere in documentation. Before that is done, it could make an article on website about Haiku.

14

This “Recent applications” question actually seems to me more in the category of obscure details. I didn’t find much discussion about it, and I think it’s a little premature to say we really understand the issue. That SYS:NAME seems to have made it work, but some seem to think (see above) that was just coincidental, and alternatively it may turn out that if I’d done the application correctly I wouldn’t have needed to add SYS:NAME.

I added SYS:NAME with addattr from the command line, by the way. It had been through FileTypes multiple times before that.

If someone’s looking for documentation ideas, here are a couple:

  • the deskbar menu structure. Package should include a symlink in data/deskbar/menu/Applications/
  • the .PackageInfo file. I believe I’ve seen good documentation for this, just couldn’t find it. What I did find was a fairly rigorous outline of the syntax in Backus-Naur type notation but little info about the meaning, for example, of “cmd:” type prefix. You could construct a syntactically correct file, but not be sure what it’s going to do.
15

Started anew with a new name and signature and… the signature in the resources was not enough. It needs an entry in the mime db pointing to the right path, something I had from previous experiments (lazy as I am I call everything test). The entry is added with mimeset -af file (if you don’t force it and there’s an entry already pointing to some other path, it won’t be updated), and that uses the signature from the attributes.

16

I don’t know. That worked for me - mimeset - but then I started another experiment, and didn’t have to do either of these extra steps.

  • Compile with long and useless signature
  • run Identify option
  • addattr BEOS:APP_SIG
  • run FileTypes add-on, set application flags, save (this step apparently unnecessary.)

… registers as recent application.

17

Last one does it. You can check before using FileTypes that there were no resource (with xres -l file) and no mime db entry (~/config/settings/mime_db/application/whatever), and that they were created afterwards.

18

Could be, but apparently those resources and entries aren’t needed beforehand. In a couple tests, the first 3 steps were sufficient to get into Recents.

Afterwards, /boot/home/config/settings/mime_db/applications/$SIG has been set up, apparently in the process of launching the file.

My guess is that when it doesn’t work, it’s because something is wrong in this apparatus. Then when you run it through FileTypes, maybe that fixes it … or maybe it doesn’t, maybe it takes mimeset, depends on what’s wrong. Maybe somehow that SYS:NAME did lead to the problem getting fixed, when FileTypes hadn’t. I haven’t been looking at the mime_db data. If I ever find another case where this doesn’t work automatically, I’ll look at that while I’m experimenting.

19

The registrar_server, which keep these recents apps list, requires to add a new entry to that list that:

  • the app must have a signature (list is kept by signature as key). So, either an executable using a BApplication that will identify by itself and automatically to BRoster (and then to registrar_server) or via an attribute BEOS:APP_SIG (which can be extracted from ressource by MIME auto detection) to the executable file
  • the app should NOT have “args only” nor “background app” flags set. I dunno if no flags is known (no ressource/attribute BEOS:APP_FLAGS) what is the expected behavior.

Which means that, by default, any simple, non BeOS/Haiku aware ELF executable, like a simple hello_world.c or a rust compiled binary, won’t qualify.

That’s my understanding.

For those interested on details:

20

This is true because of the “by default” qualification, and also applies to C++ programs. If an executable on the other hand can manage to construct BApplication with a signature, it will qualify, however it was compiled. With a language other than C++, there will just need to be a foreign C++ interface library.

That’s just a fine point. Where my test cases differ, is that it looks to me like the BEOS:APP_SIG attribute is really necessary, along with (I assume) the BApplication signature - it isn’t just one or the other.

And I did start with this one case where that initially wasn’t enough, for whatever reason.