Currently, if a bar is created with maximum number of items X and then updated (.Add(i)) with i that is significantly lower than 1% of X (e.g. 0.1%), then the item count shown to the right of the bar ((n/X)) will only update when it has accumulated to a whole percentage value (e.g. 1%, 2%) and so on. When you have a lot of items in between, it looks really weird.

It is possible to introduce fractional percentage (which i guess will by default fix this behaviour), or somehow re-render the item count text on Add?

TL;DR

The title is a bit misleading but currently this PR:

• ✅ Introduces a "default value render" where it can render a 0% progress (instead when .Add(n) is called
• ✅ Removes the instance setters and replace 'm with construction time Functional Options
• ✅ Introduces a setting to change the initial rendering behaviour
• ❎ Obliterates backward compatibility
• ❎ Depends on Go 1.10 to run the tests (uses strings.Builder)

The details

This PR removes any of the "setters" and is more in line with the immutability concept. I'm not sure what the typical use-case is, but I don't expect people changing the options frequently once the bar is configured. This design supports that philosophy by having this moment a bit "sooner". Once the constructor is called, it's ready to be used and doesn't support any "configuration" changes.

This way we can also render a blank bar on the get-go and voids the need to call bar.RenderBlank(). However I've tinkered with it and I don't think I personally like the implicit behaviour. So I've made it optional (disabled by default) and we can pick and choose.

New API

I think the API speaks for itself, but now it'll work like:

bar := progressbar.NewOptions(100, OptionSetSize(10))
bar.RenderBlank()
bar.Add(5)

• SetSize() has been removed and renamed to it's Width equivalent OptionSetWidth()
• OptionSetRenderBlankState() is introduced to define the rendering behaviour of a blank progress bar

Pending considerations

• I've left progressbar.New(max) in, but I can just as easily replace it with what's now called progressbar.NewOptions().
• ~~Decide if we want to set the maximum bar units using FO or as a straight-up parameter.~~

Should resolve https://github.com/schollz/progressbar/issues/12

This error happens every 9 out of 10 times, all renders error out with: golang.org/x/sys/windows.ERROR_INVALID_HANDLE (6). I am using the default GoLand configuration, so it's a Command Prompt terminal.

Ref: #79

Issue pictured Code:

	bar := progressbar.NewOptions(-1,
		progressbar.OptionSetDescription("downloading emojis "+count),
		progressbar.OptionSpinnerType(4),
		progressbar.OptionShowCount(),
		progressbar.OptionShowBytes(true),
		progressbar.OptionOnCompletion(func() {
			fmt.Fprint(os.Stderr, "\n")
		}),
	)

I can't get the bar to properly add a newline afterwards for whatever reason.

This PR adds the ProgressBar.String() method that returns the rendered version of the progress bar as a string. This is useful for environments where one doesn't want to output to stdout, but use the progess bar somewhere else. Personally I'm using it in Amfora, which is a TUI application.

This PR also adds the DefaultSilent and DefaultBytesSilent funcs, which create a ProgressBar that doesn't output anywhere, and doesn't have

OptionOnCompletion(func() {
	fmt.Fprint(os.Stderr, "\n")
})

Here are the following changes made in code:

1. Added ignoreLength flag.
2. config.currentByte takes care of the number of bytes progressed.
3. Able to show infinite progress bar withiteration/sec.
4. Added showByte Option to toggle the speed rate display.
5. Added test cases.
6. Removed option to update max value through ChangeMax() function.

Resolves #27

my progressbar init:

        max := 10000
	writer := os.Stdout
	bar := progressbar.NewOptions(max,
		progressbar.OptionSetDescription(""),
		progressbar.OptionSetWriter(writer),
		progressbar.OptionSetWidth(50),
		progressbar.OptionThrottle(65*time.Millisecond),
		progressbar.OptionShowCount(),
		progressbar.OptionShowIts(),
		progressbar.OptionOnCompletion(func() {
			fmt.Fprint(writer, "\n")
		}),
		progressbar.OptionSpinnerType(14),
		progressbar.OptionFullWidth(),
	)
	_ = bar.RenderBlank()

	for i := 0; i <= max; i++ {
		bar.Add(1)
		time.Sleep(time.Millisecond * 50)
	}

it starts scrolling.so what i can do?

most IO progress implementations seem to only allow for a known fixed length denominator. in the case where the operation is for instance an HTTP POST, the total length/duration is not known and there doesn't seem to be a way to easily tie into the network layer to do a 'better' job. to satisfy this use case it would be great to have the progress bar simply ping back and forth, ping pong style, until progress bar Finish or Reset is called. Passing -1 perhaps to OptionSetWidth could be an approach to indicate unknown length.

Anything against having int64 for maxBytes, currentNum and so on? If we're processing a file, and we're using a progressbar, it's likely it's a huge file :)

int will do in 64bit OS, but not in 32bit one (such as raspbian)

Affected version

3.9.0

Steps To Reproduce

Create the following code example

package main

import (
	"fmt"
	"github.com/schollz/progressbar/v3"
	"time"
)

func main() {
	count := 10
	progressBar := progressbar.NewOptions(
		count,
		progressbar.OptionFullWidth(),
		progressbar.OptionSetRenderBlankState(true),
		progressbar.OptionShowCount(),
		progressbar.OptionSetVisibility(true),
		progressbar.OptionSetPredictTime(false),
		progressbar.OptionClearOnFinish(),
	)

	for i := 0; i < count; i++ {
		time.Sleep(time.Millisecond * 100)
		_ = progressBar.Add(1)
	}

	fmt.Println("hello")
}

Run

go get github.com/schollz/progressbar/[email protected]

Then run the example.

The result is

> go run .
hello

Then run

go get github.com/schollz/progressbar/[email protected]

And run the example again.

The result is

> go run .
                                                                                                                                           hello

Notice number of spaces before the hello word.

See the playground https://go.dev/play/p/Tpiz7wA-E2g?v=goprev

I've introduced a new function to call to render the blank bar. I've refrained from adding it as an option, since the current API doesn't easily allow for setting options. I've also refrained from adding it by default as I didn't wanted to introduce a backwards incompatible change.

b := progressbar.New(10)
b.RenderBlank()
ticker := time.NewTicker(1 * time.Second)
now := time.Now()
for t := range ticker.C {
	b.Add(1)
	if t.Sub(now).Seconds() >= 10 {
		break
	}
}

ticker.Stop()

Description

This PR makes the spinner type custom so that you can use one of the 76 preset spinners or any custom animation. To do this, the OptionSpinnerType now accepts a []string instead of an int, so any animation can be passed. If you want to use one of the presets, just use the new func GetPresetSpinner(spinnerType int) which gives you access to the previous standard animations.

When trying to follow docker container logs with "docker logs container -f" the progress bar is not showing even though by default it's following StdOut and the progress bar is writing to os.Stdout

main.go

package main

import (
	"time"

	"github.com/schollz/progressbar/v3"
)

func main() {
	bar := progressbar.Default(100)

	for i := 0; i < 100; i++ {
		bar.Add(1)
		time.Sleep(1 * time.Second)
	}
}

Dockerfile

FROM golang:1.18-alpine
WORKDIR /app
COPY go.mod ./
COPY go.sum ./
RUN go mod download
COPY *.go ./
RUN go build -o /application
CMD [ "/application" ]

Building:

docker build -t app . Running:

docker run -d -t app Follow logs:

docker logs 0b26e53d7321 -f

I start my progress bar as indeterminate for the first query that retrieves the count.
Then I set the count as the new max, my log line does show the correct number.
The progress bar never changes from indeterminate to an actual progress bar.

Here is my setup.

bar := progressbar.NewOptions(
	-1,
	progressbar.OptionSetDescription("Fetching messages from API"),
	progressbar.OptionSetWriter(os.Stderr),
	progressbar.OptionFullWidth(),
	progressbar.OptionEnableColorCodes(true),
	progressbar.OptionSetPredictTime(true),
	progressbar.OptionShowCount(),
	progressbar.OptionShowIts(),
	progressbar.OptionShowElapsedTimeOnFinish(),
	progressbar.OptionSetItsString("Msgs"),
	progressbar.OptionSpinnerType(14),
	progressbar.OptionSetRenderBlankState(true),
)

// This is just the initial query
folderMessages := f.getMessages(client, log.Named("Messages"), queryLimit)
msgCount := *folderMessages.GetOdataCount()
log.With(zap.Int64("Count", msgCount)).Info("Message Count")
bar.ChangeMax64(msgCount)

// Proceeds to the processing loop

And inside my loop.

if err := bar.Add(1); err != nil {
	log.With(zap.Error(err)).Error("Failed to increment progress bar!")
}

I'm trying this code:

func main() {
	bar := progressbar.NewOptions(-1,
		progressbar.OptionSetDescription("spinnertest"),
		progressbar.OptionShowIts(),
		progressbar.OptionShowCount(),
		progressbar.OptionSpinnerType(7),
	)

	for i:=0; i < 100; i++ {
		bar.Add(1)
		time.Sleep(1 * time.Second)
	}
}

And I'm expecting that each time it updates, it would move 1 step in the spinner, instead it just flops back and forth between 2 values. If I use spinners with more steps, 1 second intervals also seem to skip steps.

If I change the delay to be time.Sleep(500 * time.Millisecond) it does work and I see all 4 steps, but my proposed usage would be at 1 second intervals. On the other hand, if I go to time.Sleep(2 * time.Second) I get no change in the spinner, although in all situations the count increments correctly.

Is there somewhere I need to set the "total time lapse" of a spinner rotation?

I have added ability to customize way of bytes show by adding an option.

func ExampleOptionUseCustomBytesShowWithMax() {
	bar := NewOptions(100,
		OptionSetWidth(10),
		OptionShowIts(),
		OptionShowCount(),
		OptionSetElapsedTime(false), OptionUseCustomBytesShow(func(f float64, i int64) string {
			return fmt.Sprintf("%.0f of %d items", f, i)
		}))
	bar.Reset()
	time.Sleep(1 * time.Second)
	bar.Add(5)

	// Output:
	// -  (5 of 100 items, 5 it/s)
}

closes #138