dankox
commented
3 years ago I was looking into it a bit and at first it didn't really make sense at all. Why would g.Update cause such a problem with print into the view. But after some testing and looking into @Rudi9719 code in his repo, I think the problem is somewhere else.
I was testing the original code with simple example and it works fine, you can try:
package main
import (
"fmt"
"log"
"sync"
"time"
"github.com/awesome-gocui/gocui"
)
var (
done = make(chan struct{})
wg sync.WaitGroup
)
func main() {
g, err := gocui.NewGui(gocui.OutputNormal, true)
if err != nil {
log.Panicln(err)
}
defer g.Close()
g.SetManagerFunc(layout)
if err := keybindings(g); err != nil {
log.Panicln(err)
}
printView(g)
wg.Add(1)
go textMessage(g)
if err := g.MainLoop(); err != nil && err != gocui.ErrQuit {
log.Panicln(err)
}
wg.Wait()
}
func layout(g *gocui.Gui) error {
if v, err := g.SetView("myView", 2, 2, 50, 12, 0); err != nil {
if err != gocui.ErrUnknownView {
return err
}
v.Autoscroll = true
// v.Wrap = true <- this is the problem
fmt.Fprintln(v, "starting...")
}
return nil
}
func keybindings(g *gocui.Gui) error {
if err := g.SetKeybinding("", gocui.KeyCtrlC, gocui.ModNone, quit); err != nil {
return err
}
return nil
}
func quit(g *gocui.Gui, v *gocui.View) error {
close(done)
return gocui.ErrQuit
}
func textMessage(g *gocui.Gui) {
defer wg.Done()
for {
select {
case <-done:
return
case <-time.After(2000 * time.Millisecond):
printView(g)
}
}
}
func printView(g *gocui.Gui) {
g.Update(func(g *gocui.Gui) error {
updatingView, err := g.View("myView")
if err != nil {
return err
}
fmt.Fprintf(updatingView, "%s\n", "test message: "+time.Now().String())
return nil
})
}If you run the above code, the lines are print from the beginning in 2 seconds delays in between. Kinda simulate the problem.
However, I looked into his repo to see what else is there and I noticed that they use on all views Autoscroll and Wrap. So I tried with Autoscrol all good.
But Wrap is kinda different. If you set wrap, it will add one more line to the output and if the output should be scrolled, it might not (because of how the line count was counted).
In the sample above, just uncomment the Wrap line in layout function and you can see the difference where the lines are printed in 2 seconds interval until the end of view is hit and then a longer delay appears until the next line is printed (even though you can see it has the correct timestamp on it).
The reason is probably because the output is out of the view and is pushed in to the view after more lines are printed.
@Rudi9719 can you confirm the problem might be as described? With delay at the end of View container? Or does the problem appears also in the middle of the view, when it shouldn't scroll?
Rudi9719
mjarkk
fixes: #92