Thanks for the pointer Allister, 
I think a good compromise could be what you suggest in your ticket, very close from Mapinfo's ergonomy:

- have a button in a toolbar (next to tooltip one for example) that can enable mask for Mapcanvas
  - if polygons are selected in active layer, they are taken to generate mask
  - if no polygon selected , a msgBox recalls how to use it. 
  - if a mask is already activated, pushing the button unactivate it
  - if a mask is already activated AND active layer has polygon selected, a dialog asks if user wants to deactivate current mask or create a new one based on current selection. This way, we avoid having two buttons as in Mapinfo, which was not very easy to understand at start. 

- In composer, each map could have a new property "activate Mask for that map". We solve then one of the bigger problems

- Mask behaviour with labels must be discussed by dev's. I see to possibilities:
   1. My prefered one (slow option in Mapinfo): layers with labeling activated are clipped with mask geom, and then resulting geom is used for labeling. none labeled layers are drawn before mask, so that they can be hidden, or seen semi-transparent below mask.  Can be slow when clipping objects if geom are big. We should maybe have some progress bar or warning to explain this can be a slow feature depending on complexity of concerned geoms. Good point, we only add  features, without changing labeling and drawing engine

  2. A workaround, that avoid necessity of clipping geometries, but looses ability to generate correctly labels (fast option in Mapinfo) : Mapcanvas is drawn, and then Mask is drawn afterwards. Certainly slower, but I remember users really barking against those limitations. 


- Mask options should be stored in project file. We could have options to define default mask style in general options.  Storing Mask Object is more tricky. Will we start putting potentially big WKTs objects inside qgs? Again, two options :
  1. We don't change qgs structure. We use memory or plugin layers capacities, and save it serializing into a QDataStream along with the project just like Memory Layer Saver does. (my prefered option, since we can do that in 2.0 or 2.1 roadmap)
  2. We wait for qgs refactoring, if it happens, and store then geometries following what will be chosen by core developpers (sqlite /  qtdatastream...). I guess, that could be long. Why not start with previous implementation and then switch to second if one day qgs is refactored. 

I would really be glad to achieve a consensus on it. I could then fund something. 

All the best
Régis

- 


        
        
        
<br/><hr align="left" width="300" />
View this message in context: <a href="http://osgeo-org.1560.n6.nabble.com/Let-s-discuss-on-a-Mask-feature-tp5021391p5021612.html">Re: Let's discuss on a Mask feature</a><br/>
Sent from the <a href="http://osgeo-org.1560.n6.nabble.com/Quantum-GIS-User-f4125267.html">Quantum GIS - User mailing list archive</a> at Nabble.com.<br/>