Clipboard isn't perfect

[Slackadays]

trafficstars

This isn't an issue with Clipboard, but rather one of humans in general.

Consider this. If you look at some repo, your eyes might look at the number of Issues and Pull Requests first. If you then notice that this repo has zero issues and zero PRs, what do you assume? There are two potential cases here. The first is where most/all issues get quickly resolved and PRs get quickly resolved too. The second is where nobody has bothered to make any issues or PRs because nobody is using the project. Us humans tend to default to the second option.

Unfortunately, Clipboard falls into the first case. Most issues are quick fixes, some aren't actually issues with Clipboard but rather some underlying standard (so we can't fix them), and the rest do take more effort to fix. The end result of this is few to no issues or PRs, which gives false credence to the second case.

So, the purpose of this issue is to inform you of this psychological phenomenon and to keep at least one open issue in the queue.

[ghost]

This isn't an issue with Clipboard, but rather one of humans in general.

Consider this. If you look at some repo, your eyes might look at the number of Issues and Pull Requests first. If you then notice that this repo has zero issues and zero PRs, what do you assume? There are two potential cases here. The first is where most/all issues get quickly resolved and PRs get quickly resolved too. The second is where nobody has bothered to make any issues or PRs because nobody is using the project. Us humans tend to default to the second option.

Unfortunately, Clipboard falls into the first case. Most issues are quick fixes, some aren't actually issues with Clipboard but rather some underlying standard (so we can't fix them), and the rest do take more effort to fix. The end result of this is few to no issues or PRs, which gives false credence to the second case.

So, the purpose of this issue is to inform you of this psychological phenomenon and to keep at least one open issue in the queue.

why not just make something new? because clipboard isn't gaining much PRs, issues and stars.

[Martinits]

For me, I'll take the first option. If a repo has stars more than 500 or 1k, I'll consider it as something that is worth a try. Small number of issues and PRs means maintianers are active on this, and I prefer such repos because I can get quick feedback, fixed or not, rather than waiting for an issue to be replied for weeks or even months. Many repos are like that, and I end up quiting reluctantly. Meanwhile, Clipboard is not with complex functionalities, just a small widget I think. So just keep it simple, with less issues and quick feedback. If you want more issues to keep a repo more "active", make a new one, with more functionalities.

[Slackadays]

The tricky part is that Clipboard does actually do some funky/advanced stuff under the hood to get everything working, so it's a wonder how there aren't more issues because there are so many moving parts. However, I can see where you're coming from, as Clipboard right now just has the basics. Hopefully there should be some more advanced features coming soon. I'm thinking once the macOS tests are fixed, the next items for the todo list are to add the remove action, MIME type detection, the note action, fuzzy file search, and custom color schemes.

[Yarden-zamir]

Cute

[Mart-Bogdan]

Why do you require following checks on bug reports?

Answer these questions so that we can help you faster:

• [ ] If I compiled Clipboard myself, then the errors don't mention "LTO error" (this is a bug with the compiler, not Clipboard)
• [ ] If I compiled Clipboard myself, then the errors don't mention "XYZ has not been defined in namespace std" (this usually means you need a compiler with C++20 support, so upgrade first)

You don't accept bug reports from downloaded binary? Or in case you are, it's not clear from this check-boxes...

[Slackadays]

Those two checkmarks verify that you aren't reporting an unrelated compiler issue because we can't fix those. LTO errors sometimes crop up due to various compiler changes and there's no good way to get rid of them other than disabling LTO altogether. C++20 support is also something that we can't fix as Clipboard only adheres to the C++ standard (see https://github.com/Slackadays/Clipboard/issues/86#issuecomment-1435235180), so it's really a compiler/OS issue. All of this verifies that only real problems with Clipboard show up in Clipboard Issues.

[deep-soft]

Fix for build-clipboard.yml

job:
  freebsd-amd64:
change
            sudo pkg install -y cmake llvm15-15.0.6_1 xorg wayland
with
            sudo pkg install -y cmake llvm15-15.0.7_1 xorg wayland
or
            sudo pkg install -y cmake llvm15 xorg wayland

[Slackadays]

Fix for build-clipboard.yml

job:
  freebsd-amd64:
change
            sudo pkg install -y cmake llvm15-15.0.6_1 xorg wayland
with
            sudo pkg install -y cmake llvm15-15.0.7_1 xorg wayland
or
            sudo pkg install -y cmake llvm15 xorg wayland

This fixed FreeBSD, thanks! I thought it was an issue with Cross Platform Actions but I guess not.

[deep-soft]

Tried to find suitable version for freebsd 13.1 using https://freebsd.pkgs.org/13/freebsd-amd64 but 3 attemps failed. So, next step was to remove version number (using only llvm15) and in GA log pkg selected this "llvm15-15.0.7_1"

[sbritorodr]

Good comment. However, the number of closed PR and issues are literally at the top of the issues tab. Maybe someone would think it's because it's unused, but if that was the case there were none closed issues. 👍

[anotherglitchinthematrix]

I think Clipboard has the most user friendly defaults and features, what I have to do with maim --select | xclip -selection clipboard -t image/png Clipboard does with maim --select | cb :-), if the project doesn't have new commits every now and then one should just assume the project matured into a point where nothing new is needed and there is nothing to fix.

[Slackadays]

what I have to do with maim --select | xclip -selection clipboard -t image/png Clipboard does with maim --select | cb :-)

You can actually get even simpler than this, maim -s works the same as maim --select so you can do just maim -s | cb for the fewest number of characters to type :)

[Slackadays]

It turns out that making one issue isn't enough: there's actually more activity if there are multiple issues in the queue. This is an example of the bandwagon fallacy, where people tend to think something is better if it looks like it's popular. It's also more proof that we aren't living in a meritocracy or else none of this behavior would happen in the first place.

[chromevanadium]

This is a great project, unifying command based clipboard managing across platforms (and, for Linux, even within: X11 versus Wayland!). Congratulations, developer!

I wanted to comment on the aspect of visibility of the project: while the name "Clipboard" is very clear and straightforward, the generic name hinders the project from standing out. It is, for one thing, impossible to search for information (third party blogs, video's, etc).

[Slackadays]

while the name "Clipboard" is very clear and straightforward, the generic name hinders the project from standing out.

I thought about this, and I'm also sad that I didn't think of a better name. However, something that has helped is exclusively branding "Clipboard" as the "Clipboard Project" and using "CB" as the short name, since that's what the binary is and is more distinct. Therefore, if you want to search for info, try "cb" and that should work better than "clipboard."