I dont understand what do you mean by "if its pure qt without any hardware accleration" .
With this I mean that you derive from QWidget and implement paint() using QPainter. This is comparatively slower than OpenGL or Vulkan. For these you need a QOpenGLWidget or QVulkanWindow. This then allows to use OpenGL or Vulkan directly for drawing while still using Qt for everything else (including mouse handling).
You _vbox variable is now useless, you should remove it.
Passing a parent to a layout when creating it automatically applies that layout to the parent. That's not what you want here (beside the fact that there are no use in setting a widget on a QMainWindow object.
Since applications using burger menus usually have a very distinctive style I didn't want to make any assumptions. The look of the menu is up to you to style, it only implements the functionality. Same goes for the burger icon, you can set it to whatever you want, either the one included in the project or your own. There's an example in the repo showing how to style it.
As for actions - you can add an existing QAction or let the widget create one for you using any of the overloads of addMenuAction. In any case it returns a QAction* and you can connect to its triggered signal just as you would with any other action in the built-in Qt menus. Alternatively you can tag these actions in any way you want and only make a single connection to the BurgerMenu::triggered signal. You will get an action that was triggered as a parameter.
One way to tag an action is by using QAction::setData or you can just store the action pointers somewhere when creating them and identify the action by the pointer, text, some property or whatever fits you.
on_actionName_triggered() looks like a slot name created for the the auto-connection feature. If you want to use it you can do that too (although I wouldn't reccomend it). Just create your actions in the designer via its action editor and make your slots names match, just like you would with any normal menus/actions. The only caveat is that you need to manually add these actions to the menu from code, as there's no way to do that in the designer, but that's not a huge problem.
So those are a couple of the most straightforward options out of couple more. It's deliberately left very flexible so you can use it however fits your overall application design best.
I'm sorry, my last remark was non-sensical since a dockwidget is not part of the centralwidget. This is probably some very specific dockwidget stuff that i don't know about. Perhaps some of the guru's here will know if it's possible.