https://github.com/wxWidgets/wxWidgets/pull/24600
(1 file)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
@vadz commented on this pull request.
Thanks for the fixes, I think the logic is correct here, but if we could store the items in, say, wxQTreeWidget
, as member variables, it would be better IMHO.
> +static wxTreeItemId gs_currentItem; +static wxTreeItemId gs_previousItem;
Do these really need to be global? I am not 100% sure it's not going to be a problem, e.g. if a handler of some event changes selection in some other tree control.
> @@ -125,6 +125,61 @@ class ImageState Q_DECLARE_METATYPE(TreeItemDataQt) +// We use a custom selection model because we need to generate the +// wxEVT_TREE_SEL_CHANGED event only if it is allowed. that is, only
Nitpick of the day:
⬇️ Suggested change-// wxEVT_TREE_SEL_CHANGED event only if it is allowed. that is, only +// wxEVT_TREE_SEL_CHANGED event only if it is allowed, that is, only
(alternatively, keep the period, but capitalize "That")
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
@AliKet pushed 1 commit.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
@AliKet commented on this pull request.
> @@ -125,6 +125,61 @@ class ImageState Q_DECLARE_METATYPE(TreeItemDataQt) +// We use a custom selection model because we need to generate the +// wxEVT_TREE_SEL_CHANGED event only if it is allowed. that is, only
forgot to update this
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
@dsa-t It would be really apreciated if you could test this PR (or this patch) before it get merged because I had to change the implementation a little due to problems encountered with wxTreeBook
control with the previous version.
TIA.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Oops! this version reintroduced the infinite loop reported by @dsa-t which can be seen with the notebook sample (File -> Type -> Treebook)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
This is really strange because the treectrl sample works correctly but the notebook (treebook page) does not! maybe the problem is in the wxTreeBook
control !?
Needs more debugging...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
@AliKet pushed 1 commit.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
@AliKet pushed 1 commit.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
This is really strange because the treectrl sample works correctly but the notebook (treebook page) does not! maybe the problem is in the
wxTreeBook
control !?Needs more debugging...
Everything seems to work correctly now: the treectrl and notebook (wxTreebook) samples.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Works good generally, but I also see a small issue with multiple selections:
wxTR_MULTIPLE
mode, select File child 1.1
to File child 1.5
File child 1.2
OnSelChanged
, GetSelections
will say "File child 1.1""File child 1.2""File child 1.3""File child 1.4""File child 1.5"—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Works good generally, but I also see a small issue with multiple selections in
treetest
:
- In
wxTR_MULTIPLE
mode, selectFile child 1.1
toFile child 1.5
- Then, select, for example,
File child 1.2
- Inside
OnSelChanged
,GetSelections
will say "File child 1.1""File child 1.2""File child 1.3""File child 1.4""File child 1.5"
Also the name editor gets triggered (I don't think it should).
Thanks for testing, but it works correctly for me!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Thanks for testing, but it works correctly for me!
In the 2nd step, I mean select just the 1.2 item, not deselect it:
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Thanks for testing, but it works correctly for me!
In the 2nd step, I mean select just the 1.2 item, not deselect it:
Indeed, I can reproduce the problem. And the fix is simple which I'll push soon.
but preventing the editor from being triggered is trickier because this is how Qt interpret SelectedClicked
flag passed here https://github.com/wxWidgets/wxWidgets/blob/f8043a62f3319719cbd3a400ea454e4dbb3d23ff/src/qt/treectrl.cpp#L1311-L1315
i.e. It starts editing when clicking on an already selected item
See Qt docs https://doc.qt.io/qt-6/qabstractitemview.html#EditTrigger-enum:~:text=QAbstractItemView%3A%3ASelectedClicked
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
@AliKet pushed 1 commit.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
@dsa-t this patch:
diff --git a/src/qt/treectrl.cpp b/src/qt/treectrl.cpp index ea68681ae0..45be7b0c48 100644 --- a/src/qt/treectrl.cpp +++ b/src/qt/treectrl.cpp @@ -330,11 +330,31 @@ protected: } } + // For compatibility with MSW, selecting an item that is part of a multiple selection + // simply deselects the other items without triggering the edit mode on the item. This + // is not the case with Qt because we already tell it to start editing when clicking + // on an already selected item with setEditTriggers(QTreeWidget::SelectedClicked) call. + bool m_blockEditing = false; + + void selectionChanged(const QItemSelection& selected, + const QItemSelection& deselected) override + { + m_blockEditing = selected.size() == 0; + + QTreeView::selectionChanged(selected, deselected); + } + bool edit(const QModelIndex &index, EditTrigger trigger, QEvent *event) override { // AllEditTriggers means that editor is about to open, not waiting for double click if (trigger == AllEditTriggers) { + if ( m_blockEditing ) + { + m_blockEditing = false; + return false; + } + // Allow event handlers to veto opening the editor wxTreeEvent wx_event( wxEVT_TREE_BEGIN_LABEL_EDIT,
solves the problem with starting edit you mention, but I'm still not sure if we should apply it or not because wxGTK3 also start editing if you do the following:
File child 1.1
Ctrl
key down and select File child 1.2
File child 1.1
and File child 1.2
)File child 1.2
with or without holding the Ctrl
key down.Notice that this happens only if you select the focused item. wxMSW
doesn't behave like this. i.e. it doesn't start editing at all.
@vadz any thoughts about this ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
I think wxGTK (i.e. generic implementation) is wrong here, this doesn't seem like a useful behaviour to me.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
@AliKet pushed 6 commits.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
@AliKet pushed 11 commits.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
@AliKet pushed 1 commit.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
@AliKet pushed 1 commit.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
@vadz I have no idea what's going on here, or what to do with these failures?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
I'm afraid that at least the Mac failures are real ones, i.e. actually due to the changes here as they seem to be occurring in the affected code. For the MSW ones I'm less sure and I don't have time to debug this right now, sorry...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
@AliKet pushed 1 commit.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
@AliKet pushed 1 commit.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
@AliKet pushed 1 commit.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
@AliKet pushed 3 commits.
You are receiving this because you are subscribed to this thread.
@AliKet pushed 6 commits.
You are receiving this because you are subscribed to this thread.
@AliKet pushed 10 commits.
You are receiving this because you are subscribed to this thread.