Doesn't this mean that when you open okular you end up with two print actions?

In D12067#243884, @aacid wrote:

Doesn't this mean that when you open okular you end up with two print actions?

Yep:

Oh, I see. So Okular's Print action must go then. There is currently no way to print a PDF file from within Ark.

As discussed on IRC with Kai it seems more a bug in Ark since Konqueror seems to have it correctly work

So, the situation is: the "Print" action comes from Konqueror. Kate part, for instance, adds its own "Print" action, so you get two but only one in Ark. So I don't know how this could be fixed in both cases. Either you end up with duplicate actions in Konqueror or none in Ark (or duplicate in Ark if we add one there).

@dfaure David, what is correct, should the part or the shell provide the print action?

The idea was that the shell provides the print action, and the part gets triggered via a BrowserExtension slot (just like cut/copy/paste).

So, Ark should get a print action (I could add one next to the "Close" button which would make it quite obvious) and Kate is wrong to show it in the menu?

I'd say so.

When I do m_part->actionCollection()->action(KStandardAction::Print) I get the "next bookmark" action in Okular and none in Kate. I tried QMetaObject::invokeMethod but sometimes it's called print and sometimes slotPrint and I don't find where Konqueror actually handles the "print" action.

Hmm that's not how this is supposed to work, no need to look up actions. Look at the connect in kparts browserextension.cpp. The basic idea is: the part derives from BrowserExtension and provides a print slot, the shell calls it. Then the question became "but how does the shell know when to enable/disable the action", which is what actionSlotMapPtr() and isActionEnabled() are about, see KonqMainWindow::connectExtension for sample code.