Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apply custom logic to feature click #5911

Open
woutergd opened this issue Dec 23, 2024 · 2 comments
Open

Apply custom logic to feature click #5911

woutergd opened this issue Dec 23, 2024 · 2 comments

Comments

@woutergd
Copy link
Contributor

Hi all,

Just a question. We are working on a plugin, and want to apply some custom logic after a feature has been clicked in a vector layer, instead of showing the regular featurelist / attribute list.

Based on what I found in the code was my idea to set the layer itself as not-identifyable within the QGis-project to disable the default behaviour for a layer, and then manually pass the click-event through the Identifytool (or some kind of similar logic) to retrieve the feature that is clicked on.

However, I tried to capture both events within the identifytool and the mapcanvas, but I don't seem to get any response.

Can anyone point me in the right direction to get this behaviour integrated in a plugin. If it require any modification in the utils or code itself just let me know where to start, then I will try to get this implemented and propose as PR.

@woutergd woutergd changed the title Plugin: Apply custom logic to feature click Apply custom logic to feature click Dec 23, 2024
@nirvn
Copy link
Member

nirvn commented Dec 30, 2024

@woutergd , that's not something available ATM, but I can definitively see it being super useful for plugin authors. I imagine a system whereas we can register a listener against a tap listeners bank, and conditionally take ownership of the tap, preventing default identify behavior.

Feel most invited to open a PR, and ask questions along the way.

BTW, we very much appreciate these enhancement requests being opened before PRs, it allows for a discussion that can ultimately avoid wasted energy :)

@woutergd
Copy link
Contributor Author

woutergd commented Jan 3, 2025

@nirvn thanks for your input, we will start to implement this.

My idea was to start at an intercept on the IdentityTool, so we can intercept it with the features already detected. Does that fit your idea, or is a more basic integration with the taplistener itself more in line with the plugin framework of QField?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants