This week in KDE: GTK CSD support and more!

I’ve got big news today. Something major landed: full support for the GTK_FRAME_EXTENTS_ protocol, which hugely improves the user experience for running GTK apps that use client-side decoration headerbars! This includes GNOME apps and an increasing number of 3rd-party GTK apps too. In particular, these apps now display window shadows and have proper resize areas without needing to use a thick border. Here’s how Gedit now looks:

It’s almost native-looking! And it fits right in with the rest of your apps.

I’d like to extend a big thanks for Vlad Zahorodnii who has been working hard on this for months! The feature lands in the upcoming Plasma 5.18 LTS.

But wait, there’s more…

More New Features

Bugfixes & Performance Improvements

User Interface Improvements

How You Can Help

Do you love KDE’s apps? Would you like to help develop for them? I knew you would. 🙂 It’s really fun, and you can have a major impact. Many of KDE’s apps are quite beginner-friendly; among them are Dolphin, Elisa, and Spectacle. See the full list here! These apps’ maintainers as well as KDE’s experienced developers are happy to help and mentor newcomers who want to contribute. For more information on how to get help and who to ask, see https://community.kde.org/Get_Involved#Start_Here.21

More generally, have a look at https://community.kde.org/Get_Involved and find out more ways to help be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Finally, consider making a tax-deductible donation to the KDE e.V. foundation.

40 thoughts on “This week in KDE: GTK CSD support and more!

    1. That’s a huge improvement, as in the current state a GTK window above another window with the same background color cannot be distinguished from one another. 🙂 Good job!!!

      Liked by 1 person

  1. > The cursor no longer unexpectedly changes its appearance when hovering over a GTK app by default (Kai Uwe Broulik, Plasma 5.18.0)

    This bug report still says “reported” only?

    Like

  2. Just..wow. Plasma 5.18 IS “the year of the linux desktop”, for sure. It’s very satisfying to be able to follow the progress easily here on your site, Nate, thanks a lot. Also it’s very reassuring to know that there are so many talented people working together on things big and small to continuously make KDE better. It really does make a difference while choosing a desktop/distro when you know that there’s more than one or two people doing everything and there’s a risk they just give up one day, and that you can reach out easily to someone that can help with any issue that you may encounter. This is all just great, enjoyable fun, very cool and excuse my French: GODDAMN FANTASTIC! I thank you, my computers thank you and come Plasma 5.18 all my friends/familys computers (old and new) will thank you as well.

    Liked by 1 person

    1. I feel similarly. One-man projects or very small teams are always a bit disconcerting. But KDE’s developer community is humongous! The pace of improvement is pretty amazing. Believe it or not, sometimes I get a bit frustrated that it isn’t even faster! There are so many cool things in the pipeline that are like 80%+ done. But that’s the way all projects are, ultimately. the old 80/20 rule strikes again!

      Like

        1. Mounting remote locations in Dolphin. PolicyKit support in KIO. Seamlessly discovering Windows samba shares in Dolphin. All in progress and close to completion!

          Like

  3. > The weather widget’s weather station configuration window now has a better default size and margins, and the “no weather stations found” text no longer overflows the view (me: Nate Graham, Plasma 5.17.4):

    Is it a bug that there are alternating row colors displayed in the screenshot, although no items were found?

    Like

  4. Wow! This is amazing!

    Thank you Nate for informing us about everything in KDE, and a big thank you to all contributors of KDE.

    Best thing about KDE: It’s build by users, for users!

    Like

    1. It’s up to the apps themselves to either hook into KIO directly (as LibreOffice does) or use the GTKFilePickerNative API and force the use of XDG desktop portals when in a Plasma environment (as Firefox and Thunderbird and many GNOME apps do). But there’s nothing we can do on the KDE side to force this.

      Please file bugs against apps that use the GTK file dialog when run on Plasma!

      Like

  5. I have a question about GTK CSDs and their behavior logic.

    What will happen when the titlebar is stripped (by latte or some script)? This is a typical option for global menus and maximized windows. Stripping titlebar ensures that there is no redundant stripe since all functionality is moved to upper panel (buttons, appmenu, titles plus other panel’s elements).

    I assume that the CSD will be exempt from that stripping. Unless latte developer will do his magic and creates another widget that will move CSD functionality into panel… All is possible 😉

    Anyway, what about the buttons and title? This could create doubled elements, so I’m curious if the new option already has a solution for global menu with upper panel setup behavior? I know that this isn’t the official available setup but maybe the new CSD option included option for it? If not, it will be brought to the table by many users so it’s better to think of it before the official release.

    I kinda enjoy the idea about the additional widget with CSD buttons where we could tweak, turn on/off certain elements but is there any space for that on a panel? It’s already pretty filled with buttons, title, menu, system tray, clock and few additional widgets (like for weather).

    In general, I think it’s a good idea to support officially CSDs. Plasma always has been inclusive, even if some elements weren’t native to it and that is why it makes it so powerful. One DE that rules them all ;D.

    Like

    1. CSD apps have no titlebar to strip. I imagine that titlebar-stripping apps will just ignore these windows. I *think* it would be technically possible to remove the close/minimize/maximize buttons from the headerbar when it’s maximized as we do have a hook into their ordering and visibility. I don’t know if that’s been implemented yet though. Our next thing is going to be trying to make order and visiblity of those buttons in CSD headerbar apps respect the settings you’re using for SSD apps.

      Liked by 1 person

      1. Yeah. Especially when we move buttons to the left side so the CSD buttons order may look weird.
        Having an option to enable stripping buttons in maximized mode would be awesome. The CSD stripe would be effectively like a toolbar. A bit weird and empty one in maximized mode but nothing is perfect. CSDs have cons, and we have to accept it, especially that there are no standards to CSDs (different elements on each program).

        Like

  6. Great stuff! Regarding “Visible notifications now move out of the way rather than disappearing when the System Tray popup is open in the same area”: 1. the video doesn’t play on Firefox for Android even though the play/pause button toggles and the progress indicators animate. 2. In Fedora the notification about “17 updates available” obscures the Plasma pop-up behind it with the details of the packages and the button to update; will this fix address that usability glitch?

    Like

  7. hello Nate, I noticed that a while ago you switched off windows borders. Now I cannot distinguish the edge of a window overlapping another window. That is not very handy. It this a temporary situation? Thanks! John

    Like

      1. Thanks for the friendly advice Nate, I always get a good feeling from you!
        I did not change any shadow settings (*)
        I did not manage to find in system settings a setting to turn on/off shadows (**), the information on Google seems outdated, kde system setting changes (changed?) a lot each release 🙂
        From my Google search I got the idea to use System Settings – Hardware – Display and Monitor to switch the Rendering backend to OpenGL3.1 (it was on 2.0) and that did the trick. No idea why this was on 2.0.

        Anyway, my GUI system is much more usable with shadows!

        (*) I always use the default settings due to this reasoning: Don’t trust my system otherwise since I feel it is impossible for developers to test all scenario’s (Exponential increase of complexity / all combinations).

        (**)
        system setting crashed on my while I navigated some pages (sorry, I do not remember the actual scenario).

        Like

        1. Glad you got it working! I guess your graphics hardware is somehow subtly incompatible with OpenGL 2.0.

          The System Settings crash should be fixed in the next Frameworks release (coming out in two days).

          Like

  8. A lot of these posts have window decorations without the white circle in the close button. That looks so much better, and yet I could never find where you can obtain that or an announcement for a system-wide theme change. Could you explain it to me?

    Like

    1. System Settings > Application Style > Window Decorations > Breeze > Click on inline Edit button (it looks like a pencil) > Uncheck “Draw a circle around close button”

      Like

  9. It turns out that the CSD support feature is not obvious and we don’t know what it really is.

    My suspicion is, that instead letting GTK to draw the CSD (and then use GTK theming system), all elements will be imported and processed by kwin and then draw by kwin. This will ensure compatibility with aurorae themes or at least with breeze only. However, if it would be for breeze only, it would rise many usability questions – what about other aurorae themes? Plus what about personalization (moving buttons to other side, appmenu, additional buttons,

    Latte’s developer on the other hand assumed that the support means only window/SCD shadows.

    So as you see “CSD support” expression is too vague and not telling much and everyone has different idea what it will be doing. The attached screenshot/mockup(?) suggests rather my theory. If it was only for shadows, this wouldn’t be a big deal worth the title IMO. I hope that because the CSD elements will be processed, there will be some layer in between deciding where those elements will be put and how they will behave, so we get proper options like “disable window buttons in maximized mode” otherwise we will have the same issue as right now, doubled buttons (when buttons are reflected on an upper panel with global menu).

    Like

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s