Quick preview of my current project

shift+tab switches between the screens. Eventually you'll be able to merge and split screens, though this is not implemented yet.

Some more demos:

Link
Link

(This was originally one video, but it's broken into two parts due to size restrictions)

Splitting is a work in progress… As you can see, the split isn't taking the entire screen. Oops!

Spoiler

Very cool looking!

I think it needs a preview of which monitor it's currently writing to on the current screen.

You could have tabs on the terminal, swapping between them for each monitor (term.redirect() to a monitor that's linked to a tab?) which would then redirect all output to the monitor while also displaying the output on your screen as well. Use a method similar to most remote-control computer programs (re-writing term functions and redirecting to the object) and it should work nicely.

Another way you could do it is just have an indicator of which monitor it's going to.

Also, just voicing my opinion here, this program doesn't look overly useful in that you need to have peripheral (ha, pun) vision of the monitors while also using the computer. Maybe a pocket computer could help with this, but still not quite ideal..Maybe use the MC chatbox method, using a command computer to parse the commands.

I think a preview would be incredibly difficult, if not impossible, to do correctly, considering the monitors are much larger than the original screen.

Similarly, displaying output on two displays which are different resolutions is a non-trivial problem. I do plan to add support for "mirroring" but only for monitors with the same width and height.

I have thought about an indicator of which monitor it's on, and I think that would be a good idea. I think flashing a 1px boarder on the current window when switching would be effective, though I would need additional windows to accomplish this… it would be inefficient and probably increase latency.

My thoughts were that it could be combined with a peripheral such as the Moarperipheral's keyboard to create an interesting concept. In addition, touch-to-mouse-click support will be added eventually, which will ignore which program is "active" and resume the program running on the clicked monitor with the mouse event. This would allow mouse-only programs to be used effectively.

KingofGamesYami, on 01 November 2017 - 04:58 PM said:

I think a preview would be incredibly difficult, if not impossible, to do correctly, considering the monitors are much larger than the original screen.

Similarly, displaying output on two displays which are different resolutions is a non-trivial problem. I do plan to add support for "mirroring" but only for monitors with the same width and height.

I have thought about an indicator of which monitor it's on, and I think that would be a good idea. I think flashing a 1px boarder on the current window when switching would be effective, though I would need additional windows to accomplish this… it would be inefficient and probably increase latency.

My thoughts were that it could be combined with a peripheral such as the Moarperipheral's keyboard to create an interesting concept. In addition, touch-to-mouse-click support will be added eventually, which will ignore which program is "active" and resume the program running on the clicked monitor with the mouse event. This would allow mouse-only programs to be used effectively.

I don't think it would be impossible..Since the monitor is still using the same resolution as the host computer (in a sense, it's still using the same amount of pixels per character even though the screen is bigger) and I'm assuming you're using window objects, therefore you can have a scrollbar on the buffer to scroll up and down, loading the screen as a window buffer rather than a program (if you catch my drift).

However you wouldn't need this. If you're just using CraftOS' CLI it doesn't matter - you can display it on the host without many problems.

Another method could just be swapping between tabs on your host that just get redirected to the selected monitor as well, instead of having the monitors 'hosting' an instance. While this may seem to limit your monitor, you could trick the program into thinking your computer's monitor size is bigger than it is (actually being the monitor itself), then your computer can handle the rest with scrollbars and things. This method requires the host program to catch events and pass them to the program, instead of the program catching it's own events - otherwise you'll have issues if it's a mouse-clickable GUI..

If you don't want to do any of these and you want to indicate which monitor your using, you could do it colour based, having a screen border on your client and on the monitor (or just a coloured pixel in a corner)..Or even have a backend menu like DISH does.

If you ask me, any way you look at it you've still got yourself into an event-catching mess, haha.

Oh yeah, I've definitely got a lot of events to catch and subsequently pass to the appropriate program. It's not really all that different than what I did with stitch*, especially since I'm using statemachine to handle the multitasking. In fact, I'm actually using stitch within this to do the monitor merging.

It's not necessarily going to be CraftOS running on the monitors. I just have that set up as a way to test. A preview which is scrollable is pretty dang ugly. Plus, you're assuming I'm using windows, which I'm not - well, not until something fancy happens (splits and merges are windows).

I like the 'colored pixel in a corner' idea - that sounds like it wouldn't be too intrusive, and fairly intuitive.

*See lines 218 - 244