View Single Post
Old 11-07-2022, 02:11 PM   #44
chaley
Grand Sorcerer
chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.
 
Posts: 12,476
Karma: 8025702
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by un_pogaz View Post
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.
chaley is offline   Reply With Quote