-
Notifications
You must be signed in to change notification settings - Fork 499
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
Issue overwiew/prioritization as of 08/2022 #1463
Comments
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... |
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. |
That's totally fine, thank you for your investigation efforts! |
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. |
Has anyone attempted this recently? Specifically are there any forks or branches with this attempted where I might lend a hand? |
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. |
for client side decorations there is libdecor |
@johannesrld integrating 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. |
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
--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.Issues which seem to exhibit mass-issues but causes/actions are not clear yet
which
as it is on most shellsCombining those
twothree, we could maybe solve those in one dash through directly letting the shell find and call thenvim
binary (not doing thewhich
and path call workaround). But I haven't investigated there well enough to say which problems this could raise.set clipboard=unnamedplus
Some small final notes
I'll introduce some new issue tags, to be specific:
And also try to throw the
Windowing
and other tags on more issues.The text was updated successfully, but these errors were encountered: