[Qt-interest] QAbstractItemView and tri state check boxes

Atlant Schmidt aschmidt at dekaresearch.com
Thu Jun 2 17:15:40 CEST 2011


Scott, et al.:

  Ahh, here's an example for you, courtesy of:

    http://guijournal.com/2011/05/gui-design-tri-state-checkboxes/


  Go to the Windows property box for any folder. If your folder contains
  a mix of read-only and read-write files, the [ ] Read-only chechbox will
  cycle among the three states of Partially-Checked, Unchecked, and
  Checked.

  Of course, this is also an easy implementation because it follows
  the second implementation method that I suggested: Don't roll-
  out the changes to the inferior nodes until the user stops modifying
  the checkbox. In this case, that action is easy to spot because it
  occurs when the user presses the "OK" button on the Properties
  dialog box.

                                   Atlant

________________________________
From: Scott Aron Bloom [mailto:Scott.Bloom at onshorecs.com]
Sent: Thursday, June 02, 2011 10:54
To: Graham Labdon; Atlant Schmidt; Qt-interest at qt.nokia.com
Subject: RE: [Qt-interest] QAbstractItemView and tri state check boxes

Having implemented this exact functionality, I did quite a bit of research into what "other tools do"

I could not find one tool, (not saying they don't exist, but I couldn't find them) that went partial checked -> checked -> unchecked -> partial checked...

All the tools I found (about 4-5 of them, none of them Qt based) went partial checked -> checked ->unchecked ->checked etc

To implement, it all comes down to the model.  If you are using the pre-canned standard item model, derive from it, overload the data and setData methods.

For setData override when role == CHeckStateRole

Value will be Qt::Checked or not Recursively set the child values.. (using QStandardItem::setCheckState or your custom method)

Then make sure to call dataChanged on each child AND each parent

For QStandardItemModel you need to override data for the role CheckStateRole, since setCheckState DOESN'T do recursive (and isn't virtual L)

Depending on your model, its not too hard to do..

Scott

From: qt-interest-bounces+scott.bloom=onshorecs.com at qt.nokia.com [mailto:qt-interest-bounces+scott.bloom=onshorecs.com at qt.nokia.com] On Behalf Of Graham Labdon
Sent: Thursday, June 02, 2011 6:57 AM
To: Atlant Schmidt; Qt-interest at qt.nokia.com
Subject: Re: [Qt-interest] QAbstractItemView and tri state check boxes

Thanks - that's a lot to think about!!

From: Atlant Schmidt [mailto:aschmidt at dekaresearch.com]
Sent: 02 June 2011 14:51
To: Graham Labdon; Qt-interest at qt.nokia.com
Subject: RE: QAbstractItemView and tri state check boxes

Graham:

  I'm a little unclear on your question so let me "think out loud"
  and discuss this in a general fashion...

  For each node on the tree, it can present its checkbox in any
  of two or three states:

    o Unchecked if all of its decendents' checkboxes are
       unchecked.
    o Checked if all of its decendents' checkboxes are
       checked.
    o Partially checked for any other condition (never happens
       for leaf nodes).


  Clicking the checkbox of any node in the tree to the checked state
  causes its checkbox to become checked and also conceptually
  asserts the checkbox of any child nodes. (These children can, in
  turn, propagate the action to their children and so on...)

  Clicking the checkbox of any node in the tree to the unchecked state
  causes its checkbox to become unchecked and also conceptually
  deasserts the checkbox of any child nodes. . (These children can,
  in turn, propagate the action to their children and so on...)

  But a nice, very-typical additional feature is to allow the user to cycle
  back to the "Partially-Checked" state without having seemed to actually
  affect any of the child nodes. This is the tricky part, requiring that
  something somewhere either:

     o Save the state of the entire tree below the affected node
        so that it can be restored each time the user steps back
        to the "Partially-Checked" state.

        (This must happen recursively with each descendent
        because each descendent that has children may also
        itself be in the "Partially-Checked" state. Signals and
        Slots might be the mechanism here or just ordinary
        calls to methods in the inferior nodes.)

   *OR*

     o Postpone the action associated with this checkbox until
        the user performs some other action unrelated to this
        checkbox. At that point, all of the descendent checkboxes
        are affected as necessary.

        (This seems difficult to me as it's difficult to determine the
        correct moment to "play out" all of the stored effects onto
        the descendents. Your interface may be simple enough to
        take this approach, though.)

    *OR*

     o You carefully craft the action that finally evaluates and uses
        the state of the checkboxes so that it walks the tree as necessary
        and ignores the state of those descendent checkboxes that are
        over-ridden by a "superior" checkbox that is not in the "Partially-
        Clicked" state.

        This same "over-riding action" takes place each time an inferior
        checkbox is initially displayed for the user. Changing an inferior
        checkbox away from the over-ridden state has effects that
        propagate up the tree to the highest node that is calling for
        an override (since they now must become merely "Partially-
        Checked" and no longer provide the over-ride) and then back
       down the tree to the nodes that were over-ridden but are no
        longer (since they should probably take on the state that was
        being forced onto them by the over-ride, but this part of it can
        be your design decision).

        (To me, this feels like probably the best way to approach this
        problem as it never requires any special "state" to be kept
        around. All leaf checkboxes only contain their "Checked/
        Unchecked" state and all non-leaf checkboxes only contain
        their "Checked/Unchecked/Partially-checked" state and all
        of the special effects are created by evaluating the tree with
        each display or click of a checkbox or when the checkbox
        data is actually used to affect operation.)

                                                 Atlant

________________________________
From: qt-interest-bounces+aschmidt=dekaresearch.com at qt.nokia.com [mailto:qt-interest-bounces+aschmidt=dekaresearch.com at qt.nokia.com] On Behalf Of Graham Labdon
Sent: Thursday, June 02, 2011 06:55
To: Qt-interest at qt.nokia.com
Subject: [Qt-interest] QAbstractItemView and tri state check boxes

Hello
I have a model/view that allowed me to display a check box for each item in my tree and allowed the user to check or uncheck the item.
What I want, however, is that if an item has subitems and these are not all checked then the parent should be partially checked, if they are all checked the parent should be checked and if none are checked then the parent should be unchecked. This should of course be applied to the whole tree.
I am struggling to implement this and would be grateful if anyone has any suggestions on how I can achieve this

Thanks

Graham


Click here<https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg==> to report this email as spam.

________________________________
This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.

________________________________
This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110602/55928197/attachment.html 


More information about the Qt-interest-old mailing list