Maybe this is an unusual request, but would it be possible to define the width of the graphic display, and extend thus the width of the print-window section? I currently do have the problem that during debug of code the print-window is simply too narrow, so that print commands produce results in multiple lines. E.g. You want to test the content of a 10x10 matrix … Thus it would be simply perfect, if we could get a possibility to adjust that. In addition this feature would help for some pure algebraic problems to be solved, where you only produce tables or matrices or …
The output window is too narrow. I’m not sure what the best solution is at the moment, but I’ll give it some thought.
I wonder if there wouldn’t be a use for “text mode”. I mean - we have a graphic window with text along the side, and fullscreen graphics - I’ll bet there are people who could use fullscreen text as well, for just that sort of thing. (print() would need to be sped up, w00f).
or - maybe just setWidth(), and just make the console fill the rest of the screen. Making it too narrow or wide would be a “well, if you don’t like it, don’t do that” kind of thing.
It strikes me that a lot of the requests are for text output - and loading a third-party font library is more heavyweight than people want/need.
@Bortels: this is a very good idea: I do have currently the problem that I am doing number crunshing with Codea, where I am also printing data on the output window (e.g. some reasonable error messages if I am doing something wrong in my functions or matrix output, which looks horrible on current output window, since it is too narrow).
Adjusting the width of the output window is exactly what would solve the problem in my opinion: setDisplayWidth(0, Landscape) equals to FULLSCREEN_NO_BUTTONS, setWidth(WIDTH, Landscape) equals to NOSCREEN_FULL_OUTPUT_WINDOW. If this is available in both Portrait and Landscape, perfect would be the best word for that (setWidth(0, Portrait …). And as you say: in case you don’t like it, well, use the default settings and don’t touch this feature …
I have a solution in mind that will fix this problem, but it probably won’t be implemented by 1.3. However with 1.3 you will be able to use the text() rendering to get nice and large on-screen output.
Could we look at vague comparision of screen and text()?
Native text() preview
http://twolivesleft.com/Codea/Talk/discussion/420/native-text-rendering-preview