Re: [dev] Announcing a couple small X11 utilities
On 15.02.24 03:47, NRK wrote: maybe also announce it on xorg-announce ? IMHO it's good to get some more publically visible traffic on X tools, showing that X isn't dead at all. by the way: I'd recommend using spdx-license-identifer tag instead of redundant license texts in individual sources - also makes it easier for distros etc. --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: [dev] Announcing a couple small X11 utilities
Hi, > I've addressed most of your concerns, please check the attached patch > and let me know what else can be done. I've added a commit to `selx` that allows you to pick a monitor [0]. You can either use the cli flag: $ sxot -g $(selx -m 0) or select a monitor interactively via Ctrl+RightClick: $ sxot -g $(selx) The reason I haven't added it to `sxot` is because I'm assuming that there are existing "standard" tools that can extract monitor information already (xrandr maybe?). So it's better to reuse those existing tools. But if that assumption turns out to be incorrect then I might reconsider. [0]: https://codeberg.org/NRK/selx/commit/cbf753b97fbefe31c2553fa629878d20df88e6e3 - NRK
Re: [dev] Announcing a couple small X11 utilities
On Thu, Aug 17, 2023 at 11:08:58PM +0200, Max Schillinger wrote:
> -CROP_CFLAGS = ${CFLAGS} ${DB_CFLAGS} -Wall -Wextra -D_POSIX_C_SOURCE=200809L
> `pkg-config --cflags x11` `imlib2-config --cflags`
> -CROP_LDFLAGS = ${LDFLAGS} ${DB_LDFLAGS} `pkg-config --libs x11`
> `imlib2-config --libs` -lm
> +CROP_CFLAGS = ${CFLAGS} ${DB_CFLAGS} -Wall -Wextra -D_POSIX_C_SOURCE=200809L
> `pkg-config --cflags x11` `pkg-config --cflags --libs imlib2`
> +CROP_LDFLAGS = ${LDFLAGS} ${DB_LDFLAGS} `pkg-config --libs x11` `pkg-config
> --cflags --libs imlib2` -lm
Thanks, I hadn't noticed this because I'm currently on a system that
still includes imlib2-config. I replaced it with pkg-config now
since that also works on my system. I added a note in case there are
any old systems around still that don't have pkg-config files for
imlib2 yet.
> And it wasn't obvious to me that I have to exit croptool via dwm to get
> some output. It would be nice if it supported a common shortcut like
> Ctrl-q to quit.
I added 'q' to exit now, like feh and sxiv. If I ever get around to it, I
might make it easier to configure that like in dwm. For now, you need to
look at the function 'key_press' at the bottom of croptool.c if you want
to modify any of the key bindings.
Thanks for the feedback!
--
lumidify
Re: [dev] Announcing a couple small X11 utilities
tor 2023-08-17 10:19:01 skrev Max Schillinger:
> On Tue Jul 4, 2023 at 3:51 PM CEST, NRK wrote:
> > sx4
> > ===
> >
> > This one is a selection tool. It outputs the selection rectangle to
> > stdout which can then be used for other purposes, such as screenshoting
> > or screen-recording a specific area.
>
> All these tools are great! Thanks for sharing.
>
> I don't do much image processing but when I do, it's most often cropping
> images. Of course, GIMP can do this. But it's huge. I usually use nomacs
> instead. But now the nomacs package for Arch Linux is broken because of
> dependencies. Now I use gThumb as a replacement but it's also big.
>
> When I heard about sx4, I was wondering if it's somehow possible to
> connect sxiv, sx4 and ImageMagick. I could open an image with sxiv (or
> feh or something simple) without any zoom, then I could select a region
> with sx4 and pass it to ImageMagick. For this I would have to correct
> the coordinates by the offset of the canvas relative to the screen. This
> seems to be the missing link.
>
> Any ideas how to achieve this?
I think this can be done with (image|graphics)magick import, simply
`import cropped.png` and select the region you want.
I do a lot of cropping using some ugly hacks, attached diff is for
nsxiv master and uses ctrl-q to crop the active image to what is
currenly visible, regardless of zoom (a 100x100 window at 400% zoom
will give a 25x25 image). (Replace 'mogrify -crop' with some wrapper
script if you don't want to accidentally destroy images..)
>
> Regards,
> Max
>
diff --git a/commands.c b/commands.c
index 97cadf2..ff80201 100644
--- a/commands.c
+++ b/commands.c
@@ -253,6 +253,24 @@ bool cg_change_contrast(arg_t d)
return change_color_modifier(d, );
}
+bool ci_crop(arg_t _)
+{
+ char geo[64];
+ char *argv[5];
+ int x, y, w, h;
+
+ x = MAX(0, -img.x / img.zoom);
+ y = MAX(0, -img.y / img.zoom);
+ w = MIN(img.w, win.w / img.zoom);
+ h = MIN(img.h, win.h / img.zoom);
+ if (x == 0 && y == 0 && w == img.w && h == img.h)
+ return false;
+ construct_argv(argv, ARRLEN(argv), "mogrify", "-crop", geo,
files[fileidx].path, NULL);
+ waitpid(spawn(NULL, NULL, argv), NULL, 0);
+ img.dirty = true;
+ return true;
+}
+
bool ci_navigate(arg_t n)
{
if (prefix > 0)
diff --git a/commands.h b/commands.h
index 4e694f0..530c363 100644
--- a/commands.h
+++ b/commands.h
@@ -25,6 +25,7 @@ bool cg_unmark_all(arg_t);
bool cg_zoom(arg_t);
/* image mode */
bool ci_alternate(arg_t);
+bool ci_crop(arg_t);
bool ci_cursor_navigate(arg_t);
bool ci_drag(arg_t);
bool ci_fit_to_win(arg_t);
@@ -72,6 +73,7 @@ bool ct_select(arg_t);
/* image mode */
#define i_alternate { ci_alternate, MODE_IMAGE }
+#define i_crop { ci_crop, MODE_IMAGE }
#define i_cursor_navigate { ci_cursor_navigate, MODE_IMAGE }
#define i_drag { ci_drag, MODE_IMAGE }
#define i_fit_to_win { ci_fit_to_win, MODE_IMAGE }
diff --git a/config.def.h b/config.def.h
index 7fbfb17..c530e8a 100644
--- a/config.def.h
+++ b/config.def.h
@@ -137,6 +137,7 @@ static const keymap_t keys[] = {
{ 0,XK_Right, t_move_sel, DIR_RIGHT },
{ 0,XK_R, t_reload_all, None },
+ { ControlMask, XK_q, i_crop, None },
{ 0,XK_n, i_navigate, +1 },
{ 0,XK_n, i_scroll_to_edge, DIR_LEFT |
DIR_UP },
{ 0,XK_space, i_navigate, +1 },
Re: [dev] Announcing a couple small X11 utilities
> I don't have an answer to your question, but if all you need is
> cropping, I have a shameless plug for a moderately simple tool
> I wrote a while ago: https://lumidify.org/git/croptool/log.html
Nice tool! It works as described. Thank you.
I needed this patch to be able to compile it:
diff --git a/Makefile b/Makefile
index 9f7b524..0952346 100644
--- a/Makefile
+++ b/Makefile
@@ -20,8 +20,8 @@ DB_LDFLAGS = `pkg-config --libs xext`
#DB_CFLAGS = -DNODB
#DB_LDFLAGS =
-CROP_CFLAGS = ${CFLAGS} ${DB_CFLAGS} -Wall -Wextra -D_POSIX_C_SOURCE=200809L
`pkg-config --cflags x11` `imlib2-config --cflags`
-CROP_LDFLAGS = ${LDFLAGS} ${DB_LDFLAGS} `pkg-config --libs x11` `imlib2-config
--libs` -lm
+CROP_CFLAGS = ${CFLAGS} ${DB_CFLAGS} -Wall -Wextra -D_POSIX_C_SOURCE=200809L
`pkg-config --cflags x11` `pkg-config --cflags --libs imlib2`
+CROP_LDFLAGS = ${LDFLAGS} ${DB_LDFLAGS} `pkg-config --libs x11` `pkg-config
--cflags --libs imlib2` -lm
all: ${BIN}
I found this fix here [1]. `imlib2-config` is deprecated if I got it
right.
And it wasn't obvious to me that I have to exit croptool via dwm to get
some output. It would be nice if it supported a common shortcut like
Ctrl-q to quit.
[1]: https://aur.archlinux.org/packages/ipager#comment-865929
For those interested in a solution using feh + sx4 + ImageMagick: I
hacked togehter this little wrapper script. It's far from perfect as it
depends on:
- xdotool being installed
- my shortcut to hide the status bar
- same being visible when the script is started
- a German keyboard layout.
But it works for me :-)
Usage:
crop-image ~/Pictures/cropme.png /tmp/cropped.png
Regards,
Max
---
#!/bin/sh
filename="$1"
filename_cropped="$2"
# disable dwm status bar
xdotool key super+shift+b
feh --borderless "$filename" &
sleep 0.5
# shift+plus = * in a German QWERTZ layout
# '*' zooms to 100% and moves the image to the top-left corner
xdotool search --class feh windowactivate --sync '%1' key 'shift+plus'
geom="$(sx4)"
pkill feh
geom="$(echo ${geom#*,*,} | tr , x)+$(echo ${geom%,*,*} | tr , +)"
magick "$filename" +repage -crop "$geom" "$filename_cropped"
# enable dwm status bar
xdotool key super+shift+b
Re: [dev] Announcing a couple small X11 utilities
On Thu, Aug 17, 2023 at 10:19:01AM +0200, Max Schillinger wrote: > I don't do much image processing but when I do, it's most often cropping > images. Of course, GIMP can do this. But it's huge. I usually use nomacs > instead. But now the nomacs package for Arch Linux is broken because of > dependencies. Now I use gThumb as a replacement but it's also big. > > When I heard about sx4, I was wondering if it's somehow possible to > connect sxiv, sx4 and ImageMagick. I could open an image with sxiv (or > feh or something simple) without any zoom, then I could select a region > with sx4 and pass it to ImageMagick. For this I would have to correct > the coordinates by the offset of the canvas relative to the screen. This > seems to be the missing link. > > Any ideas how to achieve this? I don't have an answer to your question, but if all you need is cropping, I have a shameless plug for a moderately simple tool I wrote a while ago: https://lumidify.org/git/croptool/log.html It's mainly written for cropping many similar images quickly, but I also use it for cropping single images. The actual command for cropping the image is output to stdout (see the manpage). -- lumidify
Re: [dev] Announcing a couple small X11 utilities
On Tue Jul 4, 2023 at 3:51 PM CEST, NRK wrote: > sx4 > === > > This one is a selection tool. It outputs the selection rectangle to > stdout which can then be used for other purposes, such as screenshoting > or screen-recording a specific area. All these tools are great! Thanks for sharing. I don't do much image processing but when I do, it's most often cropping images. Of course, GIMP can do this. But it's huge. I usually use nomacs instead. But now the nomacs package for Arch Linux is broken because of dependencies. Now I use gThumb as a replacement but it's also big. When I heard about sx4, I was wondering if it's somehow possible to connect sxiv, sx4 and ImageMagick. I could open an image with sxiv (or feh or something simple) without any zoom, then I could select a region with sx4 and pass it to ImageMagick. For this I would have to correct the coordinates by the offset of the canvas relative to the screen. This seems to be the missing link. Any ideas how to achieve this? Regards, Max
Re: [dev] Announcing a couple small X11 utilities
Hello,
I've addressed most of your concerns, please check the attached patch
and let me know what else can be done.
Regards,
Yan
On 7/31/23 11:44, NRK wrote:
Hi Yan,
On Sat, Jul 29, 2023 at 02:46:29PM +0200, Yan Doroshenko wrote:
I've created a patch for sxot that adds a -m (--monitor) param that allows
to select which monitor to capture in a multihead setup. Let me know what
you think.
Thanks for the patch, I don't use a multimonitor setup to test it out
properly, but there are already a couple things which aren't too good.
+ int m[1];
+ str_to_int(str_from_cstr(argv[++i]), m);
str_to_int() does certain error checking (such as overflow) and returns
false in case of failure. That return value should not be ignored. It
should fatally error out if str_to_int() returns false.
It's also weird to use `int m[1]` instead of using `int m` and then
taking a pointer.
+ XRRScreenResources *screen;
+ screen = XRRGetScreenResources (x11.dpy,
DefaultRootWindow(x11.dpy));
I'm not familiar with Xrander (and my local manpage is lacking
documentation for this function) but given that it returns a pointer, it
most likely needs to be error checked.
+ XRRCrtcInfo *crtc_info;
+ crtc_info = XRRGetCrtcInfo (x11.dpy, screen,
screen->crtcs[m[0]]);
Same here, most likely needs error checking. But even more importantly:
screen->crtcs[m[0]]
one can never assume anything about data that came from outside. There's
no guarantee that m[0] won't be bigger than the len of `screen->crtcs`.
I see that there's a `ncrtc` member, which likely contains the len of
`crtcs`. You should check to make sure that it doesn't exceed that.
If you compile with AddressSanitizer (see the "recommended debug build"
on the README) and input some absurdly high value, you'll notice the
buffer overflow:
$ ./sxot -m 1024 >/dev/null
=
==11432==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x61a02600 at pc 0x00404271 bp 0x7ffe95aa74a0 sp 0x7ffe95aa7498
And even if you enter a valid value, ASan reports 2 leaks (output
cleaned up):
$ ./sxot -m 0 >/dev/null
SUMMARY: AddressSanitizer: 1296 byte(s) leaked in 2 allocation(s).
So something probably needs to be freed above.
- NRK
diff --git a/sxot.c b/sxot.c
index de87126..094cd7b 100644
--- a/sxot.c
+++ b/sxot.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
typedef uint8_t u8;
typedef uint32_tu32;
@@ -207,7 +208,8 @@ main(int argc, char *argv[])
"usage: sxot [options]\n"
"Options:\n"
" -g, --geomCapture the specified rectangle\n"
- " -c, --curosr Capture the cursor also\n"
+ " -c, --cursor Capture the cursor also\n"
+ " -m, --monitor nCapture the specified monitor\n"
);
Str version = S(
"sxot " VERSION "\n"
@@ -237,6 +239,38 @@ main(int argc, char *argv[])
if (!parse_geom(opt.v, str_from_cstr(argv[++i]))) {
fatal(S("invalid geometry\n"));
}
+
+ } else if (str_eq(arg, S("--monitor")) || str_eq(arg, S("-m"))) {
+ int m;
+ if (!str_to_int(str_from_cstr(argv[++i]), )) {
+fatal(S("invalid monitor number\n"));
+ }
+
+ int n;
+ XRRMonitorInfo *monitors;
+ monitors = XRRGetMonitors(x11.dpy, x11.root, true, );
+
+ free(monitors);
+
+ if (n == -1) {
+fatal(S("get monitors failed\n"));
+ }
+ if (m >= n) {
+fatal(S("no monitor with such index\n"));
+ }
+
+ XRRScreenResources *screen;
+ screen = XRRGetScreenResources(x11.dpy, DefaultRootWindow(x11.dpy));
+ XRRCrtcInfo *crtc_info;
+ crtc_info = XRRGetCrtcInfo(x11.dpy, screen, screen->crtcs[m]);
+
+ opt.x = crtc_info->x;
+ opt.y = crtc_info->y;
+ opt.h = crtc_info->height;
+ opt.w = crtc_info->width;
+
+ free(crtc_info);
+ free(screen);
} else if (str_eq(arg, S("--cursor")) || str_eq(arg, S("-c"))) {
opt.capture_cursor = true;
} else if (str_eq(arg, S("--help")) || str_eq(arg, S("-h"))) {
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [dev] Announcing a couple small X11 utilities
On 7/31/23 11:44, NRK wrote: Hi Yan, On Sat, Jul 29, 2023 at 02:46:29PM +0200, Yan Doroshenko wrote: I've created a patch for sxot that adds a -m (--monitor) param that allows to select which monitor to capture in a multihead setup. Let me know what you think. Thanks for the patch, I don't use a multimonitor setup to test it out properly, but there are already a couple things which aren't too good. + int m[1]; + str_to_int(str_from_cstr(argv[++i]), m); str_to_int() does certain error checking (such as overflow) and returns false in case of failure. That return value should not be ignored. It should fatally error out if str_to_int() returns false. It's also weird to use `int m[1]` instead of using `int m` and then taking a pointer. + XRRScreenResources *screen; + screen = XRRGetScreenResources (x11.dpy, DefaultRootWindow(x11.dpy)); I'm not familiar with Xrander (and my local manpage is lacking documentation for this function) but given that it returns a pointer, it most likely needs to be error checked. + XRRCrtcInfo *crtc_info; + crtc_info = XRRGetCrtcInfo (x11.dpy, screen, screen->crtcs[m[0]]); Same here, most likely needs error checking. But even more importantly: screen->crtcs[m[0]] one can never assume anything about data that came from outside. There's no guarantee that m[0] won't be bigger than the len of `screen->crtcs`. I see that there's a `ncrtc` member, which likely contains the len of `crtcs`. You should check to make sure that it doesn't exceed that. If you compile with AddressSanitizer (see the "recommended debug build" on the README) and input some absurdly high value, you'll notice the buffer overflow: $ ./sxot -m 1024 >/dev/null = ==11432==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61a02600 at pc 0x00404271 bp 0x7ffe95aa74a0 sp 0x7ffe95aa7498 And even if you enter a valid value, ASan reports 2 leaks (output cleaned up): $ ./sxot -m 0 >/dev/null SUMMARY: AddressSanitizer: 1296 byte(s) leaked in 2 allocation(s). So something probably needs to be freed above. - NRK Howdy, Thanks for the feedback. I'm not a C programmer in any way, shape or form so it's completely expected for there to be issues with the code. I'll do what I can about what you've mentioned and come back for feedback or advice if you don't mind. Thanks, Yan OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [dev] Announcing a couple small X11 utilities
Hi Yan, On Sat, Jul 29, 2023 at 02:46:29PM +0200, Yan Doroshenko wrote: > I've created a patch for sxot that adds a -m (--monitor) param that allows > to select which monitor to capture in a multihead setup. Let me know what > you think. Thanks for the patch, I don't use a multimonitor setup to test it out properly, but there are already a couple things which aren't too good. + int m[1]; + str_to_int(str_from_cstr(argv[++i]), m); str_to_int() does certain error checking (such as overflow) and returns false in case of failure. That return value should not be ignored. It should fatally error out if str_to_int() returns false. It's also weird to use `int m[1]` instead of using `int m` and then taking a pointer. + XRRScreenResources *screen; + screen = XRRGetScreenResources (x11.dpy, DefaultRootWindow(x11.dpy)); I'm not familiar with Xrander (and my local manpage is lacking documentation for this function) but given that it returns a pointer, it most likely needs to be error checked. + XRRCrtcInfo *crtc_info; + crtc_info = XRRGetCrtcInfo (x11.dpy, screen, screen->crtcs[m[0]]); Same here, most likely needs error checking. But even more importantly: screen->crtcs[m[0]] one can never assume anything about data that came from outside. There's no guarantee that m[0] won't be bigger than the len of `screen->crtcs`. I see that there's a `ncrtc` member, which likely contains the len of `crtcs`. You should check to make sure that it doesn't exceed that. If you compile with AddressSanitizer (see the "recommended debug build" on the README) and input some absurdly high value, you'll notice the buffer overflow: $ ./sxot -m 1024 >/dev/null = ==11432==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61a02600 at pc 0x00404271 bp 0x7ffe95aa74a0 sp 0x7ffe95aa7498 And even if you enter a valid value, ASan reports 2 leaks (output cleaned up): $ ./sxot -m 0 >/dev/null SUMMARY: AddressSanitizer: 1296 byte(s) leaked in 2 allocation(s). So something probably needs to be freed above. - NRK
Re: [dev] Announcing a couple small X11 utilities
Howdy,
I've created a patch for sxot that adds a -m (--monitor) param that
allows to select which monitor to capture in a multihead setup. Let me
know what you think.
Regards,
Yan
On 7/4/23 15:51, NRK wrote:
Hi all,
I'd like to share some small X11 utilities that I've developed and have
been using in my daily setup. The utilities are all fairly small in
size and requires only typical X libraries.
sxcs
This is a simple color picker and magnifier. My issue with all other
existing minimal color pickers were that due to no magnification,
picking out specific pixels was fairly difficult.
The usage is simple, you launch the program and pick a color. The result
will be output to stdout in tab separated RGB, HSL and HEX format.
Repo: https://codeberg.org/NRK/sxcs
SLoC: ~628
Dependencies: Xlib, libXcursor
sxot
This one is a *very minimal* screenshot tool. I wrote this when I
realized that other cli screenshot tools (scrot, maim) do way too much.
sxot on the other hand is meant to follow the unix philosophy - it
simply takes a screenshot and outputs a binary ppm image to stdout.
Any other functionalities are supposed to be handled by more specialized
tools. E.g sx4 (see below) for selection, optipng to convert to png,
xclip for copying to clipboard etc.
Repo: https://codeberg.org/NRK/sxot
SLoC: ~251
Dependencies: Xlib, libXfixes
sx4
===
This one is a selection tool. It outputs the selection rectangle to
stdout which can then be used for other purposes, such as screenshoting
or screen-recording a specific area.
Repo: https://codeberg.org/NRK/sx4
SLoC: ~500
Dependencies: Xlib, libXext
---
And that's all. Feel free to report any bugs, send bug-fixes, request
additional features (within the project's scope) etc.
- NRK
diff --git a/sxot.c b/sxot.c
index de87126..712ba66 100644
--- a/sxot.c
+++ b/sxot.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
typedef uint8_t u8;
typedef uint32_tu32;
@@ -207,6 +208,7 @@ main(int argc, char *argv[])
"usage: sxot [options]\n"
"Options:\n"
" -g, --geomCapture the specified rectangle\n"
+ " -m, --monitor nCapture the specified monitor\n"
" -c, --curosr Capture the cursor also\n"
);
Str version = S(
@@ -237,6 +239,20 @@ main(int argc, char *argv[])
if (!parse_geom(opt.v, str_from_cstr(argv[++i]))) {
fatal(S("invalid geometry\n"));
}
+
+ } else if (str_eq(arg, S("--monitor")) || str_eq(arg, S("-m"))) {
+ int m[1];
+ str_to_int(str_from_cstr(argv[++i]), m);
+
+ XRRScreenResources *screen;
+ screen = XRRGetScreenResources (x11.dpy, DefaultRootWindow(x11.dpy));
+ XRRCrtcInfo *crtc_info;
+ crtc_info = XRRGetCrtcInfo (x11.dpy, screen, screen->crtcs[m[0]]);
+
+opt.x = crtc_info->x;
+ opt.y = crtc_info->y;
+ opt.h = crtc_info->height;
+ opt.w = crtc_info->width;
} else if (str_eq(arg, S("--cursor")) || str_eq(arg, S("-c"))) {
opt.capture_cursor = true;
} else if (str_eq(arg, S("--help")) || str_eq(arg, S("-h"))) {
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [dev] Announcing a couple small X11 utilities
> On Thu, Jul 06, 2023 at 03:43:31PM -0400, fo...@dnmx.org wrote: > > I love such tools.. Is it possible to make something console-based? > > Most terminal emulators (I think?) already have some option to > dump the screen content into some image format. If not, I don't > think it'd be difficult feature to add to the terminal - > especially for simple image formats like ppm or farbfeld. > > And it makes more sense for it to be done by the terminal > emulator, since it /already/ has parsed all the escape codes and > rendered a pixmap - instead of doing it via an external tool > which would need to duplicate all that work. > > - NRK > Sure that's cool, but ideally the end-goal would be a TTY, without X11/Wayland. In other words: throwing away as much tools/code as possible. Lowerind attack surface, feeling more minimalist and as such less filthy, it's like cleaning a room.
Re: [dev] Announcing a couple small X11 utilities
On Thu, Jul 06, 2023 at 03:43:31PM -0400, fo...@dnmx.org wrote: > I love such tools.. Is it possible to make something console-based? Most terminal emulators (I think?) already have some option to dump the screen content into some image format. If not, I don't think it'd be difficult feature to add to the terminal - especially for simple image formats like ppm or farbfeld. And it makes more sense for it to be done by the terminal emulator, since it /already/ has parsed all the escape codes and rendered a pixmap - instead of doing it via an external tool which would need to duplicate all that work. - NRK
Re: [dev] Announcing a couple small X11 utilities
Whoah, that sounds really amazing! I'm glad you list SLOC and depends :) Althought there's 'xgrab' I think that grabs a RGB color code from screen, and is suckless, I remember reviewing it's source code like a year ago. I love such tools.. Is it possible to make, since you seem to be within the scope, something console-based? Like no X11, no Wayland, just the console and perhaps something like tmux/dvtm :) I'd like to get rid of X11.. I feel sooo dirty for using it. I love that because it gives me motivation to excel even further beyond, to be so much elitist, until there's no one more elite than me (funny, right? I think Terry Davis achieved that before dying) > Hi all, > > I'd like to share some small X11 utilities that I've developed and have > been using in my daily setup. The utilities are all fairly small in > size and requires only typical X libraries. > > sxcs > > > This is a simple color picker and magnifier. My issue with all other > existing minimal color pickers were that due to no magnification, > picking out specific pixels was fairly difficult. > > The usage is simple, you launch the program and pick a color. The result > will be output to stdout in tab separated RGB, HSL and HEX format. > > Repo: https://codeberg.org/NRK/sxcs > SLoC: ~628 > Dependencies: Xlib, libXcursor > > sxot > > > This one is a *very minimal* screenshot tool. I wrote this when I > realized that other cli screenshot tools (scrot, maim) do way too much. > > sxot on the other hand is meant to follow the unix philosophy - it > simply takes a screenshot and outputs a binary ppm image to stdout. > Any other functionalities are supposed to be handled by more specialized > tools. E.g sx4 (see below) for selection, optipng to convert to png, > xclip for copying to clipboard etc. > > Repo: https://codeberg.org/NRK/sxot > SLoC: ~251 > Dependencies: Xlib, libXfixes > > sx4 > === > > This one is a selection tool. It outputs the selection rectangle to > stdout which can then be used for other purposes, such as screenshoting > or screen-recording a specific area. > > Repo: https://codeberg.org/NRK/sx4 > SLoC: ~500 > Dependencies: Xlib, libXext > > --- > > And that's all. Feel free to report any bugs, send bug-fixes, request > additional features (within the project's scope) etc. > > - NRK > P.S. would love to see self-hosted code like on Cgit, or just offer plain files like I do (did and hopefully will) via I2P/Tor) for my shitty unfinished unusable code
Re: [dev] Announcing a couple small X11 utilities
On Tue, Jul 04, 2023 at 04:37:23PM -0400, Sebastian LaVine wrote: > I'm curious, what inspired you to write this instead of using xwd? Never really knew that it existed :) Going by the manpage, it seems to do a bit more than I'd like, but overall it doesn't seem too bad. - NRK
Re: [dev] Announcing a couple small X11 utilities
Cool stuff! On Tue Jul 4, 2023 at 9:51 AM EDT, NRK wrote: > ... > > sxot > > > This one is a *very minimal* screenshot tool. I wrote this when I > realized that other cli screenshot tools (scrot, maim) do way too much. > > sxot on the other hand is meant to follow the unix philosophy - it > simply takes a screenshot and outputs a binary ppm image to stdout. > Any other functionalities are supposed to be handled by more specialized > tools. E.g sx4 (see below) for selection, optipng to convert to png, > xclip for copying to clipboard etc. > > Repo: https://codeberg.org/NRK/sxot > SLoC: ~251 > Dependencies: Xlib, libXfixes > > ... I'm curious, what inspired you to write this instead of using xwd? I've been using a script[0] based on that for many years now. [0]: https://git.sr.ht/~smlavine/scripts/tree/master/item/src/shoot
Re: [dev] Announcing a couple small X11 utilities
On Tue, Jul 04, 2023 at 07:51:59PM +0600, NRK wrote: > Hi all, > > I'd like to share some small X11 utilities that I've developed and have > been using in my daily setup. The utilities are all fairly small in > size and requires only typical X libraries. > > sxcs > > > This is a simple color picker and magnifier. My issue with all other > existing minimal color pickers were that due to no magnification, > picking out specific pixels was fairly difficult. > > The usage is simple, you launch the program and pick a color. The result > will be output to stdout in tab separated RGB, HSL and HEX format. > > Repo: https://codeberg.org/NRK/sxcs > SLoC: ~628 > Dependencies: Xlib, libXcursor > > sxot > > > This one is a *very minimal* screenshot tool. I wrote this when I > realized that other cli screenshot tools (scrot, maim) do way too much. > > sxot on the other hand is meant to follow the unix philosophy - it > simply takes a screenshot and outputs a binary ppm image to stdout. > Any other functionalities are supposed to be handled by more specialized > tools. E.g sx4 (see below) for selection, optipng to convert to png, > xclip for copying to clipboard etc. > > Repo: https://codeberg.org/NRK/sxot > SLoC: ~251 > Dependencies: Xlib, libXfixes > > sx4 > === > > This one is a selection tool. It outputs the selection rectangle to > stdout which can then be used for other purposes, such as screenshoting > or screen-recording a specific area. > > Repo: https://codeberg.org/NRK/sx4 > SLoC: ~500 > Dependencies: Xlib, libXext > > --- > > And that's all. Feel free to report any bugs, send bug-fixes, request > additional features (within the project's scope) etc. > > - NRK > Nice, thanks for sharing :) -- Kind regards, Hiltjo
[dev] Announcing a couple small X11 utilities
Hi all, I'd like to share some small X11 utilities that I've developed and have been using in my daily setup. The utilities are all fairly small in size and requires only typical X libraries. sxcs This is a simple color picker and magnifier. My issue with all other existing minimal color pickers were that due to no magnification, picking out specific pixels was fairly difficult. The usage is simple, you launch the program and pick a color. The result will be output to stdout in tab separated RGB, HSL and HEX format. Repo: https://codeberg.org/NRK/sxcs SLoC: ~628 Dependencies: Xlib, libXcursor sxot This one is a *very minimal* screenshot tool. I wrote this when I realized that other cli screenshot tools (scrot, maim) do way too much. sxot on the other hand is meant to follow the unix philosophy - it simply takes a screenshot and outputs a binary ppm image to stdout. Any other functionalities are supposed to be handled by more specialized tools. E.g sx4 (see below) for selection, optipng to convert to png, xclip for copying to clipboard etc. Repo: https://codeberg.org/NRK/sxot SLoC: ~251 Dependencies: Xlib, libXfixes sx4 === This one is a selection tool. It outputs the selection rectangle to stdout which can then be used for other purposes, such as screenshoting or screen-recording a specific area. Repo: https://codeberg.org/NRK/sx4 SLoC: ~500 Dependencies: Xlib, libXext --- And that's all. Feel free to report any bugs, send bug-fixes, request additional features (within the project's scope) etc. - NRK
