KDE

Gcompris Multiple dataset Migration of an Activity This post is a step by step tutorial for adding multiple datasets to an activity in Gcompris. The procedure of adding multiple datasets to an activity is fairly simple in Gcompris. The steps for it ... [More] are given below. Note: In these steps we'll refer the activity in consideration as current_activity. Also we assume that we plan to add 3 datasets to current_activity. PROCEDURE Add the following line to current_activity/ActivityInfo.qml file levels: "1,2,3" The above line indicates that that the activity will contain 3 datasets and will automatically create the dataset selection menu for the activity with 3 options. example import GCompris 1.0ActivityInfo {name: "money/Money.qml"difficulty: 2icon: "money/money.svg"author: "Bruno Coudoin <[email protected]>"demo: false//: Activity titletitle: qsTr("Money")//: Help titledescription: qsTr("Practice money usage")// intro: "Click or tap on the money to pay."//: Help goalgoal: qsTr("You must buy the different items and give the exact price. At higher levels, several items are displayed, and you must first calculate the total price.")//: Help prerequisiteprerequisite: qsTr("Can count")//: Help manualmanual: qsTr("Click or tap on the coins or paper money at the bottom of the screen to pay. If you want to remove a coin or note, click or tap on it on the upper screen area.")credit: ""section: "math money measures"createdInVersion: 0levels: "1,2,3"} Create a resource directory inside the current_activity folder and inside it create separate folders for separate datasets with the name of the folder representing dataset number. The resultant directory structure would be as follows. +-- current_activity | ++-- resource | +++-- 1 | ++++-- Data.qml | +++-- 2 | ++++-- Data.qml | +++-- 3 | ++++-- Data.qml Create a Data.qml file inside each dataset folder in the following format objective - It will contain the text corresponding to this dataset that would be shown in the dataset selection menu. difficulty - contains the difficulty of the dataset. data - contains the actual data of the dataset The following example demonstrates the layout. import QtQuick 2.6import GCompris 1.0import "../../../../core"Dataset { objective: qsTr("Set and display time on analog clock for full half and quarters of an hour.") difficulty: 2 data: [ { "numberOfSubLevels": 5, "fixedMinutes": 0, "displayMinutesHand": false, "fixedSeconds": 0, "displaySecondsHand": false }, { "numberOfSubLevels": 5, "fixedMinutes": 15, "displayMinutesHand": true, "fixedSeconds": 0, "displaySecondsHand": false }, { "numberOfSubLevels": 5, "fixedMinutes": 30, "displayMinutesHand": true, "fixedSeconds": 0, "displaySecondsHand": false }, { "numberOfSubLevels": 5, "fixedMinutes": 45, "displayMinutesHand": true, "fixedSeconds": 0, "displaySecondsHand": false } ]} In the current_activity/CurrentActivity.qml file add the following line to get the currenlty selected dataset. property var levels: activity.datasetLoader.item.data example QtObject { id: items property Item main: activity.main property alias background: background property GCSfx audioEffects: activity.audioEffects property alias answerModel: answerArea.pocketModel property alias pocketModel: pocketArea.pocketModel property alias store: store property alias instructions: instructions property alias tux: tux property var levels: activity.datasetLoader.item.data property alias tuxMoney: tuxMoney property alias bar: bar property alias bonus: bonus property int itemIndex property int pocketRows property var selectedArea property alias pocket: pocketArea.answer property alias answer: answerArea.answer } This way the variable levels will contain the data section of the selected dataset. The dataset can be extracted from the levels variable inside the js file as follows. dataset = items.levels var data = dataset[currentLevel] [Less]

One of the main goals of this GSoC project is to have a fully working build of KDE ISO Image Writer on Windows to allow people that want to install KDE Neon to easily write the ISO image onto a USB flash drive. In order to compile the code on ... [More] Windows, I used Craft which is a cross-platform build system and package manager. With Craft, I could easily get the dependencies of KDE ISO Image Writer. I started by writing a Craft blueprint which is a Python file that describes an application (or library) and list its dependencies which allows Craft to fetch the necessary packages before compiling the application. My journey to get KDE ISO Image Writer running on Windows was not without its hurdles. I first had to figure out how to use Craft to compile an application from a Git repository but that was quickly solved after using Craft’s --help command. Then, I run into an issue with Qgpgme, which is used by KDE ISO Image Writer to verify the digital signature of an ISO image. I tried to compile using MSVC which failed systematically because of CMake complaining about not being able to finding Qgpgme. I learned from the KDE Windows team that Qgpgme can, at the moment, only be compiled using MinGW. I was finally able to compile KDE ISO Image Writer on Windows using Craft and MinGW. In parallel to working on a Windows build of KDE ISO Image Writer, I continued my work on the user interface by implementing the designs made by the KDE Community. You can see in the following screenshots the new user interface running on Windows: Writing an ISO image to a USB flash drive [Less]

For the last week I have been reading and understanding the code of kis_imagepipe_brush.cpp, and it has been an eye opening experience. Read More...

For the last week I have been reading and understanding the code of kis_imagepipe_brush.cpp, and it has been an eye opening experience. Read More...

For those that don't know me, I'm relatively new to KDE and spend most of my time doing VDG (Visual Design Group) stuff . The Plasma/Usability & Productivity sprint in Valencia which took place from June 19th to June 26th, was my first ever KDE sprint. Although we were all working together, I was formally...... Continue Reading →

Actually, a smart pointer is quite simple: It is an object that manages another object by a certain strategy and cleans up memory, when the managed object is not needed anymore. The most important types of smart pointers are: A unique pointer that ... [More] models access to an object that is exclusively maintained by someone. The object is destroyed and its memory is freed then the managing instance destroys the unique pointer. Typical examples are std::unique_ptr or QScopedPointer. A shared pointer is a reference counting pointer that models the shared ownership of an object, which is managed by several managing instances. If all managing instances release their partly ownership, the managed object is automatically destroyed. Typical examples are std::shared_ptr or QSharedPointer. A weak pointer is a pointer to an object that is managed by someone else. The important use case here is to be able to ask if the object is still alive and can be accessed. One example is std::weak_ptr that can point to a std::shared_ptr managed object and can be used to check if the object managed by the shared pointer still exists and it can be used to obtain a shared pointer to access the managed object. Another example is QPointer, which is a different kind of weak pointer and can be used to check if a QObject still exists before accessing it. For all these pointers one should always keep one rule in mind: NEVER EVER destroy the managed objects by hand, because the managed object must only be managed by the smart pointer object. Otherwise, how could the smart pointer still know if an object can still be accessed?! E.g. the following code would directly lead to a crash because of a double delete: { auto foo = std::make_unique(new Foo); delete foo.get(); } // crash because of double delete when foo gets out of scope This problem is obvious, now let’s look at the less obvious problems one might encounter when using smart pointers with Qt. QObject Hierarchies QObject objects and instances of QObject derived classes can have a parent object set, which ensures that child objects get destroyed whenever the parent is destroyed. E.g., think about a QWidget based dialog where all elements of the dialog have the QDialog as parent and get destroyed when the dialog is destroyed. However, when looking at smart pointers there are two problems that we must consider: 1. Smart Pointer Managed objects must not have a QObject parent It’s as simple as the paragraph’s headline: When setting a QObject parent to an object that is managed by a smart pointer, Qt’s cleanup mechanism destroys your precious object whenever the parent is destroyed. You might be lucky and destroy your smart pointer always before the QObject parent is destroyed (and nothing bad will happen), but future developers or user of your API might not do it. 2. Smart Pointers per default call delete and not deleteLater Calling delete on a QObject that actively participates in the event loop is dangerous and might lead to a crash. So, do not do it! – However, all smart pointers that I am aware of call “delete” to destroy the managed object. So, you actively have to take care of this problem by specifying a custom cleanup handler/deleter function. For QScopedPointer there already exists “QScopedPointerDeleteLater” as a predefined cleanup handler that you can specify. But you can do the same for std::unique_ptr, std::shared_ptr and QSharedPointer by just defining a custom deleter function and specifying it when creating the smart pointer. Wrestling for Object Ownership with the QQmlEngine Besides the QObject ownerships there is another, more subtle problem that one should be aware of when injecting objects into the QQmlEngine. When using QtQuick in an application, often there is the need to inject objects into the engine (I will not go into detail here, but for further reading see https://doc.qt.io/qt-5/qtqml-cppintegration-topic.html). The important important fact one should be aware of is that at this point there is a heuristic that decides whether the QML engine and its garbage collector assumes ownership of the injected objects or if the ownership is assumed to be on C++ side (thus managed by you and your smart pointers). The general rule for the heuristic is named in the QObjectOwnership enum. Here, make sure that you note the difference between QObjects returned via a Q_PROPERTY property and via a call of a Q_INVOKABLE methods. Moreover, note that the description there misses the special case of when an Object has a QObject parent, then also the CppOwnership is assumed. For a detailed discussion of the issues there (which might show you a surprisingly hard to understand stack trace coming from the depths of the QML engine), I suggest reading this blog post. Summing up the QML part: When you are using a smart pointer, you will hopefully not set any QObject parent (which automatically would have told the QML engine not to take ownership…). Thus, when making the object available in the QML engine, you must be very much aware about the way you are using to put the object into the engine and if needed, you must call the QQmlEngine::setObjectOwnership() static method to mark your objects specifically that they are handled by you (otherwise, bad things will happen). Conclusion Despite of the issues above, I very much favor the use of smart pointers. Actually, I am constantly switching to smart pointers for all projects I am managing or contributing. However, one must be a little bit careful and conscious about the side effects when using them in Qt-based projects. Even if they bring you a much simpler memory management, they do not relieve you from the need to understand how memory is managed in your application. PS: I plan to continue with a post about how one could avoid those issues with the QML integration on an architectural level, soon; but so much for now, the post is already too long [Less]

Actually, a smart pointer is quite simple: It is an object that manages another object by a certain strategy and cleans up memory, when the managed object is not needed anymore. The most important types of smart pointers are: A unique pointer that ... [More] models access to an object that is exclusively maintained by someone. The object is destroyed and its memory is freed then the managing instance destroys the unique pointer. Typical examples are std::unique_ptr or QScopedPointer. A shared pointer is a reference counting pointer that models the shared ownership of an object, which is managed by several managing instances. If all managing instances release their partly ownership, the managed object is automatically destroyed. Typical examples are std::shared_ptr or QSharedPointer. A weak pointer is a pointer to an object that is managed by someone else. The important use case here is to be able to ask if the object is still alive and can be accessed. One example is std::weak_ptr that can point to a std::shared_ptr managed object and can be used to check if the object managed by the shared pointer still exists and it can be used to obtain a shared pointer to access the managed object. Another example is QPointer, which is a different kind of weak pointer and can be used to check if a QObject still exists before accessing it. For all these pointers one should always keep one rule in mind: NEVER EVER destroy the managed objects by hand, because the managed object must only be managed by the smart pointer object. Otherwise, how could the smart pointer still know if an object can still be accessed?! E.g. the following code would directly lead to a crash because of a double delete: { auto foo = std::make_unique(); delete foo.get(); } // crash because of double delete when foo gets out of scope This problem is obvious, now let’s look at the less obvious problems one might encounter when using smart pointers with Qt. QObject Hierarchies QObject objects and instances of QObject derived classes can have a parent object set, which ensures that child objects get destroyed whenever the parent is destroyed. E.g., think about a QWidget based dialog where all elements of the dialog have the QDialog as parent and get destroyed when the dialog is destroyed. However, when looking at smart pointers there are two problems that we must consider: 1. Smart Pointer Managed objects must not have a QObject parent It’s as simple as the paragraph’s headline: When setting a QObject parent to an object that is managed by a smart pointer, Qt’s cleanup mechanism destroys your precious object whenever the parent is destroyed. You might be lucky and destroy your smart pointer always before the QObject parent is destroyed (and nothing bad will happen), but future developers or user of your API might not do it. 2. Smart Pointers per default call delete and not deleteLater Calling delete on a QObject that actively participates in the event loop is dangerous and might lead to a crash. So, do not do it! – However, all smart pointers that I am aware of call “delete” to destroy the managed object. So, you actively have to take care of this problem by specifying a custom cleanup handler/deleter function. For QScopedPointer there already exists “QScopedPointerDeleteLater” as a predefined cleanup handler that you can specify. But you can do the same for std::unique_ptr, std::shared_ptr and QSharedPointer by just defining a custom deleter function and specifying it when creating the smart pointer. Wrestling for Object Ownership with the QQmlEngine Besides the QObject ownerships there is another, more subtle problem that one should be aware of when injecting objects into the QQmlEngine. When using QtQuick in an application, often there is the need to inject objects into the engine (I will not go into detail here, but for further reading see https://doc.qt.io/qt-5/qtqml-cppintegration-topic.html). The important important fact one should be aware of is that at this point there is a heuristic that decides whether the QML engine and its garbage collector assumes ownership of the injected objects or if the ownership is assumed to be on C++ side (thus managed by you and your smart pointers). The general rule for the heuristic is named in the QObjectOwnership enum. Here, make sure that you note the difference between QObjects returned via a Q_PROPERTY property and via a call of a Q_INVOKABLE methods. Moreover, note that the description there misses the special case of when an Object has a QObject parent, then also the CppOwnership is assumed. For a detailed discussion of the issues there (which might show you a surprisingly hard to understand stack trace coming from the depths of the QML engine), I suggest reading this blog post. Summing up the QML part: When you are using a smart pointer, you will hopefully not set any QObject parent (which automatically would have told the QML engine not to take ownership…). Thus, when making the object available in the QML engine, you must be very much aware about the way you are using to put the object into the engine and if needed, you must call the QQmlEngine::setObjectOwnership() static method to mark your objects specifically that they are handled by you (otherwise, bad things will happen). Conclusion Despite of the issues above, I very much favor the use of smart pointers. Actually, I am constantly switching to smart pointers for all projects I am managing or contributing. However, one must be a little bit careful and conscious about the side effects when using them in Qt-based projects. Even if they bring you a much simpler memory management, they do not relieve you from the need to understand how memory is managed in your application. PS: I plan to continue with a post about how one could avoid those issues with the QML integration on an architectural level, soon; but so much for now, the post is already too long [Less]

Following Dan it’s my turn this time to provide you with an overview on what has happened around Kontact in the past two months. With more than 850 commits by 22 people in the KDE PIM repositories this can barely scratch the surface though. KMail ... [More] Around email a particular focus area has been security and privacy: Sandro worked on further hardening KMail against so-called “decryption oracle” attacks (bug 404698). That’s an attack where intercepted encrypted message parts are carefully embedded into another email to trick the intended receiver in accidentally decrypting them while replying to the attacker’s email. Jonathan Marten added more fine-grained control over proxy settings for IMAP connections. André improved the key selection and key approval workflow for OpenGPG and S/MIME. Laurent also continued the work on a number of new productivity features in the email composer: Unicode color emoji support in the email composer. Color emoji selector. Integration with grammar checkers such as LanguageTool and Grammalecte in the email editor. Grammalecte reporting a grammar error. Markdown support in the email composer, allowing to edit HTML email content in markdown syntax. Markdown editing with preview. This isn’t all of course, there’s plenty of fixes and improvements all around KMail: Albert fixed fixed an infinite loop when the message list threading cache is corrupted. David fixed a Kontact crash on logout (bug 404881). Laurent fixed access to more than the first message when previewing MBox files (bug 406167). The itinerary extraction plugin benefited from a number of improvements in the extractor engine, see this post for details. And fixing papercuts and general polishing wasn’t forgotten either (most changes by Laurent): Fix cursor jumping into the Bcc field in new email (bug 407967). Fix opening the New Mail Notifier agent configuration. Fix settings window being too small (bug 407143). Fix account wizard not reacting to Alt-F4 (bug 388815). Fix popup position in message view with a zoom level other than 100%. Fix importing attached vCard files (bug 390900). Add keyboard shortcut for locking/unlocking the search mode. David fixed interaction issues with the status bar progress overlay. KOrganizer Around calendaring, most work has been related to the effort of making KCalCore part of KDE Frameworks 5, something that particularly benefits developers using KCalCore outside of KDE PIM. The changes to KCalCore also aimed at making it easier to use from QML, by turning more data types into implicitly shared value types with Q_GADGET annotations. This work should come to a conclusion soon, so we can continue the KF5 review process. Of course this isn’t all that happened around calendaring, there were a few noteworthy fixes for users too: Fixed an infinite loop in the task model in case of duplicate UIDs. Improved visibilities of timeline/Gantt views in KOrganizer with dark color schemes. Damien Caliste fixed encoding of 0 delay durations in the iCal format. KAddressBook Like calendaring, contact handling also saw a number of changes related to making KContacts part of KDE Frameworks 5. Reviewing the code using KContacts lead to a number of repeated patterns being upstreamed, and to streamlining the contact handling code to make it easier to maintain. As a side-effect, a number of issues around the KContacts/Grantlee integration were fixed, solving for example limitations regarding the localization of contact display and contact printing. There is one more step required to complete the KContacts preparation for KDE Frameworks 5, the move from legacy custom vCard entries to the IMPP element for messaging addresses. Akregator Akregator also received a few fixes: Heiko Becker fixed associating notifications with the application. Wolfgang Bauer fixed a crash with Qt 5.12 (bug 371511). Laurent fixed comment font size issues on high DPI screens (bug 398516), and display of feed comments in the feed properties dialog (bug 408126). Common Infrastructure The probably most important change in the past two months happened in Akonadi: Dan implemented an automatic recovery path for the dreaded “Multiple Merge Candidate” error (bug 338658). This is an error condition the Akonadi database state can end up in for still unknown reasons, and that so far blocked successful IMAP synchronization. Akonadi is now able to automatically recover from this state and with the next synchronization with the IMAP server put itself back into a consistent state. This isn’t all though: Another important fix was raising the size limit for remote identifiers to 1024 characters (bug 394839), also by Dan. David fixed a number of memory leaks. Filipe Azevedo fixed a few macOS specific deployment issues. Dan implemented improvements for using PostreSQL as a backend for Akonadi. The backend connectors also saw some work: For the Kolab resource a memory management issues got fixed, and it was ported away from KDELibs4Support legacy code. David Jarvie fixed a few configuration related issues in the KAlarm resource. Laurent fixed configuration issues in the MBox resources. The pimdataexporter utility that allows to import/export the entire set of KDE PIM settings and associated data has received a large number of changes too, with Laurent fixing various import/export issues and improving the consistency and wording in the UI. Help us make Kontact even better! Take a look at some of the junior jobs that we have! They are simple, mostly programming tasks that don’t require any deep knowledge or understanding of Kontact, so anyone can work on them. Feel free to pick any task from the list and reach out to us! We’ll be happy to guide you and answer all your questions. Read more here… [Less]

We’re up to week 77 in KDE’s Usability & Productivity initiative! This week’s report encompasses the latter half of the Usability & Productivity sprint. Quite a lot of great work got done, and two features I’m particularly excited about are ... [More] in progress with patches submitted and under review: image annotation support in Spectacle, and customizable sort ordering for wallpaper slideshows. These are not done yet, but should be soon! Meanwhile, check out what’s already landed: New Features When trying to access a network with a captive portal (e.g. an airport or hotel wifi network that requires you to log in or click a “yes I accept the terms of use bla bla bla” button), an icon in the system tray allows you to access it again in case you miss the page the first time around (Aleix Pol Gonzalez, KDE Plasma 5.17.0) Dolphin’s Information Panel can now optionally auto-play media files; the setting is in the Information Panel’s context menu (Méven Car, Dolphin 19.08.0) Bugfixes & Performance Improvements Flatpak and Snap apps with mismatching app IDs now show up properly in the task manager (Kai Uwe Broulik, KDE Plasma 5.16.2) Job status notifications once again appear for people using Latte Dock (Kai Uwe Broulik, KDE Plasma 5.16.2) Notification pop-ups no longer sometimes become collapsed or fly in from the wrong location when there’s an unpleasant flood of notifications (Kai Uwe Broulik, KDE Plasma 5.16.2) Paused job notifications no longer show an inaccurate “time remaining” indicator (Kai Uwe Broulik, KDE Plasma 5.16.2) Fixed a crash on Wayland when using the default “Smart” window placement strategy (David Edmundson, KDE Plasma 5.16.2) The System Settings Look and Feel and Splash Screen pages now consume much less memory (Kai Uwe Broulik, KDE Plasma 5.16.2) Plasma no longer freezes at a black screen when logging out of a Wayland session (David Edmundson, KDE Plasma 5.16.3) Plasma’s KWin window manager no longer gobbles up all available memory when using a non-Breeze window decoration theme on Wayland (Vlad Zagorodniy, KDE Plasma 5.16.3) It’s now possible for the screen to automatically lock itself while a KWin effect is active (David Edmundson, KDE Plasma 5.17.0) Apps like Kate and KDevelop that use the KTextEditor framework now continue to spell-check documents for which spell-checking is turned on after they have been reloaded after being changed on disk, and scroll down when dragging something to the bottom of the view at the same speed as they scroll up when dragging it to the top (Ahmad Samir and Axel Kittenberger, KDE Frameworks 5.60) When Spectacle is used to save an image with a space in its filename and then quit itself automatically, the link in the notification generated by this action now works (David Redondo, Spectacle 19.08.0) User Interface Improvements The Plasma notification history no longer includes apps that don’t properly configure their notifications, preventing notification spam (Kai Uwe Broulik, KDE Plasma 5.16.2) The Notifications history now displays the configure and clear buttons in the same order on top as they appear within individual notifications (Kai Uwe Broulik, KDE Plasma 5.16.2) Notifications that appear within one second of another notification that has identical content are now automatically suppressed, preventing notification spam from misbehaving software (Kai Uwe Broulik, KDE Plasma 5.16.3) The System Settings Colors page now displays color schemes’ titlebar colors too, so for example you can distinguish color schemes that vary only in their titlebar colors (Kai Uwe Broulik, KDE Plasma 5.17.0): Pages in Info Center now all have the same sized titles (Méven Car, KDE Plasma 5.17.0) The Plasma network manager widget no longer futilely tries to keep scanning for wifi networks even when wifi is disabled (Aleix Pol Gonzalez, KDE Plasma 5.17.0) The Audio Volume’s settings window now accurately describes what the feedback options do (me: Nate Graham, KDE Plasma 5.17.0): The System Settings User Manager page no longer encourages you to enter an incorrect short name (Filip Fila, KDE Plasma 5.17.0) The Places Panel in Dolphin, file dialogs, and other apps no longer shows a “Root” item by default. Don’t worry, you can still get to / with one click using the Places panel, just click on its corresponding Devices entry, which gets a special icon to make it easy to pick out. Relatedly, the Places Panel now always shows a root device when running from a live ISO image (Méven Car and Stefan Brüns, KDE Frameworks 5.60) The sharing feature’s job dialog is now even more polished, having a better default size and more consistent bottom buttons (Nicolas Fella and me: Nate Graham, KDE Frameworks 5.60) It’s now possible to disable Dolphin’s unreleased “open externally-opened folders in new tabs” feature (Alexander Saoutkin, Dolphin 19.08.0) Everything in Dolphin’s main window now has “What’s this?” text (Felix Ernst, Dolphin 19.08.0) Okular’s annotation configuration dialogs now look better (Simone Giarin, Okular 1.8.0): Pretty freakin’ sweet, huh?! It was a great development sprint and I’m really happy with how it went. I’ll be writing another more in-depth article about it, so stay tuned. Next week, your name could be in this list! Not sure how? Just ask! I’ve helped mentor a number of new contributors recently and I’d love to help you, too! You can also check out https://community.kde.org/Get_Involved, and find out how you can help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite! If you find KDE software useful, consider making a tax-deductible donation to the KDE e.V. foundation. [Less]

Previously: 1st GSoC post 2nd GSoC post With the first phase of Google Summer of Code over it's high time some substantial progress on achieving the main goal of the project was presented. Since the last post, there's two things that have been done. First, Plasma is now going to be following upstream advice on...... Continue Reading →