Notable things I've had to fix due to 1.78:
- Better detection of unused items
- New clippy lint (`assigning_clones`) that points out places where assignment operations with clone rhs could be replaced with more performant `clone_into`
Release Notes:
- N/A
Since Wayland doesn't have a way for windows to activate themselves,
currently, when you click on a link in Zed, the browser window opens in
the background.
This PR implements the `xdg-activation` protocol to get an activation
token, which the browser can use to raise its window.
https://github.com/zed-industries/zed/assets/71973804/8b3456c0-89f8-4201-b1cb-633a149796b7
Release Notes:
- N/A
This should have fixed the problems that some users were reporting with
https://github.com/zed-industries/zed/pull/10695 .
The problem was with devices which send more than one valuator axis in a
single event whereas the original PR assumed there would only ever be
one axis per event. This version also does away with the complicated
device selection and instead just uses the master pointer device, which
automatically uses all sub-pointers.
Edit: Confirmed working for one of the user's which the first attempt
was broken for.
Release Notes:
- Added smooth scrolling for X11 on Linux
- Added horizontal scrolling for X11 on Linux
fixes https://github.com/zed-industries/zed/issues/9132
By setting the app id, window managers like `sway` can apply custom
configuration like `for_window [app_id="zed"] floating enable`.
Tested using `wlprop`/`hyprctl activewindow` for wayland, `xprop` for
x11.
Release Notes:
- Zed now sets the window app id / class, which can be used e.g. in
window managers like `sway`/`i3` to define custom rules
Release Notes:
- N/A
Picks up https://github.com/kvark/blade/pull/113 and a bunch of other
fixes.
Should prevent the exclusive full-screen on Vulkan - related to #9728
cc @kazatsuyu
Note: this PR doesn't enable transparency, this is left to follow-up
Reverts zed-industries/zed#10695
Some users are experiencing broken scrolling due to the changes from
this PR, so it should be reverted while I investigate what causes the
problems.
Release Notes:
- N/A
Changes the X11 platform code to use the xinput extension which allows
for smooth scrolling and horizontal scrolling.
Release Notes:
- Added smooth scrolling to X11 on Linux
- Added horizontal scrolling to X11 on Linux
This fixes certain shortcuts/motions on X11 like in vim mode "v i )",
where previously zed would interpret it as "v i SHIFT )" due to the x11
backend emitting key press events for modifier keys even though other
platforms like Wayland don't. This also adds support for
ModifiersChanged events to X11
Release Notes:
- Fixed vim motions like "v i )" not working on X11
([#10199](https://github.com/zed-industries/zed/issues/10199)).
This puts the Linux platform implementation at a similar code style and
quality to the macOS platform. The largest change is that I collapsed
the `LinuxPlatform` -> `[Backend]` -> `[Backend]State` ->
`[Backend]StateInner` to just `[Backend]` and `[Backend]State`, and in
the process removed most of the `Rc`s and `RefCell`s.
TODO:
- [x] Make sure that this is on-par with the existing implementation
- [x] Review in detail, now that the large changes are done.
- [ ] Update the roadmap
Release Notes:
- N/A
Sharing a project displays a notification (window) on every screen.
Previously there was an issue with the positioning of windows on all
screens except the primary screen.
As you can see here:
Now:
@mikayla-maki and I also decided to refactor the `WindowOptions` a bit.
Previously you could specify bounds which controlled the positioning and
size of the window in the global coordinate space, while also providing
a display id (which screen to show the window on). This can lead to
unusual behavior because you could theoretically specify a global bound
which does not even belong to the display id which was provided.
Therefore we changed the api to this:
```rust
struct WindowOptions {
/// The bounds of the window in screen coordinates
/// None -> inherit, Some(bounds) -> set bounds.
pub bounds: Option<Bounds<DevicePixels>>,
/// The display to create the window on, if this is None,
/// the window will be created on the main display
pub display_id: Option<DisplayId>,
}
```
This lets you specify a display id, which maps to the screen where the
window should be created and bounds relative to the upper left of the
screen.
Release Notes:
- Fixed positioning of popup windows (e.g. when sharing a project) when
using multiple external displays.
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Separate from #9451
On Windows, a new window may already active immediate after creation.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
This PR adjusts scrolling to be a lot faster on Linux and also makes
terminal scrolling work.
For Wayland, it makes scrolling faster by handling the `AxisValue120`
event (which also allows high-resolution scrolling on supported mice)
On X11, changed the 1 line per scroll to 3.
### Different solutions
I tried replicating Chromium's scrolling behaviour, but it was
inconsistent in X11/Wayland and found it too fast on Wayland. Plus, it
also didn't match VSCode, since it seems that they do something
different.
Release Notes:
- Made scrolling faster on Linux
- Made terminal scroll on Linux
This reverts #9053 and #9375 because they introduced a regression on
`main` that broke the titlebars on macOS:
Two things are off:
- Left padding is missing
- Titlebar height is less than it was before, which means the
traffic-light buttons are not centered vertically
What @as-cii and I noticed while looking into this: the `cfg!(macos)`
macros that were used don't work like that. You need to check for
`cfg!(target = "macos")` etc. Means that on macOS we never used the
macOS-specific code because the condition was always false.
Overall height, we're not sure about.
Release Notes:
- N/A
Switch to using `x11rb` crate instead of current `xcb` crate for gpui's
x11 platform.
Also fixes the crash on resize, and white flashing on resize.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
This PR changes GPUI to open windows with a default size and location,
and to otherwise inherit from their spawning window.
Note: The linux build now crashes on startup.
Release Notes:
- N/A
---------
Co-authored-by: Nathan <nathan@zed.dev>
Co-authored-by: Ezekiel Warren <zaucy@users.noreply.github.com>
Fix panic caused by missing screen mode for specified crtc mode id #9105
by searching over all crtcs instead of using the first one which may be
invalid.
This PR simplifies the Zed file system abstraction and implements
`Fs::watch` for linux and windows.
TODO:
- [x] Figure out why this fails to initialize the file watchers when we
have to initialize the config directory paths, but succeeds on
subsequent runs.
- [x] Fix macOS dependencies on old fsevents::Event crate
Release Notes:
- N/A
Changes Zed CI to build and upload Linux nightly bundles.
* `todo!(linux)` are replaced with `TODO linux` to make `todo!`-based
workflows more convenient
* renames `run-build-dmg` label into `run-bundling`, also renames a few
GH Actions entries to be more generic
* make another upload path for Linux, which keeps a separate file with SHA to version the nightly artifact.
* adds a `*.deb` package building with a couple of caveats, marked with
new `TODO linux` entries:
1. `cargo-bundle` is not very flexible, so it generates artifacts with
the structure and names that we're unable to alter before/during the
generation.
For that, a set of extra steps is made by repacking the *.deb package —
this is not very portable between different Linux distros, so later one
needs to find a way to combine multiple package types in this script.
2. `cargo-bundle` is not able to properly generate the *.msi bundle
despite declaring it in the features:
https://github.com/burtonageo/cargo-bundle/issues/116
Windows needs to invent its own way of bundling or fix the tool.
3. Both `cli` and `zed` binaries are added into the archive under
`/usr/local/bin/` path with their `-$channel` suffix
(-nightly/-preview/-dev/-stable) and a `/usr/local/bin/zed ->
/usr/local/bin/cli-nightly` symlink is made to make CLI work as Zed
launcher:
```
~/work/zed kb/linux-nightly:origin/kb/linux-nightly* ❯ dpkg -c target/zed_amd64.deb
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/bin/
-rwxr-xr-x allaptop/allaptop 8746832 2024-03-06 00:53 ./usr/local/bin/cli-nightly
-rwxr-xr-x allaptop/allaptop 689078560 2024-03-06 00:53 ./usr/local/bin/zed-nightly
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/applications/
-rw-r--r-- allaptop/allaptop 153 2024-03-06 00:53 ./usr/share/applications/zed.desktop
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/apps/
-rw-r--r-- allaptop/allaptop 716288 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/apps/zed.png
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/apps/
-rw-r--r-- allaptop/allaptop 239870 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/apps/zed.png
lrwxrwxrwx allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/bin/zed -> /usr/local/bin/cli-nightly
```
But the CLI does not work under Linux yet and there's no way to install
that CLI from Zed now; Zed binary itself is not able to open
`file/location:12:34`-like things and set up the env properly, but is
able to start or open a directory.
So, this structure can be considered temporary and changed, if needed.
4. Zed Nightly on Linux does not know how to update itself, so all
nightly publishing is not picked up automatically.
5. Rust cache from `main` builds does not get shared between CI jobs,
due to being run in a different CI job that forms a different CI key, so
```
- name: Cache dependencies
uses: swatinem/rust-cache@v2
with:
save-if: ${{ false }}
```
would not work.
This makes Linux bundling jobs long.
Release Notes:
- N/A
This adds a GPUI fallback for window prompts. Linux does not support
this feature by default, so we have to implement it ourselves.
This implementation also makes it possible for GPUI clients to override
the platform prompts with their own implementations.
This is just a first pass. These alerts are not keyboard accessible yet,
does not reflect the prompt level, they're implemented in-window, rather
than as popups, and the whole feature need a pass from a designer.
Regardless, this gets us one step closer to Linux support :)
<img width="650" alt="Screenshot 2024-03-06 at 5 58 08 PM"
src="https://github.com/zed-industries/zed/assets/2280405/972ebb55-fd1f-4066-969c-a87f63b22a6f">
Release Notes:
- N/A
Associates every window with its own refresh event. Removes the use of
X11 present.
Alternative to #8592.
Instead of doing the rendering on idle and then involving a hack for
polling X11 events, this PR just tries to do the rendering inside the
main loop. This guarantees that we continue to poll for events after the
draw, and not get screwed by the driver talking to X11 via the same file
descriptor.
Release Notes:
- N/A
This practice makes it difficult to locate todo!s in my code when I'm
working. Let's take out the bang if we want to keep doing this.
Release Notes:
- N/A
This reverts commit 0cebf68306.
Although this thing is very cool, it is a top source of crashes.
Example crash:
```
Segmentation fault: 11 on thread 26
objc_retain +16
invocation function for block in Overlay::onCommandBufferCommit(id<MTLCommandBuffer>) +60
MTLDispatchListApply +52
```
Release Notes:
- Removed "Toggle Graphics Profiler" as it crashes too much.
This PR unifies the event loop code for Wayland and X11. On Wayland,
blocking dispatch is now used. On X11, the invisible window is no longer
needed.
Release Notes:
- N/A
---------
Co-authored-by: Dzmitry Malyshau <kvark@fastmail.com>
Co-authored-by: Tadeo Kondrak <me@tadeo.ca>
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: julia <julia@zed.dev>
With this change, interaction with Zed is actually real-time and usable
🚀🎉
The gist of it is - trying to process all of the input events before
rendering anything.
Release Notes:
- N/A
**Note**: this can be further improved in a follow-up.
Currently, once the input and runnables are processed, we'd try to draw
+ render a frame.
Presentation starts with acquiring a new frame. We currently have FIFO
presentation method, so acquiring a frame is blocking on that swapchain
image to become available. As the result, presentation takes around 16
ms, most of which is just busy wait.
Ideally, we'd be able to process more input in this time frame, instead.
**Note2**: it's a bit laggy in Debug for me, but that's just because of
the extra-long `draw` times, which is unrelated to rendering (or
platform support, for the matter). I'm curious how come on MacOS the
`draw()` times in Debug are more modest.
[Profiling](https://crates.io/crates/profiling) crate allows easy
integration with various profiler tools. The best thing is - annotations
compile to nothing unless you request a specific feature.
For example, I used this command to enable Tracy support:
```bash
cargo run --features profiling/profile-with-tracy
```
At the same time I had Tracy tool open and waiting for connection. It
gathered nice stats from the run:
Release Notes:
- N/A
With `send_and_check_request` we'd be blocking both the main loop and
the caller. `send_request` is only going to be blocking on the main loop
when processing the request.
Release Notes:
- N/A
Based on a flamegraph from `perf`/`hotspot`, we are spending 40% of time
redrawing, another 40% of time downloading stuff (i.e. rust toolchain),
and the rest on text rendering, layout and such. This is with Vulkan
Validation (see https://github.com/zed-industries/zed/pull/8044).
I'm also wondering if it would be better with #7758, but regardless we
should have no problem rendering at 60-120 fps and processing user
input. More follow-ups are expected here.
Depends on https://github.com/zed-industries/font-kit/pull/2 and
https://github.com/kvark/blade/pull/77
This change enables Blade to be also used on MacOS. It will also make it
easier to use it on Windows.
What works: most of the things. Zed loads as fast and appears equally
responsive to the current renderer.
<img width="306" alt="Screenshot 2024-02-11 at 12 09 15 AM"
src="https://github.com/zed-industries/zed/assets/107301/66d82f45-5ea2-4e2b-86c6-5b3ed333c827">
Things missing:
- [x] video streaming. ~~Requires a bit of plumbing on both Blade and
Zed sides, but all fairly straightforward.~~
- verified with a local setup
- [x] resize. ~~Not sure where exactly to hook up the reaction on the
window size change. Once we know where, the fix is one line.~~
- [ ] fine-tune CA Layer
- this isn't a blocker for merging the PR, but it would be a blocker if
we wanted to switch to the new path by default
- [ ] rebase on latest, get the dependency merged (need review/merge of
https://github.com/zed-industries/font-kit/pull/2!)
Update: I implemented resize support as well as "surface" rendering on
the Blade path (which will be useful on Linux/Windows later on). I
haven't tested the latter though - not sure how to get something
streaming. Would appreciate some help! I don't think this should be a
blocker to this PR, anyway.
The only little piece that's missing for the Blade on MacOS path to be
full-featured is fine-tuning the CALayer configuration. Zed does a lot
of careful logic in configuring the layer, such as switching the
"present with transaction" on/off intermittently, which Blade path
doesn't have yet.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Alternative to #7758, which doesn't involve adding a new trait method
`request_draw`.
Somehow, my whole screen goes blinking black with this when moving the
window, so not ready for landing.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Release Notes:
- Separated Linux platform and X11-specific code, so that we can add
Wayland support now.
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Dzmitry MalyshauandJan Solanti
Piotr Osiewicz
apricotbucket28
Owen Law
Jakob Hellermann
Maxime ForveilleandMikayla Maki
Kamal Ahmad
Bennet Bo FennerandConrad Irwin
PaulandMikayla Maki
白山風露andMikayla
Daniel Zhu
Thorsten Ball
Ezekiel WarrenandMikayla
Rajesh MalviyaandMikayla Maki
Vitor Ramos
Kirill Bulatov
Rom Grk
Joel SelvarajandMikayla
gmorenz
bbb651andMikayla Maki
