-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wayland: Window controls and drag #11525
wayland: Window controls and drag #11525
Conversation
Is it at all possible for this to be hidden behind a (default-on) option which otherwise has Zed opt into SSD? |
I think that's something we'd like to have, but that we don't need to block this PR on :) |
That is a perfectly understandable approach. Though I would point out prior examples of this leading to de-prioritization and eventual complete dropping of the features - as postponement means later re-opening & re-designing now-cold areas of the codebase vs. factoring it into the original design. The cost of the two are not the same and just like the postponement decision is perfectly reasonable, so is the decision to at that point go "the required resources are not a good investment vs. the niche audience it serves" - just as it has been for an ocean of MS Windows tools never ported. My point being those dependent on SSD are better served with clear "No, this is not something we want" communication now vs. "Stick around and eventually we will make a decision" :) Similarly reasonable responses include: "Just use Gnome" and "Just force Zed to run X11 until support for that is dropped by either end" - classed neatly with the non-porting of Windows apps :) |
Nobody said this isn't gonna get implemented. If you have followed the development of the linux client so far, you would notice that things get merged rather quickly, even in an incomplete state, so that others can iterate and improve those implementations. If you are that concerned that it won't be implemented, check out how the default decoration state is set, add a config for it, and make a PR. I'm sure @mikayla-maki is gonna merge it in no time, just like she did with all the other linux related PRs! |
I'm sorry - I did not mean to suggest that anyone did. I was hoping my seeding of smilies and distinct lack of exclamation points could help diffuse a read like that :) What I was trying to express (in the bits you did not quote) was a concern that postponement rather than working it into the the current PR, working in the exact same area, could easily lead to a scenario where non-support would be the logical and reasonable outcome. The bit you did quote was a call for clear communications, with arguments for that attached. I did not think it unreasonable at time of writing, but I do apologize for the obvious offense caused. "Do it yourself" was missing from my list of reasonable responses - I had not thought to pre-empt that one, but perhaps that would have helped guard against a negative read. I would absolutely enjoy learning Rust some day. This scale seems a bit wild as a starting point, but I can of-course always hope to one day find overlap of available time and opportunity to execute on it :) |
* titlebar reuses some of the icons from the asset pack
525643c
to
10e61f3
Compare
I just try to compile and test on fedora 40 gnome 46 and wayland and its work as inded :) |
Thank you! |
Based on zed-industries#11046 - Partially fixes zed-industries#10346 - Fixes zed-industries#9964 ## Features Window buttons ![image](https://github.com/zed-industries/zed/assets/71973804/1b7e0504-3925-45ba-90b5-5adb55e0d739) Window drag ![image](https://github.com/zed-industries/zed/assets/71973804/9c509a37-e5a5-484c-9f80-c722aeee4380) Native window context menu ![image](https://github.com/zed-industries/zed/assets/71973804/048ecf52-e277-49bb-a106-91cad226fd8a) ### Limitations - No resizing - Wayland only (though X11 always has window decorations) ### Technical This PR adds three APIs to gpui. 1. `show_window_menu`: Triggers the native title bar context menu. 2. `start_system_move`: Tells the compositor to start dragging the window. 3. `should_render_window_controls`: Whether the compositor doesn't support server side decorations. These APIs have only been implemented for Wayland, but they should be portable to other platforms. Release Notes: - N/A --------- Co-authored-by: Akilan Elango <akilan1997@gmail.com>
This (mostly) allows the CSD added in #11525 to work in X11. It's still a bit buggy as it detects a second window drag right after the first one finishes, but it's probably better to change the way window drags are detected in the title bar itself (as that causes other issues). The CSD can be tested by changing the return value of `should_render_window_controls` to true. Also fixes F11 crashing. Release Notes: - N/A
Based on #11046
Features
Window buttons
Window drag
Native window context menu
Limitations
Technical
This PR adds three APIs to gpui.
show_window_menu
: Triggers the native title bar context menu.start_system_move
: Tells the compositor to start dragging the window.should_render_window_controls
: Whether the compositor doesn't support server side decorations.These APIs have only been implemented for Wayland, but they should be portable to other platforms.
Release Notes: