Language Selection

English French German Italian Portuguese Spanish

KDE Squashing Bugs Ahead of Release

Filed under
KDE
  • KDE Applications 18.12 Release Candidate Available For Testing

    Ahead of the official release next month, KDE Applications 18.12 is now available in release candidate form for those wanting to test out this latest slew of KDE app updates.

  • Applications 18.12 Release Candidate

    Today KDE released the Release Candidate of the new versions of KDE Applications. With dependency and feature freezes in place, the KDE team's focus is now on fixing bugs and further polishing.

    Check the community release notes for information on tarballs and known issues. A more complete announcement will be available for the final release.

  • Do your part! Squash bugs for Kdenlive!

    On the 2nd of December, the Kdenlive team will be holding an open bug-squashing day in preparation for the major refactoring release due in April 2019. Everybody is invited!

    This is a great opportunity for developers of all levels to participate in the project. The team has triaged hundreds of reports, closing more than a hundred of them in the past month. Kdenlive developers have also made a list of entry-level bugs you can get started with.

    For the more seasoned developers, there are plenty of options - be it a shiny feature request or a challenge to polish some non-trivial edges. To hack Kdenlive, you need to know C++, Qt, QML or KDE Frameworks. Those with knowledge of C can join the fun by improving MLT, the multimedia framework Kdenlive runs on.

    Even if you have no programming experience, you can still help by testing fixes and features, as well as by triaging more bug reports.

More in Tux Machines

AMD Staging Another Fix To Try Correcting Some Raven Ridge Systems On Linux

AMD Raven Ridge APUs have been out for more than one year now and at least under Linux can still be quite problematic depending upon the particular motherboard BIOS and other factors. Fortunately, while Raven 2 and Picasso APU support is appearing to be in better shape, the AMD open-source developers haven't forgot about these problematic Raven 1 systems. Out today is the latest patch trying to help those with original Raven Ridge systems. This latest hopeful fix is now skipping over loading the DMCU firmware for Raven Ridge. DMCU in this context is the Display Micro-Controller Unit and is the micro-controller used for Panel Self Refresh (PSR) and similar functionality. Read more Also: Intel 19.20.13008 Open-Source Compute Stack Restores Broadwell To Production Quality

Graphics: Intel, XWayland and Vulkan

  • Intel Linux Graphics Driver Adding Support For The Mule Creek Canyon PCH
    Mule Creek Canyon is the PCH to be paired with Intel Elkhart Lake processors. Elkhart Lake as a reminder is the Gemini Lake SoC successor that will feature Gen11 class graphics and now thanks to the open-source Intel Linux graphics driver we know that new PCH is the Mule Creek Canyon. Mule Creek Canyon doesn't appear to be widely publicized up to this point but appeared in today's latest open-source development activity. Mule Creek Canyon is the new PCH for Elkhart Lake and required some minor changes around Port-C remapping that differ from other Icelake graphics hardware.
  • XWayland Receive An EGL-Based GLX Provider, Helping Various Games On Linux
    A notable improvement was merged into the "xserver" Git tree for the eventual X.Org Server 1.21 release that will improve the support for various Linux games relying on XWayland for running under a Wayland compositor.
  • Vulkan 1.1.109 Released With Two New Intel Extensions
    Vulkan 1.1.109 was released today as the latest update to this graphics/compute specification ahead of the US holiday weekend. With two weeks having passed since Vulkan 1.1.108 there are a few different documentation corrections/clarifications. There are also two new vendor extensions contributed by Intel.

Rob Szumski’s Keynote and Abby Kearns Interview at CloudNativeCon & KubeCon

GNOME: Theming, Mutter and Sprint 1

  • App Devs Ask Linux Distros to “Stop Theming Our Apps”
    A group of independent Linux app developers have written an open letter to ask wider GNOME community to ask: “stop theming our apps”. The letter is addressed to the maintainers of Linux distributions who elect to ship custom GTK and icons themes by default in lieu of upstream defaults. By publicising the issues they feel stem from the practice of “theming” it’s hoped that distros and developers might work together to create a “healthier GNOME third party app ecosystem”.
  • A Group of Independent Linux App Developers Has Asked Wider GNOME Community To 'Stop Theming' Its Apps
  • GNOME's Mutter Makes Another Step Towards X11-Less, Starting XWayland On-Demand
    GNOME 3.34 feature development continues at full-speed with a lot of interesting activity this cycle particularly on the Mutter front. On top of the performance/lag/stuttering improvements, today Mutter saw the merging of the "X11 excision" preparation patches. The Mutter patches by longtime GNOME developer Carlos Garnacho around preparing for X11 excision were merged minutes ago.
  • Georges Basile Stavracas Neto: New Background panel, Calendar search engine, GTK4 shortcut engine (Sprint 1)
    GNOME To Do is full GTK4 these days. Which means it’s both a testbed for new GTK4 features, and also a way to give feedback as an app developer for the GTK team. Unfortunately, it also means To Do is blocked on various areas where GTK4 is lacking. One of these areas is keyboard shortcut. Last year, Benjamin wrote a major revamp for keyboard shortcuts. As part of this cycle, I decided to rebase and finish it; and also make To Do use the new API. Unfortunately, I failed to achieve what I set myself to. Turns out, adding a shortcuts engine to GTK4 is more involving and requires way more context than I had when trying to get it up to speed. I failed to predict that one week would have not been enough to finish it all. However, that does not mean all the efforts were wasted! The rebasing of the shortcuts engine was a non-trivial task successfully completed (see gtk!842), and I also fixed a few bugs while working on it. I also got a working prototype of GNOME To Do with the new APIs, and confirmed that it’s well suited — at least for a simpler application such as To Do. In retrospect, I believe I should have been more realistic (and perhaps slightly pessimistic) about the length and requirements of this task.