On Sun, Jun 17, 2012 at 8:37 PM, Carsten Haitzler <ras...@rasterman.com> wrote:
> 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
It's there to draw lines? Do ncurses work for you (kernel's make menuconfig)?
For keys: I'll look later, thanks. But I just realized even the
elm_entry does not handle it :-/
For example I can type ç by using AltGr + "," but not ' + c as
expected by us-intl or cedilla input methods.
>> 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.
Ok, so far it seems to do okay for the tests I did. But the ncurses
and input problems are bit of pain for me to change. I'll see if I can
fix those and use it daily.
> 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) :)
ok, seems fair. I did some patches today, take a look. If possible
let us toggle the "mild" theme by default, the default highlight is
annoying and makes it unreadable :-)
What I plan to work on whenever time (?) allows:
- detect protocol://xxx and call xdg-open with it. Where to add it?
- see if we need reset sigaction for SIGTERM et al. Did you think
about that?
- change option GUI from side-by-side toolbar (which is broken for
me) to a naviframe + lists, it's extensible and will work nice for
more options.
- replace options from swallow to inwin... play better with elementary
- allow theme group fallback... so we don't need to provide whole
theme just to change one
- shortcut to enlarge/shrink font size (see gnome-terminal, useful
for presentations and friends coming by)
- provide xterm colors in the theme
- configure xterm colors
- multiple windows and/or tabs
- configure background color and transparency (ie: dark-gray at 60%)
What I did already is:
- added eina log. If you want your termpy.c speed back of
disabling DBG() just use configure --with-maximum-log-level=3
- removed config from global, we can do something to have
per-instance config... just need to define a policy on what to do and
save.
- made the options dialog larger, so I can actually have something
- made it possible to specify the font preview string, with some
PITA chars by default (Ox0, 1xl).. It works, but height is not
resizing properly :-/
- changed command parsing... uses $SHELL and can do $SHELL -c
$COMMAND if it seems to be a shell expression.
- use ecore_getopt!
- use XDG_CONFIG_HOME instead of ~/.terminology
Last but not least, I get the following error when I run:
termpty.c:802 _handle_esc_csi() unhandled screen mode arg 1034
termpty.c:836 _handle_esc_csi() unhandled 'h' : '?1034'
Also running irssi shows couple of color cmd error (93, 97, 104...)
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
------------------------------------------------------------------------------
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
