I don't understand your arguments.

Whatever desktop environment you're referring to probably uses some of the same underlying third-party libraries for file format support as EFL, so what's the difference?

Why would being able to display graphical elements in my terminal program only be useful if it were supported on the Linux virtual console or some other terminal program I don't use?

Why would you expect "the same folks" to stop working on projects they find interesting or useful in favor of fixing your problems with entirely different applications?

▲ pino83 2 days ago | parent [-]

At first, I don't expect anything from anybody; that's just way beyond my privileges, unfortunately... :D I can only comment things and add my 2 ct.

All the terminal tech ecosystem is already somewhat beyond it's actual capabilities. You see that when you e.g. use tmux or screen. Or when you just have some emojis which are actually wider than the API tells you and your alignment goes off the rails. Or that conceptual discrepancy between the 16 colors support, where users can typically decide freely how exactly each color should look like (up to the point of having the background in white instead of black), and then the additional 256-color support, which adds 240 more colors (or sth like that?!), but with really fixed color values...

Everything is just a historically grown mess. And I've just mentioned a few points that came to my mind spontaneously, and there are probably a lot of further problems that I've never even heard about.

With that in mind, when I hear about the idea of hacking full graphics support into that, as a professional software developer my first instinct is to understand whether that's really worth the trouble. And what the rationale behind is. And whether it actually makes sense, from an architecture perspective if you want to call it this way. And all the arguments that I've read here made no sense to me at all. It feels more like a cult when I talk to terminal-centric users.

I don't have any privileges to decide for any involved project, though. If e.g. Konsole starts supporting that tomorrow, well, I'd doubt this was a useful thing, but then that's what it is. I could then only hope that they didn't break other things.

As a Linux user since 20 years, my experience tells me that all these things always break something else.

And then it's basically for people who say that basic image viewers start too slow for them. Either that's trivially fixable (and then we'd all be better off doing _that_ instead!), or just an illusion/cult, or the EFL previews will not be faster. There is just no way they could be faster. A basic graphical image viewer would do the same thing, just without all these indirection, translation to escape sequences, interpreting them again, etc.

Similar for the matters of proper keyboard support.

▲ rasterman a day ago | parent | next [-]

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 3 hours ago \| parent [-]
		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... :)

▲ antisol a day ago | parent | prev [-]

  > I don't expect anything from anybody

Aah, I see. So then I guess that wasn't a demand that people who have their own perfectly functional terminals with graphics support that they've been using for years and are perfectly happy with patch graphics functionality into every other terminal in existence just in case you might happen to try to use a terminal program that requires graphics support. I guess I must have misunderstood. Silly me.

  > can only comment things and add my 2 ct.

Perhaps it would be wise to do some basic reading and perhaps even testing to understand some of the basics about how the technology works before making comments about them. This is an excellent method to not come across as totally uninformed and ignorant.

  > All the terminal tech ecosystem is already somewhat beyond it's actual capabilities. You see that when you e.g. use tmux or screen

???

  > Or when you just have some emojis which are actually wider than the API tells you and your alignment goes off the rail

????

My terminal displays emojis just fine and they align just fine as far as I know. Have you considered trying software that isn't shit? Or filing a bug report containing more than zero detail on the issue?

  > Or that conceptual discrepancy between the 16 colors support, where users can typically decide freely how exactly each color should look like

This is actually extremely straightforward if you spend 5 minutes understanding how it works, particularly with regards to backwards compatibility with terminals that don't support it. Which are few - it's incredibly well-supported in almost all terminals. I don't know what you're talking about...

  >  (or sth like that?!)

...and neither do you.

Damn, your nose is going to get right out of joint if you ever learn about RGB terminal colours. Shhh, nobody tell him!

  > Everything is just a historically grown mess

Indeed! Finally something we agree on!

And people working to improve terminals with efforts like terminology and kitty are trying to do what they can to address some of these issues without breaking anything. Which is hard. It's really quite an admirable effort worthy of respect.

But first you'd need to understand what they're doing.

   > there are probably a lot of further problems that I've never even heard about.

I have no doubt that there's lots that you haven't heard about

  > when I hear about the idea of hacking full graphics support into that, as a professional software developer my first instinct is to understand whether that's really worth the trouble

Ooh, appeal to authority. I'm so impressed.

Perhaps, as "a professional software developer", you should take the time to understand the tech that you're talking about. Doing so will help you form an informed opinion and will help you to avoid wasting everyone's time reading ignorant, uninformed, assumption-laden nonsense.

  > And what the rationale behind is

Excellent! So go back and try actually reading my previous posts. That'll help a lot with this.

  > And whether it actually makes sense, from an architecture perspective

Excellent! So go and read the docs and form an actual opinion that isn't "I don't like the sound of this herp derp". I'm sure once it's not immediately obvious that you have no clue what you're talking about and have spent zero seconds attempting to understand the architecture, people will be happy to discuss your pull requests making all the revolutionary improvements that I'm sure you'll make.

  > And all the arguments that I've read here made no sense to me at all

Then maybe you should try actually reading them

  > It feels more like a cult when I talk to terminal-centric users.

Aah! And the penny drops! You don't know how to use the terminal and don't understand its benefits. So of course you don't understand the arguments I've repeatedly outlined for why this functionality is desirable.

  > As a Linux user since 20 years, my experience tells me that all these things always break something else

Ooh, appeal to authority #2. I'm so impressed! Meanwhile I've been using linux since last century.

Enlighten me, then, o great software developer and 20-year Linux user: What does the graphics support in terminology / kitty break?

Maybe you should spend 5 minutes understanding how it works before you go making assumptions.

  > people who say that basic image viewers start too slow for them

You. Do. Not. Understand. My. Point. Because you don't understand how I operate. Because you don't know how to use a terminal.

  > Either that's trivially fixable (and then we'd all be better off doing _that_ instead!),

Please explain, in excruciating detail, exactly how you plan to "trivially" prevent the need to load in the qt library to get VLC to start and show its qt interface. I look forward to reading your technical paper.

  > or just an illusion/cult, or the EFL previews will not be faster

I already provided you with hard timing data demonstrating that previewing videos in terminology is more than 90% faster than the way you'd do it. If you have something other than completely uninformed assumptions based on nothing at all to back up your claim that previewing in terminology is not faster, please present your data here.

But as I've alluded to repeatedly and you've completely ignored, speed is actually not the primary issue. It's the context change. It's that "taking my hand off the keyboard" thing. Even more, it's the "staying in the same application" thing. And it's also more than all those factors. It's a similar phenomenon to how I can't really explain to you just exactly how pipes are amazing and one of the most incredibly powerful paradigms you could ever learn. I can't really explain it to you properly because IMO the only way that it will really click in your head is in the moment that you really actually understand pipes, and to do that you have to actually learn and work with pipes.

You're just fixated on the speed because you don't understand the cost of the context change because you don't understand how terminal people work, because you don't know how to use a terminal and think that switching contexts constantly and twiddling your thumbs while GUIs initialise is normal and fine. And that's fine, if you want to work like a windows user. You do you, and more power to you. Just stay the fuck away from making suggestions about how terminals should or shouldn't work.

  > There is just no way they could be faster

I have already explained in excruciating detail some of the major reasons why they are. If you still don't understand, I'd suggest reading my previous responses where I explain that. Or, you know, doing some further reading to understand the technology you're talking about.

  > A basic graphical image viewer would do the same thing, just without all these indirection, translation to escape sequences, interpreting them again

Maybe you should spend 5 minutes reading and understanding the technology you're commenting about, so that you don't make wildly incorrect assumptions, and don't come off as totally ignorant and uninformed.

Who translates what exactly into escape sequences that you think is more expensive than loading up the gtk/qt/wx widget libraries and instantiating a new window?

  > Similar for the matters of proper keyboard support

Without some detail of what you're talking about this is just a non sequitur. Terminology works fine with my keyboard, as has...let me think... every terminal I've used in the last 30+ years.

Since we're doing non sequiturs, allow me to retort: Avatar 3 was shit.