added possibility to add custom actions for the group-nodes in the layer tree

[notguiltyspark]

Description

Currently, you can create a custom action in the context menu of layer-tree only for different types of layers. This PR provides public API to add an action for groups of layers.

Two functions are added to public API of QGisInterface:

• Add action to context menu for all group-nodes in the layer tree.

virtual void addCustomActionForGroups( QAction *action, const QString &menu ) = 0;

• Remove action from the context menu for all group-nodes in the layer tree previously added with addCustomActionForGroups().

virtual bool removeCustomActionForGroups( QAction *action ) = 0;

Fixes #53692

[github-actions]

🪟 Windows builds

Download Windows builds of this PR for testing.
Debug symbols for this build are available here.
(Built from commit 3f172e6)

🪟 Windows Qt6 builds

Download Windows Qt6 builds of this PR for testing.
(Built from commit 3f172e6)

[jbp35]

It would be great to be able to add a custom action in the default menu (right click in blank area of layer tree).

[notguiltyspark]

It would be great to be able to add a custom action in the default menu (right click in blank area of layer tree).

I agree, though i think it would be better to create a separate issue.

[github-actions]

The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check

• that all unit tests are passing

• that all comments by reviewers have been addressed

• that there is enough information for reviewers, in particular

  • link to any issues which this pull request fixes

  • add a description of workflows which this pull request fixes

  • add screenshots if applicable

• that you have written unit tests where possible
  In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
  If there is no further activity on this pull request, it will be closed in a week.

[github-actions]

The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check

• that all unit tests are passing

• that all comments by reviewers have been addressed

• that there is enough information for reviewers, in particular

  • link to any issues which this pull request fixes

  • add a description of workflows which this pull request fixes

  • add screenshots if applicable

• that you have written unit tests where possible
  In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
  If there is no further activity on this pull request, it will be closed in a week.

[Rusty-JonesBMT]

Would love to see this implemented.

If there was a way to upvote or something, that would be great. I'm hoping that by commenting, it attracts attention.

[notguiltyspark]

@rouault Could you please check if i need to add anything here or is it good to go?

[rouault]

It's fine by me, but I'd welcome the ACK from another core committer more familiar than me with that part of the application

[notguiltyspark]

Ah, i see! Should i tag someone specific or we just wait for someone to come and review it when they have time?

[nyalldawson]

I'm personally -1 to this approach. I think that what you're trying to achieve can already be done by connecting to the contextMenuAboutToShow signal in iface.layerTreeView().

[github-actions]

The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check

• that all unit tests are passing

• that all comments by reviewers have been addressed

• that there is enough information for reviewers, in particular

  • link to any issues which this pull request fixes

  • add a description of workflows which this pull request fixes

  • add screenshots if applicable

• that you have written unit tests where possible
  In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
  If there is no further activity on this pull request, it will be closed in a week.

[notguiltyspark]

@nyalldawson
Ah, i see! While this signal certainly presents possibility to customize menu, group-functionality seems to go under "general" category, meaning that different components potentially may be interested in already existing mechanism, such as, for example, already prepared interface to add layer-type-specific actions.

In other words, adding it to the interface of menu provider (extending it) allows it to be encapsulated in object-oriented sense, keeping general functionality in one place and particular customization - in the other (through the means of the handling signal).

There is also a moment of where custom menus/actions are being added in context menu. If we catch menu via signal - by default addition appends them to the end, which is often reserved to the export options in terms of user experience. But in manager it is potentially customizable (api can be extended to use some kind of priority)

[nyalldawson]

@notguiltyspark

There is also a moment of where custom menus/actions are being added in context menu. If we catch menu via signal - by default addition appends them to the end, which is often reserved to the export options in terms of user experience. But in manager it is potentially customizable (api can be extended to use some kind of priority)

Actually the signal gives MORE flexibility, because you have access to the full (already populated) menu in the argument. So your code can decide exactly where to insert actions/submenus, as you can find an inbuilt action and then insert your action/menu before it. You also get a lot more flexibility in handling submenus then the API proposed in this pull request, as you could nest submenus, add to other submenus, etc.

In short, the proposed API is adding a lot of complexity for quite a rigid API, when there's already a much more flexible API available in current versions which allows you to achieve the same result.

[github-actions]

The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check

• that all unit tests are passing

• that all comments by reviewers have been addressed

• that there is enough information for reviewers, in particular

  • link to any issues which this pull request fixes

  • add a description of workflows which this pull request fixes

  • add screenshots if applicable

• that you have written unit tests where possible
  In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
  If there is no further activity on this pull request, it will be closed in a week.

[notguiltyspark]

@nyalldawson

Understood!
I removed commits with unsuitable api and instead added one with named separators to help in customization process - this way one can get easier to the place in menu for custom action insertion. What do you think?

[nyalldawson]

I think this should be:

Suggested change

	menu->addSeparator()->setText( QLatin1String( "UndoRedoSeparator" ) );
	menu->addSeparator()->setObjectName( QLatin1String( "UndoRedoSeparator" ) );