[Feature request, discussion] Line merging / concatenation

[CarterLi]

Introduction

As requested in #453, we have several modules prints only a few characters (for example, Processes module prints only an integer), it will be nice to merge them into one line.

With the introduction of JSON config, the configuration part for this is possible. I plan to implement Line merging / concatenation in 2.0.

Configuration

{
  "modules": [
    "os", // Normal module
    {
      "type": "host" // Normal module too
    },

    {
      "type": "~", // A special module type indicates that its child modules should be merged.
      "separator": " | ", // The separator between modules
      // should this module have its own key?
      "modules": [
        "shell",
        "terminal" // Print Shell and Terminal information in one line, with default key and formation
      ]
    },
    {
      "type": "~",
      "separator": "", // Don't print separator; default value
      "modules": [
        "cpuusage",
        {
          "type": "processes",
          "key": null, // Don't print key
          "format": " (processes: {1})"
        }
      ]
    }
  ]
}

Expected result:

OS: Arch Linux x86_64
Host: Windows Subsystem for Linux (1.3.11.0)
Shell: fish 3.6.1 | Terminal: Windows Terminal
CPU Usage: 8% (processes: 302)

Design

Principle: line merging should not invade module implementations; that's to say, a module implementation should not care if it's merged or not.

1. Line endings should be handled outside of modules. We print \n everywhere, this requires major code refactoring.
2. Logo (cursor moving) should be handled outside of modules. No ffPrintLogoAndKey

There are modules prints multiple lines (Display, GPU, Disk, LocalIP, etc). This is what I want to discuss. My basic ideas:

1. Add option --compact or --compact-type to force them to print in one line, like --display-compact-type and --localip-compact.
2. In general these modules still print multi lines. However since we are moving logo and line ending handling outside of modules, it will be problematic when printing second line. Therefore a module should not print anything, but generates a list of strings, so that they don't need to take care of other works between printing two lines.

void ffGenerateGPUOutput(FFGPUOptions* options, FFlist output)
{
  FFlist gpus;
  FF_LIST_FOR_EACH(FFGPUResult, gpu, gpus)
  {
    appendGPUResult(options, index, gpu, (FFstrbuf*) FFListAdd(output));
  }
}

To be honest this requires much more code changes and is what I want to avoid. Any easier-to-do ideas?

3. If we get multiple lines in ~ (line merging) module, just concat them normally.

{
  "modules": [
    {
      "type": "~",
      "separator": " | "
      "modules": [
        "gpu"
      ]
    }
  ]
}

Expected result:

GPU 1: Intel(R) Iris(R) Xe Graphics (1.00 GiB) [Integrated] | GPU 2: NVIDIA GeForce RTX 3070 Ti Laptop GPU (8.00 GiB) [Discrete]

The line may be trancated with --disable-linewrap enabled.

Thoughts?

[CarterLi]

Currently an empty key results in printing the default key, and a FFstrbuf can't store a NULL value. So users are unable to hide keys. This is problematic.

[CarterLi]

Doesn't seem to get any interests. Postponed.

[tdtooke]

I probably should have spoken earlier. I would use this, a little at least. It makes sense to have shell and terminal on the same line. I'd probably use it for GPUs as well, I have 2 of them. A lot of theming stuff occupies multiple lines as well and quite often says the exact same thing.

[lightproof]

I'm surprised there is so little feedback on this! I would gladly use it to merge not only shell/terminal, but also DE/WM. And maybe something else.

[Samueru-sama]

I would also love this, would use it to merge the Packages and Kernel lines.

[Paulie420]

I would also use this... I might be missing other methods of 'renaming' titles of sources or merging sources, but this makes sense to me - or however the developer would like to include these types of features. :P Thanks!!

[wendellavila]

I would like to use this as well. Would be great to have cpu + cpuusage on the same line, or theme+wmtheme+lm, os+kernel...

[Samueru-sama]

Worth mentioning that it can be done right now, but it requires a lot of hacks lol

This is how I have my config which merges several modules into one line: https://pastebin.com/ntDAPMFT

I also cache the info of the modules that take a while to load, so that is why some of the modules cat a file in cache.

[Princess-Sunset-Shimmer]

i so like this festure,
and i

    {
        "type": "~",
        "separator": " ",
        "modules": [
            {
                "type": "os",
                "key": null,
                "format": "{4}"
            },
            {
                "type": "kernel"
                "key": null
            }
        ]
    }

ha ha, then it print

Blank, literally blank
😫

[Princess-Sunset-Shimmer]

Currently an empty key results in printing the default key, and a FFstrbuf can't store a NULL value. So users are unable to hide keys. This is problematic.

Soooo, When will it be solved? Tomorrow? TODAY? i got tons of new idea to config fastfetch 20%cooler if you finish adding merging feature to fastfetch

[timoteuszelle]

I didn't see it mentioned yet, it would be nice if next to the formatting options already available, to further extend it with regex.
This would allow for more clean and boxed in strings for the exact (wanted) values to be displayed.
Looking at the current use of the formatting options, this might cause some sort of overhaul to accommodate this?

I realize you could load values in scripts and parse those to the jsonc to get the same results.
Thanks for your attention and consideration.

[spenserblack]

Just started using fastfetch a few minutes ago and already love it!

Might I suggest ["module1", "module2"] as shorthand { "type": "~", "modules": ["module1", "module2"] }, with a reasonable default for separator?

So it would look like this:

{
  "modules": [
    "os",
    ["shell", "terminal"]
  ]
}

and that would be the same as

{
  "modules": [
    "os",
    {
      "type": "~",
      "separator": " | " // or some other default separator
      "modules": ["shell", "terminal"]
    }
  ]
}

With a quick glance at the current schema, I don't think this conflicts with anything.

From an implementation point of view this might be difficult, but as a user this can be nice.