1
0
mirror of https://github.com/jesseduffield/lazygit.git synced 2024-12-04 10:34:55 +02:00
lazygit/pkg/gui/tasks_adapter.go

142 lines
3.3 KiB
Go
Raw Normal View History

allow fast flicking through any list panel Up till now our approach to rendering things like file diffs, branch logs, and commit patches, has been to run a command on the command line, wait for it to complete, take its output as a string, and then write that string to the main view (or secondary view e.g. when showing both staged and unstaged changes of a file). This has caused various issues. For once, if you are flicking through a list of files and an untracked file is particularly large, not only will this require lazygit to load that whole file into memory (or more accurately it's equally large diff), it also will slow down the UI thread while loading that file, and if the user continued down the list, the original command might eventually resolve and replace whatever the diff is for the newly selected file. Following what we've done in lazydocker, I've added a tasks package for when you need something done but you want it to cancel as soon as something newer comes up. Given this typically involves running a command to display to a view, I've added a viewBufferManagerMap struct to the Gui struct which allows you to define these tasks on a per-view basis. viewBufferManagers can run files and directly write the output to their view, meaning we no longer need to use so much memory. In the tasks package there is a helper method called NewCmdTask which takes a command, an initial amount of lines to read, and then runs that command, reads that number of lines, and allows for a readLines channel to tell it to read more lines. We read more lines when we scroll or resize the window. There is an adapter for the tasks package in a file called tasks_adapter which wraps the functions from the tasks package in gui-specific stuff like clearing the main view before starting the next task that wants to write to the main view. I've removed some small features as part of this work, namely the little headers that were at the top of the main view for some situations. For example, we no longer show the upstream of a selected branch. I want to re-introduce this in the future, but I didn't want to make this tasks system too complicated, and in order to facilitate a header section in the main view we'd need to have a task that gets the upstream for the current branch, writes it to the header, then tells another task to write the branch log to the main view, but without clearing inbetween. So it would get messy. I'm thinking instead of having a separate 'header' view atop the main view to render that kind of thing (which can happen in another PR) I've also simplified the 'git show' to just call 'git show' and not do anything fancy when it comes to merge commits. I considered using this tasks approach whenever we write to a view. The only thing is that the renderString method currently resets the origin of a view and I don't want to lose that. So I've left some in there that I consider harmless, but we should probably be just using tasks now for all rendering, even if it's just strings we can instantly make.
2020-01-11 05:54:59 +02:00
package gui
import (
2021-11-02 07:39:15 +02:00
"io"
allow fast flicking through any list panel Up till now our approach to rendering things like file diffs, branch logs, and commit patches, has been to run a command on the command line, wait for it to complete, take its output as a string, and then write that string to the main view (or secondary view e.g. when showing both staged and unstaged changes of a file). This has caused various issues. For once, if you are flicking through a list of files and an untracked file is particularly large, not only will this require lazygit to load that whole file into memory (or more accurately it's equally large diff), it also will slow down the UI thread while loading that file, and if the user continued down the list, the original command might eventually resolve and replace whatever the diff is for the newly selected file. Following what we've done in lazydocker, I've added a tasks package for when you need something done but you want it to cancel as soon as something newer comes up. Given this typically involves running a command to display to a view, I've added a viewBufferManagerMap struct to the Gui struct which allows you to define these tasks on a per-view basis. viewBufferManagers can run files and directly write the output to their view, meaning we no longer need to use so much memory. In the tasks package there is a helper method called NewCmdTask which takes a command, an initial amount of lines to read, and then runs that command, reads that number of lines, and allows for a readLines channel to tell it to read more lines. We read more lines when we scroll or resize the window. There is an adapter for the tasks package in a file called tasks_adapter which wraps the functions from the tasks package in gui-specific stuff like clearing the main view before starting the next task that wants to write to the main view. I've removed some small features as part of this work, namely the little headers that were at the top of the main view for some situations. For example, we no longer show the upstream of a selected branch. I want to re-introduce this in the future, but I didn't want to make this tasks system too complicated, and in order to facilitate a header section in the main view we'd need to have a task that gets the upstream for the current branch, writes it to the header, then tells another task to write the branch log to the main view, but without clearing inbetween. So it would get messy. I'm thinking instead of having a separate 'header' view atop the main view to render that kind of thing (which can happen in another PR) I've also simplified the 'git show' to just call 'git show' and not do anything fancy when it comes to merge commits. I considered using this tasks approach whenever we write to a view. The only thing is that the renderString method currently resets the origin of a view and I don't want to lose that. So I've left some in there that I consider harmless, but we should probably be just using tasks now for all rendering, even if it's just strings we can instantly make.
2020-01-11 05:54:59 +02:00
"os/exec"
2020-09-26 02:45:13 +02:00
"strings"
allow fast flicking through any list panel Up till now our approach to rendering things like file diffs, branch logs, and commit patches, has been to run a command on the command line, wait for it to complete, take its output as a string, and then write that string to the main view (or secondary view e.g. when showing both staged and unstaged changes of a file). This has caused various issues. For once, if you are flicking through a list of files and an untracked file is particularly large, not only will this require lazygit to load that whole file into memory (or more accurately it's equally large diff), it also will slow down the UI thread while loading that file, and if the user continued down the list, the original command might eventually resolve and replace whatever the diff is for the newly selected file. Following what we've done in lazydocker, I've added a tasks package for when you need something done but you want it to cancel as soon as something newer comes up. Given this typically involves running a command to display to a view, I've added a viewBufferManagerMap struct to the Gui struct which allows you to define these tasks on a per-view basis. viewBufferManagers can run files and directly write the output to their view, meaning we no longer need to use so much memory. In the tasks package there is a helper method called NewCmdTask which takes a command, an initial amount of lines to read, and then runs that command, reads that number of lines, and allows for a readLines channel to tell it to read more lines. We read more lines when we scroll or resize the window. There is an adapter for the tasks package in a file called tasks_adapter which wraps the functions from the tasks package in gui-specific stuff like clearing the main view before starting the next task that wants to write to the main view. I've removed some small features as part of this work, namely the little headers that were at the top of the main view for some situations. For example, we no longer show the upstream of a selected branch. I want to re-introduce this in the future, but I didn't want to make this tasks system too complicated, and in order to facilitate a header section in the main view we'd need to have a task that gets the upstream for the current branch, writes it to the header, then tells another task to write the branch log to the main view, but without clearing inbetween. So it would get messy. I'm thinking instead of having a separate 'header' view atop the main view to render that kind of thing (which can happen in another PR) I've also simplified the 'git show' to just call 'git show' and not do anything fancy when it comes to merge commits. I considered using this tasks approach whenever we write to a view. The only thing is that the renderString method currently resets the origin of a view and I don't want to lose that. So I've left some in there that I consider harmless, but we should probably be just using tasks now for all rendering, even if it's just strings we can instantly make.
2020-01-11 05:54:59 +02:00
"github.com/jesseduffield/gocui"
"github.com/jesseduffield/lazygit/pkg/tasks"
)
2021-04-04 16:31:52 +02:00
func (gui *Gui) newCmdTask(view *gocui.View, cmd *exec.Cmd, prefix string) error {
2021-10-17 10:01:02 +02:00
cmdStr := strings.Join(cmd.Args, " ")
gui.c.Log.WithField(
2020-09-26 02:45:13 +02:00
"command",
2021-10-17 10:01:02 +02:00
cmdStr,
2020-09-26 02:45:13 +02:00
).Debug("RunCommand")
allow fast flicking through any list panel Up till now our approach to rendering things like file diffs, branch logs, and commit patches, has been to run a command on the command line, wait for it to complete, take its output as a string, and then write that string to the main view (or secondary view e.g. when showing both staged and unstaged changes of a file). This has caused various issues. For once, if you are flicking through a list of files and an untracked file is particularly large, not only will this require lazygit to load that whole file into memory (or more accurately it's equally large diff), it also will slow down the UI thread while loading that file, and if the user continued down the list, the original command might eventually resolve and replace whatever the diff is for the newly selected file. Following what we've done in lazydocker, I've added a tasks package for when you need something done but you want it to cancel as soon as something newer comes up. Given this typically involves running a command to display to a view, I've added a viewBufferManagerMap struct to the Gui struct which allows you to define these tasks on a per-view basis. viewBufferManagers can run files and directly write the output to their view, meaning we no longer need to use so much memory. In the tasks package there is a helper method called NewCmdTask which takes a command, an initial amount of lines to read, and then runs that command, reads that number of lines, and allows for a readLines channel to tell it to read more lines. We read more lines when we scroll or resize the window. There is an adapter for the tasks package in a file called tasks_adapter which wraps the functions from the tasks package in gui-specific stuff like clearing the main view before starting the next task that wants to write to the main view. I've removed some small features as part of this work, namely the little headers that were at the top of the main view for some situations. For example, we no longer show the upstream of a selected branch. I want to re-introduce this in the future, but I didn't want to make this tasks system too complicated, and in order to facilitate a header section in the main view we'd need to have a task that gets the upstream for the current branch, writes it to the header, then tells another task to write the branch log to the main view, but without clearing inbetween. So it would get messy. I'm thinking instead of having a separate 'header' view atop the main view to render that kind of thing (which can happen in another PR) I've also simplified the 'git show' to just call 'git show' and not do anything fancy when it comes to merge commits. I considered using this tasks approach whenever we write to a view. The only thing is that the renderString method currently resets the origin of a view and I don't want to lose that. So I've left some in there that I consider harmless, but we should probably be just using tasks now for all rendering, even if it's just strings we can instantly make.
2020-01-11 05:54:59 +02:00
manager := gui.getManager(view)
2021-11-02 07:39:15 +02:00
start := func() (*exec.Cmd, io.Reader) {
r, err := cmd.StdoutPipe()
if err != nil {
gui.c.Log.Error(err)
2021-11-02 07:39:15 +02:00
}
cmd.Stderr = cmd.Stdout
2020-03-01 03:30:48 +02:00
2021-11-02 07:39:15 +02:00
if err := cmd.Start(); err != nil {
gui.c.Log.Error(err)
2021-11-02 07:39:15 +02:00
}
return cmd, r
2020-03-01 03:30:48 +02:00
}
linesToRead := gui.linesToReadFromCmdTask(view)
if err := manager.NewTask(manager.NewCmdTask(start, prefix, linesToRead, nil), cmdStr); err != nil {
gui.c.Log.Error(err)
allow fast flicking through any list panel Up till now our approach to rendering things like file diffs, branch logs, and commit patches, has been to run a command on the command line, wait for it to complete, take its output as a string, and then write that string to the main view (or secondary view e.g. when showing both staged and unstaged changes of a file). This has caused various issues. For once, if you are flicking through a list of files and an untracked file is particularly large, not only will this require lazygit to load that whole file into memory (or more accurately it's equally large diff), it also will slow down the UI thread while loading that file, and if the user continued down the list, the original command might eventually resolve and replace whatever the diff is for the newly selected file. Following what we've done in lazydocker, I've added a tasks package for when you need something done but you want it to cancel as soon as something newer comes up. Given this typically involves running a command to display to a view, I've added a viewBufferManagerMap struct to the Gui struct which allows you to define these tasks on a per-view basis. viewBufferManagers can run files and directly write the output to their view, meaning we no longer need to use so much memory. In the tasks package there is a helper method called NewCmdTask which takes a command, an initial amount of lines to read, and then runs that command, reads that number of lines, and allows for a readLines channel to tell it to read more lines. We read more lines when we scroll or resize the window. There is an adapter for the tasks package in a file called tasks_adapter which wraps the functions from the tasks package in gui-specific stuff like clearing the main view before starting the next task that wants to write to the main view. I've removed some small features as part of this work, namely the little headers that were at the top of the main view for some situations. For example, we no longer show the upstream of a selected branch. I want to re-introduce this in the future, but I didn't want to make this tasks system too complicated, and in order to facilitate a header section in the main view we'd need to have a task that gets the upstream for the current branch, writes it to the header, then tells another task to write the branch log to the main view, but without clearing inbetween. So it would get messy. I'm thinking instead of having a separate 'header' view atop the main view to render that kind of thing (which can happen in another PR) I've also simplified the 'git show' to just call 'git show' and not do anything fancy when it comes to merge commits. I considered using this tasks approach whenever we write to a view. The only thing is that the renderString method currently resets the origin of a view and I don't want to lose that. So I've left some in there that I consider harmless, but we should probably be just using tasks now for all rendering, even if it's just strings we can instantly make.
2020-01-11 05:54:59 +02:00
}
return nil
}
2021-04-04 16:31:52 +02:00
func (gui *Gui) newStringTask(view *gocui.View, str string) error {
2021-10-17 10:01:02 +02:00
// using str so that if rendering the exact same thing we don't reset the origin
return gui.newStringTaskWithKey(view, str, str)
allow fast flicking through any list panel Up till now our approach to rendering things like file diffs, branch logs, and commit patches, has been to run a command on the command line, wait for it to complete, take its output as a string, and then write that string to the main view (or secondary view e.g. when showing both staged and unstaged changes of a file). This has caused various issues. For once, if you are flicking through a list of files and an untracked file is particularly large, not only will this require lazygit to load that whole file into memory (or more accurately it's equally large diff), it also will slow down the UI thread while loading that file, and if the user continued down the list, the original command might eventually resolve and replace whatever the diff is for the newly selected file. Following what we've done in lazydocker, I've added a tasks package for when you need something done but you want it to cancel as soon as something newer comes up. Given this typically involves running a command to display to a view, I've added a viewBufferManagerMap struct to the Gui struct which allows you to define these tasks on a per-view basis. viewBufferManagers can run files and directly write the output to their view, meaning we no longer need to use so much memory. In the tasks package there is a helper method called NewCmdTask which takes a command, an initial amount of lines to read, and then runs that command, reads that number of lines, and allows for a readLines channel to tell it to read more lines. We read more lines when we scroll or resize the window. There is an adapter for the tasks package in a file called tasks_adapter which wraps the functions from the tasks package in gui-specific stuff like clearing the main view before starting the next task that wants to write to the main view. I've removed some small features as part of this work, namely the little headers that were at the top of the main view for some situations. For example, we no longer show the upstream of a selected branch. I want to re-introduce this in the future, but I didn't want to make this tasks system too complicated, and in order to facilitate a header section in the main view we'd need to have a task that gets the upstream for the current branch, writes it to the header, then tells another task to write the branch log to the main view, but without clearing inbetween. So it would get messy. I'm thinking instead of having a separate 'header' view atop the main view to render that kind of thing (which can happen in another PR) I've also simplified the 'git show' to just call 'git show' and not do anything fancy when it comes to merge commits. I considered using this tasks approach whenever we write to a view. The only thing is that the renderString method currently resets the origin of a view and I don't want to lose that. So I've left some in there that I consider harmless, but we should probably be just using tasks now for all rendering, even if it's just strings we can instantly make.
2020-01-11 05:54:59 +02:00
}
2021-04-04 16:31:52 +02:00
func (gui *Gui) newStringTaskWithoutScroll(view *gocui.View, str string) error {
2021-10-22 12:48:43 +02:00
manager := gui.getManager(view)
f := func(tasks.TaskOpts) error {
gui.c.SetViewContent(view, str)
2021-10-22 12:48:43 +02:00
return nil
}
// Using empty key so that on subsequent calls we won't reset the view's origin.
// Note this means that we will be scrolling back to the top if we're switching from a different key
if err := manager.NewTask(f, ""); err != nil {
return err
}
return nil
2021-10-17 10:01:02 +02:00
}
func (gui *Gui) newStringTaskWithScroll(view *gocui.View, str string, originX int, originY int) error {
manager := gui.getManager(view)
f := func(tasks.TaskOpts) error {
gui.c.SetViewContent(view, str)
_ = view.SetOrigin(originX, originY)
return nil
}
if err := manager.NewTask(f, ""); err != nil {
return err
}
return nil
}
2021-10-17 10:01:02 +02:00
func (gui *Gui) newStringTaskWithKey(view *gocui.View, str string, key string) error {
manager := gui.getManager(view)
f := func(tasks.TaskOpts) error {
gui.c.ResetViewOrigin(view)
gui.c.SetViewContent(view, str)
return nil
}
2021-10-17 10:01:02 +02:00
if err := manager.NewTask(f, key); err != nil {
return err
}
return nil
}
allow fast flicking through any list panel Up till now our approach to rendering things like file diffs, branch logs, and commit patches, has been to run a command on the command line, wait for it to complete, take its output as a string, and then write that string to the main view (or secondary view e.g. when showing both staged and unstaged changes of a file). This has caused various issues. For once, if you are flicking through a list of files and an untracked file is particularly large, not only will this require lazygit to load that whole file into memory (or more accurately it's equally large diff), it also will slow down the UI thread while loading that file, and if the user continued down the list, the original command might eventually resolve and replace whatever the diff is for the newly selected file. Following what we've done in lazydocker, I've added a tasks package for when you need something done but you want it to cancel as soon as something newer comes up. Given this typically involves running a command to display to a view, I've added a viewBufferManagerMap struct to the Gui struct which allows you to define these tasks on a per-view basis. viewBufferManagers can run files and directly write the output to their view, meaning we no longer need to use so much memory. In the tasks package there is a helper method called NewCmdTask which takes a command, an initial amount of lines to read, and then runs that command, reads that number of lines, and allows for a readLines channel to tell it to read more lines. We read more lines when we scroll or resize the window. There is an adapter for the tasks package in a file called tasks_adapter which wraps the functions from the tasks package in gui-specific stuff like clearing the main view before starting the next task that wants to write to the main view. I've removed some small features as part of this work, namely the little headers that were at the top of the main view for some situations. For example, we no longer show the upstream of a selected branch. I want to re-introduce this in the future, but I didn't want to make this tasks system too complicated, and in order to facilitate a header section in the main view we'd need to have a task that gets the upstream for the current branch, writes it to the header, then tells another task to write the branch log to the main view, but without clearing inbetween. So it would get messy. I'm thinking instead of having a separate 'header' view atop the main view to render that kind of thing (which can happen in another PR) I've also simplified the 'git show' to just call 'git show' and not do anything fancy when it comes to merge commits. I considered using this tasks approach whenever we write to a view. The only thing is that the renderString method currently resets the origin of a view and I don't want to lose that. So I've left some in there that I consider harmless, but we should probably be just using tasks now for all rendering, even if it's just strings we can instantly make.
2020-01-11 05:54:59 +02:00
func (gui *Gui) getManager(view *gocui.View) *tasks.ViewBufferManager {
manager, ok := gui.viewBufferManagerMap[view.Name()]
if !ok {
manager = tasks.NewViewBufferManager(
gui.Log,
view,
func() {
// we could clear here, but that actually has the effect of causing a flicker
// where the view may contain no content momentarily as the gui refreshes.
// Instead, we're rewinding the write pointer so that we will just start
// overwriting the existing content from the top down. Once we've reached
// the end of the content do display, we call view.FlushStaleCells() to
// clear out the remaining content from the previous render.
view.Reset()
allow fast flicking through any list panel Up till now our approach to rendering things like file diffs, branch logs, and commit patches, has been to run a command on the command line, wait for it to complete, take its output as a string, and then write that string to the main view (or secondary view e.g. when showing both staged and unstaged changes of a file). This has caused various issues. For once, if you are flicking through a list of files and an untracked file is particularly large, not only will this require lazygit to load that whole file into memory (or more accurately it's equally large diff), it also will slow down the UI thread while loading that file, and if the user continued down the list, the original command might eventually resolve and replace whatever the diff is for the newly selected file. Following what we've done in lazydocker, I've added a tasks package for when you need something done but you want it to cancel as soon as something newer comes up. Given this typically involves running a command to display to a view, I've added a viewBufferManagerMap struct to the Gui struct which allows you to define these tasks on a per-view basis. viewBufferManagers can run files and directly write the output to their view, meaning we no longer need to use so much memory. In the tasks package there is a helper method called NewCmdTask which takes a command, an initial amount of lines to read, and then runs that command, reads that number of lines, and allows for a readLines channel to tell it to read more lines. We read more lines when we scroll or resize the window. There is an adapter for the tasks package in a file called tasks_adapter which wraps the functions from the tasks package in gui-specific stuff like clearing the main view before starting the next task that wants to write to the main view. I've removed some small features as part of this work, namely the little headers that were at the top of the main view for some situations. For example, we no longer show the upstream of a selected branch. I want to re-introduce this in the future, but I didn't want to make this tasks system too complicated, and in order to facilitate a header section in the main view we'd need to have a task that gets the upstream for the current branch, writes it to the header, then tells another task to write the branch log to the main view, but without clearing inbetween. So it would get messy. I'm thinking instead of having a separate 'header' view atop the main view to render that kind of thing (which can happen in another PR) I've also simplified the 'git show' to just call 'git show' and not do anything fancy when it comes to merge commits. I considered using this tasks approach whenever we write to a view. The only thing is that the renderString method currently resets the origin of a view and I don't want to lose that. So I've left some in there that I consider harmless, but we should probably be just using tasks now for all rendering, even if it's just strings we can instantly make.
2020-01-11 05:54:59 +02:00
},
func() {
gui.render()
},
func() {
2021-10-17 10:01:02 +02:00
// Need to check if the content of the view is well past the origin.
2022-04-16 07:27:56 +02:00
linesHeight := view.ViewLinesHeight()
2021-10-17 10:01:02 +02:00
_, originY := view.Origin()
if linesHeight < originY {
2022-04-16 07:27:56 +02:00
newOriginY := linesHeight
2021-10-17 10:01:02 +02:00
err := view.SetOrigin(0, newOriginY)
if err != nil {
panic(err)
}
}
view.FlushStaleCells()
},
2021-10-17 10:01:02 +02:00
func() {
_ = view.SetOrigin(0, 0)
},
Use first class task objects instead of global counter The global counter approach is easy to understand but it's brittle and depends on implicit behaviour that is not very discoverable. With a global counter, if any goroutine accidentally decrements the counter twice, we'll think lazygit is idle when it's actually busy. Likewise if a goroutine accidentally increments the counter twice we'll think lazygit is busy when it's actually idle. With the new approach we have a map of tasks where each task can either be busy or not. We create a new task and add it to the map when we spawn a worker goroutine (among other things) and we remove it once the task is done. The task can also be paused and continued for situations where we switch back and forth between running a program and asking for user input. In order for this to work with `git push` (and other commands that require credentials) we need to obtain the task from gocui when we create the worker goroutine, and then pass it along to the commands package to pause/continue the task as required. This is MUCH more discoverable than the old approach which just decremented and incremented the global counter from within the commands package, but it's at the cost of expanding some function signatures (arguably a good thing). Likewise, whenever you want to call WithWaitingStatus or WithLoaderPanel the callback will now have access to the task for pausing/ continuing. We only need to actually make use of this functionality in a couple of places so it's a high price to pay, but I don't know if I want to introduce a WithWaitingStatusTask and WithLoaderPanelTask function (open to suggestions).
2023-07-09 03:32:27 +02:00
func() *gocui.Task {
return gui.c.GocuiGui().NewTask()
},
)
allow fast flicking through any list panel Up till now our approach to rendering things like file diffs, branch logs, and commit patches, has been to run a command on the command line, wait for it to complete, take its output as a string, and then write that string to the main view (or secondary view e.g. when showing both staged and unstaged changes of a file). This has caused various issues. For once, if you are flicking through a list of files and an untracked file is particularly large, not only will this require lazygit to load that whole file into memory (or more accurately it's equally large diff), it also will slow down the UI thread while loading that file, and if the user continued down the list, the original command might eventually resolve and replace whatever the diff is for the newly selected file. Following what we've done in lazydocker, I've added a tasks package for when you need something done but you want it to cancel as soon as something newer comes up. Given this typically involves running a command to display to a view, I've added a viewBufferManagerMap struct to the Gui struct which allows you to define these tasks on a per-view basis. viewBufferManagers can run files and directly write the output to their view, meaning we no longer need to use so much memory. In the tasks package there is a helper method called NewCmdTask which takes a command, an initial amount of lines to read, and then runs that command, reads that number of lines, and allows for a readLines channel to tell it to read more lines. We read more lines when we scroll or resize the window. There is an adapter for the tasks package in a file called tasks_adapter which wraps the functions from the tasks package in gui-specific stuff like clearing the main view before starting the next task that wants to write to the main view. I've removed some small features as part of this work, namely the little headers that were at the top of the main view for some situations. For example, we no longer show the upstream of a selected branch. I want to re-introduce this in the future, but I didn't want to make this tasks system too complicated, and in order to facilitate a header section in the main view we'd need to have a task that gets the upstream for the current branch, writes it to the header, then tells another task to write the branch log to the main view, but without clearing inbetween. So it would get messy. I'm thinking instead of having a separate 'header' view atop the main view to render that kind of thing (which can happen in another PR) I've also simplified the 'git show' to just call 'git show' and not do anything fancy when it comes to merge commits. I considered using this tasks approach whenever we write to a view. The only thing is that the renderString method currently resets the origin of a view and I don't want to lose that. So I've left some in there that I consider harmless, but we should probably be just using tasks now for all rendering, even if it's just strings we can instantly make.
2020-01-11 05:54:59 +02:00
gui.viewBufferManagerMap[view.Name()] = manager
}
return manager
}