Edwin Leuven wrote:
Richard heck wrote:
I've fixed this at r24311. The bug was introduced by Edwin at r23981.
Note that this will now allow much more elaborate tooltips to be set
at various points that use the GuiIdListModel.
mm, i thought this
- if (role == Qt::DisplayRole || role == Qt::EditRole)
+ if (role == Qt::DisplayRole || role == Qt::EditRole || role ==
Qt::ToolTipRole)
was an innocuous way to get a tooltip since it only seemed to return a
string at that position.
i obviously didn't study the code well enough, sorry about that...
Not a problem. I'd have done the same thing, frankly, and only realized
what was happening after the proverbial light bulb went on in my head.
Here's the deal. In GuiSelectionManager, we want (in effect) to copy
things from the list of available whatevers (modules, say) to the list
of selected whatevers. We do this by calling GuiIdListModel::itemData to
get the available item's data, and then calling GuiIdListModel::setData,
which is just inherited, to set the new item's data. The first calls
data() to build a QMap from roles to data, and the latter calls
setData() to assign the data to the roles. So what was happening was
that the call to setData was failing, since we didn't know how to set
the ToolTipRole. Simply pretending to do so would have worked, actually,
but I figured while I was at it I'd give us some real tool tips here. If
we had something like a short description of each layout file, we could
use that.
I'll add an assertion there, so we won't get burned in the future.
Richard
