FLOSS Project Planets

Season Of KDE 2024 Conclusion

Planet KDE - Wed, 2024-05-08 20:00
Introduction

Another year, another successful Season Of KDE for 12 contributors!

This article has been co-written with the input from all contributors.

Translation Projects

KDE counts on a very active translation community and translates software into over 50 different languages. In SOK 2024, we had 2 projects that focused on translating multiple apps into Hindi. Asish Kumar and Akash Kumar joined the KDE Hindi community to translate multiple apps into Hindi. They both worked together on translating Merkuro, then Akash focused on Tellico while Asish worked on KDE Connect and Cantor.

Kdenlive

Kdenlive brings you all you need to edit and put together your own movies. We had 2 projects for KDE's full-featured video editor:

  • Ajay Chauhan implemented multi-format rendering for Kdenlive by adding a filter to adjust the aspect ratio of video clips in the main track, allowing users to select the desired aspect ratio during export, and integrating it into the final rendering profile. Ajay also added code to apply filters to clips, calculate crop parameters, and handle video cropping to the desired ratio; and implemented the GUI component ComboBox that selects the aspect ratio and ensures that the selected ratio is passed to the RenderRequest object. Additionally, various issues were fixed during development, such as temporary file handling issue, preventing crashes, and refactoring code.

  • aisuneko icecat created a prototype keyframe curve editor GUI for Kdenlive. Based on recent progress in introducing advanced keyframe types and capabilities into the editor, the widget allows the user to intuitively view and control the current animation curve of keyframable effect parameters. As of now, the widget supports basic interactions such as dragging and double clicking, and integrates well with other existing Kdenlive components. This is still a work-in-progress feature, as more work needs to be done beyond SoK to have it further enhanced before it can be released to end users.

KDE Eco / Accessibility

There are 5 new projects that made measuring the energy consumption of software easier and more integrated in the development pipeline. This helps make KDE software more efficient and environmentally friendly, as well as more accessible at the same time:

  • Sarthak Negi focused on testing, bug-fixing and integrating measurement workflows on KEcoLab. After setting up the testing environments, Sarthak worked on creating a CI test and refactoring code for efficiency and the code has been merged in the main repository.

  • Pradyot Ranjan worked on improving and updating the setup guide for selenium, a tool to automatize testing. The result can be found on this wiki page.

  • Amartya Chakraborty added support for KdeEcoTest on the Windows platforms. To do this, Amartya replicated test-scripts for Okular test using KdeEcoTest which previously used xdotool. Now this test-script can be executed on any platform. The conditional installation of packages based on the platform using pipenv has been implemented.

  • Athul Raj Kollareth worked on bringing support for KdeEcoTest on Wayland systems. The initial work consisted of [adding an abstraction layer](https://invent.kde.org/echarruau/feep-win-32-kdotool-integration/-/ merge_requests/1) so that KdeEcoTest could be run on different platforms including Windows. To build support for Wayland, we had to first restrict our scope and finally decided to move with only supporting the KWin compositor as it had built in functionalities for automating window related manipulations on the GUI. To automate input devices, the Linux kernel's evdev module was used which allowed us to monitor input devices and also emulate them using uinput. With these changes integrated into KdeEcoTest, we were able to run tests on Wayland, X11 and Windows thanks to Amartya's implementation. ![KEcoTest running on Wayland](KdeEcoTest_running under wayland.png)

  • Aakarsh MJ worked on integrating KEcolab into Okular's pipeline. This will allow the Okular team to measure energy consumption for each release. This paves the way for the creation of a template which will be further helpful for other projects as well. A merge request is in progress to integrate it into Okular.

Cantor / LabPlot

Cantor is an application that lets you use your favorite mathematical programming language from within a friendly worksheet interface, while Labplot is KDE's user-friendly data visualization and analysis software. Both applications are closely intertwined, and have had three projects completed during SOK:

  • Dhairya Majmudar worked on extending the embedded documentation for supported Computer Algebra Systems Project. Dhairya created the common styles for several mathematical system documents, enhancing the users' experience allowing them to use them simultaneously; and Python scripts have been written to link the stylesheets to the HTML files. These Python scripts are further extended to convert HTML files in Qt Help files that can be uploaded to the KDE Store. The in-progress merge request can be found at: https://invent.kde.org/education/cantor/-/merge_requests/74.

  • Israel Galadima contributed to the "LabPlot: Download/Import of datasets from kaggle.com" project. Since kaggle.com seems to be the central place nowadays for finding datasets in the data science community, we wanted LabPlot's users to be able to access the datasets on kaggle.com directly from within LabPlot. Thus, Israel worked on a new dialog in LabPlot that allows users to search for and import datasets directly from kaggle.com into LabPlot spreadsheets, using the official kaggle cli tool to facilitate the communication between LabPlot and kaggle.com. Multiple merge requests have been merged, the last one is still in review.

  • Raphael Wirth introduced the support for data stored in the MCAP format to LabPlot. Throughout the project, Raphael extended the backend of LabPlot to allow the loading of JSON-encoded MCAP files into its internal data structure as well as the export back to the MCAP file format. Additionally, the user interface has been adapted to accommodate these advancements. This required the extension of the existing import dialog and the introduction of a new export dialog tailored specifically for saving MCAP files.

We would like to congratulate all participants and look forward to their future journey with KDE!

Categories: FLOSS Project Planets

The State of KDE Apps and Plasma in Archlinux

Planet KDE - Wed, 2024-05-08 20:00

KDE has a symbiotic relationship with many linux distros, since while we develop our software we also use particular versions of linux, I personally use archlinux as my distro of choice for many years being the only distro that I manage to bare for more than six months ( and I believe I am using it for more than 15 years already so that counts).

The "recipe" for packaging KDE software for arch is big, because we are big, and packaging large amounts of software is no easy feat, so me and Antonio Rojas started to update the build scripts to be less manual and less error prone. All the versions of Plasma 6 that have been packaged for arch are using this scripts in one way or another (or manually when we broke everything :)

This work is being done in a separate branch to not break the current workflow, but things are looking good and we hope to merge this in master soon, so that deploying newer versions of KDE software for arch will be a single command, meaning more time for the developers and less time creating packages.

Categories: FLOSS Project Planets

Trey Hunner: My favorite Python 3.13 feature

Planet Python - Wed, 2024-05-08 16:30

Python 3.13 just hit feature freeze with the first beta release today.

Just before the feature freeze, a shiny new feature was added: a brand new Python REPL. ✨

This new Python REPL is will likely be my favorite thing about 3.13. It’s definitely the feature I’m most looking forward to using while teaching after 3.13.0 final is released later this year.

I’d like to share what’s so great about this new REPL and what additional improvements I’m hoping we might see in future Python releases.

Little niceties

The first thing you’ll notice when you launch the new REPL is the colored prompt.

You may also notice that as you type a block of code, after the first indented line, the next line will be auto-indented! Additionally, hitting the Tab key inserts 4 spaces now, which means there’s no more need to ever hit Space Space Space Space to indent ever again.

At this point you might be thinking, “wait did I accidentally launch ptpython or some other alternate REPL?” But it gets even better!

You can “exit” now

Have you ever typed exit at the Python REPL? If so, you’ve seen a message like this:

1 2 >>> exit Use exit() or Ctrl-D (i.e. EOF) to exit

That feels a bit silly, doesn’t it? Well, typing exit will exit immediately.

Typing help also enters help mode now (previously you needed to call help() as a function).

Block-level history

The feature that will make the biggest different in my own usage of the Python REPL is block-level history.

I make typos all the time while teaching. I also often want to re-run a specific block of code with a couple small changes.

The old-style Python REPL stores history line-by-line. So editing a block of code in the old REPL required hitting the up arrow many times, hitting Enter, hitting the up arrow many more times, hitting Enter, etc. until each line in a block was chosen. At the same time you also needed to make sure to edit your changes along the way… or you’ll end up re-running the same block with the same typo as before!

The ability to edit a previously typed block of code is huge for me. For certain sections of my Python curriculum, I hop into ptpython or IPython specifically for this feature. Now I’ll be able to use the default Python REPL instead.

Pasting code just works

The next big feature for me is the ability to paste code.

Check this out:

Not impressed? Well, watch what happens when we paste that same block of code into the old Python REPL:

The old REPL treated pasted text the same as manually typed text. When two consecutive newlines were encountered in the old REPL, it would end the current block of code because it assumed the Enter key had been pressed twice.

The new REPL supports bracketed paste, which is was invented in 2002 and has since been adopted by all modern terminal emulators.

No Windows support? Curses!

Unfortunately, this new REPL doesn’t currently work on Windows. This new REPL relies on the curses and readline modules, neither of which are available on Windows. I’m hoping that this new REPL might encourage the addition of curses support on Windows (there are multiple issues discussing this).

The in-browser Python REPL on Python Morsels also won’t be able to use the new REPL because readline and curses aren’t available in the WebAssembly Python build.

Beta test Python 3.13 to try out the new REPL 💖

Huge thanks to Pablo Galindo Salgado, Łukasz Langa, and Lysandros Nikolaou for implementing this new feature! And thanks to Michael Hudson-Doyle and Armin Rigo for implementing the original version of this REPL, which was heavily borrowed from PyPy’s pyrepl project.

The new Python REPL coming in 3.13 is a major improvement over the old REPL. While the lack of Windows support is disappointing, but I’m hopeful that a motivated Windows user will help add support eventually!

Want to try out this new REPL? Download and install Python 3.13.0 beta 1!

Beta testing new Python releases helps the Python core team ensure the final release of 3.13.0 is as stable and functional as possible. If you notice a bug, check the issue tracker to see if it’s been reported yet and if not report it!

Categories: FLOSS Project Planets

PreviousNext: Creating a cards section with Layout Builder

Planet Drupal - Wed, 2024-05-08 16:00

In this post, we explore building a cards section with Layout Builder.

 

by lee.rowlands / 9 May 2024

The component will look something like the 'Services' section on our homepage*. If you've built websites over the last decade, you've probably built a component like this many times.

The key aspects of the component are

  • A title
  • Some intro text
  • A series of cards. Each card has a URL, title, image and teaser text

If you've previously used paragraphs for modelling landing pages, you may immediately be thinking that your content model will be made up of paragraph type 'cards' with three fields as follows:

  • A title
  • A teaser field for the intro text
  • A multi-value cards field, which is itself another paragraph type 'card'.

Or rather, because this is Layout Builder, you might be thinking of a block-content type called cards with those fields on it — leaning on paragraphs for the multi-value cards field.

Whilst that approach works well for paragraphs, it isn't the best approach for Layout Builder:

  • There are some gnarly bugs with Layout Builder + Block Content + Paragraphs + Content moderation
  • It requires content-editors to fumble in the off-canvas editor to rearrange each card using drag-and-drop. We want a nice re-order experience like this:
Making the most of layout plugins

Let's instead pivot to a layout plugin for the cards component and think of it in terms of regions.

We have:

  • A layout title
  • An introduction region
  • A cards region

We probably already have a block-content type that consists of a WYSIWYG field — e.g., something like the Basic block content type in core. We can use that for the intro text.

So we need a card block content-type. But we probably want two. A lot of our cards will just point to other pages on the site — and it makes sense for the card to be built from fields on that page. If we put a teaser image and teaser text field on all our node-types, we can make use of them when creating a card for that page. We can also use these for meta-tags like the OpenGraph image. And all our node-types already have a title and URL. The second block-type is if we need to link to pages outside the site. So, the content models for those two block types are as follows:

  • For the internal card block-type, we need an entity-reference field to allow the content-editor to select the content to generate the card for
  • For the external card block-type, we need all the fields — title, image, teaser, URL
Defining layout plugins

Next, we need to define our layout plugin. We start with a layouts.yml file in our theme or module.

cards:   label: Card grid   category: Layouts   template: layouts/cards   icon_map:     - [intro, intro, intro]     - [c1, c2, c3]     - [c4, c5, c6]     - [c7, c8, c9]     - [c10, c11, c12]   regions:     content:       label: Cards     intro:       label: Introduction   library: 'your_theme/card'

Note: the icon_map isn't needed here, but it gives us a nice icon in the 'Add section' form.

With those pieces in place, we can use Layout builder restrictions to ensure only the right block-types can be placed in each region. The introduction region can be limited to the basic WYSIWYG block-type. The cards region can be limited to the internal and external card block-type.

This layout will use the default layout plugin, but we want a custom layout plugin with a title field in the configuration form. You can read more about creating a custom layout plugin from our previous post about creating a dynamic layout with flexible regions. This one will be much simpler. We just need a title field in the configuration form and a preprocess hook to expose that to our template. 

The first step of this is to add a 'class' entry to our layout definition.

cards: // ...   class: \Drupal\your_theme\Layouts\Cards   // ...

Then, we need to create that class. 

<?php namespace Drupal\your_theme\Layouts; use Drupal\Core\Form\FormStateInterface; use Drupal\Core\Layout\LayoutDefault; /** * Defines a class for a layout that has a title option. */ class LayoutWithTitle extends LayoutDefault { /** * {@inheritdoc} */ public function defaultConfiguration() { return parent::defaultConfiguration() + ['title' => '']; } /** * {@inheritdoc} */ public function buildConfigurationForm(array $form, FormStateInterface $form_state): array { $build = parent::buildConfigurationForm($form, $form_state); $build['title'] = [ '#weight' => -10, '#type' => 'textfield', '#default_value' => $this->configuration['title'], '#title' => $this->t('Title'), '#description' => $this->t('Provide an optional title for this section'), ]; return $build; } /** * {@inheritdoc} */ public function submitConfigurationForm(array &$form, FormStateInterface $form_state): void { parent::submitConfigurationForm($form, $form_state); $this->configuration['title'] = $form_state->getValue('title'); } }

Then, in your theme you can preprocess to make this variable available to the template.

/** * Implements hook_preprocess_HOOK(). */ function your_theme_preprocess_layout(array &$variables): void { // Add the title from LayoutWithTitle. $variables['title'] = $variables['content']['#settings']['title'] ?? NULL; }

For optimum UX, we'd probably want to make Layout Builder Browser blocks, too. You can read more in our previous post about our approach to Layout Builder UX.

All that remains then is to theme the block-content types to match the design. For more on that, see our previous post on theming block-content types with Layout Builder.

As an extra enhancement, you could add integration with Layout Section Classes module to give content editors additional options like the number of cards shown across the page in the card grid.

Note: this component on our website is automated and built with Views, but there is often a need to build out curated equivalents.

Tagged Layout Builder
Categories: FLOSS Project Planets

Python Insider: Python 3.13.0 beta 1 released

Planet Python - Wed, 2024-05-08 14:11

I'm pleased to announce the release of Python 3.13 beta 1 (and feature freeze for Python 3.13).

https://www.python.org/downloads/release/python-3130b1/

 

This is a beta preview of Python 3.13

Python 3.13 is still in development. This release, 3.13.0b1, is the first of four beta release previews of 3.13.

Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release.

We strongly encourage maintainers of third-party Python projects to test with 3.13 during the beta phase and report issues found to the Python bug tracker as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Tuesday 2024-07-30). Our goal is to have no ABI changes after beta 4 and as few code changes as possible after 3.13.0rc1, the first release candidate. To achieve that, it will be extremely important to get as much exposure for 3.13 as possible during the beta phase.

Please keep in mind that this is a preview release and its use is not recommended for production environments.

Major new features of the 3.13 series, compared to 3.12

Some of the new major new features and changes in Python 3.13 are:

New features Typing Removals and new deprecations
  • PEP 594 (Removing dead batteries from the standard library) scheduled removals of many deprecated modules: aifc, audioop, chunk, cgi, cgitb, crypt, imghdr, mailcap, msilib, nis, nntplib, ossaudiodev, pipes, sndhdr, spwd, sunau, telnetlib, uu, xdrlib, lib2to3.
  • Many other removals of deprecated classes, functions and methods in various standard library modules.
  • C API removals and deprecations. (Some removals present in alpha 1 were reverted in alpha 2, as the removals were deemed too disruptive at this time.)
  • New deprecations, most of which are scheduled for removal from Python 3.15 or 3.16.

(Hey, fellow core developer, if a feature you find important is missing from this list, let Thomas know.)

For more details on the changes to Python 3.13, see What’s new in Python 3.13. The next pre-release of Python 3.13 will be 3.13.0b2, currently scheduled for 2024-05-28.

 More resources  Enjoy the new releases

Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation.

Your release team,
Thomas Wouters
Łukasz Langa
Ned Deily
Steve Dower 

 

Categories: FLOSS Project Planets

Acquia Developer Portal Blog: DrupalCon Portland Day 2 Recap

Planet Drupal - Wed, 2024-05-08 13:47

Welcome to Day 2 at DrupalCon!! Today is another exhilarating day packed with cutting-edge sessions, collaborative workshops, and unparalleled networking opportunities. There are few better ways to enhance your skills and connect you with the vibrant Drupal community. Let's dive deeper into the world of Drupal and check out a few highlights from Day 2:

Keynote: Open Source AI Now: Why Open Must Win the AI War

Categories: FLOSS Project Planets

KDE e.V. is looking for a web designer (Hugo) for environmental sustainability project

Planet KDE - Wed, 2024-05-08 13:30

KDE e.V., the non-profit organisation supporting the KDE community, is looking for a web designer who is skilled with Hugo to implement a new environmental sustainability campaign for the KDE Eco website. Please see the [job ad]({{ '/resources/jobad-KDE-Eco-Website_2024.pdf' | prepend: site.url }}) for more details about this employment opportunity.

We are looking forward to your application.

Categories: FLOSS Project Planets

Evolving Web: Inside Access: Stories of the 12 Stars of EvolveDrupal Atlanta

Planet Drupal - Wed, 2024-05-08 13:19

Last month we took EvolveDrupal—a unique summit that fosters digital transformation and open source collaboration—to Atlanta for its first appearance in the United States.  

Couldn’t attend? Well, no need to feel left out! You can get the inside scoop right here. I’ve shared stories about 12 summit stars that’ll have you smiling, chuckling, or taking notes.

Attendees will find this a worthwhile read, too. Because unless you harnessed an AI bot to put you in three rooms at once, we’re betting there’s plenty you missed!

Ready to meet our stars? First, a quick refresher for those who need it.

Wait, What’s EvolveDrupal Again?

Ok, let’s rewind. About a year ago our digital agency started EvolveDrupal in our hometown of Montreal. After years of remote meet-ups, it was a way to finally reunite the tech and design communities in person. 

People were overjoyed to socialize in the same room as their peers again! Because let’s face it: sharing a beer on Zoom just isn’t the same. There’s none of those silly stories and spontaneous oversharing that really bring people together. 

After that first summit, we built on EvolveDrupal’s success with events in Toronto and Ottawa, before heading across the border to Atlanta. (Psst... a little birdy told me we're coming back to the U.S. in September for EvolveDrupal NYC.)

Meet the Stars of EvolveDrupal Atlanta

Now that you’re up to speed, here are all the juicy details you’re waiting for. Meet the standout stars who made EvolveDrupal Atlanta absolutely stellar. 

1. Our Event-Planning Extraordinaire, Maya Schaeffer

Maya wears multiple hats at Evolving Web. On top of taking care of us as our Employee Experience & Operations Manager, she’s the de facto Chief Event Organizer for EvolveDrupal. Maya learned on-the-job to orchestrate big corporate gatherings and she tirelessly ensures their success. You can find her at EvolveDrupal looking like she’s in her element.

Unforeseen challenges and setbacks are an inevitable part of events—like the time a well-known office supplies company printed all of our participants’ name tags upside down! But Maya has learned to roll with the punches and adapt quickly.

Maya’s can-do attitude means she sometimes tries to do everything herself, but she’s learned to delegate more over the past year. Her charming smile means that few people can say “no” to her requests. 

 

No one is a match for Maya's organizing skills!
2. Our Boss Baby: Sofia 

Just 15 months old, Sofia has been to more Drupal conferences than most seasoned developers. She has accompanied her parents (our co-founders Alex and Suzanne) to DrupalCon Pittsburgh, DrupalConLille, GovCon, High Ed Web, and all four of our previous EvolveDrupal summits.  

With this trajectory, in 20 years she’ll have the elusive combination that so many employers seek: a freshly minted college degree and two decades of Drupal experience. 

Expect to see Sofia in Forbes 5 Under 5 very soon.

 

Sofia loves showing her Drupal pride, accompanied by Alex (her dad), Maya, and Sammy the Eagle.
3. Artificial Intelligence  

I’d like to thank ChatGPT for writing this blog post. Joking! I’m a real person, I swear. Yet everywhere we look it seems that AI is popping up as a way to generate content, code, images, and so much more. So it was really helpful to get some perspective from the experts.

Nikhil Deshpande, Chief Digital & AI Officer at the Georgia Technology Authority, sat down for a Q&A session with our co-founder, Suzanne Dergacheva. Their discussion hit on a crucial dilemma: how to accelerate innovation through open source while retaining integrity and managing risk.

Some key takeaways from their talk include:

  • AI has progressed beyond analytical tasks to creative endeavors like writing poetry.
  • Its role in the workplace is expanding: over half of the U.S. workforce now uses AI tools to enhance productivity.
  • AI is also shaping public services and government operations. In Minnesota, AI translation has improved accessibility for non-English speakers.
  • In this age of AI, ethical considerations and good content governance are more important than ever. 
  • The integration of AI technologies into existing systems will foster a new era of innovation—one where these tools not only enhance existing processes, but optimize creativity and problem solving.

We also heard from Misha Sulpovar, Head of AI at Cherre & Wired Cognition. In This Is not a Drill: Seeing the Real Opportunities Among the AI Hype, Misha debunked some common myths about AI. No, robots are not going to take over. No, the robots didn’t tell us to say that. In the face of concerns that machines will take our jobs, Misha argues that AI is actually enhancing—instead of replacing—human capabilities. It’s time to embrace the robots. They’re your new work besties. 

4. A11y (a.k.a. Accessibility)

Championing open source goes hand-in-hand with advocating for accessibility. At Evolving Web we’re committed to making the web a better place for all. So we were thrilled to host not one, but two accessibility sessions at EvolveDrupal Atlanta!

Mary Blabaum, Senior UX Manager at Acquia, gave a great overview of accessibility in her session 5 Ways to Grow Your Inclusive Design Approach

  • Understand your user needs
  • Activate by including inclusive strategy into your day to day
  • Set standards such as adhering to WCAG
  • Create with intent by baking inclusion into your design process
  • Measure what matters using transparent accessibility conformance reports

 

Mary Blabaum from Acquia offered strategies to make accessibility the default in every design.

 

Penny Kronz, VP of Client Services at DubBot, gave us the rundown on the new success criteria in WCAG guidelines 2.2  with her session WCAG 2.2: What Changed? What Do I Need to Know? so that we can meet the latest accessibility requirements. Some notable changes include new criteria for increased touch target size, consistent focus appearance, and easy dismissal of pop-ups. While WCAG 2.2 retains the same structure as previous versions, it offers more specific guidance for building inclusive digital experiences.

5. OOUX  

So much more than a pleasing acronym, object-oriented UX (OOUX) is a proven method for making user experiences more human-centric. Sophia Prater taught us how to shift our UX process to turn complex processes into intuitive user flows in How to Fix UX Fails with Object-Oriented UX. The room was packed, with every seat taken and more participants standing at the back to catch the talk! 

One great takeaway from the talk was "ORCA". No relation to the whale. ORCA is an acronym that highlights great questions to ask when designing a single screen: 

  • O: What are the objects in the users' mental model?
  • R: What are the objects' relationships to each other?
  • C: What calls-to-action do objects offer users?
  • A: What are the attributes that make up the objects?
6. Our Creative Director, Morgan, and His Infallible Attention to Detail

Morgan decided to take a steamer to our backdrops. There wasn’t a single wrinkle to be seen when he was done with them. Not that he’s a Monica or anything (from the TV show Friends for those who—gasp!—don't get the reference.) 

Morgan also delivered From Chaos to Clarity: The Benefits and Challenges of Design Systems with Bryenne. They dived into the complexities and challenges our team has encountered over the years, offering up some invaluable best practices for creating a sustainable design system.

Finally, Morgan captivated a creative audience at our EvolveUX Unconference, an interactive session with real-time feedback from the audience. Morgan showcased the Planned Parenthood Direct app and took participants behind the scenes of the project. 

 

Creases? Not on Morgan's watch.
7. Sammy the Eagle

You read that right—the official mascot of Drupal GovCon swooped in to steal the show at EvolveDrupal Atlanta. I guess it’s easy when you have wings. Naturally, we set aside a free ticket and cleared his visit with the civil aviation authorities. 

 

The Eagle has landed. Sammy the Eagle, that is.
8. Steve Persch’s Twister Board

Steve Persch is a seasoned Drupalist and the Director of Developer Experience at Pantheon. He’s also a theater grad! Which explains why he brings a dramatic flair to even the most technical of presentations.  

In his talk The Fourth Decade of Web Deployments, Steve literally bent over backwards to illustrate how complex web pages have become. It certainly woke people up to see Steve pretzeling on a Twister board first thing in the morning. We’ve never seen a more visually stimulating illustration of a technical concept. Proof that majoring in theatre is useful, no matter what the haters say. 

 

Always stretch before attending EvolveDrupal.
9. The EPIC Page Builder Battle 

The boxing gloves came out when five speakers went head-to-head, each of them representing a different page building tool. And if you thought Drupal would have a leg up at an event with Drupal in the name, think again! It was no match for the ease with which our designer Yue Lu could build a site in Webflow.

Nevertheless, the key takeaway from our Page Builder Battle was that no single tool is perfect for everyone or every project. Choosing the right tool depends heavily on your unique needs.

We also learned that while Drupal’s content creation experience has room for improvement, the Drupal community is aware of this fact and actively working on it.

 

We duked it out to see which page builder tool is the ultimate champion.
10. Josh, Our Magic Weatherman

Our Atlanta-based team member, Josh, seems to have a mysterious ability to control the weather. Who knows how he did it, but Josh ordered some darn good weather for the event. 

Booking the rooftop patio three months in advance was always going to be a gamble. So we were biting our fingernails as rain poured down the day before… but the summit rolled around with nothing but the bluest of skies! Honourable mention to Josh because we're sure he had something to do with it. Definitely a wizard.

 

Team members Adrienne and Josh enjoying suspiciously good weather at the Zivtech rooftop after-party. 
11. The Drake Quote in our Brand Colours

As we left the elevator for the rooftop after-party, what did we see but a big quote from Drake on the wall! Way to make a canuck feel at home. And way to make us feel special, because it was in our brand green.  

 

We're definitely not team Kendrick.
12. The Airbnb Deer

This is becoming a weird trend for us. It all started with the Airbnb we stayed in for DrupalCamp Florida. Our team walked in to find a huge taxidermy deer on the wall. After initially feeling creeped out, they named him Luke and accepted him as part of the gang.

Would you believe it, when we turned up at our Airbnb for DrupalCamp New Jersey—oh dear, another deer! This one was named Frosty because he seemed a little aloof.

And then in Atlanta, what did we find but yet another deer! Perhaps we should just listen to the signs from the universe and get one for our office.
 

What should our Atlanta deer be called? Send name suggestions on a postcard.
Join the EvolveDrupal Adventure

Tickets are now on sale for EvolveDrupal Montreal on June 14. We're also heading back to the United States for EvolveDrupal NYC on September 20. 

Want to stay in the loop? Sign up for EvolveDrupal updates. You'll be among the first to hear about ticket sales, early bird discounts, and competitions for free stuff!

Here's what to read next: 9 Ways to Make the Most of EvolveDrupal

+ more awesome articles by Evolving Web
Categories: FLOSS Project Planets

Tag1 Consulting: Migrating Your Data from Drupal 7 to Drupal 10: Assumptions of the API

Planet Drupal - Wed, 2024-05-08 12:49

As pointed out in the first article, the Migrate API scope is to move over content and configuration. Porting modules and themes are out of scope. With that in mind, let’s take a closer look at some of the assumptions and limitations. In addition to what will be presented in today’s article, I highly recommend reviewing the official documentation for upgrading from Drupal 7. Drupal is ever-evolving and the Migrate API documentation gets updated regularly. Of particular importance, review the page on known issues when upgrading from Drupal 7, as things get added and removed from that list as issues are discovered and fixed.

mauricio Wed, 05/08/2024 - 17:13
Categories: FLOSS Project Planets

Daniel Roy Greenfeld: TIL: Running UV outside a virtualenv

Planet Python - Wed, 2024-05-08 11:22

Breaking the rules to satisfy continuous integration.

A few months ago I blogged about forcing pip to require a virtualenv. However, when automating tests and deployments sometimes you work outside of virtualenvs. With pip this isn't a problem, you just don't set what I did in that article. However, what if you are using the rust-based uv where the default is to keep you in a virtualenv?

The answer is when you install dependencies using uv in this scenario, use the --python flag to specify the interpreter. According to the uv docs, this flag is intended for use in continuous integration (CI) environments or other automated workflows.

So without further ado, this is what I did:

python -m pip install uv uv pip install -p 3.12 -r requirements.txt

As a bonus, here's the command inside GitHub actions-flavored YAML:

- name: Install Dependencies run: | python -m pip install uv uv pip install -p 3.12 -r requirements.txt

Want to know how to handle multiple versions of Python? Here's how use a matrix on GitHub: https://github.com/pydanny/dj-notebook/blob/main/.github/workflows/python-ci.yml#L18-L19

Categories: FLOSS Project Planets

The Python Show: 40 - Open Source Development with Antonio Cuni

Planet Python - Wed, 2024-05-08 10:28

In this episode, we discuss working on several different open-source Python packages. Antonio Cuni is our guest, and he chats about his work on PyScript, pdb++, pypy, HPy, and SPy.

Listen in as we chat about Python, packages, open source, and so much more!

Show Links

Here are some of the projects we talked about in the show:

Categories: FLOSS Project Planets

Real Python: PyTorch vs TensorFlow for Your Python Deep Learning Project

Planet Python - Wed, 2024-05-08 10:00

PyTorch vs TensorFlow: What’s the difference? Both are open-source Python libraries that use graphs to perform numerical computations on data in deep learning applications. Both are used extensively in academic research and commercial code. Both are extended by a variety of APIs, cloud computing platforms, and model repositories.

If they’re so similar, then how do you decide which one is best for your project?

In this tutorial, you’ll learn:

  • What the differences are between PyTorch and TensorFlow
  • What tools and resources are available for each
  • How to choose the best option for your specific use case

You’ll start by taking a close look at both platforms, beginning with the slightly older TensorFlow. Then, you’ll explore PyTorch and some considerations to help you determine which choice is best for your project. Let’s get started!

Get Your Decision Guide: Click here to download the free decision guide that will help you choose between PyTorch and TensorFlow for your Python deep learning project.

What Is TensorFlow?

TensorFlow was developed by Google and released as open-source in 2015. It grew out of Google’s homegrown machine learning software, which was refactored and optimized for use in production.

The name “TensorFlow” describes how you organize and perform operations on data. The basic data structure for both TensorFlow and PyTorch is a tensor. When you use TensorFlow, you perform operations on the data in these tensors by building a stateful dataflow graph, kind of like a flowchart that remembers past events.

Who Uses TensorFlow?

TensorFlow has a reputation for being a production-grade deep learning library. It has a large and active user base and a proliferation of official and third-party tools and platforms for training, deploying, and serving models.

After PyTorch was released in 2016, TensorFlow declined in popularity. But in late 2019, Google released TensorFlow 2.0—a major update that simplified the library and made it more user-friendly, leading to renewed interest among the machine learning community.

Code Style and Function

In TensorFlow 2.0, you can use eager execution, which is how Python normally works. Eager execution evaluates operations immediately, so you can write your code using Python control flow rather than graph control flow. To see this in action, you’ll take a look at how you would multiply two tensors using both Tensorflow 1.0 and 2.0.

To start, here’s an example of how to multiply tensors using TensorFlow 2.0. With eager execution, all you need is tf.math.multiply():

Python >>> import tensorflow as tf >>> x = [[2., 4., 6.]] >>> y = [[1.], [3.], [5.]] >>> m = tf.math.multiply(x, y) >>> m <tf.Tensor: shape=(3, 3), dtype=float32, numpy= array([[ 2., 4., 6.], [ 6., 12., 18.], [10., 20., 30.]], dtype=float32)> Copied!

In this code, you declare your tensors using Python’s list notation, and tf.math.multiply() executes the element-wise multiplication immediately when you call it.

Before TensorFlow 2.0, you had to manually stitch together an abstract syntax tree by making tf.* API calls. You then had to pass a set of output tensors and input tensors to a session.run() call and manually compile the model.

A Session object is a class for running TensorFlow operations. It contains the environment in which Tensor objects are evaluated and Operation objects are executed, and it can own resources like tf.Variable objects. The most common way to use a Session is as a context manager.

To see how a Session is used in this way, here’s an example of how you multiply two tensors using the old TensorFlow 1.0 method:

Python >>> import tensorflow as tf >>> tf.compat.v1.disable_eager_execution() >>> x = tf.compat.v1.placeholder(tf.float32, name = "x") >>> y = tf.compat.v1.placeholder(tf.float32, name = "y") >>> multiply = tf.math.multiply(x, y) >>> with tf.compat.v1.Session() as session: ... m = session.run( ... multiply, feed_dict={x: [[2., 4., 6.]], y: [[1.], [3.], [5.]]} ... ) ... print(m) [[ 2. 4. 6.] [ 6. 12. 18.] [10. 20. 30.]] Copied!

This code uses TensorFlow 2.x’s tf.compat API to access TensorFlow 1.x methods and disable eager execution.

You first declare the input tensors x and y using tf.compat.v1.placeholder tensor objects. Then you define the operation to perform on them. Note that nothing has been calculated at this point.

Next, using the tf.Session object as a context manager, you create a container to encapsulate the runtime environment and do the multiplication by feeding real values into the placeholders with a feed_dict. Finally, still inside the session, you print() the result.

Note: Keep in mind that because TensorFlow 1.0 has been deprecated, it probably isn’t the best option for your future projects, and you should stick with using TensorFlow 2.0.

Read the full article at https://realpython.com/pytorch-vs-tensorflow/ »

[ Improve Your Python With 🐍 Python Tricks 💌 – Get a short & sweet Python Trick delivered to your inbox every couple of days. >> Click here to learn more and see examples ]

Categories: FLOSS Project Planets

Bastian Venthur: New python-debianbts in experimental

Planet Debian - Wed, 2024-05-08 09:00

Last month, I asked for help migrating python-debianbts to zeep, a SOAP library that would replace the now unmaintained pysimplesoap. The main blocker was the lack of a proper WSDL file provided by Debian’s BTS software, debbugs.

Peter De Wachter pointed out other issues with debbugs’ SOAP implementation and provided a patch that solves the whole issue by removing the dependency on an external SOAP library altogether by implementing the required bits of the SOAP protocol directly in python-debianbts. The new version is completely backwards compatible, and the test suites of python-debianbts and reportbug are still passing.

Apparently, while working on this patch, Peter also uncovered an issue with the type hints defined in Python’s xml.etree module, for which he also provided a patch. Really great work!

I’ve uploaded the new version to Debian/experimental for now to get some exposure and feedback, before uploading it to unstable.

Peter, thank you very much for your support, I really appreciate it!

Categories: FLOSS Project Planets

1xINTERNET blog: 1xINTERNET supports the new Drupal Starshot

Planet Drupal - Wed, 2024-05-08 08:00

Dries announced the Starshot initiative, a default CMS config for easy Drupal project creation, prioritizing no-code and low-code features. 1xINTERNET supports the strategy to promote Drupal through pre-configured application and will contribute to Starshot's success.

Categories: FLOSS Project Planets

Python Software Foundation: PSF Grants Program 2022 &amp; 2023 Transparency Report

Planet Python - Wed, 2024-05-08 06:28

The PSF’s Grants Program is a key plank in our charitable mission to promote, protect, and advance the Python programming language, and to support and facilitate the growth of a diverse and international community of Python programmers. After much research, input, and analysis, we are pleased to share a PSF Grants Program 2022 & 2023 Transparency Report. The report includes context, numbers, analysis, and a proposed path forward. It also includes a supplemental analysis of several specific grant applications for which we were requested to share more information.

We feel it is important to acknowledge that Pythonistas, regional communities, and the broader community are behind these statistics and commentary. Our community called for this report to be created. While the report is focused on data and outcomes, we also feel it is important to acknowledge in this introduction the concerns and frustrations that brought us here, explained further in the ‘Setting context’ section below. We hope that this report, along with many other steps, helps to remediate this.

This report reflects the outcome of thousands of hours of PSF and volunteer efforts over 2022 and 2023 by the Grants Working Group, the PSF Board, Python organizers, and PSF Staff worldwide. We truly value this opportunity to share information on the last two years of increasing grants to the community and to improve our Grants Program while honoring the hard work of everyone involved in making the Program and our mission possible.

This report was compiled by PSF Staff and reviewed by the PSF Board and Grants Working Group. If you have questions, comments, or feedback about the Grants Program or this report, please email grants@pyfound.org.
 

Setting context

In December of 2023, we received an open letter from a coalition of organizers from the pan-African Python community asking the PSF to address concerns and frustrations around our Grants Program. Before receiving the letter, the PSF Board was aware of the Grant application that spurred this letter and published a transparency blog post regarding the September and October 2023 Board votes concerning that application. PSF Staff were aware of a need for a refresh of Grants Program documentation and processes and worked on these updates time allowing. Since receiving the letter in December, the PSF Board and Staff have:

  • Spent time listening during many discussions with the letter writers and other community members.
  • Re-prioritized reviewing and rewriting Grant-related documentation and processes, including revisiting the Grants Working Group Charter.
  • Established monthly Grants Program Office Hours.
  • Contracted Carol Willing to perform a DjangoCon Africa Grants Process Retrospective which is now available on the PSF Blog.

For a high-level idea of the scope of our Grants Program, we are happy to share:

  • The PSF distributed $393K in Grants during 2022 and $623K during 2023 for the Grants Program and the PyCon US Travel Grants Program combined.
  • The Grants Program distributed $215K in Grants during 2022 and $393K during 2023. 
  • Noting this Transparency Report is focused on the Grants Program only. If you want to learn more about travel grants check out the Travel Grants Process for PyCon US 2024 blog post on the PyCon US blog.

The growth we saw from 2022 to 2023 is exciting to reflect on, and we’re looking forward to what 2024 and beyond has in store for our Grants Program!

  The numbers (in graph form)

 

Thanks to Tania Allard for helping improve the readability and accessibility of the graphs provided in this report.

Our analysis  General Trends, Observations, & Notes
  • In 2022, Grants requests were not at “full capacity” as our community was still recovering from the impact of COVID-19 on events, initiatives, and collective burnout.
  • The increase in total grant applications we received from 2023 over 2022 is encouraging. The program grew in 2023 as we began to return to in-person and hybrid events, and we anticipate more applications coming in throughout 2024 and beyond.

 Number of Total Grant Applications by Continent
  • In both 2022 & 2023, we received the most number of applications from Africa and Europe, with South America not far behind.
 Percentage of Grants Approved
  • The percentage of approved vs. declined applications is reasonable. Some reasons applications were denied include:
    • Unable to meet PSF Grants Program criteria
    • Unclear benefit to funding the application
    • Not Python related
    • Spam

 Percentage of Grant Applications by Continent
  • The percentages across continents are reasonably balanced, with fewer applications from Asia, North America, and Oceania. Based on the distribution of populations globally, the percentage of applications from Asia is lower than expected. After receiving input on this directly from PyCon organizers from Asia, we have come to understand that this is based on an approach focused on sustainability. PyCon organizers in Asia are focused on local sponsorship, fiscal responsibility, and independence. We absolutely commend this approach, and at the same time, we urge organizers from Asia to request Grant funding to supplement and enhance their events.
  • Additionally, note that we cannot award Grants to certain countries in Asia due to OFAC and our status as a US-based 501c3 non-profit.

 Approved & Declined Grant Applications by Continent
  • The number of declined applications from Africa shows an area for improvement. Our conclusion is that our documentation is not clear enough on the requirements for a grant to be awarded and that results in applications that will not pass.

 Dollar Amount Granted by Continent & Percentage of Money Granted by Continent
  • This graph appears to show that Europe received disproportionate funding. On further review, we believe this is because the grant applications we got from Europe were for conferences. In contrast, a large number of the grant applications from other regions were for meetups and workshops, including many Django Girls events. Conferences typically cost significantly more than meetups. Here’s a breakdown:
Continent Applications Received in 2022 Granted in 2022 Applications Received in 2023 Granted in 2023 Africa 4 conferences, 7 meetups 3 conferences, 7 meetups 7 Conferences, 16 meetups 5 conferences, 13 meetups Europe 12 conferences, 1 meetup 11 conferences, 1 meetup 15 conferences, 2 meetups 15 conferences, 2 meetups .table { display: block; overflow-y: hidden; overflow-x: auto; scroll-behavior: smooth; } .table thead { display: table-header-group; vertical-align: middle; border-color: inherit; color: white; background: darkcyan; } tr { display: table-row; vertical-align: inherit; border-color: inherit; } table th { padding: 16px; text-align: inherit; border-bottom: 1px solid black; color:white!important; } tbody { display: table-row-group; vertical-align: middle; border-color: inherit; } table:not(.tr-caption-container) { min-width: 100%; border-radius: 3px; }

  • We are encouraged to see the dollar amount granted to the Africa region rise significantly between 2022 and 2023.
 Average Amount Granted by Continent
  • Oceania is an outlier; the PSF received one application in 2022 and two in 2023 from Oceania. Many more grants were awarded to other regions, which caused their average dollar amount to be lower. With that in mind, we feel the average is reasonable. It means that we are receiving both large and small grant applications!
  • Africa and South America received less on average than other regions. This is another example of the typical types of grant requests we are receiving from different regions (workshops and meetups vs. large conferences).
 Grant Decision Times in Weeks by Number & Percentage of Applications
  • The majority of the average grant review period is 4 weeks, which we feel is reasonable based on the process and load of grant applications we receive.
  • When we reviewed applications that took longer than 4 weeks to decide, we found a couple of scenarios.
  • One of the main reasons for longer decision times is that applications are sometimes submitted without crucial information, and there is significant time spent on communications between applicants, PSF Staff, and the Grants Working Group. Once requested, there are often delays in receiving the required information back from applicants.
  • The grant application was escalated to the Board who meet on a monthly basis. Grants can be escalated to the Board either because the amount requested is greater than $10,000 or because the Grants Working Group cannot reach a consensus on a decision.
 Grant Program Average Days to Decide by Continent
  • This graph also shows Oceania as an outlier, and, again, it is skewed because we received only one application in 2022 and only two in 2023 applications from that region.
  • In 2023, applications from Asia took longer to reach decisions. When we looked into this further, we found that the reasons for delays were that applications were submitted without the required information and that significant time was spent on communications between applicants, PSF Staff, and the Grants Working Group.
  • We are pleased to see that the average number of days is very close across most regions. 
 
Supplemental information on specific grant requests

The open letter we received from the pan-African Python community asked us to specifically review the process and share information about several older grant applications from 2018, 2019, and 2022. We want to share as much information as possible while noting that some of these requests were managed by folks who have since moved on from the PSF and Grants Working Group (GWG).

Introducing Python and related technologies to more high schools in Uganda (2018)
  • Grant request submitted January 2nd, 2018
  • Requesting funding for four events in different schools for the 7-9 February, 12-14 February, 19-21 February, 26 Feb-1 March, of 2018.
  • GWG Chair forwarded request to the GWG January 4th
  • GWG reviewed and needed more information
  • GWG Chair requested more information and forwarded that to GWG on January 12th
  • GWG Chair acknowledged to the GWG on February 7th that the request was dropped
  • No further comments added or actions taken
 PyLadies Fest in Kampala, Uganda (2019)
  • Grant request submitted February 21st, 2019
  • Requesting funding for a five day event starting on May 6th, 2019
  • GWG Chair requested more information
  • GWG Chair forwarded request and additional information to the GWG on March 25th
  • GWG reviewed and needed more information
  • GWG Chair requested more information and forwarded a reply to GWG on April 26th saying the grant requestor was working on solidifying the necessary information
  • GWG Chair forwarded additional information to the GWG on July 10th and advised the GWG the event was rescheduled for September 16th
  • No further comments added or actions taken
 PyLadies Kampala Open Source Workshop (2022)
  • Grant request submitted September 20, 2022
  • Requesting funding for a one day event for November 26th, 2022.
  • GWG Chair requested more information, which was provided on September 26th
  • GWG Chair forwarded request to GWG on October 20th
  • GWG reviewed and no one objected
  • GWG Chair moved the request to a vote on October 31st
  • Board Member contacted PSF Staff for an update on November 2nd
  • GWG approved the request and the GWG Chair sent the Resolution to the grant requester on November 3rd
 Our comments

We do not have many insights into the administration of these Grant requests outside of what exists on the GWG mailing list, including any off list emails or in-person conversations that might have occurred. The PSF Staff administering the GWG for the grant requests from 2018 and 2019 are no longer on the team. The request from 2022, which was approved, was 2 days over our goal of 6 week turnaround time for decisions on grant applications.

While our staff roster is currently small, it was even smaller in 2018 and 2019. We realized some time ago that as our grant requests increased having a solo administrator for the GWG was tough- it was hard for our staff to catch a break! When we put out a call for a Community Communications Manager in June of 2023, we planned for whoever stepped into that role to be a second administrator for the GWG to always have a stopgap at the ready. Our current administration for the GWG now includes two PSF Staff members. This is done purposefully to avoid situations where applications get dropped because a critical piece of information comes just as someone is scheduled to be out of the office or an emergency happens.


A path forward

Some of our goals:

  • Review, rewrite, and improve the Grants Working Group Charter, including exploring various decision-making options and criteria.
  • Review, rewrite, and improve documentation so that:
  • Applicants can be confident that their application meets the Grants Program criteria before submitting.
  • Reduce the need for follow-ups for additional information that can cause delays.
  • Continue to host the PSF Grants Program Office Hours to increase ongoing transparency, support grant applicants, and understand the gaps in our documentation.
  • Analyze and deliberate on the equity of designating grant funding allocated by region.
  • Explore ways that the PSF could regularly support the organization of large-scale events in underserved regional communities.  
  • Examine and update our processes regarding timeframes, including escalating grant applications after 4 weeks of review to avoid 8-week review periods.
  • We’d like to receive more applications in the future by continuing to publicize the opportunity and providing support during our Office Hours.
  • Revisit the effectiveness and sustainability of the Grants Program yearly.
 A final note

We hope this transparency report will help our community understand the state of our Grants Program over the last two years. It has been instructive to the Board, the Grants Working Group, and our staff who administer the program to understand where our strengths and weaknesses lay. This report will inform our efforts as we progress with improvements to the Grants Program. We also feel this exercise will continue to be helpful year over year, to both monitor the health of and analyze how our improvement efforts have impacted the success of the Grants Program.

If you have any questions, comments, or feedback, please email grants@pyfound.org.

Categories: FLOSS Project Planets

The Drop Times: Which CMS Powers Your Country's Official Website? A Global CMS Usage Analysis

Planet Drupal - Wed, 2024-05-08 06:18
A growing trend is seen in governments favouring free and open-source solutions (FOSS) for their official websites. The potential benefits of FOSS include enhanced security, flexibility, and cost savings. But how widespread is this trend, and which specific systems are gaining traction? To understand the scope of this trend, we examined the official websites of 195 countries globally. This analysis digs deeper into the trend of governments favouring free and open-source solutions for their online presence, uncovering which CMS systems—including Drupal, WordPress, and others—are most preferred for official government communication.
Categories: FLOSS Project Planets

Debian Brasil: MiniDebConf BH 2024 - vídeos e fotos

Planet Debian - Wed, 2024-05-08 06:00

Os vídeos das palestras MiniDebConf BH 2024 estão disponíveis nos links abaixo:

As fotos do evento estão nos links abaixo:

E os arquivos usados nas apresentações estão aqui:

Em breve divulgaremos um relato sobre o evento, aguardem :-)

Categories: FLOSS Project Planets

The Drop Times: Drupal Iberia 2024 Unites Portuguese and Spanish Communities

Planet Drupal - Wed, 2024-05-08 02:29
Drupal beria 2024 brings together Spanish and Portuguese Drupal communities for the first time. Set in Évora on May 10th, this event, organized by Associação Drupal Portugal and Asociación Española de Drupal, aims to foster collaboration and unity. With a biennial format, it promises engaging sessions and keynotes, supporting both seasoned professionals and newcomers.
Categories: FLOSS Project Planets

Dries Buytaert: State of Drupal presentation (May 2024)

Planet Drupal - Tue, 2024-05-07 22:54

This week, approximately 1,400 Drupal enthusiasts came together for DrupalCon North America in Portland, Oregon. As a matter of tradition, I delivered my State of Drupal keynote, often referred to as "DriesNote". In case you missed it, you can watch the video or download my slides (385 MB).

This year's keynote was inspired by President John F. Kennedy's famous "Moonshot" speech. After being global leaders, the U.S. had fallen behind in the Space Race. Challenged by the Soviet cosmonaut program, President Kennedy rallied Americans around the ambitious goal of landing on the moon before the decade was out.

Drupal Starshot, a new version of Drupal

Drupal has always been known for its low-code capabilities. However, many competitors now offer similar features, and in some areas, they even surpass what Drupal provides. While Drupal is celebrated for its robustness, it can be challenging for newcomers, especially those with limited technical expertise. So in my keynote, I was excited to introduce Drupal Starshot, our "Moonshot" to make Drupal more accessible and easier to use.

Twenty-three years after Drupal's inception, we are preparing to launch a second official version of Drupal. For the time being, we're calling this second version "Drupal CMS". It will be built on top of Drupal Core and common contributed modules, and available as a separate download alongside Drupal Core. Wireframe of the Drupal.org download page featuring two options: Drupal CMS (Drupal Starshot) and Drupal Core, with Drupal CMS being promoted as the preferred starting point for most.

Drupal Starshot will be designed to have a great out-of-the-box experience. It will enable Ambitious Site Builders without Drupal experience to easily create a new Drupal site and extend it with pre-packaged recipes, all using their browser.

The vision for Drupal Starshot is the outcome of highly productive brainstorming sessions with Drupal Core Committers, the Drupal Association, colleagues at Acquia, various Drupal agencies, and others.

From an implementation standpoint, it will primarily rely on the Project Browser and Recipes initiatives, while also incorporating elements from the Experience Builder initiative. We actually started prototyping Drupal Starshot a few weeks ago and showcased our progress at DrupalCon. Our goal is to launch a first version of Drupal Starshot within 8 months.

At DrupalCon, hundreds of people pledged to get involved, and we had two "super BoFs" with over 50 people each. If you're interested in getting involved with the Drupal Starshot project, you can register your interest at https://drupal.org/starshot. Additionally, join the conversation in the #Starshot channel on Drupal Slack.

Drupal's brand refresh and marketing strategy

Alongside our technical efforts, we've launched a bold marketing strategy. At DrupalCon Lille, I discussed the need for a fresh marketing approach. Since then, we've made tremendous progress.

I introduced a Drupal brand refresh, which includes updated brand guidelines to ensure a consistent and modern visual identity. This refresh aims to invigorate our brand – making it more vibrant and appealing to newcomers, while still honoring our history and representing our diverse, global community.

I couldn't cover all the details around the brand refresh in my keynote, so I'm expanding on them in this blog post. For a detailed explanation of Drupal's refreshed brand, check out this video by Shawn Perritt: Drupal 2024 brand refresh explained.

Our efforts went beyond just a brand refresh. The Marketing Committee has also guided the community in developing a comprehensive marketing toolkit, which includes messaging guides, pitch decks, and more. All these resources will be available at https://www.drupal.org/marketing.

Let's reach for the stars

As we advance with Drupal Starshot, I recall President Kennedy's famous words:

We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win.

Embracing the Drupal Starshot initiative reflects a similar ethos; we're not choosing the easy path, but the one that tests our strength, creativity, and ability to do hard things. The success of Drupal Starshot will be a testament to the incredible collective power of the Drupal community. It's a challenge we are also unwilling to postpone, and intend to win.

Drupal Starshot is more than a technological leap; it represents a shift in how we think, innovate, and collaborate. It's about reaching for the stars and making the Open Web accessible to everyone.

Thank you for being part of this journey. I can't wait to see where it takes us together. The feedback from the last two days at DrupalCon has been overwhelmingly positive. I am more committed than ever and excited to pledge a significant amount of my time to this mission, and to the future of Drupal.

Categories: FLOSS Project Planets

KGraphViewer 2.5.0 released

Planet KDE - Tue, 2024-05-07 20:00

KGraphViewer 2.5.0 has been just released! The main focus of this release is the port to Qt6 and KDE Frameworks 6 as well as general code modernisation, but of course some bugs have been squashed too. The full changelog can be found below.

About KGraphViewer:

KGraphViewer is a Graphviz DOT graph file viewer, aimed to replace the other outdated Graphviz tools. Graphs are commonly used in scientific domains and particularly in computer science.

You can learn more at https://apps.kde.org/kgraphviewer/

URL: https://download.kde.org/stable/kgraphviewer/2.5.0/
SHA256: 872bee63fb4df6f7fb2b4eaf02ff825cba3ca953ac02509a287fe5cd0f1e2b69
Signed by: D81C 0CB3 8EB7 25EF 6691 C385 BB46 3350 D6EF 31EF Heiko Becker heiko.becker@kde.org
https://invent.kde.org/sysadmin/release-keyring/-/raw/master/keys/heikobecker@key1.asc

Full changelog:

  • appstream: Add upcoming 2.5.0 release
  • Brush up menu & action terms a bit
  • Add icons to more actions & submenus
  • Update homepage URL in README
  • Remove some outdated/unused files
  • Avoid double look-ups in maps, use iterator returned from find method
  • Add widget parent to QMenu instances
  • DotGraphView: create popup menu only on demand
  • Share also zoom actions between DotGraphView & KGraphViewerPart
  • Use enum QColor constructor instead of string based one
  • Use KStandardAction convenience creation methods, parent all to collecitions
  • Drop file_open_recent from ui.rc files, given KStandardAction toolbar magic
  • Use more member-function-pointer-based Qt signal/slot connects
  • Port away from auto-casting from ascii strings
  • Fix missing closing tags in D-Bus API xml files
  • Use QList directly instead of Qt6-times alias QVector
  • Make manual build & install fully optional
  • Update links to graphviz website
  • Fix handling file cmdl arguments with relative path
  • Fix bad defaults for fonts, also for colors, shapes & style
  • KGraphViewerPart CMake config file: drop KGraphViewerPart_INCLUDE_DIRS
  • Bump version & SO version for first Qt6-based release
  • Drop support for Qt5/KF5
  • Clean up includes & forward declares
  • Do not use Qt modules includes
  • Deploy custom pixmaps as Qt resource
  • Printing page settings: remove custom broken window icon
  • Printing page settings: replace "lock ratio" button with checkbox
  • KGraphViewer KPart metadata: use normal app display name as name
  • Drop libkgraphviewer appstream file, no other libraries provide some
  • Set target properties right after declaring the target
  • Remove unused version header includes
  • Drop code for no longer supported KF versions
  • Fix another wrong min Qt version variable name usage
  • Use ECMDeprecationSettings
  • Port away from deprecated QMouseEvent::globalPos()
  • KGraphEditor: fix bad port to QMessageBox::question
  • Use Q_EMIT instead of emit
  • Switch to ECM required-default KDE_COMPILERSETTINGS_LEVEL
  • Remove unneeded ; after Q_DECLARE_PRIVATE() & Q_DECLARE_PUBLIC()
  • Use more nullptr
  • Fix wrong min Qt version variable name usage
  • Add Qt6/KF6 build support
  • Remove unneeded QApp::setOrganizationDomain, dupl. KAboutData::setApp...Data
  • appdate: use desktop-application type, add developer & launchable tags
  • Update homepage to apps.kde.org
  • Port away from deprecated QDesktopWidget
  • Port away from deprecated QPrinter::setOrientation()
  • Port away from deprecated QPrinter::numCopies()
  • Port away from deprecated operator+(Qt::Modifier, Qt::Key)
  • Port away from deprecated QWheelEvent::delta()/orientation()
  • Port away from deprecated signal QButtonGroup::buttonClicked(int)
  • Port away from deprecated I18N_NOOP2
  • Port away from deprecated KXmlGui RESTORE() macro
  • Bump min required Qt/KF to 5.15.2/5.100.0
  • Port away from deprecated QLayout::setMargin()
  • Add missing includes for Qt6 build
  • Remove unused include
  • Drop usage of outdated no-effect QGraphicsView::DontClipPainter
  • Port away from deprecated QStyle::PM_DefaultLayoutSpacing
  • change QFontMetrics.width with horizontalAdvance
  • replace QRegExp by QRegularExpression
  • Use for instead of foreach
  • Replace deprecated endl with Qt variant
  • remove -qt5 suffix
  • change path in gitlab-ci
  • snapcraft: initial import snapcraft files.
  • kgrapheditor: deploy ui.rc file as Qt resource
  • Remove Designer's "." normaloff file data from icon properties in .ui files
  • Add explicit moc includes to sources for moc-covered headers
  • doc: use a non-deprecated entity for Frameworks
  • Add releases
  • Add Open Age Content Rating
  • Remove warning about unknown DOT fonts
  • Remove custom action to configure shortcuts
  • Init graph members
  • Remove unused graphviz/gvc.h includes
  • Add KI18n and KDocTools macro to install translations
  • Port away from deprecated KMessageBox Yes/No API
  • Remove arcconfig
  • Add interface library for part include dir
  • Handle Qt6 change around enterEvent
  • Add missing include
  • Remove unused include
  • Port away from deprecated KPluginLoader
  • Port away from deprecated endl
  • Adapt build system to Qt6
  • Remove pointless/broken icons
  • Enable highdpi pixmaps
  • Add git blame ignore file
  • Add GitLab CI
  • Use ecm_qt_install_logging_categories to generate kdebugsettings file
  • Drop code variants for no longer supported Qt/KF versions
  • Use more target-centric cmake code
  • Update .gitignore
  • Use non-deprecated KDEInstallDirs variables
  • Port away from deprecated KSelectAction::triggered(QString)
  • Documentation updates - Update date and fix version numbers - Fix tagging and sync option's text
  • Port away from deprecated QMatrix
  • KAboutData::setupCommandLine() already adds help & version options
  • kgraphviewer_part.desktop: remove unused key Categories
  • Use .in suffix for header file that is passed to configure_file()
  • Port away from deprecated signal QProcess::error
  • Use default window flags for QInputDialog::getText
  • Port away from deprecated KEditToolBar::newToolbarConfig
  • Port to new KPluginMetaData-based KParts API
  • Deploy ui.rc files as Qt resources
  • Remove broken argument SERVICE_TYPES kpart.desktop from desktop2json call
  • Handle Graphviz capitalization changes
  • Capitalize Graphviz consistently
  • cmake: Simplify and improve FindGraphviz.cmake
  • Add KDE ClangFormat on CMake and run the target
  • Fix link: ui.html -> menus.html
  • Draw empty arrowheads closed
  • add genericname for use on kde.org/applications
  • Set StartupWMClass in desktop file
  • Use more https in links (and update outdated ones)
Categories: FLOSS Project Planets

Pages