Feeds

Leveraging AI and Machine Learning in Drupal Editor Mon, 07/01/2024 - 09:59

Dries Buytaert once predicted that AI bots would provide factual information and communicate with emotions and personality, offering more human-like interactions than websites.
Artificial intelligence technologies have recently begun to be actively used in various fields, including web development. But what exactly? Implementing AI into your Drupal-based website opens up vast opportunities to improve your business's efficiency, significantly improve your customers' service quality, and much more. In this article, you will learn how to achieve success by using AI and Machine Learning in Drupal.

At home, I have both a laptop and a *desktop PC. Most of my essential things, such as emails, repositories, password managers, contacts, and calendars are synced between the two devices. However, when I need to share some documents and I am lazy enough to go pick a flash drive, my only option is to push them to the Internet and download them on the other system, which is sitting at 20~ meters away. Typically, I do this either through email attachments or a matrix client.

Occasionally, I think about setting up a network storage solution at home. But then I ask myself do I really need one.

In my home network, I already have a Raspberry Pi running as my Wi-Fi router, doing DNS level ad blocking with Dnsmasq and DNS over TLS with stubby. Rpi has a 16GB memory card. I can mount RPi remote directory to both machines.

I use pcmanfm as my file manager. It has the ability (like every other file managers) to mount remote storage over ssh. But one annoying thing is that whenever I open the mount directory, by default it shows the root file system of the remote device even when I explicitly mentioned the path.

Then I discovered sshfs. I wrote the following script, which mount remote directory and open that in pcmanfm.

#!/bin/bash LOCMOUNT="/home/user/Public" sshfs raspberrypi:Public $LOCMOUNT pcmanfm $MOUNT

I haven’t enabled any encryption for the memory until now since other than some logs RPi wasn’t writing anything to it. I set up fscrypt on Rpi storage now. And ta-da, a lazy person’s local sharing solution.

*Desktop - Well, technically it’s an old laptop with a broken keyboard and trackpad, connected to a monitor, keyboard and mouse. I don’t feel keeping it on a shelf.

Review: Snuff, by Terry Pratchett

Series: Discworld #39 Publisher: Harper Copyright: October 2011 Printing: January 2013 ISBN: 0-06-221886-7 Format: Mass market Pages: 470

Snuff is the 39th Discworld novel and the 8th (and last) Watch novel. This is not a good place to start reading.

Sam Vines has been talked, cajoled, and coerced into taking a vacation. Since he is now the Duke of Ankh, he has a country estate that he's never visited. Lady Sybil is insistent on remedying this, as is Vetinari. Both of them may have ulterior motives. They may also be colluding.

It does not take long for Vimes to realize that something is amiss in the countryside. It's not that the servants are uncomfortable with him talking to them, the senior servants are annoyed that he talks to the wrong servants, and the maids turn to face the wall at the sight of him. Those are just the strange customs of the aristocracy, for which he has little understanding and even less patience. There's something else going on. The nobility is wary, the town blacksmith is angry about something more than disliking the nobles, and the bartender doesn't want to get involved. Vimes smells something suspicious.

When he's framed for a murder, the suspicions seem justified.

It takes some time before the reader learns what the local nobility are squirming about, so I won't spoil it. What I will say is that Snuff is Pratchett hammering away at one of his favorite targets: prejudice, cruelty, and treating people like things. Vimes, with his uncompromising morality, is one of the first to realize the depth of the problem. It takes most of the rest longer to come around, even Sybil. It's both painful, and painfully accurate, to contemplate how often recognition of other people's worth only comes once they do something that you recognize as valuable.

This is one of the better-plotted Discworld novels. Vimes starts out with nothing but suspicions and stubbornness, and manages to turn Snuff into a mystery novel through dogged persistence. The story is one continuous plot arc with the normal Pratchett color (Young Sam's obsession with types of poo, for example) but without extended digressions. It also has considerably better villains than most Pratchett novels: layers of foot soldiers and plotters, each of which have to be dealt with in a suitable way. Even the concluding action sequences worked for me, which is not always a given in Discworld.

The problem, unfortunately, is that the writing is getting a bit wobbly. Pratchett died of early-onset Alzheimer's in 2015, four years after this book was first published, and this is the first novel where I can see some early effects. It mostly shows up in the dialogue: it's just a bit flabby and a bit repetitive, and the characters, particularly towards the end of the book, start repeating the name of the person they're talking to every other line. Once I saw it, I couldn't unsee it, and it was annoying enough to rob a bit of enjoyment from the end of the book.

That aside, though, this was a solid Discworld novel. Vimes testing his moral certainty against the world and forcing it into a more ethical shape is always rewarding, and here he takes more risks, with better justification, than in most of the Watch novels. We also find out that Vimes has a legacy from the events of Thud!, which has interesting implications that I wish Pratchett had more time to explore.

I think the best part of this book is how it models the process of social change through archetypes: the campaigner who knew the right choice early on, the person who formed their opinion the first time they saw injustice, the person who gets there through a more explicit moral code, the ones who have to be pushed by someone who was a bit faster, the ones who have to be convinced but then work to convince others, and of course the person who is willing to take on the unfair and far-too-heavy burden of being exceptional enough that they can be used as a tool to force other people to acknowledge them as a person. And, since this is Discworld, Vetinari is lurking in the scenery pulling strings, balancing threats, navigating politics, and giving Vimes just enough leeway to try to change the world without abusing his power. I love that the amount of leeway Vimes gets depends on how egregious the offense is, and Vetinari calibrates this quite carefully without ever saying so openly.

Recommended, and as much as I don't want to see this series end, this is not a bad entry for the Watch novels to end on.

Followed in publication order by Raising Steam.

Rating: 8 out of 10

Trying to do a vector approach which most other programs with the pixel-perfect algorithm uses. So currently we have a vector strokeCoordinate initiated in kistoolfreehand because that's where strokes gets initiated, doStroke, and endStroke are. The ...

A review of the pros and cons of moving towards or away from publishing PDFs on government sites in Australia.

A month ago, I started working on a new application to manage your passwords in Plasma. And while still at a PoC status, this weekend, it finally started to look like something almost usable, so it sounded like a good occassion to write a small blog post about it.

The current name is “Keychain” or “Plasma Keychain” but this is subject to change and suggestions are more than welcome.

My end goal is to provide a more future proof replacement to the ageing KWallet application. From a technical point of view, this is a fork of the internal of KeepassXC with a Kirigami GUI completely written from scratch. This means it uses the standardized Keepass format to store the passwords in the database which is implemented by many applications including on other platforms like Android and iOS (see the list of Keepass port). And while not yet exposed in the GUI, basing the work on top of KeepassXC enables a lot of interesting features not available in KWallet, like Yubikey and PassKey support, password sharing, export and import for various other password database formats, TOTP support and browser integration…

While also providing vital features for the desktop integration like the Freedesktop Secret Service protocol what we also have in KWallet.

Here are some screenshots of the current state.

This is the main view where viewing, adding, editing and removing entries already work.

Main View

This is the database generator page which unfortunately doesn’t work yet.

Database generator

And this is the UI to open an existing database.

Database generator

As you can see there is still a lot of work required, so if people are interested to help or to take a look at the current progress, the code is on KDE’s gitlab instance.

One great way to extend your catalog of components is by creating components variations. Variations, in the context of component-driven development, refers to displaying your content in different ways. Variations of a component reduce the need of building new components as well as duplicate code.

In Storybook, variations are known as Stories. In this post I will be using variations and stories interchangeably.

The image below shows how different card stories or variations, can display the same content in many ways.

Fig. 1: Example of multiple variations of a Card component.

Principles of building components

Sometimes when building a new component, we can't anticipage how the website will evolve with time and therefore we build components the best way possible at the time of building them. As time goes by and requirements change, we realize that we could have done things differently had we known about the requirements changes. Variations of a component give you a chance to alter how something was built without having to change your entire environment of content architecture.

Some time ago I wrote about principles for building components. Rather than repeating myself, take a quick look at the article and comeback when you are done. You will find those principles not only apply to building new components, but also to building variations of components.

Building component variations in Storybook

In Storybook, all variations of a component are referred to as "Stories", hence the name Storybook. A story captures the rendered state of a UI component. Developers write multiple stories per component that describe all the “interesting” states/variations a component can support. Here's a visual that describes the official naming and hierarchy Storybook uses.

Fig. 2: Storybook's official naming convention and hierarchy.

The Card component

First off, I am going with the assumption that you already know how Storybook stories are created and that you have a Storybook instance running. If that's not the case, follow these instructions to get your Storybook environment up and running. You will need NodeJS 20+ and NVM installed on your system to follow along.

Next, let's look at the Card variations we will be creating in this post.

Fig. 3: Example of the different card variations we will build in this post.

The image above shows the Card stories or variations we will build. From top-left to right:

• Default or Stacked
• Light CTA
• Small
• No image
• Horizontal

In the interest of time, I have a repo that already includes the base of the Card component so you can focus only on building the variations.

1. Clone the repo which already contains a project to work with and the Card component.

   If you already have a working Storybook environment, copy the components directory (src/components), from the newly cloned repo, into your project.

2. Switch to the variations branch by running git checkout variations

3. Run the project as instructed in the README in the repo

Methods for creating stories

In this tutorial, we will use two methods for creating variations in Storybook:

1. Doing all the work directly in card.stories.jsx to change fields values or hide/show fields, depending on the story requirements.
2. Using additional *.yml files to assist with the same fields updates above.

We will be using the first method above for all stories except the Card horizontal. The original Card component was built with Twig, but for the variations we will be working exclusively in card.stories.jsx. The current version of the card story looks like this:

import parse from 'html-react-parser'; import card from './card.twig'; import data from './card.yml'; import './card.css'; const component = { title: 'Molecules/Card', render: (args) => parse(card(args)), }; export const Card = { name: 'Card stacked', args: { ...data }, }; export default component;

Let me explain the snippet above as this is the foundation for all the variations we will be creating.

• First we do a series of imports to collect all the pieces needed to build components and stories:

  • import parse: This is a react plugin which allows us to parse the HTML in our stories into React code Storybook can understand.
  • import card: It imports all the code and logic inside our component's twig template.
  • import data: Pulls in all the data from the component's .yml file so we can use it as React args.
  • import './card.css': Imports all CSS styles so Storybook can displayed the styled components and stories. Inside card.css, we already have styles for each of the stories we will be building.

• Next, we set a new configuration object called component, which will serve as the default instance of the card component. This is an arbitrary name and can be anything that makes sense to you.
  Inside the component object we have two properties: title and render.

  • The title property's value determines the location and name of the component within Storybook's hierarchy. In this example the Card component will be located under the Molecules folder. See Fig.2 above for details about the hierarchy.
  • The render property is what handles the rendering of the component by using the card and data objects we imported earlier, and combined together (Twig and YML), they render the full component.

• Next, we create our first story by defining a new configuration object called Card, in which we pass a name (Card stacked), for the story and the data variable as args.

• Finally, we export the component object as default, which is a React requirement.

If Storybook is running, you should see the new variation which will display the Card stacked. If you need to run Storybook for the first time, in your command line navigate to the storybook directory and run these commands:

IMPORTANT: You need NodeJS 20+ and NVM installed in your system. nvm install npm install npm run build npm run storybook

If all goes well, Storybook should be running showing the Card stacked story under the Molecules folder.

Preview of Card stacked

Fig. 4: Example of the Card stacked from which other variations will originate.

Card with light CTA

• Inside card.stories.jsx, and directly after the closing of the Card object (around line 17), add the following object to create a new story:

export const CardLightCta = { ...Card, name: 'Card light CTA', args: { ...data, cta: { modifier: 'button--light', text: 'Try it now', url: 'https://mariohernandez.io', } }, };

Let's go over the snippet above:

• We start by creating and exporting a new object called CardLightCta. This is a new story. This name is arbitrary but it should be unique for each story.
• Next, we pass the default Card story (...Card), as a spread operator, so the new story inherits all attributes from the original card.
• The name property allows for each story to have a unique name which will appear directly under the component name in Storybook's sidebar (see Fig. 2 at the top for details).
• Finally, we open the args object where we will update some of the fields to achieve the desired variation:
  • We pass the ...data object as a spread operator to individually update the fields that need updating.
  • Since the only difference between this variation and the original card is that the CTA is light, we need to define the cta object and provide each of its properties with the appropriate values:
    • First as a modifier class we pass button--light. This is a predefined modifier class which will turn the CTA white.
    • Next, we type the text that will become the CTA's label, Try it now.
    • And finally, we pass a URL to the CTA.

Preview of Card with light CTA

Fig. 5: Example of a Card component with a light CTA.

Card small

This next story or variation is the small version of the card. The difference between this card and the original one is that this one has no CTA, and its size is ...well, small 🙂

Same as before, add the following snippet to card.stories.jsx directly after the closing of the card with light CTA story:

export const CardSmall = { ...Card, name: 'Card small', args: { ...data, modifier: 'card--small', cta: '', }, };

This story is very similar to the previous one from the updates needed point of view. As you can see, the only thing we are doing is passing card--small as a modifier class to the entire component, and since we don't need a button or CTA, we are defining the cta object but its value is empty which will suppress it from printing on the page. If you notice in card.twig, we use a conditional that checks if the cta object exists, otherwise don't print any of the markup starting with the footer tag.

Preview of small card

Fig. 6: Example of a small card.

Card with no image

• You know the drill, inside card.stories.jsx, directly after the closing of the previous story, add the following snippet:

export const CardNoImage = { ...Card, name: 'Card no image', args: { ...data, modifier: 'card--no-image', image: '', }, };

Even more similar to the previous story, this variation only varies from the original story as follows:

• We are passing a modifier class to the component, card--no-image.
• Since we want no image, we define the image object but leave its value empty.

Preview of card without image

Fig. 6: Example of a card without image.

Card horizontal

The final variation is the Card horizontal. For all previous variations we have done all the changes inside card.stories.jsx, but for this one, we will resource to using an alternative *.yml file. Why you may ask, well, this variation requires a bit more changes and making all those changes inside the stories.jsx file may look a little too busy and not as easy to read the code. That's pretty much the only reason for me to use this method, to keep the code in my stories clean and more readable.

You may have noticed in the project you cloned; inside the card directory we have a file called card-horizontal.yml. This file is almost identical to the original card.yml as far as the fields in it. The only difference is that some of the fields have unique content or no content at all. Let's look at the file before starting.

--- modifier: 'card--horizontal' image: <img src="/card-square.jpg" alt="Palm trees near city buildings" /> title: level: 2 modifier: 'card__title' text: 'Step outside to the outdoors' url: 'https://mariohernandez.io' teaser: 'With spring in full bloom, the weather could not be better to take a walk outside and enjoy the beauty of nature.' cta: ''

• The modifier field has a specific CSS class we will pass: card--horizontal. This class will allow us to change the layout of the card to be in horizontal direction.
• The image field uses a different image altogether. The image has been cropped in square aspect ratio for better fitting of this variation.
• Finally, the cta field is empty, meaning we don't want to print a button on this variation.

Maybe I exaggerated when I said that this variation has too many changes, but my point is that in cases when your stories do require a lot of changes, using a different yml file may help you keep your stories.jsx file a lot neater and cleaner.

• The first step is one we haven't done before. Inside card.stories.jsx somewhere around line 5 (after the last import in the file), add the following import:

import dataHorizontal from './card-horizontal.yml';

• Next, the way we've done before, inside card.stories.jsx add the following object directly after the closing of the last story:

export const CardHorizontal = { ...Card, name: 'Card horizontal', args: { ...dataHorizontal, }, };

• First we imported a new data file called card-horizontal.yml and assigned the object name of dataHorizontal. By doing this, any changes we make inside card-horizontal.yml will be reflected in Storybook.
• Lastly, we repeat the same process as the previous variations but this time, inside the args object, we pass the new object we created in the previous step (...dataHorizontal), rather than ...data.
• That's it. Our story file is nice and clean. Since we handled all the fields updates in card-horizontal.yml, the .jsx file is simply consuming its data to achieve the desired variations.

Preview of horizontal card

Fig. 6: Example of a card in horizontal layout.

Now that we have covered both methods for creating variations, know that neither method is better than the other. The decision to use one over the other boils down to personal preferences and sometimes which makes the most sense to simplify the process.

End result

At the end of this process, your card.stories.jsx should look like this:

import parse from 'html-react-parser'; import card from './card.twig'; import data from './card.yml'; import dataHorizontal from './card-horizontal.yml'; import './card.css'; const component = { title: 'Molecules/Card', render: (args) => parse(card(args)), }; export const Card = { name: 'Card stacked', args: { ...data }, }; export const CardLightCta = { ...Card, name: 'Card light CTA', args: { ...data, cta: { modifier: 'button--light', text: 'Try it now', url: 'https://mariohernandez.io', } }, }; export const CardSmall = { ...Card, name: 'Card small', args: { ...data, modifier: 'card--small', cta: '', }, }; export const CardNoImage = { ...Card, name: 'Card no image', args: { ...data, modifier: 'card--no-image', image: '', }, }; export const CardHorizontal = { ...Card, name: 'Card horizontal', args: { ...dataHorizontal, }, }; export default component;

In closing

This only touches the surface of creating stories, but it is refreshing to know that no matter how complex your components may be, when it comes to having Storybook parse them, the React code in your stories is very minimum. Certainly, there are exceptions, but as I complete the migration of our large Drupal project with many components, some of which are pretty large and complex, we still were surprised how little React code was required of us to write because all the heavy lifting is being done by Storybook, with its contrib extensions, as well as Twig itself.

I am happy to announce a new release of GNU poke, version 4.2.

This is a bugfix release in the 4.x series.

See the file NEWS in the distribution tarball for a list of issues
fixed in this release.

The tarball poke-4.2.tar.gz is now available at
https://ftp.gnu.org/gnu/poke/poke-4.2.tar.gz.

    > GNU poke (http://www.jemarch.net/poke) is an interactive, extensible
    > editor for binary data.  Not limited to editing basic entities such
    > as bits and bytes, it provides a full-fledged procedural,
    > interactive programming language designed to describe data
    > structures and to operate on them.


Thanks to the people who contributed with code and/or documentation to
this release.

Happy poking!

Mohammad-Reza Nabipoor

This tutorial looks at how to build client-side UI components in Django with Stimulus and Tailwind.

The setup

Imagine you are living on a riverbank. Every now and then, the river swells and you have high water. The first few times this may come as a surprise, but soon you learn that such floods are a recurring occurrence at that river, and you make suitable preparation. Let’s say you feel well-prepared against any flood that is no higher than the highest one observed so far. The more floods you have seen, the higher that mark is, and the better prepared you are. But of course, eventually a higher flood will occur that surprises you.

Of course such new record floods are happening rarer and rarer as you have seen more of them. I was wondering though: By how much do the new records exceed the previous high mark? Does this excess decrease or increase over time?

A priori both could be. When the high mark is already rather high, maybe new record floods will just barley pass that mark? Or maybe, simply because new records are so rare events, when they do occur, they can be surprisingly bad?

This post is a leisurely mathematical investigating of this question, which of course isn’t restricted to high waters; it could be anything that produces a measurement repeatedly and (mostly) independently – weather events, sport results, dice rolls.

The answer of course depends on the distribution of results: How likely is each possible results.

Dice are simple

With dice rolls the answer is rather simple. Let our measurement be how often you can roll a die until it shows a 6. This simple game we can repeat many times, and keep track of our record. Let’s say the record happens to be 7 rolls. If in the next run we roll the die 7 times, and it still does not show a 6, then we know that we have broken the record, and every further roll increases by how much we beat the old record.

But note that how often we will now roll the die is completely independent of what happened before!

So for this game the answer is: The excess with which the record is broken is always the same.

Mathematically speaking this is because the distribution of “rolls until the die shows a 6” is memoryless. Such distributions are rather special, its essentially just the example we gave (a geometric distribution), or its continuous analogue (the exponential distributions, for example the time until a radioactive particle decays).

Mathematical formulation

With this out of the way, let us look at some other distributions, and for that, introduce some mathematical notations. Let X be a random variable with probability density function φ(x) and cumulative distribution function Φ(x), and a be the previous record. We are interested in the behavior of

Y(a) = X − a ∣ X > x

i.e. by how much X exceeds a under the condition that it did exceed a. How does Y change as a increases? In particular, how does the expected value of the excess e(a) = E(Y(a)) change?

Uniform distribution

If X is uniformly distributed between, say, 0 and 1, then a new record will appear uniformly distributed between a and 1, and as that range gets smaller, the excess must get smaller as well. More precisely,

e(a) = E(X − a ∣ X > a) = E(X ∣ X > a) − a = (1 − a)/2

This not very interesting linear line is plotted in blue in this diagram:

The expected record surpass for the uniform distribution

The orange line with the logarithmic scale on the right tries to convey how unlikely it is to surpass the record value a: it shows how many attempts we expect before the record is broken. This can be calculated by n(a) = 1/(1 − Φ(a)).

Normal distribution

For the normal distribution (with median 0 and standard derivation 1, to keep things simple), we can look up the expected value of the one-sided truncated normal distribution and obtain

e(a) = E(X ∣ X > a) − a = φ(a)/(1 − Φ(a)) − a

Now is this growing or shrinking? We can plot this an have a quick look:

The expected record surpass for the normal distribution

Indeed it is, too, a decreasing function!

(As a sanity check we can see that e(0) = √(2/π), which is the expected value of the half-normal distribution, as it should.)

Could it be any different?

This settles my question: It seems that each new surprisingly high water will tend to be less surprising than the previously – assuming high waters were uniformly or normally distributed, which is unlikely to be helpful.

This does raise the question, though, if there are probability distributions for which e(a) is be increasing?

I can try to construct one, and because it’s a bit easier, I’ll consider a discrete distribution on the positive natural numbers, and consider at g(0) = E(X) and g(1) = E(X − 1 ∣ X > 1). What does it take for g(1) > g(0)? Using E(X) = p + (1 − p)E(X ∣ X > 1) for p = P(X = 1) we find that in order to have g(1) > g(0), we need E(X) > 1/p.

This is plausible because we get equality when E(X) = 1/p, as it precisely the case for the geometric distribution. And it is also plausible that it helps if p is large (so that the next first record is likely just 1) and if, nevertheless, E(X) is large (so that if we do get an outcome other than 1, it’s much larger).

Starting with the geometric distribution, where P(X > n ∣ X ≥ n) = pn = p (the probability of again not rolling a six) is constant, it seems that these pn is increasing, we get the desired behavior. So let p1 < p2 < pn < … be an increasing sequence of probabilities, and define X so that P(X = n) = p1 ⋅ ⋯ ⋅ pn − 1 ⋅ (1 − pn) (imagine the die wears off and the more often you roll it, the less likely it shows a 6). Then for this variation of the game, every new record tends to exceed the previous more than previous records. As the p increase, we get a flatter long end in the probability distribution.

Gamma distribution

To get a nice plot, I’ll take the intuition from this and turn to continuous distributions. The Wikipedia page for the exponential distribution says it is a special case of the gamma distribution, which has an additional shape parameter α, and it seems that it could influence the shape of the distribution to be and make the probability distribution have a longer end. Let’s play around with β = 2 and α = 0.5, 1 and 1.5:

The expected record surpass for the gamma distribution

• For α = 1 (dotted) this should just be the exponential distribution, and we see that e(a) is flat, as predicted earlier.

• For larger α (dashed) the graph does not look much different from the one for the normal distribution – not a surprise, as for α → ∞, the gamma distribution turns into the normal distribution.

• For smaller α (solid) we get the desired effect: e(a) is increasing. This means that new records tend to break records more impressively.

The orange line shows that this comes at a cost: for a given old record a, new records are harder to come by with smaller α.

Conclusion

As usual, it all depends on the distribution. Otherwise, not much, it’s late.

I am pleased to announce the release of scikit-survival 0.23.0.

This release adds support for scikit-learn 1.4 and 1.5, which includes missing value support for RandomSurvivalForest. For more details on missing values support, see the section in the release announcement for 0.23.0.

Moreover, this release fixes critical bugs. When fitting SurvivalTree, the sample_weight is now correctly considered when computing the log-rank statistic for each split. This change also affects RandomSurvivalForest and ExtraSurvivalTrees which pass sample_weight to the individual trees in the ensemble. Therefore, the outputs produced by SurvivalTree, RandomSurvivalForest, and ExtraSurvivalTrees will differ from previous releases.

This release fixes a bug in ComponentwiseGradientBoostingSurvivalAnalysis and GradientBoostingSurvivalAnalysis when dropout is used. Previously, dropout was only applied starting with the third iteration, now dropout is applied in the second iteration too.

Finally, this release adds compatibility with numpy 2.0 and drops support for Python 3.8.

Install

scikit-survival is available for Linux, macOS, and Windows and can be installed either

via pip:

pip install scikit-survival

or via conda

conda install -c conda-forge scikit-survival

Hello! Today I have released new digital updates to my PyQt5, PyQt6, PySide2 and PySide6 book Create GUI Applications with Python & Qt.

This update brings all versions up to date with the latest developments in Qt, As well as corrections and additions to existing chapters, there are new sections dealing with form layouts, built-in dialogs and developing Qt applications using a Model View Controller (MVC) architecture.

As always, if you've previously bought a copy of the book you get these updates for free! Just go to the downloads page and enter the email you used for the purchase.

You can buy the latest editions below --

• PyQt6 Book 5th Edition, Create GUI Applications with Python & Qt6
• PySide6 Book, 5th Edition, Create GUI Applications with Python & Qt6
• PyQt5 Book 5th Edition, Create GUI Applications with Python & Qt5
• PySide2 Book 5th Edition, Create GUI Applications with Python & Qt5

If you bought the book elsewhere (in paperback or digital) you can register to get these updates too. Email your receipt to register@pythonguis.com

Enjoy!

KDE participates in OSPP 2024

We are pleased to announce our participation in the Open Source Promotion Plan (OSPP) 2024. KDE will mentor a project within this program. OSPP is largely organized by The Institute of Software at the Chinese Academy of Sciences. Its goal is to encourage college students to engage in developing and maintaining open-source software.

This marks KDE Community's first year participate in OSPP, and we mentor a project.

Porting KDE Games to the Android Platform

KDE Games and educational games are integral parts of the KDE Gear suite. This year, under the guidance of Benson Muite, Hanyang Zhang will undertake work in this area. Hanyang Zhang will be responsible for porting one to two KDE Games to the Android platform.

Let's warmly welcome the new contributor and wish them a enjoyable summer within KDE!

Hello! I intentionally skipped last month because I was busy with other tasks, and I didn’t have much to discuss KDE-wise. Anyway, let’s get started:

Akademy #

I have booked my travel plans for Akademy 2024, and hopefully this time my travel will be uneventful. I’ll be attending QtCS 2024 in Würzburg too. At the time of writing, the program has not been announced yet - so I’m not sure if I’m giving a talk yet, but fingers crossed 🤞

Art on Wayland #

A common problem with artists inquiring about the KDE Wayland session is that a lot of information is passed down. Some of the information is clearly out of date, and it spreads like wildfire. On top of that, factual information is scattered across multiple wiki pages, forum posts, and chat messages. I wrote up a page (personally maintained by me, mind) hosted at https://artonwayland.redstrate.com/. (If all goes well, I hope to retire this page in a year or two.)

In terms of software, gsetwacom was recently released by Peter Hutterer. So, I created our own (intentionally a seperate tool), called ktabletconfig. I personally don’t have a use for this tool, but I wanted to create it anyway. I hope it serves someone well!

I do plan on expanding ktabletconfig’s features, as the Wayland session continues to mature.

Plasma #

Feature I merged the tablet tester, finally! Thanks to Nate for pushing it past the finish line, as always. 6.2

A slightly out of date screenshot of the Tester

Feature Clearly explain what left-handed mode does in the Tablet KCM, because even I didn’t know until I looked it up! 6.2

Feature Rebased and merged Aki Sakurai’s “Map to Workspace” (aka all monitors) feature for the Tablet KCM. 6.2

Bugfix I also fixed the wrong aspect ratio for the output preview in the Tablet KCM. Now mapping between 4:3 and 16:9 screens should make more sense in the UI. 6.1

Bugfix Went through the whole Tablet KCM and cleaned up the terms we use. It’s a small thing, but I hope it makes the features we have more understandable. 6.2

Frameworks #

Feature I have begun adding a way for Kirigami applications to save and restore window state like our QtWidget applications do. I have stalled on it because of something else, but this is something I want to finish soon. ???

Feature Added a generic “translate” icon for applications based on the crow-translate icon we already have. 6.4

Tokodon #

Feature I finished up and merged quoted posts support! I’m also pretty happy with the implementation. 24.08

Quoted posts are now “supported” in Tokodon, at least with what we can do Krita #

Bugfix Fixed the “DEV BUILD” badge going to a 404. 5.2.3

Bugfix Fix the lag in the tablet tester when using it with a S-Pen on Android. 5.2.3

Bugfix Multiple small improvements for the S-Pen on Android. 5.2.3

I changed up some of the text and mentioned S9 family support here now! NeoChat #

Bugfix Prevented the location map showing up even though no locations were shared. That also fixes copyright link activation! 24.05

Bugfix Fixed the QR code not showing up on the account page. 24.05

Bugfix Added a focus border to the appearance page modes, which helps users who solely depend on the keyboard. (It was navigable before, but you would have no idea which one was selected.) 24.05

Bugfix Removed room members being highlighted on tap. This makes the member list appear slightly less buggy. 24.05

Feature Added basic keyboard navigation for the server selection popup. 24.05

Bugfix Fixed keyboard navigation in the space drawer. 24.05

Bugfix Fixed keyboard navigation on the room & user search pages. 24.05

Other #

Bugfix Fixed keyboard navigation for Kirigami Add-on’s FormComboBoxDelegate, which improves keyboard navigation in lots of Kirigami applications! 1.3.0

I updated the Plasma Desktop README in line with the other README things I did this year!

My work in KDE for April 2024

My Work in KDE

Home

55th issue of Andrei Neagoie's must-read monthly Python Newsletter

aider: Console-based LLM pair programming tool, to edit code in your local git repository.

Links:

• Repo
• Home

napar: A fast, interactive, multi-dimensional image viewer for annotation and analysis of large images.

Links:

• Repo
• Home
• Fund

Plane: Modern, self-hostable issue and product roadmap tracker. An alternative to JIRA, Linear, and Asana.

Links:

• Repo
• Home

Codex: Self-hostable comic archive browser and reader.

Links:

• Repo
• Demo

Review: Bitter Angels, by C.L. Anderson

Publisher: Ballantine Books Copyright: 2009 ISBN: 0-553-59217-3 Format: Mass market Pages: 438

Bitter Angels is a stand-alone science fiction novel. It won the Philip K. Dick award for best SF original paperback in 2010. C.L. Anderson is a pen name for Sarah Zettel.

Terese was a Guardian, one of the agents of the Pax Solaris who find ways to keep the peace in troubled systems and high-stress situations with the help of an implanted Companion, an assistant AI. Forty years ago, on one of those missions, she was captured and her Companion was forcibly removed. She was rescued by her friend and mentor and retired afterwards, starting a new life and a new family, trying to leave the memories behind.

Now, the woman who rescued her is dead. She was murdered on duty in the Erasmus system, a corporate hellhole that appears to be on the verge of exploding into a political hot spot. Bianca's last instructions asked for Terese to replace her. Terese's family is furious at her for even considering returning to the Guardians, but she can't say no. Duty, and Bianca's dying request, call too strongly.

Amerand is Security on Dazzle, one of the Erasmus stations. He is one of the refugees from Oblivion, the station that the First Bloods who rule the system let die. He keeps his head above water and tries to protect his father and find his mother without doing anything that the ever-present Clerks might find concerning. Keeping an eye on newly-arriving Solaris saints is a typical assignment, since the First Bloods don't trust the meddling do-gooders. But something is not quite right, and a cryptic warning from his Clerk makes him even more suspicious.

This is the second book by Sarah Zettel that I've read, and both of them have been tense, claustrophobic thrillers set in a world with harsh social inequality and little space for the characters to maneuver. In this case, the structure of her future universe reminded me a bit of Iain M. Banks's Culture, but with less advanced technology and only humans. The Pax Solaris has eliminated war within its borders and greatly extended lifespans. That peace is maintained by Guardians, who play a role similar to Special Circumstances but a bit more idealist and less lethal. They show up where there are problems and meddle, manipulating and pushing to try to defuse the problems before they reach the Pax Solaris.

Like a Culture novel, nearly all of the action takes place outside the Pax Solaris in the Erasmus system. Erasmus is a corporate colony that has turned into a cross between a hereditary dictatorship and the Corporate Rim from Martha Wells's Murderbot series. Debt slavery is ubiquitous, economic inequality is inconceivably vast, and the Clerks are everywhere. Erasmus natives like Amerand have very little leeway and even fewer options. Survival is a matter of not drawing the attention of the wrong people. Terese and her fellow Guardians are appalled, but also keenly aware that destabilizing the local politics may make the situation even worse and get a lot of people killed.

Bitter Angels is structured like a mystery: who killed Bianca, and what was her plan when she was killed? Unlike a lot of books of this type, the villains are not idiots and their plan is both satisfyingly complex and still depressingly relevant. I don't think I'm giving anything away by saying that I have read recent news articles about people with very similar plans, albeit involving less science-fiction technology. Anderson starts with a tense situation and increases the pressure relentlessly, leaving the heroes one step behind the villains for almost the entire novel. It is not happy or optimistic reading — at times, the book is quite dark — but it certainly was engrossing.

The one world-building quibble that I had is that the Erasmus system is portrayed partly as a hydraulic empire, and while this is arguably feasible given that spaceship travel is strictly controlled, it seemed like a weird choice given the prevalence of water on the nearby moons. Water smuggling plays a significant role in the plot, and I wasn't entirely convinced of the politics and logistics behind it. If this sort of thing bugs you, there are some pieces that may require suspension of disbelief.

Bitter Angels is the sort of tense thriller where catastrophe is barely avoided and the cost of victory is too high, so you will want to be in the mood for that before you dive in. But if that's what you're looking for, I thought Anderson delivered a complex and satisfying story.

Content warning: major character suicide.

Rating: 7 out of 10