dudik/herbe

Daemon-less notifications without D-Bus. Minimal and lightweight.

dudik

dudik

herbe's Issues

segfault

Every time: herbe hi segfaults.

Backtrace:

#0  IA__FcUtf8ToUcs4 (src_orig=src_orig@entry=0x7ffffffff000 <error: Cannot access memory at address 0x7ffffffff000>, dst=dst@entry=0x7fffffffd0ec,
    len=len@entry=21) at fcstr.c:639 (/lib/libfontconfig.so.1)
#1  0x00007ffff7db0c89 in IA__FcUtf8ToUcs4 (src_orig=src_orig@entry=0x7ffffffff000 <error: Cannot access memory at address 0x7ffffffff000>,
    dst=dst@entry=0x7fffffffd0ec, len=len@entry=21) at fcstr.c:636 (/lib/libfontconfig.so.1)
#2  0x00007ffff7df6c49 in XftTextExtentsUtf8 (dpy=0x7ffff7921040, pub=pub@entry=0x7ffff7810b30,
    string=0x7ffffffff000 <error: Cannot access memory at address 0x7ffffffff000>, string@entry=0x7fffffffefe0 "", len=21, len@entry=53,
    extents=extents@entry=0x7fffffffe14c) at xftextent.c:228 (/lib/libXft.so.2)
#3  0x00005555555563b1 in get_max_len (string=string@entry=0x7fffffffefe0 "", font=font@entry=0x7ffff7810b30,
    max_text_width=max_text_width@entry=420) at herbe.c:46
#4  0x0000555555556695 in main (argc=2, argv=0x7fffffffe4d8) at herbe.c:136

Apply patchs

Hello guys,

I don't know if I being stupid or what, but I only able to apply one patch. It's possible to use more than one? I'm applying like this

curl https://patch-diff.githubusercontent.com/raw/dudik/herbe/pull/25.diff | git apply

What am I doing wrong?

How to build on FreeBSD?

Hi can you fix so I can compile on FreeBSD. I have Xlib headers installed already.
herbe.c:1:10: fatal error: 'X11/Xlib.h' file not found
#include <X11/Xlib.h>
^~~~~~~~~~~~

[Question] Could herbe interpret ansi escape sequences?

Could herbe interpret ansi escape sequences? It would be really useful with some commands like cal which use* ansi escape sequence to highlight current date.

*(at least it seems like it does)

If it's not possible for what ever reason (or would add unnecessary complexity (I like my programs minimal ;) )), supporting multiple text colors would also be awesome (with it's own escape codes like e.x. %c0 %c1, etc.), but if there isn't simple way of doing this, or it's more fit for a patch, I won't mind not having it.

PS: Thank you dudik, herbe is awesome!

Set window title, class, and window type.

Hello, It's usefull to set the window title, class and window type for those that have custom rules in the window manager/compositor that handles notification windows differently. In my case I like to set fading just for notification windows.

This page here basically implements this as intended. If this is wanted I will gladly make a pr. Thanks for making this program.

Man page

Is it possible to get a manpage for this? Mainly summarising the contents of the README's "Usage" section. I'd be willing to write it myself if necessary.

start herbe in xinitrc

I could see the notification window if I run:

herbe "Notification body" && echo "This is an action"

Then, I added herbe & in my .xinitrc. I send a notification with notify-send "Title" "Body" but can't see the notification window.

patch: dynamic window width

The width of the window is equal to the length of the text (made with chatGPT)
herbe.txt

herbe don't update

basically i have a archlinux build with herbstluftwm and herbe. i don't want to use a statusbar so i use herbe instead, basically i press F1 and open a notification that show me the battery percentage, time, date ecc. but the values doesn't update. for example: i open herbe at 12:00
and i have 100% battery if i open herbe 2 hours later the battery is still on 100% but if i reload herbstluftwm the values are updated and i can se the real percentage of battery

Display is too short.

How do I lengthen the amount of time the notification is displayed?

Monitor

How can I select what monitor to display notifcations? I have 2 monitors and I'd like it on monitor 1 but it shows on monitor 2.

Patch proposition: multiple color schemes

Hello

I've been playing around with hastinbe's command-line options patch
And I've come down to this version to compile herbe with a set of colorschemes,
and an option to chose from them at runtime.

In the example config.def, there's a blue-ish default color, a gray-ish "low" mode and a red-ish "high" mode.

I can enjoy playing around with C, but I'm sorry, I still will not learn git while the manpages are such a mess.
I've already spent more than an hour today trying to submit a pull request with my patch, and I give up :
Below is the content of the patch, feel free to put it somewhere it belongs, I don't even ask that you mention me as author.

commit 0de261c94a8dc209e4c20194151ba75b6647f0bd
Author: Arsaell
Date: Tue Apr 18 17:50:41 2023 +0200

[Arsaell] Creation of patch: multiple_color_schemes.diff

Depends on diff "Add minimalistic command-line options" #18
which should be applied prior.

Default option is `herbe -c [0-n] BODY` to switch between
pre-defined color schemes

diff --git a/config.def.h b/config.def.h
index 86b7e76..4056484 100644
--- a/config.def.h
+++ b/config.def.h
@@ -1,6 +1,16 @@
-static const char *background_color = "#3e3e3e";
-static const char *border_color = "#ececec";
-static const char *font_color = "#ececec";
+#define COLOR_SCHEMES_COUNT 3
+
+//Color schemes
+enum {SchemeNorm, SchemeHigh, SchemeLow}; 
+
+static char *colors[COLOR_SCHEMES_COUNT][3] = {
+/*		Name			  background	border		font	*/
+	[SchemeNorm]	=	{ "#152544",	"#005577",	"#00bbdd" },
+	[SchemeHigh]	=	{ "#442222",	"#cc0000",	"#ccbbbb" },
+	[SchemeLow]		=	{ "#222222",	"#444444",	"#bbbbbb" }
+};
+static unsigned int default_color_scheme=SchemeNorm;
+
 static const char *font_pattern = "monospace:size=10";
 static const unsigned line_spacing = 5;
 static const unsigned int padding = 15;
@@ -15,5 +25,13 @@ enum corners corner = TOP_RIGHT;
 
 static const unsigned int duration = 5; /* in seconds */
 
+
+
 #define DISMISS_BUTTON Button1
 #define ACTION_BUTTON Button3
+
+#define VERSION_STRING "1.0.0"
+
+#define EXIT_ACTION 0
+#define EXIT_FAIL 1
+#define EXIT_DISMISS 2
diff --git a/herbe.c b/herbe.c
index 389a2df..cf1b0df 100644
--- a/herbe.c
+++ b/herbe.c
@@ -68,8 +68,8 @@ static void die(const char *format, ...)
 
 static int handle_options(const char ***argv, int *argc)
 {
-    const char **orig_argv = *argv;
+    const int orig_argc = *argc;
     while (*argc > 0) {
         const char *cmd = (*argv)[0];
         if (cmd[0] != '-')
@@ -82,6 +82,13 @@ static int handle_options(const char ***argv, int *argc)
             print_version();
             exit(0);
         }
+
+        else if (!strcmp(cmd, "-c")) {
+            default_color_scheme=atoi((*argv)[1]);
+	        (*argv)++;
+	        (*argc)--;
+        }
+
         else {
             fprintf(stderr, "Unknown option: %s\n", cmd);
             usage(herbe_usage_string);
@@ -90,7 +97,8 @@ static int handle_options(const char ***argv, int *argc)
         (*argv)++;
         (*argc)--;
     }
-    return (*argv) - orig_argv;
+
+    return orig_argc - *argc;
 }
 
 int get_max_len(char *string, XftFont *font, int max_text_width)
@@ -246,7 +254,13 @@ int main(int argc, char *argv[])
 
 	/* Look for flags.. */
     av++;
-    handle_options(&av, &argc);
+
+    int options_count=handle_options(&av, &argc);
+
+	char *background_color=colors[default_color_scheme][0];
+	char *border_color=colors[default_color_scheme][1];
+	char *font_color=colors[default_color_scheme][2];
+
 
 	const char* id =getenv("HERBE_ID");
 	mqd_t mqd=-1;
@@ -322,7 +336,7 @@ int main(int argc, char *argv[])
 	attributes.border_pixel = color.pixel;
 	font = XftFontOpenName(display, screen, font_pattern);
 
-	constructLines(argv+1, argc-1);
+	constructLines(argv+1+options_count, argc-1);
 
     int y_offset_id;
     unsigned int *y_offset;

Feature request: Wayland support

psuedodaemon brainstorm

I haven't really tested, maybe it isn't a problem, but i fear that with this new queuing of messages, it might get a bit complicated if one would do something like:

herbe -x 500 "msg1"
herbe -x 1000 "msg2"
herbe "msg3"

That was actually my main motivation adding the commandline-options ( #3 ), having different geometry for different notificatoins. I have been experimenting a bit with a flow like this:

tl;dr as long as a notification is visible a daemon and socket is open

herbe "msg1" 
# will start a herbe daemon and open a "local" socket, and start a timeout timer, 
# when time is up, notification, daemon and socket are killed

herbe -t 10 "msg2"
# if the daemon is running, -t 10 and "msg2" is sent to the daemon via the socket, 
# "msg2" notificatoin will get created and displayed immediately, 
# and "10 seconds would get added to the current timeout". (kind of)

Benefit of doing it this way is that herbe by default will be "executed in the background", like dunstify. But it will be easy to also add a --block option so that execution of herbe command will terminate when the notification is terminated. It will also be easy to add an ID system, so one can emulate f.i. dunstify --replace ID which is a feature i use a lot with dunstify.

It will however make the program a little bit more complex, but not that much. And it is almost not fair calling it a daemon either, since the daemon only exist as long as there are visible notifications. It will also ofc make startup a little bit slower when the daemon and socket doesn't exist (meaning most of the time). imho, that will never be a problem for any usecase of a notification program.

And i also envision this:

herbe -x 10 -y 10 "msg1"
herbe -x 100 -y 500 "msg2"

Above code would result in two independent notifications displayed at the same time, but managed by the same process (the daemon). More options like --font and --color could ofc also be used.

But sometimes one might want to queue a notification (having the same behaviour as herbe currently have), and i don't think it would be a big deal adding a --queue option.

---

I have tried some of this out in my own messy not public fork, and i don't think any external libs are needed, and when it is clean it will not be that noisy (both linecount and complexity). But as you can imagine, this change will not really work as a "patch"...

Migrate from signal to sigaction

According to the man page for signal(2) it's use is discouraged in favour of sigaction(2). Migration is very easy (Just make two sigactions, one for expire and for ignore. I've already tested this on my fork and it's quite easy. This is not crucial as signal(2) obviously works, but I think it's always good to try and use more up to date apis.

Feature request: Backward-compatible IPC

I can achieve this by using tiramisu, but would be awesome to have this feature natively and without external dependencies(if possible 👍)

Support for fallback fonts

It would be nice if herbe could accept, instead of a single font_pattern, an array containing all the fonts needed(for example Emojis), similarly to how dwm and dmenu handle fonts.

herbe doesn't close itself (sometimes)

I'm on alpine linux, using dwm in floating mode, herbe as standalone, and this script to put herbe in the background 'setsid nohup $@ &> /dev/null &'. Can't reproduce it at will, but often notice notification has stopped and have to find the herbe notification to click it away manually.

Anyone know what the issue could be?

Patch to make herbe not appear when the focused window is fullscreen

I liked a lot this program, and i can almost substitute dunst. But the only problem that i have is that it shows when there is a fullscreen window. It wold be nice if when herbe is called and the focused window is a fullscreen window it waits to display the output.

I don't know c or xlib well enough, but i found a post in the arch linux forums with a solution to find if the focused window is fullscreen via the _NET_WM_STATE property.

#include <stdio.h>
#include <stdlib.h>
#include <X11/Xatom.h>
#include <X11/Xlib.h>

int
main()
{
    Atom prop_fullsrceen, prop_type, prop, da;
    char *an;
    Display *dpy;
    int di;
    int status;
    unsigned char *prop_ret = NULL;
    unsigned long dl;
    dpy = XOpenDisplay(NULL);

	Window focused;
	int revert_to;
	XGetInputFocus(dpy, &focused, &revert_to);

    prop_type = XInternAtom(dpy, "_NET_WM_STATE", True);
	prop_fullsrceen = XInternAtom(dpy, "_NET_WM_STATE_FULLSCREEN", True);

    status = XGetWindowProperty(dpy, focused, prop_type, 0L, sizeof (Atom), False,
                                XA_ATOM, &da, &di, &dl, &dl, &prop_ret);

    if (status == Success && prop_ret)
    {
        prop = ((Atom *)prop_ret)[0];

        /* Debug output, not really relevant: Re-resolve atom number to
         * printable name */
        an = XGetAtomName(dpy, prop);
        fprintf(stderr, "Type found: %s\n", an);
        if (an)
            XFree(an);

        /* Compare internal atom numbers */
        if (prop == prop_fullsrceen)
            fprintf(stderr, "It's a fullscreen window\n");
    }
	exit(EXIT_SUCCESS);
}

If anyone could give me a tip on how to do this i would appreciate it.

Thanks!

Using herbe in a cronjob

Hi,

I wanna set up a cronjob to let me know when my battery is dying.
So basically I wrote a script that plays a sound and displays a notification with herbe when the battery level is too low. It works fine when I run it from my terminal but cron fails to run herbe.
Adding export DISPLAY=:0 in the script does not make the trick.
The arch wiki also suggests to:

• set up a DBUS variable which obviously won't help
• Use xuserrun but it has systemd as dependency and I intend to run this on void

Is there another global variable I gotta set ? Or is herbe simply not sable in a cronjob ?

Thanks

patch: first argument is Title.

first argument gonna showed big on top and other arguments gonna be normal.

diff (.txt suffix added bc github didn't accepted .patch suffix.)
my fork repo isn't on github and that's why I did "issues" instead of "Pull requests", sorry if that's not good
my fork repo is: https://git.vern.cc/mertoalex/herbe-title-patched

Publish Herbe to the AUR

I'm not sure if you use the AUR, but if you do, it would be very nice to have this on there. You're actively improving it, so being able to easily update it through the normal commands would be very nice.