I think Kepler and I discussed this when #156 was opened, but I never spun it out into a separate issue.

The window API is incredibly useful, but I (and I suspect other people) often end up rolling their own implementation because they need a specific bit of functionality. It'd be nice if we could expand the window API to include some of the more common use-cases.

Some ideas of things it might be potentially nice to have:

• Ability to read back the current frame buffer - possibly something as simple as Window.getLine(line:number): string, string, string.

• Extend Window.reposition(...) to also take a different redirect buffer - allow changing the parent after creating the window.

• Some way to determine when the buffer has changed/is dirty? I'm really not sure how to do this in an efficient way - both a polling (set a flag) or callback (call a function) mechanism have their problems.

• More? I don't know what sort of other common use-cases there are.

A couple of things to stress here: Firstly, I don't want to sacrifice on performance any more than is necessary. On advanced computers, every program is running through at least one layer of window instances, so we need to keep this as fast as possible.

I also don't want to handle every use case, only ones which are well suited to the current design, and people often find themselves needing. Things like mbs's scrolling buffer are really not suitable.

For the has changed/is dirty thing is there any issue with providing both a callback option and a polling option? Aside from the duplication.

I think window.getLine can be as simple as this:
window.getLine(line:number, includeColors:bool): string
If you pass includeColors it will return the line with §<color> for each color change, and obviously prepending the first character's color.

Possible useful feature, being able to change the colour of a pixel without changing the character in the pixel.

Although the user could do this with get line

For the has changed/is dirty thing is there any issue with providing both a callback option and a polling option? Aside from the duplication.

I'm a little worried about performance, though I doubt it'll be too terrible TBH.

If you pass includeColors it will return the line with § for each color change, and obviously prepending the first character's color.

This just feels a really ugly API, as it's not really in sync with the rest of how CC's terminals work.

This just feels a really ugly API, as it's not really in sync with the rest of how CC's terminals work.

I just took a look at Terminal.java and you're right. Your way makes a lot more sense now lol.

getLine has just been added 🎉, though I'm not entirely happy with the naming. Don't know if people have any alternative suggestions?

I did not think about it. However, somehow when you use the read function, it returns a line of text that has just been written on the screen by the user.
If anyone expected that from a Window.read() function it could work.

Since we use the "write" function, the getLine function could be called "read". In the same way as a file handler.

@absolument

Since we use the "write" function, the getLine function could be called "read". In the same way as a file handler.

Maybe calling it readLine instead ? I think it's better than read because it's says directly what it does, but calling it read or readLine could be misleading no ? I mean people could think it has the same behaviour as the read function from bios.lua, IDK.