Modify The Terminal?

Hey guys, I was just wondering, for my OS, I would really like to have the terminal but I want the very top (or bottom) line to be a clock and maybe some other stuff aswell. I am wondering if there is some way I can change the terminal to not use the bottom/top line and then control it myself. I assume it would be possible to make a "thread" to update a clock yes?

Do not use the command term.setCursorPos(x,1) or term.setCursorPos(x,<height>) followed by term.write(<string>) and that's the main part.
I hear term.scroll(), print() and term.clear() are ones to stay away from also.
Either that or you'll have to ensure your clock prints over the top of anything else that prints there.

An OS should be an advanced program/s and will require you to really know how to do this.

reububble, on 17 August 2013 - 11:31 PM said:

Do not use the command term.setCursorPos(x,1) or term.setCursorPos(x,<height>) followed by term.write(<string>) and that's the main part.
I hear term.scroll(), print() and term.clear() are ones to stay away from also.

… What? That's not valid information. term.scroll, print, and term.clear are perfectly fine functions to use. Moreover, they have nothing to do with what the OP is asking.

Either that or you'll have to ensure your clock prints over the top of anything else that prints there.

This is possible, but there are better solutions.

An OS should be an advanced program/s and will require you to really know how to do this.

False. An OS can be as simple or as advanced as the programmer wants.

@OP - This is pretty simply achievable by using function replacement. With function replacement, you essentially redefine the functions that handle moving the cursor so that nothing is ever drawn in whatever areas of the screen you want. For example:

local setCursorPos = term.setCursorPos --# This is our function backup. That way, we can still use the function once we redefine the old one
term.setCursorPos = function(x,y)
  if y>=1 then
    setCursorPos(x,y+1)
  end
end

This way, only your program will be able to write at the y-pos 1 using the backup function we made.

Bubba are you following me?

I'll agree that the OS can be simple or advanced. I do not agree that my statement was "False". I simply said, and I purposely said, that the OS "should" be advanced. This cannot be proven, and exists as an opinion based on the wording I've used.
But still, my advice stands quite well. If the OP wants to not print on the top and bottom lines, then that is entirely up to the way that they code the program. The only reason the program would print in the top or bottom lines is because the OP scripted it to work that way.

It's like asking the checkout assistant to make sure you don't buy any cheese.
The only person who can make sure of that is yourself… Just, don't buy cheese.

I like the replacement of the function, but I know that there are more efficient ways to make sure you don't write the wrong code.

Maybe you should draw out how you want your OS to look, and label all the important locations with their coordinates.
I suggest you stay away from the print() function for this reason: it changes the y position. This can and will eventually result in the bottom line being written over.
I suggest you stay away from the clear() function for this reason: it colours the entire screen with the selected background colour. This can result in only the string you place over the line to be the correct colour.
I suggest you stay away from the scroll() function for this reason: it scrolls the entire screen. This can result in the bottom and top lines becoming distorted, as the function does not disclude them from the scroll.

Bubba, on 18 August 2013 - 12:42 AM said:

@OP - This is pretty simply achievable by using function replacement. With function replacement, you essentially redefine the functions that handle moving the cursor so that nothing is ever drawn in whatever areas of the screen you want. For example:

local setCursorPos = term.setCursorPos --# This is our function backup. That way, we can still use the function once we redefine the old one
term.setCursorPos = function(x,y)
  if y>=1 then
	setCursorPos(x,y+1)
  end
end

This way, only your program will be able to write at the y-pos 1 using the backup function we made.

There is 2 major things I would actually do in line of what you posted:

1. Check the bottom line too (since that's what OP asked about too)
2. Override the term.getSize function as well

local getSize = term.getSize
term.getSize = function()
local w,h = getSize()
return w, h-2
end

this way it also attempts to get programs that draw based on screen size don't look odd or funny. using this method i'd also just shift the setCursorPos calls by y on the y axis that way it prints in-between the top and bottom bars.

reububble, on 18 August 2013 - 05:11 AM said:

-snip-

I don't understand your desire to tell OP to steer clear of particular functions, these functions don't have a problem when used correctly! and with some simple overrides/upgrades of those functions can be improved to work nicely in such a way that they wont cause a problem. for example when term.scroll is used it could scroll just the inner area, this would make more sense than telling people with programs for the OS that they "can't use those functions" because who would code for an OS like that!

reububble, on 18 August 2013 - 05:11 AM said:

Bubba are you following me?

Not following you. I'm simply supposed to moderate and respond to the topics in AaP, and you happen to be posting in a good number of them.

I'll agree that the OS can be simple or advanced. I do not agree that my statement was "False". I simply said, and I purposely said, that the OS "should" be advanced. This cannot be proven, and exists as an opinion based on the wording I've used.

You're contradicting yourself here. "Should" denotes requirement, not opinion, unless you negate it using opinion statements such as "In my opinion" (which you did not in that first statement).

But still, my advice stands quite well. If the OP wants to not print on the top and bottom lines, then that is entirely up to the way that they code the program. The only reason the program would print in the top or bottom lines is because the OP scripted it to work that way.

It's like asking the checkout assistant to make sure you don't buy any cheese.
The only person who can make sure of that is yourself… Just, don't buy cheese.

I like the replacement of the function, but I know that there are more efficient ways to make sure you don't write the wrong code.

What you don't seem to be understanding here is that typically an OS will replace the shell. The shell runs other programs which are not programmed by us, and because of that, it would require a rewrite of each one in order to avoid using the first line in every program. And then you have to worry about other programs that a user creates and which you have no control over.

Hence, function replacement.

Maybe you should draw out how you want your OS to look, and label all the important locations with their coordinates.
I suggest you stay away from the print() function for this reason: it changes the y position. This can and will eventually result in the bottom line being written over.
I suggest you stay away from the clear() function for this reason: it colours the entire screen with the selected background colour. This can result in only the string you place over the line to be the correct colour.
I suggest you stay away from the scroll() function for this reason: it scrolls the entire screen. This can result in the bottom and top lines becoming distorted, as the function does not disclude them from the scroll.

No… See above for why you are not correct. These functions, when used with function replacement, will never cause any issues.

The easiest way of controlling which areas of the screen can be drawn to is by creating a terminal redirect that limits the ability for code to draw to the screen by making the screen seem smaller than it really is. The redirect method is best because it is the easiest to use once written, and it allows any existing code to be limited to the area of the screen that you desire it to use.

In my opinion,
making the OS as you've suggested it be done, would mean changing the ACTUAL files, not adding your own versions. My point with not using the functions was because of what they do, not taking into account what you might decide to change them into doing.

In my opinion,
I don't need to say in my opinion before I state an opinion. If I say "green is good" everybody knows that it's an opinion. The same goes for how I'm accustomed to using the word 'should'.
And another thing, why are you arguing about this so much!? Gosh, I'm trying to help, you're trying to help, and apparently we're trying to say the other is wrong, without even knowing who the OP is understanding.

reububble, on 19 August 2013 - 03:19 AM said:

making the OS as you've suggested it be done, would mean changing the ACTUAL files, not adding your own versions.

False. It is quite easy to override functions without editing original files. For example run the following code in a program.

local oldPrint = _G.print

function _G.print( msg )
  oldPrint("I don't care what you said, I'm going to say this")
end

print("Say this please?")

You will note that the function has now been overridden for ALL programs that run after it.

Also as Lyqyd stated you can even redirect the terminal, which is the best/easiest option for overriding terminal related functions.
This is a common method I use for overriding term function:

--# any overrides you wish to make, put them in here, making sure to use term.native.x when referring to the original function
local termObj = {
  getSize = function()
	local w,h = term.native.getSize()
	return w, h - 2
  end
}

--# make sure that any functions we haven't overridden get included from the native so that we can redirect the terminal
termObj.__index = term.native
setmetatable(termObj, termObj)

--# we can now redirect with
term.redirect(termObj)

--# and to restore the terminal to normal we can use
term.restore()

reububble, on 19 August 2013 - 03:19 AM said:

And another thing, why are you arguing about this so much!? Gosh, I'm trying to help, you're trying to help, and apparently we're trying to say the other is wrong, without even knowing who the OP is understanding.

Well it's currently 3 to 1. Do you not think that if Lyqyd, Bubba, and I are all stating that your method is not the best and that there is much better ways to do things, and not to tell people not to use functions, that your methodology is flawed and in need of revising?

Ease up, gents. reububble's advice would be sound if this were a case of wanting to create a single program that did not draw to the top or bottom lines of the screen. It isn't the best fit for this situation (an OS which would likely expect to need to interact with other programs), but it isn't entirely invalid. There's a fair bit more hostility here than the situation warrants.

theoriginalbit, he's right that your usual comment on OSs (which we will not get into here) does involve editing at least one file, though admittedly not the term API file.

Now, for the purposes OP stated in the question, I think that creating a terminal redirect is going to be more practical and easier to use than writing to the restricted area of the screen only. It is simpler to create that than to create a new print function (as I'm sure word wrapping is still a desirable feature) that only writes to certain portions of the screen, and it's certainly easier to handle things like automatic scrolling (though that will require a buffered redirect to work properly). If the use case was just a single program, the careful screen control approach might be viable.

Remember, it's always better to show others what we consider best practice and engage in discussion whenever feasible. It's not often that hostility would be appropriate, and if it is, it's usually best to report any posts that might require it, so that the moderatorial and administrative team can handle it as necessary.

I needed this exact thing, but I didn't see an API in the forum. So I wrote one:

http://www.computercraft.info/forums2/index.php?/topic/14877-panel-terminal-redirection-to-parts-of-screen/

Looking for constructive critisism…

I did this:

getSize = term.getSize
pullEvent = os.pullEvent

term.getSize = function(...)
 w, h = getSize(...)
 return w, h-1
end

local w,h = term.getSize()

os.pullEvent = function(...)
 o = {pullEvent(...)}
 x,y = term.getCursorPos()
 term.setCursorPos(1,h+1)
 write("HELLO!")
 term.setCursorPos(x,y)
 return unpack(o)
end