This PR sets up a `cargo xtask clippy` command for running `cargo
clippy` with our defined set of options.
The intent is to make this easier to manage as we start enabling more
Clippy rules.
Release Notes:
- N/A
Fix initialization of minio to happen on service start instead of
bootstrap,
don't log errors if extensions are empty or if clickhouse is disabled
Release Notes:
- N/A
This lets us run rustc_demangle on the backtrace, which helps the Slack
view significantly.
We're also now uploading files to digital ocean's S3 equivalent (with a
1 month expiry) instead of to Slack.
This PR paves the way for (but does not yet implement) sending this data
to clickhouse too.
Release Notes:
- N/A
Move away from columns of icons towards the "changed" info dot we used
for files.
Secondary actions for chat/notes still show up (if you're lucky) on
hover.
Co-Authored-By: Marshall <marshall@zed.dev>
Release Notes:
- Improved design of collab panel
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Openssl is required by the `openssl-sys` crate. Trying to build zed on a
Fedora 39 workstation install. This is the error I got from the
compiler.
```
error: failed to run custom build command for `openssl-sys v0.9.93`
Caused by:
process didn't exit successfully: `/home/dionysus/git/zed/target/debug/build/openssl-sys-9f784a7979d04ba8/build-script-main` (exit status: 101)
--- stdout
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_LIB_DIR
X86_64_UNKNOWN_LINUX_GNU_OPENSSL_LIB_DIR unset
cargo:rerun-if-env-changed=OPENSSL_LIB_DIR
OPENSSL_LIB_DIR unset
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_INCLUDE_DIR
X86_64_UNKNOWN_LINUX_GNU_OPENSSL_INCLUDE_DIR unset
cargo:rerun-if-env-changed=OPENSSL_INCLUDE_DIR
OPENSSL_INCLUDE_DIR unset
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_DIR
X86_64_UNKNOWN_LINUX_GNU_OPENSSL_DIR unset
cargo:rerun-if-env-changed=OPENSSL_DIR
OPENSSL_DIR unset
cargo:rerun-if-env-changed=OPENSSL_NO_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG
cargo:rerun-if-env-changed=OPENSSL_STATIC
cargo:rerun-if-env-changed=OPENSSL_DYNAMIC
cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
cargo:rerun-if-env-changed=PKG_CONFIG_PATH
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
run pkg_config fail: `PKG_CONFIG_ALLOW_SYSTEM_CFLAGS="1" "pkg-config" "--libs" "--cflags" "openssl"` did not exit successfully: exit status: 1
error: could not find system library 'openssl' required by the 'openssl-sys' crate
--- stderr
Package openssl was not found in the pkg-config search path.
Perhaps you should add the directory containing `openssl.pc'
to the PKG_CONFIG_PATH environment variable
Package 'openssl', required by 'virtual:world', not found
--- stderr
thread 'main' panicked at /home/dionysus/.cargo/registry/src/index.crates.io-6f17d22bba15001f/openssl-sys-0.9.93/build/find_normal.rs:190:5:
Could not find directory of OpenSSL installation, and this `-sys` crate cannot
proceed without this knowledge. If OpenSSL is installed and this crate had
trouble finding it, you can set the `OPENSSL_DIR` environment variable for the
compilation process.
Make sure you also have the development packages of openssl installed.
For example, `libssl-dev` on Ubuntu or `openssl-devel` on Fedora.
If you're in a situation where you think the directory *should* be found
automatically, please open a bug at https://github.com/sfackler/rust-openssl
and include information about your system as well as this message.
$HOST = x86_64-unknown-linux-gnu
$TARGET = x86_64-unknown-linux-gnu
openssl-sys = 0.9.93
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...```
I didn't explicitly test this patch on arch or debian.
Release Notes:
- Added/Fixed/Improved ... ([#8135](https://github.com/zed-industries/zed/issues/8135)).
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>
This PR adds a REST API to the collab server for searching and
downloading extensions. Previously, we had implemented this API in
zed.dev directly, but this implementation is better, because we use the
collab database to store the download counts for extensions.
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Conrad <conrad@zed.dev>
This should eliminate a pretty significant (multiple seconds) slowdown
that new users (or users after restarting their OS) have been
experiencing.
Previously, we would just notarize the application, which meant that
every user of the application had to perform an integrity check against
Apple's servers to ensure the app wasn't malicious.
With this commit, we are now using `xcrun stapler staple`, which
attaches the notarization ticket to both the app bundle as well as the
DMG. This should prevent users from needing to reach out to Apple's
notarization service in order to verify the app's integrity.
You can confirm the quarantine status of the application by running `ls
-l@` in `Terminal.app`:
ls -l@ /Applications/Zed.app/Contents/MacOS/zed
Release Notes:
- Improved startup time when opening Zed for the first time or after
restarting the operating system.
Co-authored-by: Thorsten <thorsten@zed.dev>
Co-authored-by: bennetbo <bennetbo@gmx.de>
Co-authored-by: Martin Palma <m@palma.bz>
Co-authored-by: evrsen <146845123+evrsen@users.noreply.github.com>
This PR adds Wayland support to gpui using
[wayland-rs](https://github.com/Smithay/wayland-rs). It is based on
[#7598](https://github.com/zed-industries/zed/pull/7598).
It detects Wayland support at runtime by checking the existence of the
`WAYLAND_DISPLAY` environment variable. If it does not exist or is
empty, the X11 backend will be used. To use the X11 backend in a Wayland
session (for development purposes), you just need to unset
WAYLAND_DISPLAY (`WAYLAND_DISPLAY= cargo run ...`).
At the moment it only creates the window and renders the initial content
provided by `BladeRenderer`, so it can run "Hello world" example.
Todo:
- [x] Add basic Wayland support.
- [x] Add window resizing.
- [x] Add window closing.
- [x] Add window updating.
- [ ] Implement input handling, fractional scaling, and support other
Wayland protocols.
- [ ] Implement all unimplemented todo!(linux).
- [ ] Add window decorations or use custom decorations (like on MacOS).
- [ ] Address other missing functionality.
Release Notes:
- N/A
---------
Co-authored-by: gabydd <gabydinnerdavid@gmail.com>
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Before the change to `script/clippy`, bash ignored first `clippy`
invocation failure and CI moved on with Linux errors and warnings
emitted.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
* fix: avoid panics in case of non-existing path for watching
* fix: copy the themes and plugins
* Revert "add a few more libraries to the linux script"
This reverts commit 7509677003.
* fix: add vulkan validation layers to the system deps
* fix: fix the themes paths
After this change we'll be able to push a tag to github to deploy to
collab.
The advantages of this are that there's no longer a separate step to
first
build the image, and then deploy it.
In the future I'd like to make this happen more automatically (maybe as
part of
bump nightly).
Release Notes:
- N/A
This PR changes the theme loading to use the JSON themes bundled with
the binary rather then the Rust theme definitions.
### Performance
I profiled this using `cargo run --release` to see what the speed
differences would be now that we're deserializing JSON:
**Before:** `ThemeRegistry::load_user_themes` took 16.656666ms
**After:** `ThemeRegistry::load_user_themes` took 18.784875ms
It's slightly slower, but not by much. There is probably some work we
could do here to bring down the theme loading time in general.
Release Notes:
- N/A
Previously the script would choke on lines generated, for example, by
`cargo run`.
This just skips lines that don't contain `frame duration:`.
Co-authored-by: Antonio <antonio@zed.dev>
This uploads apples crash reports to our servers when telemetry is
enabled.
Rather than jumping via the website, it uploads to collab directly. (I'd
like
to update the panic handler to do this too to make it possible to work
on that end-to-end without zed.dev running).
Release Notes:
- Added reporting of crashes when telemetry is enabled
When testing Zed locally, it's rarely necessary to log in the real with,
via Zed.dev and GitHub. We usually use `zed-local`. Since zed.dev is not
going to be open source (at least right away), this PR removes it from
our local development workflow.
* Remove zed.dev from the Procfile
* Change the `seed` script to not create an admin user for your
signed-in github user
* Instead have both `zed-local` and the `seed` script read from an
`.admins.json` file, which the user can create in order to customize who
they sign in as when running `zed-local`.
* Update all of the docs for building and developing zed.
Instead, admins are specified using a JSON file, 'admins.json'. This file is
gitignored. If it is not present, there is a default list of admins in
'admins.default.json'.
This PR decouples the generation of licenses for the themes we ship from
the TypeScript theme definitions.
For now, we are embedding the license information for the themes in the
`theme_importer`, and emit a combined `LICENSES` file in the `theme`
crate whenever we import themes. This is also where we check that each
theme has a valid license.
We then use this `LICENSES` file when building up the global license
file for Zed.
This decoupling is one step towards us being able to delete the old Zed1
styles.
Release Notes:
- N/A
Also, move postgrest service + deployment into a separate manifest
file, which is deployed via a separate script, `deploy-postgrest`.
This way, we don't have unused postgrest instances in preview and
nightly, since those use the prod database.
Co-authored-by: Conrad <conrad@zed.dev>
This PR builds on top of #3652 by adding a selection prompt to the
storybook to allow you to choose from the available list of stories if
you don't provide one explicitly:
<img width="1387" alt="Screenshot 2023-12-14 at 12 00 26 PM"
src="https://github.com/zed-industries/zed/assets/1486634/640d62a3-1340-45f1-9746-69b513faff62">
This way we don't have to keep generating the `script/storybook` script
whenever stories are added/removed.
#### Usage (through `cargo`):
```sh
# Select from the available stories
cargo run -p storybook2
# Run a specific story
cargo run -p storybook2 -- components/list_item
```
#### Usage (through `script/storybook`):
```sh
# Select from the available stories
./script/storybook
# Run a specific story
./script/storybook list_item
```
Release Notes:
- N/A
./script/zed-local now looks for "--zed2" flag in its args and runs Zed2 binaries instead of zed1.
'foreman start' can be launched with '-f Procfile.zed2" argument to launch zed2 collab server.
[[PR Description]]
Adds `script/deploy-docs`:
- If you don't already have it, it will clone the `zed-docs` repo into
`../zed-docs`
- It will build the docs and output them in `../zed-docs`
- Then it will open the docs.
- By default this "dry runs" (doesn't push) but you can pass `-p` to
push the changes.
- If you add `-c` it will clean out the old docs before running.
If you run the script with `p` it will push up the changes, and vercel
will automatically deploy them.
Release Notes:
- N/A
Ignore this PR for now.
This has a chance to speed up a build in case where e.g. we're
single-threaded in aarch64 build; at that point the x86_64 codegen can
take place. Also, MIR can probably be shared between the two
architectures, further reducing build time.
Release Notes:
- N/A
This has a chance to speed up a build in case where e.g. we're single-threaded in aarch64 build; at that point the x86_64 codegen can take place. Also, MIR can probably be shared between the two architectures, further reducing build time.
This makes zed always behave as if the app is active, even if no window is focused.
It prevents the 'viewing a window outside of zed' state during collaboration.
When you pass -l, we build for the local architecture only and copy the
resulting app bundle to /Applications. You can provide a bundle name as
an optional argument.
