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

Albert: enhancements discussion #81

Open
rsyring opened this issue Jul 4, 2022 · 0 comments
Open

Albert: enhancements discussion #81

rsyring opened this issue Jul 4, 2022 · 0 comments

Comments

@rsyring
Copy link

rsyring commented Jul 4, 2022

My context: I'm trying to be less dependent on the mouse and albert+brotab could help a lot by being able to instantly jump into any tab on my browser from anywhere I happen to be on the desktop. However, I'm currently hindered by a few issues. I thought I'd list them here for discussion and can break them out into separate issues if needed.

  • SQLite cache db TTL
    • Turns out that when using the keyboard for everything, it's not uncommon to open new tabs in FF then switch away to do something else, then want to switch back fairly quickly. A five minute delay in updating tabs is problematic.
    • When using bt list in the CLI it seems to respond really quickly. Is there a reason the albert extension uses index instead of getting realtime results from the browser?
    • Or, if the browser extension can detect new tab creation, maybe it can use that event to tell the client to update it's index? No polling/TTL needed then?
  • Display / Search
    • I've not found the parsed page content in the search results to be helpful. It's actually been a hindrance because there is so much "noise" in the results.
    • As an example, I'm currently writing this issue with about 17 other tabs open. A bunch of them are GitHub tabs but only two tabs are in a repo's "issues" area. But, this is what brotab returns:
      image
    • Recommendations for improvement
      • Don't use page content in the search? Or, and not sure if Albert supports this, use different triggers to indicate whether page content should be included or not.
      • Weighted search results that prioritize tab title, then URL, then (if activated) page content
      • Put the tab title as the primary text line and then use the URL path + page content (if activated) for the subtext
  • Focus

BTW, I really appreciate the work that you've but into this app. FWIW, I'm a Python dev and could submit PRs for any functionality above that you think is worthwhile. I just wanted to get on the same page conceptually before working on a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant