Add sharing functionality

[Herbstein]

I do a lot of sharing of Spotify songs, and to make this my main client I need the feature. This implementation uses the key-bind m and the command share to copy the currently playing song to the system clipboard.

Creating a clipboard context for each time a share happens isn't great, but because sharing is (generally) a rare occurrence.

The new library is used by Mozilla in Servo so shouldn't be an issue to include.

Is copying the currently playing song the desired functionality, or would it be better to share the currently selected song? Maybe sharing the currently playing song only when used with a shift modifier. You could then modify the command to be either share selected or share current.

[im-n1]

This is great just one question. Why is "sharing" under "m" and not under "s"?

[Herbstein]

Because s is already taken. I didn't want to move that as my initial implementation, but I agree that it's the best place for it.

[hrkfdn]

Thanks for the PR! s would indeed be nice for sharing, but it's taken by save, which seems equally fitting 😛.

Other options:

• y: as in yank/copy from vim.
• x: no good reason to be honest, except it feels appropriate.

Do you want to re-map it before I merge it? I'm fine with it either way.

[Herbstein]

I'll move it to x. There are already a few things down on the bottom row.

[Herbstein]

Do you have a preference on saving the selected song vs currently playing?

[hrkfdn]

To the clipboard? I'd say the currently selected, otherwise one needs to first play a song to share the link. What do you think?

[Herbstein]

I can definitely see both usecases. We could amend the command with a parameter. current for the currently playing and selected for the currently selected. The keybind x could then default to one of those, with Shift+x for the other option.

[hrkfdn]

I like the idea!

[Herbstein]

I am struggling with finding out which track/element is currently selected. You could make it general to any selected "shareable" element, but right now I think that requires doing backwards parsing from Cursive.

[hrkfdn]

Commands are handled in their respective UI source files. The UI structs should have access to the currently selected track, e.g. ui/listview.rs. Have a look at the on_command handler. Hope this helps.

[Herbstein]

That was indeed very helpful! Do you want me to move the entire share command into the ListView impls? I can't quite figure if I prefer handling the "generic" method in a generic place, and the specifics in a specific place, or having an entire command implemented in one place. Any thoughts on that?

[hrkfdn]

If the single handler doesn't get too convoluted, I'd prefer that, as new code readers might miss the specific implementations distributed across the files. However, if it results in a too large method, it would seem reasonable to split it. Just my two cents, though.

[Herbstein]

One last thing. I come from a functional programming background. If the command option chaining is too big I can easily break it up if you prefer.

[hrkfdn]

Looks good to me. I commented a minor detail, after that I think we can merge it.

[Herbstein]

I updated the readme. I don't think I have anything else to add.

[hrkfdn]

Great, thanks a lot for your contribution. Merged!

[inwwin]

@Herbstein I cannot use this feature in Wayland. Is this suppose to work in Wayland?

Edit: It seems the upstream project has not yet support Wayland, never mind.