What do we want to display?

[123marvin123]

In it's current state, Macchina is limited in the amount of displayed data. We should display more information and this issue is here to collect some ideas:

• Disk Usage (implemented by libmacchina, needs to be included in macchina)
• CPU / GPU Temp
• GPU (feature implemented in aparato, and will soon integrate with libmacchina)
  • Linux
  • NetBSD
  • macOS
  • Windows
  • Android
• Screens and their resolution
  • Linux
  • NetBSD
  • macOS
  • Windows
  • Android
• CPU Usage
• Local IP address

Edited by @grtcdr: Migrated to a discussion.

[grtcdr]

I personally would like to start by adding the local IP address, as its the easiest of the bunch.
GPU for example is kind of tricky, maybe the user has 2 or more GPUs, should we split them up?
And do we add a limit to how many GPUs to display to keep the output tidy?

[laurentlbm]

I have a computer with 2 GPUs. neofetch displays both, each having their own line.

[grtcdr]

An important thing to consider is systems with 2 or more, I think limiting the GPU output to 2 is better than having say four lines of:

• GPU0
• GPU1
• GPU2
• GPU3

[laurentlbm]

By default, it could be limited, with an option to show all GPUs.

[grtcdr]

By default, it could be limited, with an option to show all GPUs.

That's a good idea 💡

[grtcdr]

#53 You can now view your local IP address 🚀

[grtcdr]

@123marvin123 We should fetch GPUs next!

We might also want to move this issue to libmacchina as it makes more sense for the issue to be there now that they are separate repositories.

[pfr-dev]

How about an option for smaller ascii art as seen in ufetch and pfetch ?

I'd also love to see even more bar options:

• Disk space
• Screen brightness
• Volume
• Swap usage

I suppose you could also use bars for things like cpu/gpu temps?

Lastly, an option to choose circles or squares in the bar, and an option to have shortened (3 letter) names in the left column. With these options themes would be more customizable.

Cheers,

[grtcdr]

Small ASCII would not look to appealing, it only looks nice on fetchers that fetch a maximum of 5 lines, but it is possible to detect the number of readouts and display a smaller ASCII image if only several readouts are visible.

The other suggestions already do exist, our second theme, "Helium" has three letter keys, and square bars.

Moving bars is not feasible as the point of Macchina is to be a static program that you call, and it writes your information to the terminal as fast as it can, so no while loops.

Storage, backlight and volume information might come in the future, and since they are not yet implemented, each of them needs to be added as a fetchable readout by libmacchina, so Macchina can display it.

[pfr-dev]

it is possible to detect the number of readouts and display a smaller ASCII image if only several readouts are visible.

That would be excellent, as I (and I'm sure others) often only want about 5 lines or output. Again, it would just be nice to have that option.

The other suggestions already do exist, our second theme, "Helium" has three letter keys, and square bars.

Yes, but there is currently no possible way to achieve three letter keys with round bars. Therefore, either adding an option to specify the length of the keys OR an option to specify the shape of the bars would be handy. But ultimately, options for both would negate the need for theme's altogether as you would then be able to completely customise Macchina's output style.

Moving bars is not feasible as the point of Macchina is to be a static program that you call, and it writes your information to the terminal as fast as it can, so no while loops.

I wasn't suggesting moving bars necessarily. Similar to the CPU Usage bar, it just prints out the current state. Same could be done for Swap usage, and cpu/gpu temps.

Storage, backlight and volume information might come in the future, and since they are not yet implemented, each of them needs to be added as a fetchable readout by libmacchina, so Macchina can display it.

Sounds good. I look forward to hopefully seeing these new features in future releases! 👍

[grtcdr]

Hey @Ramiferous!

I wasn't suggesting moving bars necessarily. Similar to the CPU Usage bar, it just prints out the current state. Same could be done for Swap usage, and cpu/gpu temps.

Yeah there was a typo in your message that I should've understood as "more" instead of "move", my apologies.

How about an option for smaller ascii art as seen in ufetch and pfetch ?

Ask and you shall get, here's a sneak peek :^)

Smaller ASCII art is activated when the amount of readouts is less or equal to 6

I made a small NetBSD logo, what do you think?

()ncncncncncncncn
 \\ncncncncncn
  \\ncncncncncncnc
   \\
    \\
     \\

[grtcdr]

UPDATE

I'm working on extending the capabilities of CPU Usage, for now this is exclusive to Linux and NetBSD thanks to the proc filesystem. CPU Usage will be able to display the amount of processes of the host's machine.

This is a Rust-only approach, it is completely safe and no commands are called.

I'm not planning to make a readout for processes, and I'm thinking of appending them to the CPU% (Load), and they are only visible when bars are disabled.

The amount of threads is also exposed by sysinfo but this is Linux only and will land in the future.

[pfr-dev]

Smaller ASCII art is activated when the amount of readouts is less or equal to 6

Excellent! I still think a flag as an option to chose small ascii might be nice.

I made a small NetBSD logo, what do you think?

That cool, I like it! Can the flag be orange/red and the flagpole be grey/black (depending on your theme)

Also, Any thoughts on the cpu/gpu & temp bars?

[grtcdr]

Excellent! I still think a flag as an option to chose small ascii might be nice.

That's a good idea, will do :)

That cool, I like it! Can the flag be orange/red and the flagpole be grey/black (depending on your theme)

I'll try and tweak the colors, as the current choice of color doesn't reflect that of the actual logo.

Also, Any thoughts on the cpu/gpu & temp bars?

They'll definitely come in the future :)

[Staubgeborener]

Anything new about gpu hardware support?

[matrixik]

Thank you for response. I did not know that Rust have such problems with environment variables.

[thorion3006]

can we display the current shell instead of the default shell? or add a new variable called Current Shell? this would come in handy when switching between multiple shells. In neofetch to get this functionality, i just overwrite the SHELL variable with the current shell and it works fine.

[grtcdr]

@thorion3006 Noted :)

[grtcdr]

@thorion3006 see this commit, it's planned to land as a configuration option (and command line flag too).

[thorion3006]

thanks :-)

[grtcdr]

You could take it for a spin if you'd like :)

[Vinegret43]

There's really no good way to do this, shell versions like BASH_VERSION and ZSH_VERSION aren't exposed to rust programs, as macchina is not a shell script

@grtcdr, the fact that Rust cannot access shell's version from std::env is not a problem, you can just run a command like bash -c echo $BASH_VERSION and collect its output. Here i wrote a function for this, it's not very polished but it just shows the fact that it's possible

fn get_shell_version(shell: &str) -> Option<String> {
    let output = std::process::Command::new(shell)
        .arg("-c")
        .arg(format!("echo -n ${}_VERSION", shell.to_uppercase()))
        .output();
    match output {
        Ok(output) => {
            let stdout = String::from_utf8_lossy(&output.stdout).to_string();

            if stdout.is_empty() {
                None
            } else {
                Some(stdout)
            }
        }
        Err(_) => None
    }
}

I tested it with bash, fish and zsh, it works as expected, returning data in format like this:

5.1.8(1)-release
3.2.2
5.8

for these shells, respectively

[grtcdr]

There's really no good way to do this, shell versions like BASH_VERSION and ZSH_VERSION aren't exposed to rust programs, as macchina is not a shell script

@grtcdr, the fact that Rust cannot access shell's version from std::env is not a problem, you can just run a command like bash -c echo $BASH_VERSION and collect its output. Here i wrote a function for this, it's not very polished but it just shows the fact that it's possible

fn get_shell_version(shell: &str) -> Option<String> {
    let output = std::process::Command::new(shell)
        .arg("-c")
        .arg(format!("echo -n ${}_VERSION", shell.to_uppercase()))
        .output();
    match output {
        Ok(output) => {
            let stdout = String::from_utf8_lossy(&output.stdout).to_string();

            if stdout.is_empty() {
                None
            } else {
                Some(stdout)
            }
        }
        Err(_) => None
    }
}

I tested it with bash, fish and zsh, it works as expected, returning data in format like this:

5.1.8(1)-release
3.2.2
5.8

for these shells, respectively

Can you provide a benchmark? I'd love to know how well this runs, as we might ship this feature in the future.

[Vinegret43]

@grtcdr, sure. This is what i used to test those 3 shells

fn main() {
    println!("{}", get_shell_version("bash").unwrap());
    println!("{}", get_shell_version("fish").unwrap());
    println!("{}", get_shell_version("zsh").unwrap());
}

fn get_shell_version(shell: &str) -> Option<String> {
    let output = std::process::Command::new(shell)
        .arg("-c")
        .arg(format!("echo -n ${}_VERSION", shell.to_uppercase()))
        .output();
    match output {
        Ok(output) => {
            let stdout = String::from_utf8_lossy(&output.stdout).to_string();

            if stdout.is_empty() {
                None
            } else {
                Some(stdout)
            }
        }
        Err(_) => None
    }
}

Not really sure if this is exactly what you assumed by "benchmark", so if it's not what you wanted, please tell me what a benchmark for this should be like

[uttarayan21]

By benchmark he means make a cargo build --release and then benchmark the resulting binary with something like hyperfine

[grtcdr]

Yeah, it would also help if you replicated our current profile.release so we get a reading that's as accurate for our use-case as possible.

[Vinegret43]

I replicated your profile.release and ran hyperfine target/release/tst for the code i posted above (Testing 3 shells each time). Results:

Benchmark #1: target/release/tst
  Time (mean ± σ):     374.8 ms ±   5.7 ms    [User: 241.6 ms, System: 126.4 ms]
  Range (min … max):   365.5 ms … 383.8 ms    10 runs

on Intel Core 2 3.00Ghz

[Vinegret43]

My bad, didn't think this may be so bad for performance

[uttarayan21]

I also tried to implement this a while ago but stopped since the performance was not great.
Maybe an approach using SHELL --version might be better but not all of them have similar info.

[grtcdr]

Yeah, they all like to print out their versions differently, the worst offender is probably bash. version info hides behind an entire paragraph, so it's not exactly made for parsing.