search

bugaevc / wl-clipboard

Command-line copy/paste utilities for Wayland
GNU General Public License v3.0
1.62k stars 59 forks source link

2.0 release preparations #56

Closed bugaevc closed 5 years ago

bugaevc commented 5 years ago

The big rewrite of wl-clipboard is done, merged and pushed into master, and we can go forward with the 2.0 release :tada:

Before we cut a release though, let's give the 2.0 beta (the current master) some testing. I'm doing as much testing as I can myself, and it'd be great if you all could help me :slightly_smiling_face:

Please report bugs as separate issues, and leave general comments here.

Known not to work:

Also cc @notramo, @Ferdi265, @emersion, @shmerl, @kode54, @brunelli, @YaLTeR, @bennydictor, @nostdm, @yory8, @szpak, @lovesegfault

lovesegfault commented 5 years ago

Can you add a 2.0.0_beta1 or something like that tag so that I can bump this for Gentoo without having to do git commit voodoo?

bugaevc commented 5 years ago

Sure!

ainola commented 5 years ago
  • Packagers (@ainola, @adabru, @fsateler, @ddevault, @elmarco, @myfreeweb, @maxice8, @colemickens, @jbeich; did I forget anyone?), please check that you can build wl-clipboard 2.0 on your system without any problems. Please pay attention to what features (in particular which protocols) get enabled during the configuring stage — the more, the better, but any configuration should work. Do you make some changes that you would like to upstream? I'm particularly interested in whether wl-clipboard still builds on BSD and non-glibc non-gcc systems.

GCC on Arch here. Builds just fine but I haven't yet built it in a chroot.

  • Check that wl-paste immediately after the compositor startup errors with No selection, and so does wl-paste --list-types

Confirmed fine.

  • Try copying with wl-copy and pasting it back with wl-paste; are the contents identical? Do the -n (--no-newline/--trim-newline) flags work as expected? Try doing the same with --primary

Confirmed fine.

  • Copy between wl-clipboard, Wayland apps and XWayland clients. Does it work? Does wl-copy -o still break pasting into XWayland clients?

Breaks it how? It seems to be working as expected with Gedit for me (with GDK_BACKEND=x11 set)

  • If you have the hardware, please check that multiseat support (--seat) still works. Try asking for an invalid (or even empty) seat name, does it return an error correctly?

Never used this function before.

  • Does it work with binary data correctly? Can you copy an image into the primary clipboard and then paste it with middle click?

Yes and yes. However, I must start the application before running wl-copy -p < myimg.png in order for the primary paste to work. I don't know if that's a limitation or bug in something else, though.

(This applies for both x11 and sway)

  • Does it work with non-UTF-8 text? Does pasting from and into Qt apps work?

Yes and yes (both x11/sway).

  • Does it leave temp files in /tmp after all wl-copy processes exit? Does wl-copy -o clean up too?

Yes.

  • Does type inference in wl-paste still work? Copy an image from a web page, observe wl-paste --list-types, then try pasting (to the terminal, to a text file, to a .png file, to a .jpg file...) and see if it does what it should. Try requesting a different type explicitly. Try requesting a generic type (e.g. --type image).

Confirmed all works.

  • Do --clear and --paste-once work as expected? What about them in combination with --primary? Does clearing one clipboard mess with another?

Confirmed all works.

  • If you use a wlroots-based compositor, does wl-paste --watch work? If you don't, does it report an error as it should?

Works just fine on sway.

  • Does bash completion work? Does it complete the correct currently available types after --type <TAB><TAB>? Does it correctly complete the nested command in say wl-paste -pw f<TAB>?

Running this from a build dir, so I can't test this one.

  • Copy a file from a file manager, see what MIME types it translates to. Try to replicate the same format with wl-copy; can you paste it back in the file manager?

Er, I'm a little lost on this one here.

NilsIrl commented 5 years ago

Please name it something else than 2.0.

wl-clipboard is a library and there is no reason there should be a major version change because of some fixed bugs and refactor.

bugaevc commented 5 years ago

@ainola

However, I must start the application before running wl-copy -p < myimg.png in order for the primary paste to work. I don't know if that's a limitation or bug in something else, though.

Hmm, I cannot reproduce this, it works fine for me. If you can, please open a new issue and get WAYLAND_DEBUG=1 logs — preferably for both the wl-copy -p invocation and the app (tip: you can |& grep primary on the app log to keep it to a readable size).

Running this from a build dir, so I can't test this one.

You can get the completions into any shell by just sourcing the completion scripts, e.g.

$ cd wl-clipboard
$ source completions/bash/wl-copy
$ source completions/bash/wl-paste
$ cd build
$ src/wl-paste -t <TAB><TAB>
bugaevc commented 5 years ago

@NilsIrl

Please name it something else than 2.0.

wl-clipboard is a library and there is no reason there should be a major version change because of some fixed bugs and refactor.

wl-clipboard is not a library! There are just two utilities, wl-copy and wl-paste, and that's it.

You might be thinking of:

There is a very good reason for a major version increase. There are major new features since 1.0 (such as wlr-data-control support and wl-paste --watch mode), and the whole Wayland interaction logic was practically rewritten. It very much feels like a 2.0 :smile:

NilsIrl commented 5 years ago

When I said wl-clipboard is a library, I am not making any mistakes.

It is "virtually" a library since its main use is in shell scripts and programs such as vim use it to provide clipboard support.

colemickens commented 5 years ago

I've literally never heard of someone use the term "library" to refer to an executable that is used in shell scripts.

Ferdi265 commented 5 years ago

When I said wl-clipboard is a library, I am not making any mistakes.

It is "virtually" a library since its main use is in shell scripts and programs such as vim use it to provide clipboard support.

So, would you call GNU coreutils a "library" as well?

Also, the new features and new supported protocols are definitely reason enough to call this 2.0

colemickens commented 5 years ago

My overlay, nixpkgs-wayland, was able to build the new wl-clipboard. I don't have time to test extensively right now, but it seems someone else has tested the new version with Sway, which is what I'd be testing anyway. Let me know if you want any other info from me.

NilsIrl commented 5 years ago

I've literally never heard of someone use the term "library" to refer to an executable that is used in shell scripts.

I guess curl sort off (I know it is also a C library)

So, would you call GNU coreutils a "library" as well?

Yes and no. The word "library" isn't the problem. The thing is that semantic versioning applies fully for this as much as it would for a "normal" library.

bugaevc commented 5 years ago

It is "virtually" a library since its main use is in shell scripts and programs such as vim use it to provide clipboard support.

Indeed, wl-clipboard is intended to be nicely usable in shell scripts and other sorts of Unix-y programs (I wouldn't say that's its main use though), and many programs already rely on it for their Wayland clipboard support.

But shell scripting is a very different environment to pervasively semver networks/ecosystems of libraries (think npm and crates.io). You don't declare the exact versions of your dependencies in some sort of a JSON buildconfig file and have some specialized, semver-aware package manager fetch the right versions from an online repository just for your project, for your own little "virtual environment" as they call it.

Instead, shell scripts exist in an integrated OS environment, where a compatible set of packages of specific versions is selected and configured by the distribution your script happens to be running on. So what you do in a shell script is you check at runtime whether an executable called wl-copy (or whatever) is in the PATH, and enable your Wayland backend code if it is. This is what neovim does, and this is also what wl-clipboard itself does when it tries to use e.g. xdg-mime. On the other hand, it means that command-line programs used in scripts practically cannot make backwards incompatible changes to their interface, and that's something I take very seriously in wl-clipboard.

So this is why wl-clipboard versioning follows common sense, not semver (not to suggest that semver is bad, but it's a convention for a different kind of environment). Of course I won't do silly things like bumping the major version for every bugfix, but I also don't follow the policy of only bumping the major version for backwards incompatible changes.

wl-clipboard 2.0 is a big release which in every way deserves to be called 2.0, so that's what I'm calling it.

ainola commented 5 years ago

Now that this bikeshedding is out of the way, would someone kindly test what I could not? :)

bugaevc commented 5 years ago

Pushed a 2.0.0_beta2 tag with some fixes & improvements; importantly, a build fix (thanks @Eluminae for the report!) and zsh completion (thanks @RPigott for contributing it!)

prometheanfire commented 5 years ago

packaged beta2 on gentoo, there are some compiler warnings that I can share if you want but working fine so far (beta1 did as well).

bugaevc commented 5 years ago

Yes, I would appreciate the warnings!

prometheanfire commented 5 years ago

here's my build log https://gist.githubusercontent.com/prometheanfire/8dbb16d6c383d9e9081b5fab97239c6e/raw/4148ff0c60140d0f7bf5e810264bbed660c46833/gistfile1.txt

bugaevc commented 5 years ago

Thanks! These are pretty harmless, but I pushed https://github.com/bugaevc/wl-clipboard/commit/bd49478c60a4be5516931de6307f872c1d48973c

jbeich commented 5 years ago

2.0.0_beta2 (1763510):

ainola commented 5 years ago

@bugaevc , I've pushed beta 2 to the arch [community] repos since the 1.x series was no longer functional. If there are issues, I imagine the users will let you know :)

bugaevc commented 5 years ago

Thank you 😉

fsateler commented 5 years ago

I have built on debian and uploaded to debian. Seems to work fine for me, including the tests mentioned in the top post.

I have the following comments though:

  1. editorconfig match is too broad. debian/rules is a makefile and is thus broken by the forced tabs :cry: . I added locally an exception:
[debian/rules]
indent_style = tab
indent_size = 8

  1. Some compiler warnings:

    [19/35] Compiling C object 'src/25a6634@@wl-clipboard@sta/util_files.c.o'.
../src/util/files.c: In function ‘trim_trailing_newline’:
../src/util/files.c:91:5: warning: ignoring return value of ‘ftruncate’, declared with attribute warn_unused_result [-Wunused-result]
91 |     ftruncate(fd, seek_res);
  |     ^~~~~~~~~~~~~~~~~~~~~~~
../src/util/files.c: In function ‘infer_mime_type_from_contents’:
../src/util/files.c:105:5: warning: ignoring return value of ‘pipe’, declared with attribute warn_unused_result [-Wunused-result]
105 |     pipe(pipefd);
  |     ^~~~~~~~~~~~
[27/35] Compiling C object 'src/25a6634@@wl-clipboard@sta/types_popup-surface.c.o'.
../src/types/popup-surface.c: In function ‘popup_surface_init’:
../src/types/popup-surface.c:100:5: warning: ignoring return value of ‘ftruncate’, declared with attribute warn_unused_result [-Wunused-result]
100 |     ftruncate(fd, size);
  |     ^~~~~~~~~~~~~~~~~~~
[30/35] Compiling C object 'src/25a6634@@wl-paste@exe/wl-paste.c.o'.
../src/wl-paste.c: In function ‘selection_callback’:
../src/wl-paste.c:214:5: warning: ignoring return value of ‘pipe’, declared with attribute warn_unused_result [-Wunused-result]
214 |     pipe(pipefd);
  |     ^~~~~~~~~~~~
../src/wl-paste.c:262:9: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
262 |         write(STDOUT_FILENO, "\n", 1);
  |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  2. The zsh installation path is wrong when prefix=/usr. /usr/share/zsh/site-functions is not part of $fpath, at least on debian. I have worked around this locally moving the files, but I figure a meson option to set the path would be the correct option.

  3. Zsh completion is a bit funky: for example, it suggests --watch=, which does not accept that format. Very minor though.

rpigott commented 5 years ago

@fsateler site-functions is in the default $fpath for upstream zsh. Seems debian uses vendor-completions though, right? I suppose there could be a build option to use a non-standard zsh completions dir though.

You are right about --watch.

fsateler commented 5 years ago

@RPigott site-functions is on the fpath, but only for usr/local tree

eli-schwartz commented 5 years ago

@fsateler

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934926 is some interesting reading, which was prompted when I submitted an issue to joeyh's project git-annex asking for an option to fix the zsh-completion directory due to the fact that Debian's configuration is incompatible with literally every other distribution of zsh ever produced, packaged, or self-compiled, on any OS ever.

A build option seems sane, though. The alternative is to do what I believe many other Debian packages do, which is mv the files after the fact.

bugaevc commented 5 years ago

@fsateler

I have built on debian and uploaded to debian. Seems to work fine for me, including the tests mentioned in the top post.

Thanks! :)

editorconfig match is too broad. debian/rules is a makefile and is thus broken by the forced tabs 😢 . I added locally an exception

You don't have to add an exception to the root editorconfig file; you should be able to just drop another editorconfig file into your debian/ folder.

Some compiler warnings

These should already be fixed in https://github.com/bugaevc/wl-clipboard/commit/bd49478c60a4be5516931de6307f872c1d48973c

The zsh installation path is wrong when prefix=/usr. /usr/share/zsh/site-functions is not part of $fpath, at least on debian.

Zsh completion is a bit funky

@RPigott is getting these fixed / worked around in #66 :)

adabru commented 5 years ago

Works for me 👍, I have nothing to add.

fsateler commented 5 years ago

@eli-schwarz

Thanks, interesting reading indeed. This is not so nice :(

@bugaevc thanks for the tip! I'll use that instead then.

tardypad commented 5 years ago

Does wl-copy -o still break pasting into XWayland clients?

I experience this issue myself now on Arch Linux using wl-clipboard 2.0.0_beta2-1 Please let me know how I can help you debug this issue

bugaevc commented 5 years ago

This is not a wl-clipboard bug; it's mostly expected (if unfortunate) behavior. XWayland wants to inspect the offer multiple times, and you're explicitly telling wl-clipboard not to allow that.

If you want to paste into an XWayland window once and then clear the selection, you can do that explicitly with wl-copy --clear after you paste.

tardypad commented 5 years ago

Ah ok, I guess I misunderstood that "Does wl-copy -o still break pasting into XWayland clients?" comment then :) I assumed it meant that this got fixed in the new version and you were asking people to test it. Thanks for clearing that up quickly, I understand why now.

bugaevc commented 5 years ago

wl-clipboard 2.0 is out! 🎉 Thank you all for testing & helping me get it out, now please update your packages :smile:

Read the announcement on Mastodon.

asvvvad1 commented 4 years ago

Sorry to bring this up again but is there plans for making it into a library? I know it's not and tried looking in the source for how to turn it into one but but couldn't figure it out since I don't really know C :disappointed:

emersion commented 4 years ago

Not sure it's worth turning into a library. Using the wayland protocol directly wouldn't be a lot more effort.

asvvvad1 commented 4 years ago

Thanks for the reply will look more into the protocol ^^

bugaevc commented 4 years ago

Even if I do turn it into a library, you wouldn't be able to use it without knowing C :slightly_smiling_face:

asvvvad1 commented 4 years ago

I know of that but I was wondering if I could make bindings to it for another language that compile to C

lovesegfault commented 4 years ago

Guys, please don't necro old issues to talk about completely different things :laughing:

YaLTeR commented 2 years ago

Dear packagers who are presumably still subscribed to this issue: this is a ping to let you know I've just tagged a v2.1.0 bugfix release (in @bugaevc's temporary absence). I've tested it on GNOME 42, Weston 10 and sway 1.7 and it seems to work fine. If there's any issue please let me know.