On Sun, 17 Jun 2012 11:57:15 -0300 Gustavo Sverzut Barbieri
<barbi...@profusion.mobi> said:

> On Sun, Jun 17, 2012 at 7:21 AM, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> > 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. :)
> 
> It went a good amount since the first days, but basic terminal stuff
> as the ncurses boxes break, and I still can't get áé to be composed by
> it. It's basically unusable to do "make menuconfig" for kernel and use
> with an UTF-8 system that have some internationalized chars with an
> us-international keyboard.  (AltGr + key works).

it does full utf8 (actually utf8 only). it works correctly too - if it sees
utf8 charts in the pty stream, displays right too, BUT... there is ZERO work in
input methods, composing, deadkeys, blah blah blah.

termpty is the escape handling. for things that change into gfx mode to draw
lines/border it's there. for key input it's in keyin.c

> These I have no idea where to look, if they are related to termpty or
> what. So I'd wait you ;-)

you'll be waiting a while as i have never used deadkeys. i do know how to use
the compose key and combos, but even xterm doesn't do those for me, so i'm not
amazingly worried, but that's about all i could manage off the top of my head
with a little research (i'll have to build in a table of all the compose
combos). it doesn't handle every escape sequence in existence and even the ones
it does handle may be buggy - ie i got it wrong. as such there is no document
that tells you the terminal state machine and exactly what every mode means,
what modes you should start in, what every esc seq or char does EXACTLY etc.
it's all some level of guess-work based on reading pages on escape codes and
other terminal emulator srcs.

the way i wrote it was read these pages, run the apps i used day-to-day and
then some (i even bothered making vim start up right and do the basics right
anyway as well as pico/nano, and emacs mostly works except for 1 small turd
buglet i couldn't find), and handle all the escapes i saw. that sucked up about
1.5 weeks of work (not 8h/day fulltime - kind of 1-2h/day). it just needs more
of that, and i thought i'd flesh out the other bits for a while and come back
to that later as the termpty handling gets a bit dry and boring after a while
since it's "poking in the dark" quite often. :)

> But there are some things I could try to help, let's see.

that's what i'm hoping. everyone will just pitch in a bit.

for terminal emulation: termpty.c. it's all there with backscroll buffer.
for key input handling: keyin.c. it's all there.
for terminal output (from the in-memory grid of cells to the evas grid of
cells) and mouse input, selections, scroll handling as well as higher level key
handling (shift+pgup/dn for scroll as these get caught and not sent to the pty).
for a hard-coded list of colors: col.c
for initial setup and glue of things together: main.c

the rest you can easily figure out. options* files are for the options popup.
media* is for handling the bg (images, scalable images, edje files and video
files). utf8.c is just a quick utility for taking pty glyph/codepoitns and
turning them back into utf8 char sequences. i inlined it for speed as i was
doing 1 char at a time, not whole runs, and i didnt want to strdup the
strings. (thus didnt use eina) :)

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


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to