On Sun, Jun 17, 2012 at 10:27 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > 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.
Thanks to KainX and his expertise I was able to get it working. There is now a vt100 to unicode table I got from urxvt. The key was to understand it may change the charset to DEC's ACS. >> For keys: I'll look later, thanks. But I just realized even the >> elm_entry does not handle it :-/ > > bigger problems :) Fixed. Ecore_IMF was fine, but XIM module was trying to set styles that were not supported in my machine. Now it will fallback if unsupported. Also added IMF to terminology based on edje_entry.c, many thanks to Sachiel for pointing out where to look for example. I just did the basics, no preedit, prediction or surrounding stuff. NO idea how it will look like with a vkbd. >> 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. done :-) >> >> 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. :) as said, done. >> > 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!) :) my screen is good, so are my eyes... but it's annoying as said by multiple people at #edevelop. How about make it your theme and the default be usable? >> 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. :) ok, will look at it later. >> - 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? in the child, where you exec. I'm asking because GLIBC's system does 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. > > 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. no, it's desktop. Not illume. >> - 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. well, if you have tabs you need fast switch AND fast lookup where you are. So far nothing beats visual tabs for that. The switch often happens with shortcut... so invisible. But the lookup where you are you can easily see with the tab position as in an actual physical file/archive. You also need hints of visual bells or alarms on other tabs -- tabs are usual and unbeatable as people are used to it, even with screen. IOW: let's use the fancyness for other elements, like the wallpaper and font choosers? >> - 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. color classes? One can set the color class of an object, instead of the whole color class if needed. >> 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. THEN WHY U NO USE IT? :-) Just noticed some spurious printf() and perror() in the code :-/ >> - 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? That's a problem with Elementary. I've noticed that, we must make the row theme not not use the space if there is no icon, or at least provide a theme with end-only icon. >> - 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. The most annoying bit that leads one to change terminal fonts is due some specific glyphs -- that we can't predict. Some people dislike lowercase-L as it looks like 1. Some uppercase-O x zero. Some use it to detect subtle differences with "a"... IOW: letting the user choose a font without trying is just strange. Yes, one can change and see the feedback on the background termio, but that's annoying to have to do it :-/ >> - 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. We should change other EFL utils. The thing is some systems may choose to prune ~/.cache and persist ~/.config from time to time. >> 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. I don't really know where these came from. They always show when I start it, my PS1 is: \[\033[01;32m\]\u@\h\[\033[01;34m\] \w \$\[\033[00m\] (Gentoo's default). Debug shows the following for username "gustavo": DBG<29797>:terminology termpty.c:1080 _handle_esc() ESC: ']' DBG<29797>:terminology termpty.c:1080 _handle_esc() ESC: '[' DBG<29797>:terminology termpty.c:389 _handle_esc_csi() CSI: 'h' args '?1034' ERR<29797>:terminology termpty.c:909 _handle_esc_csi() unhandled screen mode arg 1034 ERR<29797>:terminology termpty.c:943 _handle_esc_csi() unhandled 'h' : '?1034' DBG<29797>:terminology termpty.c:1080 _handle_esc() ESC: '[' DBG<29797>:terminology termpty.c:389 _handle_esc_csi() CSI: 'm' args '01;32' DBG<29797>:terminology termpty.c:1318 _handle_seq() txt: [ DBG<29797>:terminology termpty.c:1321 _handle_seq() g DBG<29797>:terminology termpty.c:1321 _handle_seq() u DBG<29797>:terminology termpty.c:1321 _handle_seq() s DBG<29797>:terminology termpty.c:1321 _handle_seq() t DBG<29797>:terminology termpty.c:1321 _handle_seq() a DBG<29797>:terminology termpty.c:1321 _handle_seq() v DBG<29797>:terminology termpty.c:1321 _handle_seq() o DBG<29797>:terminology termpty.c:1321 _handle_seq() @ ... -- 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
