Enlightenment Terminal Allows Video Playback, PDF Viewing 114
An anonymous reader writes "The E17 Enlightenment project has released a new version of its Terminology terminal emulator. With Terminology 0.3 comes several fancy features, including the ability to preview video files, images, and PDF files from within the terminal. There's new escape sequences, inline video playback, and other features to this terminal emulator that's only built on EFL and libc."
Re: (Score:3, Insightful)
Re:Terminals with graphical capabilities... (Score:4, Informative)
In the financial world, you also have the Bloomberg terminal. It's very heavily command line driven, although it does have some pointy-clicky functionality for noobs. You get a mix of text, graphics, audio and video from what I'd call a self-contained semantic web.
Re: (Score:2)
Yep there goes the neighborhood. (Score:1)
Can it do... (Score:4, Interesting)
Can it do all the above inside lynx [wikipedia.org]? 'Cause if not, I'm going to wait a bit for the emacs module.
(grin)
(tell me again: why would someone want to do any of the above in a terminal?)
Re:Can it do... (Score:5, Interesting)
'Because I can' ... yup.
Seriously though it's zero extra code to handle video in a bg when it's already supported in Popups. It's the same object. It's supported in popups because it's helps people who use terminals for irc, email and more and when they have a link to a video stream they get easy one click access. Users of irssi have been singing terminology's praises for this. There are tonnes of legitimate normal uses of such features. You might not see it now or your usage of terminals is incredibly narrow, but many who live in them all day find these features a godsend.
Re: (Score:3)
it's helps people who use terminals for irc, email and more and when they have a link to a video stream they get easy one click access. Users of irssi have been singing terminology's praises for this
You don't need viewers integrated into the terminal for that. Just an URL aware terminal(e.g. urxvt) and something like xdg-open [archlinux.org].
Solutions already exist that follow the UNIX philosophy. Do one thing, and do it well. Don't stick a PDF viewer into the terminal. Make a kickass terminal, and a kickass PDF viewer
Re: (Score:2)
what you don't get is.. the pdf comes for free if you do images/svg's etc... that's the point of libraries. and there is a vast difference between writing a full pdf viewer and something that just happens to display them because its whole toolkit stack gives it that for free.
as for your quoting of unix philosophy... it's like the church saying the world is flat and people being too scared to get in a boat and sail west from europe lest they fall off the edge of the world! why does everything have to religio
Re:Can it do... (Score:5, Interesting)
(tell me again: why would someone want to do any of the above in a terminal?)
After having watched the full video of its capabilities I am pretty amazed and certainly some of it will be useful.
I particularly liked things like the ability to use ls to a get a list of files but with small thumbnails next each. You were then able to select the thumbail and see a bigger preview for images and movies. I also like the ability to do things like hover over a file in a "ls" output then just click and drag it but getting a full path to the file.
Re: (Score:2)
(tell me again: why would someone want to do any of the above in a terminal?)
Because if you're working at a terminal, leaving the command-line is always a pain in the ass?
Re: (Score:2, Informative)
> Because if you're working at a terminal, leaving the command-line is always a pain in the ass?
OSX has a cool feature that makes it a bit less of a pain. It has a command-line "open" tool that has the same effect as double-clicking a file in the file browser. In particular, I often use "open ." to open the current folder in the file browser.
A GUI-aware terminal is of course way cooler.
Re: (Score:3)
Terminology also does this if it doesn't know the media file type or it's a directory and it asks a generic open tool to deal with it. ( Configurable). Thus it opens with your favorite tool or even a file manager view.
Re: (Score:2)
Re: (Score:3)
gnome-open or xdg-open ftw
Re: (Score:1)
All the power-users have ways to "Open Command Prompt here" from the GUI and the dual: open the GUI File/Folder Explorer from the shell:
To go from Command Line --> GUI with Bash
Re: (Score:3)
(tell me again: why would someone want to do any of the above in a terminal?)
Because if you're working at a terminal, leaving the command-line is always a pain in the ass?
Ass... mmchhh... that's not what I fancy.
But I'll grant you the point: for some terminal (ends of the body) to be worked at, this could be tremendously effective. Exempli gratia (adjust to your taste):
cd ~/MyCollection
find -type f -name "*.ogg" -exec grep --video-frame-content "wild-riding|yeehaaa" {} \; | play
Re: (Score:1)
Now that he has seen that it can be done without creating a community-wide fuss or massive regression like KDE or GNOME do each time, he has nothing good to say, so he regresses to poking at the whole purpose when he would probably be the guy complaining about how this package sucks this way, that one sucks that way and so on.
Some people just can't appreciate a piece of software done well.
Cranks're gonna cry, bitches're gonna bitch.
Ignore them (even if they have 3-digit Slashdot ID's because smaller ID's do
Re: (Score:1)
Can you honestly say you've never wanted to split your terminal into four separate panels, having garish (and even moving!) picture backgrounds which make your commands and output completely unreadable? Or that you've never _ever_ wanted to watch a movie which partially obscures another movie playing in the background, with text on top?
You, sir, need to raise your expectations!
Re: (Score:2)
it's a demo for crying out loud. it's meant to show off as much as possible in a short space of time, NOT show you how you MUST use it every day. a looping video of a dark night sky with clouds drifting by etc. would be perfect. doesn't obscure your text BUT provides a nice "pattern". i don't happen to have such video content with me right now. imagine:
http://www.flickr.com/photos/christopics/118890688/ [flickr.com]
but without the people, (and the pool right at the bottom, not the middle), with the video edited to loop
Re: (Score:2)
I use dolphin's synced terminal and file view quite a bit. Some tasks are easier with a mouse (picking out a subset of files by previewing them) and some tasks are easier with a terminal (running imagemagick across a slew of files). Having a terminal integrated into a GUI file manager makes sense. This is simply moving toward the same kind of thing from the other direction, adding these things things in a terminal-focused interface.
Re: (Score:3, Funny)
For every window manager, there's a terminal wishing it were a window manager.
Why have a window manager at all when one may have emacs?
Re: (Score:2)
Why have a window manager at all when one may have emacs?
Because viper is not quite good enough yet.
Re: (Score:2)
And every window manager wishing it was a terminal. That damn mouse is one of the most inefficient things for input.
This new terminal thing looks great. I wonder if emacs -nw would display images in it.
Re: (Score:2)
Imagine ipython or isympy optimized for this terminal.
So (Score:5, Funny)
Re:So (Score:5, Funny)
Re: (Score:1)
Security implications do not look good (Score:4, Insightful)
Re: (Score:1)
The demo video they have look really cool and I like any idea that improves the usability of the terminal. I just hope that they have some strategies in place to minimize the security impact of adding a large amount of potentially vulnerable code to a critical service such as the terminal
Do not innovate. It might not be secure.
Re: (Score:3)
Do not innovate. It is guaranteed to not be secure.
Very much so. That's the depressing reality of the Internet in 2013.
Things might be different if we had languages and platforms which didn't actively conspire against us.
Re: (Score:1)
> platforms which didn't actively conspire against us.
We sort of do (well, much better anyway), but everybody keeps using C (or C++, just as bad) for application development, because, you know, *serious* languages give you six loaded machine guns and no convenient way to carry them except in holsters that aim the muzzle directly at your feet. Languages that do not do this are "scripting languages" and are "fine for quick one-off stuff" but "no good f
Re: (Score:3)
It's no more dangerous than having those programs around for the user. Let programs run a less-enhanced terminals when they need to run one automatically, let the user launch the fancy terminal from an icon.
Re: (Score:3)
However, there are ways around this. IIRC chrome decodes images inside a seccomp jail, causing an exploit in the image decoder to be very hard to use for anything except showing a a naughty image and eating CPU time. (I don't know i
Re:Security implications do not look good (Score:4, Insightful)
Most users are already running a file manager which decodes files willy-nilly for the purpose of thumbnailing. This is directly comparable.
I would also have imagined that by now there are image decoding libraries which never, ever trust the contents of the file, which have limits-style protection for excessively large images, and the like. It has always boggled my mind that anyone would ever write a file decoder which trusted the file's contents. Even in a world without malware, there is still data corruption.
Re: (Score:3)
I would also have imagined that by now there are image decoding libraries which never, ever trust the contents of the file, which have limits-style protection for excessively large images, and the like.
That's what I imagined too, but it seems like all the professional working programmers who wrote industrial-strength image parsing libraries just didn't bother to do any security checking at all and took all sorts of unsafe shortcuts. And then were really surprised to find that their 100% bulletproof code had been exploited.
I suppose I shouldn't really be surprised, given the corruption and meltdowns going on in other 'industrial strength' fields like, say, mining, or global banking -- but I always used to
Re: (Score:2)
it's no more dangerous than a filemanager that automatically displays thumbnails too.
Seems logical.. (Score:2)
The terminal is an echo from the past, even with all the things added like shells and so on. It makes sense that someone make a terminal that can in fact operate just like a window manager can, with the added power that can bring. Seems to me that with things like HTML5 - that weaving this into a nice terminal (which care of the video seems to be what they have done).
Its still a little rough around the edges, and it looks a bit like it needs more work in terms of UI and polish, but someday all terminals mig
Re: (Score:2)
Is this some kind of parody?
Re: (Score:3, Interesting)
Terminal : Low bandwidth, low resources way of accessing the system often remotely by experienced technical users
This Terminal : High bandwidth, high resources way of accessing the system bad for remote access and friendly to inexperienced non-technical users ....
Who is this for ...?
Re: (Score:2)
No, Terminal was originally simply the crippled ways users (I'm using the term with some sarcasm) had to use just to get access to a computer..
And the age of the 56k modem is applicable in a minority of cases, move on.
And to quote jobs, when he was at Parc Xerox - and he saw the future, he said once seen all computers will work that way. It was just obvious.
And further, friendly to users is a good thing. I meet many who argue otherwise, and they are wrong. Nuff said.
Re: (Score:2)
I meet many who argue otherwise, and they are wrong.
I don't think I've ever heard anyone advocating an unfriendly system.
What people advocate often is an expert friendly system that makes no particular effort for novice friendliness.
Most proponents of "user friendliness" tend to tell the experts that they don't want what they want and noone cares anyway.
Re: (Score:1)
This terminal's not high bandwidth at all... I can't comment on the resources. I switched back to lxterminal because I don't like how it handles tabs or transparency.
That being said, it had no issues at all SSH'ing into my server over a cellular connection, and I have no reason to think that it's actually going to increase the amount of data being transferred.
Unless you're stupid enough to try to run it remotely from the server, and use something like nx or vnc to display it locally....
Re: (Score:3)
I like it. I'm often annoyed at the split between the GUI and command line. What if I want to run a find and view the images or videos that result? Or I write a program that produces images, and I want to test many parameters without having to write a GUI to view the results. This allows shell script style programming to interact with graphical data, and that is something I've wanted for a while.
Re:Seems logical.. (Score:5, Insightful)
This is for people that like to work in the terminal--instead of a file browser--but still want to look at all their files.
When the UNIX terminal was invented, there weren't a lot of things to look at other than text files. Times have changed somewhat since then.
The terminal is often the best place to get work done, and sometimes you don't want to go into a file browser or fire up an external viewer just to look at a PDF. Being able to preview a file so you can correctly sort it into a directory, for instance, seems like a good use of this upgrade.
In OS X, you can get something like Pathfinder that lets you manage your files graphically, but has an attached shell if you need one. This is just a more terminal-centric view of things. You can still work text-only, if you like.
Re: (Score:2)
sometimes you don't want to go into a file browser or fire up an external viewer just to look at a PDF.
Why not? Why would you want to load a PDF viewer and movie player every time you want to pop open a shell? Doesn't loading the PDF viewer as needed make more sense?
As far as I'm concerned, make the output of 'ls' drag&dropable and call it done. That's all the GUI integration the terminal needs.
Re: (Score:2)
Well, if you get right down to it, this is what most graphical file browsers do already. So if I open up the Finder or Pathfinder in OS X, I get a previewer for all sorts of files automatically loaded. If I highlight a file and hit the spacebar, I get a preview of the content (or, really, you just see the content outside of a specific viewer; 'preview' is the the terminology that Apple uses, but it's not strictly correct). All this terminal application is doing is making it so that if you prefer to work in
Re: (Score:2)
All this terminal application is doing is making it so that if you prefer to work in a terminal to manipulate and view files, you have the same functionality as a GUI filebrowser.
I already do. If I'm at the command line and I want to view a file, all I have to do is type "preview file.pdf". Apple's Preview is just another application.
Re: (Score:2)
make the output of 'ls' drag&dropable and call it done.
I *hate* grag&drop. What I would like would be a feature like vimperator or pentadactyl, or maybe lynx numbered links, where a hotkey would make all displayed files, paths and objects in general labeled in some way, and I could start applications on the labeled objects, or use the labels on the command line in some way.
Re: (Score:2)
A couple small notes about the OS X terminal -- I'm not saying this Enlightenment thing is bad or not needed or Apple did it first, but just vaguely related, and of possible interest to people reading this thread...
- drag a file from the Finder into Terminal and it writes the path.
- `open` will open files, folders, or apps. `open .` will open the directory you're currently in. `open foo.txt` will open foo.txt in your default text editor, same as if you had double-clicked it in the Finder. I wrote a script c
Re: (Score:1)
Also I miss rewrapping output (that maybe more than the dnd, having to reissue a command because of truncated output is just a waste of my time) and the kerning.
Re: (Score:3, Informative)
Please become informed before claiming things you have no clue about. It does everything your current terminal does (more or less if we talk of vt100/200 and friends) the same way. It ALSO adds extended escapes and inside these all it sends is file paths or uri text. If you call a file path high bandwidth then ok, guilty. But I think you are simply living up to slashdots reputation in the users category of blowing hot air.
Re: (Score:1)
There are many different terminals with low bandwidth requirements. These are not going anywhere. However, if you are accessing your local system and bandwidth is not an issue, and you would find these facilities useful (I know I might sometimes like file previews etc. when using the terminal) then this is a clever and positive enhancement, reducing the need to swap between terminal and gui.
You seem to be either of the school that says "This is no good for what I want so it's bad" or "Choice is bad".
Re: (Score:2)
bingo. it's a terminal at its core and does all the things a regular terminal does. it ADDS things you CAN use. you CAN set a background to an image fine - most terms can since i added that to rxvt many years ago and started the trend (rxvt-xpm became eterm and then everyone copied). there is nothing wrong with ADDING some bonus features. the libraries already do all the work. the code and features are there. it's generic code. there is no good reason to specifically disallow such things just because it's
Re: (Score:3)
The reason I like this is that it seems to be good for everybody. inexperienced non-technical users will find it easier using a terminal, while experienced users will get to use a terminal just like before, with added stuff that does not seem to get in the way. I would like to know how configurable all the graphical stuff is. Can I add graphics into my shell prompt? I guess since it works using escape sequences, the answer is probably yes. Including a little sparkline displaying system load, or a miniatu
Re: (Score:2)
you can put imagery into your prompt indeed.. as long as the imagery is only of green phosphors! :)
WOW! (Score:3)
Can it access media over ssh? (Score:4, Interesting)
Re: (Score:2)
Not related to in-terminal preview but to stream over SSH have you tried mounting the remote location and streaming with sshfs? I've done it before and as long as the link is stable it seems to work fine (even for video).
Re: (Score:2)
Yes, I tried. But things like mass re-tagging media (ogg vorbis) files are very slow if the actual file content needs to be sent back and forth over wi-fi, compared to doing the file operations locally on the media server.
Re:Can it access media over ssh? (Score:5, Informative)
Sorry. Doesn't work over a remote shell. Has to be local atm. Haven't figured out how to sensibly do it remotely.
Re: (Score:2)
Do you say this as a beta tester or as a developer?
I suppose that one could implement the 'tyls' replacement for ls without all the GUI libraries (probably a 20 line perl script could do the job). Maybe without thumbnails, but at least with hyperlinked filenames. If the filenames are then encoded as, e.g., sftp://host/path/foo.jpg, then it would not be too hard to implement a handler inside terminology
Re: Can it access media over ssh? (Score:3)
I say this as the guy who wrote it... came up with the escaping side Chanel data scheme and wrote most of the library code it depends on in efl. :)
Re: (Score:2)
I just had a look at tyls.c; it looks to me like the escape codes have the filename and a generic icon identifier ("like "application-x-tar") embedded, or no icon identifier if it is a media file. I assume that the terminal client then looks up the file and generates the thumbnail.
Why is it infeasible to use URIs rather than pathnames, so that the terminal can fetch the data? I understand that it's more work than adding three lines of code, but your wording "Haven't figured out how to sensibly do it remot
Re: Can it access media over ssh? (Score:4, Interesting)
it already does uri's... just provide http://blahlahblah.com/blah [blahlahblah.com] instead of /path/to/file and it'll fetch it. here's the catch - that;s not useful as WHO will serve it? what URL? what webserver? won't work over ssh. wont work OVER your connection. it has to work VIA it to be feasible.
now to display a thumbnail i could have tyls generate small low res thumbs itself and embed the thumbnail image inside escapes and send it down the terminal pipe, but this will only work for small thumbnails - what if i want to ... play video? then we have to stream the entire video via an escapecode... and that;s just awful! i am not ready for THAT level of evil.
btw. thanks so much for being an informed user who will bother to look at the code before rabbiting on about vague unfounded assumptions. :) i guess it's sad that i have to even say this. :) anyway - and tyls.c is ugly as. it was a quick test program i brewed to test the escapes it is not at a nice piece of code... :) it needs some love.
Re: (Score:2)
I'm using Gnome 2 and Compiz, so I'm not sure whether this translates to your platform, but in the Gnome file manager I can enter sftp://username@hostname:/home/username/foo.jpg . I guess the problem is figuring out as which hostname the server is accessible, which will probably mean an old-style ~/.tyls configuration file ("When logged in from 192.168.1.14, then prefix the pathnames with sftp
Re: (Score:2)
correct. what is the hostname that is visible FROM one system TO the other? who knows. you may ssh through several natted gateways into an internal network. i do this all the time actually. it simply wont work then (the sftp:// idea). i am not fond of the configuration idea. oh and it handles uri's but not sftp - http/https/ftp sure, but that doesn't solve the issue here. to work right it needs to transport via the terminal stream, and that's where i haven't decided on a sensible solution. i've given it som
Re: (Score:2)
He is saying it as the rasterman, duh!
VERY poor choice of escape sequences (Score:5, Informative)
They should have used the future-proofed OSC, DCS, SOS, PM, or APC prefixes instead of this new ESC{ sequence. And then they terminate the sequence with a control character (NUL)! This is worse than "ANSI music".
Terminology authors, if you are reading this, could you PLEASE talk to Ted Dickey (xterm and ncurses maintainer) about the RIGHT way to do this? Otherwise you're going to find yourselves with your own version of brokenLinuxOSC.
Re: (Score:1)
PLEASE talk to Ted Dickey (xterm and ncurses maintainer)
Tom Dickey?
Re:VERY poor choice of escape sequences (Score:4, Interesting)
And what is wrong with this? It's the same style as xterm title set escapes. ?
Re: (Score:2)
The two problems I'm seeing (Dickey may see more) are:
1) The sequences use a non-standard opening. This means for terminal writers that we need several new states in the state machine just for this terminal. We're unlikely to do this, especially when OSC/DCS/etc. already exist for this precise purpose, and this is indeed how xterm does it.
2) The sequence is (sometimes) terminated by a control character in the C0 set. Control characters are normally processed separately from the rest of the state machine
Re: (Score:1)
Re:"only built on EFL and libc" (Score:5, Informative)
Me (author) doesn't care about this as these are already the requirements of e17 anyway, so for the target audience or doesn't need extra dependencies they don't already have. By the time you have any featured desktop installed you have at least this much installed.
Re: (Score:1)
Sometimes I think people will find anything they can to complain about. Of course you'll need libraries to render the pictures and play back video, not to mention all the other features. And since it is part of Enlightenment, why shouldn't it utilize the libraries that are already there? It's not like there aren't other tiny terminal emulators around. I haven't played with E17 in a while, but this makes me think I should at least look to see about installing this. I just wish there was some way to have some
Re: (Score:3)
You're clearly not already running e17 from that list of dependencies... your complaint is akin to somebody complaining that installing kopete on their gnome system pulls in a ton of unneeded deps.
From a system that's already running e17:
tara@MarchHare:~$ sudo apt-get autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
tara@MarchHare:~$ sudo apt-get install terminology
Reading package lists... Done
Buildi
Turing Test Completed (Score:5, Funny)
a material improvement to terminals (Score:3)
Cmon, this is a real improvement to the functionality provided by modern linux terminals. I think it's cool as hell.
Re: (Score:1)
I agree. It's exactly where the linux desktop improvements need to be - doing the desktop in the linux way rather than copying.
I'd like to see more drag and drop linking to programs; edit those pix, imagemagick those pics into a flow of processing and so on.
The copy and paste improvement is good. Seeing the pics is good. The eye candy... meh. Possibly that's what put a lot of people of reading the article and we only have a few comments. I admit I usually skip anything from Enlightenment.
I'll keep an eye ou
just linux (Score:1)
Re: (Score:2)
Why is this big news? (Score:2)
After all, playing video and displaying pdf's have been
solved problems for decades.
What does it matter what 'shell' program is built around
such functionality?
I am sympathetic towards Enlightenment, but this I don't
get. And by the way, doesn't this run in the face of the old
UNIX adagium 'modularity'?
Re:Why is this big news? (Score:4, Informative)
it's modular. just at the library level which does make for a lot more efficiency. :) and what is new here - bringing the usability to your regular cmdline terminal without the need for launching other apps in windows... oh and did you read? it can render with opengl.. THAT is not exactly old hat.. AND it works in the framebuffer without x... and gives u moue control and copy and paste... IN the framebuffer... AND.. its like 20 TIMES faster than the kernel text console (try see how long u ait for a file to cat in the console vt)... and then in your console u can view pdf's, images and videos... the SAME as you do in x... oh and tabs and splits will work in the fb too... oh and it works in wayland too... not like there are a lot of terminals for wayland atm.
Re: (Score:3)
Re: (Score:1)
If you want something to really get hopping mad about, terminals that can do this have been around for years [acko.net]. Ages, in fact [xml.com].
Nice to know that xmlterm is still remembered (author). There is now an updated version, called GraphTerm [mindmeldr.com], which is similar in some respects to Terminology but is written in python works completely within the browser.
Way to go, E! (Score:2)
I often find myself switching between CLI and GUI, either of which has usability advantages depending on the problem at hand. This one has a good chance of combining the some of advantages of both and come out as a solution outperforming either of the two traditional options. Nice job! So inspiring. Very creative! Way to go, E!
Re: (Score:2)
people did think about it before, but it has pretty much become forgotten, and hasn't been slickened up and polished and shipped in a modern terminal. it hasn't been demoed or shoved in peoples faces to get them to think "wait a sec.. if THAT is possible... what could i DO with it?". this is not an end. it's a beginning. it's trying to say "hey people. you don't HAVE to JUST do text. what if you wrote your shell scripts or other cmd line tools to assume such capabilities... what would YOU do with it? would
Re: (Score:2)
Who'd have thought this troll would have an actual reference point to a submission...