cross-posted from: https://piefed.zip/c/rust@programming.dev/p/1873943/mpris-lyrics-a-simple-linux-cli-that-displays-synced-lyrics-from-the-mpris-xesam-astext-pr

So yeah, as the probably unnecessarily long title says, this is a CLI that displays the current playing lyrics, but instead of trying to go online and fetch a match it just uses the already there xesam:asText property in MPRIS.

Sadly a lot of popular players that implement the MPRIS2 standard still don’t implement that specific one, so it wont work with them. Even the one used in the showcase had to be modified, tho I am hopefully gonna upstream it soon.

I am very strict about AI usage, so for this project the only hint of AI that was used was for tab auto completion that is just used for boilerplate like, idk, implementing the Default trait for PlayerState (not including the actual tricky metadata_last_updated part). Safe to say it was only one notch above no AI at all.

So yeah, here you go give it a try and feel free to roast me, after all this is my first cli and cargo publish ;)

  • Ephera@lemmy.ml
    8·
    21 days ago

    Small nitpick that I noticed while skimming the code:

    Where you define your constants, you can change those comments to be doc-comments instead, so that your editor can display them when you hover over constants.

    And personally, I would go one step further with the units, by putting them at the end of the name of the constant, like you did with some variables in the code. That way, the unit shows up inline while reading code that uses the constant, which makes it easy to see that units match up (or not).

    Side-note: You don’t have to denote the unit for Duration. You construct it from milliseconds, but then it’s unitless and you decide where you use it in what unit you want the value. So, Duration is very cool and I would recommend using it for LRC_START_THRESHOLD as well.

    But yeah, back to the comments-thing: Plain comments are kind of inherently crappy, because they only show up in one place in the code, so you’re less likely to see them and less likely to update them. By putting things into doc-comments, names, log statements, error messages etc., they show up in at least two places.
    Plain comments only really make sense for explaining why the code does something. The what can generally be explained in other ways, at least in a sufficiently abstracted language like Rust.

    • TehPers@beehaw.orgEnglish
      4·
      21 days ago

      Side-note: You don’t have to denote the unit for Duration. You construct it from milliseconds, but then it’s unitless and you decide where you use it in what unit you want the value. So, Duration is very cool and I would recommend using it for LRC_START_THRESHOLD as well.

      Expanding on this further, but the best kind of documentation for what a value represents is its type. Since all of these are duration-related, I would even go as far as using only Duration types for these. The values in Hz (aka n/sec) can be inversed to turn them into Durations (which happens below them to create REFRESH_DURATION and METADATA_REFRESH_DURATION which, despite their names, are actually intervals from what I can tell).

      • AMA@piefed.zipOPEnglish
        4·
        21 days ago

        yeah, thinking about it, probably the naming of those isn’t the best, will make sure to change them and use doc comments

        tho, I will probably keep the 2 Hz consts (while adding a _HZ in both their names) as they make it easier to understand imo [changed my mind: I guess it is easier if it is just the intervals]

        thank u both for actually caring :)