New filtering system

For the record: I’m not against inheritance, or even using inheritance by default. I use it in plenty of situations, since it essentially lets you assign tags (and other properites) “in bulk.”

But there are just as many situations where I want exact matches. Especially for filters that employ negation or booleans, it can be very hard to achieve predictable results. Simple example: PARENT = plain and its CHILD = Task. If I filter to hide Tasks, I see just the Parent. The child doesn’t inherit the mutually-contradictory non-task-ness of its Parent. So inheritance apparently is overriden by the child’s property. I particularly hate this behavior because the parent is shown without the ‘expander’ caret. So it is either hard (if bold parents is ON) – or impossible – to tell that it’s a Parent at all. I can’t figure out any reason to actually want this outcome.

How does this work with priorities, where the different options have a ‘hierarchy’? Example:
Priorities (multiple, ranked states): If PARENT = pri1 and its CHILD = pri2. Child gets filtered as if it is both pri1 and pri2 at the same time. You can’t, actually, do anything to hide either the parent or the child whether you use pri1, pri2, -pri1, or -pri2 filters.

Jerud Are you talking about the date filter icon that used to be under “contains”? I don’t see it after I just updated a couple of minutes ago (Update 1641415995942), but I swear it was there for a short while when I updated this morning (Update 1641351385129). I was playing around with it thinking “Oh, this is what Jerud was asking for!”

Did @Jay do something by mistake in the latest update to remove the “has:date” (or whatever it’s exact wording is) icon in the basic search?

Really appreciate the auto-expand on all filters, however it is doing so for most but not all matching items. Can’t figure out why but will look for a pattern to try to reproduce.

webalstrom I’ve checked for it after each update pushed to me, although I might have got a double-update at one point. I haven’t seen it reappear yet. Perhaps it’s due to the shift from “HAS:date” to “DATE:any”. They’re functionally identical, just organized/phrased differently…

Thanks for all this work!

Jay I’m fine with “collapse matches of filters” as a general setting. Being unable to differentiate a collapsed parent with no matching children from a leaf item is still problematic (regardless of this change). What do you think about showing the ‘ >’ but when user expands the parent they see a message under it: “none of these child items match the current filter.”

The date:any button is back for me. Will have to test the other bugs in a day or so; I need to work away from the computer for a while.

Jay I think global setting makes sense.

The auto-expand/collapse is working nicely with text matches. It doesn’t seem to be reliably expanding or collapsing for some other filters like star button, priority (in simple or advanced mode). Will have to experiment more with it later.

BUG: I’m seeing completes shown in hide-completes Panes. They are children of a mirror which is, itself, not complete. Have not observed this with non-mirror items

At least, I think it’s a mirror. It has an always-visible tally box, but the item text draws as a [[Link and appears inside [[braces]] in the breadcrumbs. It’s an old item but I’m pretty sure it was a mirror that ‘degraded’ to a link, as they do.

BUG (?); Can’t specify sort-order in the Pane Configuration dialog for “group-by” Panes. The up/down sort-order arrow is not shown. The arrows for the next column over (Item sort-order) are still available.
Obviously not filter-related, but seems to have broken due to the most recent round of updates.

Or am I imagining it? I swear this used to be there.

My previous post on this thread brings up a separate issue… one of the benefits of the old filter panel is that it never obscured the results. With this new bigger panel and a very narrow pane (which all of my panes are), it does. Mostly an issue when using it as a filtered search, where you are looking for an item that appears at the top of the pane. That’s why I would be pressing ESC before typing the text.

One thought is to have a filter icon button (such as a funnel icon) to toggle the filter panel rather than showing it when clicking in the filter text input. Then you could also use it to hide the filter panel, and you could type in the filter text input without having to close the panel first.

Another idea is to shrink the filter panel so it doesn’t obscure the first item(s) in a narrow pane.

Pressing ESC before typing is a reasonable workaround as far as entering filter text (would be nice to have an x to close the filter panel as well). Just wondering if anyone else has a preference for how this should work.

BUG: It seems that the text filter is not matching on items with a note, unless the note itself matches the text filter.

Jay I just realized that this is really only problematic when I’ve got a narrrow pane that is the rightmost pane on a board that has several panes, so that it ends up being right aligned with the pane’s right edge, and I can usually widen that pane. So that’s much less significant of an issue.

That said, I do think you could consider using smaller icons/buttons, as even shrinking the width just a bit would help.

You could also make the panel maximum width dynamic as a percentage of the pane width and wrap the buttons if necessary, so it would only do so with a narrow pane. You might only do that where the filter panel is right aligned with the pane. If you ever add more CONTAINS buttons and it starts getting even wider, this would accomodate that.

In any case, it’s less of an issue than I originally thought.

Regarding auto-expanding the Overview, I think this has been discussed before but I think it becomes more noticeable when auto-expanding on any filter change…. since the Overview is not filtered, I don’t think it makes sense to auto-expand the Overview to match the expansion of the outline with a filter change. It ends up containing many entries that don’t match the filter. If the Overview were filtered (a separate debate!), it might make more sense to auto-expand it, but that is not the case.