grim
awesome-wlroots
grim | awesome-wlroots | |
---|---|---|
11 | 6 | |
757 | 140 | |
- | - | |
6.9 | 0.0 | |
about 2 years ago | 9 months ago | |
C | ||
MIT License | Creative Commons Zero v1.0 Universal |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
grim
-
Ubuntu 22.10: Error "compositor doesn't support wlr-screencopy-unstable-v1" when trying to record the screen
"GNOME doesn't support wlr-screencopy-unstable-v1, which is the protocol grim uses to take screenshots." Source.
-
[GRIM] question
It's in the README
-
Good cli screenshots tool under wayland ?
there is grim which is supposed to work under Wayland but it seems like it only works under swayWM, the reason why i need a cli tool is that I want to build Rofi script on top of it, I'm a ware spectacle and it is a very great option but I would prefer a Rofi based tool .
-
Tell HN: Gnome on Wayland Is Amazing
sway laptop user here (for almost 2 years I think?).
I spent a little while on this, but I migrated from i3, so I just ported every little section of my config bit by bit.
In terms of battery bar and other "bar" type things, I use waybar[0] which basically does all the things you'd expect by default (just install and it "works").
For multi-monitor, config, I initially setup with wdisplays[1] (think arandr for wayland) and then manually copied the positions into my sway config. Monitor positioning was the only thing I needed to setup (and telling it that one monitor was HDPI) and then all of the scaling and everything worked perfectly. This was my biggest selling point for wayland, I now get nice crisp fonts and application scaling works nicely (which was not the case with X).
volume control from the keyboard took no time, just a couple of extra lines.
There was some stuff to do with the clipboard (wl-clipboard[2]) and screenshots (grim[3] + slurp[4]) that required some setup, but again, just a few lines, and didn't take much mental load.
Oh and I needed to change my notifications daemon(dunst[5]), and chose to change my program launcher to one with a nicer interface and cleaner fonts (wofi[6]).
I think that's all the tweaking that I did. Oh, and I needed to do something with pipewire to sort out screensharing at the start, don't remember that too well though...
[0] https://github.com/Alexays/Waybar
[1] https://github.com/artizirk/wdisplays
[2] https://github.com/bugaevc/wl-clipboard
[3] https://github.com/emersion/grim
[4] https://github.com/emersion/slurp
[5] https://github.com/dunst-project/dunst
[6] https://hg.sr.ht/~scoopta/wofi
-
Screenshot app: remembers "selection" mode, copies to clipboard, wayland support?
grim might work well but you'll probably have to write a shell script or something to keep track of the user preferences. You'll also need slurp if you want to select a region to screenshot.
-
What apps are you running on Sway? (Wayland Native Apps of course)
Screenshots: grim + slurp + swappy
- Can I install Spectacle merely without other kde packages?
-
How can I take screenshot with imagemagick?
Since you have already noticed that it does not work with Wayland, it is a strange requirement to take a screenshot "with it". Why not use a tool that does work with wayland, e.g. Grim?
-
What are some automation scripts that have made your life easier?
# Details I'm an English speaker living abroad, and while I'm trying to learn the local language it's real hard. I found myself popping open a browser to use deepl quite frequently, or trying to find translator plugins for several different applications. To make this process easier, I wrote a script (bound to a hotkey) which will screenshot a selected area, OCR it, translate it to english, and show a notification with the translated text. It also copies the translated text to the clipboard. Why screenshot + OCR rather than just selecting and copying text? Images and screen-sharing, mostly. I think this is just a really cool way to show how the hard parts have usually been done for you, and all you need to do is put the blocks together. ## Implementation I'm running sway, so the several of the tools are Wayland specific. You could easily swap them out for xorg compatible variants if you like. The script is [here](https://github.com/rbuchberger/dotfiles/blob/master/scripts/screenshot\_translate). The toolchain is: * [Slurp](https://github.com/emersion/slurp) - select an area * [Grim](https://github.com/emersion/grim) - screenshot that area * [Tesseract](https://github.com/tesseract-ocr/tesseract) - OCR * [Translate Shell](https://www.soimort.org/translate-shell/) - Translation CLI * [Mako](https://github.com/emersion/mako) - Notification window Mako needed a little configuration to show long form text: [category=translation] width=900 height=1200 Edit: added details and links for the tools used.
-
Flameshot, powerful screenshot tool, fully support Wayland (able to run on sway)
I don't wanna poop on their parade, but haven't Wayland screenshotters been around for a while? https://github.com/emersion/grim
That one has at least been around for long enough, and has worked perfectly under Sway for long enough, that I had to look up its name because I had it bound to a hotkey and had forgotten what it was called.
awesome-wlroots
-
Firefox Is Going to Try and Ship with Wayland Enabled by Default
If you are scripting-heavy user, I recommend trying out one of WMs based on wlroots (or implementing its custom protocols). Core Wayland protocols are designed with security in mind, which doesn't necessarily let you have all the automation fun. wlroots protocols bring back most of X11 capabilities at the cost of having similar security model.
https://github.com/solarkraft/awesome-wlroots is a pretty nice list of various CLI utils you can use. Sadly I don't think anyone aimed to 1:1 replicate APIs of xdotool etc, so you will need to change the syntax in your scripts a bit.
-
Three signs that Wayland is becoming the favored way to get a GUI on Linux
An incomplete list of compositors (they forgot hyprland):
https://github.com/solarkraft/awesome-wlroots#compositors
Among non-tiling ones are: hopalong, labwc, laikawm, tinybox, waybox, wayfire.
-
Wayland: “Move fast and break things” as a moral imperative
This appears to be an attempt at trolling or bait (“Drew Default”) but I’ll bite.
> Wayland ostensibly supports several dozen extensions, but only the GNOME-blessed extensions can be reasonably expected to work.
Instead of actual protocol extensions it seems like the author is talking about desktop tools. “only the GNOME-blessed extensions can be reasonably expected to work” oh GNOME and nowhere else, because GNOME has a “loose relationship” with standards. Meanwhile the rest of the ecosystem is unifying behind wlroots, which coincidentally I have made a small list of tools for that cover most needs: https://github.com/solarkraft/awesome-wlroots
> I can assure you that it’s a nightmare. Creating a new compositor would be a hellish experience. Ask any distribution packager who works with Wayland to share their horror stories — they have many.
Distribution packagers try to make compositors? Maybe they should take a look at wlroots.
> Even on the supported platforms it comes with a substantial burden on build requirements, calling for 10× to 100× or more RAM, CPU time, and power usage.
Obviously not. Some sessions on GPU acceleration being available nowadays, but that’s not a new development. The GNOME Wayland session has been demonstrated to be faster than the X session (many years ago on a Raspberry Pi).
> Novel hardware which addresses issues like microcode and open hardware, like POWER9 and RISC-V, are also suffering under Wayland’s mainstream-or-bust regime.
Why? What does “mainstream-or-bust”? Probably not the protocol maintainers’ tendency to compromise on things to make Wayland not appealing to average users (ha).
> Anyone left behind is forced to use the legacy Xorg codebase you’ve abandoned, which is much worse for their security than the hypothetical bugs you’re trying to save them from.
Xorg, by design and historical growth, is insecure. That said security fixes will of course continue to be shipped (I don’t say this with any internal knowledge of Xorg maintainable, only trust in the FOSS ecosystem). Of course, the user base is still huge.
> Rewriting your code in Wayland is always going to introduce new bugs, including security bugs, that wouldn’t be there if you just maintained the Xorg code. Maybe there are undiscovered bugs lurking in your Xorg codebase, but as your codebase ages under continuous maintenance, that number will only shrink.
Xorg is insecure. Not because of bugs, but because of features people rely on.
> Those of us who work with such systems, we feel like the Wayland community has put its thumbs into its collective ears, sung “la la la” to our problems, and proceeded to stomp all over the software ecosystem like a toddler playing “Godzilla” with their Lego, all the while yelling at us old fogies for being old and fogey.
I agree. I consider ”Out of scope” to be the unofficial Wayland motto.
The summary at the end is a beautiful soup of contradictions.
> Slow down the protocol
It’s already fairly slow.
> write a specification
That’s what a protocol is, isn’t it?
> focus on improving your protocol extensions
By that do you mean adding more? I thought the protocol was developing too quickly?
> support more Xorg programs
The charitable interpretation is that it means “support more Xorg use cases”, which is completely valid. The way it’s said would also allow for the interpretation that the author hasn’t understood what Wayland is and wants X APIs added.
> work on performance, stability, and accessibility
The protocol allows for very high performance. If individual compositors are inefficient, please talk to their maintainers. This isn’t an issue with Wayland in general. Same deal with stability. The compositor I use (wayfire) is super stable. Unfortunately I can’t comment much on accessibility other than that I know that Linux has historically been pretty bad in this area.
> Invest more in third-party implementations like wlroots.
With it defining the third compositor type besides KDE and GNOME I think wlroots is seeing an healthy amount of investment. What’s going too slowly for my taste is the standardization and adoption of wlroots protocols by other compositors (will GNOME ever care about what other people are doing? Will they stay incompatible forever?).
> Your ecosystem has real problems that affect real people. It’s time to stop ignoring them.
I completely agree. The “out of scope” meme may have been holding Wayland back. We need much more standardization, akin to the XDG standards. There’s still a lot to do.
-
Flameshot, powerful screenshot tool, fully support Wayland (able to run on sway)
wlrobs has issues for me with 2 screens of different densities. With xdg-desktop-portal-wlr the Pipewire route will work as well.
My favorite way to record on wlroots compositors is wf-recorder, which seems to be lighter on resources than the others.
There's also a fork of SimpleScreenRecorder (with similar issues, unfortunately).
Here's an overview of screencasting tools for wlroots based compositors like Sway and Wayfire: https://github.com/solarkraft/awesome-wlroots#screencasting
-
NVIDIA continues tweaking their work for hardware accelerated Xwayland support
It's true, it's going to drag on for years. But Wayland is creeping into the mainstream. It has been the default on Gnome for a good while and Gnome Wayland is going to be the default in Ubuntu's new release. KDE is a bit behind but also on it, promising "production level quality" until the end of this year. At the same time a new class of compositors without any X heritage is emerging around the wlroots library.
What are some alternatives?
slurp - Select a region in a Wayland compositor
cinnamon-screensaver - The Cinnamon screen locker and screensaver program
swappy - A Wayland native snapshot editing tool, inspired by Snappy on macOS
gamescope - SteamOS session compositing window manager [Moved to: https://github.com/ValveSoftware/gamescope]
wayland-protocols - Wayland protocol development (mirror)
xdg-desktop-portal - Desktop integration portal
kanshi - Dynamic display configuration (mirror)
gamescope - SteamOS session compositing window manager
wl-clipboard - Command-line copy/paste utilities for Wayland
xdg-desktop-portal-wlr - xdg-desktop-portal backend for wlroots
flameshot - Powerful yet simple to use screenshot software :desktop_computer: :camera_flash: