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

[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?

[grtcdr]

Anything new about gpu hardware support?

I've already started implementing GPU support as a separate crate but I haven't gotten around to actually working on it and completing it, it's not even close to being complete to be frank. But as soon as I have some free time to focus on it it'll be added.

[grtcdr]

@Staubgeborener A library I'm working, pci_fetch can fetch PCI devices' information, among them GPUs, all that's left to do is have libmacchina integrate this feature and macchina will have GPU support in no time :)

[matrixik]

Maybe there could be also switch to show versions of shell, windows manager and terminal? I would like to have output similar to neofetch (also nice that it's showing Ubuntu logo):

And after this and GPU I could replace neofetch with macchina. Then I still need to find some fast replacement for inxi -Fx.

[grtcdr]

Hey @matrixik

Maybe there could be also switch to show versions of shell, windows manager and terminal

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.

I would like to have output similar to neofetch

Macchina doesn't have this feature currently, but you could always import your own ascii art, ANSI color codes work too so you could have it exactly like Neofetch's.

[matrixik]

Sorry, I wrote it in confusing way, by "similar output" I mean similar data with version numbers, not similar graphic representation (I don't really care about this).

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.

I don't get this part. You run it from shell so you should have access to all shell environment variables (from any language). No?

I don't know how are you detecting different programs but maybe it would be possible to locate they binary and run it with --version and then display it to user if no error (like no existing flag) is reported.

[grtcdr]

I don't get this part. You run it from shell so you should have access to all shell environment variables (from any language). No?

This would work if Rust exposed to macchina what a shell exposes to a shell script, but unfortunately, this isn't the case.

I don't know how are you detecting different programs but maybe it would be possible to locate they binary and run it with --version and then display it to user if no error (like no existing flag) is reported.

We don't need to care about where the shell binary is located, the issue stems from the fact that different shells write different things when invoked with --version, some keep it clean, and some don't. Which means a different implementation to fetch the version for every shell out there (or at least the widely used ones).

So to sum it up, Rust programs don't have access to a lot of environment variables like shell programs do.

[grtcdr]

I'll give you an example:

• What macchina can do is run zsh --version.
• What it can't do is access the value of $ZSH_VERSION, as far as it thinks, $ZSH_VERSION isn't an environment variable due to the restrictions of the language.

Example

zsh

zsh --version output: zsh 5.8 (x86_64-pc-linux-gnu)
ZSH_VERSION value: 5.8

bash

bash --version output:

GNU bash, version 5.1.8(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

BASH_VERSION value: 5.1.8(1)-release

[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.