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

Implement frecency (frequency + recency) #33

Open
RaitaroH opened this issue Apr 5, 2020 · 2 comments
Open

Implement frecency (frequency + recency) #33

RaitaroH opened this issue Apr 5, 2020 · 2 comments

Comments

@RaitaroH
Copy link

RaitaroH commented Apr 5, 2020

I really wish plasma-hud could give the most recent/used results first. So I suppose if you were to interject frece before sending the menu list to rofi that would be amazing.

This will have to create quite a few files. For that reason I think $USER/.cache/plasma-hud/ would be a nice place to keep all the files needed.

@Zren
Copy link
Owner

Zren commented Apr 20, 2020

This would require loading all menu items in python first, before letting frece sort them, and disabling sort in rofi right?

We currently pipe menu items to rofi, as reading the menu items via the dbus in python is pretty slow for huge menus like Firefox (Issue #9).

So turning on this feature would means rofi would appear, but the menu wouldn't be populated for up to a few seconds I believe.


I would either need to:

  • 1 db, and prefix each menu item text with the app name somehow.
  • multiple dbs, 1 for each app, with the app name as the filename (probably not).

@RaitaroH
Copy link
Author

RaitaroH commented Apr 20, 2020

Yes, I also considered the possibilities. I don't think you have to really load them in python each time. Just once to create the initial database. After that, you can either never change the db file and just use it as is, or, better, pipe the dbus into some tmp file, use frece to check it against the db, update the db if needed (frece will do that) and then frece pipe the db into rofi. After which you need to tell frece to increment the database.

To be fair, frece is rather quick in my opinion so that shouldn't be much of an issue. Yes it would be slightly slower than it is now, but not too much. That is, if a db file is kept. Just as an example I use frece for a bunch of thinks, such as my music folders (folders only and all files), a replacement of baloo and other things. You can imagine that the db files can become rather large, even up to 50k entries for me, and yet showing plasma-hud for kate is pretty much as fast feeling as dumping 50k files in rofi from frece.

In terms of db files, I wonder. I am not sure you can keep 1db file unless you have some python logic for it. I think is not a bad solution to have a ~/.local/share/plasma-hud folder or ~/.cache/plasma-hud folder where the db files for each program could be kept.

Here is an example of my music folders:

    cd "$dir"
    find -type d > "$ENTRIES_FILE"

    # Create database
    if [ ! -f "$DB_FILE" ]; then
        frece init "$DB_FILE" "$ENTRIES_FILE"
    else
        frece update "$DB_FILE" "$ENTRIES_FILE" --purge-old
    fi

    icon="inode-directory-symbolic"
    frece print "$DB_FILE" | \
      sed -e "s|$|\x00icon\x1f$icon|" | \
      $DMENU -l 15 -p "What to open?" | sed 's/%21/\!/g' | \
        (read -r x; [[ -z $x ]] || (
            audacious "$dir/$x" & > /dev/null 2>&1
            frece increment "$DB_FILE" "$x"))
    ;;

Which creates something like this (1k-ish lines)
image

I'm also thinking that perhaps, the database could be handled in one of these ways:

  1. never use dbus if database exists
  2. update database if the database is older than today. Something like this in bash if it helps:
"$(stat -c %y ~/.cache/plasma-hud.db 2>/dev/null | cut -d' ' -f1)" != "$(date '+%Y-%m-%d')"
  1. update database at every plasma-hud call
  2. have frece off

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

2 participants