Got it working now (just the app for now, have not yet looked at installing the QML plugin and using it separately) - thanks a lot! And it all really looks gorgeous!

I think can we can easily achieve both - a "signal" based area available under the right license (likely BSD/MIT in this case) can easily be used as a black box via it's API or included as a customized part of application code if needed.

Yeah - and it's not just differences, but I can imagine cases where you might want to block some of the signals outright (eq. in navigation mode, etc.). It's easy to do if it's your application code sitting between the area and the widgets, forwarding the signals or not, based on current application state.

But I guess for simpler applications (let's say a location view in a Twitter client) an all in one pre-configured element might also be welcome. It would be basically a Mapbox map view with the area on top, with signals connected to respective map view APIs in a generic way, so that pinch zoom, panning, & flicking work out of the box without the need for application side configuration. This could likely be left for later on though.

Would it be actually Mapbox specific ? If not, it might be just called MapMouseArea/MapTouchArea/MapGestureArea/MapManipulationArea/etc. And maybe people might even use it for stuff not directly related to map manipulation.