Issue overwiew/prioritization as of 08/2022

[MultisampledNight]

Continuation in spirit of #1061. Though I have literally no idea how difficult or easy each one of these things are, I'll just list them to have a handy overview at one place. Order has no meaning except for grouping purposes.

Issues which are actionable

• The winit story (Wayland, IME and like)
  • Handled in Update to use new upstream unified keyboard branch #1789.
• Transparency "lagging behind" one redraw
  • Enable transparency on startup #1457
• Draw our own client-side decorations
  • GNOME on Wayland doesn't do server-side window decorations and seemingly won't. I have no idea why, but basically two options here:
    • Use libadawaita to match GNOME's look. Could be a bit of library configuration and setup hassle. Also maybe upstream winit has this already done.
    • Draw it ourselves. Allows for some nice effects.
  • Inconsistent titlebar on Gnome Wayland #1445
  • Non-standard window decorations in Gnome/Wayland #728
• Better error handling
  • Currently, we have to ask literally every time a crash happens to re-run Neovide with --nofork or, even better, to provide reproduction steps. Which is pretty much useless with setup issues. It'd be nice if we'd wrap the whole main into another function which is just catching an unwind and writes an error log with some environmental information.
• Shells printing stuff in their startup sequence
  • Neovide does not start on MacOS 12.4 on Apple Silicon #1345
  • Handled in fix: Improve nvim detection #1946.

Issues which seem to exhibit mass-issues but causes/actions are not clear yet

• Shells setting $PATH in their resource file, not profile
  • Failed launching neovide on macOS from brew #1373
• Some shells don't seem to implement which as it is on most shells
  • Can't start Neovide when using nushell because of "which" command #1498

Combining those twothree, we could maybe solve those in one dash through directly letting the shell find and call the nvim binary (not doing the which and path call workaround). But I haven't investigated there well enough to say which problems this could raise.

• macOS notarization and signing
  • macOS is moving to a point where Apple and companies basically require everyone shipping code on their platform to also apply for a developer program/ID, which seems to cost 99$ a year (see the In-App purchases on the App Store for Apple Developer, though we might be able to circumvent that fee through fee-waives as we're an open-source and not-for-profit project, though this might not apply since we're not a legal entity) and involves some CI pipeline setup on our side. I guess everyone can think their own part about that, but please empathize with a user's perspective
  • Failed launching neovide on macOS from brew #1373 (partly)
  • “Neovide” can’t be opened because Apple cannot check it for malicious software. #1479
• Font rendering
  • Something's badly wrong with font rendering in general. Probably we're doing both layouting (a full block with color doesn't match a space with background color) and swash usage (text's more vivid/bold than it should be, though this might just be an effect of the layouting) wrong
  • Character height gets rendered subtly wrong, but only at certain sizes #1453
  • Font rendering issues #1325
  • Problems rendering text with Unicode #1318
  • Red line next to character #1225
  • ╱ unicode pattern does not display as well as in the terminal #1197
• Crashing on lua errors
  • Neovide freezes when a lua error occurs and I try to close it first. #1429
  • Click to focus on MacOS should not move the cursor #1343
• Snap doesn't specify its plugs correctly/other snap issues I have no idea about
  • UPDATE: The snap is removed for now
  • Snap won't start on Ubuntu 20.04 with AMD GPU #1372
  • Neovide fails to run after snap install #1081
  • neovide crashes on start-up (installed with snap on Fedora 34 & 35) #1060
• Mouse cursor doesn't match actually sent position when forming a visual selection
  • Mouse pointer may be drifted while click and drag selection. #1368
• Cursor and scroll animation has small "hiccups"
  • Cursor animation is glitchy on the right window with multigrid enabled #1239
  • Smooth scrolling is jumpy sometimes #1334
• Remote clipboard seems to be broken with set clipboard=unnamedplus
  • neovide copy/paste is not working when connect to remote neovim #1331

Some small final notes

I'll introduce some new issue tags, to be specific:

• snap
• macos
• multigrid
• shell

And also try to throw the Windowing and other tags on more issues.

[TobTobXX]

I happen to have previous experience trying to migrate from winit v0.25 to v0.27. I could try my hand at this, though no guarantees made, as I don't know what patches should be rebased etc...

[TobTobXX]

Ok, so while the Linux implementation (rust-windowing/winit#1932) got rebased recently (7. Jul) and is now only 44 commits behind mainline v0.27.1, the MacOS implementation (rust-windowing/winit#1890) never got rebased since its start (2020-12-05). master was merged a couple of times, but that makes rebasing only harder. To make this even more confusing, the branch it is supposed to be pushed to (winit/new-keyboard) got horse-pushed recently (12. Jun) so there now exist some sizeable merge conflicts, even before rebasing...

... and I haven't even tried merging the winit/new-keyboard branch into the winit/master branch yet.

I'll take my hand off of this for now, sorry. It seems that merging/rebasing that mess would need extensive knowledge of the platform-specific implementation of winits keyboard system.

[MultisampledNight]

That's totally fine, thank you for your investigation efforts!

[j-xella]

Are there any plans to address the broken clipboard issue? This is a major obstacle to day-to-day work !

#1331
#1411

[MultisampledNight]

Clipboard is not completely broken. The issue you linked is about remote clipboard, which works in a different manner and personally I have no interest in investigating there. If nothing's publicly mentioned, probably no one is working on them, though I'll include the issue here now if you want to.

[Atif-Mahmud]

... Wait AND update our fork. Instead of cherry-picking everything that seems interesting, completely ditch the current state of things on our fork and start from upstream again, again integrating all PR changes. Since they seem like they've been rebased recently, this could be quite easy.

Has anyone attempted this recently? Specifically are there any forks or branches with this attempted where I might lend a hand?

[MultisampledNight]

Most of that work happens locally in the way of resolving rebase conflicts, I fear. TobTobXX higher up in the issue seemed to try it, but looking at their neovide-winit fork they didn't seem to push their WIP state.

Also be aware that resolving the rebase conflicts requires a good understanding of all platform APIs winit supports, though I guess you might be able to rebase the macOS one only if you're familiar with Cocoa, for example.

[johannesrld]

for client side decorations there is libdecor

[fredizzimo]

@johannesrld integrating libdecor is most likely never going to happen. We are already using https://github.com/polymeilex/sctk-adwaita, indirectly through winiti, which was chosen by them in favour of libdecor. See rust-windowing/winit#2263 and rust-windowing/winit#1967 for the reasoning. And yes libdecor-rs has been abandoned for two years https://github.com/cmeissl/libdecor-rs

Personally, I don't think the window decoration issue on Wayland Gnome is our priority anymore, we already have basic support, and there's nothing we can do better than ´sctk-adwaita ourselves`. So, further improvements should be done there, and Neovide will take those improvements into use when new releases are done and the dependencies updated. That also benefits the Rust echo system as a whole, rather than being something Neovide specific.