|
Post by Pjot on Nov 4, 2018 15:31:40 GMT 1
All, Lately I have been playing around with XTerm. This program is in fact a very cool terminal emulator with a plethora of options, and ported to almost every platform. For fun, I tried to mold XTerm as a drawing canvas, to see how far I could get And it actually worked pretty well. Of course, there is no double buffering or hardware rendering, but apart from that, it is possible to create a drawing on XTerm based on ASCII. XTerm can even query mouse events! The resulting canvas wrapper can be found here. A demo program with some screenshots below. Best regards Peter REM INCLUDE canvas INCLUDE canvas-xterm
OPTION VARTYPE double
WINDOW("Turtle Graphics Tree", 600, 700)
INK(0,0,0,255) CLS
RESETANGLE
PENXY(300, 680)
PEN(1, TRUE)
CALL tree(400)
INK(0, 255,0, 255) TEXT("A Beautiful Turtle Tree in ASCII", 20, 20)
WAITKEY
SUB tree(size)
IF size < 5 THEN DRAW(size) DRAW(-size) EXIT SUB ENDIF
INK(0,255,0,255) DRAW(size/3)
TURN(-30) tree(size*2/3) TURN(30)
INK(0,255,0,255) DRAW(size/6)
TURN(25) tree(size/2) TURN(-25)
INK(0,255,0,255) DRAW(size/3)
TURN(25) tree(size/2) TURN(-25)
INK(139,69,19,255) DRAW(size/6)
DRAW(-size) END SUB
Attachments:
|
|
|
Post by vovchik on Nov 4, 2018 16:37:25 GMT 1
Dear Peter,
That is very impressive for Xterm. On Mint 18 (32-bit), I am getting the entire screen, except for the task bar, occupied by the window and the text is about 700 pixels high, which means I see no drawing. And it hangs. Also the same on PI. On PI I got this at runtime:
Warning: Cannot convert string "true " to type Boolean Warning: Cannot convert string "false " to type Boolean Warning: Cannot convert string "true " to type Boolean Warning: Color name "green " is not defined
I think the canvas part is not getting the screen size back properly and making some kind of erroneous assumption.
But it will work, I see, with a tiny bit of tweaking. Thanks.
With kind regards, vovchik
|
|
|
Post by Pjot on Nov 4, 2018 17:05:00 GMT 1
Hi vovchik,
Which version of Mint18 are you using exactly (18.0, 18.1, 18.2, 18.3) ?
It works on my Linux Mint 18.3 64bit, and it also works on a vanilla install of Mint 19.0 32bit.
BR Peter
|
|
|
Post by vovchik on Nov 4, 2018 17:30:34 GMT 1
Dear Peter,
My Mint on an old "tower" is:
Linux vovchik-tower 4.15.0-33-generic #36~16.04.1-Ubuntu SMP Wed Aug 15 17:19:05 UTC 2018 i686 athlon i686 GNU/Linux Linux Mint 18.3 Sylvia
And the PI has raspbian 4.14 (Debian).
And an old Atom Lenovo has:
Linux vovchik01 3.19.0-32-generic #37~14.04.1-Ubuntu SMP Thu Oct 22 09:37:25 UTC 2015 i686 i686 i686 GNU/Linux Linux Mint 17.3 Rosa \n \l
All three machines behave the same way with the xterm canvas.
With kind regards, vovchik
|
|
|
Post by bigbass on Nov 4, 2018 20:19:26 GMT 1
Hello Peter and vovchik Thanks Peter this is very impressive for XTerm! And on the raspberry pi3 BTW on another note the raspberry pi has major problems with GL this isnt your fault at all and is very annoying until we can sort out the problems with some kind of stable fix P.S I am happy to say it is working for me and will provide any feed back vovchik to help you get it going
pi@raspberrypi:~/Documents $ bacon p Converting 'p.bac'... done, 1054 lines were processed in 0.733 seconds. Compiling 'p.bac'... cc -D_XOPEN_SOURCE=600 -D_POSIX_SOURCE -D_DEFAULT_SOURCE -D_ATFILE_SOURCE -c p.bac.c cc -o p p.bac.o -L. -lbacon -lm Done, program 'p' ready. pi@raspberrypi:~/Documents $ ./p
|
|
|
Post by Pjot on Nov 4, 2018 21:14:27 GMT 1
Hi vovchik, It should work in Linux Mint 32bit as well. I made a scratch install on a VM using Linux Mint 18.3 32bit and all worked out of the box (see screenshot). @ bigbass: thanks! BR Peter Attachments:
|
|
|
Post by Pjot on Nov 4, 2018 21:31:52 GMT 1
And for Linux Mint 17.3 in 32bit it all works for me as well (see screenshot). I never see those warnings about "cannot convert string" either... Attachments:
|
|
|
Post by vovchik on Nov 4, 2018 22:05:43 GMT 1
Dear Joe and Peter, If both of you have tested and it works, the problem is my installed base with something unusual there that is causing problems with Mint 17, Mint 18 and PI. I wonder what it is (something in .Xresources, .bashrc or .profile?). I am scratching my head. With thanks and kind regards, vovchik
|
|
|
Post by Pjot on Nov 4, 2018 22:16:48 GMT 1
Hi vovchik, What is the resolution of your screen? It should be approx 1024x768. Also, maybe you need to remove .Xresources altogether and test it from there? Below is an image of the famous Seascape program, rendered using ASCII in XTerm - yikes! Peter Attachments:
|
|
|
Post by vovchik on Nov 4, 2018 23:42:49 GMT 1
Dear Peter,
My screen sizes are all different: 1200x678 on the PI, 1600x1000 on an old Athlon tower with Mint 18.3 and 1680x1050 on a Lenovo IdeaCentre with Mint 17.3. In all cases, the initial window occupies the entire screen, minus the task bar. Weird. I will try without .Xresources and see what happens...
With kind regards, vovchik
|
|
|
Post by bigbass on Nov 4, 2018 23:42:58 GMT 1
Hello vovchik
looks like xterm has undefined values
see if you get color
xterm -fg green
try doing this if not
export TERM=xterm-color
Joe
|
|
|
Post by vovchik on Nov 4, 2018 23:51:15 GMT 1
Dear Joe, Thanks. I get the color change, but the screen flashes a few times (goes black) when I run xterm in Mint and I get the warnins on PI. Something wrong with xome xterm settings somewhere, I think. I will keep investigating. If you have an idea, please post. With kind regards, vovchik
|
|
|
Post by bigbass on Nov 5, 2018 0:14:28 GMT 1
hello vovchik
we can force some values to test the font size and force the fullscreen off
xterm -fa 'Monospace' -fs 14 -fg green +fullscreen then compile from the new terminal that opens with those default values set
let me know how it goes
Joe
|
|
|
Post by bigbass on Nov 5, 2018 1:34:26 GMT 1
Hello vovchik I Found a fix for the screen size only a small edit of the ysize-140
IF xsize = 0 OR ysize = 0 THEN SYSTEM "xterm -fn -*-*-bold-*-*-*-2-*-*-*-*-*-*-* +sb -bg white -fg black -fullscreen -S" & TAIL$(client$, 1, "/") & "/" & STR$(master) & " &" ELSE SYSTEM "xterm -title " & CHR$(34) & title$ & CHR$(34) & " -fn -*-*-bold-*-*-*-2-*-*-*-*-*-*-* +sb -bg white -fg black -geometry " & STR$(xsize) & "x" & STR$(ysize-140) & " -S" & TAIL$(client$, 1, "/") & "/" & STR$(master) & " &" ENDIF
Here I reduced the default height -140 ysize-140now it fits nicely Joe PS I got the seascape running only replace y1 for yone because y1 is defined by C already 'INCLUDE canvas.bac INCLUDE canvas-xterm.bac very cool to see that this is possible in xterm Joe
|
|
|
Post by Pjot on Nov 5, 2018 18:04:17 GMT 1
Hi vovchik, One of the secrets of the XTerm canvas is that it uses an X-font which is defined as 2point bold "-*-*-bold-*-*-*-2-*-*-*-*-*-*-*". Such font is of course completely ridiculous (who can read a 2pt font?), however, it causes a terminal with acceptable x:y proportions and small pixels, which creates a nice rendering surface. Then, the XTerm builtin Line Drawing Characters contain a large dot (this is a 2nd secret) which appears as a genuine pixel. So I am wondering, it could be that your experiments with TTF fonts in the past are in now the way of XTerm being displayed correctly? To update the Xorg font cache, you could possibly try to run this command: Alternatively, you can also run the following X utility to verify your X fonts: This will present a small window, goto the menu 'pxlsz' and see if you can select pixel size 2 (the font uses by the XTerm canvas). If this is not possible then you may need to reinstall the Xorg fonts package.... HTH Peter
|
|