Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emoji/icons are too large on my terminal #3724

Closed
jsravn opened this issue Feb 20, 2019 · 18 comments

Comments

Projects
None yet
8 participants
@jsravn
Copy link

commented Feb 20, 2019

screenshot from 2019-02-20 15-39-17

Please fix this, or remove the icons. It makes minikube unusable for me recently. On gnome-terminal 3.30.2.

@tstromberg

This comment has been minimized.

Copy link
Contributor

commented Feb 20, 2019

Ouch! That looks very painful, and completely unintentional. Terminal applications do not have the ability to control font sizes, but we do offer a way to turn off this feature:

https://github.com/kubernetes/minikube/blob/master/docs/env_vars.md#example-disabling-emoji

What distribution of Linux is this on, and what version of it?

I thought I've seen everything.

I did find one mention of someone running arch linux experiencing this in another application:
https://www.reddit.com/r/archlinux/comments/81wyq2/giant_emoji_in_terminal/ - the comments indicate the possibility of a missing symlink:

Perhaps this is influenced by the fontconfig file that's about scaling bitmap fonts. It's named "10-scale-bitmap-fonts.conf" in /etc/fonts/conf.avail/. If you don't have a link to it in /etc/fonts/conf.d/, perhaps try creating it and see what happens.

I didn't symlink the bitmap scaling conf file. Turns out the emoji was a bitmap! Never would have guessed.

If you do find a solution, please add the fix to this bug so that other users can find it in the future. Thanks for the bug report!

@afbjorklund

This comment has been minimized.

Copy link
Contributor

commented Feb 20, 2019

You can use MINIKUBE_IN_COLOR=false to disable color output (including emojis)

Or maybe just increase your font size to 180pt or whatever would match those icons 😀

@jsravn

This comment has been minimized.

Copy link
Author

commented Feb 21, 2019

Haha, thanks guys. It was pretty funny when I saw this the first time. A giant hand showed up on my terminal (the wait icon I think?).

It is indeed the bitmap scaling which I've disabled, since it can make bitmap fonts blurry. I don't think I've used bitmap fonts in a while though, so I may just enable that again.

@shanesveller

This comment has been minimized.

Copy link

commented Feb 22, 2019

Guess I'm setting that environment variable for the rest of time. Not a fan of the new emoji in the output. Would be really, really nice to not sacrifice all color to avoid that particular aesthetic.

@afbjorklund

This comment has been minimized.

Copy link
Contributor

commented Feb 22, 2019

AFAIK, minikube doesn't use any color in the output ? Maybe we should split the configuration variables, one for color (text) and one for emoji (icons). That way you could have colored text output - without emojis.

Note that on older platforms the emoji will be shown in black-and-white, so there's no color here...
minikube-start

@intelfx

This comment has been minimized.

Copy link

commented Feb 25, 2019

Who got the clever idea of adding emoji into the output, anyway?..

@afbjorklund

This comment has been minimized.

Copy link
Contributor

commented Feb 25, 2019

@intelfx: There is an ASCII version available as well.

$ export MINIKUBE_IN_COLOR=false
$ minikube start --container-runtime=cri-o --cache-images
o   minikube v0.34.1 on linux (amd64)
$   Caching images in the background ...
>   Creating virtualbox VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...
-   "minikube" IP address is 192.168.99.100
-   Configuring CRI-O as the container runtime ...
-   Preparing Kubernetes environment ...
:   Waiting for image caching to complete ...
-   Pulling images required by Kubernetes v1.13.3 ...
-   Launching Kubernetes v1.13.3 using kubeadm ... 
-   Configuring cluster permissions ...
-   Verifying component health .....
+   kubectl is now configured to use "minikube"
=   Done! Thank you for using minikube!

The main suggestion here was to split "color" and "emoji" configuration into two variables...

@afbjorklund

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2019

Did so in #3773

@huguesalary

This comment has been minimized.

Copy link
Contributor

commented Mar 11, 2019

What is the meaning of those ASCII symbols (and emojis...)? This seems quite random and unusual for a command line tool.

@jakebasile

This comment has been minimized.

Copy link

commented Apr 18, 2019

These symbols (both emoji and the "lo-fi" symbols like '= ', etc.) provide no meaning whatsoever to an end user, and should be removed entirely or an option provided to disable them. In the meantime, I'll probably alias minikube to something that cleans up this inane output.

@DarinDouglass

This comment has been minimized.

Copy link

commented Apr 18, 2019

I agree with @jakebasile, these emotes feel arbitrary and don't add any real meaning.

I understand the desire for some additional severity info (i.e. info, debug, etc) but the current prefixes (both the emotes and especially the low prefixes) don't provide any additional meaning. In fact they're usually redundant: a whale emote when talking about Docker? A running man emote when talking about "running" the vm?

At best they're redundant information. At worst they're eyesores added to every line.

@intelfx

This comment has been minimized.

Copy link

commented Apr 18, 2019

Seconded @jakebasile and @DarinDouglass.

These emotes are not just redundant information, they're misinformation because they are not related to the text content in any meaningful way (they represent neither severity nor category of the message). That, and they severely clutter the text output, distracting the operator (the issue will often be exaggerated by virtue of these emojis being brighter than the text).

Please either provide an option to completely disable both emoji and ASCII prefixes without impacting the rest of the tool's functionality, or (better) replace them with something meaningful (e. g. prefixes tied to the message severity).

@afbjorklund

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2019

Should probably open a new issue, rather than continuing on this one (on icon size). But here we are....

The prefixes are supposed to have a meaning, but like you mention they are are mostly focused on style at the moment. Maybe we should indeed add a severity/category before the (optional) style emoji/prefix.

For reference, here is an example of the same styles when printed out as text:

[happy] minikube v1.0.0 on linux (amd64)
[caching] Downloading Kubernetes v1.14.0 images in the background ...
[tip] Tip: Use 'minikube start -p <name>' to create a new cluster, or 'minikube delete' to delete this one.
[running] Re-using the currently running virtualbox VM for "minikube" ...
[waiting] Waiting for SSH access ...
[connectivity] "minikube" IP address is 192.168.99.103
[CRI-O] Configuring CRI-O as the container runtime ...
[CRI-O] Version of container runtime is 1.13.1
[waiting] Waiting for image downloads to complete ...
[copying] Preparing Kubernetes environment ...
[pulling] Pulling images required by Kubernetes v1.14.0 ...
[restarting] Relaunching Kubernetes v1.14.0 using kubeadm ... 
[waiting-pods] Waiting for pods: apiserver etcd scheduler controller
[reconfiguring] Updating kube-proxy configuration ...
[verifying-noline] Verifying component health .....
[kubectl] kubectl is now configured to use "minikube"
[ready] Done! Thank you for using minikube!

They could probably be grouped further, a bit too many when not displaying in "style".

In the meantime we can just make it opt-out, I'm thinking a MINIKUBE_NO_STYLE environment variable that will just disable the prefix altogether and just show the text. Maybe revisit with severity/category later.

@DarinDouglass

This comment has been minimized.

Copy link

commented Apr 19, 2019

@afbjorklund You're right, it probably should have gone into a new issue; that's my bad. Thanks for making one!

@afbjorklund

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2019

As for the original issue, I'm not sure if there is a way to detect that bitmap scaling has been turned off ?

@afbjorklund

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2019

Please open a new issue about making the output format acceptable, not going to disable the style.

@tstromberg suggestion:

- top level item
  * second level item
! error/warning item
@jakebasile

This comment has been minimized.

Copy link

commented Apr 25, 2019

Created #4157

@tstromberg

This comment has been minimized.

Copy link
Contributor

commented Apr 30, 2019

Thank you for sharing your experience. It's been a good one to learn from.

In the end, I don't believe we should implement detection for the too-large-emoji issue, as it isn't exactly trivial. If you run into this, please set MINIKUBE_IN_STYLE=0 in your environment, or a non-color TERM setting.

Thank you again for raising this issue.

@tstromberg tstromberg closed this Apr 30, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.