zed-industries
Drop target improvements
This introduces multiple improvements to the drop targets.
Hitbox shape
Currently, hitboxes are rectangles, where the vertical ones reach all the way to the ends, which reduces the space for the horizontal ones, making the hitboxes a bit awkward in the corners. This new approach just determines the closest side.
Visual representation:
Hitbox size
The width of the hitbox was currently always 8 rem all around. In setups with many columns or rows, or when the font size was very large, this could potentially overlap the center hitbox, not allowing to drop a tab without another split. Now the width of the hitboxes are a fraction of the smaller size of its parents width and height. This makes sure the hitboxes have the same width all around, but never fully block the center hitbox.
I've also made this value configurable through the new drop_target_size config which takes a f32 fraction and is set to 0.2 by default.
Not sure if this is worth mentioning, but this technically allows to remove the split hitboxes all together by setting it to 0.0, or removing the center hitbox by setting it to any value >=0.5. Not that this is necessary, but it would be possible now.
Larger visualization
The visual overlay when using one of the side hitboxes were also 8em wide. Since their logical size now changed, and it can't currently be represented with GPUI (without abusing the canvas element), I made the visual feedback take half of the width or height of the available space, just like how other editors do this.
Also, the opacity/alpha value set by a theme is currently ignored. This change now respects the themes opacity for it!
Respect alpha value
Currently, the alpha value of drop_target.background is ignored. Even the default themes set a value that is overwritten by a hard coded value. I have removed this hard coded value and it now respects the alpha value.
This change affects existing themes, see https://github.com/zed-industries/zed/pull/10643#issuecomment-2059641528
No more lag while dragging over gutter
It looks like the editor had a small optimization to drop events when hovering the gutter. This also happens while dragging a tab over the gutter, and causes some stuttering. Please correct me if this wasn't just a small optimization, but I could not derive a different reason for this code to exist.
Here is a video that tries to show all those changes with a before on the left, and the after on the right:
https://github.com/zed-industries/zed/assets/1282767/f97f3420-513f-410f-a1c8-7966429ad348
Release Notes:
- Added
drop_target_sizeconfig option - Improved drop target hitbox
- Fixed issue where themes opacity for
drop_target.backgroundwas ignored - Fixed issue where dragging a tab over the gutter would cause it to stutter
Since one of the changes makes it so the opacity drop_target.background is respected, themes without an alpha value for this would display it as fully opaque.
I've went through all currently added theme extensions, and those are all themes that either have no alpha value, or use (maybe on accident) FF for a fully opaque drop area background:
- https://github.com/bswinnerton/base16-zed
- https://github.com/catppuccin/zed
- https://github.com/nauvalazhar/cosmos
- https://github.com/dracula/zed
- https://github.com/ThomasAlban/everforest-zed
- https://github.com/xqsit94/zed-xqsit-theme
- https://github.com/skarline/zed-fleet-themes
- https://github.com/AdinAck/graphene
- https://github.com/kdubrovsky/kiselevka
- https://github.com/pcminh0505/ktrz-monokai-zed-theme
- https://github.com/xerodark/zed-material-theme
- https://github.com/sonodima/zed-mellow
- https://github.com/borngraced/monosami
- https://github.com/mikesun/msun-dark-zed
- https://github.com/napalmpapalam/napalm-theme-zed
- https://github.com/elGusto/night-owlz
- https://github.com/rkunev/oceanic-next
- https://github.com/jbisits/penumbra-zed
- https://github.com/mshaugh/poimandres.zed
- https://github.com/segersniels/zed-smooth
- https://github.com/srcery-colors/srcery-zed
- https://github.com/ssaunderss/zed-tokyo-night
- https://github.com/trojanfoe/visual-assist-dark.zed
- https://github.com/d1y/vscode_dark_plus.zed
- https://github.com/skarline/zed-xcode-themes
- https://github.com/Brunowilliang/zedspace
How should we deal with this? Open an issue mentioning this change in all of them?
Very cool! I can't speak to the technical portion, but the change to make it respect the passed color with alpha looks great š
How should we deal with this? Open an issue mentioning this change in all of them?
Can we patch around this by checking the generated color's opacity, and only apply the 75% when the color is fully opaque?
How should we deal with this? Open an issue mentioning this change in all of them?
Can we patch around this by checking the generated color's opacity, and only apply the 75% when the color is fully opaque?
I thought about doing that as well, but that would mean a theme can't purposely make it fully opaque. And there are a few which might already attempted to do this. I'd rather go through a bit of pain now, than introduce a workaround that will be even worse to deal with later.
Edit: for the record, I don't mind pinging the maintainers of all affected themes, and waiting until a reasonable majority of them have updated their themes. But maybe this is a good opportunity to think about how "breaking" (won't really break anything) theme changes are handled in the future.
Maybe a versioning system could be introduced to the theme files, which could be used to handle changes like this going forward. For example, there would be a file containing the needed changes to bump the format version, so for v2 you need to explicitly set the opacity. If the version is < v2 or not stated, it defaults to 0.75. Then once all themes migrate, old code could be removed. Iād say it would be best to get such a system up sooner rather than later, because there will be other changes in the future.
