pengui - devlog #8

Hello again! Not gonna lie, but when I found out that stardance is has been extended by another month, I switched myself into procrastination mode.

So what I’ve changed?

• I added ruler
• As I said before that I wanna do this, I rebranded the project from yasu to pengui (but I haven’t updated the stardance page yet)
• Fixed all the errors related to clipboard

See you next devlog 👋

yasu - devlog #7

It’s time to hurry! Here’s what I’ve added/changed since last devlog.

• added toolbar with fancy fonts
• added pipette
• removed glew cuz it’s buggy as hell, now using glbinding

I’ve also fixed minor bugs, tbh I’m little bit worried that there will be no time left to deploy it to flathub. Anyway, It’s time to work work work.

Here’s how it’s looking after the changes:

yasu - devlog #6

So since last devlog I’ve worked on:

• a modular abstraction layer for the main loop
• error dialog popup instead of cerr (works with KDE and GNOME, cerr is used as a fallback)
• adding (very) basic README, for now it only contains build information and even that isn’t complete yet
• some bugfixes with memory and so on

And yeah, that’s it. Refactoring took the biggest part of the time. Now I can move on to other things that I’ve been talking about. Oh, and also I’m thinking about rebranding the project in the near future, I think that this name is silly.
See ya.

yasu - devlog #5

THERE IS GLOW EFFECT!11!!!1 After messing with shaders a lot, I finally finished it and the effect is kinda neat. Under the hood I’m using the exponential function to achieve smooth and nonlinear increase of transparency with distance. In reference to the previous devlog, I’ve successfully rewritten shader loader as a class. Probably you will not notice because it’s very subtle, but there’s also a tween that scales strength of that glow and it lasts something around 0.5s.

Moving on, now I’ll focus on these things:

• screenshot save & clipboard implementation
• basic UI
• configuration
• rewrite of main loop as a class 🤡 (it’s unusable rn due to amount of things in it)

I want to achieve something similar that you can see in game development industry, there is a main loop, and every submodule is another script that is attached to it. Each “attached script” has their own implementation of init and update method so later it can draw things, assign variables and so on.

yasu - devlog #4

Hello, fortunately I’ve recovered from my bipolar delusion of rewriting it in C. Let’s say that this has been a fever dream.

When writing it, I completely forgot about the number of C++ functions I’ve been using for convenience.

Anyway, I’ve implemented dragging. Now you can drag from one point to another, and the rect with blue borders will highlight the area. It works by rendering the same texture (screenshot) that is in the background.

Now I’m fighting with shaders because I want to add fancy dandy animations!!111!1! I’ve implemented a custom loader, but now I’m rewriting it as a class. I can’t show you the classic triangle because it doesn’t work yet

See you next devlog!

yasu - devlog #3

So this has been some time, I was busy with my own things and now I’m back. I have 5 hours of work, but this was something like month or two ago, so to be honest I don’t remember what I was doing. Anyway, I can definitely say that I’ve had a lot of problems with ImGui. And it wasn’t my fault, I’m using Meson WrapDB and there was outdated version that led to memory leaks. When I figured this out, I made a PR to Meson WrapDB with the updated one. That’s all I remember. I came to the conclusion that I probably want to rewrite everything in C, because every library that I’m using is powered by C, not C++. And the only feature of C++ that I use are classes, but my abstraction layer is bloated piece of junk, so whatever.

yasu - devlog #2

Finally, I’ve finished implementing the abstraction layer, so now I’m free from using C libraries in C++ 🥹 Oh wait….. there is glfw here…….

Anyway, there isn’t any visible progress, so that’s why you can see that awesome screenshot (hope staff doesn’t complain 🙏). The codebase in its logic is practically the same, but now it’s packed into a pretty class and I added error handling for everything, so now I can catch every possible exception. Also, I (tried to) get rid of all possible memory leaks and yeah, that’s all.

Now it’s time for the UI. I repeat myself, but I’m going to use GLFW with ImGui. If someone is curious how I’m going to display the screenshots, here’s the explanation:

1. I make one big screenshot with all monitors (that’s how portals work)
2. Then I separate and crop it, so each monitor has it’s own
3. I convert each screenshot to raw pixel buffer
4. For each monitor, I create new window with GLFW and I load the screenshot from that buffer

And later I’ll add things like cropping etc. but that’s the part of UI, so I will be talking about it in the future devlogs!

See ya

yasu - devlog #1

Yasu is an acronym of yet another screenshot utility, I was thinking a lot about the name and that’s what I’ve come up with.

Why?

I’ve been playing a lot with Linux on my servers, but never used it as a main operating system on my desktop. Recently, I finally moved over and I can say that I’m a happy user of openSUSE with KDE Plasma.

But there is one aspect, that annoys me. I love the screenshot app from Windows 11 available under Win+Shif+S shortcut, and none of the popular Linux equivalents satisfies me. Spectacle from KDE is slow and bloated with too many features and buttons, I just want to make a screenshot that goes into my clipboard without thinking which button to click. Flameshot is just OK, but in its design it’s similar to Spectacle.

To be honest, I’m not a fan of screen capture app on macOS too. So maybe later I will add the support for Apple devices. It will not be that hard, because I’m using my own abstraction layer over system’s screenshot function, so I’m going to have implement only that part of the code again.

So, that’s how my idea has born.

Implementation

For this project I went with C++, and no, I’m not using Qt like Spectacle or Flameshot. I’m planning to use OpenGL via GLFW with ImGui for the screen capture UI, and GTK4 for small settings app.

One of my other requirements, is that I want this app to be available on all Linux distros, regardless of the display server (X11/Wayland), desktop environment is (GNOME/KDE) or window manager (Hyprland etc.).

I don’t have any experience in writing apps for Linux, but after a quick research I found that the best solution for me is use of XDG Desktop Portal, and it’s made by Flatpak, so I’ve instant support for it. Double win I can say.

As I’ve said earlier I’m writing my own abstraction layer over native’s screenshot function. So I will be able to implement it both for Linux and later for macOS. And maybe even Windows in the future…

What I’ve done in the past few hours?

I’ve set up the project with Meson as a build system, and…. I’ve captured my first screenshot! Take a look at it. In the first place I tried to use ScreenCast because it’s gives me much more freedom, but finally due to technical reasons I picked Screenshot, main disadvantage of it is that me as a program, receive an URI to a file on a disk, instead of a raw pixels on screen like with ScreenCast. But for the user, it’s much more friendly and safer in terms of application’s permissions. Also, I’m going to have much less compatibility issues later. And also, the given capture, contains all monitors in one image, so I’ve to separate everything by loading the image into RAM, then calculating where is each monitor with GTK, and finally I crop everything with gdk-pixbuf, so I’m left with separate image for each monitor.

Now I’m going to focus on writing the abstraction layer, because I haven’t finished it yet. And after I’ll probably move straight forward to implementing the window with GLFW.

That was a lot of text, more than I would assume. I hope someone is really going to read this. 😉

Oh, and I’ve made amazing logo in Figma, hope you like it!