Saved Searches in toolbars & menus, including favourites

[theducks]

Originally Posted by ownedbycats

Honestly, I find it a little funny when a single line of code can cause so many things to break.

How much code have you written?
Back at my first job, I was off by 1 pin putting in a jumper, 1000 numbers went to the intercept operator: 'This number is not in service' (took the switchmen almost 1 Hr to find my goof

[Katja_hbg]

Originally Posted by ownedbycats

Built-in toolbar option. You'll need to run from source or wait for the next update.

EDIT: Here's a screenshit:

Attachment 197240

assuming that this is the build‐in «saved searches», how are you able to add folder to it?

[ownedbycats]

Originally Posted by Katja_hbg

assuming that this is the build‐in «saved searches», how are you able to add folder to it?

Go to Preferences > Look & Feel > Tag Browser > Hierarchy and searching, and select "Saved Searches."

Then create a saved search named something like foo.bar — the period is what's important. 'foo' will appear as a folder. (If you also have a 'foo' search, it'll appear as a separate entry - see the 'recently added' entries on my screnshot.)

[chaley]

Originally Posted by ownedbycats

Go to Preferences > Look & Feel > Tag Browser > Hierarchy and searching, and select "Saved Searches."

Then create a saved search named something like foo.bar — the period is what's important. 'foo' will appear as a folder.

The "improved" saved searches menu does hierarchy based on internal periods regardless of whether or not it is chosen in Tag browser hierarchy. The tag browser saved searches display does hierarchy only if it is chosen.

I am waiting for someone to complain about the inconsistency.

[Katja_hbg]

Thanks for quick reply. Now I am able to create something looking like a folder. ... But (sorry to ask) how to put/move more searches into it?

I got it. It must be same first name, as usual by hierarchy.

[ownedbycats]

If you want to add searches to a 'foo' folder you can rename them to 'foo.my search'.

EDIT: I'm slow.

[chaley]

Originally Posted by ownedbycats

(If you also have a 'foo' search, it'll appear as a separate entry - see the 'recently added' entries on my screnshot.)

Since you brought this up: I have been debating with myself this case. Given a search "foo" and a hierarchy "foo.something", where should be "foo" search go?

This is what it does today. The "foo" search is on the upper level, followed by a menu containing the "something".


Here is an example where the "foo" search goes inside the menu at the top. It has a "search" icon and is suffixed by the word "Parent" to distinguish it from a possible search "foo.foo"


And here is an example where there is no "foo" search (in this case "zzz").


I really don't know which is better. Opinions?

[ownedbycats]

That was also something I thought of (and then forgot before I made a ticket ). I like the second option - if feasible, it would look nice if it was divided from the 'subsearches' with a divider.

[Katja_hbg]

if you are interested in my opinion: none of that options.

My initial mistake was the assumption that this is a folder with content.
But in fact it is hierarchy with sub.elements.
To be in line with hierarchy like series or genres, there is no «parent» within the hierarchy structur nor is the same name allowed to be twice (single plus hierarchy).

[chaley]

Originally Posted by ownedbycats

That was also something I thought of (and then forgot before I made a ticket ). I like the second option - if feasible, it would look nice if it was divided from the 'subsearches' with a divider.

Like this?

[chaley]

Originally Posted by Katja_hbg

if you are interested in my opinion: none of that options.

My initial mistake was the assumption that this is a folder with content.
But in fact it is hierarchy with sub.elements.
To be in line with hierarchy like series or genres, there is no «parent» within the hierarchy structur nor is the same name allowed to be twice (single plus hierarchy).

I don't understand.

There is a parent in hierarchies. For foo.bar, the parent is foo. You see that in the tag browser. It isn't required that the parent actually exist as a tag/genre, but it is shown in the tag browser as if it exists.

In addition, it is legal to have the name twice, as in foo.foo. Edit: It is also legal to have a name and the same name with children. I can have the genres:

Good books
Good books.Good books
Good books.Bad books

They show in the tag browser like this:


They show in Edit metadata like this:

Good books, Good books.Bad books, Good books.Good books

And in any event, if none of the above then how would you display hierarchy?

[chaley]

Here is what the saved search menu would look like for the same saved searches as above, if I made the menu honor the hierarchy setting and then turned off hierarchy.

[un_pogaz]

Personally, I find the current behavior is very good.

I think that the "foo (parent)" requires a little gymnastics to arrange and retrieve the wanted Search, while "A Search does not overlap with a folder of the same name" is very more simple to understand and work with.

[chaley]

Originally Posted by un_pogaz

Personally, I find the current behavior is very good.

I think that the "foo (parent)" requires a little gymnastics to arrange and retrieve the wanted Search, while "A Search does not overlap with a folder of the same name" is very more simple to understand and work with.

Thanks. This well expresses the worry I have: putting the "parent" into the "child" menu introduces a semantic inconsistency, one that I tried to overcome with the word "(parent)". The current implementation avoids that by separating the search from sub-searches. There is also an issue with translations, where "parent" meaning a higher item in the hierarchy might be hard to express well and succinctly. And then there is @Katja_hbg's point (I think): that the parent/child relationship in the hierarchies isn't a graph.

On the other hand, the current implementation takes more menu space -- in effect two lines per search for searches that exist as bare and with children. This is the situation @ownedbycats is seeing.

I am leaning toward keeping it how it is, with the exception of following the "hierarchical" specification in the tag browser.

[ownedbycats]

Originally Posted by chaley

Like this?

Yes, that's what I was thinking

un_pogaz also makes good points tho