wayland: rebased and merge into master#2079
Conversation
Also use `im` crate to solve reentrancy on windows collection (a group of windows, rather than the ubiquitous Microsoft product).
while not 100% there implements significant improvements to the wayland backend. most (all?) examples seem to basic work. most outstanding work is integrating with the druid APIs cleanly, implement repeating keys, some point work, naturally performance fixes and finally there are some bugs when resuming from sleep.
6cda60d to
330f3c5
Compare
|
We also want CI for wayland backend, probably just need to copy druid/.github/workflows/ci.yml Lines 113 to 153 in 2d80ca0 |
|
agreed, can do it as part of the next PR if you want. CI env is very different than my environment, which isn't an issue but don't want to think about it for this one. =) |
|
I can do it tomorrow. wanted it because |
|
can you add the following commits: |
removes the need to use some unsafe code.
allows for us to replace inner surfaces dynamically. (necessary for layershells).
fix minor issue with global id
- fixes a seg fault when resizing the current window. - fixes a bug where even if no seg fault happens we skip painting.
while these changes don't fully implement a working copy/paste. I have confirm that when Clipboard::get_string is invoked the contents from the system clipboard are returned.
- bunch of other misc cleanups
- refactors some of the wayland connection code out of the application startup.
|
@emersion we talked, your concerns were understood. using unstable protocols by default comes with that risk. I'd expect the same potential risks from any of the unstable protocols. this isn't news to anyone. same with the xdg_output, or layershell. if it breaks its entirely not your problem. |
|
No, it has nothing to do about the protocols being "unstable". "unstable" protocols (in wayland-protocols parlance) just means that a separate protocol may supersede it at some point, but "unstable" protocols never see backwards-incompatible changes. See the wayland-protocols README. In other words, even if you use an "unstable" protocol, your client will never be broken by a protocol update. What I'm talking about here is very different. I'm saying that I'll make it so your clients won't even launch on purpose, to avoid having other clients be tempted to use privileged protocols they must not use.
Please take time to understand how Wayland works before making your points.
Yes, it is my problem, because it causes more work for me. I'm already spending a good chunk of time trying to convince you and explain that this pull request is doing the wrong thing. |
|
We have talked it out on IRC, and we're all good. :) In the wlroots team we're mainly worried about special protocols ending up used by normal clients when such use will be blocked in the future. @james-lawrence explained that this part is going away in the next PR, so while we find it odd that its included here, I guess that's just people having different git workflows. |
- remove wlr management api. - allow the application logic to make use of the code.
wayland: display refactor
8fdcd68 to
2451da9
Compare
|
@maan2003 this is ready to go, I pulled in changes from the next branch I was going to PR to resolve @emersion concerns. makes the PR larger than I wanted and makes it no longer a pure rebase but ./shrug. at this point I think with there will be 1 final small PR around layershell reinitializing unless I encountered something when working on my applications. I'll be opening up issues around the remaining work once the final PR is in for documentation/disccusion purposes for whomever takes up the torch next. ;) |
|
oh and of course I'll be avail if issues crop up. |
maan2003
left a comment
There was a problem hiding this comment.
Sorry for such a late review :/
|
Also, choice of using |
|
@maan2003 all good, its holiday season. =) |
|
@maan2003 generally speaking I recall some comment about moving to arc be default within druid but i could be misremembering. I'm fairly indifferent to the usage of either outside of what rust itself enforces or performance related issues. most (all?) of the RC usage is from the original branch I started this work off of. it seems slapdash because why I defaulted to using arcs and original branch defaulted to using RC. |
that is probably for druid only, we mostly use |
1bdb232 to
667ff0e
Compare
|
ah then it was a misunderstanding on my end. is the arc/rc stuff a blocker for this PR? would be easier for me to tackle after this is merged to limit the diverging from my private branch. |
29335c1 to
4145711
Compare
We can fix it later :) |
4145711 to
bdf6792
Compare
|
@maan2003 bump =) weekend is coming up have some bug fixes in my branch I'm planning on opening another PR for =) |
|
Sorry, I forgot to merge this. |
pull all the changes from wayland into master since we're down to just a few missing pieces in wayland (mostly pieces also missing within the x11 backend) time to let it soak in master.