makoctl history returns "type" : "aa{sv}" ....

[plum]

Hello, I want to thnak you for an excellent notification system.

The issue I have here is thwat when I issue the command: $makoctl history

I hope you are able to point out what may be wrong with my configuration, or installation.

What is returned in the terminal (I.E. Kitty), is the following :

{
        "type" : "aa{sv}",
        "data" : [
                [
                        {
                                "app-name" : {
                                        "type" : "s",
                                        "data" : "notify-send"
                                },
                                "app-icon" : {
                                        "type" : "s",
                                        "data" : ""
                                },
                                "category" : {
                                        "type" : "s",
                                        "data" : ""
                                },
                                "desktop-entry" : {
                                        "type" : "s",
                                        "data" : ""
                                },
                                "summary" : {
                                        "type" : "s",
                                        "data" : "mako"
                                },
                                "body" : {
                                        "type" : "s",
                                        "data" : "TESTHISTORY"
                                },
                                "id" : {
                                        "type" : "u",
                                        "data" : 1
                                },
                                "urgency" : {
                                        "type" : "y",
                                        "data" : 1
                                },
                                "actions" : {

(btw NOTE: the actions line bracket is not closed)

I tried the command suggested here, makoctl history | jq -r '.data | .[] | map(select(.summary.data == "Recording" and (.body.data | match("Finished recording")))) | .[0:4] | .[].body.data' | sed -e 's/Finished recording \?//g' | xargs mpv --hwdec=vaapi --vo=dmabuf-wayland

That makoctl command dissapointingly returns results from an mpv query:

mpv v0.37.0 Copyright © 2000-2023 mpv/MPlayer/mplayer2 projects
 built on Jan 19 2024 09:09:45
libplacebo version: v6.338.2
FFmpeg version: n6.1.1
FFmpeg library versions:
   libavutil       58.29.100
   libavcodec      60.31.102
   libavformat     60.16.100
   libswscale      7.5.100
   libavfilter     9.12.100
   libswresample   4.12.100

Usage:   mpv [options] [url|path/]filename

mako version : 1.8.0-1 kernal: linux-lts 6.6.21-1

Thanks, John

[emersion]

Weird, not sure what could cause this. We just use busctl here.

[plum]

@emersion thanks, for thinking about it. It is weird. Seldom ever found anything weird. I suppose I could be pleased about it. (-:

Seriously though, Not sure why you mention busctl - use it for what purpose, in relation to makoctl history? I tried the command $busctl and it gives a list of processes. Neither mako nor makoctl are listed. My mako notifications work alright.

Maybe I should use 'busctl capture' with 'makoctl history' , somehow? I'm trying to figure something out; haven't tried busctl before. Meanwhile, if yo could poin tme the way... that's be nice. John

[mjholub]

@plum From the D-Bus spec:

Type System

D-Bus has a type system, in which values of various types can be serialized into a sequence of bytes referred to as the wire format in a standard way. Converting a value from some other representation into the wire format is called marshaling and converting it back from the wire format is unmarshaling.

The D-Bus protocol does not include type tags in the marshaled data; a block of marshaled values must have a known type signature. The type signature is made up of zero or more single complete types, each made up of one or more type codes.

A type code is an ASCII character representing the type of a value. Because ASCII characters are used, the type signature will always form a valid ASCII string. A simple string compare determines whether two type signatures are equivalent.

A single complete type is a sequence of type codes that fully describes one type: either a basic type, or a single fully-described container type. A single complete type is a basic type code, a variant type code, an array with its element type, or a struct with its fields (all of which are defined below). So the following signatures are not single complete types:

    "aa"

    "(ii"

    "ii)"

And the following signatures contain multiple complete types:

    "ii"

    "aiai"

    "(ii)(ii)"

Container types

In addition to basic types, there are four container types: STRUCT, ARRAY, VARIANT, and DICT_ENTRY.

ARRAY has ASCII character 'a' as type code. The array type code must be followed by a single complete type. The single complete type following the array is the type of each array element. So the simple example is:

      "ai"

which is an array of 32-bit integers.	Category	Conventional Name	Code	Description
container	DICT_ENTRY	101 (ASCII 'e'), 123 (ASCII '{'), 125 (ASCII '}')	Entry in a dict or map (array of key-value pairs). Type code 101 'e' is reserved for use in bindings and implementations to represent the general concept of a dict or dict-entry, and must not appear in signatures used on D-Bus.

v stands for VARIANT and s stands for STRING. So in this case, aa{sv} is a nested array (i.e. array of arrays), where the first element is a map of string: variant pairs. And variant means that type of the value is part of the value itself.

Hope this clarifies this a bit. @emersion I don't think this should be treated as an issue then, as I suppose that if there's someone using this for scripting or planning to do so, expecting the standard dbus spec is pretty implicit.

[emersion]

The "weird" thing is that busctl (used by makoctl) seems to abruptly stop in the middle of the JSON output.

Anyways, mako can't do anything about this. You can isolate the busctl command that makoctl invokes, and report that to systemd, if you can still reproduce.