[rasterman]

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.

[pino83]

In terms of wall clock time, on my system, it costs nothing. I can start a "Hello World" application based on Qt or GTK, and the window is there while I'm still releasing the Enter key. Technically, sure, a lot of things happen... But it's not happening on a P-90 anymore... :) BTW: My machine wasn't particularly strong or expensive either, when I bought it 6 years ago. ;)

When I read (in your other reply) that you are trying "soften the boundaries between workflows and bring some features of of workflow into another", well, that probably sounds nice... I just get a headache tbh...

I'm sure it was fun and a big achievement to implement that. And there obviously is a fan-base for that. So where am I... :)

[em-bee]

I just get a headache tbh

why?

it is effectively a keyboard driven GUI. you potentially get the full power of the commandline to do your actions without giving up a graphical view of your system.

i wrote in my own comment that i want to go even further and integrate a full terminal: https://news.ycombinator.com/item?id=47801068

ttyphoon on the other hand is a terminal project that approaches this from the other side, getting even more graphics and structured data support into the terminal: https://github.com/lmorg/ttyphoon

both have a similar goal: get away from the old limitations that terminals have but keep the power they offer.

[pino83]

Just quickly, because I have to leave:

I actually do somewhat like the paradigm, from a user perspective. If done well, why not, could be cool... If done very well, it could be very very cool...

But please let's not invent these new kinds of applications based on terminal tech. I still don't see why one would go this pointless detour, instead of just start as a graphical application, tech-wise.

[em-bee]

let's not invent these new kinds of applications based on terminal tech

i agree with that. the terminal with its escape sequences needs to go away, it is old and limited. however the commandline will not go away. nor should we give up text based applications. both are too powerful for that.

so what we want is a modernization of the commandline. this is happening with alternative shells, but also with ttyphoon and other projects. and efm brings the power of the commandline to the gui directly. i'd like to see more projects like that.

i see a large spectrum here. some projects try small incremental changes (sixels for example, a wierd concept, and i ask myself why, but ok). others try to bring more powerful datastructures to the commandline. good, because those are terminal independent. on the GUI side there have been various attempts to send objects between applications already for decades. none of them achieved broad acceptance. there is a lot of potential still. a GUI for data pipes for example would be nice. there is one for the terminal. tmux is a terminal manager, it is gaining GUI support. doesn't get rid of the terminal, but modernizes it. small incremental steps. 10 years ago i would not even have believed that alternative shells would gain acceptance. but they are. half a dozen projects that break bash compatibility and are gaining popularity.

[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.