rasterman

well this is a bit of a slow-ish box. it's my daily driver workstation at work. ampere emag (arm64 machine). numbers taken using strace -tt thus adding some overhead. time to launch eog (gnome/gtk image viewer) and go idle after drawing: 2.221 sec. definitely measurable. similar number for entice (efl image viewer) 2.294 sec. within spitting distance of each other (error margin) but time to tycat the same image in a terminal (between enter and image shown and terminal idle again: 0.123 sec. this is a server chip with 32 arm64 cores launched about 6 years ago or so. 3ghz. :) i definitely have benchmarked this kind of thing many many many times over the years. i've stared at process startup times and what toolkits do on startup to create a window etc. - i've memory and other profiled them a lot too. i know it's a good chunk cheaper to just tycat :) but it's more about less interruption to workflow.

right now in theory it allows different sized icons... the metadata can exist and define it.. but i have not provided a ui to change sizes... but yes... amiga-like :) there is a .efm/ dir in each dir ... and in this can be files for thumbnails, or metadata (as well as metadata for the dir view as a whole). if you don't have write access it can shadow these in ~/.e/e/efm/meta/ - i thought a lot on this and chose to put the data in the dirs because in the end it's the sanest place to have the metadata follow files as you move/copy/delete stuff around your filesystem. some of this metadata can define x,y per icon as well as size... they are little .ini format files per file. so as such in principle it is a bit like the good old amiga .info files ... but just stored in a different place and now a .efm/file.meta.efm or .efm/file.thumb.efm.eet for thumbnail data...

This is just a demo right now - buttons surrounding the file view are for testing:

http://www.rasterman.com/files/efm-typebuf-ex.webm

This is just a demo right now - buttons surrounding the file view are for testing:

http://www.rasterman.com/files/efm-typebuf-ex.webm

the cost of launching a new process with a gui is not cheap. there's a lot of setup before you even get a window up ... when that process is already there (terminal) with all of that cost paid for it is actually provably cheaper in terms of cpu cycles, latency etc. to pop up an image/video in your terminal. and cheaper not by 1 or 2 ms... but by 100's ms or more. that new window is not cheap. you also have the visual disconnect - the window pops up somewhere else with your wm having no idea that that new window is related to the terminal you ran it from because there will be no transient_for hints set to say that. relying on process tree hunting to figure this out is a crapshoot at best and will probably give you more misses than hits. we can go down that rabbit hole if you want but trust me - it is measurably less overhead to pop it up in a terminal with a few dozen chars worth of escapes sent to the terminal to do it.

there are in fact ways of drawing raw bitmap data in terminals - look up sixel for starters...

but that's not what this is about. the escapes to do images and video are very simple and very lean in terms of i/o from pty to terminal - unlike sixel.

i added this because it's useful. to me. and apparently to quite a few other people. as i've explained. a quick tycat file.mp4 or typop file.jpg or tybg file.mpg etc. - or even roll these escapes with echo's into your shell rc files... like you might change prompt colors with escapes when you su/sudo as root or you ssh into another machine and change the terminal title to alert you - you can use images and video to do this too.

you can just not use the feature. fine. up to you. why should your lack of desire for it mean no one else gets a useful feature for them? it was not like adding the support was drastically difficult and i had to write an entire video codec engine. i re-used existing support that already wrapped it up in a nice little bow (i also wrote most of that support code in efl btw so i know what it can do, what it does and how it does it).

i can ALSO use my gui in the normal way. i wrote a video player too: rage. plays video (and music too - snarfs album art for music if you have none too). i wrote a file manager or 2 or 3... they show thumbnails of files... can even pop up a video and play it in a tooltip popup... same libraries behind terminology do all the hard work. i can choose whatever workflow works for me at the time. i'm not limited to one way only. this softens the boundaries between workflows and brings some features of of workflow into another. it creates less of an abrupt "i have to switch" and more of a "i can just keep going for a while doing what i was doing". my new rewrite of efm (e's built-in filemanagger) also has a terminal-like worklflow. i can literally in the efm window type "ls ./dir" and it will liteally change to that dir and list/show it. same with "cd .." or "rm a.jpg b.txt *.png" and it will delete those files. you can even just run apps like "gimp file.png" .... and it knows gimp is a command and there is a desktop file for it and will let you know by putting an icon next to it.. and it'll just run the command with those arguments... this is the inverse of terminology - it's bringing some terminal workflow into a gui filemanager. it softens the boundaries. it allows you to use muscle memory you already have for more things. that's the point.

terminology has other handy features that piggyback off the same extended escapes. tysend will do a zmodem-like transfer of a file via the terminal. and btw - the libraries that deal with images and video.. they can also load xls files... and pdf too - as images. it's how the filemangager can generate thumbnails for them... they can actually access arbitrary pages in a pdf - it's just a feature of the image loader. so a little wrapper and you can flip through rendered pages of a pdf... i just didn't do a "paged interface" in terminology like i did a video/audio one with play/pause etc. controls... i could pretty easily. :) easy enough to add though... but i'm busy with the filemanager work at the moment.

when it's your window manager you are using right now... you tend to debug differently :) yes yes - xephyr and what not. i know...

that was literally me... i stopped it because... well.. short version - chasing bug in efl that blurted out an invalid object stdout errors when http requests for the forecasts module failed - the module relies on a caching proxy service on e.org to get weather forecasts. i simulated it a bit brute-force by temporarily taking down apache :) it's back and bug is fixed in git. it's silent now not complaining about invalid objects.

well why video in a terminal? 1. it's "free" because the toolkit already offers video objects - feature is there... why not expose it. you just call 2 lines of code or so and and tell it to play. it's similar amount of code for an image, so it's basically free really. why do still images and NOT video? why stop there when video is only a little more code. sure. if you want a movie as a background: probably a bad choice, but if it's one of those zen videos with just trees swaying in the breeze as a background or a mountain lake rippling in the wind with very little motion but enough to make it "come to life", why not? but ok - for real usability? example: you're browsing through your dirs. cd ~/xxx/yyy; ls; cd zz; ls ... oh there's cat-sunning.mp4 there... i have 87 videos of cats sunning themselves.. which was that? tycat cat-sunning.jpg -> boom. video appears in terminal - you cat'd it.. it plays (tycat is just a tiny cmdline tool that emits the right escapes to terminology. you could make it a shell alias or script too and not use tycat. escapes are documented in the readme. this works even in a dumb framebuffer without wayland or x display systems (because the toolkit handles auto-detecting its environment and if in just a tty/vt it'll fall back to fbcon or kms/drm and render there). so you get a mouse and a full-screen graphical terminal that can do splits/tiles/tabs and so on with no windowing system and you can happily still explore all your files there even if they are videos... you aren't forced to use the feature... but it's there if you need it or want it.

> In lua it is customary to bring along your own main loop. > People often start with one based on select, but later move to libevent, libev, cqueues, luv (libuv), glib or others.

And that is what we provide - yes the toolkit is built around the mainloop we provide. It's a core design concept. It's a necessary thing to have a working UI to drive I/O. Trying to avoid a mainloop is just an order of magnitude more painful and leads to pretty bad design. UI updates are tied in great detail to the mainloop where they actually time themselves to vsync updates invisibly to the programmer for example.

> Neither is there for C.

Yes, and thus a toolkit brings one along. This is the case for sure for GTK+ - that mainloop is glib. That's how this works. Trying to avoid a mainloop or just choose whatever one you like is also like asking "well I want to use GTK+ for this widget and Qt for this one, and maybe EFL for this other one... in my window". If you jump through enough hoops and create enough ugliness it might be possible, BUT it comes at a cost. Trying to avoid this pushes everyone into the loweest common denominator design which basically means "assume X11, a window and draw commands and you call a 'draw me' function, then have more functions to push in events etc." ... this gets insanely complex once you start dealing with sizing, layout logic which differ, and not to mention you just screwed the pooch on deferred rendering, trying to to real acceleration e.g. via OpenGL because this is no longer even close to optimal etc. ... and mainloops are similar (though simpler). you can squeeze them together with some effort but trying to design without one and "well go bring your own" just leads to incredibly horrible API as well as overhead for the developer.

> The 'sample' lua application is quite often used as a runtime; if your library can't be used from it, it won't be useful for the majority of developers.

that's not of much if any concern to us as we provide a runtime already.

> In elua you still have to load in the bindings yourself (via require).

that will change as its simply boilerplate someone shouldn't need to go from zero to working app.

> I have no idea how this is related. lua already has tools to pack resources into one executable (e.g. srlua). but you can use any tool/method you want. This doesn't dictate the main loop used in any way.

If your source and resources are packed into a single file then the executor needs to be able to read from that file and unpack stuff from it FIRST before a single line of any lua code is run. it has nothing to do with mainloop etc. - it has to do with features existing before any lua code is run.

> you just use #!/usr/bin/env lua. Which will pick up whatever the user/distro has picked (e.g. a user might use debian update-alternatives). If you need a particular version of lua, use `#!/usr/bin/env lua5.1` which is the generally accepted shebang.

perhaps ONLY on debian... because on arch i can have both lua and luajit installed and /usr/bin/lua is PUC lua ALWAYS and /user/bin/luajit is from luajit - always. env will not work here as the command is actually totally different.

well we already did the integration. it doesn't need exposing. it's meant to be handled by the bindings for that runtime environment specifically or is just always available. so it merges currently with glib mainloop and with libuv so if you run the ecore mainloop you ALSO have (optionally as long as efl is compiled with these) a glib and a libuv loop too merged together as one, so they all are then compatible and work at the same time. yes - it requires the app spin up the ecore mainloop (it actually is the efl.loop now) instead of another, but existing code that uses the 'native mainloop' for that runtime will continue to happily work just as it was working before in that runtime env, but as lua never provided a mainloop, then we're it along with glib if you want and/or libuv. the integration is done down in the c code for the efl loop. for lua there IS not native mainloop as there is no native lua runtime (beyond a sample lua cmdline), and by this i contrast it to something like node.js. we provide one (elua) that will load in the bindings stubs for you and thus work. we do this because lua itself unlike something like node.js or python doesn't push the idea of "a single lua executable to run all lua runtimes". it has demo/sample/test executors, but it is built as a library primarily to then be embedded into another runtime. we happen to provide a guaranteed runtime binary too.

there are very good reasons for this for the future, like being able to package up applications into archives (like .apk for android, .jar or java etc.) as we already have a whole archive library (eet) that handles random access read (and decompress), so this would allow for lua apps to be shipped as single file archives with all script AND data files (images, theme data, videos, icons and more) in a single file just dropped into a directory with no extra dependencies or tools needed. to do this we need something like elua. our whole intent is to actually become a portable cross-platform toolkit where you do not need external plugins, binaries, libraries and can build a portable application that "just works" on multiple OS's without needing to instruct people on how to install 3rd party dependencies.

also so far we've supported both luajit and puc lua (and intend to drop puc lua because of ffi and a few other niggles) so this is a big problem as to which executable then gets used? different names. lua va luajit. how do you run things "by default" and know it will work and which one will be installed? part of our build uses elua and lua scripts to generate documentation so how could we run our doc generator when we don't know what executor is there on the host? we'd have to add more detection and have file.lua.in files where #!/bin/whatever is replaced with the correct lua etc. ... not pretty where now #!/bin/env elua will do fine.

node.js insists on its own mainloop. python is agnostic. efl already integrates with node's libuv usage and glib mainloop. really gtk requires a glib mainloop. you make glib integrate/sit on top of something elses and efl did the same thing.

well it's a framework like Qt is... :) or like GTK+ and glib and then some. so if these were acceptable for bindings if they were maintained/up to date then EFL would be.

But yeah - we bound to LuaJIT because of performance and FFI. Technically bindings could generate C code for PUC Lua too. We generate C++ for v8 for JS, so it's possible but not done. My point was that we're making bindings a first class citizen part of development of the core. maybe this will fill in the gaps others have tried to fill before?

We may have come up with an alternative for bindings - at least for EFL, where we now generate the C API from an IDL that expresses classes, inheritance, events (signals/slots), etc. so our C API is pushed out by code gen tools and we just fill in the functions, and right now we support automatically generating C++, JS and LuaJIT bindings out of the box whenever you type "make" on the toolkit. We're going for "full bindings with zero maintenance overhead EXCEPT for fixing bugs in the generators or the initial work for adding a new language binding tool". At least the plan is to have language bindings "first class citizens" all coming out of core development (with yes, the core still in C - that's how we roll). Our cross-platform support hasn't been great and originally it was never intended/planned, but now we do port to Windows, Mac and Linux (X11 + Wayland), other Unixen... sure the ports need more work/maintenance and to be made easier and less prone to breaking, and we don't have iOS, android or Windows Phone ports (and no obscure OS's like Symbian, QNX etc.), so that's something to fix, but we're shifting design to push portability first and foremost and that allows for OS ports, so maybe this will pan out. There are Python bindings waiting int he wings that will come in once we're done with our interfaces work and the core OO layer is stable (not changing/breaking), so that language will get added. given the range of languages above and Python I think that means that adding more languages shouldn't be hard as most core concepts have been covered. Just FYI on "pick up favorite language and write cross-platform app".