Now, regardless of how the Zed window is closed, Zed can remember the
window's restore size.
- [x] Windows implementation
- [x] macOS implementation
- [x] Linux implementation (partial)
- [x] update SQL data base (mark column `fullscreen` as deprecated)
The current implementation on Linux is basic, and I'm not sure if it's
correct.
The variable `fullscreen` in SQL can be removed, but I'm unsure how to
do it.
edit: mark `fullscreen` as deprecated
### Case 1
When the window is closed as maximized, reopening it will open in the
maximized state, and returning from maximized state will restore the
position and size it had when it was maximized.
https://github.com/zed-industries/zed/assets/14981363/7207752e-878a-4d43-93a7-41ad1fdb3a06
### Case 2
When the window is closed as fullscreen, reopening it will open in
fullscreen mode, and toggling fullscreen will restore the position and
size it had when it entered fullscreen (note that the fullscreen
application was not recorded in the video, showing a black screen, but
it had actually entered fullscreen mode).
https://github.com/zed-industries/zed/assets/14981363/ea5aa70d-b296-462a-afb3-4c3372883ea3
### What's more
- As English is not my native language, some variable and struct names
may need to be modified to match their actual meaning.
- I am not familiar with the APIs related to macOS and Linux, so
implementation for these two platforms has not been done for now.
- Any suggestions and ideas are welcome.
Release Notes:
- N/A
Fixed various small issues on Linux, mainly on Wayland.
Apart from the first commit (which should be self-describing), the other
commits have a description explaining the issue and what they do.
caadc58bea should fix
https://github.com/zed-industries/zed/issues/11037
Release Notes:
- N/A
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
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
* Otherwise is_maximized always returns `true`
Release Notes:
- Fixed maximized state. Tested with a dummy maximize/restore button
with the `zoom()` (not implemented yet). Without the right `maximized`,
in toggle zoom function is not possible to call `set_maximized()` or
`unset_maximized()`.
```rust
fn zoom(&self) {
if self.is_maximized() {
self.borrow_mut().toplevel.unset_maximized();
} else {
self.borrow_mut().toplevel.set_maximized();
}
}
```
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
With the recent Linux rewrite, I attempted to simplify the number of
wrapper structs involved in the Linux code, following the macOS code as
an example. Unfortunately, I missed a vital component: pointers to the
platform state, held by platform data structures. As we hold all of the
platform data structures on Linux, this PR reintroduces a wrapper around
the internal state of both the platform and the window. This allows us
to close and drop windows correctly.
This PR also fixes a performance problem introduced by:
https://github.com/zed-industries/zed/pull/10343, where each configure
request would add a new frame callback quickly saturating the main
thread and slowing everything down.
Release Notes:
- N/A
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 reverts https://github.com/zed-industries/zed/pull/9392 and
fixes the regressions that led to the reversion.
Release Notes:
- N/A
---------
Co-authored-by: Ezekiel Warren <ezekiel@seaube.com>
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
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>
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
Release Notes:
- N/A
`DoubleBuffered` is not currently very necessary because we only care
about a single field `OutputState::scale` but I think it can be useful
for other objects as it's a fairly common pattern in wayland.
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>
This PR enables server side decorations on Wayland if possible. This is
stopgap solution, so that the window can be moved, resized and dragged
on Wayland sessions at all.
Since Wayland compositors can decide to force either mode (as in,
forcing server or client side decorations), this requires additional
handling in zed. Since zed doesn't provide any of that handling as of
now, as a temporary solution server side decorations are always
requested.
Release Notes:
- N/A
---
Right now the Wayland backend is using `xkb::State::key_get_utf8` as the
`key`, when it should be used as the `ime_key`. It also manages
pressing/releasing modifiers manually when this should be managed by the
display server.
This allows modifier combinations to work in more cases, making it an
alternative to https://github.com/zed-industries/zed/pull/7975, which
interprets what is now only used as the `ime_key` value as a `key`
value.
Adds initial keyboard and mouse input for Wayland (thanks to @gabydd and
@kvark for reference).
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
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 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>
