[Solved] Have Deskbar show tray replicant after restart

I’m tinkering with WorkspaceNumber that displays the current workspace number in the Deskbar tray. I improved the colour and font size handling and it runs as well as before (better even :slight_smile: )…

Only, as before my tinkering, the replicant doesn’t appear automatically in the tray, after a reboot or restart of the Deskbar.

The number image gets drawn by a BView that is added to the Deskbar when you start the app. The BView archives the app’s signature as “add_on” and the view’s signature as “class”.
Isn’t that enough for Deskbar to instantiate the BView on next Deskbar launch?

1 Like

I don’t know if this has ever worked this way. What should work is using the archiving functionality that is placed as a BMessage under “view”. See BarWindow.cpp « deskbar « apps « src - haiku - Haiku's main repository, and StatusView.cpp « deskbar « apps « src - haiku - Haiku's main repository.

Thanks @axeld, but I’m too stupid to have gained much insight from the linked Deskbar code… :slight_smile:

However, I did manage to make it work by stealing from myself the code from Clipdinger’s replicant, which IIRC I also painstakingly lifted from other apps before…

Anyone interested, see this commit.

What I still don’t quite get: Now, I don’t add the BView directly to the Deskbar (which did work BTW), but use the alternative method and add the ref of the WorkspaceNumber application that I get from its app_info.
How does the Deskbar know from the ref of the app that it should instatiate the BView that draws the icon in the tray?
If it started the app from the ref that got added, it still wouldn’t know about the BView, because all the app does is either adding the app’s ref to the Deskbar, or remove it if it’s already been added before…

1 Like

Trough your instantiate_deskbar_item function. You’ve added it as an add-on, and it runs that instead of the App.

1 Like

Mmm, even my never quite finished “Hardmony” app from 2003 uses that instantiate_deskbar_item() to put the CPU temp on Deskbar… but somehow I can’t find any documentation for it.

Guess I too just lifted it up from some other sources back in the days (or I just read this OpenBeOS Newsletter article in time… most likely… the former :smiley:).

Seems appropriately named, thanks for pointing this out!
I suppose the compiler, linker or whatever fills in the blanks to inform the Deskbar where to find my BView’s instantiate_deskbar_item function. As you can see, I’m happily ignorant about the inner workings of the tooling (and vast amounts of pretty much everything else, too)… :smiley:

instanciate_deskbar_item is not a function of your BView, it is a “free function” that does not belong to any particular class and just exists on its own. Just like the main function that is run at the start of the program when you run it normally.

All such functions (unless they are declared static) are available for use in this way by default currently. This means you can find them using load_add_on and then get_image_symbol (a “symbol” is a name for something, either a function or a variable usually).

So, DeskBar can do just this, load your app as an add-on and check if there is a function named instanciate_deskbar_item in it. Then, once it has found that function, it can call it.

For extra details (no need to understand this to use replicants):

Note that while gcc does make all functions visible, this isn’t the case for other compilers and systems. Earlier versions of BeOS and possibly the PPC versions don’t work this way, and so, some extra care is needed. You may see this implemented with the dllexport/dllimport attributes in some old BeOS sourcecode. In newer gcc versions, we can also compile things so functions are hidden by default (-fvisibility=hidden compiler command line flag) and then manually select which functions need to be exported, either using __attribute__((visibility)) function attributes, or linker script tricks. We have started doing this in some places in Haiku sources, and we should probably do it more. It reduces executables sizes and allows the compiler to know that non-exported functions can’t be called from outside, opening for some more optimization, making executables smaller and faster.

Thanks for the background info. Anything can lead to a rabbit hole if you’re prepared to keep digging. My journey ends here, though, Alice. :slight_smile: