421–430 of 491 posts
Earlier quoted context omitted.
> A non-GPL licensed cross-platform clipboard library, (That is, that project is GPL licensed, and they didn't want that)
Oh, I thought "clipboard" was dual licensed to GPL and/or Apache 2.0. My bad. I hadn't seen that the x11 related code was purely GPL 2.0. Thanks for your help, Steve !
I really disagree with the authors definition of minimal. Terminal emulators have such a minimal user interface as it is it's a bit boggling that I have to make the case for the following "bloat" that other terminal emulators have. I need scrollback because I do occasionally pick up my mouse and grab things that have scrolled off the screen. Tmux doesn't help with this but maybe there is some magic that I don't know…
Earlier quoted context omitted.
"... generally infinite willingness to accept web apps..." Interesting. I stay in textmode. Hence I do not need an emulator. If I need graphics I access the files over VLAN from another computer designed for mindless consumption of graphics, like the locked-down ones they sell today with touchscreens, etc. My understanding is that emulators like xterm can redraw the screen faster than VGA. I remember this can make te…
The Web is two things. First, it's the promise that a certain runtime with a specific minimum set of capabilities is available almost anywhere. Secondly, it's a staggeringly-huge installed base of stuff written for that runtime. I don't think there's anything out there in the that matches the volume of deployed HTML, CSS and JS in the wild. The horribly sad part is that HTML, CSS and JS are a gigantic Rube Goldberg i…
And that's what HERE Maps does best, without needing massive storage.
I am using iTerm2 on a maxed-out MBP 15 Retina quad core and Xshell on a $150 Asus Cherry Trail netbook. You won't believe it but Xshell on the crappy netbook feels light-years faster and more responsive than iTerm2 on the MBP.
Wondering how Alacritty will perform, looking forward.
Earlier quoted context omitted.
keyboard autorepeat doesn't have anything to do with the terminal emulator (or I would be surprised). There's an X11 setting, try "xset r rate ", e.g. "xset r rate 170 30".
The timing of the input itself doesn't vary, but the timing of the visual feedback does. I like a fast 60Hz autorepeat, and I rely on visual feedback for precise positioning (I find this has lower cognitive load than Vim style character/word/line/etc counting). If the terminal is displaying at 40fps then some separate inputs will be merged and displayed at the same time. And if you like 30Hz autorepeat, instead of co…
But I acknowledge there's a general problem with the slow screen refresh rates we have. What are people doing if they want an ergonomic FPS shooter, or a video decoder that must decode videos with arbitrary video and audio rates? Probably ignore the problem and drop a frame here and there.
It sounds like a fun project, but I don't really understand what performance issues this solves? I don't think I've ever had an issue with slow terminal rendering using the default terminals on Ubuntu or Mac OS. What sort of applications do you run where it becomes an issue? On the other hand, something like mosh [1] seems like it could be really useful on slow network connections. But that's not about rendering fast…
Earlier quoted context omitted.
>That's company policy Yes. I was just pointing out that regardless of modification/distribution/whatever, bigco policy is to not allow ANY AGPL code within a 10 mile radius of any computer owned by said company. The author(s) are free to use AGPL, but there are significant downsides if they care about adoption.
They care about the freedom of software users, not weird corporate policies. Non-adoption by non-respecters of freedom isn't a downside.
I'm all for the moral stance, but moral purity in a vacuum is essentially irrelevant. Effective morality is about impact on the world. A morality that's only about the good feelings of the purist is sterile self-indulgence.
Earlier quoted context omitted.
That only addresses part of the reason for the policy. Please, you have to be aware the legal world and companies is very complicated, and smart people spend a lot of time analyzing this.
While licenses are not simple, AGPL is specifically meant to "counter" closed source services based on AGPL code. So unless you want to offer Alacritty-as-a-Service, you should be just fine with the license.
At a large company, the stakes get large in two ways. One is that all the numbers are just larger. But more important is that an individual decision maker's career success can become dependent on a relatively small number of things. E.g., if a lawyer approves a license that should be fine but actually isn't, that could substantially harm career prospects. It still may be a small problem overall for a major company, but if it means somebody gets fired, those are pretty big stakes.
Earlier quoted context omitted.
Thank you for the thoughtful comment. There's been a lot more pushback on the scrolling decision than I had anticipated. It's not something I want in my terminal, but it seems that a simple feature like this is essential for others. Perhaps I should reconsider. I worry that a "simple" feature like this may be overly complex internally. Performance with large amounts of output is also a concern. At least if we were to…
I've already tested alacrity and it's super easy to configure, the only thing stopping me from making the move is scrollback. I understand not adding tabs or a GUI config: I use my WM to do tabbing on linux even though my terminal implements tabs. However scrollback is an absolute must for me. If you implemented scrollback I would be able to switch terminals from terminology (at first glance).
Earlier quoted context omitted.
> Features like ... are better provided by a terminal multiplexer I would strongly argue that this thinking is putting the cart before the horse. I don't use tmux, nor do I want to (though occasionally I have to use screen as a hack to keep programs running on remote servers, and I hate every second of it). Solutions like tmux arguably exist because terminals have poor UIs, and the terminal protocol is too weak to fo…
Thank you for the thoughtful comment. There's been a lot more pushback on the scrolling decision than I had anticipated. It's not something I want in my terminal, but it seems that a simple feature like this is essential for others. Perhaps I should reconsider. I worry that a "simple" feature like this may be overly complex internally. Performance with large amounts of output is also a concern. At least if we were to…
Even if tmux is in theory a better solution, it's not such a radically better solution that the benefits outweigh the switching cost. Terminals with scrollback have been around at least 30 years at this point [1], and scrollback is by far the majority use mode. You're asking 95%+ of your potential userbase to spend a bunch of time retraining themselves for little or no benefit.
You're also up against a variant of Jakob's law:
https://www.nngroup.com/articles/end-of-web-design/
Scrolling down and back is a key part of the web user experience. Even if every terminal emulator got rid of scrollback, most of your users would still have scrolling back baked into their brains. When they want to see something that just scrolled past, they are going to do what they do in a web browser, which is to look for a scroll bar, hit a scrolling key, or perform a scrolling gesture.
That's not to say you shouldn't try radical things. But if you want user adoption, you have to make sure the benefits you offer are very much larger than the costs you impose. So radically different UI can't be about as good as the existing one; it has to be radically better.
[1] And of course terminals are made to emulate teletype machines, which had infinite scrollback to begin with.