Sir_Cmpwn

104 ms·

1. 931.▲
   by Sir_Cmpwn 8y ago

   That's just Gnome's opinion. wlroots and KDE are working together to standardize these sorts of protocols, just in the past few months our screenshot and screen capture protocols began to stablize.
2. 932.▲
   by Sir_Cmpwn 8y ago

   Well, woe is you then.
3. 933.▲
   by Sir_Cmpwn 8y ago

   The answer is "it depends on how much work you want to put into making custom protocols for these purposes". >Is it possible to implement an interaction bound to a global hotkey (e.g. middle click) that takes the current select
4. 934.▲
   by Sir_Cmpwn 8y ago

   I'd have to forward declare everything, which is annoying. It's a C thing.
5. 935.▲
   by Sir_Cmpwn 8y ago

   >[xdg-shell] is implemented by literally who? Uh... everyone. Mutter, Kwin, qwayland, wlroots, wlc, Sway, waymonad, Way Cooler, Weston, Enlightenment, and Mir all support it, as well as clients like GTK+, Qt, GLFW, SDL, EFL... Look, you
6. 936.▲
   by Sir_Cmpwn 8y ago

   Oooh, that's very cool. Thanks for the links.
7. 937.▲
   by Sir_Cmpwn 8y ago

   No, it's definitely poorly thought out. This is one of the problems that we're trying to deal with over in the wlroots camp.
8. 938.▲
   by Sir_Cmpwn 8y ago

   That doesn't have anything to do with what I said.
9. 939.▲
   by Sir_Cmpwn 8y ago

   There's already been universal standards under discussion for a long time, for example xdg-shell for application windows. The recent discussions are attempting to make more standards, and has been going on for 2 or 3 years now. This
10. 940.▲
    by Sir_Cmpwn 8y ago

    Same, a crash will kill all of your applications. But that's also what happens when xorg-server crashes. The difference is that window management is usually handled in a separate process, and if that process crashes you don't lose
11. 941.▲
    by Sir_Cmpwn 8y ago

    Yes.
12. 942.▲
    by Sir_Cmpwn 8y ago

    This is FUD. One of wlroots core goals from day one has been to promote the standardization of cross-desktop protocols that allow for these features. We have already addressed two of the points you brought up, namely screenshots and screen
13. 943.▲
    by Sir_Cmpwn 8y ago

    This solves a different problem. Say actor A makes a website and uses CDNs provided by actor B. This protects users from actor B changing their scripts, but not from a malicious actor A. In this case I'm presuming ProtonMail is actor A
14. 944.▲
    by Sir_Cmpwn 8y ago

    Any of these projects could use your help :) https://github.com/swaywm/wlroots https://github.com/swaywm/wlroots/wiki
15. 945.▲
    by Sir_Cmpwn 8y ago

    We haven't forgotten about you, but we could use your help if you want it done fast. We've made some important progress towards supporting this functionality recently. A protocol our people have been working on is currently underg
16. 946.▲
    by Sir_Cmpwn 8y ago

    Not that it matters. They could silently replace it with a backdoored script and your browser would never tell you it happened. And to preempt the ProtonMail rep who is probably going to respond to this comment, I know that you can run the
17. 947.▲
    by Sir_Cmpwn 8y ago

    You don't have to be impressed, but I don't necessarily think it's disingenuous. A "small" Wayland compositor which doesn't use a library like wlroots is nigh impossible. The code for handling DRM+KMS alone is
18. 948.▲
    by Sir_Cmpwn 8y ago

    It was, but when it became clear that Wayland was winning they changed gears and started developing it into a generic Wayland compositor instead.
19. 949.▲
    by Sir_Cmpwn 8y ago

    >Does Wayland even have a mechanism to allow the compositor to tell the application that it is time to draw another frame? Yes, Wayland will tell you when it's time for another frame. >If I give the compositor a bitmap every 60th
20. 950.▲
    by Sir_Cmpwn 8y ago

    Actually, the repository I linked to does not do much more driver stuff than wlroots does. The xorg drivers are maintained in separate trees: https://cgit.freedesktop.org/xorg/ Most modern xorg drivers depend heavily o
21. 951.▲
    by Sir_Cmpwn 8y ago

    Assuming you did some kind of primitive `find . -name "*.c" | wc -l` kind of operation to arrive at this number, you also got all of the rootston code. Rootston is a test compositor we use for working on wlroots but it's not
22. 952.▲
    by Sir_Cmpwn 8y ago

    TinyWM also needs all of this code: https://cgit.freedesktop.org/xorg/xserver/ ~500,000 lines of code that wlroots does not depend on, but who's counting.
23. 953.▲
    by Sir_Cmpwn 8y ago

    Kind of. Weston is a reference compositor, it exists to demonstrate the features of wayland.xml and act as a testbed for Wayland development. These days though I think people are better off reading the wlroots source code than the Weston co
24. 954.▲
    by Sir_Cmpwn 8y ago

    Yeah, we feel the same way. We've recently standardized a protocol[0] for negotiating server side decorations and client support is underway for Qt and GTK+. [0] https://cgit.freedesktop.org/wayland/wayland-protoco
25. 955.▲
    by Sir_Cmpwn 8y ago

    Without Xlib and the X11 server, so would TinyWM.
26. 956.▲
    by Sir_Cmpwn 8y ago

    >I guess the question really is, could you write a general compositor, which just handle inputs and output, and then use that compositor to run any number of different desktop environments where the authors technically doesn't need
27. 957.▲
    by Sir_Cmpwn 8y ago

    Thanks <3
28. 958.▲
    by Sir_Cmpwn 8y ago

    My blog posts: https://duckduckgo.com/?q=site%3Adrewdevault.com+wayland&ia=...
29. 959.▲
    by Sir_Cmpwn 8y ago

    Reading through this source code should tell you that pretty much any user interaction paradigm is possible with Wayland. I am the maintainer of Sway[0], a drop-in replacement for the i3 tiling window manager of X11 fame, and of wlroots[1],
30. 960.▲
    by Sir_Cmpwn 8y ago

    The package for xdg-shell is likely called "wayland-protocols".