Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a proper search option #428

Closed
Ortham opened this issue Apr 29, 2015 · 5 comments
Closed

Add a proper search option #428

Ortham opened this issue Apr 29, 2015 · 5 comments

Comments

@Ortham
Copy link
Member

Ortham commented Apr 29, 2015

At the moment LOOT v0.7 has a content filter, but no search function, due to technical difficulties relating to the virtual lists used. Search functionality is useful for seeing where certain plugins are in relation to others though, so it would be good to have.

Because of the virtual lists, I don't think this could be done using Chromium's native search, but I see no reason why it couldn't be implemented in JavaScript, with a result counter and next/previous arrows.

@Ortham Ortham modified the milestone: v0.7.x May 20, 2015
@Ortham
Copy link
Member Author

Ortham commented May 25, 2015

The UI for search could be modelled off Chrome for Android's "Find in page" UI. The search element could be put in the sidebar, replacing the content filter (which could be moved into the Filters tab), or it could be put in the application toolbar.

With a 1024x768 window, there's enough space in the sidebar for a functional Chrome-for-Android-style search UI.

If the search UI were put in the app bar, it would have to be as an icon button that when clicked, hid the rest of the app bar contents and replaced it with the actual search UI. There's not enough space otherwise, and in any case adding another button may clutter things up a little too much.

@Ortham
Copy link
Member Author

Ortham commented May 25, 2015

A couple of UI mockups:

screenshot 98

screenshot 99

The search controls actually fit OK in the app bar, I think I'll put them there after all. It does make more sense for them to be there too, as the search would be performed on the plugin cards, not the sidebar items.

I think I'll still move the contents filter into the Filters tab, it makes more sense for it to be there, it frees up space in the sidebar, and there's less confusion between it and search if it's clearly a filter.

Ortham added a commit that referenced this issue May 25, 2015
For #428. Search is functional, though there is no highlighting of
results, and it may interact oddly with filters.
@Ortham
Copy link
Member Author

Ortham commented May 26, 2015

The odd interaction with filters doesn't actually exist, it's really the above bug, message filters are independently broken.

In the add-search branch, search now only looks for visible matches, but currently if a filter is applied after a search has been performed, the matching cards can still be iterated over using the buttons. I think I will change this so that any action that may change the visible matches will also cause the search to be re-performed. Such actions are:

  • Hide version numbers
  • Hide CRCs
  • Hide Bash Tags
  • Hide notes
  • Hide 'Do not clean' messages
  • Hide all plugin messages
  • Hide inactive plugins
  • Hide messageless plugins
  • Filter content
  • Show Only Conflicts
  • Apply (metadata edits)
  • Clear User Metadata

@Ortham
Copy link
Member Author

Ortham commented May 26, 2015

pStyl3 has given some feedback on search results highlighting: in particular highlighting matches within cards may not be feasible given the range of colours used for text and backgrounds.

I like the inset border on the left of the card, it's a distinctive highlighting method.

@Ortham
Copy link
Member Author

Ortham commented May 27, 2015

Closing this, as it has now been implemented as of 837a9de.

@Ortham Ortham closed this as completed May 27, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

1 participant