npm / gauge

A terminal based horizontal guage aka, a progress bar
Other
322 stars 34 forks source link

More elegant spinner #5

Closed gillesdemey closed 8 years ago

gillesdemey commented 9 years ago

Would you be open to changing the default unicode theme to a more elegant spinner, like https://github.com/sindresorhus/elegant-spinner? The current implementation feels a bit crooked.

I'm not suggesting to introduce it as a dependency, as that would probably be too much effort.

iarna commented 9 years ago

elegant-spinner looks lovely, but I don't believe the brail blocks it uses are available across our supported environments. I looked at using them myself when I was first selecting characters for the spinner. (We already have an outstanding issue just for the darn solid block ), which is in the "is it double width? who knows" unicode classification, which means some settings can break everything. =/ Even just here on github, it's single-width in the fixed width font and double-width with the proportional font.

I kind of like the blobbyness of the current spinner, but I'm totally open to a replacement. What a replacement needs to do is, display correctly by default in the following environments:

iarna commented 9 years ago

On my mind, btw, is a gauge@2 with better templating. At the same time it might be handy to have more than "unicode" and "ascii" for detected template types, so we can have more expressive characters on OSes that support it.

dbkaplun commented 9 years ago

I just found cli-spinner which looks great. I think a few of them should work everywhere.

iarna commented 9 years ago

I'm aware of it– and unfortunately IIRC, the answer is "almost none of them".

I'm not taking anything without actually testing them on all of the platforms listed.

Or... I actually took ALL of the unicode line drawing-ish characters and tried them on all of those platforms and had prepared a list of the one's that work. Unfortunately I seem to have been all cute and only recorded them in a tweet, finding it will take longer.

iarna commented 9 years ago

Found it! Ok, so this is (I believe) a complete list of characters that work across platforms:

←↑↓↔↕─│┌┐└┘├┬┼═║╒╓╔╕╖╗╘╙╚╛╜╝╞╟╠╡╢╣╤╥╦╧╨╩╪╫╬▀▄▌▐░▒▓■▬▲►▼◄◊○◘◙

Any spinner has to come from these or from the Unicode "basic latin" set.

iarna commented 9 years ago

You'll note annoyances, like the fat arrows are thinner sideways than up and down. Also that there's no rightward version of ← (I mean, there is →, but it's not supported on all platforms).

iarna commented 9 years ago

The original version of this module used ◐◓◑◒, which I think looks pretty keen but does not work everywhere. =/

Of those example spinners the following can work:

  1. |/-\
  2. ┤┘┴└├┌┬┐
  3. .oO°Oo. (maybe, untested)
  4. .oO@*

The first is the ascii spinner we already have. And I think 3 + 4 are pretty ugly =/

I'm be curious about seeing 2 in motion.

gillesdemey commented 9 years ago

I don't think the "ambiguous-width characters" option is supported as of yet? At least with the latest version of NPM and iTerm2.

gillesdemey commented 9 years ago

At the same time it might be handy to have more than "unicode" and "ascii" for detected template types

The Windows shell uses the CP437 character encoding, so that could be another type? (https://en.wikipedia.org/wiki/Code_page_437)

We could show the elegant spinner for full Unicode supported shells, the current unicode template for CP437 Windows shells and the ASCII template for non-unicode shells.

I'll play around for a bit with my own fork of Gauge to look into extending the character encoding detection.

EDIT: Testing this indicates that CP437 is more commonly the default character set.

gillesdemey commented 9 years ago

I've taken the liberty of testing some of my changes on the platforms that are available to me right now using three different themes:

I've created an album to showcase all of the different rendering possibilities http://imgur.com/a/5UcqW

So far, my tests include:

Terminal and iTerm on OSX — mostly using zshell and some with bash to show that the shell isn't really influencing the rendering

cmd and the Git cmd on Windows, using whatever the default settings are for both.

I'll do some more tests on Linux and in Windows (Powershell mainly) when I have some more time on my hands.

iarna commented 9 years ago

When I last tried on Linux (Ubuntu), the brail code blocks weren't available in the default terminal fonts, but time does march on.

iarna commented 9 years ago

Ultimately I do think the fix for this is to allow templates to be specified not just for unicode and ascii, but for different OSes too, so Unicode + Mac can make use of everything, and the others can get a cut down version appropriate to their character sets.

gillesdemey commented 9 years ago

I've looked around for some modules that detect the available character set, but no luck. I'm also going off of the assumption that Windows only supports cp437 — even though it can support the full unicode range if it's set up properly.

iarna commented 9 years ago

I don't think the "ambiguous-width characters" option is supported as of yet? At least with the latest version of NPM and iTerm2.

I'm not sure what you mean? My understanding is that making "ambiguous-width characters" be double spaced currently breaks everything, because the solid block character is rendered as two spaces.

iarna commented 9 years ago

(Yeah, even determining unicode is a pain, let alone font character availability.)

gillesdemey commented 9 years ago

Re: ambiguous-width characters this is the behaviour I'm seeing, could totally be blamed on my iTerm nightly build though.

screenshot 2015-10-09 01 47 20

iarna commented 9 years ago

That looks like what I'd expect from it, yeah. =/

gillesdemey commented 9 years ago

I've updated the album to include Powershell on Windows and Terminal and XTerm on Ubuntu 14.04 LTS.

I'm not sure how far back we want to support Ubuntu, maybe this particular issue warrants taking a look at some older distros?

othiym23 commented 8 years ago

So, as npm/npm#10648 points out, we don't really have control over what codepage Windows users are using. I've seen enough other issues from people using npm in a CJKV environment to lead me to believe that we probably need to only use characters that are guaranteed to be the same (half) width, regardless of codepage or encoding.

gillesdemey commented 8 years ago

I'd like to pick up where I left off at this issue. I'll run some tests using other code pages on Windows.

Should we consider going full ASCII for Windows machines? I'm assuming Windows is the only platform where multi-lingual support is problematic?

iarna commented 8 years ago

Yeah, I'm of the opinion we should go full ASCII on windows, and let users via configuration select a prettier display if that's what they want.

gillesdemey commented 8 years ago

Regarding full-width characters, this is what Wikipedia has to say:

Range U+FF01–FF5E reproduces the characters of ASCII 21 to 7E as fullwidth forms, that is, a fixed width form used in CJK computing.

So we can typeset those characters properly in CJK text. The output looks to be correct after changing my system language and switching to a CJK code page.

http://i.imgur.com/npQAX0j.png

Any ideas on how the user might configure a different spinner, does such an option already exist?

iarna commented 8 years ago

It's not double width characters per se that are the concern. It's ambiguous width characters, that some terminals treat as double width and some treat as single width. Without knowing how wide the character will be displayed as, there's no way to correctly layout a line.

gillesdemey commented 8 years ago

Correct, but as long as we stay within the ASCII range, we can assume that every terminal will treat it as either half-width for non-East-Asian character sets and full-width for East-Asian character sets.

iarna commented 8 years ago

If we stay in the ASCII range we can assume every terminal will treat all of that as half width. East Asian code pages have a different set of codepoints for full width characters.

You'll note in your example above that everything is half width except the arrow.

iarna commented 8 years ago

As I said earlier, my intent for fixing this is:

Ultimately I do think the fix for this is to allow templates to be specified not just for unicode and ascii, but for different OSes too, so Unicode + Mac can make use of everything, and the others can get a cut down version appropriate to their character sets.

So specifically, for Windows it'll get ASCII as we have no way of determining support, Linux will get something closer to what we have today, and Mac can have a much richer result.

I have a rewrite in process that I'll be ready to share with you all in the next week or two, probably.

iarna commented 8 years ago

I've done a little research into how to support windows and it means either a system call, which is out due to it requiring C, or a call out to a command line tool, which might be the right answer for some applications but is, I think, out of scope for gauge.

iarna commented 8 years ago

My in progress branch (with lots of unsquashed wip commits) is here: https://github.com/iarna/gauge/tree/new-rewrite

iarna commented 8 years ago

@gillesdemey @dbkaplun

So this work has landed in master and is out as gauge@2 with a beta tag– you can install it by explicitly asking for the version or installing gauge@beta.

Now is the time for figuring this out! It can select different themes based on your OS, so OSX users can get a much richer set of unicode.

Please join me in the bikeshedding issue to hash things out:

https://github.com/iarna/gauge/issues/36

(I'm closing this issue in favor of that one.)