While working on implementing `add_recent_documents` for Windows, I
found that the process is significantly more complex compared to macOS.
On macOS, simply registering the `add_recent_documents` function is
enough, as the system handles everything automatically.
On Windows, however, there are two cases to consider:
- **Files opened by the app**: These appear in the "Recent" section (as
shown in the screenshot, "test.txt") and are managed automatically by
Windows (by setting windows registry), similar to macOS.
- **Folders opened by the app**: This is more complicated because
Windows does not handle it automatically, requiring the application to
track opened folders manually.
To address this, this PR introduces a `History Manager` along with
`HistoryManagerEvent::Update` and `HistoryManagerEvent::Delete` events
to simplify the process of managing recently opened folders.
https://github.com/user-attachments/assets/a2581c15-7653-4faf-96b0-7c48ab1dcc8d
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Similar to #20826 but keeps the Swift implementation. There were quite a
few changes in the `call` crate, and so that code now has two variants.
Closes#13714
Release Notes:
- Added preliminary Linux support for voice chat and viewing
screenshares.
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
Issues found:
* audio does not work well with various set-ups using USB
* switching audio during initial join may leave the client with no audio
at all
* audio streaming is done on the main thread, beachballing certain
set-ups
* worse screenshare quality (seems that there's no dynamic scaling
anymore, compared to the Swift SDK)
This reverts commit 1235d0808e.
Release Notes:
- N/A
See https://github.com/livekit/rust-sdks/pull/355
Todo:
* [x] make `call` / `live_kit_client` crates use the livekit rust sdk
* [x] create a fake version of livekit rust API for integration tests
* [x] capture local audio
* [x] play remote audio
* [x] capture local video tracks
* [x] play remote video tracks
* [x] tests passing
* bugs
* [x] deafening does not work
(https://github.com/livekit/rust-sdks/issues/359)
* [x] mute and speaking status are not replicated properly:
(https://github.com/livekit/rust-sdks/issues/358)
* [x] **linux** - crash due to symbol conflict between WebRTC's
BoringSSL and libcurl's openssl
(https://github.com/livekit/rust-sdks/issues/89)
* [x] **linux** - libwebrtc-sys adds undesired dependencies on `libGL`
and `libXext`
* [x] **windows** - linker error, maybe related to the C++ stdlib
(https://github.com/livekit/rust-sdks/issues/364)
```
libwebrtc_sys-54978c6ad5066a35.rlib(video_frame.obj) : error LNK2038:
mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't
match value 'MD_DynamicRelease' in
libtree_sitter_yaml-df6b0adf8f009e8f.rlib(2e40c9e35e9506f4-scanner.o)
```
* [x] audio problems
Release Notes:
- Switch from Swift to Rust LiveKit SDK 🦀
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: Conrad Irwin <conrad@zed.dev>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Michael Sloan <michael@zed.dev>
**Clipboard Behavior on Windows Under This PR:**
| User Action | Zed’s Behavior |
| ------------------- |
-------------------------------------------------- |
| Paste PNG | Worked |
| Paste JPEG | Worked |
| Paste WebP | Worked, but not in the way you expect (see Issue section
below) |
| Paste GIF | Partially worked (see Issue section below) |
| Paste SVG | Partially worked (see Issue section below) |
| Paste BMP | Worked, but not in the way you expect (see Issue section
below) |
| Paste TIFF | Worked, but not in the way you expect (see Issue section
below) |
| Paste Files | Worked, same behavior as macOS |
| Copy image in Zed | Not tested, as I couldn’t find a way to copy
images |
---
**Differences Between the Windows and macOS Clipboard**
The clipboard functionality on Windows differs significantly from macOS.
On macOS, there can be multiple items in the clipboard, whereas, on
Windows, the clipboard holds only a single item. You can retrieve
different formats from the clipboard, but they are all just different
representations of the same item.
For example, when you copy a JPG image from Microsoft Word, the
clipboard will contain data in several formats:
- Microsoft Office proprietary data
- JPG format data
- PNG format data
- SVG format data
Please note that these formats all represent the same image, just in
different formats. This is due to compatibility concerns on Windows, as
various applications support different formats. Ideally, multiple
formats should be placed on the clipboard to support more software.
However, in general, supporting PNG will cover 99% of software, like
Chrome, which only supports PNG and BMP formats.
Additionally, since the clipboard on Windows only contains a single
item, special handling is required when copying multiple objects, such
as text and images. For instance, if you copy both text and an image
simultaneously in Microsoft Word, Microsoft places the following data on
the clipboard:
- Microsoft Office proprietary data containing a lot of content such as
text fonts, sizes, italics, positioning, image size, content, etc.
- RTF data representing the above content in RTF format
- HTML data representing the content in HTML format
- Plain text data
Therefore, for the current `ClipboardItem` implementation, if there are
multiple `ClipboardEntry` objects to be placed on the clipboard, RTF or
HTML formats are required. This PR does not support this scenario, and
only supports copying or pasting a single item from the clipboard.
---
**Known Issues**
- **WebP, BMP, TIFF**: These formats are not explicitly supported in
this PR. However, as mentioned earlier, in most cases, there are
corresponding PNG format data on the clipboard. This PR retrieves data
via PNG format, so users copying images in these formats from other
sources will still see the images displayed correctly.
- **GIF**: In this PR, GIFs are displayed, but for GIF images with
multiple frames, the image will not animate and will freeze on a single
frame. Since I observed the same behavior on macOS, I believe this is
not an issue with this PR.
- **SVG**: In this PR, only the top-left corner of the SVG image is
displayed. Again, I observed the same behavior on macOS, so I believe
this issue is not specific to this PR.
---
I hope this provides a clearer understanding. Any feedback or
suggestions on how to improve this are welcome.
Release Notes:
- N/A
This aligns the Windows platform implementation with a code style
similar to macOS platform, eliminating most of the `Cell`s and
`Mutex`es. This adjustment facilitates potential future porting to a
multi-threaded implementation if required.
Overall, this PR made the following changes: it segregated all member
variables in `WindowsPlatform` and `WindowsWindow`, grouping together
variables that remain constant throughout the entire app lifecycle,
while placing variables that may change during app runtime into
`RefCell`.
Edit:
During the code refactoring process, a bug was also fixed.
**Before**:
Close window when file has changed, nothing happen:
https://github.com/zed-industries/zed/assets/14981363/0bcda7c1-808c-4b36-8953-a3a3365a314e
**After**:
Now `should_close` callback is properly handled
https://github.com/zed-industries/zed/assets/14981363/c8887b72-9a0b-42ad-b9ab-7d0775d843f5
Release Notes:
- N/A
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>
