TTE: Terminal Text Effects
251–260 of 279 posts
Re: TTE: Terminal Text Effects
#252Re: TTE: Terminal Text Effects
#253Re: TTE: Terminal Text Effects
#254Re: TTE: Terminal Text Effects
#255I freaking love this library! It reminds me of a time that I don't even know happened when computers seemed like a scifi possibility come true. So happy to see it on the front page. One of the coolest things is not just the ability to pipe cat outputs into it, but that it doubles up as a python library- next time you're making a throw away CLI with print outs and prompts, why not make it insanely jazzy?
It's fun for silly stuff, but I've definitely been on enough slow links that I wouldn't put it in a serious tool. EDIT: Don't get me wrong, I think it's really cool, but I wouldn't use it as a universal hammer.
Re: TTE: Terminal Text Effects
#256I’ve no idea what I would really use this for, and yet it’s one of the coolest things I’ve ever seen. My eyes are forever improved from having seen this.
Re: TTE: Terminal Text Effects
#257Very cool! But I’m just a bit sad that this is “just” a set of effects implemented on top of the same old standard ANSI escape codes as primitives. I’ve been waiting for one or more terminal emulators to get together and add some ridiculous new escape codes, such that animated effects (or things like collapsible sections, font size, “form-input-ness” and “form-button-ness” ala 3270, etc) all get treated as part of th…
> (There’s precisely one thing like this I’m aware of terminal emulators adding in recent memory: clickable links, ca. six years ago.) And they are often disabled by default, as a potential security risk. We don't get to have fun things, do we? (also worth read: CVE-2003-0063, abusing escape seq is unfortunately a valid concern against adding more stuff). On the other hand, more and more emulators are adding support…
Well, that and a clickable link would conflict with mouse reporting if both were active at once.
Given that mouse reporting exists, and "has precedence" due to its age, I think iTerm's choice — to style the anchor-SGR text either way, but to only make them actually act like links rather than text if you hold a modifier key — is the only "correct" behavior for rendering anchor-SGR text, regardless of security concerns.
But that really wouldn't be true for most other potential novel graphical-rendition "styles." Anything that's non-interactive could certainly be on by default.
Re: TTE: Terminal Text Effects
#258I love terminals, but I have to say, I kind of hate this sort of thing? Where you need at least 256 colors, GPU acceleration, and 240 columns x 80 lines? At that point it's just a curiosity, anywhere you could do that in a terminal you could do it easier and better in a graphical window. I want my terminal apps to actually still work in an 80x24 monochrome VT220 at 19200 baud. I want them to use termcap instead of ha…
I wonder if there is a similar, more lightweight library that has cool effects that work with the minimum specs you've specified?
The demo, BB, should be more like it. https://www.youtube.com/watch?v=9ukhOAUseKY
AAlib, as far as I know, works in VT220.
Re: TTE: Terminal Text Effects
#259Oh dear, why would any terminal user want that?
https://chrisbuilds.github.io/terminaltexteffects/img/effect...
Re: TTE: Terminal Text Effects
#260Earlier quoted context omitted.
It's fun for silly stuff, but I've definitely been on enough slow links that I wouldn't put it in a serious tool. EDIT: Don't get me wrong, I think it's really cool, but I wouldn't use it as a universal hammer.
On the contrary, I am currently scaffolding out the template projects for a new system at $DAYJOB and I'm seriously considering putting it in the CLI tool template. On the one hand, these tools are going to be used for Serious Business™ but on the other hand... I owe it to 14 year old me. I'll probably add something to allow disabling it with a flag file that can be created with the tool or manually. ¯\_(ツ)_/¯