On Sun, 17 Jun 2012 21:43:05 -0300 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
> 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)? there are some gfx mode thgins in escapes. i assume thats used to draw lines using special line characters as it remaps regular chars to these sequences when in that mode - i think. i've never tried the menuconfig/ncurses lines thing in terminiology, so don't know. > For keys: I'll look later, thanks. But I just realized even the > elm_entry does not handle it :-/ bigger problems :) > For example I can type ç by using AltGr + "," but not ' + c as > expected by us-intl or cedilla input methods. bigger problems indeed :). as i said -i know how compose key combos work. i need to make a table and handle them. no idea about altgr stuff. never used it, don't know it. would have to research. > >> 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 ncurses line thing is on a list of stuff to look at - but it wasn't a necessity for my daily stuff so i didnt do it yet. :) > > 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 :-) i want it to be unique and noticable. the highlight can be toned down a bit, but i want something visible that makes you know its terminology not just xterm etc. but just fyi - either your eyesight is horrible, lighting conditions insane or you have some of the crappiest screens around if u can't read it with that highlight :) are you using that macbook.. speaking of crappy screens? :):) (oooh just had to jibe that one in!) :) > What I plan to work on whenever time (?) allows: > - detect protocol://xxx and call xdg-open with it. Where to add it? in termio.c - you'll have to scan the cells fetched by termpty_cellrow_get() (fetched 1 row at a time for the visible grid of cells and put into textgrid). while scanning you'll have to then detect these. you'll have to handle your own line-wrap logic here - ie if url finishes at last char or not or it continue on the next line. right now there are special bit markers set to know if it was auto-wrapped or not that the selection-to-text handling tries to detect. the selection-to-text stuff is not that reliable or solid so i need to work on that as its only partly usable. look at that code for ideas - that is what converts back to utf8 strings too. :) > - see if we need reset sigaction for SIGTERM et al. Did you think > about that? ummm do we need to? ecore by default auto handles quitting main loop on that so nothing to do? or was that sigint? > - 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. bnecause your elementary is configured for touch (illume) as opposed to desktop with smaller finger sizes. the term is rather small by default - if its bigger it works fine, which is what i'd expect of a touch device too. > - replace options from swallow to inwin... play better with elementary i actually had plans to split the list of options (wallpaper, theme, behavior etc.) and content into 2 swallows as my plan is to have things like theme/wallpaper be like e17's wallpaper2 and separated from the toolbar. for current ones it'd need some other panel to slide out etc. > - allow theme group fallback... so we don't need to provide whole > theme just to change one yeah. that's sensible. > - shortcut to enlarge/shrink font size (see gnome-terminal, useful > for presentations and friends coming by) yup. makes sense. eterm and xterm have this too in code somewhere i rememebr seeing. > - provide xterm colors in the theme yes - though leave 256 color palette alone. just normal ansi colors, default colors and reverse colors. 256 col needs to be the set expected as its a coarse "truecolor" mode. also config dialog for custom color pallet for the user. > - configure xterm colors ytup. > - multiple windows and/or tabs right now this is right on the end of a list of features as frankly i'm not happy with the 1 process goes down and ALL my terminals go thing that gnome-terminal does. as for tabs - don't use TABS... be imaginative. i was thinking a thumbnail-like chooser - wp2 style with a quick select bar with smaller thumb on mouseover the top of the term or something. > - configure background color and transparency (ie: dark-gray at 60%) right now it's left to theme, but actually just replacing the media obj with a rect with the trans u want would do the job - if theme just stayed clear on transparency mode enabling. > 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 ok. > - 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. ok > - made the options dialog larger, so I can actually have something you now waste space in the font selector by not USING the blank, unused icon swallow. thats why i split it into 2. what is the entry box for other than displaying some text that doesnt change? > - 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 :-/ oooh... do we REALLY want that there all the time? its a waste of space and people will barely ever change it. putting that in another "tab" might be more useful and space efficient. > - 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 this i'm not so sure of. elementary doesnt use it. e doesnt use it. it's out of place for e land. > 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...) that'll be the incomplete esc handling. also yes - it doesnt handle those 93/97/104 color ranges. as for esc 1034 - i cant find it documented anywhere - even eterm doesnt handle it. i don't know what it does. i hunted for that before. the 93/97 etc. colors are just coplor repeats in "bright mode" i think (90-97 and 100-107). 99 and 109 too. easy to handle without any fuss - but the 1034 one.. beats me what to do with it. > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > -- ------------- 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-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
