C libdbus:从DBusMessage参数获取字符串列表

C libdbus:从DBusMessage参数获取字符串列表,c,linux,dbus,C,Linux,Dbus,我最近通过编写一个简单的工具,向活动媒体播放器发送消息,学习了libdbus 第一步是通过DBU获取媒体播放器列表: // send the ListNames command over the DBus DBusMessage* msg = dbus_message_new_method_call( "org.freedesktop.DBus", "/", "org.freedes

我最近通过编写一个简单的工具,向活动媒体播放器发送消息,学习了
libdbus

第一步是通过DBU获取媒体播放器列表:

    // send the ListNames command over the DBus
    DBusMessage* msg = dbus_message_new_method_call(
        "org.freedesktop.DBus",
        "/",
        "org.freedesktop.DBus",
        "ListNames");

    // send the message
    DBusPendingCall* call;
    dbus_bool_t success = dbus_connection_send_with_reply(con, msg, &call, 100);
    if (!success || call == NULL) return 1;

    // wait for a reply
    dbus_pending_call_block(call);

    // check reply
    DBusMessage* reply = dbus_pending_call_steal_reply(call);
现在,我必须解析DBus回复以获得媒体播放器名称列表。 阅读参考资料后,我认为这应该可以通过以下方式实现,如文件所述:

支持字符串、对象路径和签名数组;但这些将作为分配内存返回,必须使用dbus\u free\u string\u array()释放。[…]获取“char***array_location”和“int*n_elements”中的字符串数组传递

这让我写了以下内容:

    // pull list of players from reply
    const int MAX_ARGS = 10;
    const char** args;
    dbus_message_get_args(reply, &err, DBUS_TYPE_ARRAY, &args, &MAX_ARGS);
但在检查DBusError时,我得到以下消息:

DBus错误: org.freedesktop.DBus.Error.InvalidArgs 参数0被指定为“未知”数组,但实际上是“字符串”数组

我最初认为我一定传递了一个坏的
DBUS\u类型
,但找不到比
DBUS\u类型
更合适的数组

我知道,通过使用
dbus\u message\u iter
调用也可以做到这一点,但文档似乎表明这是不必要的,甚至建议尽可能使用
get\u message\u args


所以实际的问题是……我是否遗漏了文档中的某些内容,或者调用函数时出错了?或者,使用这种方法确实无法获取字符串列表?

建议不要使用
libdbus-1
,因为它是一个非常低级的D-Bus库,而且正如您所发现的,它很难使用

使用更高级别的D总线库,如或。你会让你的生活轻松很多


请参阅。

我建议一定要阅读libdbus源代码,但类似的内容是我的回忆:

dbus_message_get_args(reply, &err, DBUS_TYPE_ARRAY,
        DBUS_TYPE_STRING, &args, &len, DBUS_TYPE_INVALID);
请注意,
len
不是您可以指定的最大长度:libdbus将在此处写入数组的实际长度。我不是100%确定这里的参数顺序,您可能需要阅读源代码才能确定


如果您现在想“但那将是一个带有糟糕文档的奇怪API”。。。你可能是对的:正如Philip提到的,在2020年使用libdbus不是一个好的选择。

嗨,谢谢你的建议,我知道所有这些,但除了新颖性之外,我并不完全出于任何实际原因使用这个库,所以我想继续寻找这个问题的直接答案这看起来是正确的,我会尽快尝试,一旦我回到这个工作,并会让你知道它是否有效:D完全切线:我想知道,不清楚的文档是否会保证一个库被完全放弃,但我记得,我也只是触及这个库的表面,可能有更糟的问题hahaIt不是我想要的要放弃libdbus,更重要的是,例如GDBus是一个更好的API,几乎没有缺点(基本上libdbus是低级的,比较起来很难正确使用,但没有提供任何主要的好处):因此,更合理的问题是“为什么我要使用一个劣质的API?”。可能会有一些边缘案例,libdbus是一个不错的选择,但我个人还没有看到。GDBus也需要一些学习,但一旦你弄明白了,处理复杂的方法/信号签名就比使用libdbus容易多了。刚刚确认了这个修复方法,效果非常好:)tyvm