Announcement

Collapse
No announcement yet.

KDE Is Getting A New Screenshot Utility, But No Wayland Support Yet

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • KDE Is Getting A New Screenshot Utility, But No Wayland Support Yet

    Phoronix: KDE Is Getting A New Screenshot Utility, But No Wayland Support Yet

    KDE Applications 15.12 will be presenting a new screenshot utility that's completely rewritten and replacing the original KSnapshot...

    http://www.phoronix.com/scan.php?pag...enie-KSnapshot

  • #2
    Originally posted by phoronix View Post
    rather than relying on Qt's built-in screenshooting APIs. XCB is used directly for the X11 back-end to take screenshots
    That's no anti-KDE'ish.
    The KDE would be to use the Qt API and improve that upstream.

    Comment


    • #3
      It's difficult a developer understands wayland word or that x11 is deprecated so I'll BOYCOT this useles deprecated utility.

      utilities have to be made in wayland state.

      Comment


      • #4
        Originally posted by Azrael5 View Post
        It's difficult a developer understands wayland word or that x11 is deprecated so I'll BOYCOT this useles deprecated utility.

        utilities have to be made in wayland state.
        If you had read the article, you would know that it is the lack of common screenshot support across Wayland compositors that currently doesn't make it viable to add support for all of them.

        Remember that taking a screenshot is a priviledged operation in a Wayland context, something that needs support from the compositor.

        I wouldn't be surprised if the application will be capable of taking screenshots soon when be used with kwin-wayland as the compositor, mabye it even already does, but to say it "supports Wayland" would imply it works with all compositors.

        Which it can only start to do once the compositor developers have agreed on a respective shared protocol extension.

        Cheers,
        _

        Comment


        • #5
          Originally posted by anda_skoa View Post
          If you had read the article, you would know that it is the lack of common screenshot support across Wayland compositors that currently doesn't make it viable to add support for all of them.
          He thinks X is deprecated, he's not aware Wayland is not the default on any distribution yet. Your technical explanation will probably fall of dear ears.
          I wonder what DE is he using if he's boycotting everything that doesn't support Wayland?

          Comment


          • #6
            Originally posted by Azrael5 View Post
            It's difficult a developer understands wayland word or that x11 is deprecated so I'll BOYCOT this useles deprecated utility.

            utilities have to be made in wayland state.
            Read the article next time. The kwin wayland compositor screenshot APIs are not ready yet, and without those APIs you can't take screenshots. They have gotten as far as they can without those APIs, the application actually runs under Wayland, but it can't take screenshots because, again, there is currently no way to do so. Wayland support will come after the kwin screenshot APIs are ready.

            Comment


            • #7
              Hi, I'm the KScreenGenie/KSnapshot 2.0 maintainer

              Originally posted by Awesomeness View Post
              The KDE would be to use the Qt API and improve that upstream.
              Actually, no. You have to realise that Qt is a generic toolkit that's used not only in Linux/Windows/Mac OS X, but also Android, Blackberry, QNX, Solaris, BSD and a whole bunch of exotic platforms. KDE officially supports only Windows, Linux and OS X.

              The way Qt supports all of these platforms is through a module called QPA - QPlatformAbstraction. A QPA module exists for every single supported platform, but not all the QPAs support every possible function. In Linux, for example, in the Qt4->Qt5 transition the X11 layer was changed from XLib to XCB, which fixed a few bugs but introduced a few more. Critically, taking single-screen screenshots on multi-monitor set-ups is somewhat ambiguous.

              Then there's turnaround time. Patching a KDE module may take mere hours for a KDE developer, but getting a patch into Qt is a long-drawn out process. This is by virtue of the fact that the patch must be tested rigorously to check if we don't unintentionally break something on other platforms, and to check that we don't break ABI compatibility with previous versions of Qt, etc. etc. To be fair, even the KDE Frameworks have the very same rigorous coding standards, because the Frameworks are cross-platform and have strict ABI compatibility rules.

              So the easiest thing to do, especially when no one else is going to use the functionality that I'm implementing, is to fix issues in my own application. Since taking screenshots on Wayland is a privileged action, I'm going to have to bypass Qt and directly use the Wayland APIs in KScreenGenie anyway, so I might as well use the XCB APIs directly for my X11 backend too. It allows me a much greater degree of control. I am using KDE components too - libKScreen, to be exact - because it's a nice library that has both a native XRandR backend and an eventual Wayland backend which gives me information about monitor layouts that I can use to properly take single-output screenshots in multi-monitor setups.

              Additionally, there's a new feature in KSG that's not available in KSnapshot - that I can now take composite shots of pop-up menus along with their parent windows. This will be impossible to do without access to the native XCB API (although the current code uses as much API from KWindowSystem as possible, dropping to pure XCB only when necessary). Also, this kind of functionality has no place in Qt. In KWin's screenshot effect - maybe, especially as that's what is going to provide screenshot support in Wayland eventually. But not in Qt.

              As for Wayland support, the moment a stable API becomes available, it's just one file with 5-6 functions that need to tap into those APIs that needs to be implemented to have Wayland support. It is highly unlikely, though, that Wayland will have a proper screenshot API by December, in which case we'll just have to tap directly into KWin's screenshot effect. That'll mean under Wayland KSG/KSnapshot 2.0 will only capture images when KWin is the compositor.

              Comment


              • #8
                Originally posted by BaloneyGeek View Post
                Hi, I'm the KScreenGenie/KSnapshot 2.0 maintainer



                Actually, no. You have to realise that Qt is a generic toolkit that's used not only in Linux/Windows/Mac OS X, but also Android, Blackberry, QNX, Solaris, BSD and a whole bunch of exotic platforms. KDE officially supports only Windows, Linux and OS X.
                Still, I understand that it's a lot of work to move something like this in Qt, but wouldn't each of the supported platforms have use for the screenshot capability? (The answer is probably NO, otherwise it would have been done by now, but I don't see the reason behind it.)

                And thanks for the lengthy explanation, it's nice to get a little more technical details than Michael can access sometimes.

                Comment


                • #9
                  Originally posted by bug77 View Post

                  Still, I understand that it's a lot of work to move something like this in Qt, but wouldn't each of the supported platforms have use for the screenshot capability? (The answer is probably NO, otherwise it would have been done by now, but I don't see the reason behind it.)

                  And thanks for the lengthy explanation, it's nice to get a little more technical details than Michael can access sometimes.
                  Pretty much every QPA plugin has support for full-screen screenshots. The magic happens when you try to do advanced stuff, like take shots of single windows, or a single widget in a window. That kind of image acquisition support has no place in Qt. In KSnapshot we used to use the full-screen screenshot API along with bits from QDesktopWidget and QScreen to figure out what to crop, but now we use pure XCB and libKScreen for the same effect. The added advantage is that with libKScreen, we (KDE) controls the code, not Qt, and we can get it changed much faster than we can upstream, and also support use cases that don't align with Qt's goals.

                  Comment


                  • #10
                    Nice, kscreenshot was definitely one of the missing pieces.
                    ## VGA ##
                    AMD: X1950XTX, HD3870, HD5870
                    Intel: GMA45, HD3000 (Core i5 2500K)

                    Comment

                    Working...
                    X