HerrCrazi

Ahh, no problem buddy. Happy to be of some help. Thanks for the feedback as well, it would seem useful to know. Smooches

Maybe, opening a term window shouldn't be such a pain.. I have done it before, just need to remember and test how I did it... I'll post back asap
I figured a way to switch terminals. Dunno if its a "good" way or not but it should work.
local component = require "component" local process = require "process" local term = require "term" local termGpuAddr, termScrAddr = ... -- # use whatever logic you would to get the relevant component address (this line will cause an error if you dont shove some address in) local termGpu = component.proxy(termGpuAddr) termGpu.bind(termScrAddr) -- # component bind -- # I thought you could get the current term window with `process.info().data.window` or `rawget(process.info().data, 'window')` or `term.internal.window()` -- # for some reason getting the current window was giving me nil, even with rawget :/ local window = term.internal.open() -- # create new term window term.bind(termGpu, window) -- # bind pty to gpu window.keyboard = component.invoke(termScrAddr, 'getKeyboards')[1] -- # dont forget a keyboard or it will use the last term kb -- # lastly you have to assign the window to an actual process. here we'll assign the init process our window. all child processes will inherit this window local init_index = 1 -- # find the highest process (init) while true do if process.info(init_index + 1) then init_index = init_index + 1 else break end end -- # cram 'er in there. If you only want the current process to use the pty just use `process.info().data.window = window` process.info(init_index).data.window = window This is tested and should work. It did for me anyway. just adjust for termGpuAddr and termScrAddr

I feel like I should add some more information.. Just some things I learned asking around and poking at the OpenOS source. So here it goes. Term "windows" aren't really a feature of the OS, they're kinda hidden, and in my quest to abuse them I learned that at the moment they're kinda 'half baked', although functional. If you look at the `term` library you'll see that a lot of methods take an optional `window` argument but the library lacks a documented way to create or get a new or active pty. Wtf mang. Another tip would be to note that the computer has no preference for screen and/or keyboard proximity, hence why you're in this mess in the first place. So it would be handy to know that the "boot screen" is what will become the "primary" screen component and thus the init process(highest process in the OS) will bind the boot screen and first gpu compatible with that screen. `tty.window`  is referenced in `process.info(init_index).data.window`
You can see more of this reflected in the concept of primary components and that even extends to the /dev dir... i.e.
-- # get the first non-'primary' component of `ctype` local function getSecondary(ctype) -- # dev component/ listings start at 0. Thus /dev/components/by-type/`ctype`/1 is the second gpu.. local fd = assert(io.open('/dev/components/by-type/'..ctype..'/1/address', 'r')) local address = fd:read('*a') fd:close() return address end You could use this in my example above.
local component = require "component" local process = require "process" local term = require "term" local function getSecondary(ctype) local fd = assert(io.open('/dev/components/by-type/'..ctype..'/1/address', 'r')) local address = fd:read('*a') fd:close() return address end -- # Get the first non-primary gpu and screen, assuming that this is in a condition where we want to switch the screen... local termGpuAddr, termScrAddr = getSecondary('gpu'), getSecondary('screen') local termGpu = component.proxy(termGpuAddr) termGpu.bind(termScrAddr) local window = term.internal.open() term.bind(termGpu, window) window.keyboard = component.invoke(termScrAddr, 'getKeyboards')[1] local init_index = 1 while true do if process.info(init_index + 1) then init_index = init_index + 1 else break end end process.info(init_index).data.window = window I hope some of this info may save you some time.. Good luck. And feel free to ask away bud

This is an object-oriented library, the main priority of which is the maximum possible performance. It works on the double buffering concept, it has a lot of widgets, animations and custom event handlers support. All programs from the screenshots above are implemented with its help. If you want to develop a fast and beautiful program in just a few lines of code without butthurt - then this library is made for you.

Detailed illustrated documentation, installation methods and tons of practical examples are available at:
https://github.com/IgorTimofeev/GUI