Feeds

This week in Plasma: converging 6.2

Planet KDE - Fri, 2024-09-27 23:22

The core Plasma team remains deep in bug-fixing mode until Plasma 6.2.1, with lots of bugs fixed this week! This is the second-to-last week of development before the repos are frozen, and we’re cranking away like mad to get 6.2 in great shape. And it is indeed in very good shape so far. The worst issues we’re still seeing are related to notifications freezing and being mis-rendered, caused by recent changes made to fix another significantly less severe issue. So in the worst-case scenario, we can simply revert the changes before the final 6.2 release if we don’t manage to fix the regressions in time.

Something I hope we can prove to the world is that we’re capable of keeping Plasma stable over the long haul at the same time that we add features and refine the UI. Plasma 6.2 offers us a good opportunity for it!

Notable UI Improvements

Kickoff’s category icons have been made symbolic and monochrome (where the active icon theme supports it), which conforms better to the HIG and other apps, and mirrors a similar change done for Discover recently (me: Nate Graham, Plasma 6.2.0. Link):

On System Settings’ Region and Language page, the list of languages you can add to your system is now alphabetized by first letter (rather than by the hidden language code), and all the languages are properly capitalized (David Edmundson, Plasma 6.2.0. Link 1 and link 2)

In Plasma’s Digital Clock popup, calendar dates are now perfectly horizontally aligned even when some of them have text for events under them, and content can no longer sometimes overflow the header when using the combination of an alternate calendar plugin, certain third-party Plasma themes, and a large font size (Tusooa Windy, Plasma 6.2.0. Link 1 and link 2)

It’s now possible to get a standard context menu for the text field that appears when renaming files or folders on the desktop (Akseli Lahtinen, Plasma 6.2.0. Link)

System Settings’ Legacy X11 App Support page now supports the non-default settings highlighting feature (David Edmundson, Plasma 6.2.0. Link)

With the “Switch virtual desktops on screen edge” setting turned on, screen edges with no virtual desktop on the other side of them will no longer inappropriately show a glow anyway (Xaver Hugl, Plasma 6.2.0. Link)

Plasma notifications that show job progress no longer include a “Details” button if there are no extra details to show (Kai Uwe Broulik, Plasma 6.2.0. Link)

Windows no longer snap to the invisible edge where an auto-hidden panel would be when it’s visible (Vlad Zahorodnii, Plasma 6.2.0. Link)

Improved the margins and paddings for the “Add Widgets” sidebar (me: Nate Graham, Plasma 6.2.0. Link 1 and link 2):

When dragging an abstract representation of an app (from e.g. Kickoff, KRunner, or Task Manager) to the desktop, you’ll no longer be prompted to create an Icon widget out of it; you’ll now only have the “Copy” and “Link” options that create an actual file. The Icon Widget option was found to be confusing on the desktop because it doesn’t follow the normal semantics for desktop icons. This is part of a larger project to improve the usability of dragging apps to the desktop; expect more similar patches in coming weeks (me: Nate Graham, Plasma 6.3.0. Link)

Improved how System Settings’ Default Applications page communicates the situation where you’ve forced it to use an app that doesn’t actually advertise support for the file formats you want it to open (Marco Martin, Plasma 6.3.0. Link):

Don’t do this, it’s silly!

Every KWin effect listed on System Settings’ Desktop effects page that needs to be activated using a keyboard shortcut now mentions this in its caption (me: Nate Graham, Plasma 6.3.0. Link)

Plasma’s Sticky Note widget now has a symbolic monochrome widget when placed on a panel while using the Breeze icon theme. This completes the project to support symbolic panel icons for all of the widgets we ship by default! (Martin Frueh, Frameworks 6.7. Link 1 and link 2):

The “sleep and screen locking are inhibited” icon has gotten a redesign to hopefully make its meaning clearer (Andy Betts and Natalie Clarius, Frameworks 6.7. Link)

Notable Bug Fixes

Fixed a case where KWin would crash while you’re using the Khronkite tiling script (Vlad Zahorodnii, Plasma 6.2.0. Link)

Fixed a case where KWin could crash under certain circumstances while the Sheet effect is active (Vlad Zahorodnii, Plasma 6.2.0. Link)

Fixed a case where Plasma could crash and KWin could hang when you drag a layer from GIMP onto the desktop for some reason (David Edmundson, Plasma 6.2.0. Link)

Fixed a case where Plasma could crash when you chicken out of applying a Global Theme and its associated desktop layout after starting the process (Marco Martin, Plasma 6.2.0. Link)

Fixed a case where Powerdevil could crash on login (Alessandro Astone, Plasma 6.2.0. Link)

Fixed a way that System Settings’ KWin Rules and Device Automount pages could crash on close due to the use of nested event loops. Nested event loops are evil; get rid of them all! (Nicolas Fella, Plasma 6.2.0. Link 1 and link 2)

XWayland-using apps now have their accessibility properties exposed to screen readers as expected (David Edmundson, Plasma 6.2.0. Link)

When Flatpak has an oopsie and throws the dreaded “Aborted due to failure” message while you’re updating Flatpaks, Discover now wraps it in a nicer message telling you to try again later, which is usually enough to make it work the next time. This also fixes a related issue with Discover’s error dialogs that could cause them to not be large enough to show their content in some cases. Unfortunately we have not been able to actually fix the error itself or improve its wording yet, since it’s a bug in Flatpak itself (Akseli Lahtinen, Plasma 6.2.0. Link 1 and link 2)

Fixed an annoying bug that could cause some (not all) tiled CSD-using apps to become un-tiled when their headers are clicked. This affected VSCode specifically, but for other affected apps (e.g. Firefox) it can also be an app-specific issue (Vlad Zahorodnii, Plasma 6.2.0. Link)

On System Settings’ Shortcuts page, extremely long labels for shortcuts no longer sometimes overflow the layout (Akseli Lahtinen, Plasma 6.2.0. Link)

Fixed a bug that could cause maximized windows in multi-screen setups to be restored to the wrong screen after un-maximizing them with certain methods (Xaver Hugl, Plasma 6.2.0. Link)

Setting up the Meta key to toggle KWin’s Overview effect now works consistently after a reboot (Xaver Hugl, Plasma 6.2.0. Link)

Fixed an issue that prevented newly installed or deleted third-party splash screens from being shown or removed (respectively) from the relevant System Settings page at the right times (Marco Martin, Plasma 6.2.0. Link)

Fixed an issue that made it hard to trigger edges and hotcorners on screen edges that also have a Plasma panel in auto-hide mode (Xaver Hugl, Plasma 6.2.0. Link)

Fixed a graphical glitch affecting people using AMD and NVIDIA GPUs who maximize windows on a screen with a floating panel (Vlad Zahorodnii, Plasma 6.2.0. Link)

Fixed a color bug in Kirigami that caused the text of disabled buttons in various Kirigami-based apps to not look visually disabled, and also caused caused some pieces of text to inappropriately have a disabled appearance on System Settings’ Screen Locking page (Marco Martin and Arjen Hiemstra, Frameworks 6.7. Link 1 and link 2)

Fixed a series of sizing bugs affecting Kirigami.Dialog and its subclasses that could cause it to not be wide enough when assigned very long footer buttons (Akseli Lahtinen, Frameworks 6.7. Link 1 and link 2)

Fixed the ugly new Qt font selector dialog to at least not be completely visually broken when using a dark color scheme (Kai Uwe Broulik, Qt 6.8.0. Link)

Setting the GTK_USE_PORTAL=1 environment variable on your system to make GTK apps use the portal system (and hence use the superior KDE file dialog) no longer breaks font rendering in GTK apps quite horribly unless the GTK portal is also installed (Ilya Fedin, GTK 3.24.44, Link)

Other bug information of note:

Notable in Performance & Technical

Improved the speed with which the Plasma Task Manager widget’s context menu appears when recent document tracking is globally disabled, especially when using a networked home directory (Kai Uwe Broulik, Plasma 5.27.12. Link)

Fixed the binding loops affecting Kirigami.Dialog and its subclasses. These components are widely used, so this should make a difference (Akseli Lahtinen, Frameworks 6.7. Link)

How You Can Help

Please continue to test the Plasma 6.2 beta release! We’ve focused a lot on stability for this release and want to make sure we haven’t missed anything big before the final release in two weeks. Your bug reports do not go into a black hole; we triage every one! So enthusiastic testing and bug reporting is encouraged.

Otherwise, visit https://community.kde.org/Get_Involved to discover additional ways to 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! Or consider donating instead! That helps too.

Categories: FLOSS Project Planets

Zero to Mastery: Python Monthly Newsletter 💻🐍

Planet Python - Fri, 2024-09-27 21:44
58th issue of Andrei Neagoie's must-read monthly Python Newsletter: itertools Guide, Become an Open-Source God, and much more. Read the full newsletter to get up-to-date with everything you need to know from last month.
Categories: FLOSS Project Planets

Akademy 2024 in Würzburg

Planet KDE - Fri, 2024-09-27 20:00
Three weeks ago, I attended KDE Akademy 2024 in Würzburg, Germany. It was pretty exciting to meet my KDE friends after one year since last Akademy 2023! Travel drama Ideally whole trip should’ve taken just ~18 hours door-to-door but thanks to Lufthansa whole travel turned out to be of 48 hours in total including layovers. Flight cancellation and rebooking caused by travel to start way earlier than planned (Thursday 5:00 AM instead of planned 07:00 PM) and had to spend insane amount of time in layover.
Categories: FLOSS Project Planets

Python Morsels: The string split method in Python

Planet Python - Fri, 2024-09-27 18:00

Strings can be split by a substring separator. Usually the string split is called without any arguments, which splits on any whitespace.

Table of contents

  1. Breaking apart a string by a separator
  2. Splitting a specific number of times
  3. Splitting from the end of a string
  4. The string split method versus regular expressions

Breaking apart a string by a separator

If you need to break a string into smaller strings based on a separator, you can use the string split method:

>>> time = "1:19:48" >>> time.split(":") ['1', '19', '48']

The separator you split by can be any string. It doesn't need to be just one character:

>>> graph = "A->B->C->D" >>> graph.split("->") ['A', 'B', 'C', 'D']

Note that it's a little bit unusual to call the string split method on a single space character:

>>> langston = "Does it dry up\nlike a raisin in the sun?\n" >>> langston.split(" ") ['Does', 'it', 'dry', 'up\nlike', 'a', 'raisin', 'in', 'the', 'sun?\n']

It's usually preferable to call split without any arguments at all:

>>> langston = "Does it dry up\nlike a raisin in the sun?\n" >>> langston.split() ['Does', 'it', 'dry', 'up', 'like', 'a', 'raisin', 'in', 'the', 'sun?']

Calling the split with no arguments will split on any consecutive whitespace characters. So we're even splitting on a new line here in between up and like (up\nlike).

Also note that the split method without any arguments removes leading and trailing whitespace (note that the last element in the list is sun? rather than sun?\n).

There's one more split feature that's often overlooked: maxsplit.

Splitting a specific number of times

When calling split with a …

Read the full article: https://www.pythonmorsels.com/string-split-method/
Categories: FLOSS Project Planets

Carl Trachte: DAG Hamilton Graph Presented as SVG in Blogger

Planet Python - Fri, 2024-09-27 15:30

Through the kindness of the DAG Hamilton project team, I was able to secure an official svg version of the DAG Hamilton logo. It looks significantly better than the one I had generated with an online image to svg converter and is much smaller and easy to work with (4 kilobytes versus 200 kb). The DAG Hamilton graphviz graph now shows up in Blogger; it is unlikely to show up on the planet(python) feed. Blogger is not liking the code and svg I have included (complaints of malformed html). In the interest of preserving the rendering of the graph(s), I am constraining the text here to a few paragraphs

The first graph has the code provided. This graph is from a previous post.

The second graph represents the DAG Hamilton workflow for the production of the first graph. This is in keeping with the "Eat your own dogfood" mantra. I happen to like the DAG Hamilton dogfood as I've mentioned in previous posts. It allows me to visualize my workflows and track complexity and areas for improvement in the code.

The third one I did with a scaled down version of the code presented (no logos). I hand pasted the DAG Hamilton official logo into the third one. It is not subtle (the logo is huge), but it provides an idea of what one can do creatively with the logo or any svg element. Also, it shows the DAG Hamilton workflow for the graph with the respective two logos.

All the code is a work in progress. Ideally I would like to keep reducing this to the most simple svg implementation possible to get it to show up or "work." Realistically, I'm afraid to sneeze for fear Blogger will protest. For now, I'm leaving good enough alone. Links and thoughts on svg (there is at least one python library (orsinium-labs/svg.py) out there that is way more elegant in its treatment of the medium than my rough regular expressions / text processing) will have to wait for another post.

Thanks for stopping by.

Toy Web Scraping Script Run Diagram Web Scraping Functions Highlighted Legend datafile str commodity_word_counts dict info_dict_merged dict colloquial_company_word_counts dict data_with_wikipedia dict data_with_company dict parsed_data dict wikipedia_report str info_output str input function

run.py code

""" Hamilton wrapper. """ # run.py import sys import pprint from hamilton import driver import dag_hamilton_to_blogger as dhtb dr = driver.Builder().with_modules(dhtb).build() dr.display_all_functions('dhtb.svg', deduplicate_inputs=True, keep_dot=True, orient='BR') results = dr.execute(['defluffed_lines', 'scale_and_translation', 'logo_positions', 'captured_values', 'scaled_elements', 'translated_elements', 'hamilton_logo_data', 'scale_and_translation_hamilton_logo', 'fauxcompany_logo_data', 'scale_and_translation_fauxcompany_logo', 'svg_ready_doc', 'written_svg'], inputs={'svg_file':'web_scraping_functions_highlighted.svg', 'outputfile':'test_output.svg', 'hamiltonlogofile':'hamilton_official_stripped.svg', 'hamiltonlogo_coords':{'min_x':-0.001, 'max_x':4353.846, 'min_y':-0.0006, 'max_y':4177.257}, 'fauxcompanylogofile':'fauxcompanylogo_stripped_down.svg', 'fauxcompanylogo_coords':{'min_x':11.542786063261742, 'max_x':705.10684, 'min_y':4.9643821, 'max_y':74.47416391682819}})

Main DAG Hamilton functions (dag_hamilton_to_blogger.py)

# python 3.12 """ Make DAG Hamilton graph show up in Blogger. """ import re import sys import pprint import math import copy import reusedfunctions as rf VIEWBOX_PAT = (r'[ ]viewBox[=]["][-]?[0-9]+[.]?[0-9]*[ ][-]?[0-9]+[.]?[0-9]*[ ]' r'([0-9]+[.]?[0-9]*)[ ]([0-9]+[.]?[0-9]*)') # 5 coordinates. POLYGON_PAT = (r'[]polygon' r'.*([ ]points[=]["])([-]?[0-9]+[.]?[0-9]*)[,]' r'([-]?[0-9]+[.]?[0-9]*)[ ]' r'([-]?[0-9]+[.]?[0-9]*)[,]' r'([-]?[0-9]+[.]?[0-9]*)[ ]' r'([-]?[0-9]+[.]?[0-9]*)[,]' r'([-]?[0-9]+[.]?[0-9]*)[ ]' r'([-]?[0-9]+[.]?[0-9]*)[,]' r'([-]?[0-9]+[.]?[0-9]*)[ ]' r'([-]?[0-9]+[.]?[0-9]*)[,]' r'([-]?[0-9]+[.]?[0-9]*)["]') # 4 coordinates instead of 5. POLYGON_PAT_4 = (r'[]polygon' r'.*([ ]points[=]["])([-]?[0-9]+[.]?[0-9]*)[,]' r'([-]?[0-9]+[.]?[0-9]*)[ ]' r'([-]?[0-9]+[.]?[0-9]*)[,]' r'([-]?[0-9]+[.]?[0-9]*)[ ]' r'([-]?[0-9]+[.]?[0-9]*)[,]' r'([-]?[0-9]+[.]?[0-9]*)[ ]' r'([-]?[0-9]+[.]?[0-9]*)[,]' r'([-]?[0-9]+[.]?[0-9]*)["]') # x, y TEXTPAT = (r']text[ ].*' r'([ ]font[-]size[=])' r'["]([0-9]+[.]?[0-9]*)["]') # initial bezier curve notation PATHPAT = (r'[]path[ ].*' r'([ ]d[=]["]M)([-]?[0-9]+[.]?[0-9]*)[,]' r'([-]?[0-9]+[.]?[0-9]*)C') X_SIZE = 600 NEW_FIRST_LINE = '') IMAGE_FLAG = '') # 4 coords (arrow head). POLYGON_STR_4 = (r' points="{0:.3f},{1:.3f} {2:.3f},{3:.3f} ' r'{4:.3f},{5:.3f} {6:.3f},{7:.3f}"/>') PATH_START_STR = r' d="M{0:.3f},{1:.3f}C' PATH_STR_SEGMENT = ' {0:.3f},{1:.3f}' PATH_STR = r' {0:s}"/>' TEXT_STR = r' x="{0:.3f}" y="{1:.3f}"' TEXT_STR_FONT = r' font-size="{0:.3f}"' HAMILTON_LOGO_DIMENSIONS_PAT = (r'.*width[=]["]([0-9]+[.]?[0-9]*)px["][ ]' r'height[=]["]([0-9]+[.]?[0-9]*)px["][>]') FAUXCOMPANY_LOGO_DIMENSIONS_PAT = (r'[ ]width[=]["]([0-9]+[.]?[0-9]*)["][ ]' r'height[=]["]([0-9]+[.]?[0-9]*)["][ ][>]') # The official Hamilton logo splits the path into multiple # lines with the last one having the absolute location # ("C") of a bezier curve. HAMILTON_CHANGE_LINE_PAT = r'.*C[-]?[0-9]+[.]?[0-9]*' HAMILTON_TRANSFORM_FMT = (' transform="scale({scale:f}) ' 'translate({translate_x:f},{translate_y:f})" />') # One line of paths in Inkscape generated file. FAUXCOMPANY_CHANGE_LINE_PAT = r'.*d[=]["]m[ ]' # Inkscape put the closing tag /> on the following line. FAUXCOMPANY_TRANSFORM_FMT = (' transform="scale({scale:f}) ' 'translate({translate_x:f},{translate_y:f})"') # * - get rid of first 6 lines. # * - get rid of any line starting with: # # "
Categories: FLOSS Project Planets

Qt beyond 6.8 - Akademy 2024

Planet KDE - Fri, 2024-09-27 14:48

By Volker Hilsheimer

The Qt 6.8 should be around the corner by the time of Akademy, and we'll just have had our Qt Contributors Summit. This is a great time to look at some of the things we are working on for the upcoming releases, and where we intend to put our focus in the Qt Project and Qt Company R&D teams.

Categories: FLOSS Project Planets

QML in Qt6 - Akademy 2024

Planet KDE - Fri, 2024-09-27 14:38

By Ulf Hermann

The talk will give an overview on how the QML language has developed since Qt5. It will point out the opportunities for better performance and maintainability arising from new tooling and a more extensive type system. It will also point out some sore spots to look out for and show the direction in which we hope to develop the language going forward.

This is a good place to also discuss KDE's feature wishes for the QML language. Since a lot of those have come up lately, I will prepare some structured notes of what I've heard of so far and reserve some time for it.

Categories: FLOSS Project Planets

Pythonizing Qt - Akademy 2024

Planet KDE - Fri, 2024-09-27 14:30

By Cristián Maureira-Fredes

Since its release, Qt has been exposed to other languages in order to bring the amazing features to other communities, and to combine our beloved framework with other language-specific features.

After the success of many language bindings like Python, particularly for the PyQt and PySide projects, one can ask: "Once the language bindings are complete, is the project done?"

This talk presents the many implemented and planned features that PySide (a.k.a. Qt for Python) has, which go beyond to the known Qt API, and the motivation behind those decisions.

The goal of the presentation is to highlight a success story of bringing Qt to a completely different language, and also the lessons learned that could be used in order to improve the main Qt implementation in C++.

Attendees also will be exposed to the current project plan for future Qt releases, and new prototypes that have been discussed.

Categories: FLOSS Project Planets

Plasma Next - Visual Design Evolution for Plasma - Akademy 2024

Planet KDE - Fri, 2024-09-27 14:21

By Andy Betts

Soon after the launch of Plasma 6, many contributors requested updates for the visuals in the new Plasma Desktop. Touted as a stability release, Plasma 6 evolved to be more consistent, more bug-free than predecessors. The only thing missing from the release was a refreshed style.

Taking this feedback into consideration, a small team of designers from the team took to review and create a few exciting changes for the current visual style.

The team worked on creating:

  1. A graphical design system
  2. New color selection
  3. New font selection with specific sizes
  4. New grids and spacing system
  5. New editing workflow using Figma and Penpot
  6. Updating all 22px icons to a 24px size
  7. New shadows and blurs
  8. In addition to these, new components such as buttons, dropdowns, toggles, checkboxes, tooltips, progress indicators, sliders, badges, inputs.

We would like to provide a preview to the community of all of these changes and gauge interest. We would like to request the developer community for their help.

We also would like to follow up with a couple of BoFs to see how we could execute some of these elements given our constraints.

Above all, we believe in moving our visual style forward. We want to give our users a consistent look that helps them achieve the most they can using our systems.

Many thanks to Helden Hoierman, @manueljilin, @PhilipB, @depman, @Akseli, @Natalie Clarius, @nathanu, @DSLitvinov who have contributed so much to this project.

Categories: FLOSS Project Planets

Opt In? Opt Out? Opt Green! KDE Eco's New Sustainability Initiative - Akademy 2024

Planet KDE - Fri, 2024-09-27 14:12

By Joseph De Veaugh-Geiss

What consumers indicate they want, Free Software can provide, though many consumers may not know it .... yet! With the newly-funded project "Opt Green: Sustainable Software For Sustainable Hardware" KDE Eco aims to change that. A 2020 Eurobarometer poll found that 80% of European consumers believe manufacturers should make it easier to repair digital devices, while 50% indicate that the reason they purchase a new device is due to performance issues and non-functioning software. Free Software communities already understand that you don't need to buy new hardware to have an efficient, well-functioning, and up-to-date digital device; you just need the right software! Now, KDE Eco wants to make sure everyone else knows it, too.

For the next 2 years, the "Opt Green" initiative will bring KDE Eco's work on sustainable software -- and, in turn, sustainable hardware -- directly to consumers. And this is as good a time as ever. In 2025, the end of support for Windows 10 is estimated to make e-waste out of 240 million computers ineligible for Windows 11. One year later in 2026, at the earliest, macOS support for Intel-based Apple computers -- the last of which were sold in 2020 -- is predicted to end, rendering even more millions upon millions of functioning computers obsolete. Every one of these functioning, yet vendor-abandoned devices can stay out of the landfill and in use for years to come with sustainable Free Software. (Consider, by comparison, that only in 2022 did Linus Torvalds suggest ending support for 1989's Intel 486 processors. That's 33 years of Linux kernel support!)

By design, Free Software is right-to-repair software: it gives users control over their hardware by removing vendor dependencies and guaranteeing transparency and user autonomy. In this talk, I will present KDE Eco's new "Opt Green" project in terms of the whys, whats, and hows for bringing sustainable Free Software to new users. A target audience for the project are eco-consumers, those whose consumer behaviors are driven by principles related to the environment, and not necesssarily convenience or cost. Through online and offline campaigns as well as installation workshops, KDE Eco will demonstrate at fair-trade, organic, and artisinal markets the power of Free Software to drive down energy consumption and keep devices in use for years beyond official vendor support. With independent, sustainable software designed for users' needs, not vendors', it is possible to run efficient, cutting-edge software on the digital devices you already have at home or in your pocket. Opt green today! The most environmentally-friendly device is the one you already own.

Categories: FLOSS Project Planets

Openwashing - How do we handle (and enforce?) OSS policies in products? - Akademy 2024

Planet KDE - Fri, 2024-09-27 14:04

By Markus Feilner (grommunio, Feilner-IT, Press), Holger Dyroff (ownCloud), Richard Heigl (Hallo Welt! GmbH), Leonhard Kugler (Center for digital sovereignty (ZenDiS)), and Cornelius Schumacher (KDE)

Hosted by senior journalist Markus Feilner, the panel of prominent open source players will discuss the ongoing topic of openwashing and what we can or should do about it - from cloud to AI and public administration.

Especially in these three fields the term "opensource" has become a valuable asset, but more and more companies feel urged to call their solutions "Open Source". Despite the great success e.g. in public tenders, many company owners are actually still afraid of publishing source code, not all are following the basic rules, not everybody understands what open source actually means. Evasion strategies abound.

On the other hand, companies need to make money, even (!) with open source. How can that be accomplished in the different communities of cloud, public administration and the world of wikipedia and knowledgemanagement? How can the barely two years old center for digital sovereignty (ZenDiS) help the OSS community and companies? Hint: The ZenDiS was recently invited by the United nations and has received world-wide acknowledements.

We are very proud to have Holger Dyroff (COO ownCloud), Richard Heigl (CEO HalloWelt/BlueSpice Mediawiki, OSS Alternative to Atlassian Confluence), Leonhard Kugler, director of Open CoDE at ZenDis and Cornelius Schumacher (KDE Board) on stage.

Categories: FLOSS Project Planets

Terri Oda: Best practices in practice: Black, the Python code formatter

Planet Python - Fri, 2024-09-27 14:00
This is crossposted from Curiousity.ca, my personal maker blog. If you want to link to this post, please use the original link since the formatting there is usually better.


I’m starting a little mini-series about some of the “best practices” I’ve tried out in my real-life open source software development. These can be specific tools, checklists, workflows, whatever. Some of these have been great, some of them have been not so great, but I’ve learned a lot. I wanted to talk a bit about the usability and assumptions made in various tools and procedures, especially relative to the wider conversations we need to have about open source maintainer burnout, mentoring new contributors, and improving the security and quality of software.





So let’s start with a tool that I love: Black.





Black’s tagline is “the uncompromising Python code formatter” and it pretty much is what it says on the tin: it can be used to automatically format Python code, and it’s reasonably opinionated about how it’s done with very few options to change. It starts with pep8 compliance (that’s the python style guide for those of you don’t need to memorize such things) and takes it further. I’m not going to talk about the design decisions they made but the black style guide is actually an interesting read if you’re into this kind of thing.





I’m probably a bit more excited about style guides than the average person because I spent several years reading and marking student code, including being a teaching assistant for a course on Perl, a language that is famously hard to read. (Though I’ve got to tell you, the first year undergraduates’ Java programs were absolutely worse to read than Perl.) And then in case mounds of beginner code wasn’t enough of a challenge, I also was involved in a fairly well-known open source project (GNU Mailman) with a decade of code to its name even when I joined so I was learning a lot about the experience of integrating code from many contributors into a single code base. Both of these are… kind of exhausting? I was young enough to not be completely set in my ways, but especially with the beginner Java code, it became really clear that debugging was harder when the formatting was adding a layer of obfuscation to the code. I’d have loved to have an autoformatter for Java because so many students could find their bugs easier once I showed them how to fix their indents or braces.





And then I spent years as an open source project maintainer rather than just a contributor, so it was my job to enforce style as part of code reviews. And… I kind of hated that part of it? It’s frustrating to have the same conversation with people over and over about style and be constantly leaving the same code review comments, and then on top of that sometimes people don’t *agree* with the style and want to argue about it, or people can’t be bothered to come back and fix it themselves so I either have to leave a potentially good bug fix on the floor or I have to fix it myself. Formatting code elegantly can be fun once in a while, but doing it over and over and over and over quickly got old for me.





So when I first heard about Black, I knew it was a thing I wanted for my projects.





Now when someone submits a thing to my code base, Black runs alongside the other tests, and they get feedback right away if their code doesn’t meet our coding standards. It hardly any time to run so sometimes people get feedback very fast. Many new contributors even notice failing required test and go do some reading and fix it before I even see it, and for those that don’t fix issues before I get there I get a much easier conversation that amounts to “run black on your files and update the pull request.” I don’t have to explain what they got wrong and why it matters — they don’t even need to understand what happens when the auto-formatter runs. It just cleans things up and we move on with life.





I feel like the workflow might actually be better if Black was run in our continuous integration system and automatically updated the submitted code, but there’s some challenges there around security and permissions that we haven’t gotten around to solving. And honestly, it’s kind of nice to have an easy low-stress “train the new contributors to use the tools we use” or “share a link to the contributors doc” opening conversation, so I haven’t been as motivated as I might be to fix things. I could probably have a bot leave those comments and maybe one of those days we’ll do that, but I’m going to have to look at the code for code review anyhow so I usually just add it in to the code review comments.





The other thing that Black itself calls out in their docs is that by conforming to a standard auto-format, we really reduce the differences between existing code and new code. It’s pretty obvious when the first attempt has a pile of random extra lines and is failing the Black check. We get a number of contributors using different integrated development environments (IDEs) that are pretty opinionated themselves, and it’s been freeing to not to deal with whitespace nonsense in pull requests or have people try to tell me on the glory if their IDE of choice when I ask them to fix it. Some python IDEs actually support Black so sometimes I can just tell them to flip a switch or whatever and then they never have to think about it again either. Win for us all!





So here’s the highlights about why I use Black:





As a contributor:






  1. Black lets me not think about style; it’s easy to fix before I put together a pull request or patch.




  2. It saves me from the often confusing messages you get from other style checkers.




  3. Because I got into the habit of running it before I even run my code or tests, it serves as a quick mistake checkers.




  4. Some of the style choices, like forcing trailing commas in lists, make editing existing code easier and I suspect increase code quality overall because certain types of bug are more obvious.





As a an open source maintainer:






  1. Black lets me not think about style.




  2. It makes basic code quality conversations easier. I used to have a *lot* of conversations about style and people get really passionate about it, but it wasted a lot of time when the end result was usually going to be “conform to our style if you want to contribute to this project”




  3. Fixing bad style is fast, either for the contributor or for me as needed.




  4. It makes code review easier because there aren’t obfuscating style issues.




  5. It allows for very quick feedback for users even if all our maintainers are busy. Since I regularly work with people in other time zones, this can potentially save days of back and forth before code can be used.




  6. It provides a gateway for users to learn about code quality tools. I work with a lot of new contributors through Google Summer of Code and Hacktoberfest, so they may have no existing framework for professional development. But also even a lot of experienced devs haven’t used tools like Black before!




  7. It provides a starting point for mentoring users about pre-commit checks, continuous integration tests, and how to run things locally. We’ve got other starting points but Black is fast and easy and it helps reduce resistance to the harder ones.




  8. It reduces “bike shedding” about style. Bikeshedding can be a real contributor to burnout of both maintainers and contributors, and this reduces one place where I’ve seen it occur regularly.




  9. It decreases the cognitive overhead of reading and maintainin a full code base which includes a bunch of code from different contributors or even from the same contributor years later. If you’ve spent any time with code that’s been around for decades, you know what I’m talking about.




  10. In short: it helps me reduce maintainer burnout for me and my co-maintainers.





So yeah, that’s Black. It improves my experience as an open source maintainer and as a mentor for new contributors. I love it, and maybe you would too? I highly recommend trying it out on your own code and new projects. (and it’s good for existing projects, even big established ones, but choosing to apply it to an existing code base gets into bikeshedding territory so proceed with caution!)





It’s only for Python, but if you have similar auto-formatters for other languages that you love, let me know! I’d love to have some to recommend to my colleagues at work who focus on other languages.



comments
Categories: FLOSS Project Planets

Only hackers will survive - Akademy 2024

Planet KDE - Fri, 2024-09-27 13:55

By Joanna Murzyn

In this talk, I'll explore how the hackers' ethos - defined by open knowledge sharing, bold experimentations, and collective problem-solving - is vital for tackling global challenges, especially those one related to lack of regenerative resources management.

I'll take you on a journey from crucial mineral mining hubs to electronic waste dumpsters, uncovering the intricate connections between code, hardware, open source principles as well as social and environmental justice.

You'll gain a new perspective and discover how the KDE community's work is shaping a more resilient, regenerative future, and explore ways to
extend those principles to create positive impact beyond tech world.

Categories: FLOSS Project Planets

Looking back: What's next? - Akademy 2024

Planet KDE - Fri, 2024-09-27 13:45

By Nicolas Fella

This year we completed the major milestone of releasing Plasma 6 and KDE Frameworks 6, the culmination of years of work across the community. In this talk we are going to look at how we approached this transition, what went well, what didn't, and what we can learn for the future.

We are also going to explore what might come next in the future of KDE development.

Categories: FLOSS Project Planets

Lint all the things! - Akademy 2024

Planet KDE - Fri, 2024-09-27 13:39

By Albert Astals Cid and Alexander Lohnau

QML is a great language to write fast User Interfaces but given its runtime nature it makes it a bit fragile to refactors. This lightning talk will try to convince you to enable qmllint in your compilation steps so that QML issues are found on compile time instead of runtime.

JSON files play an important role in KDE's sources: We use them as metadata files for applets, embed them in plugin metadata.

In order to avoid runtime problems or implicit type conversions, a CI job is added to all repos. But this is only a small benefit of the improved validation and schema efforts.

This talk will highlight some benefits and show you, how you may utilize them.

Categories: FLOSS Project Planets

KWin Effects: The Next Generation - Akademy 2024

Planet KDE - Fri, 2024-09-27 13:37

By David Edmundson

Plasma 6 saw the return of the desktop cube, but the underlying story is so much bigger. KWin gained support for an entire new infrastructure to tightly couple QtQuick with Kwin's own rendering and with Kwin's content available.

In this talk we go through the problems with the current approach, what we created, and look at what this enables creative people (like you!) to do next.

Categories: FLOSS Project Planets

KDE to Make Wines — Using KDE Software on Enterprise Desktops a Return on Experience - Akademy 2024

Planet KDE - Fri, 2024-09-27 13:34

By Kevin Ottens

If we told you there is a company with hundreds of desktops running KDE Plasma? If we also told you they've been using it for more than 10 years? Finally, what if we told you they're in Australia and making wines? Wouldn't you be curious to know more about them and what they think of our software?

Well, good for us they do exist: they are De Bortoli Wines, an Australian winemaking company.

It turns out they became an enioka Haute Couture customer and we developed an interesting relationship. The work they pushed our way has been interesting and challenging. As such this gave us an interesting insight on how KDE software can be used and the constraint such entreprise desktops can encounter.

We ended up looking at application code like Okular, to frameworks like KIO, or even dug deeper exploring issues close to the kernel. This might give ideas of features to prioritize or tests to carry to cater to such users.

If you're interested in the enterprise desktop use case, or if you like to hear about funny bugs and wine labels, this talk will be for you.

Categories: FLOSS Project Planets

KDE Apps Initiative - Akademy 2024

Planet KDE - Fri, 2024-09-27 13:09

By Carl Schwan

This talk is about the my new KDE Apps initiative, to try to get people to write more KDE applications. I will describe the current state of the KDE app ecosystem and explain why it is important to get more KDE apps and what we can do to improve the situation.

This will be continuation of this blog post and includes the progress made since then.

Categories: FLOSS Project Planets

KDE's CI and CD infrastructure - Akademy 2024

Planet KDE - Fri, 2024-09-27 12:57

By Ben Cooksley, Hannah von Reth, Julius Künzel, and Volker Krause

From compiling, automated testing, linting and license verification over producing application packages for various platforms to shipping signed production releases to app stores, KDE's CI/CD system offers many ways to support you in developing software and getting it to your users.

With the migration from Jenkins to Gitlab which was concluded earlier this year, the CI/CD infrastructure not only gained new capabilities but also became more accessible for contributors to set up and customize things. In this talk, we will give an overview of the available features and how to best employ those for your application.

We will cover continuous integration (CI), that is compiling, testing and linting changes as they appear in Git or in merge requests, on all supported platforms as well as continuous delivery (CD), that is producing ready-made runnable/installable application packages in various formats, for testing individual changes or for production releases to app stores.

Finally we'll also look at current developments and future plans.

Categories: FLOSS Project Planets

The Drop Times: The la_eu Site Project Takes a Step Further at Barcelona

Planet Drupal - Fri, 2024-09-27 10:20
Esmeralda Braad-Tijhoff, writing for The DropTimes, reports from DrupalCon Barcelona where local Drupal associations met at the BoF session led by Bjorn Brala to discuss the La_eu project. This shared codebase, used by multiple countries for their association websites, will see new features, automated updates, and monthly check-ins, streamlining collaboration and further development.
Categories: FLOSS Project Planets

Pages