[e-users] Terminology - time to talk.

[Carsten H. (T. R. <ra...@ra...>]

So I got a little bit of stuff done while on holiday the week before last...
and i wrote a terminal emulator. it's from scratch, so not a port of an
existing one. This of course means the terminal emulation bit is definitely not
totally all there. It needs work, but it's usable enough to the point where I
have switched to the new terminal -> terminology.

For the impatient, it's in SVN -> trunk/terminology

http://trac.enlightenment.org/e/browser/trunk/terminology
svn checkout http://svn.enlightenment.org/svn/e/trunk/terminology

Why write a new terminal core? it was less work than porting an existing one.

Why do a new terminal - don't you have Eterm? eterm is old. old old old. it's
an rxvt core with some imlib2 stuff. it uses no modern EFL at all. it's
unrelated to EFL and making it related would be a very large task. We need..
want an EFL terminal - just for our own pride and sanity alone, so I finally
stepped up and did it, or the larger chunk of it.

How does this benefit E? Well it means we now have a terminal that can fit into
our desktop and use the same widgets, toolkits and look. It's also rather lean
and simple and very cleanly split, and can serve as an example of how to make
EFL apps.

How does this benefit EFL? Terminology has proven a pretty good little test app
so far - I've found a fair few bugs in EFL that have been lurking and no one
found yet. I still have a short list of them to clean up. Also terminology
drove vincent to finally finish his textgrid evas object and put it into SVN -
been waiting for this for a while and this is good for the next release. a
textgrid gives us the basis for not just a terminal emulator but IRC clients,
code editors, and in fact anything that lives with gridded text arrays. You
could do it with a grid of text objects - but that's horribly inefficient. You
could do it with textblock, but that's inefficient in a bunch of other ways. So
this has driven textgrid to mature and go in, be optimized, debugged and now
work - well mostly. a few features not finished and an update offness I am
unsure as to why it happens right now, so you sometimes get update "turds" left
around.

What is so great about this and why should I use it? Well it uses EFL. a Lot.
it's totally centric. just click right mouse to see how much. It has full GUI
config built in (as well as some cmd-line switches). It's missing theme and
wallpaper browser, but font selection, size changing, other behavior options
etc. all work and are pretty slick and well done, if I don't say so myself :).
It saves its config automatically too. On the cmd-line (run terminology -h for
help), you can select theme (another edje file) and you can select background.
Right now terminilogy supports the following backgrounds: normal pixel images
(jpeg, png, bmp, tga, ppm, xpm, tiff etc. etc. - whatever evas does). It
supports scalable images (svg, ps, pdf) as wallpapers. it will even properly
scale them to the exact terminal size. yes - you read right. svg, pdf and svg
backgrounds. It supports animated gifs - yes i know. They play (on loop) like
they would in a browser. Feel free to go nuts here. It also supports... VIDEO
as a background wallpapers. That's right. video. movies. audio included. You
can play entire feature-length movies, or just short video snippets, or
whatever. (audio is mutable on cmd-line or in gui, and video decode engine is
selectable too - gstreamer, xine, or generic vlc supported if emotion is
compiled with them all supported, the default is auto-select). Why do all of
this? well completeness..., and because I can. It's so trivially easy to make
such multimedia apps with layered ui's that get out of your way when you want
to focus on work, but give you all the bling. Of and did I mention it also
supports true translucency too and thanks to EFL, edje and friends themes can
not just set a scrollbar look, or a background, but also overlays and nice
shading too. Cursor is just a theme object, so its blinking is theme
controlled. Oh and did i mention that I bothered to support xterm 256 color
mode already, so 256color terminal apps should work. Oh and it ships with a
selection of bitmap fonts so you don;'t need to install them separately, and
offers them in a special bitmap section in the selector. :)

This app is far from being COMPLETE. of course you'll find rough edges and
things not fully baked yet - especially in the terminal emulation department.
That will mature (hopefully rapidly) over time, ESPECIALLY if people pitch in
and scratch their own itches and problems. The terminal emulating code is all
in termpty.c - it's not that long or hard to understand. it even has comments.

So what will the future hold? who knows, but definitely bringing it up to snuff
as a first-class terminal emulator. I INTEND it to have fancy frills - not be
frill-free. even despite all the frills it beats the memory footprint of
gnome-terminal by a good margin. It's decently fast now wit textgrid. Thanks to
Evas you can even have it use OpenGL to render... :) Give it some time and
it'll come of age and I do hope become an indispensable utility for all the
nerds out there. There's a TODO file with a list of things... to .. do... it's
all optional and malleable. For me I just want a tool that makes me more
productive day to day, looks gorgeous, and gives some self-respect to us here
to have a terminal finally that uses the libs we go around making. :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...