Planet KDE

Subscribe to Planet KDE feed Planet KDE
Planet KDE
Updated: 12 hours 18 min ago

20.04 releases dependency freeze this thursday

Mon, 2020-03-09 13:55

Next interesting dates:

March 12: 20.04 Dependency Freeze

March 19: 20.04 Freeze and Beta (20.03.80) tag & release

Categories: FLOSS Project Planets

GNU/Linux València ya es una asociación legal

Mon, 2020-03-09 13:12

Hoy me complace comentaros que finalmente los chicos y chicas de la capital del Turia han decidido dar el paso: GNU/Linux València ya es una asociación legal, y ello significa un compromiso que va mucho más allá de una moda pasajera. Así que, si os apasiona el Software Libre y estáis por la Comunidad Valenciana no dudéis en asociaros… Juntos somos legión.

GNU/Linux València ya es una asociación legal

Parece mentira como pasa el tiempo. Casi a la vez que se celebró Akademy-es 2018 de València conocí a un grupo de entusiastas valencianos que volvían a hacer florecer iniciativas libres en la capital del Turia.

Se hacían llamar GNU/Linux València, y con sus encuentros mensuales, empezaban a asomar sus proyectos de difusión del Software Libre en una ciudad que antaño era delantera.

Ahora, tras dos años de charlas, podcast, eventos, talleres y sus famosos «Almuerzos Libres» han decidido dar el paso y constituirse como Asociación.

En un extracto de su comunicado oficial podemos leer que:

«Hola, queridos amigos y amigas.

Desde la Asociación de usuarios GNU/Linux de Valencia, mas conocida por GNU/Linux valencia, queremos invitaros a formar parte de una familia cuyo propósitos son los de difundir y promover el Software Libre, tanto en su vertiente técnica, como en la ética.

Pero vamos más allá aún. Nuestra filosofía es la de hermanar a todas aquellas iniciativas que quieran promover una sociedad más justa y solidaria, desde cualquier ámbito. Muchas asociaciones que luchan por estos valores, representan diferentes movimientos sociales con muchos puntos en común entre si. Nuestra colaboración, es y será plena, con ellas. La lucha por una sociedad más justa, requiere de unión física e ideológica, y estamos seguros que unidos seremos mas fuertes.»

Su cuota de inscripción anual es de 20€ para personas físicas, y 40€ para empresas o personas jurídicas. Ambas cuotas tienen carácter anual y servirán para promocionar de forma más eficiente el Software Libre y mantener los gastos económicos que tiene constituirse como asociación (sí, aún siendo sin ánimo de lucro las asociaciones tienen gastos).

Para hacerte socio/a solo tienes que acceder a la pestaña ASOCIARSE, que puedes encontrar en el menú principal de su página web.

Más información: GNU/Linux València

Categories: FLOSS Project Planets

Interview with TrishLaWitch

Mon, 2020-03-09 05:30
Could you tell us something about yourself?

I am Patricia aka TrishLaWitch, I am a French woman who has never studied art. I had medico-social education … nothing to do with art but I always liked to draw, it is a way to travel in my imaginary world.

Do you paint professionally, as a hobby artist, or both?

I practice digital art as a hobby artist, but since digital art has become my daily life, I think to do something with. I take my time, step by step.

What genre(s) do you work in?

How to define my genre … hmm, well I like to make fantasy, sometimes dark art, I like sci-fi but today I work more with fractals, surreal, abstract. In fact what I mostly like is create some fractals, work on and transform them, I sometimes mix them with painting, I have great fun doing that.

Whose work inspires you most — who are your role models as an artist?

I admire so many known and less known artists in so many different styles but I will name 2 … The digital paintings of Alexander Fedosov are incredible and of course the great Hans Rudolf Giger.

How and when did you get to try digital painting for the first time?

The first time was in 2015. I was curious to try, first steps towards what would become a passion. I remember making some cards, printing and mailing them to a dear friend so far away.

What makes you choose digital over traditional painting?

Digital art is so much more practical and more economical. No need for pencils, paintbrushes, paint, paper or canvas, everything is there, in little space. No need to install, store, clean. Only my computer and my drawing tablet, I turn on or off when I want! Great! And if I make a mistake during my work, I erase it instantly! As I can very well make a final choice very quickly on several color tests, shapes among the multitude of layers, filters, etc … Imagine doing the same thing in traditional art!! No, impossible! But I really have admiration for traditional painters too. They are 2 different ways to make art!

How did you find out about Krita?

One day, the free software I used asked for money for some functions, due to the success of many downloads. It was a great disappointment. I had to find other free software on the Net. I found GIMP and Krita and after trying them, my choice was definitely Krita.

What was your first impression?

Very intuitive. I immediately felt comfortable with it. I was impressed by the multitude of possibilities. And all for free! I was very impatient and excited to discover everything step by step (like a child).

What do you love about Krita?

I like everything, whether for brushes, tools (settings, possible options) or filters, color adjustment, how you can also organize your work space, even the space for animation is there. And of course the useful G’MIC filters. Everything is there for my work.

What do you think needs improvement in Krita? Is there anything that really annoys you?

I don’t see anything that annoys me, I’m very satisfied.

What sets Krita apart from the other tools that you use?

I don’t use other tools except Krita, but sometimes I play with Mandelbulb3D and Incendia Next in which you obviously can not paint, very different. Whatever I do, I always need Krita for everything!

If you had to pick one favourite of all your work done in Krita so far, what would it be, and why?

There is more than one but I choose a simple painting “Call of the moon” because it was one of my first with Krita, very different from what I’m doing today but I remember having so much pleasure doing it.

What techniques and brushes did you use in it?

I used airbrush soft, blender smear, blender knife edge, texture crackles, stamp water, texture smoke, experimental webs, it was nice to discover the tools step by step.

Where can people see more of your work?

They can see some of my works on my website and on deviantart.

Anything else you’d like to share?

I would like to thank the whole Krita team. You do fabulous work, making true our dreams of creativity.

Categories: FLOSS Project Planets

Krita 4.2.9 beta released!

Mon, 2020-03-09 05:27

Much later than we wanted to, we’ve finally gotten the beta ready for Krita 4.2.9! One of the reasons it took so long is that an update to Python 3.8 broke scripting on Windows. When we finally had figured out that the reason wasn’t just that Python no longer looks for libraries in all the usual places, but also that the bindings to Qt, PyQt cannot be built in parallel, it was already February. And then, of course, Apple changed the way applications are notarized… And then we updated to a newer version of some of the libraries we build Krita on, and that broke all kinds of things. In short, we have had months of trying to get our builds working again!

On the other hand, we have also worked like crazy to make this the most stable release of Krita ever, with countless bugs fixed — and there are even some fun new features:

  • Dmitry improved the brush outline: it no longer flickers when you hover over the canvas:
    https://krita.org/wp-content/uploads/2020/02/2020-02-11_comparing-outline.mp4
  • He also added “Airbrush” and “Airbrush Rate” to the Color Smudge brush, and a new Ratio setting, also for the Color Smudge brush, which allows making the shape of the brush flatter using the different sensors. Ramón Miranda has even made a video demonstrating these features:
  • New contributor Saurabh Kumar added a “Split Layer into Selection Mask” feature:

As for the bugfixes…

  • Fix transparency checkers looked white on HDR display bug 406698
  • Several fixes to file dialogs for overwriting and jpg files bug 412651
  • Fix Grow Selection expanding in one direction bug 414647
  • Fix crash using onion skins on non-animated layers bug 414668
  • Increase the limit in Layer Offset to 100k bug 414625
  • Fix crash opening .kra with incorrect clone source (related to bug 414699</a)
  • Prevent crash on addition of color to deleted palette with colorpicker bug 413548
  • Make Add subbrush off on changing multibrush tool’s type from Copy Translate bug 415651
  • Improve rendering of predefined default Rect dab
  • Set the default location for restored files to QStandardPaths::PicturesLocation bug 415810
  • Don’t crash if remoteArguments is called when there isn’t a mainwindow bug 415794
  • On Android, default to TouchGesture for Kinetic Scrolling
  • Delay initialization of brush paintop widget state bug 415033
  • Reenable breeze: with the latest release, the bug with comboboxes has been fixed
  • Show the hand cursor if there is no colorize mask yet bug 415935
  • Fix logic for enabling/disabling options in stroke selection dialog bug 415896
  • ORA export, write entire layers instead of cropping them
  • Fix endless recursion in when assigning a profilebug 414818
  • Fix a crash when cancelling Transform Tool action bug 414672
  • Fix an obviously wrong assert in the gradients bug 414550
  • Fix 1px brush offset in line tool bug 407405
  • Fix Layer Filter Combobox with Breeze theme bug 406595
  • Fix comparison of double spin box
  • Fix PaletteDocker not showing palettes bug 414890
  • Fix undo of replacing vector selection bug 412808
  • Separate krita log dialog from system information
  • Resource bundle: turn assert into check bug 399008
  • Fix the python Canvas.setRotation method bug 416126
  • Store and restore the geometry of the svg editor window bug 416097
  • Fix number of asserts with continued transform bug 415625
  • Fix Touch Docker save button not working on new files bug 407905
  • Fix blur Filter inconsistencies bug 416241
  • Fix border artifacts in layer styles bug 414582
  • Use Qt::Popup for color selectors popup widgets bug 410959
  • Always show color popup below the cursor bug 394139
  • Remove the strength compatibility with older paintop presets bug 416335
  • Fixed unneeded error message in Render Animation. bug 412599
  • Fix canvas offset calculation bug 416352
  • Layers with alpha channel disabled correctly export as “svg:src-atop” for ORA
  • Add icon to Close button of “About Krita” dialog box
  • Fix memory leak in preset history docker
  • Warn that Krita needs to be restarted after enabling/disabling plugins bug 416575
  • Workaround Qt 5.14’s colormanagement preventing png files from being saved bug 416515
  • Fixes with last used filter command. bug 416706
  • Fix Increase/Decrease Brush Size and Switch To Previous Preset buttons
  • Fix Warp and Cage transform in master bug 416505
  • Fix crazy snapping when resizing shapes bug 414336
  • Fix hiccups when doing canvas actions bug 414576, 415773
  • Fix animation rendering problem on small images (< 100px in size) bug 415367
  • Fix display of vector shapes when transformed with transform tool bug 417016
  • Fix hangup when loading image with generator/file layers bug 415891
  • Fix slowdown associated with the quick hide function of Shift+click on layer visibility icons
  • Fix canvas border color issue
  • Fix issue when saving preferences
  • Hide SubWindow decoration on macOS
  • A number of fixes with L*A*B* and CMYK thanks to L.E Segovia’s Season of KDE work
  • Android: Make it possible to select opengles
  • Set setRedirectPolicy as per discussion on KDE mailing lists
  • Fix crash when loading asl with tdta OSType
  • Make “Save Incremental Version” update recently used files
  • Correct logic for determining whether there are multiple backups requested bug 417914
  • Fix incorrect common curve in very old presets bug 417748
  • Fix layout issue in the history docker
  • Fix strobbing of the brush outline because of subpixel precision bug 374551
  • Make local selection outline visible on layer converted to selection mask
  • Fix freeze on vector layers bug 412746
  • Fix artifacts on filter masks applied to adjustment layers bug 417673
  • Fix ratio option on lower precision brushes
  • Fix opening Appimages bug 418230
  • Set image as modified after a legacy action (fix Channels docker not updating in some cases) bug 417992

Now it’s up to you all to beta-test this release and help us make sure we’ve caught all regressions (that is, new bugs for things that used to work) and all release blockers. We are currently investigating how we can make testing more robust, so this beta has no survey, please report all bugs you find to bugs.kde.org under the product Krita. Note that the Krita Lime PPA currently only has the beta and not the current stable.

Download Windows

For the beta, you should only only use the portable zip files. Just open the zip file in Explorer and drag the folder somewhere convenient, then double-click on the krita icon in the folder. This will not impact an installed version of Krita, though it will share your settings and custom resources with your regular installed version of Krita. For reporting crashes, also get the debug symbols folder.

Linux

(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

OSX

Note: the gmic-qt is not available on OSX.

Source code md5sum

For all downloads:

Key

The Linux appimage and the source .tar.gz and .tar.xz tarballs are signed. You can retrieve the public key over https here: 0x58b9596c722ea3bd.asc. The signatures are here (filenames ending in .sig).

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos! With your support, we can keep the core team working on Krita full-time.

Categories: FLOSS Project Planets

foss-north 2020 Training Day

Mon, 2020-03-09 03:48

Let’s talk about the foss-north 2020 training day! Every year we invite interesting speakers for the conference. Some of them are also teachers, and some of them are willing to hold a heavily discounted open enrollment training the day after the conference.

This year we offer three trainings:

You can get a training as an add-on to your ticket. You can even upgrade your ticket and add a training afterwards. Check it out here: https://foss-north.se/2020/tickets.html.

This gives you four days of contents: Community – 2x Conference – Training. And you get to visit Gothenburg!

Categories: FLOSS Project Planets

Need a fast way to tag faces in many images? Try Imaginario!

Mon, 2020-03-09 03:13

Today I've released Imaginario 0.9. The big feature coming with this new release is a face tagging flow which I believe will be the fastest and simplest you've ever used, despite it being all manual. I even sat down and spent some quality time with Blender to prepare a video to show it off:

While some people might actually think that I spent more time for making the video than for implementing the face tagging feature itself, this couldn't be farther from the truth: the face tagging branch has been being worked on for at least three months (of course, that's my spare time — so it's actually less than one hour per day) and consisted of more than 40 commits (after squashing all the fixups), whereas for the video I spent no more than a couple of hours.

I would appreciate if the curious could go and try it out, and let me know about any issues you should find: there are built packages for Linux (AppImage), macOS and Windows. I do also have an Ubuntu PPA where nightly images are built, but I'm not sure if I can recommend that one, since I've not been using it myself and have no idea whether those packages actually even start. But you are welcome to try :-)

Your feedback will help me do better, so please don't be shy!

Categories: FLOSS Project Planets

Plasma Mobile Sprint 2020 in Berlin

Sun, 2020-03-08 20:00

Like last year the Plasma Mobile team met in KDAB’s office in Berlin from 3rd to 9th February for the second Plasma Mobile sprint.

Our work spans many areas:

Shell and Design

Marco Martin has been re-working the shell user interface. Check out his blog for more details.

Plasma Mobile on PinePhone

Thanks to Mathis Brüchert many Plasma Mobile apps have new icons. Mathis also worked on updating the Plasma Mobile website. The ‘Find your way’ page’s appearance is now consistent with the rest of the website.

Jonah worked on a mobile-friendly open/save file dialog. Linus added quick access to known places like in Dolphin to this new file dialog.

Linus also worked on adding a screenshot action to the top drawer.

Marco Martin fixed an issue in kdeclarative that was causing the wifi settings to show an empty message box.

KWin/Wayland

Aleix Pol implemented the zwp_input_method_context_v1 protocol in KWin/Wayland, allowing us to make use of the maliit keyboard, ibus and other input methods in Plasma. Aleix also implemented EGL_KHR_partial_update which will yield better performance on ARM GPUs that support tiled rendering. Tobias Fella fixed the virtual keyboard staying open when the screen is locked.

Applications

Jonah implemented audio visualization in Voicememo, Plasma Mobile’s audio recorder application. He also reviewed a patch by Rinigus Saar that rewrites the tab switcher of Angelfish, Plasma Mobile’s browser application. Tobias started work on a RSS feed reader. Our camera application now has a clear indication when the properties are checkable. Nicolas worked on cleaning up the dialer’s codebase.

cahfofpai maintains a list of mobile GNU/Linux applications. During the sprint this list was improved. The list now includes new applications like KTrip, Kamoso, voicememo, Ruqola, Kongress, Keysmith and Colour Palette, and some duplicate applications were removed. Workflow for editing the list was improved

cahfofpai and Jonah tested various mobile-friendly GNOME applications on KDE Neon image and found out which things need improvement. cahfofpai also figured out a bug in Kaidan’s flatpak recipe which prevented Kaidan from detecting the camera. Bhushan Shah along with cahfofpai reviewed the list of currently pre-installed applications in Plasma Mobile.

Jonah and cahfofpai tested Flatpak support on PinePhone KDE Neon image and found out that there are no arm64 flatpak builds created by binary factory.

Kirigami

Camilo and Marco worked on expanding some Kirigami features inspired by Maui apps. This includes pull back headers and footers, which is a common pattern on Android that help focussing the app’s main content on small screens. They also fixed some issues in Kirigami’s ActionToolBar which is used in Maui’s SelectionBar.

Maui apps now allow lasso selection when a mouse or keyboard is present, improving the support for desktop systems while keeping them touch-friendly.

Android

There’s an ongoing effort to make our mobile apps available on Android to grow the target audience and allow people to work on/test our apps without a Linux phone. Thanks to Nicolas you now can get Kaidan, qrca, Keysmith, and Kongress for Android from KDE’s binary factory and F-Droid repository. He also fixed an issue with KNotifications on Android that affected Kaidan. Volker Krause, Nicolas and Aleix discussed upgrading our Android builds to Qt 5.14, which promises various improvements. cahfofpai investigated why KDE Itinerary fails to import files with special characters in the name

Collaboration

This year we were joined by two UBports developers, Marius Gripsgard and Dalton Durst. The main goal was to foster collaboration between the KDE and UBports communities. We discussed sharing software components for common needs. This includes solutions for content sharing, telephony, permission management, push notifications and configuration management.

We also discussed how to get KDE applications work in the Ubuntu Touch and vice versa. Jonah worked on Ubuntu Touch flatpak runtime to enable running Ubuntu Touch application in various mobile distributions. Nicolas nagged Dalton and Marius into upgrading the Qt version shipped with Ubuntu Touch, which will allow KDE apps to work there. We also got a proof-of-concept click package for KTrip.

On Saturday, we joined the UBports Q&A, bi-weekly show hosted by UBports team, where we discussed work done at sprint,

Community

On 7th evening we went to dinner with local KDE community in Berlin.

Conclusion

We would like to thank KDE e.V. for supporting the event, KDAB for hosting us this week. We also like to thank Marius and Dalton from UBports for joining us. If you are interested in supporting our work, you can help us with various tasks or you can donate to KDE.

Categories: FLOSS Project Planets

Plasma Mobile Sprint 2020 in Berlin

Sun, 2020-03-08 20:00

Like last year the Plasma Mobile team met in KDAB’s office in Berlin from 3rd to 9th February for the second Plasma Mobile sprint.

Our work spans many areas:

Shell and Design

Marco Martin has been re-working the shell user interface. Check out his blog for more details.

Plasma Mobile on PinePhone

Thanks to Mathis Brüchert many Plasma Mobile apps have new icons. Mathis also worked on updating the Plasma Mobile website. The ‘Find your way’ page’s appearance is now consistent with the rest of the website.

Jonah worked on a mobile-friendly open/save file dialog. Linus added quick access to known places like in Dolphin to this new file dialog.

Linus also worked on adding a screenshot action to the top drawer.

Marco Martin fixed an issue in kdeclarative that was causing the wifi settings to show an empty message box.

KWin/Wayland

Aleix Pol implemented the zwp_input_method_context_v1 protocol in KWin/Wayland, allowing us to make use of the maliit keyboard, ibus and other input methods in Plasma. Aleix also implemented EGL_KHR_partial_update which will yield better performance on ARM GPUs that support tiled rendering. Tobias Fella fixed the virtual keyboard staying open when the screen is locked.

Applications

Jonah implemented audio visualization in Voicememo, Plasma Mobile’s audio recorder application. He also reviewed a patch by Rinigus Saar that rewrites the tab switcher of Angelfish, Plasma Mobile’s browser application. Tobias started work on a RSS feed reader. Our camera application now has a clear indication when the properties are checkable. Nicolas worked on cleaning up the dialer’s codebase.

cahfofpai maintains a list of mobile GNU/Linux applications. During the sprint this list was improved. The list now includes new applications like KTrip, Kamoso, voicememo, Ruqola, Kongress, Keysmith and Colour Palette, and some duplicate applications were removed. Workflow for editing the list was improved

cahfofpai and Jonah tested various mobile-friendly GNOME applications on KDE Neon image and found out which things need improvement. cahfofpai also figured out a bug in Kaidan’s flatpak recipe which prevented Kaidan from detecting the camera. Bhushan Shah along with cahfofpai reviewed the list of currently pre-installed applications in Plasma Mobile.

Jonah and cahfofpai tested Flatpak support on PinePhone KDE Neon image and found out that there are no arm64 flatpak builds created by binary factory.

Kirigami

Camilo and Marco worked on expanding some Kirigami features inspired by Maui apps. This includes pull back headers and footers, which is a common pattern on Android that help focussing the app’s main content on small screens. They also fixed some issues in Kirigami’s ActionToolBar which is used in Maui’s SelectionBar.

Maui apps now allow lasso selection when a mouse or keyboard is present, improving the support for desktop systems while keeping them touch-friendly.

Android

There’s an ongoing effort to make our mobile apps available on Android to grow the target audience and allow people to work on/test our apps without a Linux phone. Thanks to Nicolas you now can get Kaidan, qrca, Keysmith, and Kongress for Android from KDE’s binary factory and F-Droid repository. He also fixed an issue with KNotifications on Android that affected Kaidan. Volker Krause, Nicolas and Aleix discussed upgrading our Android builds to Qt 5.14, which promises various improvements. cahfofpai investigated why KDE Itinerary fails to import files with special characters in the name

Collaboration

This year we were joined by two UBports developers, Marius Gripsgard and Dalton Durst. The main goal was to foster collaboration between the KDE and UBports communities. We discussed sharing software components for common needs. This includes solutions for content sharing, telephony, permission management, push notifications and configuration management.

We also discussed how to get KDE applications work in the Ubuntu Touch and vice versa. Jonah worked on Ubuntu Touch flatpak runtime to enable running Ubuntu Touch application in various mobile distributions. Nicolas nagged Dalton and Marius into upgrading the Qt version shipped with Ubuntu Touch, which will allow KDE apps to work there. We also got a proof-of-concept click package for KTrip.

On Saturday, we joined the UBports Q&A, bi-weekly show hosted by UBports team, where we discussed work done at sprint,

Community

On 7th evening we went to dinner with local KDE community in Berlin.

Conclusion

We would like to thank KDE e.V. for supporting the event, KDAB for hosting us this week. We also like to thank Marius and Dalton from UBports for joining us. If you are interested in supporting our work, you can help us with various tasks or you can donate to KDE.

Categories: FLOSS Project Planets

Latte Dock v0.10~ | Multiple Docks In Same Screen Edge

Sun, 2020-03-08 09:31

Latte Dock v0.10~ is the development version of Latte which is going to land next summer as v0.10... Until then of course you can still enjoy it by building it yourself from Phabricator KDE or by searching in your distro repos if it is already built daily.


In that version a new interesting feature has landed, as the title says you can now have Multiple Docks and Panels in each screen edge!
- youtube presentation -
- three panels in the same top screen edge -


History

Since Latte beginning there were two important design decisions;
  1. ONLY ONE dock or panel is shown in each screen edge
  2. Docks that "Follow On Primary" screen must always shown compared to docks that are only assigned at Explicit Screen"
These decisions were made at the time in order to make multi-screen experience smoother and its code parts more maintainable.


So, What Did Change?

Latte v0.9.x family introduced a much better Layouts and Multi-Screens architecture. New implementation is much better understandable and maintanable so there is no real reason to restrict the user to only one dock/panel for each screen edge anymore.


New Presentation Priorities

So now you can have as much docks and panels you want for each screen edge that respect the following rules:

In Single Layout mode:
  1. Docks that are set to "Follow On Primary" screen are always shown.
  2. Docks that are set at "Explicit" screen are shown only if their screen edge does not have any docks from [1]

In Multiple Layouts mode:
  1. Docks from "Shared" layouts that are set to "Follow On Primary" screen; are always shown.
  2. Docks from "Shared" layouts that are set at "Explicit" screen; are shown only if their screen edge does not have any docks from [1] 
  3. Docks from "Normal" layouts that are set to "Follow On Primary" screen; are shown only if their screen edge does not have any docks from [1] and [2] 
  4. Docks from "Normal" layouts that are set at "Explicit" screen; are shown only if their screen edge does not have any docks from [1], [2] and [3]


Donations:

You can find Latte at Liberapay if you want to support,    
or you can split your donation between my active projects in kde store.
Categories: FLOSS Project Planets

Women in the IT industry (interview from Akademy)

Sun, 2020-03-08 08:47

There's a clear gender gap in computer science, beginning with education: women in schools and colleges tend to approach computer studies less frequently than men. And we should also consider the usual obstacles for occupation every woman encounters in her work life in every field. So, it's not surprising that the majority of computer science workers are men.
And, at the same time, the Free Open Source Software world is made of many kinds of communities. Some are quite closed and unfriendly for new developers, expecially if they are women. Others, instead, commit to welcome everyone, without discrimination based on gender, nationality, or any other parameter.
At Akademy 2019 in Milan, as editor for GNU/Linux Magazine Italy, I've had the opportunity to discuss this issue with Lydia Pintscher, president of KDE e.V., and Lays Rodrigues, developer for KDE software.

Categories: FLOSS Project Planets

This week in KDE: endless bugfixing

Sun, 2020-03-08 00:42

One of the challenges of such a sprawling software catalog that allows such extensive customizability is, well, bugginess. More code and more options means more bugs. So the bugfixing is a never-ending challenge, and it’s what we focused on this week! Not only do we work on fixing bugs, but there’s also a lot of exciting work going on in the background to unify various codebases, use of more shared code, and adopt common frameworks, both for backends and user interfaces. It’s not very glamorous work, but you’ll see the impact in reduced bugginess going forward!

Bugfixes & Performance Improvements User Interface Improvements How You Can Help

In Plasma 5.19, we really want to make a push on our Breeze Theme Evolution work. It’s proceeding, but would go faster with your help! There are tons and tons of mockups in the linked task and its child tasks, and what we really need at this point is people willing to help implement them. QML skills are helpful, and C++ is also useful for the needed work on the Breeze theme itself. If this sounds interesting to you, don’t be shy, step right up!

More generally, have a look at https://community.kde.org/Get_Involved and find out more ways to help be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Finally, consider making a tax-deductible donation to the KDE e.V. foundation.

Categories: FLOSS Project Planets

Introducing the MetaInfo Creator

Sat, 2020-03-07 12:22

This year’s FOSDEM conference was a lot of fun – one of the things I always enjoy most about this particular conference (besides having some of the outstanding food you can get in Brussels and meeting with friends from the free software world) is the ability to meet a large range of new people who I wouldn’t usually have interacted with, or getting people from different communities together who otherwise would not meet in person as each bigger project has their own conference (for example, the amount of VideoLAN people is much lower at GUADEC and Akademy compared to FOSDEM). It’s also really neat to have GNOME and KDE developers within reach at the same place, as I care about both desktops a lot.

An unexpected issue

This blog post however is not about that. It’s about what I learned when talking to people there about AppStream, and the outcome of that. Especially when talking to application authors but also to people who deal with larger software repositories, it became apparent that many app authors don’t really want to deal with the extra effort of writing metadata at all. This was a bit of a surprise to me, as I thought that there would be a strong interest for application authors to make their apps look as good as possible in software catalogs.

A bit less surprising was the fact that people apparently don’t enjoy reading a large specification, reading a long-ish intro guide with lots of dos and don’ts or basically reading any longer text at all before being able to create an AppStream MetaInfo/AppData file describing their software.

Another common problem seems to be that people don’t immediately know what a “reverse-DNS ID” is, the format AppStream uses for uniquely identifying each software component. So naturally, people either have to read about it again (bah, reading! ) or make something up, which occasionally is wrong and not the actual component-ID their software component should have.

The MetaInfo Creator

It was actually suggested to me twice that what people really would like to have is a simple tool to put together a MetaInfo file for their software. Basically a simple form with a few questions which produces the final file. I always considered this a “nice to have, but not essential” feature, but now I was convinced that this actually has a priority attached to it.

So, instead of jumping into my favourite editor and writing a bunch of C code to create this “make MetaInfo file” form as part of appstreamcli, this time I decided to try what the cool kids are doing and make a web application that runs in your browser and creates all metadata there.

So, behold the MetaInfo Creator! If you click this link, you will end up at an Angular-based web application that will let you generate MetaInfo/AppData files for a few component-types simply by answering a set of questions.

The intent was to make this tool as easy to use as possible for someone who basically doesn’t know anything about AppStream at all. Therefore, the tool will:

  • Generate a rDNS component-ID suggestion automatically based on the software’s homepage and name
  • Fill out default values for anything it thinks it has enough data for
  • Show short hints for what values we expect for certain fields
  • Interactively validate the entered value, so people know immediately when they have entered something invalid
  • Produce a .desktop file as well for GUI applications, if people select the option for it
  • Show additional hints about how to do more with the metadata
  • Create some Meson snippets as pointers how people can integrate the MetaInfo files into projects using the Meson build system

For the Meson feature, the tool simply can not generate a “use this and be done” script, as each Meson snippet needs to be adjusted for the individual project. So this option is disabled by default, but when enabled, a few simple Meson snippets will be produced which can be easily adjusted to the project they should be part of.

The tool currently does not generate any release information for a MetaInfo file at all, This may be added in future. The initial goal was to have people create any MetaInfo file in the first place, having projects also ship release details would be the icing on the cake.

I hope people find this project useful and use it to create better MetaInfo files, so distribution repositories and Flatpak repos look better in software centers. Also, since MetaInfo files can be used to create an “inventory” of software and to install missing stuff as-needed, having more of them will help to build smarter software managers, create smaller OS base installations and introspect what software bundles are made of easily.

I welcome contributions to the MetaInfo Creator! You can find its source code on GitHub. This is my first web application ever, the first time I wrote TypeScript and the first time I used Angular, so I’d bet a veteran developer more familiar with these tools will cringe at what I produced. So, scratch that itch and submit a PR! Also, if you want to create a form for a new component type, please submit a patch as well.

C developer’s experience notes for Angular, TypeScript, NodeJS

This section is just to ramble a bit about random things I found interesting as a developer who mostly works with C/C++ and Python and stepped into the web-application developer’s world for the first time.

For a project like this, I would usually have gone with my default way of developing something for the web: Creating a Flask-based application in Python. I really love Python and Flask, but of course using them would have meant that all processing would have had to be done on the server. One the one hand I could have used libappstream that way to create the XML, format it and validate it, but on the other hand I would have had to host the Python app on my own server, find a place at Purism/Debian/GNOME/KDE or get it housed at Freedesktop somehow (which would have taken a while to arrange) – and I really wanted to have a permanent location for this application immediately. Additionally, I didn’t want people to send the details of new unpublished software to my server.

TypeScript

I must say that I really like TypeScript as a language compared to JavaScript. It is not really revolutionary (I looked into Dart and other ways to compile $stuff to JavaScript first), but it removes just enough JavaScript weirdness to be pleasant to use. At the same time, since TS is a superset of JS, JavaScript code is valid TypeScript code, so you can integrate with existing JS code easily. Picking TS up took me much less than an hour, and most of its features you learn organically when working on a project. The optional type-safety is a blessing and actually helped me a few times to find an issue. It being so close to JS is both a strength and weakness: On the one hand you have all the JS oddities in the language (implicit type conversion is really weird sometimes) and have to basically refrain from using them or count on the linter to spot them, but on the other hand you can immediately use the massive amount of JavaScript code available on the web.

Angular

The Angular web framework took a few hours to pick up – there are a lot of concepts to understand. But ultimately, it’s manageable and pretty nice to use. When working at the system level, a lot of complexity is in understanding how the CPU is processing data, managing memory and using the low-level APIs the operating system provides. With the web application stuff, a lot of the complexity for me was in learning about all the moving parts the system is comprised of, what their names are, what they are, and what works with which. And that is not a flat learning curve at all. As C developer, you need to know how the computer works to be efficient, as web developer you need to know a bunch of different tools really well to be productive.

One thing I am still a bit puzzled about is the amount of duplicated HTML templates my project has. I haven’t found a way to reuse template blocks in multiple components with Angular, like I would with Jinja2. The documentation suggests this feature does not exist, but maybe I simply can’t find it or there is a completely different way to achieve the same result.

NPM Ecosystem

The MetaInfo Creator application ultimately doesn’t do much. But according to GitHub, it has 985 (!!!) dependencies in NPM/NodeJS. And that is the bare minimum! I only added one dependency myself to it. I feel really uneasy about this, as I prefer the Python approach of having a rich standard library instead of billions of small modules scattered across the web. If there is a bug in one of the standard library functions, I can submit a patch to Python where some core developer is there to review it. In NodeJS, I imagine fixing some module is much harder.

That being said though, using npm is actually pretty nice – there is a module available for most things, and adding a new dependency is easy. NPM will also manage all the details of your dependency chain, GitHub will warn about security issues in modules you depend on, etc. So, from a usability perspective, there isn’t much to complain about (unlike with Python, where creating or using a module ends up as a “fight the system” event way too often and the question “which random file do I need to create now to achieve what I want?” always exists. Fortunately, Poetry made this a bit more pleasant for me recently).

So, tl;dr for this section: The web application development excursion was actually a lot of fun, and I may make more of those in future, now that I learned more about how to write web applications. Ultimately though, I enjoy the lower-level software development and backend development a bit more.

Summary

Check out the MetaInfo Creator and its source code, if you want to create MetaInfo files for a GUI application, console application, addon or service component quickly.

Categories: FLOSS Project Planets

Kdenlive 19.12.3 is out

Fri, 2020-03-06 10:00

The last minor release of the 19.12 series is out with bug fixes and usability improvements. Next month we mark the one year anniversary of the refactored code base so stay tuned for many nifty features coming like pitch shifting, tagging and rating of clips in the project bin and the much anticipated preview scaling of monitors bringing a huge performance boost.

Commits:

  • Fix clip monitor ruler not always adjusting to correct length. Commit.
  • Fix paste speed clip broken on comma locale. Commit. See bug #418121
  • Fix 1 frame offset in fade out. Commit. See bug #416811
  • Fix markers drawn outside clip. Commit.
  • Fix crash on insert track. Related to #573. Commit.
  • Fix changing of title clip duration broken. Commit. Fixes bug #417505
  • Fix org.kde.kdenlive.appdata.xml. Commit.
  • Filter effects in current category only. Commit.
  • Fix recent change breaking effects with jobs (like motion tracker). Commit.
  • Update appdata for 19.12.3. Commit.
  • Fix audio mixer balance cannot be changed after project opening. Commit.
  • Fix clip fades cannot be inserted after undoing. Commit.
  • Fix cannot update render filename. Commit.
  • Fix pasted clips with negative speed have wrong in/out. Commit. See bug #417143
  • Fix dropping effect on monitor. Commit.
  • Spelling fixes (by Patrick Matthäi). Commit.
  • Fix rotoscoping broken in some circumstances on cut clips. Commit.
  • Some updates for AppImage rubberband (not automatically included, needs some manual patching). Commit.
  • Add vamp-sdk to AppImage scripts. Commit.
  • Add rubberband to AppImage scripts. Commit.
  • Fix monitor fullscreen in some cases and don’t lose focus (broke shortcuts). Commit.
  • Update org.kde.kdenlive.appdata.xml. Commit.
Categories: FLOSS Project Planets

Performance when using QPainter with QSceneGraph

Fri, 2020-03-06 08:54

When using a profiler to look into your programs, sometimes it feels like looking behind the stage of magician and suddenly grasping the trick behind the magic… Quite recently, I had an application in front of me, which demanded surprisingly much CPU time. In a nutshell, this application has some heavy computational operations in its core and (primarily) produces a rectangular 2D output image, which is rendered by QPainter to display the results. This output is updated once every few milliseconds and is embedded inside a QtQuick window. The handover of the rendered QImage is done by a harmless looking Q_PROPERTY.

So, I wondered: How big can the impact of handing over a QImage to the QSG renderer be? In particular — as we all know — copying a big chunk of memory is a CPU expensive operation which should be avoided if possible. For getting proper profiling results, I created a simple test application. This application just creates a QtQuick scene with a QQuickPaintedItem derived render object, which updates its output every millisecond (thus renders whenever the render-loop iterates). I use a big output rectangle of 640×640, because I want to focus on the memory copying effect, which is more obvious with bigger outputs.

When using QQuickPaintedItem::Image as render target for the QQuickPaintedItem object, on my computer I can see a quite constant 30% CPU usage (one core) and the following flamegraph when looking into the process with Perf (sudo perf record --call-graph dwarf -p $(pidof qmlwithqpainter-experiment) -o perf-qimage.data) and visualizing the result with Hotspot:

However, when simply changing the render target to QQuickPaintedItem::FramebufferObject, the application’s CPU usage drops to about 11-12% (of one core) and I get the following result:

Actually, this change is to be expected! We get rid of a quite expensive copy operation that has to be done on every image update. Let’s look into the QQuickPaintedItem documentation for confirmation:

When the render target is a QImage, QPainter first renders into the image then the content is uploaded to the texture. When a QOpenGLFramebufferObject is used, QPainter paints directly onto the texture.

So, what is the story I want to tell? — When facing performance problems inside an application, one can only guess until looking at the problem with a decent profiler (and Perf + Hotspot is an excellent combination for that!). And even then, you have to think about what your application is doing when much of CPU time is lost and ponder whether there are better code paths for your specific situations. In my example, the output still looks the same after the change, but note that I lost all of the fancy anti-aliasing of QImage and now resizing the output became a much more expensive operation.

Hence, for my scenario this change made sense, because the CPU usage drops from 30% to 11% and I do not need to support resizing operations. For other scenarios, this might be different.

Categories: FLOSS Project Planets

foss-north 2020 Community Day

Fri, 2020-03-06 08:47

Let me tell you about the foss-north 2020 community day. It has been an idea for many years, but it all started last year. The idea is that we welcome open source projects to a day of hacking, workshoping, teaching and fun the day before the conference.

This year we are visited by Ansible, Debian, FreeBSD, Gnome, KDE and RISC-V. We a functional programming group meeting and a badge hacking workshop.

The community day is free of charge. It works thanks to the volunteers from the projects, and all the companies helping us with venues.

You are of course very welcome to join the conference days too. For them you will need a ticket. You can learn more here: https://foss-north.se/2020.

Categories: FLOSS Project Planets

Qt Creator 4.12 Beta released

Fri, 2020-03-06 07:50

We are happy to announce the release of Qt Creator 4.12 Beta!

Categories: FLOSS Project Planets

GCompris is back on Patreon

Thu, 2020-03-05 11:44

In case you missed the news: last month I decided to make the full version of GCompris gratis for all platforms! I hope that this move will make it easier for all the children in the world to get access to the best educational software.

Now in order to support my work on GCompris development, I will rely only on Patreon.

Each month I will publish a News post there to keep patrons informed of the work done. All the patrons will have their name on the donation page of GCompris website, except those who select the “Hidden Cats” tier.

If you like my work and want to support Free Software in education, please consider becoming a patron of GCompris.

Categories: FLOSS Project Planets

Nitrux Weekly Summary — 11th-15th November 2019

Thu, 2020-03-05 00:37

Hi, and welcome to this week’s weekly summary. This week’s recap is the seventh overall and the second for November 2019.

Infrastructure MauiKit Development
  • Debugging of VVave builds for Windows.
ZNX
  • The AppImage file has the correct product name for both the master and the development branch.
Distribution
  • Updated znx AppImage and kernel in the Development ISO branch.
  • Use mkiso from the master branch of mkiso to build ISO.
Other
  • Flashing our ISO files to a USB does not result in a boot error anymore in older EFI computers.
Categories: FLOSS Project Planets

OpenUK Kids Competition with Imogen Heap’s MiniMu

Wed, 2020-03-04 17:52

The OpenUK Kids Competition is now open for registrations. Teams of 4 aged 11 and 14 can take part to design the most interesting use for the MiniMu musical glove from Imogen Heap.

It’s free to enter and one winning team from each Region will be brought by OpenUK to London on 10 and 11 June. They will compete in the Competition Final at Red Hat’s Innovation Lab in Monument, London on 11 June having had the opportunity to spend the night before in London.

Categories: FLOSS Project Planets

Getting rid of “volatile” in (some of) Qt

Wed, 2020-03-04 08:00

The upcoming version of the C++ Standard (C++2a) is proposing to deprecate certain usages of the volatile keyword, by adopting the P1152 proposal (Deprecating volatile).

Despite the somewhat “flamboyant” title, the actual deprecated parts are very limited and indeed the paper limits the deprecation to somehow language/library corner cases and/or dangerous antipatterns.

For instance certain read-modify-write operations on a variable declared volatile are now deprecated, like:

volatile int i = 42; ++i; // deprecated i *= 2; // also deprecated

In any case, I took the occasion for digging a bit into Qt’s own usages of volatile. I didn’t do a thorough search through the entirety of Qt because I’ve also tried to fix the mis-usages…

In this blog post I am going to share some of my discoveries.

volatile foo used in place of std::atomic<foo>

As usual, the problem here is that volatile in C++ has nothing to do with synchronization/atomicity. (Ok, that’s not entirely true on all systems, but it’s true enough.)

There are at least two big offenders I found this way.

1: QQmlIncubationController::incubateWhile(volatile bool *)

The incubateWhile call takes a pointer to volatile bool. The idea is that the pointed boolean gets periodically checked by the incubator controller; another thread can tell the controller to stop incubating by flipping that bool.

To be honest, I’m not 100% convinced by the soundness of this API. For instance, it could’ve accepted a function object to poll, moving the problem of the eventual synchronization from another thread to the user’s domain. When in doubt, making it someone else’s problem is usually a good choice.

But I don’t want to redesign the QML engine APIs here, so I’ve just attempted a fix by porting to std::atomic<bool> instead.

The fix will appear in Qt 5.15.

2: QObjectPrivate::threadData

QObjectPrivate::threadData is a raw pointer to QThreadData (i.e. QThreadData *), basically storing the thread affinity of a given QObject, by holding a pointer to that thread’s private data.

The problem is that that variable is read and written by multiple threads without synchronization. For instance it’s written from here:

void QObjectPrivate::setThreadData_helper(QThreadData *currentData, QThreadData *targetData) { ... // set new thread data targetData->ref(); threadData->deref(); threadData = targetData; // <-- the write ... }

and potentially read from here:

void QCoreApplication::postEvent(QObject *receiver, QEvent *event, int priority) { ... QThreadData * volatile * pdata = &receiver->d_func()->threadData; // <-- the read ... }

These calls can happen from different threads, without synchronization — postEvent is documented to be thread-safe. Therefore, we have a data race, and data races are undefined behavior.

This ended up being super-tricky to fix (and I’m still not sure of it).

Sure, the idea is to make QObjectPrivate::threadData an atomic pointer to QThreadData, but then how to fix all the usage points?

The big struggle is that QObject is merely reentrant, and not thread safe, so most cases don’t require any synchronization (and can be turned into relaxed loads) because you’re not supposed to be modifying that variable by multiple threads without synchronization. Big exception: the cases that involve code paths that are documented to be thread-safe, like the postEvent code path above, which thus require acquire loads.

The current fix draft is sitting here.

The most interesting part is probably the old loop in postEvent(), trying to lock receiver‘s thread event queue:

QThreadData * volatile * pdata = &receiver->d_func()->threadData; QThreadData *data = *pdata; if (!data) { // posting during destruction? just delete the event to prevent a leak delete event; return; } // lock the post event mutex data->postEventList.mutex.lock(); // if object has moved to another thread, follow it while (data != *pdata) { data->postEventList.mutex.unlock(); data = *pdata; if (!data) { // posting during destruction? just delete the event to prevent a leak delete event; return; } data->postEventList.mutex.lock(); }

This loop used volatile once more to “cheat” synchronization: the code needs to get the threadData of an object and lock its event queue. Before that’s done, however, the affinity of the object could’ve been changed, so we need to unlock and try again. The idea is sound, but volatile does not help at all here as far as C++ is concerned; it seems to work because the compiler actually reloads the value of receiver‘s threadData, since its access happens through a volatile pointer.

As a side note: the same loop was completely missing from other places, like QCoreApplication::removePostedEvents, that also need to lock an object’s event queue (oops!). So I fixed that too, as a drive-by change…

volatile as a way to tell the compiler to… stop thinking

The QLibraryInfo class stores, amongst other things, the path to Qt’s own installed “parts” (plugins, translations, etc.). This path is hardcoded at build time; it’s one of the reasons why a Qt installation cannot be easily relocated.

In QLibraryInfo there’s a mysterious “const char * volatile path” variable:

#ifndef QT_BUILD_QMAKE_BOOTSTRAP if (!fromConf) { const char * volatile path = 0; if (loc == PrefixPath) { path = getPrefix( #ifdef QT_BUILD_QMAKE group #endif ); } else if (unsigned(loc) <= sizeof(qt_configure_str_offsets)/sizeof(qt_configure_str_offsets[0])) { path = qt_configure_strs + qt_configure_str_offsets[loc - 1]; #ifndef Q_OS_WIN // On Windows we use the registry } else if (loc == SettingsPath) { path = QT_CONFIGURE_SETTINGS_PATH; #endif # ifdef QT_BUILD_QMAKE } else if (loc == HostPrefixPath) { static const QByteArray hostPrefixPath = getHostPrefixFromHostBinDir().toLatin1(); path = hostPrefixPath.constData(); # endif } if (path) ret = QString::fromLocal8Bit(path); } #endif

What’s it for? It turned out to be a complete hack.

In order to achieve relocation of Qt libraries (for instance, to allow the binary Qt installers to install Qt in any path specified by the user), Qt can be built with a dummy installation path. The installer will then binary patch Qt, replacing this dummy path with the actual installation path.

What’s the hack, then? The hack is to prevent the compiler to aggressively inline the call to QString::fromLocal8Bit below, which involves a call to strlen(path).

With path set to a compile-time string literal, strlen(path) would also be fully evaluated at compile time, and that would make the binary patch not work — it would end up with path and its length not matching, and making fromLocal8Bit return broken data or crash horribly. This has actually happened and has been reported as QTBUG-45307.

How to stop the compiler from calling strlen at compile-time? There you have it, don’t use a “const char *“, use a “const char * volatile” (a volatile pointer to const char). I have no idea why it actually works!

Didn’t fix it, but left a comment for the future reader.

volatile for setjmp/longjmp protection

Now we go into the legitimate use cases for volatile. C (and thus C++) define the setjmp and longjmp library functions. They do non-local jumps: longjmp jumps to a setjmp done somewhere before in the call stack.

In C they’re used as a poor man’s exception handling mechanism — return from a deep call stack up directly to a caller, unwinding the stack in the process. Since it’s C, every object is trivially destructible, so there’s nothing special to do to perform the unwinding. In C++ performing a longjmp that would destroy non-trivially destructible objects yields undefined behavior.

volatile has an interesting interaction with setjmp/longjmp: it’s used to give well-defined semantics when using function local variables across the jump.

For instance, a snippet like this:

volatile int i = 0; jmp_buf buf; if (!setjmp(buf)) { // first time, enter here i = 42; longjmp(buf, 1); } // then go here after the longjmp std::cout << i;

exhibits well-defined behavior (and prints 42) specifically because i is volatile. Without the volatile, i would have indeterminate value, and producing such an indeterminate value in this context is undefined behavior (I’m sensing a pattern here…). In other words: any local variable that is set after a setjmp and read after the longjmp must be declared volatile.

In layman’s terms: this volatile is telling the compiler something like “do not put i in a register and don’t optimize it out in any way; always keep it spilled on the stack, so it’s safe in case of a longjmp“.

Qt has a couple of places where there are setjmp/longjmp calls, namely its image handlers. PNG and JPEG use the respective C libraries (libpng and libjpeg), which seem to be designed with using setjmp/longjmp as a way to notify users of errors. That’s also where there are more usages of volatile.

PNG handler

In the case of the PNG image handler, a local variable was declared volatile, but that local was actually never accessed after the longjmp; so volatile wasn’t even needed in the first place. This has been fixed here.

JPEG handler

For the JPEG image handler, the situation was a bit more spicy. Sure thing, a local variable was again unnecessarily declared volatile (fix).

However the same code also was showing undefined behavior by not protecting some locals with volatile. For instance here, simplifying the code, we have this pattern:

JSAMPROW row_pointer[1]; row_pointer[0] = 0; ... if (!setjmp(jerr.setjmp_buffer)) { ... row_pointer[0] = new uchar[cinfo.image_width*cinfo.input_components]; ... } delete [] row_pointer[0];

The row_pointer local variable was not volatile; it was written after the setjmp (line 615) and then read again after the longjmp (line 716).

The fix in this case couldn’t be to simply mark it as volatile: the object in question is passed to libjpeg’s API, which simply want a pointer-to-object, and not a pointer-to-volatile-object (d’oh!). Marking an object with volatile, then const_cast‘ing volatileness away and accessing the object is an immediate undefined behavior, so don’t even think about doing it…

Also, libjpeg’s error handling requires the user to use setjmp/longjmp; therefore, the code had to keep the same structure (including the jumps). Basically, in libjpeg, one installs a custom error handling function; once libjpeg calls that handling function, it expects it not to return. So it must either exit the entire process, or longjmp out.

My fix was to make those variables non-local to the function calling setjmp, thus recovering well-defined behavior. You can read more about it in the fix’ commit message here.

longjmps, longjmps everywhere

Now the really interesting bit is that the very same code in the very same shape (and with the same very bug) is present everywhere.

For instance, it’s present in the equivalent GTK code in GDK that loads JPEG images here:

struct jpeg_decompress_struct cinfo; ... if (sigsetjmp (jerr.setjmp_buffer, 1)) { ... jpeg_destroy_decompress (&cinfo); ... } ... jpeg_create_decompress (&cinfo);

Or in ImageMagick, here:

struct jpeg_compress_struct jpeg_info; ... if (setjmp(error_manager.error_recovery) != 0) { jpeg_destroy_compress(&jpeg_info); } ... jpeg_create_compress(&jpeg_info);

It turns out that this kind of code comes all the way back from libjpeg version 6b’s own examples, dated 1998!

Those examples showcased the non-local return via setjmp/longjmp, and were affected by the same undefined behavior. You can still download them here (check out the sources for libjpeg 6b).

The historical libjpeg-turbo’s example also had the same problem. Comments are mine:

// 1. declare a non-volatile object struct jpeg_decompress_struct cinfo; if (setjmp(jerr.setjmp_buffer)) { // 3: and access it after the longjmp. jpeg_destroy_decompress(&cinfo); } // 2. access it after the setjmp jpeg_create_decompress(&cinfo);

I opened an issue asking for this to be fixed; the fix landed in this commit.

Conclusions

To conclude, let’s celebrate the longevity of this problem in all the codebases in the world. In perfect security-drama design: the most important part of an issue is its logo.

Therefore, here’s the official logo of the volatile handling in JPEG fiasco, of course made in 1998 style:

Thanks for reading!

About KDAB

If you like this blog and want to read similar articles, consider subscribing via our RSS feed.

Subscribe to KDAB TV for similar informative short video content.

KDAB provides market leading software consulting and development services and training in Qt, C++ and 3D/OpenGL. Contact us.

The post Getting rid of “volatile” in (some of) Qt appeared first on KDAB.

Categories: FLOSS Project Planets

Pages