Sounds good to me. On 11/15/2016 11:34 AM, Even Rouault wrote:
> One effect of this change is that there wouldn't be anymore a tri-state for a > group. It is either checked or unchecked. The visualisation could still be tri-state, I think * Unchecked * Checked (All subitems checked) * Semi-checked (Checked but some sub-items are invisible) Clicking would then switch between either Unchecked and Semi-Checked or Unchecked and Checked depending on the subitems. > One potential downside of the new > behaviour would be that it might not be immediately obvious to determine the > visibility of a layer if you have several levels of hiearchy : looking only > at > the layer item if it is checked isn't sufficient to tell about its > visibility. > Not sure if that's an issue though (and if so what could be ways of > indicating > the visibility state) > > At the API level, from what I can see, > * Qt::CheckState QgsLayerTreeGroup::isVisible() would be renamed to bool > isChecked() since it would be a binary state and not related to visibility. > I'm not sure if there are users outside of the layer tree mechanism where we > really need to want if a group is visible (ie all its subgroups and layers > are > visible ?). Wouldn't be hard to implement anyway > * Qt::CheckState QgsLayerTreeLayer::isVisible() would be "split" into a bool > isChecked() and a bool isVisible(). The later would inspect recursively its > parents to figure out the final visibility state. The approach sounds good. What do you think about integrating on both levels (group and layer) the methods isVisible() and itemVisibilityChecked() methods? I think this API is more verbose than a simple isChecked(). Matthias _______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
