KDE

Let’s go for my web review for the week 2022-08. The United States of Amazon: The Day Amazon Sent the FBI to Take My Family’s Bank Accounts Tags: amazon, legal Wow, this indeed looks like a major flaw in the US legal system. It’s at least a good ... [More] illustration at how major corporations can leverage it for bullying people. https://medium.com/@amy_riveter/the-united-states-of-amazon-the-day-amazon-sent-the-fbi-to-take-my-familys-bank-accounts-b5172b4ddda3 Google Tag Manager, the new anti-adblock weapon | Tracking pixel Tags: tech, google, surveillance, privacy New way to track… this is really an arm race. Let’s see how the adblockers react to this. https://chromium.woolyss.com/f/HTML-Google-Tag-Manager-the-new-anti-adblock-weapon.html Project Zero: A walk through Project Zero metrics Tags: tech, security Interesting statistics on how responsive several vendors and projects are regarding security vulnerabilities. https://googleprojectzero.blogspot.com/2022/02/a-walk-through-project-zero-metrics.html?m=1 The Fastest GIF Does Not Exist Tags: tech, gif, browser Sometimes there can be interesting deviations between specs and implementations. Clearly this is still the case for the GIF format, with surprising results. https://www.biphelps.com/blog/The-Fastest-GIF-Does-Not-Exist Data Races in Python, Despite the Global Interpreter Lock Tags: tech, python, multithreading Contrary to popular belief, data races are definitely a reality in Python. Don’t be fooled, the Global Interpreter Lock won’t prevent them. https://verdagon.dev/blog/python-data-races How I Shaved 187MB Off United Airline’s 439mb iOS App Tags: tech, bloat Please remember to strip your symbols when you build software for production before it gets that bad… https://telkins.dev/posts/how-i-shaved-187mb-off-uniteds-airlines-439mb-ios-app/ Moving the kernel to modern C [LWN.net] Tags: tech, linux This indeed would be nice to see such a move. We’ll see if that’s doable or not in the near future I guess. https://lwn.net/SubscriberLink/885941/01fdc39df2ecc25f/ You can’t capture the nuance of my form fields Tags: tech, web, frontend This is so true… It’s just almost always better to use standard components in my experience. In particular it makes things easier for keyboard navigation and accessibility. https://drewdevault.com/2021/06/27/You-cant-capture-the-nuance.html Five Things You Notice When You Quit the News Tags: news, information A good reminder about why I stopped watching the news years ago. https://www.raptitude.com/2016/12/five-things-you-notice-when-you-quit-the-news/ Bye for now! [Less]

KDE e.V. makes it known that the KDE League is to be wound down and dissolved. Remaining assets of the League are to be transferred to KDE e.V. Interested parties are invited to comment. KDE e.V., the legal entity representing the KDE community, and ... [More] KDE League, Inc. (the “League”) are about to enter into an agreement to wind down and dissolve the League and transfer all of its remaining liquid assets (after paying the costs of dissolution) to KDE e.V. The League was formed by the KDE community in 2000 as a not-for-profit independent organization for the promotion of KDE in the United States. It represented a joint effort among KDE e.V. and numerous companies operating in the KDE ecosphere. Sadly, the organization has now been inactive for over fifteen years, without engaging in any fund-raising nor promotional activities, having been unable to obtain quorum for meetings of its board or membership. The organization retains some unspent funds collected during its early years. Thanks to renewed efforts by Andreas Pour, its former Chair, Chris Schlager, its President, and the board of KDE e.V., the League and KDE e.V. have agreed to dissolve the League and transfer remaining liquid assets to KDE e.V. This move to dissolve the League is our shared understanding of a “best effort” way to satisfy the provisions of the statutes of the League while remaining true to the intent of the League members who graciously donated funds to the League to promote KDE and the KDE community. Pursuant to the agreement, subject to resolving any objections brought by any member of the League, the League will be dissolved and its remaining assets transferred to KDE e.V. approximately 2 months after publication (february 25th, 2022) of this agreement, on april 30th, 2022. Any objections to this agreement may be sent to the KDE e.V. board by email (kde-ev board (at) kde.org) or by mail or courier to KDE e.V. Prinzenstraße 85 F 10969 Berlin Germany, and by email to the League at (KDELeague (at) AdvancedPlacementLaw.com) and must be received by april 28th, 2022. The full text of the agreement will be made available shortly. [Less]

I added some KRunner web shortcuts recently to KIO (MR600, MR631), and I’d like to tell you about them since they made my life significantly easier, and they might make yours easier too if you contribute to KDE. The inclusions from MR600, namely ... [More] Invent and Invent Repo, were added in KDE Frameworks 5.88, whereas the … Continue reading "KFluff – New KRunner web shortcuts for development and user support" [Less]

I added some KRunner web shortcuts recently to KIO (MR600, MR631), and I’d like to tell you about them since they made my life significantly easier, and they might make yours easier too if you contribute to KDE. The inclusions from MR600, namely ... [More] Invent and Invent Repo, were added in KDE Frameworks 5.88, whereas the … Continue reading "KFLuff – New KRunner web shortcuts for development and user support" [Less]

We are happy to announce the release of Qt Creator 7 Beta2!

We are pleased to announce that Plasma 5.24.2 is now available in our backports PPA for Kubuntu 21.10 (Impish Indri). The release announcement detailing the new features and improvements in Plasma 5.24.2 can be found here. To upgrade: Add the ... [More] following repository to your software sources list: ppa:kubuntu-ppa/backports or if it is already added, the updates should become available via your preferred update method. The PPA can be added manually in the Konsole terminal with the command: sudo add-apt-repository ppa:kubuntu-ppa/backports and packages then updated with sudo apt full-upgrade IMPORTANT Please note that more bugfix releases are scheduled by KDE for Plasma 5.24, so while we feel these backports will be beneficial to enthusiastic adopters, users wanting to use a Plasma release with more rounds of stabilisation/bugfixes ‘baked in’ may find it advisable to stay with Plasma 5.22 as included in the original 21.10 (Impish Indri) release. The Kubuntu Backports PPA for 21.10 also currently contains newer versions of KDE Gear (formerly Applications) and other KDE software. The PPA will also continue to receive updated versions of KDE packages other than Plasma, for example KDE Frameworks. Issues with Plasma itself can be reported on the KDE bugtracker [1]. In the case of packaging or other issues, please provide feedback on our mailing list [2], IRC [3], and/or file a bug against our PPA packages [4]. 1. KDE bugtracker: https://bugs.kde.org2. Kubuntu-devel mailing list: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel3. Kubuntu IRC channels: #kubuntu & #kubuntu-devel on irc.libera.chat4. Kubuntu ppa bugs: https://bugs.launchpad.net/kubuntu-ppa [Less]

I read a comment on Phoronix recently that reminded me why I love KDE Plasma: “KDE is normal and it works” We can ignore the argument to which this is a response, and forgive alcade for confusing the name of the community with the desktop ... [More] environment. Regardless, “KDE is normal and it works” is in a nutshell what I think makes KDE Plasma such a unique and shining point of light in the FOSS world. Plasma uses a normal, familiar layout: Panel on the bottom with an app launcher, pinned apps, system tray, and clock; desktop icons; visible buttons that mostly have text labels; minimize/maximize/close buttons on windows. You know, normal stuff. You can change everything, but it starts out normal, unlike other desktop environment projects that are explicitly abnormal–being controversially opinionated about matters of design or having an unusual component layout. This is fine! Their departures from what’s normal may in fact be better, and their developers and users they certainly think so. But tons of people out there don’t want “may be better”, they want “normal.” And that’s fine too. Our software is for them. And KDE Plasma works. It has its bugs, but it is basically a solid and reliable piece of technology that isn’t missing major features, either because of a lack of resources or because design decisions preclude supporting them. It is not a hobbyist science project missing key functionality that might break entirely. It doesn’t re-invent itself every year or two and become something different that might stop meeting your needs or tastes. It has actionable plans for adapting to industry changes surrounding it that are actively being carried out; it is not on a path to become obsolete or a technical dead end. No, it’s just it’s an imperfect and boring piece of infrastructure you can nonetheless rely on. I think the world needs something with those characteristics, and and that’s why I like it and work on it. [Less]

Tuesday, 22 February 2022. Today KDE releases a bugfix update to KDE Plasma 5, versioned 5.24.2. Plasma 5.24 was released in February 2022 with many feature refinements and new modules to complete the desktop experience. This release adds a week's ... [More] worth of new translations and fixes from KDE's contributors. The bugfixes are typically small but important and include: Plasma Desktop Hot New Stuff: Only trust the expiration date if it’s less than 24 hours. Commit. Emoji Selector: Use a more appropriate icon for the Symbols page. Commit. Fixes bug #450380 Don’t install two copies of kcm_fontinst. Commit. View full changelog [Less]

CopperSpice is a collection of libraries – a toolkit, if you will – for developing cross-platform applications in C++. That should sound familiar to KDE people, and it is an LGPL v2.1 fork of Qt from around 2013. In many ways, it is a purely-QWidget ... [More] continuation, which modernized (C++17, CMake) much earlier than Qt itself. There are some applications that use it, but CopperSpice is rarely packaged (Arch only until today!) for use as a system library. Its consumers probably build CopperSpice locally as part of a product, and this post explains why (and what I did to make to packageable on FreeBSD). Kitchensink, a demo-application Above is a screenshot of kitchensink, the “demo application” for CopperSpice. It is a multiple-document-interface window, showing off various widgets and things. Graphics scenes, multimedia, and a clock. You can never have too many clocks. Diamond Editor, a CopperSpice-based text editor .. and here’s diamond, a compact text editor that uses CopperSpice libraries. Packaging Principles Packaging CopperSpice took longer than expected, because I was working under a set of (initially implicit-to-me) assumptions of what it means to package something for FreeBSD. Retroactively, I’m writing them down: Must install everything to (somewhere under) /usr/local, or $(LOCALBASE). Ideally the latter, but I can live with a fixed prefix to start with: very few people choose for /opt or so in the FreeBSD world. Must be co-installable with Qt5 and Qt6 without being overly weird about it. CopperSpice applications that are packaged should be able to run from the command-line, with no special settings or user-specific configuration files. They should use the system-wide CopperSpice libraries. No vendoring (or minimal vendoring) and no duplication of libraries. Executables belong in /bin/, data in /share/ somewhere. hier(7) makes some of this explicit. I did not pick these specifically to be annoying for CopperSpice, but these are the reasons that it took a week worth of source-wrangling (mostly CMake bits) to get it to work. The code is just fine, and frankly if I’d thrown up my hands and said “this doesn’t need to package tidily” it could have been a 15 minute job. Patching the Code The CopperSpice source code is fairly nice. It “just works” – compiles largely warning-free except for some missing override statements – and the resulting libraries seem to work. I say “seem to work” because a library has no function on its own: it needs an application to use the library, to get something done. Naively building an application – kitchensink and diamond are applications from the CopperSpice authors – spits out a directory which contains an application, and some resources (a program icon, configuration files) and .. copies of the CopperSpice libraries. This is where packaging and upstream collide. There are no airbags to cushion the blow. As far as I can tell, upstream just drops everything into a single directory. So there is no shared-library and no need for any kind of co-installability. Applications aren’t intended to be installed in a shared prefix. Libraries are endlessly copied. From a “product” kind of software release this makes a bit of sense: take the tarball, extract it somewhere, run the software from there. There’s a FreeBSD “binary package” of diamond from upstream: it’s a tarball that extracts to . (!). But I can extract it wherever I like, and then run diamond from there. If I had an /opt/diamond this would work even for multiple users on the system: but it is anathema to software packaging in the “old school”. The one code patch I applied to libCsCore was to give it a default plugin path, so that on FreeBSD it looks in the shared, system-wide, installed location of the libraries. That removes the need to copy those plugin libraries around – but then we need to fight the build. Fighting the Build I have patched 28 CMake files in the build to not do silly things. “Silly” is, like I’ve said, in the eye of the beholder: from a the-product-is-a-tarball perspective, RPATH is a thing that happens to other people. For a packager, RPATH set to $ORIGIN (that specific string) is like the first step on the road to R’lyeh. So here’s a list of things I patched : don’t set RPATH to $ORIGIN set a default plugin path to search link publicly to pthreads (this is a FreeBSD thing) install includes into a /copperspice/ subdirectory (co-exist with Qt, which e.g. uses /qt5/) install plugins to the directories where they are searched for That last one takes a bit of explanation: the default build-and-install of CopperSpice puts libraries (libCsCore.so), platform-plugins (CsGuiXcb), and support bits (CsMultimedia_gst) all in one install directory. During an application build-and-install, the libraries are copied, and so are the plugins that the application needs. The plugin libraries are copied into /platforms/. So it is the consumer (application) that is responsible for shuffling the bits into a directory hierarchy that matches what the internal code expects. In FreeBSD packaging, I’ve patched the install locations so that platform-plugins end up in a subdirectory /platforms/ under the default plugin path; that’s different from how it would install them itself, but it makes it possible to find the installed plugins, in shared locations. In other words: I’ve forced a shared plugin installation on CopperSpice, and now I need to help the libraries and applications understand that that shared location exists. Fighting the Application Build Since applications are expected to shuffle bits into place in their own installation-directory – and to duplicate the libraries – patching applications mostly means “don’t do that then”. There is no need to copy libCSCore.so to the local installation directory when it’s packaged and installed as a shared directory and meant to be a shared directory. Mostly this means commenting-out cs_copy_ lines in CMake. Similarly, applications that are written to install to a private, non-shared directory just bung everything in there: libraries, executable, data files. For packagers who think that CMAKE_INSTALL_DATADIR is a thing that should be followed (e.g. from the GNUInstallDirs module), this is a pain in the package because there are two things to change: patch the build to install data to the data directory patch the application to search for data in the data directory. For an application like diamond, syntax files are copied into a /syntax/ subdirectory; I patched the build to install to a location under /share/, but then the code searches for syntax files in the applicationDirPath() (e.g. in /usr/local/bin which is where the executable is installed). So cue up a patch to search somewhere else. After that, the application is pretty solid. Spot the Difference I haven’t tried to do much of anything with CopperSpice. So I can’t speak to the programming experience. From a product perspective, there is a culture of bung-it-in-a-directory which doesn’t work for me as a packager. It might work for non-packaged applications. It might fit really well with AppImage, or similar new(er)-style application delivery formats. Anyway, as a fork, CopperSpice inherited some of Qt’s excellent documentation, so here’s CopperSpice 1.73 and here’s Qt 5.15 documentation for QCoreApplication. The Qt version refers to the commercial-only release 5.15.8 as of this writing, so it may not match what is currently available to Open Source consumers of the KDE Patch Collection for Qt. Future Now that the first ports have landed, there’s some examples of how CopperSpice-based applications can be turned into ports, and there might be more. If you know of any that would make sense in the ports tree, drop me a note (or submit a PR via bugs.freebsd.org). CopperSpice kitchensink source diamond source Repology link Arch packaging I found this once I was about halfway through packaging, and used it to confirm that I was doing something sensible; Arch, like FreeBSD, ends up patching bits and bobs so that things install to “traditional” locations. Who did the real work: Ansel Sermersheim & Barbara Geller do all the heavy lifting upstream. I’m just shoving their bits into an uncomfortable BSD corset. [Less]

In my previous blog, I described my activity (left and right click training) for contributing it to GCompris and its implementation details. Over Since past 4 weeks, I’ve finalized the layout and of the activity, added the animation for animal cards ... [More] to move to their houses, and improved communication with my mentors. Explanation of the current progress To completely understand the explanation, I would advise you to read the idea behind the activity in my proposal (Here). The whole screen is divided into two sections(upper and lower). The upper section contains the houses of the animals on the left and right sides of the screen, and the lower section is for the animals; they appear in this area in random order and have a hover effect on them (their size and opacity increases). They are functional, which means on a click, they move to their houses located at the top left, and top right sides of the screen. Image – What next? – Currently, the animals appearing on the lower section of the screen are random, and sometimes they overlap with one another. As advised by my mentor(Allon) this could be solved using a grid in that area, so that the animal distribution is random yet uniform over the display area and it doesn’t overlap. So my next task is to implement this. – Placement of the animal houses on the screen is still hardcoded so I’ve to improve their codes. So that, when we move the house to some other coordinates, the animation of the animal moving towards their house, wouldn’t be affected. Thank you for taking out the time to read this. [Less]