[Qgis-developer] QgsMapLayerAction and QgsAttributeAction

[Matthias Kuhn]

Hi Nyall

On 12.08.2014 13:33, Nyall Dawson wrote:
> On 12 August 2014 20:42, Matthias Kuhn <matthias.kuhn at gmx.ch> wrote:
>
>> As I am working on a menu, I am more interested in listing/triggering
>> the action than creating a new one (like the one in your link).
>>
>> From this point (usage/triggering) there is not much difference as far
>> as I can tell. So I think that it would be good to be able to query them
>> in one particular place. Therefore I wondered, what you think about also
>> exposing the attribute actions (custom) in the MapLayerActionRegistry?
> Sounds good to me!
>
>> I also have noticed, that the MapLayerActions are a subclass of the type
>> QAction, but I don't think they can be used like that (I did not test,
>> so please correct me if I am wrong. I just noticed that the trigger
>> method is not connected, so if you add them to a menu there is not much
>> happening I think). If this is true, I think it would not be nice to get
>> a fully functional QAction similar to QgsAttributeTableMapLayerAction,
>> that adds exactly this functionality around QgsMapLayerAction.
> Hmm... it is a little strange, and I can't recall exactly why it
> inherits from QAction.
> I think it was something planned for the future but not implemented at
> the time. Anyway,
> I'm in favour of your proposal.
I had a look and did some experiments, but it turned out that it is a
bit too much for me at the moment.

A short summary. We have now the following classes (that I found)

Custom Actions:
Map Layer Actions:
 * QgsMapLayerAction
 * QgsMapLayerActionRegistry
 * QgsAttributeTableMapLayerAction (QAction)
 
 * QgsAction (A custom action)
 * QgsAttributeAction (Pendant to QgsMapLayerActionRegistry -- don't
trust it's name it's not a single action)
 * QgsAttributeTableAction (QAction)

One problem with creating a QAction for both is ownership and
identification.
When used for a context menu, that is not a problem. It's really short
living, in this time nobody is going to change the actions. However, if
you build a menu for e.g. an attribute dialog, it will be there for
longer and in that time, somebody can remove actions while the menu is
shown. As the actions are not copy-able they will then just have
disappeared.
In the case of QgsAttributeAction, these are triggered by an ID, which
is its place in the list of actions. If you remove one, all subsequent
IDs will change.

A QAction is not copyable and should be owned by the menu it resides in.
Therefore the registries should instead of managing QActions rather be
managing action templates, from which it's possible to generate a
QAction. The generated QAction should then either contain all
information required to run the action (a copy of the template) or be
able to tell, when underlying information has changed (action deleted,
id changed)...

It's not so easy (but maybe possible) to fix all this while keeping the
API stable.
> It all sounds good to me! I'm just happy to see MapLayerActions used
> more extensively
> and get a bit more publicity.
I gave it some more :)
http://gis.stackexchange.com/questions/109302/qgis-2-2-possible-to-do-a-joins-from-the-action-list/110268#110268

Matthias