gabm
A layer-shell mode?
Hey there,
Satty is really great, thanks for this. But I'm still looking for a similar program that would run as a layer-shell. The idea would be to draw above the outputs, for a presentation by example. I think it would need an additional button to toggle the event listener, so that we could interact with the underlying surfaces.
Is it something someone already thought about? It is doable in the scope of Satty? Or does someone knows about an existing program that would behave this way?
Thanks!
Fullscreen doesn't work well on Sway if you already have another fullscreen window open, i.e. a fullscreen video game. Using layer-shell would fix this issue.
I meant that instead of giving a filename as argument, you would run Satty above the existing outputs. Then the clipboard button would take a screenshot, apply the user drawing, and yank the resulting image.
Exactly what I came here to ask for. Basically make Satty also a screen annotation tool, not just screenshot. I can't imagine how hard would that be but I guess just making it layer-shell and transparent should be enough?
I meant that instead of giving a filename as argument, you would run Satty above the existing outputs. Then the clipboard button would take a screenshot, apply the user drawing, and yank the resulting image.
This would also be cool! I think there are usecases for both - my usecase is to be able to annotate screenshots taken when an app is fullscreen on Sway (I currently have to un-fullscreen the game and the fullscreen satty to use it). But live annotation would also be really neat.
I like both ideas. I do see a tool scope challenge with the live annotation. Right now we are taking files from stdin, file input. Potentially clipboard (not wl-paste pipe when starting Satty) or file dialog in the future, both of which don't really change how Satty works.
If we do live annotation, we somehow have to acquire a screen copy at some point or we can't save the result. That means either implementing Wayland protocols, or do some shell trickery. The former changes considerably how the tool works right now, the latter might add some unwanted latency.
If we do live annotation, we somehow have to acquire a screen copy at some point or we can't save the result.
Not necessarily. At least not for the initial functionality.
If just the annotation part is implemented (by running satty without any inputs on the top layer of the screen with transparent background for example), then user should be able to take a screenshot by other means if one is needed.
I understand that this will render the clipboard-copy and -o options useless for this specific use case however.
On the other hand, in my opinion, that wouldn't change the scope of Satty, as it is primarily an annotation tool and the file/clipboard management is essentially just a way to use the result of the annotation. On-screen annotation can be thought of as a use on its own which does not necessarily require saving.
Yes and no. I agree that annotation is the primary use case, but we want satty to have some control over "what" to save.. at least to not save the toolbars, when working fullscreen or to leave crop within sattys scope.
I thought about implementing a wayland protocol to capture the screen itself.. I am open for this, its the most "useful" way, even for satty without layer-shell mode. There is no problem with accepting images as input as this would be just another "source of input image"
@stacyharper
Or does someone knows about an existing program that would behave this way?
The only tool that I managed to convince to "work" somehow is gromit-mpx but it's X11 and runs through Xwayland. You need to do a lot of hacks that are specific to your compositor. Here are some tips on how to make it work on Hyprland. I wasn't too happy with it, but there's nothing else (that I could find and make work).
@gabm
but we want satty to have some control over "what" to save.. at least to not save the toolbars, when working fullscreen or to leave crop within sattys scope.
That's assuming save is something the user requires in the first place (fair point with the toolbars, didn't think of that). It of course makes sense for image annotation but for (live) screen annotation, that might not be the case. In my very humble opinion, even screen annotation without save would mean a great deal.
Moving Satty to layer-shell (optionally) would solve most of the use cases mentioned here rather easily I think but other solutions might be viable, too. For instance just allowing Satty to start without an input image and have the window transparent would be useful for pretty much all screen annotation use cases except when annotating on top of fullscreen windows (like games) - though I think even that might be somehow doable with some compositor hacks (like special workspaces - as mentioned in the gromit reddit thread above).
As for making a screenshot of an annotated screen - it's still better to remember to hide the toolbars before hitting whatever the key combo for grim the user has set than having no screen annotation at all.
also,
There is no problem with accepting images as input as this would be just another "source of input image"
This can already be done by piping a screenshot to Satty directly and making sure it starts in fullscreen but it could prove a bit more complicated when fast action is needed - now it takes Satty some time to start which would make this approach rather impractical regardless of implementation details - unless Satty could run in some kind of daemon mode but I guess that would require a lot of work. That would be neat but it's out of scope of this issue.
Just stumbled across https://github.com/devmobasa/wayscriber on Reddit. I haven't tried it out, but looks like that's a tool that covers this use case.
@RobertMueller2 I have tried it out, and made a few prs and issues. The author uses ai, and you realize this very quickly from the development experience. I'm not sure I can formulate my thoughts precisely enough, but personally I wouldn't bet my effort on wayscriber. Matter of fact, I'm coming back to satty right now after exhausting my desire to get involved with wayscriber.
But it does indeed fulfill the usecase. Good program to use, bad program to contribute to, in my experience. So I'd rather not get attached to it, you know? I prefer programs I can conceivably maintain a soft fork of (which I'll probably do with satty)