Tell you more: you could also just run code to do things like change variables in the immediate window while execution was paused, so e.g that example where you want to re-run some loop: first you drag the PC arrow back to above the loop as GP already described, then in the immediate window you can just run things like e.g:

  someVariable="initial value"

then you can just step through the code or resume execution.

I used to use it a LOT for handling edge cases on long-running, one-off things: run the code until it hits an error, fix the error by doing some stuff in the immediate window, resume the loop without re-processing the 100K items you've already processed.

The destruction of VB with no upgrade path (the advice was to "just" rewrite your perfectly-functional 100KLOC codebase) is what pushed me away from MS, first to delphi and then to FOSS. But that VB6 debugger was IMO probably the best thing MS has ever done.

I wish I was kidding.

...But has it occurred to you that by putting this online and publicising it, you're effectively daring this lunatic with nuclear codes to actually go through with his threats? I for one am relieved every time he "chickens out".

  > Even with 8 GB, the difference between tycat (assuming it needs no memory at all) and VLC is then about 1% of the machine's capacity.

  > A useful baseline seems to be the actual Linux terminal. It can do 16 colors. Unfortunately, it doesn't even support emojis, though.

  > I ask myself since years: Does this terminal still switch to an actual text mode, or does the text get rendered in a framebuffer by the OS.

  > And even more so all the applications that I know that I could run inside it.

  > Again, I'm always open for something exciting.

  > for all the comfort I get back,

  > But yeah, my basic point was not actually to evangelize for Dolphin or VLC or any particular app.

  > Well, how do "the kids" get their Git icons etc? As far as I can remember, they call it "Nerd Fonts".

Oh, I see: You said "[dolphin] even can render actual icons without a patched terminal font!"...

...you mean like terminology and other graphics-supporting terminals can? If they were using terminology or kitty, they wouldn't need to patch the nerd font icons into their terminal font - they could just display the icon they want.

So your point was to sarcastically suggest another actually-pretty-good use-case for the functionality you're arguing against. Got it.

  > But all I've tried are buggy sometimes in what glyph widths they report

  > If terminology does better in that regard, good news! Nice!

  > As an application developer, I still cannot assume that my users all have terminology, so it's still no solution

Or perhaps you should just make your application graphical, since you've said solves the problem you're having with emojis and repeatedly asserted that graphical software is inherently better.

Which of these is appropriate, i don't know, because you'd have to give more than zero detail for me to be able to tell.

Maybe when you're linking to more than zero detail you can also explain how it has anything to do with whether supporting graphics in terminals is a good idea.

  > it would be odd to just support a handful of formats. Any format should be supported, then. Furthermore, it shouldn't be just a static preview. I also want to navigate around there a bit then. [...] Hell, I basically want to just have Blender there.

Raster already pointed out, and you ignored, that actually it does support pdfs, and libreoffice already. Seems it just never occurred to me to try them. So you actually won't need to patch that in at all!

  > We all know this is oversimplified in so many ways... ;)

  > This was just about adding the video support (which was already implemented and just needed to be called), not for the graphics support in general, right? 

  > Also, the code isn't even my primary concern at all. Some "improvements" would be just a single line of code, and you'd definitely hate them.

  > But just the repetition doesn't make it sound more reasonable to me tbh

  > That might very much be my fault! 

  > Unfortunately, you didn't help me in that regard either so far.

  > Well, if you have a superior approach, which is quicker and more seamless, I'd definitely want us to see it using for everything!

  > It's probably just another three lines of code to make the mouse position available in pixel granularity. And then we can basically start porting everything into that new paradigm. Why should we then stick with the inferior one?

I'm sure the e folks will be happy to look at the patches you provide for this functionality you want.

I suspect there might be a bit of discussion about things like "is this desirable" and "does this break compatibility with existing things" because this is a bizarro thing that you've invented out of nowhere based on nothing anybody said anywhere ever. But I'm sure they'll be happy to discuss it once you submit a patch.

  > I had hoped that, once someone starts to develop such a "new class of [...] applications", we could have a more modern foundation for it than ttys.

  > three or four file formats (or whatever EFL supports)

  > Technically, the application that runs your terminal _is_ a GUI application. I'm not aware of any terminal-based X11 emulators. That's just what I meant. Not more, not less.

As for "terminal-based X11 emulators:, there's a fairly prominent one you might have heard of, it's called xorg. If you try to run 'startx' inside an X session you'll have problems.

  > Ahh, you're also one of the authors of some parts of that software stack?

  > Either way, no I don't expect anything

By doing so, you're saying that people who write software that supports these graphical protocols (or maybe the authors of the terminals? It's unclear who you expected to do this for you) should jump through huge, unnecessary hoops just so that you can run their software (that you claim you don't want to run), rather than you..........simply running their software in the environment it requires.

  > I mean "instantly" in a practical meaning. You don't have to explain me once more that it can't be exactly 0 sec in a scientific meaning

That's a pretty great metaphor for your entire line of argumentation.

I would respond to the rest - there's a million things there that I'd love to dissect, e.g the admission that you haven't even tried the thing you're so against - but why would I bother? When you say things, you mean things that aren't the thing you said. Case closed.

export SDL_VIDEODRIVER=aalib

unfortunately it's only SDL1, though

  > 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

  > it's there while I'm releasing the Enter key

  > And before you start taking into account that a lot of gui software is just poorly written trash seemingly written by morons under the CADT model (Hi, gnome!).
  
  We can definitely agree here!!! :)

  > Better than reinventing a whole new kind of terminal applications which aren't actual terminal applications, 

Why are they not actual terminal applications? What terminal functionality do they lack? Please provide excruciating technical detail on this subject about which you know nothing.

  > but only work in an environment emulated by the very thing they want to replace.

For the umpteenth time, who said anything about replacing guis? I have repeatedly stated that they have their uses and are the best option for a bunch of things.

  > The same morons will come and screw up with all kinds of things there again, once that'd get more momentum. But now, since they also have to maintain EFL plugins or other graphical-to-terminal translations for their apps and file formats, they will even screw up heavier.

EFL plugins? Graphical to terminal translations? What are you talking about? It's almost like you don't understand the technology and have invented some fantasy architecture for all this stuff which is nothing like the actual architecture that exists and has been described here and elsewhere.

  > On an average day, I open a Dolphin window maybe once or twice... Often not even once (e.g. I just open my IDE and stay there, or the browser, or a game, you name it). You don't need a new one for every operation! 

  > if your workflow is seriously superior, then be happy that EFL and all that exists and supports all the file formats that you want to preview, and be happy that it provides all the features you need. I'm happy with you then. I have the feeling that it's a very special workflow for a very special task at best, though.

  > And you type "xdg-open" while I can just press Enter (or double-click ^^)

  > Why should I constantly want previews of something, so often that I'd care about a second of waiting time once in preparation,

  > Couldn't you just leave it open then?! Yeah, you'll definitely have some reasons...

Have you ever left dolphin open for 160+ hours in a directory containing 80,000 mp3s? How'd that work out for you? How did it handle it? How much ram did it use? What was your system load like?

  > Sure you do! I know! Terminology is one of them. That's exactly the point.

  > For an actual (virtual)terminal, it would at least remotely make some sense to me. Because there it's not an option to just use a common X11/Wayland image viewer.

Let's say you do mean that: You still have no clue what you're talking about. For instance it's trivially easy to view an image or play a video with no graphical environment running*, as long as you have hardware that can do a framebuffer. Like, for example, every graphics card made in the last 30+ years. And if you have that hardware, then you can run terminology on it, too. As raster already mentioned and you failed to understand.

* (one of my machines is indeed set up to play video 24x7 and does not run a windowing system or graphical environment at all)

  > It's trying to make terminal apps graphical, right? 

If you think it might be, you might want to look into that. Ascribing motivations to inanimate objects seems like it might not be healthy.

  > And all that technical complexity is just there

You don't know. Because you don't understand how it works, and you've ignored the people who tried to tell you.

  > because you don't have to move your eyes to another window 

Please try re-reading my other responses and this time try to comprehend what I'm saying if you'd like to continue this discussion.

  > there are very basic image viewers without any features

So then, you're saying they don't open up a window? They don't decode jpeg?

I question the usefulness of this software. But I can't wait to see your list.

  > I've no idea why they should be slower than the EFL previewers

  >  I'd definitely dislike to see all that arriving in major desktop environments. And I'm still optimistic in that regard

  > If it does, at least there might be ways to integrate the Dolphin thumbnailers. :)

Are you saying that you wish lsix[6] existed? And that it worked in konsole? And that you wish you could use it right now with literally 3 seconds of effort to install it? Are you saying that, after typing a hundred thousand words railing against the inclusion of any graphical features in any terminal ever?

  > In some way that's exactly what I'm wondering about when people have terminal-centric workflows in an environment that could actually just do graphics.

I love how, after having the massive complexity of gui applications explained to you, you just brush that off and say "just do graphics". That's pretty good trolling right there.

  > In particular when they then start to patch graphics support inside their terminals

[1] https://en.wikipedia.org/wiki/Sixel

[2] https://bugs.kde.org/show_bug.cgi?id=391781

[3] https://github.com/hpjansson/chafa/issues/78

[4] https://invisible-island.net/xterm/xterm.log.html#xterm_359

[5] https://man.archlinux.org/man/extra/xscreensaver/phosphor.6....

[6] https://github.com/hackerb9/lsix

  > But how often do I spontaneously need previews of something?

  > can it show me the TOC of some pdf and allows me to navigate to some chapter?

  > Well, there seem to be some use cases... Obviously... 

  > I still cannot imagine how they look like, though.

  > The performance was always good enough to be much faster than I am.

  > Before we now start to shoehorn graphical functionality into terminals, which we then only can use in graphical environments anyways, 

  > shouldn't we better just improve the graphical apps? 

  > There is no inherent reason for them to be any worse than your terminal apps (that are eventually hosted by just an ordinary graphical app).

  > About your list what Dolphin needs to do but terminal apps don't: Yes, sure. A lot is going on. In the background. I don't have to wait for it to generate thumbnails. 

  > It's not bash, which completely freezes then, e.g. when the network drive has a slow day, and I blatantly pressed Tab.

  > At least around 3000 files

  > I would avoid having so many files in a single directory. 

My music directory contains over 80,000 files. Try opening that in dolphin, you'll learn the meaning of "slow".

> I instantly see it listing the files, and it felt finished instantly, and i was able to scroll around. No waiting time that would have blocked me.

No, you don't "instantly" see it listing files, because it has to open a window first, which you've already said takes ~800ms. You're just not aware of the wait time because you've conditioned yourself to accept constant context switches and thumb-twiddling in your slow DE.

But just as an experiment, why don't you "instantly" select the file named zcat.

  > BTW: All the thumbnail stuff is done on demand, as soon as you scroll down.

  > And finally: You can just turn it off! ;)

  > Counting the files, and determining which application is associated with a file type, are quite cheap operations

Someone has never looked at a directory with subdirectories containing 100K files or more in a graphical file manager.

Someone has never looked at his disk usage while that happens.

  > But that's not because a terminal is the superior environment (how could it be if you just emulate it with the "bad" one). 

"emulate it with the 'bad' one?" What are you talking about? Who said guis were bad? When?

  > If all that 'modern' (win98) Dolphin magic is too slow, there are probably more lightweight alternatives that are still graphical.

I look forward to seeing your list of graphical file managers that are faster (or even within an order of magnitude as fast as) ls. Please be exhaustive, I want to try them all!

  > I still don't see the point in patching graphical features into something text-based, which you then need to run in an actual graphical environment

...Is your complaint here that you can't run these graphical terminal programs without having some sort of graphical environment running? i.e that it won't run on an actual text-only dumb terminal?

When was the last time you used a terminal in an environment where you didn't have hardware for graphics support?

And let's say you're one of the seven people on earth who does use a text-only dumb terminal daily: When did anybody advocate phasing out CLI software that doesn't use graphics features? How do you know that a bunch of this software with graphics support can't fall back to non-graphical options in non-graphical terminals? (hint: many/most can)

By the way, a bunch of actual "text-only" dumb terminals have had graphics support since the 1980s [1], and konsole has supported graphics for at least 5 years [2], and since 2022 it has supported the kitty graphics protocol [3]. Of course I'm sure you knew none of this because it took me >0 seconds of searching to look up the konsole support. I'm also sure this means konsole is broken and doesn't work, and the graphics support that's been there without your knowledge for half a decade has probably caused a bunch of bugs that you've been having trouble with, so I guess you should probably change terminals. Maybe to xterm... oh wait that's had sixel support for 6 years [4].

Here you go: phosphor [5]. I'm 90% sure this doesn't support graphics. And As a bonus, you'll be thrilled to know that it also doesn't support colour!

  > let's today start porting all our graphical apps into that E terminal thing

  > A terminal application that you run in an emulator, which is just some graphical application, cannot fundamentally be faster than just directly running graphical applications without that indirection, right? That would make no sense at all...

  > I played more with command.com than with the actual games installed, I suspect... My friends played NES, while I tried to hack custom program launchers as .bat files

editing .bat files, huh? And then you thought windows 3 was good and never went back to a terminal.

So, another way to say it would be that you don't know how to use a modern unix terminal - which is what I mean when I say "terminal", because dos was always a toy OS.

  > Even they made use of the 16 colors (or 8?!)

  > Sure, command.com was probably quicker than Windows File Manager, strictly speaking

  > But all that happens so quickly nowadays, in terms of wall clock time, that I really doubt the practical relevance. 

  > A "hello world" app in either Qt or GTK starts instantly on my machine. No waiting time that a human being could recognize. I press Enter, and it's there while I'm releasing the Enter key.

2. This is a false and contrived example - a "hello world" program is intentionally extremely minimal and explicitly does not involve initialising a complex interface - it's literally a single control - how many "hello world" programs do you use on a daily basis for productivity? Please link me to a "hello world" program that can preview video for me, and that starts up instantly.

  > I don't expect anything from anybody

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

  >  (or sth like that?!)

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

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.

  > 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

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

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

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

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

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

  > 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

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

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

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

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

  > Every format that someone now wants to handle on terminal, needs to be supported by the EFL library?! Does it support LO spreadsheets? PDFs?

But if you want to be able to preview libreoffice spreadsheets or PDFs in terminology - and also incidentally and for free every other EFL project which uses that control - I'm sure they'd be happy to look at your pull request.

  > And now I want to switch away from LO to some very new office tools, and I cannot, because EFL doesn't support it yet?

  > And all that just in order to show some previews in a terminal emulator instead of the graphical environment around it that is perfectly capable to do so since half a century? Where all the applications already exist?

The graphical environment might be able to do the same job, but as I've pointed out time and time again, it can't do it nearly as quickly or as fluidly when I'm already working in a terminal. We've been over this ad nauseum, but I'll just point out for the 30,000th time that all the ways you talk about involve opening up some other, slower program and switching away from the teminal. Which is a less seamless experience than just viewing the thing right there in the terminal. I don't know how I can state it any more clearly.

Did I say "editing the thing" or "working with the thing"? No, no I didn't say that. Because I didn't mean "Editing" or "working with".

  > Fine. Just replace tycat with EFL in what I wrote before

  > But it's artificial. It solves a problem that just doesn't exist at all, and it doesn't actually improve anything, as long as it's not universally supported (at least in an actual Linux virtual terminal outside of X11/Wayland).

  > But why are you trying to improve the horse riding experience, if you actually have a car that is just artificially stripped down to feel like a horse? Just use the car as a car instead! ;)

  > What context switch are you talking about

  > Why can't the same folks not improve keyboard support in e.g. VLC? 

  > I would be surprised if VLC is worse in that regard than some terminal thingy

(btw, off-subject, but there are a couple of really great terminal-based media players. And I can pretty much guarantee their keyboard controls are superior to vlc. But I'm not sure because I don't really try to keyboard control VLC. Because I don't have to. Because I don't have to launch it to preview a media file)

> You fire up a new tycat instance instead. Here VLC takes, idk, 500ms?!

I just fired up VLC. It took about 3 seconds (that's 3000ms, but what's 600% between friends?) from launch to a window being visible. According to htop, that empty VLC window with no file opened used up about 100Mb of my memory.

conversely:

  $ time tycat /path/to/some_video.mp4
  real 0m0.142s
  user 0m0.117s
  sys0m0.043s

  > What's the difference? 

  > Yeah, make them universally work on any virtual terminals, and then it'd be at least an interesting discussion

Why do you expect me to care what terminal you're using? Do you think I write software in the hope that you in particular will use it? If you want to use worse software and not be supported by my terminology-specific stuff, be my guest.

  > As long as I need some E terminal, or a particular terminal that is "popular with the kids"

  > I really don't see at all why this is a good idea to spend any efforts for

Just remember to go and set your terminal to not support colour - after all it's not supported by any of those amber-screens! And while you're at it you better disable those extended unicode characters and switch back to baudot code. You can probably find a punchcard reader if you look around.

  > Just use the car as a car, instead of disabling the engine, pretending it to be a horse, and then find clever ways to make it feel more like a car again. It already _is_ a car. Don't make up artificial restrictions that do not exist, just in order to find mediocre ways to somehow patch parts of them away a bit.

No.

Your terminal emulator is a horse. A tired, old horse. That's gray and boring and totally uninteresting. So uninteresting that you haven't even noticed it's got an infection in its foot.

Meanwhile, my terminal emulator is a horse with cybernetic legs and wings that allow it to break the sound barrier, and also fly. And if I keep messing around a bit I might be able to get it to do even more cool stuff. Who knows what exactly? Will all of it be groundbreaking and super useful immediately? Maybe not. But it'll be fun and interesting and it can already do shit you never even imagined was possible and can't even comprehend when I tell you about it, insisting on asking backwards questions like "well yeah but if it's flying then what happens with the horseshoes?"

Have fun with your old nag!

  > Give Dolphin a chance!

"patched terminal font"?? What the fuck are you talking about?? It's almost like you don't understand what you're talking about.

  > Bonus: It can display emojis

  > because the actual glyph width differs from what the "API" (i.e. dancing some escape sequences and somehow intercept the answers from somewhere) tells you.

Argle bargle snerf blu carn delg bling blong blu barg sneh bork mert.

  > Why should graphical applications be fundamentally worse (e.g. in terms of keyboard support) than terminal applications when terminal emulators are a graphical application?

> Yes. All these 800ms!

For you. This one time that you tested. It took almost an entire second. Or, another way you could say that would be "longer than it takes terminology to pop up a preview".

> Yeah, well, technically, of course. It just never felt like "waiting". It's a matter of milliseconds

Well then either dolphin is by some miracle orders of magnitude faster than any file browser I have ever seen (which includes earlier versions of dolphin that presumably have fewer features than the current one), or you're not viewing folders containing many files. Or maybe you just have the fastest and most powerful computer ever built. Or perhaps you just don't have any expectation of a performant UI and consider twiddling your thumbs to be no big deal.

> terminal applications don't need to enumerate directories when they deal with it? How does that work?

They do need to enumerate files, obviously, but they don't need to - for each and every file and subdirectory:

1. determine the mimetype for the tile, which may involve actually opening and reading the file

2. look up that mimetype in their "mime type -> friendly description" table

3. look up the default application that needs to be opened if you double-click on said file based on that mimetype

4. if the mimetype is "video" or "image", look in their cache for a thumbnail for the file, and if that doesn't exist fire up a thumbnailer to generate one, which likely involves opening and reading in the entire file.

6. load the aforementioned thumbnail into memory and display it in the appropriate place

7. as previously mentioned, enumerate and count the number of items in directories

8. I'm sure a bunch of other similar things that I can't even be bothered trying to remember right now.

  > Even if you just press "tab" in your shell, it will probably do exactly that, no? 

  > I really don't see why terminal applications should be fundamentally faster than graphical applications in that regard

Seems to me like maybe you've never used a terminal program? Or perhaps you've never used a gui program? I'm not sure what to say to this. I don't think I've ever seen a piece of GUI software which comes close to the speed of its terminal-based equivalent. I'll grant you there are outliers, but those are rare and every single example I can think of doesn't use a GUI toolkit.

There are a few factors at play here. One big one (maybe the biggest?) is simply the complexity of the interface: Terminal emulators are built and optimised to display a whole bunch of text very quickly. They have one job: display text. GUIs and GUI toolkits, on the other hand, are huge complex libraries with a large number of different controls that they need to draw in the right place, do layout, have to deal with mouse interaction and event systems and the windowing system, deal with weird input methods and accessibility, etc etc etc etc etc etc etc. They're orders of magnitude more complex just in their interfaces. And that's before you start doing things like loading icons for every little button you're displaying and thumbnailing every media file in a directory so that you can load it as a pretty icon in your file manager. And before you start taking into account that a lot of gui software is just poorly written trash seemingly written by morons under the CADT model (Hi, gnome!).

GUIs are fine, and the best option for a bunch of things. But they're much MUCH less efficient than terminal-based programs.

I don't know what else to say. Go talk to every single GUI application author ever, I guess?

  > your terminal emulator is a graphical application, right?

  > If you know the file name starts with "cat_s", then you can also find it this way in Dolphin.

Meanwhile, like I said, I'll already be half way through previewing the video, and my workflow won't involve switching to some worse program.

  > There are corner cases where I really search in a trickier, more dynamic way. Maybe with "find". Or five lines of Python scripting. But not hundred times a day. Definitely it's not worth rewriting every application now as a terminal app (that tries to be a graphical app via niche-in-niche technologies).

  > Yes, that's one of the things that I feel so spooky with that approach.

  > It cannot work... 

  > Maybe for a handful of persons that constantly search for jpeg/png/mpeg files, in bulk mode, and need quick previews.

And it's a better experience in literally every way imaginable than firing up fucking dolphin and waiting for three ice ages and also an image/video viewer.