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.
it already does uri's... just provide http://blahlahblah.com/blah 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.
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.
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.
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.
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.
and you spent 0 seconds even trying e17 or reading the page about it that tells you that that needle is the cpu freq.. and if you ever had a battery or care about the whining noise of your fans... you'd care about that needle. if you dont care.. you can remove it. it solves stuff like "my machine performs badly" and have to file a bug with your distro and hope it fixes it.. when a click of a men has it doing exactly what u want. control handed to you. you want to chew through power. want it to sip? ondemand is not a solution. try a nexus7 one day and find you need to select a special interactive scheduler to get it to work well... thats what that needle is - cpu power management control & status display. if you dont want it.. remove it. but... you'd need to actually try it ut and maybe read something first... instead you like to just draw a conclusion from a screenshot and blurt your ill-informed opinions to the world.
ummm if you couldn't drag a window from one screen to the other - this isn't e's fault. it's x config (you used multihead not xinerama/tiwinview/mergedfb). in this setup x has 1 root window per screen and you literally just cant move windows from one to the other. they need to be re-created per root window.
in the case of xinerama setups e17 still treats them as separate screens as you say, and switches desktops separately... but you can drag windows between them nicely. as such i know there have been a few odd people who complain about this initially - mostly as its a shock to see this and they want "the old behavior back", but after a short time they get used to it, then love it and can never imagine going back.
at least anecdotal evidence tells me that e17's way is the best/right way, but there is just the understandable "but hey - this is different" reaction that needs to be gotten over. its really a very small change, but very significant in terms of usability.
yeah. alan had nothing to do with that. alan is a great guy - i like him and yes - some of my code was a bit spaghetti-like at the time. other bits were clean and nice. it depends which bit you look at. current EFL code is much better. everyone learns as they go along and improves their code. i did too.
bwahahahaha. love the FUD man. i suggest you school up on history.
*I* quit doing gnome stuff because redhat was not paying me anymore indicating that i must work on gnome, thus i had the freedom to choose, and i CHOSE not to, because i hated the direction it was going and my CHOICE was to veer away and e stopped bending to gnome's will and thus it became hard for gnome to use e because it conflicted with what they wanted to do.
early on before gnome was known about, redhat caught wind of gnome and wanted me to help. i offered to tailor e for gnome at the start. miguel (hi!) stated that gnome needed no wm and would work with all and any wm just fine. i disagreed. since i wrote wm's i kind of had an idea of what would be needed. a year later it was "oh halp! we need a wm! we can't do x, y, z without one". too late. i was tailoring e to be independent of any desktop like gnome. gnome wanted to have a virtual desktop set up totally incompatible with e's because gnomes concept of desktops was too simple. it wanted to take over pager desktop switching and task switching. it wanted to be master and wm be a dumb slave and take over a lot of the functionality of e. i disagreed and by now it was too late as i wasn't going to kill all the features already now in e because gnome didn't want them. i ultimately put in some support for gnome, ability to disable such features in configuration, and it happened to be one of the first wm's with gnome support but it was limited and i had no plans to extend it or integrate it more in gnome and that is why gnome stopped using e because they wanted a wm that JUST is a wm and doesn't do anything more that a very limited set of things.
llvmpipe vs evas's software rendering is like comparing a penitum1 and a modern desktop. really llvmpipe is better than swrast but it's still like 10-30fps on a high end modern desktop for the same workload when evas pulls in 60fps+ (it gets limited to 60fps or whatever your refresh/animation rate is, but on the same machine it can pull in 200-300fps for the same workload). that's the point. it's a significantly better software fallback that makes compositing usable.
Actually it doesn't pre-date it. it came after GL started to work on Linux, but when GL still was way too immature to use for 2D. in fact it was GL beginning to work on linux back in the earl 2000's that pushed EFL's current design- to plan for a future where GL will be a primary rendering path, but provide a software version for when that doesn't pan out to be the best idea. it was all DESIGNED to abstract between back-end from the ground up and one of the design goals was to use both GL and software back-ends highly efficiently. and it's paid off handsomely now that it's being used for compositing.
E has the best of both worlds. full GL accelerated compositing (if you have the drivers/hardware) or a software version for when you don't. we don't drop features, we just switch which part of your machine is doing the work, and we made sure if it's on a CPU, it'd done fast enough to be totally usable, which it is.
rely on software fallbacks *OF OPENGL* i.e. mes'a s software implementations (swrast/llvmpipe). there is a special software rendering engine that is unrelated to opengl in any way or form. it's the same software engine powering the rest of the display/widgets/gadgets/wallpaper etc. it happens to also do the compositing. it ALSO happens to be switchable between software and GL and thus why comopsiting CAN use GL.
Desktop naming: E17 does this.:) it flashes not just the name but a full preview of all desktops in a "larger size" with their contents etc. Clip: e17 shelf. can be customized per desktop.
WM dockapps: e17 modules+gadgets. not separate processes but plug-ins so they hare generally lighter weight - you CAN implement them as a module "glue" plus slave process if u like.
Awesome skinability: we have a whole toolset for it. edje_cc compiles them and after that just select the output edj file from the theme browser. the theme though is complex, but insanely powerful.
Compositing: yeah. E17 dos that too. it also solve world peace and hunger.:)
s3 is not slower. my bet that the variance in benchmarks is totally related to the cpu wantonly clocking down to save power while running the benchmark (eg it wasn't plugged into power at the time and the benchmark doesn't have root access to force the cpu to to clock speed). thus reality is you actually have to take the highest numbers as the real number given interference with clocking down and maybe even other running tasks will drag the benchmark down.
one thing the iphone5 is good as it memory bandwidth. that is where it kicks butt. it'll help memory constrained tests a lot.
x doesnt introduce firewall issues. there is no requirement you have it listen on a tcp port externally - its an option turned off on many linxu distros these days (its a cmdline option for x).
x also is not that large. i've included it PLUS base x libs PLUS kernel, libc and everything else needed inside a 4mb filesystem image for my ipaq many years back. i'ts only bloated if you choose to make it so.
this has nothing to do with gfx vendors by is piss-poor text mode EMULATION inside the kernel. your "text mode" console is actually graphics mode and emulated to be text by the kernel splatting out pixels that look like text chars - just like x does (and x apps).
it's piss-poor at this because it's poor unoptimized code that does some royally stupid things.
1. "blit" (copy region) to scroll 1 line at a time... and this ends up being almost always done by your cpu. 2. this blit will be done by cpu to/from video memory which often is on a discrete video card across a pcie bus or such 3. writes across this bus are fast, but reads can be in the order of just 10mb/sec. it's piss-poor at reads. 4. the kernel text console doesn't try and play catch-up and scroll multiple lines at a time. it scrolls 1 line at a time thus making the overhead of copying enforced per line scrolled, as opposed to internally skipping a bunch of lines and drawing 2, 5, 20 new lines and copying up only those that are not new.
it's entirely poorly performing because of poor kernel code. how poorly performing? well.
i recently decided to write a terminal emulator (for x). of course i went and used a toolkit i knew to help, and it so happens this toolkit can automatically work in the linux framebuffer just like it does in x11. it can use opengl, but doesn't need it and works fine on a dumb fbcon text console. so i now have the EXACT same terminal in bot x11 and fbcon. hell it even manages to provide me a mouse pointer in fbcon as it detects it's in fb and the toolkit emulates one itself. it looks the same pixel-for-pixel too. so i did some performance comparisons of it in fbcon vs kernel text console. it clocks in at being 55 TIMES faster than the kernel. 55 TIMES. that's how poor the kernel is. going through scads of toolkit layers and abstractions, code to alpha blend the text on top of backgrounds, blend and scale lighting overlays and more... and its still clocking in at 55 TIMES faster. (it happens to run at about the same speed in x11 - on the same machine).
it's not fast because it's amazing code or i'm a genius at all - it's fast because it just is NOT being royally stupid, which is what the kernel text console emulation is.
personally i was quite happy to know my terminal works both in x and in fb.. so if'm i'm ever stuck there.. i can use it and not be 100% grumpy that my text console is piss-slow anymore.
Slashdot Mirror
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.
it already does uri's... just provide http://blahlahblah.com/blah 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.
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. :)
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.
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.
Sorry. Doesn't work over a remote shell. Has to be local atm. Haven't figured out how to sensibly do it remotely.
And what is wrong with this? It's the same style as xterm title set escapes. ?
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.
'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.
and you spent 0 seconds even trying e17 or reading the page about it that tells you that that needle is the cpu freq.. and if you ever had a battery or care about the whining noise of your fans... you'd care about that needle. if you dont care.. you can remove it. it solves stuff like "my machine performs badly" and have to file a bug with your distro and hope it fixes it.. when a click of a men has it doing exactly what u want. control handed to you. you want to chew through power. want it to sip? ondemand is not a solution. try a nexus7 one day and find you need to select a special interactive scheduler to get it to work well... thats what that needle is - cpu power management control & status display. if you dont want it.. remove it. but ... you'd need to actually try it ut and maybe read something first... instead you like to just draw a conclusion from a screenshot and blurt your ill-informed opinions to the world.
ummm if you couldn't drag a window from one screen to the other - this isn't e's fault. it's x config (you used multihead not xinerama/tiwinview/mergedfb). in this setup x has 1 root window per screen and you literally just cant move windows from one to the other. they need to be re-created per root window.
in the case of xinerama setups e17 still treats them as separate screens as you say, and switches desktops separately... but you can drag windows between them nicely. as such i know there have been a few odd people who complain about this initially - mostly as its a shock to see this and they want "the old behavior back", but after a short time they get used to it, then love it and can never imagine going back.
at least anecdotal evidence tells me that e17's way is the best/right way, but there is just the understandable "but hey - this is different" reaction that needs to be gotten over. its really a very small change, but very significant in terms of usability.
never got around to it. :( it's still on the todo list. we've been distracted into doing whole widget sets and toolkits and other stuff. :)
yeah. alan had nothing to do with that. alan is a great guy - i like him and yes - some of my code was a bit spaghetti-like at the time. other bits were clean and nice. it depends which bit you look at. current EFL code is much better. everyone learns as they go along and improves their code. i did too.
actually better opportunity was not in my home country... it was in california (vs north carolian)... it was a good move at the time. :)
bwahahahaha. love the FUD man. i suggest you school up on history.
*I* quit doing gnome stuff because redhat was not paying me anymore indicating that i must work on gnome, thus i had the freedom to choose, and i CHOSE not to, because i hated the direction it was going and my CHOICE was to veer away and e stopped bending to gnome's will and thus it became hard for gnome to use e because it conflicted with what they wanted to do.
early on before gnome was known about, redhat caught wind of gnome and wanted me to help. i offered to tailor e for gnome at the start. miguel (hi!) stated that gnome needed no wm and would work with all and any wm just fine. i disagreed. since i wrote wm's i kind of had an idea of what would be needed. a year later it was "oh halp! we need a wm! we can't do x, y, z without one". too late. i was tailoring e to be independent of any desktop like gnome. gnome wanted to have a virtual desktop set up totally incompatible with e's because gnomes concept of desktops was too simple. it wanted to take over pager desktop switching and task switching. it wanted to be master and wm be a dumb slave and take over a lot of the functionality of e. i disagreed and by now it was too late as i wasn't going to kill all the features already now in e because gnome didn't want them. i ultimately put in some support for gnome, ability to disable such features in configuration, and it happened to be one of the first wm's with gnome support but it was limited and i had no plans to extend it or integrate it more in gnome and that is why gnome stopped using e because they wanted a wm that JUST is a wm and doesn't do anything more that a very limited set of things.
you need to get your history right.
llvmpipe vs evas's software rendering is like comparing a penitum1 and a modern desktop. really llvmpipe is better than swrast but it's still like 10-30fps on a high end modern desktop for the same workload when evas pulls in 60fps+ (it gets limited to 60fps or whatever your refresh/animation rate is, but on the same machine it can pull in 200-300fps for the same workload). that's the point. it's a significantly better software fallback that makes compositing usable.
Actually it doesn't pre-date it. it came after GL started to work on Linux, but when GL still was way too immature to use for 2D. in fact it was GL beginning to work on linux back in the earl 2000's that pushed EFL's current design- to plan for a future where GL will be a primary rendering path, but provide a software version for when that doesn't pan out to be the best idea. it was all DESIGNED to abstract between back-end from the ground up and one of the design goals was to use both GL and software back-ends highly efficiently. and it's paid off handsomely now that it's being used for compositing.
E has the best of both worlds. full GL accelerated compositing (if you have the drivers/hardware) or a software version for when you don't. we don't drop features, we just switch which part of your machine is doing the work, and we made sure if it's on a CPU, it'd done fast enough to be totally usable, which it is.
it is.
rely on software fallbacks *OF OPENGL* i.e. mes'a s software implementations (swrast/llvmpipe). there is a special software rendering engine that is unrelated to opengl in any way or form. it's the same software engine powering the rest of the display/widgets/gadgets/wallpaper etc. it happens to also do the compositing. it ALSO happens to be switchable between software and GL and thus why comopsiting CAN use GL.
And it feels so good...
Desktop naming: E17 does this. :) it flashes not just the name but a full preview of all desktops in a "larger size" with their contents etc.
Clip: e17 shelf. can be customized per desktop.
WM dockapps: e17 modules+gadgets. not separate processes but plug-ins so they hare generally lighter weight - you CAN implement them as a module "glue" plus slave process if u like.
Awesome skinability: we have a whole toolset for it. edje_cc compiles them and after that just select the output edj file from the theme browser. the theme though is complex, but insanely powerful.
Compositing: yeah. E17 dos that too. it also solve world peace and hunger. :)
and there is at least 1 1.4gz bench clocking in at over 2000:
http://browser.primatelabs.com/geekbench2/1032880
so relevant.
http://browser.primatelabs.com/geekbench2/search?page=1&q=S+III&utf8=%E2%9C%93
http://browser.primatelabs.com/geekbench2/1012560
http://browser.primatelabs.com/geekbench2/995810
http://browser.primatelabs.com/geekbench2/912975
s3 is not slower. my bet that the variance in benchmarks is totally related to the cpu wantonly clocking down to save power while running the benchmark (eg it wasn't plugged into power at the time and the benchmark doesn't have root access to force the cpu to to clock speed). thus reality is you actually have to take the highest numbers as the real number given interference with clocking down and maybe even other running tasks will drag the benchmark down.
one thing the iphone5 is good as it memory bandwidth. that is where it kicks butt. it'll help memory constrained tests a lot.
x doesnt introduce firewall issues. there is no requirement you have it listen on a tcp port externally - its an option turned off on many linxu distros these days (its a cmdline option for x).
x also is not that large. i've included it PLUS base x libs PLUS kernel, libc and everything else needed inside a 4mb filesystem image for my ipaq many years back. i'ts only bloated if you choose to make it so.
this has nothing to do with gfx vendors by is piss-poor text mode EMULATION inside the kernel. your "text mode" console is actually graphics mode and emulated to be text by the kernel splatting out pixels that look like text chars - just like x does (and x apps).
it's piss-poor at this because it's poor unoptimized code that does some royally stupid things.
1. "blit" (copy region) to scroll 1 line at a time... and this ends up being almost always done by your cpu.
2. this blit will be done by cpu to/from video memory which often is on a discrete video card across a pcie bus or such
3. writes across this bus are fast, but reads can be in the order of just 10mb/sec. it's piss-poor at reads.
4. the kernel text console doesn't try and play catch-up and scroll multiple lines at a time. it scrolls 1 line at a time thus making the overhead of copying enforced per line scrolled, as opposed to internally skipping a bunch of lines and drawing 2, 5, 20 new lines and copying up only those that are not new.
it's entirely poorly performing because of poor kernel code. how poorly performing? well.
i recently decided to write a terminal emulator (for x). of course i went and used a toolkit i knew to help, and it so happens this toolkit can automatically work in the linux framebuffer just like it does in x11. it can use opengl, but doesn't need it and works fine on a dumb fbcon text console. so i now have the EXACT same terminal in bot x11 and fbcon. hell it even manages to provide me a mouse pointer in fbcon as it detects it's in fb and the toolkit emulates one itself. it looks the same pixel-for-pixel too. so i did some performance comparisons of it in fbcon vs kernel text console. it clocks in at being 55 TIMES faster than the kernel. 55 TIMES. that's how poor the kernel is. going through scads of toolkit layers and abstractions, code to alpha blend the text on top of backgrounds, blend and scale lighting overlays and more... and its still clocking in at 55 TIMES faster. (it happens to run at about the same speed in x11 - on the same machine).
it's not fast because it's amazing code or i'm a genius at all - it's fast because it just is NOT being royally stupid, which is what the kernel text console emulation is.
personally i was quite happy to know my terminal works both in x and in fb.. so if'm i'm ever stuck there.. i can use it and not be 100% grumpy that my text console is piss-slow anymore.