is there support for any sort of 'guake' drop down terminal mode?
There are a few pointers for Linux solutions in the issue.
101–110 of 323 posts
is there support for any sort of 'guake' drop down terminal mode?
There are a few pointers for Linux solutions in the issue.
I've been using Kitty for a month now. I really like it. It's slightly less usable out of the box than iTerm 2. The default shortcuts are very counterintuitive (no CMD T for new tab or CMD W to close tab). But editing the preferences is straightforward. I prefer it to iTerm because it's so. Damn. Fast. It's the only software (besides Sublime) I run on my laptop that actually feels like it's using the 40 years of tran…
Have you managed to configure it to behave similar to iTerm 2 in terms of keyboard shortcuts? Would you please share your config? One thing is, I don't get its layout , is it possible to create a vertical/horizontal split like what (shift+)cmd+d does in iTerm 2?
Earlier quoted context omitted.
I thought macOS was already GPU accelerated with Quartz? And wouldn't Windows be doing something similar by now? The CPU is certainly not writing pixels directly out to VESA buffers in 2018, right?
Most Cocoa apps use the CPU backend of Core Graphics, which doesn't use the GPU for vector graphics rendering. (CG is usually what "Quartz" refers to, though the brand is so overloaded at this point that it's hard to make any general statements about it.) Cocoa apps do frequently use Core Animation for compositing surfaces together on GPU, though. Most of what terminals have to do is blitting of prerendered text bitm…
This also makes me weary of statements that criticize how e.g. windows does it wrong, “except in the current three years old version”.
Earlier quoted context omitted.
"Some people have asked why kitty does not perform better than terminal XXX in the test of sinking large amounts of data, such as catting a large text file. The answer is because this is not a goal for kitty. kitty deliberately throttles input parsing and output rendering to minimize resource usage while still being able to sink output faster than any real world program can produce it. Reducing CPU usage, and hence b…
That... doesn't make any sense.
EDIT/Whinging: Welp, scratch that, kitty requires an OS X one version higher than what apple will allow me to install. And while it is an older MBP from 2010, at least it's fast and reliable. AND it has the multitude of ports that I like. And the magsafe.
I'm sure I'm venting into an echo changer, but, here goes. Why won't Apple simply provide me (an option to buy) a modern solid mid-level 15" rMBP for under $2000. I bought mine for $1700 and it came with a $200 ipod as a gift (sold on eBay).
Give me that. A rMBP, with all the ports, plus the new USB-C. They could leave out some of the stuff that's pricy.
Ya, give me a new version of what I have, and will last at least another 8 years (fully supported by MacOS releases), and price it under $2000. That I would buy. When I replace this one, I'm just going to have to buy something to linux or Windows (probably both, realistically), since I've been priced out the product I would have normally purchased and recommended.
Terminal emulators have tabs/windows, tmux has tabs/windows, vim has tabs/windows. All with different keyboard shortcuts and semantics. I wish this were all unified into a single window/tab/keybinding model. That was easy to code against and write your own interactions for. I keep hoping I'll see a boundary-pushing project like Kitty do something new in this space.
Side note, the author's home page is an absolute relic from the past: https://kovidgoyal.net , including things like provisions for 56k modems, iframes, detection scripts for IE3 and AOL, and other gems. It even looks like he has his own pre-jquery compliance library written about 18 years ago: https://kovidgoyal.net/scripts/VisualDocumentAPI.js
Why render with the GPU? I don't think I've seen a visually slow terminal emulator since 2000 and barely even in the 1990's. Text rendering is basically just blitting cached glyph bitmaps into a buffer, and CPUs have been more than overly fast doing that for eons. And CPU rendering has none of the compatibility problems/quirks that GPUs have. I can fire up a Gnome Terminal onto an unaccelerated Vesa X11 display if my…