Some question about init of CFFI modules

[Mrpaoo]

###Description
Issue #4976 raise a question about config issue of CFFI modules. When CFFI modules parsing config, it somehow fetch the comment. And i find the thing to blame, in cffi.cpp:60

or (size_t i = 0; i < keys.size(); i++) {
    const auto& value = config[keys[i]];
    if (*wbcffi_version == 1) {
      if (value.isConvertibleTo(Json::ValueType::stringValue)) {
        config_entries_stringstor.push_back(value.asString());
      } else {
        config_entries_stringstor.push_back(value.toStyledString());
      }
    } else {
      config_entries_stringstor.push_back(value.toStyledString());
    }

toStyledString() would fetch the comment here, so i try to tackle it at source include/util/json.hpp:35

Json::CharReaderBuilder readerBuilder;
    if (!Json::parseFromStream(readerBuilder, jsonStream, &root, &errs)) {
      throw std::runtime_error("Error parsing JSON: " + errs);
    }

Here i add readerBuilder[collectcomments] = false but of course tostyledstring() return human readable string so \" remain at the return value.

Although the issue didnt mention his wbcffi_version, i guess it is equal 2 so it hit the toStyledString() branch.

Summary

so i really wanna know, what's the difference between wbcffi_version 1 and others, and what kind of parameter does it really want. And is there any way to parse the raw string from Json::Value without breaking the logical here.

[B2krobbery]

Yeah, this lines up with what you’re seeing in #4976. The behavior isn’t really about JSONC parsing itself, but how Json::Value is being serialized afterward. Even if you disable collectComments, toStyledString() still generates a formatted representation of the value, and it can carry over those comment-like artifacts or extra formatting into the output. So the issue ends up looking like comments are “attached” to the next key, when in reality it’s just how the value is being stringified.
The difference with wbcffi_version == 1 makes this a bit inconsistent too, since it tries to use asString() when possible, but everything else falls back to toStyledString(). With version 2 always using toStyledString(), you basically guarantee this behavior for all types, which is probably why it shows up more clearly there.
I don’t think trying to strip comments after the fact will be very reliable, like you said. A cleaner approach would be avoiding toStyledString() here entirely and using a non-pretty writer (like StreamWriterBuilder with indentation disabled), or just handling types explicitly depending on what the CFFI side expects. Right now it feels like toStyledString() is being used for convenience, but it’s not really suitable when you need clean, predictable values.
If the intention is to pass stable values to CFFI, it might be better to avoid toStyledString() here and use a non-pretty writer instead. For example, using Json::StreamWriterBuilder with indentation disabled would give consistent output without pulling in formatting artifacts. Alternatively, keeping the wbcffi_version == 1 behavior (using asString() when possible) and extending it to handle other types explicitly might be more predictable than always stringifying with toStyledString().

[Mrpaoo]

Yes, tostyledString() should never be apply on string type value otherwise it will always fetch the annoying \", I agree with your point that we should handle other types explicitly, not just for string type. For string type, is it more reliable using asString() since we don't need to deal with any annoying \" or comment.

But another difficulty is that, there is neither a detailed documentation nor a well-mantained cffi module in waybar. So it's wont be easy until we have a standard here.

[B2krobbery]

Yeah exactly, for string values asString() seems like the safest option since it avoids both the escaped quotes and any formatting artifacts. The tricky part is really the non-string types, since toStyledString() ends up being too “lossy” in terms of formatting control.
Maybe a middle ground would be to keep asString() for strings and use a StreamWriterBuilder (with indentation disabled) for everything else, so the output stays consistent but without the extra formatting/comment issues. That way it behaves closer to raw JSON instead of debug-style output.
And yeah, the lack of clear documentation for CFFI modules makes this harder than it should be. It might actually be worth defining what the expected format of config_entries should be (e.g., raw JSON vs stringified values), otherwise different versions will keep behaving inconsistently.

[B2krobbery]

I’ve added a small note in the wiki (Writing Modules) about the current config_entries behavior that might help others. Feel free to adjust if anything needs correction.
https://github.com/Alexays/Waybar/wiki/Writing-Modules

[Mrpaoo]

I just have a more extreme idea that maybe let the CFFI module do all the job, it should be responsible for config parsing, reading its own config file, and separate its config from waybar config file. Because it's hard to make a standard of config format for every module, and put these code all in waybar just make it hard to maintain, and maybe some modules perfer other format, no just jsonc.

Of course it will affect module that are in use, but in the long term i think it will be better. Let the waybar do minimal job: load lib.so, exec the init function, and maybe pass the Json::Value and let module do the rest of them or not(Module decide what kind of format and where to put its config file)

[B2krobbery]

That’s an interesting direction and it would definitely give more flexibility to modules, but my concern is that it shifts a lot of responsibility to module authors, especially for simpler modules that currently rely on Waybar passing values directly, and it could also break existing modules that depend on the current config_entries behavior. Maybe a middle approach would work better, where Waybar keeps basic parsing for simple use cases while allowing more advanced modules to handle their own config if needed, so we maintain backward compatibility while still providing flexibility.