Russell Coker: Links January 2024

Planet Debian - Sat, 2024-01-27 21:22

Long Now has an insightful article about domestication that considers whether humans have evolved to want to control nature [1].

The OMG Elite hacker cable is an interesting device [2]. A Wifi device in a USB cable to allow remote control and monitoring of data transfer, including remote keyboard control and sniffing. Pity that USB-C cables have chips in them so you can’t use a spark to remove unwanted chips from modern cables.

David Brin’s blog post The core goal of tyrants: The “Red-Caesar” Cult and a restored era of The Great Man has some insightful points about authoritarianism [3].

Ron Garret wrote an interesting argument against Christianity [4], and a follow-up titled Why I Don’t Believe in Jesus [5]. He has a link to a well written article about the different theologies of Jesus and Paul [6].

Dimitri John Ledkov wrote an interesting blog post about how they reduced disk space for Ubuntu kernel packages and RAM for the initramfs phase of boot [7]. I hope this gets copied to Debian soon.

Joey Hess wrote an interesting blog post about trying to make LLM systems produce bad code if trained on his code without permission [8].

Arstechnica has an interesting summary of research into the security of fingerprint sensors [9]. Not surprising that the products of the 3 vendors that supply almost all PC fingerprint readers are easy to compromise.

Bruce Schneier wrote an insightful blog post about how AI will allow mass spying (as opposed to mass surveillance) [10].

ZDnet has an informative article How to Write Better ChatGPT Prompts in 5 Steps [11]. I sent this to a bunch of my relatives.

AbortRetryFail has an interesting article about the Itanic Saga [12]. Erberus sounds interesting, maybe VLIW designs could give a good ration of instructions to power – unlike the Itanium which was notorious for being power hungry.

Bruce Schneier wrote an insightful article about AI and Trust [13]. We really need laws controlling these things!

David Brin wrote an interesting blog post on the obsession with historical cycles [14].

Related posts:

  1. Links January 2020 C is Not a Low Level Language [1] is an...
  2. Links January 2023 The Intercept has an amusing and interesting article about senior...
  3. Links January 2021 Krebs on Security has an informative article about web notifications...
Categories: FLOSS Project Planets

Awesome Python Applications: Aim

Planet Python - Sat, 2024-01-27 07:55

Aim: Aim is a self-hostable machine learning experiment tracker designed to handle 10,000s of training runs.


Categories: FLOSS Project Planets

Awesome Python Applications: explainshell.com

Planet Python - Sat, 2024-01-27 07:55

explainshell.com: A web-based tool to match command-line arguments to their man pages and help text.


Categories: FLOSS Project Planets

Awesome Python Applications: liberapay.com

Planet Python - Sat, 2024-01-27 07:49

liberapay.com: A recurrent donations platform, formerly known as gittip and gratipay.


Categories: FLOSS Project Planets

Awesome Python Applications: Mathesar

Planet Python - Sat, 2024-01-27 07:43

Mathesar: Self-hostable web application which provides a spreadsheet-like interface to a PostgreSQL database, enabling users of all technical skill levels to design data models, enter data, and build reports.


Categories: FLOSS Project Planets

Awesome Python Applications: Dispatch

Planet Python - Sat, 2024-01-27 07:37

Dispatch: Incident management service featuring integrations for notifications and task management. Used at Netflix.


Categories: FLOSS Project Planets

Awesome Python Applications: Mealie

Planet Python - Sat, 2024-01-27 07:31

Mealie: Self-hostable recipe management server with rich user interface and automatic backups.


Categories: FLOSS Project Planets

Awesome Python Applications: Open Event Server

Planet Python - Sat, 2024-01-27 07:25

Open Event Server: Enable event organizers to manage events from meetups to concerts to conferences, with support for multiple tracks and venues. Used by [FOSSASIA](https://fossasia.org/) and [eventyay](https://eventyay.com/).


Categories: FLOSS Project Planets

Awesome Python Applications: PDF Arranger

Planet Python - Sat, 2024-01-27 07:18

PDF Arranger: Merge and split PDF documents, as well as crop and rearrange pages.


Categories: FLOSS Project Planets

Awesome Python Applications: Tautulli

Planet Python - Sat, 2024-01-27 07:14

Tautulli: Web monitor for Plex Media Server.


Categories: FLOSS Project Planets

The Drop Times: Join Us for the Drupal Global Contribution Weekend 2024

Planet Drupal - Sat, 2024-01-27 00:59
Mark your calendars; the Drupal Global Contribution Weekend is back! This exciting event will occur on the 27th and 28th of January, 2024.
Categories: FLOSS Project Planets

This week in KDE: everything everywhere all at once edition

Planet KDE - Sat, 2024-01-27 00:30

This week we’ve got quite a bit of everything! Mega-release UI improvements and bug-fixes, new features for post-mega-release software, more bugfixes for KF5 software, performance improvements, better internal documentation, and impactful ecosystem improvements. Let’s dive in!


KCalc now shows you the equation you just entered, in addition to the calculated result (Gabriel Barrantes, KCalc 24.05, link):

Spectacle now scans QR codes in screenshots and offers you the opportunity to open their links (Dinesh Manajipet, Spectacle 24.05. Link)

The Weather widget now shows weather alerts for U.S. locations using the NOAA Weather backend (Ismael Asensio, Plasma 6.1. Link)

System Settings’ Drawing Tablet page can now be used to configure pen or tablet buttons to act as modifier keys rather than trigger actions (Tino Lorenz, Plasma 6.1. Link)

KDE 6 Mega-Release

(Includes all software to be released on the February 28th mega-release: Plasma 6, Frameworks 6, and apps from Gear 24.02)

General info

UI improvements

It’s no longer possible to drag an app or window from the Task Manager onto another part of its panel, accidentally creating a launcher widget out of it (Niccolò Venerandi, link)

Scrolling over the volume sliders in the Audio Volume widget and System Settings page now scrolls by increments of the user-configured volume step, rather than either changing the volume by 1% per scroll tick or doing nothing (Yifan Zhu, link 1 and link 2)

In the Plasma Wayland session, you can now mirror two screens on System Settings’ Display Configuration page using a visible combobox, not just by the hidden method of dragging one screen on top of another one in the visualization area (Yifan Zhu, link)

Bug fixes

Important note: I don’t mention fixes for bugs that were never released to users; it’s just too much for me (it would probably be too much for you to read as well), and most people never encountered them in the first place. Because we’re in the middle of a big Plasma dev cycle, there are a lot of these bugs! So big thanks to everyone who’s made it a priority to fix them!

The critically important Wobbly Windows effect once again works while using the Zoom effect to zoom in on something. Never stop wobbling! (Vlad Zahorodnii, link)

On System Settings’ Cursors page, the preview of available cursor sizes is now sized correctly when using a scale factor above 100% (Yifan Zhu, link 1 and link 2)

Changing the name, icon, command etc for an app marked as a favorite in Kickoff now updates the item immediately, rather than any such changes only taking effect after restarting Plasma (Marco Martin, link)

Fixed a bug that could cause panels in “Auto-Hide” or the new “Dodge Windows” mode to inappropriately un-hide and become stuck in an un-hidden state when the screen configuration changed in certain ways (Yifan Zhu, link)

Fixed multiple issues causing keyboard shortcuts using numberpad number keys to not register correctly in both the X11 and Wayland sessions (Nicolas Fella and Eugene Popov, link 1, link 2, link 3, and link 4)

It’s no longer possible to somewhat awkwardly open the “Alternatives” popup for a widget multiple times (Niccolò Venerandi, link)

Other bug information of note:

  • 4 Very high priority Plasma bugs (up from 3 last week, though two are likely the same thing and in need of investigation and triaging). Current list of bugs
  • 34 15-minute Plasma bugs (down from 35 last week). Current list of bugs
  • 150 KDE bugs of all kinds fixed over last week. Full list of bugs
Performance & Technical

Improved the performance of certain config-lookup code used commonly through KDE software by 35-40% (Friedrich Kossebau, link)

Improved performance and GUI responsiveness of the System Settings app by a little bit everywhere (David Edmundson, link)

Improved Discover’s launch time a bit (Aleix Pol Gonzalez, link 1 and link 2)

Improved compatibility between NVIDIA GPUs and the way KWin handles screencasting, screen sharing, and generating thumgnails for windows (Xaver Hugl, link)

Fixes for KF5

KF5 software continues to get a few fixes:

The feature in Dolphin to delete the config data of a no-longer-installed Flatoak app once again works (Ivan Tkachenko, Plasma Link)

Fixed a crash in Dolphin when using kio-admin to do privilege escalation (Harald Sitter, Frameworks 5.115. Link)

Automation & Systematization

Wrote a tutorial about using PyQt to produce KDE software using Python rather than C++ (Thiago Sueto, Helio Loureiro, and Dimitris Kardarakos link)

Work not in KDE that affects KDE

KDE contributors also made two notable contributions to the world outside of KDE this week, which will positively affect not just KDE, but others as well:

There’s now a standard cross-desktop “prefers high contrast” setting that lives in the settings portal. Expect to see support for this showing up in KDE software soon! (Dominic Hayes, link)

Chromium- and Electron-based apps gained support for the cursor-shape-v1 Wayland protocol, allowing them to show standard cursor shapes and sizes in the Plasma Wayland session (Ilya Bizyaev, link)

…And Everything Else

This blog only covers the tip of the iceberg! If you’re hungry for more, check out https://planet.kde.org, where you can find more news from other KDE contributors.

How You Can Help

Thanks to you, our Plasma 6 fundraiser has been a crazy success! I originally thought the goal of 500 new KDE e.V. supporting members was over-optimistic, but you’ve all proven me happily wrong. We’re now up to an incredible 695 members, unlocked both stretch goals, and 1000 members by launch time seems like it might even be feasible. Thank you everyone for the confidence you’ve shown in us; we’ll try not to screw it up! For those who haven’t donated ot become members yet, spreading the wealth via this fundraiser is a great way to share the love.

If you’re a developer, work on Qt6/KF6/Plasma 6 issues! Which issues? These issues. Plasma 6 is very usable for daily driving now, but still in need of some final bug-fixing and polishing to get it into a solid state by February.

Otherwise, visit https://community.kde.org/Get_Involved to discover other 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!

Categories: FLOSS Project Planets

freeipmi @ Savannah: FreeIPMI 1.6.12 & 1.6.13 Released

GNU Planet! - Fri, 2024-01-26 19:59

FreeIPMI 1.6.12 - 11/19/23
o Use poll() over select() to avoid fd limit in openipmi driver.
o Fix potential portability problems on systems without cbrt().
o Minor documentation updates.

FreeIPMI 1.6.13 - 01/26/24
o Fix build issues on systems where inb/outb are declared with
  inline assembly.
o Add additional sensor/event interpretations.

Categories: FLOSS Project Planets

FSF Blogs: FSD meeting recap 2024-01-26

GNU Planet! - Fri, 2024-01-26 17:58
Check out the important work our volunteers accomplished at today's Free Software Directory (FSD) IRC meeting.
Categories: FLOSS Project Planets

FSD meeting recap 2024-01-26

FSF Blogs - Fri, 2024-01-26 17:58
Check out the important work our volunteers accomplished at today's Free Software Directory (FSD) IRC meeting.
Categories: FLOSS Project Planets

FSF Blogs: FSD meeting recap 2024-01-26

GNU Planet! - Fri, 2024-01-26 17:05
Check out the important work our volunteers accomplished at today's Free Software Directory (FSD) IRC meeting.
Categories: FLOSS Project Planets

ComputerMinds.co.uk: Aegir 3 and Drupal 10: eeek!

Planet Drupal - Fri, 2024-01-26 14:47

Aegir is a hosting system built in Drupal, for Drupal.

It lets you easily create new Drupal sites and create databases, filesystems, virtual hosts etc. for the sites. You can manage hundreds or thousands of sites using a simple Drupal based UI. As simple as you would manage a list of 100 blog posts, you can manage 100 Drupal websites.

Currently the latest released version of Aegir is: Aegir 3.

Aegir 3 relies on Drush 8, which means it can work with: Drupal 7; Drupal 8 and Drupal 9. But not Drupal 10. Oh.

I have need for it to work with Drupal 10. Specifically we have a large collection of Drupal sites, that currently Drupal 9, but ready and waiting to jump to Drupal 10. Yes, we've left it too late, we should have done this a long time ago, but we are where we are.

I've spent the day looking into various options, they are roughly:

  • Move to BOA
  • Get Aegir 3 to work with Drupal 10
  • Move to Aegir 4
  • Move to Aegir 5
  • Move to something else
My terms of reference

I'm looking for a solution that changes as little as possible in the current stack. We've got a big, beefy server, and lots and lots of Drupal sites on it. The Drupal sites themselves run fine and we're after the management of them really. We don't need to scale out particularly, and if we do, we've got options on the hardware side vertically. We also don't need some fancy multi-datacenter approach, and ideally keep with our Nginx, Varnish and Apache sandwich.

I do want to manage things in the old school way, but I need a few, select, non-technical users to be able to manage the sites in a friendly UI like Aegir's hosting system.

Lots of the new hotness out there are essentially orchestrating Kubernetes, and that's great, but I don't actually want 100 containers all running PHP which is how I understand all of these systems would essentially function.

I used to be an Aegir maintainer, and I have a deep knowledge of how Aegir works and even helped write some of the inter-process communications stuff in Drush 8. 

Move to BOA

The first option is one that has shown to be working, and requires a custom fork of Drush 8, some core patches and using BOA. BOA is quite an aggressive fork of Aegir, and I'm not sure I want all the changes and whatnot that comes with it. I think I have to discount it, because the last time I looked there would simply be too much change on the nginx side of things at least, and it was doing all kinds of things I don't simply understand and thus won't be able to reason about.

The main inspiration I take from BOA is that they've got it working! Well, they've got something working. It looks like they've essentially forked Drush 8, applied some Drupal core and Aegir patches. This makes it so that Aegir can still use it's aliases, code and talk to Drupal 10 sites. How they've been able to do this is very impressive indeed. I feel like it's just a matter of time before it breaks though, surely Drupal 10 is going to change something in it's lifecycle and cause issues. I don't quite see how this can work with Drush commands in contrib modules. For example, during deployments on our sites we revert features, but that's a features module provided Drush command, which won't be callable from Drush 8 in Drupal 10.

Get Aegir 3 to work with Drupal 10

This I feel is the least effort option. Find some way to get standard Aegir 3 to communicate with Drupal 10. Now, Drush 8 can't directly bootstrap a Drupal 10 site. Aegir 3 uses Drush 8 to be both the backend storage for all the data about the sites to host, and to bootstrap the sites it manages.

This worked really well in the Drupal 5/6/7 days, and just about coped with Drupal 8/9, but hasn't for Drupal 10. Think of it this way, what if instead of hosting a Drupal site, it was a Wordpress site? Aegir simply wouldn't be able to neatly bootstrap into a Drupal site and do it's stuff. It's the same with Drupal 10.

How much stuff does it really do though? I'm not 100% sure. I know that it gets the currently installed packages for example, but what else does it do. It looks to me like it often hands off a Drush subprocess do the heavy lifting. Maybe we can hand off to another subprocess, one that runs a site-local Drush 12+ instance, passing in all the options it needs to bootstrap and run the actual commands on the site.

Please, if this is a completely crazy way to go, someone please comment and let me know!

Move to Aegir 4

So there is a 4.x branch of Aegir, and apparently it can work with Drupal 10 sites. It does this by replicating the aliases to YAML files and then running a global Drush 11, which can then bootstrap the Drupal sites. Apparently it also has replaced some of the Drush invocations with standard process invocations. I guess it had to do this because the Drush to Drush process communication stuff was in Drush 8 and got removed.

It seems like Aegir 4 also brought in a lot of other changes too, and that's not particularly something I want or need. Also, it's never been officially released/tested by the community etc.

Move to Aegir 5

This got announced in a few blog posts a while back, and I've not heard anything since. It's possible that it's there and ready to go, but as far as I understand it, it's a whole change to how the sites would be managed and hosted, and while an import from Aegir 3 is on the roadmap, it seems like it would import the sites into something completely different, not some simple vhosts and a DB server.

Also, even if it does exist, it'll have had minimal testing and eyes on it.

Move to something else

I think this is my preferred long-term option. These sites don't really need Drupal. They could actually be static sites plugged into a central content repository. That would drastically simplify lots and lots of things. Or we keep the Drupal sites, but move them to Kubernetes and using something like Amazee's Lagoon to host them etc. This would be very cool, but probably quite expensive in terms of having enough resources to host all the containers.

One for the long term future I think.


Get Aegir 3 to work with Drupal 10

I might give this a go in that I think what I can do is this:

  1. Get Aegir running normally.
  2. Install a Drupal 9 site.
  3. Get a single Aegir task running that doesn't bootstrap the Drupal 9 site with Drush 8. I'm thinking something like getting the one-time login link. This has data flowing in both directions, and I think, Drush 8 trying to bootstrap Drupal to the run the provision command. Getting this working would involve calling a site local Drush based on the data from the alias, but not actually using the alias.
  4. If that works, put something into settings.php that throws an exception if Drush 8 is detected, and then try to get everything else working for my use-cases.
  5. Then try and set up a Drupal 10 site.

I'd love to know your thoughts on this. Do you have an old Aegir running sites, and you don't know what to do with it? Or do you think I'm crazy and want to offer me a better way to go, use the comments below, please!



So looking at the provision commands, the actual provision command to say, get the one-time login link bootstraps the Drupal site. So that would need to change that command so that it no-longer bootstrapped Drupal at all, but instead changed to be a pure Drush command. Then it could load the data from the alias etc.
I'm tempted to go ahead and get a dev instance of Aegir running and the add a new Drush command, that doesn't bootstrap Drupal, but does attempt to grab data from an alias and see what I can do. That possibly an even simpler proof of concept, as it's an entirely new Drush command, but one I then know could be called by provision's task runner instead of the current one.

Categories: FLOSS Project Planets

Four Kitchens: Tips for upgrading to CKEditor5

Planet Drupal - Fri, 2024-01-26 14:09

The Web Chefs

January 1, 1970

At Four Kitchens we keep several lists of “Hot Topics” to share our learnings across the dozens of sites that we care for. Are you upgrading a Drupal site to CKEditor5? We’ve tidied up one of these internal wiki documents into this set of general upgrade guidelines that might pertain to your website.

Rough steps to upgrade

The level of effort needed for this upgrade will be different for each site. It may take some time to figure out. CKEditor 5 is available in Drupal 9.5 and beyond. You can try switching/upgrading on a local site or multidev and assess the situation.

First, create a list of CKEditor enhancement modules on the site and check if they are Drupal 10 ready (the reports from Upgrade Status and this Drupal.org page may help). Common modules to look for include Linkit, Anchor Link, Advanced Link, IMCE, Entity Embed, Video Embed Field, Footnotes, and anything with the word “editor” in the title.

As a best practice, you should test both the creation of new content, and editing existing content in several places. This will help make sure that some lesser used HTML isn’t treated differently in the new CKEditor. Run visual regression tests (if available).

You may need to point out key interface changes to your clients or stakeholders (e.g., contextual windows for links/media/tables instead of modals, etc.). While it is a bit of a change, it’s overall an improved user experience, especially for new people who are coming in cold.

Anchor links

Anchor link gives editors the ability to create links to different sections within a page.

For “better integration with Drupal 10, CKEditor 5, and LinkIt” there is a 3.0.0@alpha version. If your project isn’t using wikimedia/composer-merge-plugin, you must require northernco/ckeditor5-anchor-drupal package and add the following to the repositories section of composer.json:

{ "type": "package", "package": { "name": "northernco/ckeditor5-anchor-drupal", "version": "0.3.0", "type": "drupal-library", "dist": { "url": "https://registry.npmjs.org/@northernco/ckeditor5-anchor-drupal/-/ckeditor5-anchor-drupal-0.3.0.tgz", "type": "tar" } } }



Embedded media

Depending on the age of your site, it might be using one of several techniques to embed media into the WYSIWYG:

If your site is using the video_embed_field module (most sites are probably using Drupal core’s media module), there is a patch that adds support for CKE5. Insert Image works slightly different (though this is probably not the case if your site uses core’s media module). It’s worth considering if there is a way to enhance this for user experience, if necessary.

If your site uses custom Entity Embed for media, consider switching to the core media library. It may provide a better administrative user experience in some cases.

The insert image button in CKEditor functions a little differently than it used to. Rather than bringing up a modal with fields to upload an image like the image below:

It now immediately pulls up your computer’s file system for you to search for images like so:

After adding your image, the alt tag box prompts you underneath the image:

After submitting your alt tag, you can adjust alignment and sizing:

Moving general styles to link styles

It was common in CKEditor4 to use its “Styles” feature to provide a way to add variations of links (to make them look like buttons, or to add icons).

There are a few UX problems with that approach. Either the styles are set to apply on <span>, which means that they can be applied to non-links, or the styles are set to apply on <a>, which means that they are mysteriously grayed out most of the time (until you select a link). Either way, it’s not intuitive how to apply a link style. In CKEditor5, we can switch to using the Link Styles module.

Change in Styles dropdown behavior

In CKEditor4, when integrated with Drupal, the Styles dropdown only allowed applying one style to an element (e.g., “external link”). If you tried to apply a different style, such as “locked link,” the previous style would be removed.

The Drupal implementation of CKEditor5 allows for multiple styles to be applied to elements via the Styles dropdown. This change may be unexpected for some, and could result in elements that look broken, such as when a link has both the “external link” and “locked link” styles.

CKEditor5 introduced a new API for adding theme-specific styles. The new architecture might cause the CKEditor5 theme to bleed into the admin theme. To know how to deal with these issues, review new API for adding theme-specific styles in CKEditor5.

You’ll likely run into an issue with styles bleeding outside of the editor, so see the other section within this page.

Cut and paste

Paste-from-Word, paste-from-Google-Docs, etc. is now built-in to CKEditor5. (At least for 90% of use cases.) There’s a paid plugin for more esoteric needs.

There is no paste-as-plain-text plugin for CKEditor5. You can use Ctrl-Shift-V (or Cmd-Shift-V) to paste as plain text. If you want to get rid of all formatting (including bold, links, etc.) in existing text, you can highlight the text, use Ctrl-C to copy, then Ctrl-Shift-V to paste it back as plain text.


Many of our Behat automated test broke after the update because there were multiple structural changes, so this is how we solved it: First, here is the doc about how to get the editor instance in case you want to know more about it. This is how we rewrite our custom step to fill out the CKEditor during testing. (We found the code in an article post-post).

/** * A step to help fill in a ckeditor wysiwyg. * * @param string $locator * The css locator of the field that ckeditor has taken over. * @param string $value * The html value you wish to fill in to ckeditor. * * @Then I fill in wysiwyg on field :locator with :value */ public function iFillInWysiwygOnFieldWith($locator, $value) { // https://ckeditor.com/docs/ckeditor5/latest/support/faq.html#how-to-get-the-editor-instance-object-from-the-dom-element $ckeditor5_drupal_editable_element = "div.form-item-$locator .ck-editor__editable"; $this->getSession() ->executeScript( " var domEditableElement = document.querySelector(\"$ckeditor5_drupal_editable_element\"); if (domEditableElement.ckeditorInstance) { const editorInstance = domEditableElement.ckeditorInstance; if (editorInstance) { editorInstance.setData(\"$value\"); } else { throw new Exception('Could not get the editor instance!'); } } else { throw new Exception('Could not find the element!'); } " ); }

and the mink step for regular field:

And I fill in wysiwyg on field "field-summary-0-value" with "Some Teaser Text"

And for a field inside a paragraph:

And I fill in wysiwyg on field "field-sidebar-content-0-subform-field-simple-text-0-value" with "Behat Side Nav Body Text"

Preventing custom styles from bleeding into admin theme with CKEditor5

See the new API documentation about implementing theme styles in the new way. This may require some adjustments on your end.

One of the major changes with CKEditor5 is that it pulls WYSIWYG styles onto the whole page when there is a WYSIWYG on the page. In CKEditor4, styles were only pulled into the CKEditor iframe. This can be extremely frustrating when the admin theme looks odd or different on pages that contain a WYSIWYG.

Limit the number of stylesheets being pulled into the WYSWIYG. (First, note that this method has only been confirmed to work on newer versions of Sous using specific webpack settings. If you are having problems with it, make sure your webpack settings allow for multiple manifests to be generated. You may need to refer to a newer site to see how it is configured.)

The first step is to create a new stylesheet (a manifest) called wysiwyg.scss in the same directory as your styles.scss file, which assembles all the stylesheets used in your theme. For this stylesheet, we’ll only want to include the stylesheets that our WYSIWYG needs. For example, I have one that looks like this:

@import url('https://fonts.googleapis.com/css2?family=Poppins:ital,wght@0,400;0,700;1,400;1,700&display=swap'); @import '~normalize.css/normalize'; @import '~breakpoint-sass/stylesheets/breakpoint'; // Components @import '00-base/**/*.scss'; // Include all atoms except form items. @import '01-atoms/00-links/**/*.scss'; @import '01-atoms/01-text/**/*.scss'; @import '01-atoms/02-lists/*.scss'; @import '01-atoms/tables/*.scss'; @import '01-atoms/images/**/*.scss'; @import '05-pages/colors.scss'; @import '05-pages/base.scss';

In this example, we are pulling in a couple needed files from node_modules (normalize and breakpoint), and then any .scss files from base, and then select files from atoms (links, text, lists, tables, and images).

Compile and make sure that it has created the new files at /dist/css/wysiwyg.css. If you get any errors, you may need to include another file that has a variable you need, or something along those lines.

1.) Update your .info file In your theme’s .info file, set CKEditor5 to use your new stylesheet:

ckeditor5-stylesheets: - dist/css/wysiwyg.css

2.) Review the WYSIWYG. Visit a page with a WYSIWYG on the page, and verify that the limited styles are loading properly within the WYSIWYG. Try all the dropdowns and buttons that are included in the WYSIWYG settings. If anything appears unthemed, review your styles to see if there’s a stylesheet missing from your manifest.

3.) Review the rest of the page. Now review the page around the WYSIWYG and note how if differs from other pages that do not have a WYSIWYG. Common differences to look for are: heading styles, text styles, buttons — basically anything that you included in your manifest.

4.) Limit styles

  • Find the page’s body class for node edit pages (in our test case, .gin--edit-form). It may depend on your admin theme.
  • Find the wrapper class for the WYSIWYG. Most likely the best choice is .ck-content. Our approach will be to hide styles from .gin--edit-form, but then add them to .ck-content.

For example:

body { background-color: clr(background); color: clr(text); @include body-copy; }


body:not(.gin--edit-form), .ck-content { background-color: clr(background); color: clr(text); @include body-copy; }

And for buttons:

.main .button { @include button-base; @include button-color-primary; @include button-medium; }

it becomes:

body:not(.gin--edit-form) .button, .main .button, .ck-content a.button { @include button-base; @include button-color-primary; @include button-medium; }

With any luck, the styles used apply mixins, which makes it easy to filter out where to apply the styles. In some cases, the overriding of styles may become hard because of the order in which the stylesheets are loaded. Try to avoid !importants and instead use things like an additional element or class to firm up your override.

One issue that may come up is your overrides here end up overriding things in your custom theme, depending on how they are defined. In this case, don’t wrap the styles in the body classes, but rather undo the custom theme’s style on the admin page items manually. Luckily, since we’re narrowly applying custom styles, only things used in the WYSIWYG will need to be addressed.

For instance:

// Apply general link styles to all links. a { @include link; } // Overrides for Admin pages containing CKEditor (you will need a body class only on admin pages). .user-logged-in { a { background-image: none; transition: none; } .horizontal-tabs-list a, .toolbar a { font-weight: normal; } } // Reapply link styles to links within the WYSIWYG .ck-editor a { @include link; }

Continue to review your page and adjust it until it no longer differs from other admin pages.

Editor explodes out of its container in deeper paragraphs

This issue seems to occur only with rich text fields within a paragraph. It might be limited to the Gin theme.

This issue might be because of the container’s width. If input fields inside the container have a specified size exceeding the screen width, it can lead the editor to inherit the container’s width, extending beyond the screen. You can see this as a Drupal Core/CKEditor5 bug in Drupal.org: CKEditor5 toolbar items of multivalue field (typically Paragraphs) overflowing on narrow viewports and overlapping with node form’s sidebar on wide viewports.

To resolve this quickly, set the input fields to 100% width, making sure everything works seamlessly. Be sure to include this in a stylesheet of your admin theme.

.node-form input[size] { width: 100%; }

We can also modify the ‘flex-wrap’ property of the CKEditor buttons to make sure they stay within the container’s width:

.ck-editor .ck.ck-toolbar.ck-toolbar_grouping > .ck-toolbar__items { flex-wrap: wrap; } Additional resources

The post Tips for upgrading to CKEditor5 appeared first on Four Kitchens.

Categories: FLOSS Project Planets

Bastian Venthur: Investigating popularity of Python build backends over time

Planet Debian - Fri, 2024-01-26 13:00

Inspired by a Mastodon post by Françoise Conil, who investigated the current popularity of build backends used in pyproject.toml files, I wanted to investigate how the popularity of build backends used in pyproject.toml files evolved over the years since the introduction of PEP-0517 in 2015.

Getting the data

Tom Forbes provides a huge dataset that contains information about every file within every release uploaded to PyPI. To get the current dataset, we can use:

curl -L --remote-name-all $(curl -L "https://github.com/pypi-data/data/raw/main/links/dataset.txt")

This will download approximately 30GB of parquet files, providing detailed information about each file included in a PyPI upload, including:

  1. project name, version and release date
  2. file path, size and line count
  3. hash of the file

The dataset does not contain the actual files themselves though, more on that in a moment.

Querying the dataset using duckdb

We can now use duckdb to query the parquet files directly. Let’s look into the schema first:

describe select * from '*.parquet'; ┌─────────────────┬─────────────┬─────────┐ │ column_name │ column_type │ null │ │ varchar │ varchar │ varchar │ ├─────────────────┼─────────────┼─────────┤ │ project_name │ VARCHAR │ YES │ │ project_version │ VARCHAR │ YES │ │ project_release │ VARCHAR │ YES │ │ uploaded_on │ TIMESTAMP │ YES │ │ path │ VARCHAR │ YES │ │ archive_path │ VARCHAR │ YES │ │ size │ UBIGINT │ YES │ │ hash │ BLOB │ YES │ │ skip_reason │ VARCHAR │ YES │ │ lines │ UBIGINT │ YES │ │ repository │ UINTEGER │ YES │ ├─────────────────┴─────────────┴─────────┤ │ 11 rows 6 columns │ └─────────────────────────────────────────┘

From all files mentioned in the dataset, we only care about pyproject.toml files that are in the project’s root directory. Since we’ll still have to download the actual files, we need to get the path and the repository to construct the corresponding URL to the mirror that contains all files in a bunch of huge git repositories. Some files are not available on the mirrors; to skip these, we only take files where the skip_reason is empty. We also care about the timestamp of the upload (uploaded_on) and the hash to avoid processing identical files twice:

select path, hash, uploaded_on, repository from '*.parquet' where skip_reason == '' and lower(string_split(path, '/')[-1]) == 'pyproject.toml' and len(string_split(path, '/')) == 5 order by uploaded_on desc

This query runs for a few minutes on my laptop and returns ~1.2M rows.

Getting the actual files

Using the repository and path, we can now construct an URL from which we can fetch the actual file for further processing:

url = f"https://raw.githubusercontent.com/pypi-data/pypi-mirror-{repository}/code/{path}"

We can download the individual pyproject.toml files and parse them to read the build-backend into a dictionary mapping the file-hash to the build backend. Downloads on GitHub are rate-limited, so downloading 1.2M files will take a couple of days. By skipping files with a hash we’ve already processed, we can avoid downloading the same file more than once, cutting the required downloads by circa 50%.


Assuming the data is complete and my analysis is sound, these are the findings:

There is a surprising amount of build backends in use, but the overall amount of uploads per build backend decreases quickly, with a long tail of single uploads:

>>> results.backend.value_counts() backend setuptools 701550 poetry 380830 hatchling 56917 flit 36223 pdm 11437 maturin 9796 jupyter 1707 mesonpy 625 scikit 556 ... postry 1 tree 1 setuptoos 1 neuron 1 avalon 1 maturimaturinn 1 jsonpath 1 ha 1 pyo3 1 Name: count, Length: 73, dtype: int64

We pick only the top 4 build backends, and group the remaining ones (including PDM and Maturin) into “other” so they are accounted for as well.

The following plot shows the relative distribution of build backends over time. Each bin represents a time span of 28 days. I chose 28 days to reduce visual clutter. Within each bin, the height of the bars corresponds to the relative proportion of uploads during that time interval:

Looking at the right side of the plot, we see the current distribution. It confirms Françoise’s findings about the current popularity of build backends:

  • Setuptools ~50%
  • Poetry: ~33%
  • Hatch: ~10%
  • Flit: ~3%
  • Other: ~4%

Between 2018 and 2020 the graph exhibits significant fluctuations, due to the relatively low amount uploads utizing pyproject.toml files. During that early period, Flit started as the most popular build backend, but was eventually displaced by Setuptools and Poetry.

Between 2020 and 2020, the overall usage of pyproject.toml files increased significantly. By the end of 2022, the share of Setuptools peaked at 70%.

After 2020, other build backends experienced a gradual rise in popularity. Amongh these, Hatch emerged as a notable contender, steadily gaining traction and ultimately stabilizing at 10%.

We can also look into the absolute distribution of build backends over time:

The plot shows that Setuptools has the strongest growth trajectory, surpassing all other build backends. Poetry and Hatch are growing at a comparable rate, but since Hatch started roughly 4 years after Poetry, it’s lagging behind in popularity. Despite not being among the most widely used backends anymore, Flit maintains a steady and consistent growth pattern, indicating its enduring relevance in the Python packaging landscape.

The script for downloading and analyzing the data can be found in my GitHub repository. It contains the results of the duckb query (so you don’t have to download the full dataset) and the pickled dictionary, mapping the file hashes to the build backends, saving you days for downloading and analyzing the pyproject.toml files yourself.

Categories: FLOSS Project Planets

PyCharm: PyCharm 2023.3.3 Is Out!

Planet Python - Fri, 2024-01-26 12:44

This year, we are trying out a new approach with our releases, moving away from a quarterly schedule to more regular monthly feature-rich releases. This change is intended to deliver new features more rapidly and streamline the feedback process.

Download PyCharm 2023.3.3

Visual diff for Jupyter notebooks

There is no need to dig into JSONs anymore – PyCharm now provides a diff view for Jupyter notebooks that renders cells with inputs as if you’re looking through the actual notebook.

AI Assistant: Unit test generation

Use JetBrains AI Assistant to speed up your Python development with automated unit test generation for methods in classes.

Jupyter notebooks: Widget rendering

While PyCharm 2023.3.3 already displays interactive graphics for libraries such as Matplotlib, Bokeh, Plotly, pyecharts, and TensorBoard, we plan on improving this functionality even further in the upcoming releases.

Async viewer for the debugger

Get information about the program’s state and track the evaluation of coroutines while debugging in PyCharm. You can now also use the await keyword outside of functions in the debug console.

Fixes for the DataFrame viewer

In PyCharm 2023.3, we introduced the ability to view DataFrames and series in a separate editor tab. Following user feedback, we’ve improved this view, which now offers new color coding for data and better performance with large datasets.

These are the most notable updates featured in the PyCharm 2023.3.3 release. For a detailed overview of all the changes, we recommend reviewing the release notes.

Your feedback is invaluable to us as we work to improve PyCharm. We encourage you to share your thoughts and suggestions on the latest features and updates. Connect with us on X (formerly Twitter) or drop a comment below to let us know what you think. If you come across any bugs while working with the IDE, please report them to our issue tracker.

Categories: FLOSS Project Planets