_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
(HTM) Visit Hacker News on the Web
COMMENT PAGE FOR:
(HTM) Linux When?
aorth wrote 3 hours 40 min ago:
This looks rad. An amazing engineering effort for such a niche problem.
As a Linux user who writes code, I'm excited, but I can't help
wondering: what is the business model of Zed Industries?
joshspankit wrote 5 hours 55 min ago:
The performance of their website got my attention.
People who care about those details and who optimize for fast are my
kind of people.
FullGarden_S wrote 11 hours 58 min ago:
> and we put a lot of effort into understanding macOS APIs to get to
120FPS
If its ultimately a text editor with dead plain UI, why not simply
stick to retained mode GUI and chill?
I don't know how much of disk space and ram this written in Rust® text
editor project demands to just build it but since its Rustâ¢,
achieving cross-platform will probably be several-folds more work than
it would be in C, I applaud the devs for their work.
I never tried Zed(yet) and keeping the support for vast programming
languages aside, I would like to check out how this editor handles
multiple workspaces and provide text editing features. I'm an Emacs guy
and I have a feeling that this is not for me because even if its fast,
it doesn't make me productive if I'm not using my emacs/vim key
bindings. I might be wrong.
jenadine wrote 10 hours 31 min ago:
> since its Rustâ¢, achieving cross-platform will probably be
several-folds more work than it would be in C,
Why would you think that?
Rust is a more expressive and powerful language than C. If anything,
I'd say it would be easier. Platform APIs are not all in C either.
FullGarden_S wrote 44 min ago:
> Why would you think that?
FFI? I don't recall stating Rust is less expressive than C, the
language looses its notorious "memory safe" feature as unsafe is
called often when performing low level sys calls.
> Platform APIs are not all in C either.
unless you are absolutely talking about web development, this is
not true at all.
tfeldmann wrote 12 hours 22 min ago:
Zed has quickly become my daily driver for mostly python and some rust
development. Awesome editor.
the_duke wrote 12 hours 37 min ago:
If you use Nix(OS), zed is already in nixpkgs-unstable: `nix run
nixpkgs#zed-editor`.
I found a few issues, but overall it already works quite well and is
very fast. It might even get me to give up on Neovim!
timvdalen wrote 13 hours 4 min ago:
From how they've been talking about Zed (on The Changelog, among other
places), I expected to be wowed on my first open of the application,
but the experience kind of fell flat for me. I might try it again when
they have some better onboarding, though!
NoraCodes wrote 13 hours 28 min ago:
One question I don't think this post answers - why not use `winit`?
mikaylamaki wrote 13 hours 15 min ago:
Simply put: historical artifact and we want to own the stack. Zed was
first created when these abstractions where a lot younger, and a text
editor needs certain features, like IME support, that weren't as
common back then. Further, owning the stack we're built on gives us
the flexibility to change the framework whenever and however we want,
which we value more than the additional work it takes to re-implement
things ourselves.
NoraCodes wrote 12 hours 31 min ago:
Makes sense, thank you for the thorough answer!
OptionX wrote 13 hours 31 min ago:
Still baffled by the idea of make a code editor not only single OS but
targeting mac.
gostsamo wrote 13 hours 42 min ago:
What is the accessibility story with Zed? I have a vague memory that
atom had none of it.
mikaylamaki wrote 13 hours 29 min ago:
Right now: mixed. We provide both user defined themes and theme
overrides that let people color-correct things as they need, we have
a strong cultural focus on keyboard accessibility for all UI
elements, you can increase or decrease the font size in the editor
and the UI, and we have strong support for IME on macOS and will be
extending that to Windows and Linux.
However, our accessibility to screen readers is non-existent. I have
ambitions to incorporate AccessKit but it's a bit of a project due to
the lack of a clear guide on how to implement it. That said, I
already made some progress based on the old egui PR and we should
have all the pieces we need once I have time to actually do it.
We also lack any way to tab through our UI elements to select each
piece in turn. This one I have yet to do any thinking on,
particularly as the tab key already does a lot of work in a code
editor. I'm sure there's prior art here, I just haven't looked at it
yet.
So, piecemeal and insufficient for many cases, usable for some
others. I'm very interested in improving this but we still have a lot
to do.
gostsamo wrote 12 hours 55 min ago:
Thanks, will keep an eye on the developments there.
A note, the tab key is not all that important. f6 for jumping the
different parts of the screen and the arrow keys for neighbouring
elements could be a good substitute for most cases. Add a few key
bindings and tabless is not an issue any more.
mikaylamaki wrote 12 hours 45 min ago:
That does seem more usable for this use case. I'll keep it in
mind, thank you!
keb_ wrote 13 hours 43 min ago:
I tried it out briefly, and it seems promising so far! Zed reminds me a
lot of Lite [1] and its community successor Lite-XL [2], which are also
"built like a videogame" using a custom renderer and ui engine. [1]
(HTM) [1]: https://github.com/rxi/lite
(HTM) [2]: https://github.com/lite-xl/lite-xl
forgotpwd16 wrote 13 hours 32 min ago:
>"built like a videogame"
A term coined Casey Muratori for this is immediate-mode GUIs or else
IMGUI programming[1]. Hence the name for the very popular Dear ImGui
project. GPUI used for Zed is mentioned as hybrid immediate and
retained mode UI framework[2].
[1] (fist post on his blog!)
[2]
(HTM) [1]: https://caseymuratori.com/blog_0001
(HTM) [2]: https://github.com/zed-industries/zed/tree/main/crates/gpui
adastra22 wrote 13 hours 43 min ago:
I had to click through three links just to find out what Zed is.
myaccountonhn wrote 13 hours 47 min ago:
I really appreciate how Zed tries to tailor make and ensure their app
looks and feels native on Linux.
One thing that scares me with it though is the lock in of the
multiplayer features. I can see it forcing me to use it and not my
preferred editor, because other people use Zed.
Would love it if we were not only platform independent but also editor
independent regardless of social pressure.
skohan wrote 13 hours 3 min ago:
I use Zed as a daily driver, and I haven't once used the
collaborative features
yencabulator wrote 8 hours 44 min ago:
$ grep -A 999 Disable .config/zed/settings.json
// Disable all genAI crap.
"features": {
"copilot": false,
},
"show_copilot_suggestions": false,
"assistant": {
"version": 1,
"enabled": false,
"button": false,
},
// Disable all "social coding" features.
"calls": {
"share_on_join": false,
},
"collaboration_panel": {
"button": false,
},
"chat_panel": {
"button": false,
},
"notification_panel": {
"button": false,
},
}
vetrom wrote 13 hours 30 min ago:
I am generally wary of anything that proposes to monetize the process
of doing my core work.
I recognize that that attitude makes marketing and selling a product
to developers difficult, though. If they changed from a CLA to a DCO
I'd feel less uneasy about it, but but is that something their
investors and business can permit?
myaccountonhn wrote 6 hours 42 min ago:
What I do is donate monthly to the projects I like.
I'd happily pay a fixed one-time fee for them though.
riffic wrote 14 hours 9 min ago:
am I supposed to know what zed is?
Longhanks wrote 13 hours 53 min ago:
Why bother commenting instead of clicking the link and in the main
navigation bar pressing the very clearly visible "ABOUT" button?
jasaldivara wrote 12 hours 29 min ago:
It's just common online courtesy to add to the title a short
description of the project like (Zed, code editor) to save users
some valuable time.
jodrellblank wrote 12 hours 23 min ago:
And it's in the HN guidelines not to: [1] > please use the
original title, unless it is misleading or linkbait; don't
editorialize.
> If the title includes the name of the site, please take it out,
because the site name will be displayed after the link.
> Please don't do things to make titles stand out, like using
uppercase or exclamation points, or saying how great an article
is. It's implicit in submitting something that you think it's
important.
(HTM) [1]: https://news.ycombinator.com/newsguidelines.html
metabagel wrote 13 hours 18 min ago:
In all fairness, and I already knew what Zed was, the About page is
a long read to find out anything more than that Zed is an editor.
(As in, it says right away that they are building an editor, but
then there is a long-winded discussion about history, goals, etc.)
mhaberl wrote 14 hours 10 min ago:
Serious question: I am looking at the measurements of speed on the
landing page between Zed and the other editors, and they don't seem
drastic. Do you actually feel the difference when typing?
bioneuralnet wrote 13 hours 54 min ago:
Compared with VSCode, absolutely. VSCode has a range of
responsiveness from "good enough" to "oh right, this is Electron".
Zed is both faster and more consistent. Sure, we're talking 10s of
milliseconds, but it's surprisingly noticeable. Can't speak for other
editors.
I'm becoming a true convert, though I occasionally must drop down to
a termianl for advanced vim features. That's high praise coming from
me, as I have a high bar for adopting new tools.
eikenberry wrote 14 hours 15 min ago:
If Apple had just adopted the Vulkan standard instead of going off with
their own proprietary graphics API this would have been a non-issue.
Smacks of Canonical and their repeatedly doing one thing while ignoring
the rest of the community standardizing on something else.
cpuguy83 wrote 13 hours 21 min ago:
Metal predates Vulkan.
But also I'm pretty sure Apple doesn't care if an app is portable.
jauntywundrkind wrote 12 hours 54 min ago:
But AMD's Mantle predates both & was proposed & what lead to
Vulkan. Apple saw the fork in the road & quickly scrambled to build
their own thing.
I'm kind of tired of this contention cropping up again and again.
Technically true but insufficient & obfuscating more than
revealing.
cpuguy83 wrote 12 hours 28 min ago:
Sorry no.
Vulkan literally did not exist.
That's not obfuscation.
It didn't even exist.
Had Apple adopted Mantle then where would they be now?
Apple did what they do, took ownership of their own stack.
jauntywundrkind wrote 9 hours 27 min ago:
"Sorry no" whatever. Khronos was discussing what to do with
Mantle as it became Vulkan. Apple was part of those industry
players who were invited to the table. Apple left and did their
own thing, like Apple does.
These specs don't spring up fully formed. Vulkan was a
collaboration long before it was named as such and released;
Approaching Zero Driver Overhead/bindless was 100% clear
writing on the wall for a while by then. Apple just doesn't
collaborate; they demand control. That's why they didn't
participate when everyone else was figuring out how to distill
out Vulkan from Mantle & other close to the metal patterns that
were already about.
pjmlp wrote 1 hour 21 min ago:
Microsoft, Sony and Nintendo also don't really care Vulkan
exists.
Besides AMD most likely only offered Mantle, because OpenGL
vNext was going to be another Long Peaks failure, had it not
been the case.
And for what, Vulkan is already an spaghetti extension mess,
with a complexity that feels like build a car out of LEGO
Technics pieces, when one wants to drive down to the grocery
store.
cpuguy83 wrote 5 hours 45 min ago:
Apple _shipped_ Metal in 2014.
Kronos started their work in 2014 and wasn't even named as
such until 2015.
The full spec wasn't released until 2016.
skohan wrote 13 hours 6 min ago:
In fact they probably care that it's not easily portable
mikaylamaki wrote 13 hours 57 min ago:
Unfortunately, the renderer is only one step in supporting an
alternative platform. Even if we could have used Vulkan on every
platform, the windowing APIs are completely different and those do
most of the things we like our code editors to support, like typing.
prophesi wrote 14 hours 18 min ago:
What's a valid Discord invite for Zed Linux? It seems like the link on
the downloads page[0][1] needs to be updated.
[0] [1]
(HTM) [1]: https://zed.dev/download
(HTM) [2]: https://discord.com/channels/869392257814519848/12046798502086...
dethos wrote 14 hours 21 min ago:
Sounds great. I'm eager to try it, when a release with early Linux
support is published. Keep it going.
Tubbe wrote 13 hours 44 min ago:
`curl [1] | sh`
(HTM) [1]: https://zed.dev/install.sh
mgaunard wrote 14 hours 29 min ago:
Atom, like most recent editors like VS Code etc., are just clones of
Sublime Text with just lots of bloat and JavaScript tech.
I'll just stick to Sublime Text.
bovermyer wrote 14 hours 23 min ago:
You're aware that Atom is not the subject of the article, right?
bioneuralnet wrote 13 hours 38 min ago:
I believe some of the Zed folks invented Atom back in the day. But
yes, it doesn't seem like a highly relevant comment...
mgaunard wrote 11 hours 4 min ago:
the article doesn't tell me what Zed is. If I look around, it
just says it's the new text editor from the authors of Atom.
FireBeyond wrote 3 hours 11 min ago:
> doesn't tell me what Zed is. If I look around, it just says
it's the new text editor
Huh. Did you mean to disagree with yourself the very next
sentence?
beeboobaa3 wrote 14 hours 33 min ago:
Will it run on iGPU?
paulcarroty wrote 12 hours 38 min ago:
Yep, just tested it few days ago.
zozbot234 wrote 14 hours 38 min ago:
If you care a lot about Linux support, Lapce is a very promising
alternative. Much like Zed, it also is written in Rust with native
GPU-based rendering and a shared focus on enabling integration with
modern IDE technologies such as LSP servers, tree-sitter parsers and
DAP for debugging.
resource_waste wrote 13 hours 2 min ago:
I didn't realize this was basically an ad for an IDE.
I thought this was some component. Lol, yeah if your IDE doesnt work
on Linux, the problem is your IDE, not linux.
iamnbutler wrote 13 hours 23 min ago:
you can build zed for linux, today :)
(HTM) [1]: https://github.com/zed-industries/zed/blob/main/docs/src/dev...
spudlyo wrote 14 hours 51 min ago:
From what I understand Zed is a text editor that is built like a game
engine, which I understand is why the marketing copy uses the term
"multiplayer" rather than "multiuser". I didn't find other mention of
its multiplayer capabilities, which is too bad. Has anyone used it for
that purpose, I'm curious as to what the experience was like.
jodrellblank wrote 12 hours 57 min ago:
"multiplayer notepad" goes back 15 years at least - [1] it was used
back with a popular website which opened a text document and anyone
viewing could type, but I can't remember the name. That became a
thing in Google Docs, Microsoft Office, Floobits, and lots of
self-hosted and cloned sites.
(HTM) [1]: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
KTibow wrote 2 hours 50 min ago:
A video I watched a while ago claimed that Talkomatic was the first
one
spudlyo wrote 10 hours 47 min ago:
You may be thinking of Hackpad from 2014, which later was bought by
Dropbox and morphed into Dropbox Paper. I guess I was thinking that
a multiuser IDE is substantially different than a multiuser text
editor. I did notice that Zed is by the same team that brought us
tree-sitter, which is a wonderful innovation that many text editors
are now using to good effect. I was wondering if were powerful
enough for one person to be debugging some code in the same session
that another person was refactoring.
jodrellblank wrote 7 hours 27 min ago:
Earlier than that; I wanted to say EditPad but that's not it. I
found it; EtherPad in 2008 is the one I was thinking of, but the
history of collaborative editing apparently goes back to Doug
Englebart's Mother of All Demos in 1968: [1]
(HTM) [1]: https://en.wikipedia.org/wiki/Etherpad
(HTM) [2]: https://en.wikipedia.org/wiki/Collaborative_real-time_ed...
gliptic wrote 11 hours 29 min ago:
IRC was what was initially called multiplayer notepad.
mikaylamaki wrote 14 hours 49 min ago:
We use them every day at Zed for pair programming, we're rather fond
of the features :D
FridgeSeal wrote 8 hours 39 min ago:
Used it the other day with my teammate to pair on some stuff, and
it genuinely felt magic. We went from never having used it, to
digging through their code together in about a minute, and have
used it a few times since. Really nice UX.
andy_xor_andrew wrote 14 hours 53 min ago:
> On macOS, for example, Zed makes direct use of Metal. We have our own
shaders, our own renderer, and we put a lot of effort into
understanding macOS APIs to get to 120FPS.
So they are taking the exact opposite approach of Electron (VS Code).
In my mind, if you're someone who types in HN comments in a rage
because your text editor (VS Code) eats up 200+ MB ram, you don't get
to cry about Zed not being supported on Linux from day one, because you
can't have your cake and eat it too - if you want it on your platform,
you gotta wait for the shaders to be written.
zamalek wrote 11 hours 40 min ago:
> In my mind, if you're someone who types in HN comments in a rage
because your text editor
WebGPU exists. It works with Metal. Vulkan could have also worked and
MoltenVK would have bridged it to Apple. No, this is just like every
other project that only works on MacOS: a mentality I really can't
comprehend or explain.
pjmlp wrote 1 hour 24 min ago:
Developed for Web browsers, targeting managed languages, and
hardware specifications from 2015.
cess11 wrote 12 hours 55 min ago:
Over the last few years I've had two applications that tended to rot
after a week or two running, one is Firefox, which I still use for
political reasons, and VS Code, the only Electron thing I've used for
more than a few hours. The other being MICROS~1 Teams, which doesn't
play nice with my window manager, tries to force me into identifying
myself to join some video chat for a bit, and prefers to hang rather
than shut down when asked nicely. Instead I join chats without video
support.
This is my problem with Electron applications. I'd be fine with them
gobbling up a few GB if they were stable.
hvis wrote 13 hours 26 min ago:
MoltenVK is also a thing. Whatever small translation overhead it
incurs is probably not that important for a text editor. And then you
get a cross-platform API: not just Linux, but Windows as well. Maybe
also other more niche OSes as well.
skohan wrote 13 hours 7 min ago:
Molten VK is amazing. When I started working with it, I was
expecting a lot of caveats and compromises, but it's shockingly
similar to just using Vulkan that you can easily forget that
there's a compatibility tool in play.
Probably you can squeeze a bit of optimization out of using Metal
directly, but I think it's a more than viable approach to start
with Vulkan/MoltenVK as a target, and add a Metal branch to the
renderer when capacity allows (although you might never feel the
need)
NoraCodes wrote 13 hours 30 min ago:
> In my mind, if you're someone who types in HN comments in a rage
because your text editor (VS Code) eats up 200+ MB ram, you don't get
to cry about Zed not being supported on Linux from day one, because
you can't have your cake and eat it too - if you want it on your
platform, you gotta wait for the shaders to be written.
This is certainly one takeaway. On the other hand, this very blog
post points out that a community member, Dzmitry Malyshau, did the
work to get the program working on the OS he uses. Malyshau does not
work for Zed, which is a for-profit company; as far as I can see, he
gets nothing out of working on Zed, except that he and other Linux
users get to use it. Perhaps, rather than characterizing Linux users
as whiny, we could take away the idea that many Linux users are
willing to put in quite a lot of work to make things better for each
other.
justinclift wrote 31 min ago:
> Perhaps, rather than characterizing Linux users as whiny, we
could take away the idea that many Linux users are willing to put
in quite a lot of work to make things better for each other.
That's more an "Open Source" thing rather than Linux specific. A
personal case in point was when I got Mellanox adapter support
officially added to FreeNAS (now TrueNAS) because that's the
adapter brand I had and needed it to work.
Not a super huge effort as the FreeBSD driver worked (so just
needed porting), but the integration process and follow up
testing/advocacy/etc work wasn't exactly trivial either.
weinzierl wrote 12 hours 36 min ago:
"Perhaps, rather than characterizing Linux users as whiny, we could
take away the idea that many Linux users are willing to put in
quite a lot of work to make things better for each other."
... and that even if it means signing away their rights in a CLA to
a for profit company. This is on another level than contributing to
the Linux kernel that is GPL2 plus practically not relicensable
because of the multitude of copyright holders.
duxup wrote 14 hours 30 min ago:
Someone has to pay for it, time, money, wait for it whatever.
I love working with technical people who ask why and think about more
optimal paths.
On the other hand I'll listen to the same folks complain about some
random app being stinky (I don't disagree) and wonder "Yeah but you
going to pay more for that burrito so that company can hire folks to
write it natively on every platform?" No you're not ...
I know our customers at times aren't willing to pay / wait for the
optimal path, and their customers aren't, so I get it.
jonhohle wrote 14 hours 39 min ago:
Or⦠use one of the existing cross platform toolkits that have
existed for decades. Text Editors, traditionally, did not require
shaders to run or be performant, and not require entire systems worth
of RAM.
Iwan-Zotow wrote 11 hours 4 min ago:
> Text Editors, traditionally, .. and not require entire systems
worth of RAM.
Emacs is looking at you
jamil7 wrote 13 hours 5 min ago:
Cross platform toolkits, more than other software components incur
massive tradeoffs. Theyâve written one themselves, tailored to
their needs and open sourced it along the way. I guess I donât
see the problem here. If one thatâs existed for decades fits your
needs better then use that.
jauntywundrkind wrote 12 hours 58 min ago:
Wgpu seems very very well loved & supported, is one of the most
successful comings together of the graphics world in ages. I'd
love to hear some actual critique of it, hear what people think
are shortcomings, because it feels to an outsider like this is
the fantasy land, that we're living in the better place now.
(HTM) [1]: https://github.com/gfx-rs/wgpu
littlestymaar wrote 9 hours 51 min ago:
What I find interesting is that kvark, the open source
contributor that made Linux port possible was the main
developer on wgpu at Mozilla, yet he decided to build an
alternative [1] to wgpu that he used for zed. I wonder what's
the rational for that.
[1]
(HTM) [1]: https://github.com/kvark/blade
jauntywundrkind wrote 8 hours 5 min ago:
Dzmitry gave a talk at a rust gamedev meetup on Blade.
This ain't my turf so apologies for inaccuracies here. It
appears to be a fairly novel attempt to write a graphics
library with a semi conventional looking pipeline, that under
the hood ends up eskewing a lot of the Vulkan concepts.
Instead of per object contexts, it uses global contexts to do
most work. Instead of taking resources and binding them into
descriptor sets to use across pipelines (tracking state),
Blade kind of recreates resources on the fly, lets them get
used, and disposed of them.
Kind of interesting philosophy of a complex binding model in
Vulkan/WebGPU vs a more direct diy render model? [1] Zed tool
this work as an outside contribution. Maybe that someone did
the work was good enough. I'm not sure what would make Blade
a better match or not, vs wgpu-hal.
(HTM) [1]: https://www.youtube.com/live/63dnzjw4azI?si=KzLPm-gB...
auggierose wrote 12 hours 30 min ago:
Well, it's Rust. I am using TypeScript. I guess I am sticking
with Electron. Maybe WebGPU can help me out.
phendrenad2 wrote 13 hours 30 min ago:
If you want a shaderless text editor, just use NotePad. But the
world has moved on and people like their text to look nice.
MR4D wrote 13 hours 50 min ago:
Out of curiosity, how many of them run at 120 FPS?
(honest question - I've never looked into it myself)
whazor wrote 12 hours 39 min ago:
Chrome supports 120Hz+ [1] It also seems like you can configure
VSCode to go faster: [2] But honestly, 'responsiveness' should
come from not blocking the main/UI threads, and rendering in the
right order of importance.
(HTM) [1]: https://www.testufo.com/browser.html
(HTM) [2]: https://stackoverflow.com/questions/52230196/vs-code-is-...
jethro_tell wrote 13 hours 23 min ago:
Honest question. What could you possibly do with a text editor
at 120 fps that you can't do at 15 or 30?
I can't think or type that fast and I can't read scroll back that
fast either so I can't wrap my head around needing something like
that.
teo_zero wrote 12 hours 30 min ago:
Smoother scrolling?
jethro_tell wrote 7 hours 2 min ago:
I mean, yeah that's pretty smooth, I'm not even sure I could
notice it past 15/30.
ajross wrote 13 hours 11 min ago:
> Honest question. What could you possibly do with a text
editor at 120 fps that you can't do at 15 or 30?
More-honest-than-it-should-be answer: sell a product to
Apple-ecosystem developers trying desperately to find something
to justify the $3k they want to spend on a new MBP.
(Typing this very comment in emacs running out of the Linux VM
on a mid-range chromebook attached to a 30 Hz 4k television,
btw. Come at me, as it were.)
jethro_tell wrote 7 hours 0 min ago:
Heh, rocking a self built tmux/vim setup her myself, but even
still I don't think I'm so cynical to think the only reason
is for the marketing speak.
I assume they have a reason, I just can't guess whatnot is.
ajross wrote 6 hours 43 min ago:
I'm... absolutely that cynical. 120 Hz displays and the
horsepower to drive them are the golden boutique speaker
wire of the Gen Z tech set.
Dylan16807 wrote 6 hours 23 min ago:
Oh come on. Fancy wires do nothing. 120Hz makes motion
much smoother. It also reduces latency. Those make a
big difference in many video games, or even just moving
my mouse around and having it not skip two inches at a
time.
Your cynicism over 120Hz should match your cynicism over
4k.
jethro_tell wrote 2 hours 48 min ago:
That, doesn't make any sense 4k allows monitors to push
past 24 inches, though, on a 24 or less 2k is plenty
for me, but the generation of 22 inch 1080p monitors
was rough on the eyes.
Dylan16807 wrote 2 hours 18 min ago:
It makes plenty of sense. They're both quite useful
but you can do without them.
I'm not saying to be highly cynical, I'm saying to be
equally cynical. You can change either side to reach
equality.
adastra22 wrote 13 hours 40 min ago:
The question doesnât make sense. They donât rerender the
buffer every frame. I assume zed isnât doing that either as it
would be horribly inefficient.
I presume what is meant is that it can handle a redraw fast
enough to be in the next frame. In which case the answer is: all
of them. Drawing text is not the bottleneck for a GUI program,
unless you have a god awful browser stack as your rendering
engine.
LoganDark wrote 12 hours 11 min ago:
> I assume zed isnât doing that either as it would be
horribly inefficient.
What are you supposed to do instead? Zed uses the GPU. It's not
making calls to retained-mode widgets to individually
reposition them, nor is it blitting into a buffer using the
CPU. It's using the GPU which eats pixels for breakfast. You've
been able to rerender the entire screen each frame for over a
decade - just look at Windows 7 Aero, which ran on the laptops
of 2009 for the exact same reason: it used the GPU!
adastra22 wrote 7 hours 58 min ago:
You render into a texture once, and then just send that to
the compositor each frame as needed.
Rusky wrote 11 hours 39 min ago:
Neither Windows Aero nor Zed renders every single frame, 120
times per second. The parent comment is correct is correct
that the important thing is to be able to render any given
frame in 1/120th of a second, but to leave things alone when
nothing is changing.
zozbot234 wrote 11 hours 48 min ago:
Rerendering each frame is wasteful because it keeps hardware
from reaching deeper power-saving states. This includes the
CPU, GPU and even the display, due to technologies such as
FreeSync. On modern hardware, even removing the blinking
cursor has been found to save quite a bit of power, by
eliminating needless screen redraws.
justinclift wrote 28 min ago:
> ... even removing the blinking cursor has been found to
save quite a bit of power, by eliminating needless screen
redraws.
Hadn't heard of that before, but it makes sense now you
mention it. :)
forgotpwd16 wrote 13 hours 40 min ago:
This is the first time I see FPS mentioned for a text editor. Is
this something that matters or just an pointless metric utilized
as selling point?
sunshowers wrote 13 hours 12 min ago:
As far as I can tell, graphics pipelines often use frame
buffering. The quicker the next frame can be drawn, the faster
it feels.
adastra22 wrote 7 hours 33 min ago:
GUI apps like text editors donât redraw frames every update
cycle.
freqmod wrote 13 hours 28 min ago:
Fps in itself is not important, but it is a substitute for
input latency, and if your keystrokes start lagging it feels
sluggish. At least historically electron based editors (like
atom) has been feeling significantly more sluggish than sublime
text or vim with a decent terminal emulator.
forgotpwd16 wrote 13 hours 18 min ago:
For terminal emulators comparisons at least the metrics used
are latency and throughput. Now those plus times to do
operations (load file, search & replace, etc) wouldn't
surprise me to be the comparison metrics for text editors.
FPS though feels weird.
SomeRndName11 wrote 13 hours 34 min ago:
Well it may have effect on ergonomics. Some people claim they
cannot use 60Hz monitor after trying 144hz.
NekkoDroid wrote 13 hours 12 min ago:
Well, that is usually refering to some form of "simulated
fluid motion", not new characters appearing and disappearing.
The only case where that kinda fluid motion would matter is
when you have text scrolling by at semi-fast speeds.
ffsm8 wrote 12 hours 32 min ago:
I count myself among the people that would consider >60hz
necessary.
For me, it's animations, especially if I'm dragging a
window or just the mouse. On 60hz it's nauseating if I'm
paying too much attention to the window I'm moving. It's
goes completely away around 90-100 Hz (at least for me)
NekkoDroid wrote 9 hours 0 min ago:
I'd still say that draggin a window would count as a
"simulated fluid motion". Maybe not something you'd
immediatly think of, but its still trying to convey the
sense of motion. Just text appearing and dissappearing
isn't something I personally could categorize ass the
same type of animation.
And I also count myself as someone who considers 120 at
least necessary (on the primary monitor)
LoganDark wrote 12 hours 7 min ago:
I've had the privilege of using a merely 90Hz display and
the difference is still incredible. It gives me input
feedback much faster so my brain does not have to do as
much buffering/prediction, everything feels a lot more
direct. One would think a measly 5 milliseconds wouldn't
amount to much, but for input feedback it absolutely
does.
I do not suffer from nausea or motion sickness of any
kind arising from computers or visuals in general, but I
can still easily tell the difference between a 60Hz and
90Hz display. A few months ago I had the privilege of
checking out the 120Hz displays on the new MacBooks and
they're amazing.
nemomarx wrote 14 hours 41 min ago:
I suppose ideally you'd want it to be written on Linux first, if
you're that kinda person - but the market is probably on Mac?
from-nibly wrote 8 hours 50 min ago:
Doing it on Linux would make people ask "why isnt it on my distro"
a LOT sooner. Thus adding complexity while you are trying to prove
the concept.
m463 wrote 13 hours 48 min ago:
I remember reading a long time ago (think pre-intel macs) that game
developers never developed for macs.
However if they did, the games would sell because the mac people
wanted games and there were so few available they would buy
anything.
problems of a closed ecosystem.
pjmlp wrote 1 hour 26 min ago:
How do you think iDevices games are developed?
wmf wrote 13 hours 8 min ago:
Because Macs are expensive (in absolute terms) Mac users are a
self-selected group who are willing to spend money. Linux users
have high standards and are not willing to spend money. For a
text editor in particular Linux is going to be the toughest
market because it's already pretty saturated.
thfuran wrote 13 hours 10 min ago:
Circa 2000, a lot of big name games actually were released for
Mac. Heroes III, StarCraft, and Diablo II, for example, all got
Mac releases.
tylerekahn wrote 14 hours 56 min ago:
I'm curious why Zed chose Blade over wgpu/wgpu-hal.
There's a bit of detail here: [1] But I'd be curious to read a longer
writeup on the tradeoffs and how they came to their decision.
(HTM) [1]: https://github.com/zed-industries/zed/issues/7015
Pannoniae wrote 13 hours 23 min ago:
This is a pretty good answer: [1] The "design of WebGPU" is a
problem. It's designed for the web to be secure and sandboxed so the
API design reflects that. This is not a good thing on desktop.
(HTM) [1]: https://github.com/gfx-rs/wgpu/tree/trunk/wgpu-hal
adwn wrote 13 hours 5 min ago:
> The "design of WebGPU" is a problem. It's designed for the web to
be secure and sandboxed so the API design reflects that.
The page you linked clearly states that wgpu-hal's API is extremely
unsafe and skips many checks in order to reduce overhead. So while
"secure and sandboxed" explains why wgpu wasn't chosen, it doesn't
explain why wgpu-hal wasn't chosen.
zie wrote 14 hours 8 min ago:
I imagine having a great PR magically show up that used Blade had a
lot to do with it.
mikaylamaki wrote 14 hours 20 min ago:
Partially because Kvark, who has a long history in graphics
programming, was enthusiastic about it, and has similar values of
simplicity and effectiveness to our own. Mainly because our renderer
is simple enough that we would have preferred to use Vulkan APIs
directly, rather than going through wgpu. Blade is a thinner
abstraction than wgpu, it's a bit more ergonomic than wgpu-hal, and
it already supports our long term platform goals (Linux, Windows, and
the web though via WebGL). So far, it's been running flawlessly, and
it's been everything else that's the hard part!
nasso_dev wrote 13 hours 34 min ago:
wgpu (and webgpu more generally) is often presented as a very good
choice for a cross platform low level graphics api. but it was
designed around safety/security constraints to support the web,
sometimes at the cost of performance (my understanding)
i heard somewhere this nice example: only big actors like AAA game
engines would really benefit from the extra development effort it
would take to use an even lower level api like vulkan/dx12 to
squeeze the last 10% of performance that wgpu can't get you
so if i understand correctly, zed, just like a AAA game engine,
wants to squeeze every last bit of performance from the gpu, and so
wgpu is "too high level" for it? and blade is "like wgpu, but no
design tradeoffs and lower level" so its a better fit? does that
mean someday zed might reach for vulkan directly one day? im
assuming dx12 is gonna be used on windows anyway?
i love kvark's work btw, we need more kvarks
mikaylamaki wrote 13 hours 8 min ago:
Roughly yes, though I'd caveat it with the specific application
of the GPU: simple, 2D, UI elements. We've already built an
abstraction that allows us to fluently build up a design, and
then burn it down into a collection of rectangles, paths, images,
and such. We're not dealing with particle effects, lighting, 3D
models, or anything else that game engines need to consider. As
such, it's a lot lower cost for us to use something like Vulkan
or DX12 directly. And, in fact, that was the backup plan if we
didn't find something like Blade that we where happy with.
Arnavion wrote 15 hours 1 min ago:
>Yup, that's a native file dialog, but we don't use GTK in Zed and that
clearly is GTK â so, how does that work? You'll find the answer in
the companion video in which Mikayla and I dive deeper into this and
also touch on the question of whether or not we should use GTK or Qt or
something else (spoiler: it's complicated).
Unless I missed it, the video doesn't actually answer the question.
They talk 38:50 onwards about how they don't want to pull in GTK / Qt
as dependencies, rather they just want to be able to read the toolkits'
config and render a mimicking UI themselves. Then they show the editor
opening a "native" file dialog, but don't actually say how exactly they
did it.
Anyway, I assumed they would use xdg-desktop-portal, and based on
searching the repo that does seem to be the case.
zozbot234 wrote 14 hours 34 min ago:
If you want a GTK-based IDE experience there's always GNOME Builder.
Like other modern GTK apps, it actually works quite well with custom
GTK themes which provide a Win9x-like look (see the chicago95 and
b00merang projects on github) if you want the better usability and
higher information density that this enables.
jchw wrote 14 hours 52 min ago:
Yeah, there are some caveats to using desktop portals this way, but
at least it'll usually give you a native dialog. I do wonder what
happens on a machine with no desktop portals, though. I suppose in
the future it probably would be feasible to implement a decent file
picker directly in GPUI as a fallback, so it's not that big of a
deal; I reckon they could make one that's more usable than the GTK
one anyways.
mikaylamaki wrote 14 hours 54 min ago:
Yep! That's how we did it, with the heavy lifting done by the
delightfully named "Aperture Science Handheld Portal Device" crate:
(HTM) [1]: https://crates.io/crates/ashpd
tomjakubowski wrote 13 hours 41 min ago:
So Zed is using dbus to create and manage the file dialog in a
toolkit independent way? Neat
Arnavion wrote 13 hours 37 min ago:
Yes, xdg-desktop-portal is a standard dbus interface. The
interface covers file picker, print, screenshot, screencast, etc.
The implementation of the interface (the "backend") is expected
to be provided by the desktop environment in some way that makes
sense for that DE. So gnome has xdp-gnome, kde has xdp-kde, etc,
and there are some like xdp-gtk that are DE-agnostic but
toolkit-specific.
Backends can implement a subset of the interfaces, and xdp can be
configured to try multiple backends in sequence until it finds
one that provides the interface that the application wants. Eg
xdp-wlr for wlroots-based Wayland compositors only implements
compositor-specific interfaces like screencast, so users would
chain it with something like xdp-gtk for other interfaces like
file picker.
Native applications usually use their toolkits' API for showing
file picker dialogs etc, and xdp's file picker interface is
primarily used by flatpak applications since that is a way for
sandboxed applications to read/write outside their sandbox. But
it's not impossible for native applications to also use it, as
zed is doing.
(HTM) [1]: https://flatpak.github.io/xdg-desktop-portal/docs/api-re...
CooCooCaCha wrote 15 hours 5 min ago:
I know itâs small thing but it annoys me so much when the blog
section of a site doesnât have a link back to the home page.
Seriously, what do people think when designing headers like this? Like
wow we should totally link to every other part of our site except the
homepage.
Because who would want to go there after they found out about a project
through a blog post?
syncsynchalt wrote 15 hours 2 min ago:
The logo in upper-left links to zed.dev, if that's what you mean.
This is not always great for accessibility (they don't have alt=,
title=, or aria-*= attributes on the or tags) but seems to be a
common pattern.
CooCooCaCha wrote 14 hours 59 min ago:
The logo doesnât show up on mobile unfortunately.
Brian_K_White wrote 14 hours 22 min ago:
Scroll a million pages to the very bottom, and it's the totally
not-visually-indicated white logo in the blue footer, it's
clickable.
I would not have found it or even thought to try to click on it
except after reading this claim that it's there somewhere.
genpfault wrote 15 hours 35 min ago:
> Zed[1] is a high-performance, multiplayer code editor from the
creators of Atom and Tree-sitter
[1]
(HTM) [1]: https://github.com/zed-industries/zed
(DIR) <- back to front page