[HN Gopher] Linux When?
___________________________________________________________________
Linux When?
Author : todsacerdoti
Score : 191 points
Date : 2024-05-07 15:31 UTC (7 hours ago)
(HTM) web link (zed.dev)
(TXT) w3m dump (zed.dev)
| genpfault wrote:
| > Zed[1] is a high-performance, multiplayer code editor from the
| creators of Atom and Tree-sitter
|
| [1]: https://github.com/zed-industries/zed
| CooCooCaCha wrote:
| 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:
| 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 <a> or <img> tags)
| but seems to be a common pattern.
| CooCooCaCha wrote:
| The logo doesn't show up on mobile unfortunately.
| Brian_K_White wrote:
| 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.
| Arnavion wrote:
| >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.
| mikaylamaki wrote:
| Yep! That's how we did it, with the heavy lifting done by the
| delightfully named "Aperture Science Handheld Portal Device"
| crate: https://crates.io/crates/ashpd
| tomjakubowski wrote:
| So Zed is using dbus to create and manage the file dialog in
| a toolkit independent way? Neat
| Arnavion wrote:
| 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.
|
| https://flatpak.github.io/xdg-desktop-portal/docs/api-
| refere...
| jchw wrote:
| 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.
| zozbot234 wrote:
| 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.
| tylerekahn wrote:
| I'm curious why Zed chose Blade over wgpu/wgpu-hal.
|
| There's a bit of detail here: https://github.com/zed-
| industries/zed/issues/7015
|
| But I'd be curious to read a longer writeup on the tradeoffs and
| how they came to their decision.
| mikaylamaki wrote:
| 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:
| 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:
| 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.
| zie wrote:
| I imagine having a great PR magically show up that used Blade
| had a lot to do with it.
| Pannoniae wrote:
| This is a pretty good answer: https://github.com/gfx-
| rs/wgpu/tree/trunk/wgpu-hal
|
| 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.
| adwn wrote:
| > _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.
| andy_xor_andrew wrote:
| > 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.
| nemomarx wrote:
| 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?
| m463 wrote:
| 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.
| thfuran wrote:
| 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.
| wmf wrote:
| 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.
| jonhohle wrote:
| 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.
| MR4D wrote:
| Out of curiosity, how many of them run at 120 FPS?
|
| (honest question - I've never looked into it myself)
| forgotpwd16 wrote:
| 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?
| SomeRndName11 wrote:
| Well it may have effect on ergonomics. Some people claim
| they cannot use 60Hz monitor after trying 144hz.
| NekkoDroid wrote:
| 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:
| 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)
| LoganDark wrote:
| 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.
| freqmod wrote:
| 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:
| 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.
| sunshowers wrote:
| 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:
| 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:
| > 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!
| zozbot234 wrote:
| 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.
| Rusky wrote:
| 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.
| jethro_tell wrote:
| 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.
| ajross wrote:
| > 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.)
| teo_zero wrote:
| Smoother scrolling?
| whazor wrote:
| Chrome supports 120Hz+ https://www.testufo.com/browser.html
|
| It also seems like you can configure VSCode to go faster:
| https://stackoverflow.com/questions/52230196/vs-code-is-
| visi...
|
| But honestly, 'responsiveness' should come from not
| blocking the main/UI threads, and rendering in the right
| order of importance.
| phendrenad2 wrote:
| If you want a shaderless text editor, just use NotePad. But
| the world has moved on and people like their text to look
| nice.
| jamil7 wrote:
| 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:
| 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. https://github.com/gfx-rs/wgpu
| auggierose wrote:
| Well, it's Rust. I am using TypeScript. I guess I am
| sticking with Electron. Maybe WebGPU can help me out.
| littlestymaar wrote:
| 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]: https://github.com/kvark/blade
| Iwan-Zotow wrote:
| > Text Editors, traditionally, .. and not require entire
| systems worth of RAM.
|
| Emacs is looking at you
| duxup wrote:
| 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.
| NoraCodes wrote:
| > 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.
| weinzierl wrote:
| _" 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.
| hvis wrote:
| 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:
| 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)
| cess11 wrote:
| 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.
| zamalek wrote:
| > 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.
| spudlyo wrote:
| 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.
| mikaylamaki wrote:
| We use them every day at Zed for pair programming, we're rather
| fond of the features :D
| jodrellblank wrote:
| "multiplayer notepad" goes back 15 years at least -
| https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
|
| 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.
| gliptic wrote:
| IRC was what was initially called multiplayer notepad.
| spudlyo wrote:
| 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.
| zozbot234 wrote:
| 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.
| iamnbutler wrote:
| you can build zed for linux, today :) https://github.com/zed-
| industries/zed/blob/main/docs/src/dev...
| resource_waste wrote:
| 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.
| beeboobaa3 wrote:
| Will it run on iGPU?
| paulcarroty wrote:
| Yep, just tested it few days ago.
| mgaunard wrote:
| 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:
| You're aware that Atom is not the subject of the article,
| right?
| bioneuralnet wrote:
| 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:
| 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.
| dethos wrote:
| Sounds great. I'm eager to try it, when a release with early
| Linux support is published. Keep it going.
| Tubbe wrote:
| `curl https://zed.dev/install.sh | sh`
| prophesi wrote:
| 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] https://zed.dev/download
|
| [1]
| https://discord.com/channels/869392257814519848/120467985020...
| eikenberry wrote:
| 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.
| mikaylamaki wrote:
| 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.
| cpuguy83 wrote:
| Metal predates Vulkan. But also I'm pretty sure Apple doesn't
| care if an app is portable.
| skohan wrote:
| In fact they probably care that it's not easily portable
| jauntywundrkind wrote:
| 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:
| 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:
| "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. 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.
| mhaberl wrote:
| 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:
| 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.
| riffic wrote:
| am I supposed to know what zed is?
| Longhanks wrote:
| Why bother commenting instead of clicking the link and in the
| main navigation bar pressing the very clearly visible "ABOUT"
| button?
| metabagel wrote:
| 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.)
| jasaldivara wrote:
| 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:
| And it's in the HN guidelines not to:
| https://news.ycombinator.com/newsguidelines.html
|
| > 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.
| myaccountonhn wrote:
| 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.
| vetrom wrote:
| 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?
| skohan wrote:
| I use Zed as a daily driver, and I haven't once used the
| collaborative features
| adastra22 wrote:
| I had to click through three links just to find out what Zed is.
| keb_ wrote:
| 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] https://github.com/rxi/lite
|
| [2] https://github.com/lite-xl/lite-xl
| forgotpwd16 wrote:
| >"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]: https://caseymuratori.com/blog_0001 (fist post on his
| blog!) [2]: https://github.com/zed-
| industries/zed/tree/main/crates/gpui
| gostsamo wrote:
| What is the accessibility story with Zed? I have a vague memory
| that atom had none of it.
| mikaylamaki wrote:
| 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:
| 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:
| That does seem more usable for this use case. I'll keep it
| in mind, thank you!
| OptionX wrote:
| Still baffled by the idea of make a code editor not only single
| OS but targeting mac.
| NoraCodes wrote:
| One question I don't think this post answers - why not use
| `winit`?
| mikaylamaki wrote:
| 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:
| Makes sense, thank you for the thorough answer!
| timvdalen wrote:
| 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!
| the_duke wrote:
| 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!
| tfeldmann wrote:
| Zed has quickly become my daily driver for mostly python and some
| rust development. Awesome editor.
| FullGarden_S wrote:
| > 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(r) text editor project demands to just build it but since
| its Rust(tm), 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:
| > since its Rust(tm), 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.
___________________________________________________________________
(page generated 2024-05-07 23:01 UTC)