Improving the Favorites Interface Pane

[brazenvoid]

The favorites pane is very basic and rudimentary. I suggest a few changes to make it more compact and clearer:

• [ ] If possible, move the sort option and direction to the title bar instead. Those two drop downs waste space as sorting is scarcely used.
• [x] If not possible, make them go into one line. Perhaps consider a toggle button with only up/down arrow icons for sort order instead.
• [x] Increase spacing and add a horizontal grey line between each favorite row. Or better; alternating row colors.
• [x] Make it so that the whole row performs actions rather than how only the font area currently does so.

Details section:

• [ ] Add a default hidden details section in the pane for selected favorite's image and information.
• [ ] Make it so that when user clicks once on the favorite, information about it is shown in the details section.
• [ ] Selected favorite should be in bold font
• [ ] Double/Middle clicking the favorites will now activate them.

[FichteFoll]

I think reworking the "Favorites" feature into a list of tracked tags that you can categorize would be neat.

For example, you could create a category for authors you'd like to track (i.e. keep getting updates on) or a list of franchises/characters/whatever you can think of. Grabber wouldn't need to know the category of a tag because you would set the category by yourself. And finally there could be a per section view that shows all unviewed images for all tracked tags in a category.

This might be more of a new feature of its own, but maybe worth exploring. Related to #1416.

[brazenvoid]

The problem with Favorites tracking is that it is same as how any other tag is tracked aside the lower date time limit. To actually do a oldest to newest order, grabber will have to do an exhaustive search for many of the sources as they do not provide the needed search filters and sort options.

For me favorites are the tags which I absolutely will download or at least give a serious thought to do so. So any file getting tagged with them are also a great interest to me and I do a search run every once in a while from scratch.

I had previously suggested but was shot down due to apparent usability. The recommendation I gave actually also catered for any image getting the tag later than when the user first goes through the time those images were posted. Tags are after all assigned by the user and it can be the case that they get tagged with a favourited tag much later than when they were posted. Essentially it meant that a md5 list be kept for each favorite which would store all the viewed file hashes and the user gets to have the option to only display not viewed ones throughout the whole tag's database.

It also needed what Jack started as a way to combine pages when results do not meet a certain number thus reducing the wait times. Though, well as you might know, demanded much more work than previously anticipated and thus, it was not heard from again.

[Bionus]

If possible, move the sort option and direction to the title bar instead. Those two drop downs waste space as sorting is scarcely used.

You mean in the menu? Like "File", "About", etc.?

If not possible, make them go into one line. Perhaps consider a toggle button with only up/down arrow icons for sort order instead.

What should go into one line?

Sorting options are already in one line. Are you talking about merging the sorting options and the search options?

Add a default hidden details section in the pane for selected favorite's image and information. Make it so that when user clicks once on the favorite, information about it is shown in the details section.

But what would you show in this pane that isn't already shown in the list? Since the list already shows the thumbnail, the favorite's name and optionally the last check date.

Selected favorite should be in bold font

Indeed, currently it can be confusing which favorite is currently enabled.

Double/Middle clicking the favorites will now activate them.

Middle clicking is already being used for opening the search in a new tab however.

Increase spacing and add a horizontal grey line between each favorite row. Or better; alternating row colors.

Currently it uses the same spacing as normal search results (Interface > Margins and borders).

What settings are you using for "Interface > Favorites display"? Did you disable the image?

Make it so that the whole row performs actions rather than how only the font area currently does so.

That should already be the case? Except for the few pixels of space between each image of course.

Example in "name-only" mode:

---

The problem with Favorites tracking is that it is same as how any other tag is tracked aside the lower date time limit. To actually do a oldest to newest order, grabber will have to do an exhaustive search for many of the sources as they do not provide the needed search filters and sort options.

Yup. It would require loading everything until the last seen image to be able to show them in reverse order.

I had previously suggested but was shot down due to apparent usability. The recommendation I gave actually also catered for any image getting the tag later than when the user first goes through the time those images were posted. Tags are after all assigned by the user and it can be the case that they get tagged with a favourited tag much later than when they were posted. Essentially it meant that a md5 list be kept for each favorite which would store all the viewed file hashes and the user gets to have the option to only display not viewed ones throughout the whole tag's database.

Not sure what you mean by your suggestion nor where I shot it down.

Are you suggesting a separate MD5 database for each favorite, and allowing an user to search through all results of a given search to find images not in that MD5 database? That sounds like a batch download with "global duplicates" enabled.

Also, it seems that a solution similar to the "Delay" setting that was recently added to monitors might be a viable solution?

It also needed what Jack started as a way to combine pages when results do not meet a certain number thus reducing the wait times. Though, well as you might know, demanded much more work than previously anticipated and thus, it was not heard from again.

In which issue was this talked about? As you know there is a lot of issues currently open so it's hard for me to keep track of all of them.

---

For example, you could create a category for authors you'd like to track (i.e. keep getting updates on) or a list of franchises/characters/whatever you can think of. Grabber wouldn't need to know the category of a tag because you would set the category by yourself. And finally there could be a per section view that shows all unviewed images for all tracked tags in a category.

It indeed feels like a feature on its own.

If I understand correctly, what you're suggesting is these two things?

• Grouping by arbitrary "category" that would be set in the favorite's setting (IIRC there is another issue open about that)
• A button that would search all favorites of a given category and merge all results

[brazenvoid]

All the points in the first post referred to the favorites pane, nothing was for other features of favorites or the search window. Let me show current favorites pane as reference:

If possible, move the sort option and direction to the title bar instead. Those two drop downs waste space as sorting is scarcely used.

You mean in the menu? Like "File", "About", etc.?

If not possible, make them go into one line. Perhaps consider a toggle button with only up/down arrow icons for sort order instead.

What should go into one line?

Sorting options are already in one line. Are you talking about merging the sorting options and the search options?

Both of these points refer to the sort selectors where in pic, Name/Ascending selectors are shown. I suggested two ways to minimize them, either make something like a menu/dropdown in the pane title for these or make it so that both of them go in one line with sort direction shown as toggle icon button.

Add a default hidden details section in the pane for selected favorite's image and information. Make it so that when user clicks once on the favorite, information about it is shown in the details section.

But what would you show in this pane that isn't already shown in the list? Since the list already shows the thumbnail, the favorite's name and optionally the last check date.

Actually this was an alternate solution to the other problems I should have described first but described later.

I like the hover popup but it only rarely shows up and as the rows are so thin, the actionable surface is just too narrow. I noticed the hover popup just a few weeks ago even after using this feature for more than a year.

Double/Middle clicking the favorites will now activate them.

Middle clicking is already being used for opening the search in a new tab however.

This point is associated with the details section. Ignore here.

Increase spacing and add a horizontal grey line between each favorite row. Or better; alternating row colors.

Currently it uses the same spacing as normal search results (Interface > Margins and borders).

What settings are you using for "Interface > Favorites display"? Did you disable the image?

You mistake this point about the favorites tab but I am referring to the pane seen in the pic.

Make it so that the whole row performs actions rather than how only the font area currently does so.

That should already be the case? Except for the few pixels of space between each image of course.

You mistake this point about the favorites tab but I am referring to the pane seen in the pic.

I had previously suggested but was shot down due to apparent usability. The recommendation I gave actually also catered for any image getting the tag later than when the user first goes through the time those images were posted. Tags are after all assigned by the user and it can be the case that they get tagged with a favourited tag much later than when they were posted. Essentially it meant that a md5 list be kept for each favorite which would store all the viewed file hashes and the user gets to have the option to only display not viewed ones throughout the whole tag's database.

Not sure what you mean by your suggestion nor where I shot it down.

Are you suggesting a separate MD5 database for each favorite, and allowing an user to search through all results of a given search to find images not in that MD5 database? That sounds like a batch download with "global duplicates" enabled.

Also, it seems that a solution similar to the "Delay" setting that was recently added to monitors might be a viable solution?

I'll look into your suggestions. To lessen the ambiguity, please consider my use case:

• Animated files are usually the best to see tag-time issues.
• These are tagged in a random time frame as sources do not auto-tag them by content type.
• Whenever you search animated tag every day or couple of days, you will keep finding new files in the last year or so. Meaning going back nearly 25-50% of pages every time to hunt them down. (Shimmy scheme has a filter for this but only for files after 9/19, i think)
• Due to this I can't keep favorites of them and thus am slowly converting them to keep for later bookmarks.
• But then bookmarks can't store post filters which then render the searches even more cumbersome for me.

It also needed what Jack started as a way to combine pages when results do not meet a certain number thus reducing the wait times. Though, well as you might know, demanded much more work than previously anticipated and thus, it was not heard from again.

In which issue was this talked about? As you know there is a lot of issues currently open so it's hard for me to keep track of all of them.

I don't remember the issue either, but you wanted to do it for a major version. The operation was similar to what e-hentai does for file count filters. Grouping pages to make up for the set search results count.

BTW, you really need to clean them up already... At least close the unassigned error reports before 7.x or install an auto close bot.

[Bionus]

Indeed, my bad. I misunderstood what you were talking about so I answered totally off the mark. In that case, I'll re-answer everything since most of my answers don't make sense.

---

If possible, move the sort option and direction to the title bar instead. Those two drop downs waste space as sorting is scarcely used.

I don't think it's possible with Qt without weird stuff.

If not possible, make them go into one line. Perhaps consider a toggle button with only up/down arrow icons for sort order instead.

This I can do, and it indeed makes sesnse. I'll replace the "order" dropdown by a single button that toddles between ascending and descending.

Add a default hidden details section in the pane for selected favorite's image and information. Make it so that when user clicks once on the favorite, information about it is shown in the details section.

Wouldn't it actually make even more sense to have a separate pane for that? Kinda like many music players do for the active song information. It would also allow to move/remove it easily.

Increase spacing and add a horizontal grey line between each favorite row. Or better; alternating row colors.

I'll see what makes the most sense visually and choose one of those two accordingly.

Make it so that the whole row performs actions rather than how only the font area currently does so.

:+1:

[brazenvoid]

Add a default hidden details section in the pane for selected favorite's image and information. Make it so that when user clicks once on the favorite, information about it is shown in the details section.

Wouldn't it actually make even more sense to have a separate pane for that? Kinda like many music players do for the active song information. It would also allow to move/remove it easily.

I had similar inspiration for that suggestion (from Xnview MP) but what makes me go against, is the screen space getting used up. That's why a section which is hidden by default inside the favorites pane works better and does not curtail its area by default either.

Perhaps you can make a thin bar with only pane named buttons accommodate these panes and have toggleable "fixed" layout option for them like in many IDEs, these screen space issues will be gone and done with. Those with small screens could see the panes overlayed on the main view

An example from JetBrains PHP Storm:

[Bionus]

I had similar inspiration for that suggestion (from Xnview MP) but what makes me go against, is the screen space getting used up. That's why a section which is hidden by default inside the favorites pane works better and does not curtail its area by default either.

Makes sense.

Perhaps you can make a thin bar with only pane named buttons accommodate these panes and have toggleable "fixed" layout option for them like in many IDEs, these screen space issues will be gone and done with. Those with small screens could see the panes overlayed on the main view

An example from JetBrains PHP Storm:

Seems like a lot of work compared to the gain. That would mean re-coding the whole thing, since from what I can see, even the most popular alternative docking systems for Qt don't have this feature:

• githubuser0xFFFF/Qt-Advanced-Docking-System
• KDAB/KDDockWidgets

[FichteFoll]

Sorry for hijacking this issue. I don't think my comments directly relate to the issues raised in OP, aside from the categorization, which would be a feature on its own.

I'll follow the discussions in the various issues already open and formulate a proper request out of my idea(s) later, once I know what is already being discussed elsewhere.

[Bionus]

@FichteFoll no worries. But indeed, especially given your suggestions above are more about favorites in general rather than the favorites dock I think it would be better to create a separate issue. 👌

Or if one already exists simply bump it, but there might not be one.