~This is a optional feature that will add option to use jp2a as the ascii backend~.
~This will add auto color support as well as a way to use jpg/png images for the ascii art.~
This will add color support to ascii images made using jp2a or similar tools.

This is an initial draft, will need more work.

Screenshot

v6 codename "Gallium" — CHANGELOG

We hope this is the last time we have to break your themes and configs, but hopefully you won't be so annoyed thanks to the new changes and features that this new version brings. Go on, have a read:

Breaking Changes

• MACCHINA_CONF has been deprecated, please use --config from now on, you can alias macchina to macchina --config <PATH> to avoid typing it every time.

• hide_bar_delimiters has been deprecated, but the feature isn't gone. You can hide your bar's delimiters using hide_delimiters, here's what'd look like:

[bar]
hide_delimiters = true

• palette has been deprecated, and again, the feature is still here. But, you now have to specify the type of variant you'd like to display and what glyph to use:

[palette]
type = "Full"
glyph = "●"
visible = true

Bugfixes

• We've officially demoted DESKTOP_SESSION, preferring XDG_CURRENT_DESKTOP over it. DESKTOP_SESSION is essentially a fallback now. (closes #199)
• --short-uptime has been renamed to --long-uptime. Somehow, I forgot to rename the long version of this command-line flag, and you can verify this by comparing the flag name with the flag description — they contradict each other.
• The spacing bug, that results in an uneven space between the left side and right side of the separator, has been fixed.

New features

• Every single option in a theme is now optional, feel free to remove anything you don't need!
• You can specify the kind of border you want macchina to use, under [box], you can add:

# Accepted values: "plain", "rounded" and "thick".
border = "plain"

• You can now tell macchina what pool of color to use when randomization is enabled, under [randomize], you can add:

# Accepted values: "base", "hexadecimal" and "indexed"
pool = "base"

• You can now use indexed colors, e.g. 38 and hexadecimal values, e.g. #FFFFFF for any option that accepts a color. (#193)
• You can now specify the glyph of the palette.

[palette]
glyph = "●"

• Added manpages — Woohoo!
  • There's one for the configuration file, and another for theming.
• More datapaths to look at:
  • macchina now looks for themes in /usr/share/macchina/themes. (closes #210)
  • macOS: macchina now looks for themes in ~/.config/macchina/themes.
• We've brought back the ability to toggle between showing your physical/logical core count.

Miscellaneous

• When using --list-themes, themes are now listed below the directory that contains them, resulting in much cleaner output.
• Some under-the-hood changes you might not notice, which mostly address the complexity of certain operations (hopefully improving performance).
• Psst... Gentoo users, macchina doesn't require portage-utils anymore.

Hi guys, Here we go again,

/home/pin()
2021-11-11 11:00 > macchina -v
macchina    5.0.4
libmacchina 3.8.1
/home/pin()
2021-11-11 11:00 > macchina
                                                                                        
 \\`-______,----__      Machine     -  Hewlett-Packard HP EliteBook 820 G1 A3009DD10303
  \\        __,---`.    OS          -  NetBSD 9.99.92                                   
   \\       `.____      Packages    -  185 (pkgsrc)                                     
    \\-______,----`.    Terminal    -  xterm                                            
     \\                 Uptime      -  2h 9m                                            
      \\                CPU         -  Intel® Core™ i5-4210U CPU @ 1.70GHz (4)          
       \\               Brightness  -  100%                                             
        \\              CPU Load    -  3%                                               
         \\             Memory      -  1.2 GB/7.5 GB                                    
          \\            Battery     -  Full                                             
           \\                                                                           

/home/pin()
2021-11-11 11:00 > macchina -d
Let's check your system for errors... Here's a summary:

We've collected 18 readouts, including 6 failed read(s) and 2 read(s) which resulted in a warning.
Readout "Host" failed with message: Unable to read account information.
Readout "DesktopEnvironment" failed with message: You appear to be only running a window manager.
Readout "WindowManager" failed with message: No graphical session detected.
Readout "LocalIP" failed with message: Please specify a network interface to query (e.g. `interface = "wlan0"` in macchina.toml).
Readout "Shell" failed with message: Unable to read account information.
Readout "Resolution" failed with message: Metric is not available on this system.

2 of the 8 unsuccessful read(s) resulted in a warning:
Readout "Kernel" threw a warning with message: This information is provided by the OperatingSystem readout on NetBSD.
Readout "Distribution" threw a warning with message: This information is provided by the OperatingSystem readout on NetBSD.
/home/pin()
2021-11-11 11:00 > 

Forget about "LocalIP", this is simply because I didn't specify the interface but, failed to fetch "Host", "WindowManager" and "Shell"?

EDIT: @grtcdr I think is better not to merge this release and let users stay on 5.0.3 for now.

Describe the bug macchina.toml settings are being ignored

To Reproduce

export XDG_CONFIG_HOME="$HOME/.config"
cd $XDG_CONFIG_HOME && mkdir macchina && cd macchina
wget macchina.toml https://raw.githubusercontent.com/Macchina-CLI/macchina/main/macchina.toml

I have restarted the terminal, re-sourced my shell configurations and so forth, but no changes occur. Must one specify explicitly that macchina must be reading the config via a flag or so?

Expected behavior The configuration .toml changes the appearence of macchina.

System Information

This PR is a big one, since it basically changes the whole structure of the project to allow easier integration with future OS support (e. g. windows). The readouts have been extracted into their own corresponding traits, which allow a cross-platform usage of the api. Each trait can then be implemented on each os.

This PR also adds support for macOS (battery readout not yet finished)

Please don't merge yet, this is just a draft for further discussion.

Describe the bug When compiling Macchina v6.1.1, I receive the error: expected enum `tui::style::Color`, found a different enum `tui::style::Color` arguments to this function are incorrect. I am compiling with cargo install macchina on Arch Linux using Rust v1.63

To Reproduce Steps to reproduce the behavior:

1. Type cargo install macchina
2. Wait for compile (all depends compile).

I have cleared ~/.cargo/registry/cache, ~/.cargo/registry/index and ~/.cargo/registry/src but results in the same error.

Expected behavior Cargo to finish compiling and install macchina binary.

Screenshots Full error:

   Compiling libmacchina v6.2.0
   Compiling macchina v6.1.1
error[E0308]: mismatched types
  --> /home/carneeki/.cargo/registry/src/github.com-1ecc6299db9ec823/macchina-6.1.1/src/theme/base.rs:14:24
   |
14 | #[derive(Debug, Clone, Serialize, Deserialize)]
   |                        ^^^^^^^^^
   |                        |
   |                        expected enum `tui::style::Color`, found a different enum `tui::style::Color`
   |                        arguments to this function are incorrect
   |
   = note: expected reference `&tui::style::Color`
              found reference `&'__a tui::style::Color`
   = note: perhaps two different versions of crate `tui` are being used?
note: function defined here
  --> /home/carneeki/.cargo/registry/src/github.com-1ecc6299db9ec823/color-to-tui-0.2.0/src/lib.rs:7:8
   |
7  | pub fn serialize<S: Serializer>(color: &Color, serializer: S) -> Result<S::Ok, S::Error> {
   |        ^^^^^^^^^
   = note: this error originates in the derive macro `Serialize` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
  --> /home/carneeki/.cargo/registry/src/github.com-1ecc6299db9ec823/macchina-6.1.1/src/theme/base.rs:14:35
   |
14 | #[derive(Debug, Clone, Serialize, Deserialize)]
   |                                   ^^^^^^^^^^^ expected enum `tui::style::Color`, found a different enum `tui::style::Color`
   |
   = note: perhaps two different versions of crate `tui` are being used?
   = note: this error originates in the macro `try` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
   --> /home/carneeki/.cargo/registry/src/github.com-1ecc6299db9ec823/macchina-6.1.1/src/theme/components.rs:106:33
    |
106 | #[derive(Debug, Default, Clone, Serialize, Deserialize)]
    |                                 ^^^^^^^^^
    |                                 |
    |                                 expected enum `tui::style::Color`, found a different enum `tui::style::Color`
    |                                 arguments to this function are incorrect
    |
    = note: expected reference `&std::option::Option<tui::style::Color>`
               found reference `&'__a std::option::Option<tui::style::Color>`
    = note: perhaps two different versions of crate `tui` are being used?
note: function defined here
   --> /home/carneeki/.cargo/registry/src/github.com-1ecc6299db9ec823/color-to-tui-0.2.0/src/optional.rs:4:8
    |
4   | pub fn serialize<S: Serializer>(color: &Option<Color>, serializer: S) -> Result<S::Ok, S::Error> {
    |        ^^^^^^^^^
    = note: this error originates in the derive macro `Serialize` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
   --> /home/carneeki/.cargo/registry/src/github.com-1ecc6299db9ec823/macchina-6.1.1/src/theme/components.rs:106:44
    |
106 | #[derive(Debug, Default, Clone, Serialize, Deserialize)]
    |                                            ^^^^^^^^^^^ expected enum `tui::style::Color`, found a different enum `tui::style::Color`
    |
    = note: expected enum `std::option::Option<tui::style::Color>` (enum `tui::style::Color`)
               found enum `std::option::Option<tui::style::Color>` (enum `tui::style::Color`)
    = note: perhaps two different versions of crate `tui` are being used?
    = note: this error originates in the macro `try` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0308`.
error: could not compile `macchina` due to 8 previous errors
error: failed to compile `macchina v6.1.1`, intermediate artifacts can be found at `/tmp/cargo-installoD2ntw`

System Information

• Distribution: Arch Linux
• Desktop Environment: Gnome w/Wayland
• Operating System: Arch Linux
• Terminal: Wezterm
• Macchina's version: v6.1.1

/home/pin()
2021-11-01 09:48 > macchina -v
macchina    5.0.0
libmacchina 3.3.1
/home/pin()
2021-11-01 09:49 > macchina
                                                                
  Host         pin@mybox                                        
  Machine      Hewlett-Packard HP EliteBook 820 G1 A3009DD10303
  OS           NetBSD 9.99.92                                   
  WM           Franken                                          
  Terminal     xterm                                            
  Shell        nu                                               
  Uptime       1h 19m                                           
  CPU          Intel® Core™ i5-4210U CPU @ 1.70GHz (4)          
  Memory       1.5 GB/7.5 GB                                    
  Battery      98% & Charging                                   

/home/pin()
2021-11-01 09:49 > macchina -d
Let's check your system for errors... Here's a summary:

We've collected 11 readouts, including 1 failed read(s) and 0 read(s) which resulted in a warning.
Readout "Packages" failed with message: No packages found — Do you have a package manager installed?
/home/pin()
2021-11-01 09:49 > 

Although, ls /usr/pkg/pkgdb | wc -l reports the correct number of installed packages. I'm still working on properly installing the themes so they get detected.

You can find my configuration and theme files here, https://codeberg.org/pin/franken-nbsd/src/branch/main/home/.config/macchina

Added support for rgb and indexed colors by using cusom de/serialization of the tui::style::Color struct.

Source here https://git.uttarayan.me/uttarayan/color-parser-tui. I will publish to crates.io after a bit more testing.

When trying to install on my Raspberry, my pi is throttling the cargo installation. All 4 core go on 100% load and becomes very slow on installing. is there any easier way? im thinking "pkg install macchina".

@grtcdr Hi, hope you're doing fine. Just came across an interesting one :)

Usually I have the DE read-out disabled as I don't use one. Yesterday I started to play arround with leftwm and finally got it to build and run from git-HEAD, https://i.postimg.cc/hGksKScV/2021-11-29-231906-1366x768-scrot.png

When macchina failed to display the WM read-out, I disabled it and enabled the DE one. Surprise, it actually fetches leftwm as DE. Not a big deal, just thought I'd let you know.

This post has made me aware of the difficulties blind people can come across when using programs.

This will of course be a feature one can enable on their own. It's time fetchers started targeting a wider audience. :smile:

If any of you lovely people has any expertise in accessibility features and can help implement this one or can help provide us with ideas, we'd really appreciate it! :heart:

Describe the bug Macchina crashes on FreeBSD 13.

To Reproduce Steps to reproduce the behavior:

1. Run cargo install macchina
2. Run macchina

Expected behavior It should display system information.

Screenshots

$ RUST_BACKTRACE=full macchina
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Utf8Error(Utf8Error { valid_up_to: 48, error_len: Some(1) })', /home/yonas/.cargo/registry/src/github.com-1ecc6299db9ec823/libmacchina-6.3.1/src/freebsd/mod.rs:244:14
stack backtrace:
   0:     0x3b064fc4c4d1 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hf9bca0a54f465bd9
   1:     0x3b064fbf7d0e - core::fmt::write::hdf9e1b7bc0c7ef23
   2:     0x3b064fc28c44 - std::io::Write::write_fmt::h6e00616d8cf5d394
   3:     0x3b064fc37186 - std::panicking::default_hook::{{closure}}::ha5a1e37665f439d8
   4:     0x3b064fc37ae4 - std::panicking::rust_panic_with_hook::h184324b56212ec2b
   5:     0x3b064fc4c862 - std::panicking::begin_panic_handler::{{closure}}::hdd7dccc960a25e4f
   6:     0x3b064fc4c7d6 - std::sys_common::backtrace::__rust_end_short_backtrace::h1fb3000d64dd03f0
   7:     0x3b064fc374c2 - rust_begin_unwind
   8:     0x3b064fbf9e12 - core::panicking::panic_fmt::hc3aba48bba555f86
   9:     0x3b064fbfad22 - core::result::unwrap_failed::hb64f9d366cb13a63
  10:     0x3b064fb7bc3c - macchina::data::get_all_readouts::heeef78197dbc036f
  11:     0x3b064fb8454a - macchina::main::h38699e8f6cd6d7fc
  12:     0x3b064fb530f3 - std::sys_common::backtrace::__rust_begin_short_backtrace::hc47aa0a27d9d3a07
  13:     0x3b064fb534a1 - std::rt::lang_start::{{closure}}::h6e1fe9ba24be0494
  14:     0x3b064fba55a7 - main

macchina --doctor output

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Utf8Error(Utf8Error { valid_up_to: 48, error_len: Some(1) })', /home/yonas/.cargo/registry/src/github.com-1ecc6299db9ec823/libmacchina-6.3.1/src/freebsd/mod.rs:244:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

System Information You don't have to provide this information if you're not comfortable doing so, but it'll help us solve the issue a lot faster.

• Distribution: FreeBSD
• Desktop Environment: N/A
• Operating System: FreeBSD 13.1-RELEASE
• Terminal: kitty
• Macchina's version: macchina 6.1.5, libmacchina 6.3.1

Currently, the only way I can see (in the docs) to use custom ascii art is through a path but could a multiline toml variable not be added that holds the ascii? Sort of like:

[custom_ascii]
ascii='''
       _                        
       \`*-.                    
        )  _`-.                 
       .  : `. .                
       : _   '  \               
       ; *` _.   `*-._          
       `-.-'          `-.       
         ;       `       `.     
         :.       .        \    
         . \  .   :   .-'   .   
         '  `+.;  ;  '      :   
         :  '  |    ;       ;-. 
         ; '   : :`-:     _.`* ;
[bug] .*' /  .*' ; .*`- +'  `*' 
      `*-*   `*-*  `*-*'
'''

This way, the whole theme can be stored within the toml file. It's also worth asking: could custom themes have multiple ASCII arts for different operating systems? I'd love to see a lot more flexibility with themes as long as it doesn't downgrade performance.

I've glanced over the theme documentation and I don't think there's this possibility yet.

Add a setting to specify the position where the ascii art should be displayed. Currently, it always displays on the left. I have a fairly wide but short ascii art I'd like to use, it would look best if it was above the system info box. Having a wide ascii art side by side with the system info doesn't work well in narrow terminal windows.

Something like:

[custom_ascii]
# Possible values: top, right, bottom, left
# Default value: left
position = "top"

I would like to be able to wrap some custom commands to display information I chose. Like

# Show available upgrade in Voidlinux
custom_info:
  - name: XBPS
    command: xbps-query -Mnu | wc -l

I would use your fetcher on remote hosts, and run it at each login to get some useful informations, and display it prettily.

A handy readout to have is battery health, which has been sitting dormant in libmacchina for a good while. I didn't get around to implementing it for the remaining operating systems, with the exception of Linux.

This is a WIP feature, further development is to be done in libmacchina

First question, where to get the information from?

I found in the pciutils repository the following:

In runs on the following systems:

Linux (via /sys/bus/pci, /proc/bus/pci or i386 ports) FreeBSD (via /dev/pci) NetBSD (via libpci) OpenBSD (via /dev/pci) GNU/kFreeBSD (via /dev/pci) Solaris/i386 (direct port access) Aix (via /dev/pci and odmget) GNU Hurd (direct port access) Windows (direct port access, see README.Windows for caveats) CYGWIN (direct port access) BeOS (via syscalls) Haiku (via /dev/misc/poke) Darwin (via IOKit) DOS/DJGPP (via i386 ports) SylixOS (via /proc/pci)

There are many possible places to search, depending on the kernel (or operating system). But in some cases it's a matter of reading a plain text file. In order not to make the issue too long, I recommend the first part of this article. As you can see in the article, it is possible to read the vendor identifier, device identifier and class identifier.

Step two: mapping identifiers to GPUs

I quote again the previous repository, the following:

The database of PCI IDs (the pci.ids file) gets out of date much faster than I release new versions of this package, so it is maintained separately.

It lives at https://pci-ids.ucw.cz/, where you can browse the database, download the most recent pci.ids file (e.g., by running the update-ids utility) and also submit new entries.

If we go through that website, we can corroborate that the GPU information (in addition to other devices that are not relevant) can be obtained from these ID's.

At first I thought that the pci.ids file should be downloaded regularly to keep it updated but, at least in Arch Linux, I found it in /usr/share/hwdata/pci.ids.

I'm not sure this is the best way to solve it, but I think it can work, without relying on system commands or external crates.