Add objects filter to the objects dock #1566

thabetx · 2017-05-10T13:05:01Z

Fixes #1467 .

The filter text box supports two shortcuts

Escape clears the filter.
Return focuses the first filtered item, pressing return while an object is focused still changes the focus to the properties dock.

Also each map has its own search string so switching between maps will change the filter.

All columns are matched (name, type, id, position) even if they are hidden. Group names are not matched.

Not entirely sure about the above decisions so would like some feedback regarding them.

Some stuff that are still missing

Expanded groups that didn't match will collapse after clearing the search, I'm still looking into it.
Matching custom properties.

selecting directly from the map doesn't update the dock

Don't show empty layers that matches the filter

thabetx · 2017-05-12T17:35:39Z

Now, any group having a matching object will be expanded while filtering, so the above the GIF is not very accurate.

I also updated the behavior of the return key to just focus the tree instead of focusing the first item.

I will fix expanding pre-filter expanded groups that didn't match.

bjorn

Hey @thabetx, I've tried it out and I really like it! It's nice that you remember the search string for each map as well as automatically expanding after filtering and restoring the user's expanded groups afterwards. I also like the handling of Return and Escape keys.

On the code side I had some requests, let me know how you feel about them!

src/tiled/objectsdock.cpp

bjorn · 2017-05-15T09:29:51Z

src/tiled/objectsdock.cpp

+
+    mObjectsView->objectsFilterModel()->setFilterFixedString(mFilterEdit->text());
+
+    if(mFilterEdit->text().isEmpty()) { // Resotre the prefilter expansion state


Coding style: please put a space after if (also fix other three cases)

Typo: Resotre

bjorn · 2017-05-15T09:39:33Z

src/tiled/objectsdock.cpp

+{
+    // Save the prefilter expansion state if this is the first applied filter
+    if(mFilterWasEmpty[mMapDocument]) {
+        mFilterWasEmpty[mMapDocument] = false;


Could we check the state of the model instead? I think mObjectsView->objectsFilterModel()->filterRegExp().isEmpty() should work.

I tried doing that but couldn't get it to work properly.

The filter is shared between documents, so suppose we switched from a non-filtered map to a filtered map, the above condition will be satisfied and the state of the new map will be saved overwriting the original saved state, I couldn't figure a clean way to prevent this from happening.

I changed the mFilterWasEmpty map to a single bool variable and got it work properly but had to introduce a small hack for this particular case.

Ah, makes sense, thanks for the explanation!

bjorn · 2017-05-15T09:54:59Z

src/tiled/objectsdock.cpp

@@ -317,7 +372,7 @@ MapObjectModel *ObjectsView::mapObjectModel() const

 void ObjectsView::onPressed(const QModelIndex &proxyIndex)
 {
-    const QModelIndex index = mProxyModel->mapToSource(proxyIndex);
+    const QModelIndex index = mObjectsFilterModel->mapToSource(proxyIndex);


While this seems to work, it is missing a translation step. The returned index is an index into the mProxyModel, which is the source model for mObjectsFilterModel. So this should be:

const QModelIndex index = mProxyModel->mapToSource(mObjectsFilterModel->mapToSource(proxyIndex));

There are more functions below missing this.

Since there are a lot of places where you have to make this double translation, I would suggest to introduce two helper functions, for example mapFromViewModel and mapToViewModel. Also, since there are two proxies now, a variable like proxyIndex should probably be renamed to viewIndex for clarity.

bjorn · 2017-05-15T10:11:54Z

src/tiled/objectsdock.cpp

+    QModelIndex index = sourceModel()->index(sourceRow, 0, sourceParent);
+
+    // sourceParent of a group has no model
+    if(!sourceParent.model())


This is a somewhat interesting and not entirely correct check. There is no model, because the parent index is invalid, so a more sensible check may be if (!sourceParent.isValid()). However, either check won't work since layers now form a hierarchy and an object layer within a group layer will have a valid parent, which would lead those object layers to be filtered as if they were an object.

Of course, group layers are a problem of their own as well, since whether they should be filtered or not would depend on whether any of their child layers are object groups that contain any non-filtered objects.

Fortunately, we know we're dealing with a MapObjectModel and I would suggest working through its interface directly instead of requesting data through Qt::DisplayRole. That way, you can use toGroupLayer, toObjectGroup and toMapObject. And to avoid having to convert between ReversingProxyModel indexes here, I would change the order in which the two proxies are applied so that the filtering happens before the reversing.

I agree on working directly with the objects, I think it will be better(using toMapObject), I will try doing that and will refactor the proxies code.

bjorn · 2017-05-15T10:17:57Z

src/tiled/objectsdock.cpp

+{
+    for (int i = 0; i < sourceModel()->rowCount(index); ++i) {
+        QModelIndex childIndex = sourceModel()->index(i, 0, index);
+        if (childIndex.isValid() && objectContainsFilterString(childIndex))


The childIndex.isValid() should not be necessary since you're only requesting data from valid indexes.

bjorn · 2017-05-15T10:18:38Z

src/tiled/objectsdock.cpp

+    for (int i = 0; i < sourceModel()->columnCount(index); ++i) {
+        QModelIndex objectIndex = sourceModel()->index(index.row(), i, index.parent());
+        QString type = sourceModel()->data(objectIndex, Qt::DisplayRole).toString();
+        if (type.contains(filterRegExp()))


"type" is a confusing variable name here.

bjorn · 2017-05-15T10:21:56Z

src/tiled/objectsdock.h

    QMenu *mMoveToMenu;
+    QModelIndex getGroupIndex(ObjectGroup *og);


Would be called groupIndex according to naming style, but I think it should instead be a convenience override to the previously suggested mapToViewModel helper function. Should be marked const.

I'm not sure what you mean by convenience override.

But here is what I did so far, I moved the getGroupIndex function from the objects dock to the objects view (it uses mapToViewModel for conversion), then made it private and made public helper functions in the objects view(isGroupExpanded, setGroupExpanded), so that the objectsDock can use them without worrying about the conversion.

bjorn · 2017-05-15T10:22:39Z

src/tiled/objectsdock.h

+    Q_OBJECT
+
+public:
+    ObjectsFilterModel(QObject *parent = 0);


Please use nullptr instead of 0.

bjorn · 2017-05-15T10:22:58Z

src/tiled/objectsdock.h

+
+private :
+    bool groupHasAnyMatchingObjects(const QModelIndex index) const;
+    bool objectContainsFilterString(const QModelIndex index) const;


Arguments are missing a &.

thabetx · 2017-05-15T11:32:15Z

Alright, thank you for the review, I will be updating the pull request.

I've a question though, suppose we have an expanded group, then we applied a filter and one of the objects of this group matched the search, then we collapsed this group, when cancelling the search it is restored to the initial state(expanded) although we just collapsed it, is this behavior expected?

I saw one application (gitkraken) that prevented changing the expansion state of any group while a filter is applied, this will solve this case but is kind of restrictive, what do you think?

bjorn · 2017-05-15T12:03:58Z

I've a question though, suppose we have an expanded group, then we applied a filter and one of the objects of this group matched the search, then we collapsed this group, when cancelling the search it is restored to the initial state(expanded) although we just collapsed it, is this behavior expected?

I guess it could be helpful to keep it collapsed given the user's disinterest in this group. So instead of collapsing everything and restoring from mPrefilterExpandedGroups, you could instead just collapse any group that isn't in it that list.

I saw one application (gitkraken) that prevented changing the expansion state of any group while a filter is applied, this will solve this case but is kind of restrictive, what do you think?

I agree that this is too restrictive.

Btw, it occurred to me that for expanding the tree when the search filter is changed you should just call mObjectsView->expandAll(). The current method of expanding all object groups won't work in case of group layers.

bjorn · 2017-05-15T12:06:44Z

Actually on second thought, it occurred to me that allowing the user to collapse the tree is not very useful when on any typed character we will automatically expand the whole thing again. So maybe disabling itemsExpandable on the view while a filter is active isn't a bad idea after all...

thabetx · 2017-05-15T12:14:46Z

Ok I will test disabling collapsing. This might also simplify the code as mExpandedGroups and mPrefilterExpandedGroups can be merged into one in that case again.

Filter then reverse

thabetx · 2017-05-18T11:01:51Z

Hey @bjorn, thank you for the great review, I've addressed the requests, the small notes were also helpful.

Filtering now works directly on the objects, this made the filtering code simpler and I think it will make filtering by custom properties possible. Right now the filter works on name, type and ID, I don't check the position, I think it's not useful but not sure.

I would like to receive some usability reviews, I think the behavior of the filtering can be improved.

thabetx · 2017-05-19T22:48:17Z

Things don't work properly when moving objects up and down, will investigate it.

thabetx · 2017-05-20T18:31:26Z

For some reason reversing the proxy models stopped deleting the objects or moving them up an down from working, I tried restoring it to the previous order and the functions worked fine. This will require adding the missing translation step when filtering, although it works without it.

I thought of introducing two extra QAbsractProxyModel pointers that point to the two proxies, called mFrontEndProxyModel and mBackEndProxyModel, I think this makes the code more readable and changing the order of the proxies is just a matter of changing what those pointers point to, I'm not sure if this is a good practice though.

Another thing to notice when moving objects up and down is that the order of the objects is the same as when the objects are not filtered, so moving-up an object while filtering might not visually move it up in the view because there might be objects above that are hidden, I think this is expected from the code, but don't know what to do about it.

bjorn · 2017-05-20T19:08:40Z

I would like to receive some usability reviews, I think the behavior of the filtering can be improved.

Can you elaborate a bit about this?

Things don't work properly when moving objects up and down, will investigate it.

I'll have a look at this as well. Sounds like an annoying thing to debug... Of course the order of the proxy models shouldn't matter at all. :-/

I thought of introducing two extra QAbsractProxyModel pointers that point to the two proxies, called mFrontEndProxyModel and mBackEndProxyModel, I think this makes the code more readable and changing the order of the proxies is just a matter of changing what those pointers point to, I'm not sure if this is a good practice though.

I prefer the more explicit names.

Another thing to notice when moving objects up and down is that the order of the objects is the same as when the objects are not filtered, so moving-up an object while filtering might not visually move it up in the view because there might be objects above that are hidden, I think this is expected from the code, but don't know what to do about it.

I think it is reasonable to not expect those actions to adjust to any active search filter.

thabetx · 2017-05-20T19:20:28Z

About the improvements, I thought it'd be useful to receive feedback from the community, I don't have much in mind other than keeping groups with selected objects expanded when cancelling the search, adding a shortcut to focus the search bar and currently when filtering, collapsing is disabled, but there is no indication for that, so needed some opinions about it.

The logic was wrong when more than one row was getting inserted.

bjorn · 2019-07-17T11:29:12Z

Ohoh, those conflicts in objectsdock.cpp are looking quite severe...

bjorn · 2019-07-17T15:50:45Z

After fixing the issue with the ReversingProxyModel by basing it on the QSortFilterProxyModel in change e248604, I decided to reimplement this change instead of trying to resolve the conflicts.

My patch does not remember a search filter for each document, but I'm anyway not sure what is the better behavior and it was easier to leave that functionality out for now.

thabetx added 14 commits May 7, 2017 12:44

Add the line edit

bd138a3

New filter

9b2c9a5

Initial working version

59d44b4

selecting directly from the map doesn't update the dock

Fix object selection from map

a821e3d

Fix saving and restoring expanded groups

eb8e1ae

Make the models private

afaf337

Fix style

6d42d49

Update filtering logic

0553dbb

Don't show empty layers that matches the filter

Add keyboard shortcuts to the objects dock

2ffaefd

Fix style

eeb0dd7

Save filter string between maps

e72855d

Refactoring

6ebcdf9

Use returnPressed signal instead of handling return key

a46173b

Expand groups having matching objects

6b522ae

thabetx added 2 commits May 13, 2017 11:10

Restore the prefilter expansion state when filter is canceled

4dc0fdb

Fix style

e425e53

bjorn self-requested a review May 15, 2017 10:26

bjorn requested changes May 15, 2017

View reviewed changes

thabetx added 7 commits May 16, 2017 08:05

Use Filter string from TileStampsDock

12eaea7

Refactor the switching code

5f6f1df

Prevent collapsing while filtering

184bff3

Fix spaces

d302c97

Use nullptr instead of 0 for initializing ObjectsFilterModel

3c0a470

Rename mProxyModel to mReversingProxyModel

9a51d46

Reverse the order of the proxy models

e4f3b46

Filter then reverse

thabetx added 6 commits May 18, 2017 00:13

Rename proxyIndex to viewIndex

5a59bd7

Create mapToViewModel function

fd400ad

Refactor getGroupIndex code

1ad9ef2

Merge remote-tracking branch 'upstream/master' into new-filter

a440d16

Filter using objects instead of indices

b62505e

Rename getGroupIndex to groupIndex

04cbe51

Fixed the logic in ReversingProxyModel::sourceRowsAboutToBeInserted

7bdad99

The logic was wrong when more than one row was getting inserted.

bjorn mentioned this pull request Jul 17, 2019

Feature request: Find object/layer #2162

Closed

bjorn closed this in 7fd47c5 Jul 17, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add objects filter to the objects dock #1566

Add objects filter to the objects dock #1566

thabetx commented May 10, 2017

thabetx commented May 12, 2017

bjorn left a comment

bjorn May 15, 2017

bjorn May 15, 2017

thabetx May 16, 2017

bjorn May 16, 2017

bjorn May 15, 2017

bjorn May 15, 2017

thabetx May 17, 2017

bjorn May 15, 2017

bjorn May 15, 2017

bjorn May 15, 2017

thabetx May 18, 2017

bjorn May 15, 2017

bjorn May 15, 2017

thabetx commented May 15, 2017

bjorn commented May 15, 2017

bjorn commented May 15, 2017

thabetx commented May 15, 2017

thabetx commented May 18, 2017 •

edited

thabetx commented May 19, 2017

thabetx commented May 20, 2017

bjorn commented May 20, 2017

thabetx commented May 20, 2017

bjorn commented Jul 17, 2019

bjorn commented Jul 17, 2019


		mObjectsView->objectsFilterModel()->setFilterFixedString(mFilterEdit->text());

		if(mFilterEdit->text().isEmpty()) { // Resotre the prefilter expansion state

		QMenu *mMoveToMenu;
		QModelIndex getGroupIndex(ObjectGroup *og);

Add objects filter to the objects dock #1566

Add objects filter to the objects dock #1566

Conversation

thabetx commented May 10, 2017

thabetx commented May 12, 2017

bjorn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thabetx commented May 15, 2017

bjorn commented May 15, 2017

bjorn commented May 15, 2017

thabetx commented May 15, 2017

thabetx commented May 18, 2017 • edited

thabetx commented May 19, 2017

thabetx commented May 20, 2017

bjorn commented May 20, 2017

thabetx commented May 20, 2017

bjorn commented Jul 17, 2019

bjorn commented Jul 17, 2019

thabetx commented May 18, 2017 •

edited