Skip to content

Monday, 24 June 2019

Fedora Logo Bubble

These days using Fedora Workstation there are multiple commands necessary to update the entire software on the system: not everything is installed as RPMs anymore – and some systems hardly use RPMs at all anyway.


In the past all updates of a Fedora system were easily applied with one single command:

$ yum update

Later on, yum was replaced by DNF, but the idea stayed the same:

$ dnf update

Simple, right? But not these days: Fedora recently added capabilities to install and manage code via other ways: Flatpak packages are not managed by DNF. Also, many firmware updates are managed via the dedicated management tool fwupd. And lost but not least, Fedora Silverblue does not support DNF at all.

GUI solution Gnome Software – one tool to rule them all…

To properly update your Fedora system you have to check multiple sources. But before we dive into detailed CLI commands there is a simple way to do that all in one go: The Gnome Software tool does that for you. It checks all sources and just provides the available updates in its single GUI:

The above screenshot highlights that Gnome Software just shows available updates and can manage those. The user does not even know where those come from.

If we have a closer look at the configured repositories in Gnome Software we see that it covers main Fedora repositories, 3rd party repositories, flatpaks, firmware and so on:

Using the GUI alone is sufficient to take care of all update routines. However, if you want to know and understand what happens underneath it is good to know the separate CLI commands for all kinds of software resources. We will look at them in the rest of the post.

System packages

Each and every system is made up at least of a basic set of software. The Kernel, a system for managing services like systemd, core libraries like libc and so on. With Fedora used as a Workstation system there are two ways to manage system packages, because there are two totally different spins of Fedora: the normal one, traditionally based on DNF and thus comprised out of RPM packages, and the new Fedora Silverblue, based on immutable ostree system images.

Traditional: DNF

Updating a RPM based system via DNF is easy:

$ dnf upgrade
[sudo] password for liquidat: 
Last metadata expiration check: 0:39:20 ago on Tue 18 Jun 2019 01:03:12 PM CEST.
Dependencies resolved.
 Package                      Arch       Version             Repository    Size
 kernel                       x86_64     5.1.9-300.fc30      updates       14 k
 kernel-core                  x86_64     5.1.9-300.fc30      updates       26 M
 kernel-modules               x86_64     5.1.9-300.fc30      updates       28 M
 kernel-modules-extra         x86_64     5.1.9-300.fc30      updates      2.1 M

This is the traditional way to keep a Fedora system up2date. It is used for years and well known to everyone.

And in the end it is analogue to the way Linux distributions are kept up2date for ages now, only the command differs from system to system (apt-get, etc.)

Silverblue: OSTree

With the recent rise of container technologies the idea of immutable systems became prominent again. With Fedora Silverblue there is an implementation of that approach as a Fedora Workstation spin.

[Unlike] other operating systems, Silverblue is immutable. This means that every installation is identical to every other installation of the same version. The operating system that is on disk is exactly the same from one machine to the next, and it never changes as it is used.

Silverblue’s immutable design is intended to make it more stable, less prone to bugs, and easier to test and develop. Finally, Silverblue’s immutable design also makes it an excellent platform for containerized apps as well as container-based software development development. In each case, apps and containers are kept separate from the host system, improving stability and reliability.

Since we are dealing with immutable images here, another tool to manage them is needed: OSTree. Basically OSTree is a set of libraries and tools which helps to manage images and snapshots. The idea is to provide a basic system image to all, and all additional software on top in sandboxed formats like Flatpak.

Unfortunately, not all tools can be packages as flatpak: especially command line tools are currently hardly usable at all as flatpak. Thus there is a way to install and manage RPMs on top of the OSTree image, but still baked right into it: rpm-ostreee. In fact, on Fedora Silverblue, all images and RPMs baked into it are managed by it.

Thus updating the system and all related RPMs needs the command rpm-ostreee update:

$ rpm-ostree update
⠂ Receiving objects: 98% (4653/4732) 4,3 MB/s 129,7 MB 
Receiving objects: 98% (4653/4732) 4,3 MB/s 129,7 MB... done
Checking out tree 209dfbe... done
Enabled rpm-md repositories: fedora-cisco-openh264 rpmfusion-free-updates rpmfusion-nonfree fedora rpmfusion-free updates rpmfusion-nonfree-updates
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2019-03-21T15:16:16Z
rpm-md repo 'rpmfusion-free-updates' (cached); generated: 2019-06-13T10:31:33Z
rpm-md repo 'rpmfusion-nonfree' (cached); generated: 2019-04-16T21:53:39Z
rpm-md repo 'fedora' (cached); generated: 2019-04-25T23:49:41Z
rpm-md repo 'rpmfusion-free' (cached); generated: 2019-04-16T20:46:20Z
rpm-md repo 'updates' (cached); generated: 2019-06-17T18:09:33Z
rpm-md repo 'rpmfusion-nonfree-updates' (cached); generated: 2019-06-13T11:00:42Z
Importing rpm-md... done
Resolving dependencies... done
Checking out packages... done
Running pre scripts... done
Running post scripts... done
Running posttrans scripts... done
Writing rpmdb... done
Writing OSTree commit... done
Staging deployment... done
Freed: 50,2 MB (pkgcache branches: 0)
  gcr 3.28.1-3.fc30 -> 3.28.1-4.fc30
  gcr-base 3.28.1-3.fc30 -> 3.28.1-4.fc30
  glib-networking 2.60.2-1.fc30 -> 2.60.3-1.fc30
  glib2 2.60.3-1.fc30 -> 2.60.4-1.fc30
  kernel 5.1.8-300.fc30 -> 5.1.9-300.fc30
  kernel-core 5.1.8-300.fc30 -> 5.1.9-300.fc30
  kernel-devel 5.1.8-300.fc30 -> 5.1.9-300.fc30
  kernel-headers 5.1.8-300.fc30 -> 5.1.9-300.fc30
  kernel-modules 5.1.8-300.fc30 -> 5.1.9-300.fc30
  kernel-modules-extra 5.1.8-300.fc30 -> 5.1.9-300.fc30
  plymouth 0.9.4-5.fc30 -> 0.9.4-6.fc30
  plymouth-core-libs 0.9.4-5.fc30 -> 0.9.4-6.fc30
  plymouth-graphics-libs 0.9.4-5.fc30 -> 0.9.4-6.fc30
  plymouth-plugin-label 0.9.4-5.fc30 -> 0.9.4-6.fc30
  plymouth-plugin-two-step 0.9.4-5.fc30 -> 0.9.4-6.fc30
  plymouth-scripts 0.9.4-5.fc30 -> 0.9.4-6.fc30
  plymouth-system-theme 0.9.4-5.fc30 -> 0.9.4-6.fc30
  plymouth-theme-spinner 0.9.4-5.fc30 -> 0.9.4-6.fc30
Run "systemctl reboot" to start a reboot

Desktop applications: Flatpak

Installing software – especially desktop related software – on Linux is a major pain for distributors, users and developers alike. One attempt to solve this is the flatpak format, see also Flatpak – a solution to the Linux desktop packaging problem.

Basically Flatpak is a distribution independent packaging format targeted at desktop applications. It does come along with sandboxing capabilities and the packages usually have hardly any dependencies at all besides a common set provided to all of them.

Flatpak also provide its own repository format thus Flatpak packages can come with their own repository to be released and updated independently of a distribution release cycle.

In fact, this is what happens with the large Flatpak community repository all packages installed from there can be updated via flathub repos fully independent from Fedora – which also means independent from Fedora security teams, btw….

So Flatpak makes developing and distributing desktop programs much easier – and provides a tool for that. Meet flatpak!

$ flatpak update
Looking for updates…

        ID                                            Arch              Branch            Remote            Download
 1. [✓] org.freedesktop.Platform.Locale               x86_64            1.6               flathub            1.0 kB / 177.1 MB
 2. [✓] org.freedesktop.Platform.Locale               x86_64            18.08             flathub            1.0 kB / 315.9 MB
 3. [✓] org.libreoffice.LibreOffice.Locale            x86_64            stable            flathub            1.0 MB / 65.7 MB
 4. [✓] org.freedesktop.Sdk.Locale                    x86_64            1.6               flathub            1.0 kB / 177.1 MB
 5. [✓] org.freedesktop.Sdk.Locale                    x86_64            18.08             flathub            1.0 kB / 319.3 MB


And there is firmware: the binary blobs that keep some of our hardware running and which is often – unfortunately – closed source.

A lot of Kernel related firmware is managed as system packages and thus part of the system image or packaged via RPM. But device related firmware (laptops, docking stations, and so on) is often only provided in Windows executable formats and difficult to handle.

Luckily, recently the Linux Vendor Firmware Service (LVFS) gained quite some traction as the default way for many vendors to make their device firmware consumable to Linux users:

The Linux Vendor Firmware Service is a secure portal which allows hardware vendors to upload firmware updates.

This site is used by all major Linux distributions to provide metadata for clients such as fwupdmgr and GNOME Software.

End users can take advantage of this with a tool dedicated to identify devices and manage the necessary firmware blobs for them: meet fwupdmgr!

$ fwupdmgr update                                                                                                                                                         No upgrades for 20L8S2N809 System Firmware, current is 0.1.31: 0.1.25=older, 0.1.26=older, 0.1.27=older, 0.1.29=older, 0.1.30=older
No upgrades for UEFI Device Firmware, current is 184.65.3590: 184.55.3510=older, 184.60.3561=older, 184.65.3590=same
No upgrades for UEFI Device Firmware, current is 0.1.13: 0.1.13=same
No releases found for device: Not compatible with bootloader version: failed predicate [BOT01.0[0-3]_* regex BOT01.04_B0016]

In the above example there were no updates available – but multiple devices are supported and thus were checked.

Forgot something? Gnome extensions…

The above examples cover the major ways to managed various bits of code. But they do not cover all cases, so for the sake of completion I’d like to highlight a few more here.

For example, Gnome extensions can be installed as RPM, but can also be installed via In that case the installation is done via a browser plugin.

The same is true for browser plugins themselves: they can be installed independently and extend the usage of the web browser. Think of the Chrome Web Store here, or Firefox Add-ons.


Keeping a system up2date was easier in the past – with a single command. However, at the same time that meant that those systems were limited by what RPM could actually deliver.

With the additional ways to update systems there is an additional burden on the system administrator, but at the same time there is much more software and firmware available these ways – code which was not available in the old RPM times at all. And with Silverblue an entirely new paradigm of system management is there – again something which would not have been the case with RPM at all.

At the same time it needs to be kept in mind that these are pure desktop systems – and there Gnome Software helps by being the single pane of glas.

So I fully understand if some people are a bit grumpy about the new needs for multiple tools. But I think the advantages by far outweigh the disadvantages.

Sunday, 23 June 2019

Yesterday, got a new website.

Screenshot of the new konsole website

Doesn’t it look nice? As a reminder the old website looked like this.

Screenshot of the old konsole website

The design is very similar to the and websites.

The content could probably still need some improvements, so if you find typos or want to improve the wording of a sentence, please get in touch with KDE Promo. The good news is that you don’t need to be a programmer for this.

Community goal

With Jonathan Riddell, we proposed a new community goal: KDE is All About the Apps.

One part of this goal is to provide a better infrastructure and promotional material for the KDE applications (notice the lowercase a). I think websites are important to let people know about our amazing applications.

So if you are maintaining a KDE applications and want a new shinning website, please contact me. And I will try to setup for you a new websites, following the general design.

Technical details

The new website uses Jekyll to render static html. Because the layout and the design aren’t unique to, I created a special Jekyll located at, so that only the content and some configuration files are located in the websites/konsole-kde-org repository. This make it easier to maintain and will make it easier to change others website in the future without repeating ourself.

This was a bit harder to deploy than I first though, I had problem with installing my Jekyll theme in the docker image, but after the third or fourth try, it worked and then I had an encoding issue, that wasn’t present on my development machine.

Ci konsole website

How can I help?

Help is always welcome, the KDE community develops more than 200 different applications, and even though not all applications need or want a new modern website, there is tons of work to do.

If you are a web developer, you can help in the development of new website or in improving the Jekyll theme. Internalization, localization and accessibility still need to be implemented.

If you are not a web developer, but a web designer, I’m sure there is room for improvement in our theme. And it can be interesting to have small variations across the different websites.

And if you are neither a designer nor a developer, there is still tons of work with writing content and taking good looking screenshots. For the screenshots, you don’t even need to have a good English.

If you have question, you can as always contact me in Mastodon at or with matrix at

You can discuss this post in reddit or mastodon.

The Skrooge Team announces the release 2.20.0 version of its popular Personal Finances Manager based on KDE Frameworks


  • Correction bug 406903: no message when Skrooge can't open .skg file given on command line
  • Correction bug 406904: skrooge command-line help "--+[URL]" doesn't match its behavior
  • Correction bug 406741: QFX Date Import
  • Correction bug 407280: Skrooge flatpak unintentionally builds unused tests
  • Correction bug 407279: Skrooge flatpak needs later libofx
  • Correction bug 407257: Importing GNUcash (Account name instead of AccountID)
  • Correction bug 409026: skrooge appdata.xml fails validation on flathub, needs release and content_rating tags
  • Correction: aqbanking corrections:
    • Added auto repair for certain banks (Sprada, Netbank, Comdirect).
    • Added --disable-auto-repair command line option
    • Added --prefer-valutadate command line option
    • Removed --balance command line option
  • Correction: getNetWorth (used to compute PFS) is now computed by using all accounts
  • Correction: Remove color of hyperlinks in dashboard for a better rendering in dark theme
  • Correction: Remove broken quotes sources (BitcoinAverage, BitcoinCharts)
  • Correction: Better handling of the mode and comment field using the aqbanking import backend.
  • Feature: New REGEXPCAPTURE operator in "Search & Process" to capture a value by regular expression
  • Feature: Import backend aqbanking allows to import accounts without an IBAN. (See

Get it, Try it, Love it...

Grab Skrooge from your distro's packaging system. If it is not yet included in repositories, go get it from our website, and bug your favorite distro for inclusion.

Now, you can try the appimage or the flatpak too !

If you want to help me to industrialise the windows version, you can get it from here:

Get Involved

To enhance Skrooge, we need you ! There are many ways you can help us:

  • Submit bug reports
  • Discuss on the KDE forum
  • Contact us, give us your ideas, explain us where we can improve...
  • Can you design good interfaces ? Can you code ? Have webmaster skills ? Are you a billionaire looking for a worthy investment ? We will be very pleased in welcoming you in the skrooge team, contact us !
KStars v3.3.1 is released for Windows, MacOS, and Linux on all platforms (Intel/AMD and ARM). This is yet another maintenance release with a few new experimental features and addons.

MacOS Updates

Robert Lancaster cleared all the issues reported on problems on MacOS. After gathering the feedback of users with experimental releases on this dedicated INDI thread.

Astrometry on MacOS

Furthermore, DBus is now working again in this release which would make the Ekos Scheduler operational again under Mac.

New Observatory Module

Wolfgang Reissenberger developed a new Ekos Observatory module to manage the dome and weather-triggered shutdown procedure. This is the first iteration of the module with more expected in the upcoming months but it provides a compact and friendly interface to observatory management. Feedback is welcome.

Meridian Flip is gone!

Well, sorta of. Wolfgang Reissenberger removed Meridian Flip from the Capture Module and moved it to the Mount Module. This way the meridian flip can be controlled even if there is no active capture session going on.

So just set when you want the meridian flip to occur at the mount module. Remember that the setting is in Hour Angle (HA). 1 HA = 15 degrees, therefore 0.1 HA = 1.5 degrees West of the Meridian. 

Always use a positive value to ensure proper meridian flip takes place. Using zero could theoretically work but it is at the very edge where the decision to flip or not is made by the mount, so it's safer to use a slightly higher value like 0.1 HA.

Stream Window

Due to popular demand, the FPS control in the Stream window is replaced Frame Duration in seconds control. So a setting of 0.1 seconds would yield a frame rate of 10 FPS (1/0.1 = 10) if the hardware can support that. The duration can be set as low as 1 microsecond but only if supported by the driver and camera!

Other highlights:

  • Reset focus frame when mount slews.
  • Do not abort PHD2 guiding while suspended.
  • Switching to homebrew, python3, and astroy for plate solving on OS X.
  • Check if dust cap is detected before checking whether the camera is shutterful or shutterless.
  • Fix translation issue with Sun, Moon, and Earth designations.

Saturday, 22 June 2019

Hello everyone, it's been almost a month since my last post and there are a lot of changes that have been done since then.

First, what I called the "minimal plan" is arleady done! Cantor can now load Jupyter notebooks and save the currently opened document in Jupyter format.

Below you can see how one of the Jypiter notebooks I'm using for test purposes (I have mentioned them in previous post) looks in Jupyter and in Cantor.

As you can see, there aren't many differences in the representation of the content except of some minor differences in the rendering of the markdown code.

For the comparison, I also prepared some previews of the same fragments of the notebooks, opened in Jupyter and in Cantor.
This is a fragment from Understanding evolutionary strategies and covariance matrix adaptation notebook.

As the next example, we show a screenshot of A Reaction-Diffusion Equation Solver in Python with Numpy notebook.

As the final example, we show a screenshot of Rigid-body transformations in a plane (2D) notebook.

To be more detailed and concrete on what is currently supported in Cantor, below is the list of objects that can be imported:
  • Markdown cells
    • With mathematical expressions
    • With attachments
  • Code cells
    • With text (including error messages) and image results)
  •  Raw NBConvert cells
Cantor is able to handle almost all content specified by Jupyter notebook format, except of some metadata information about the notebook in general and about its cells, information about the used "kernel" (support for this will be added soon) and results of another types (for example latex or html outputs), which are more difficult to implement because of the lack of good and complete documentation of them.

When saving the project in Jupyter's format, Cantor handles almost all of its native entry types like markdown entries, text entries, code entries and image entries. For the remaining "page break entry" in Cantor it is still to be worked out how to map this element to Jupyter's structures.

Despite quite a good progress made, there is still a lot place and potential for improvements. Besides some technical issues arising when dealing with the import of another format and mapping its sturcture to the native structures of your application, which is very natural actually for all applications I guess, there is currently also currently problem with perfromance of the renderer used for mathematical expressions in Cantor. Openning of large documents (either in Cantor's native format or Jupyter notebooks) having a lot of formulas takes considerable amount of time because of the bad renderer implementation in Cantor. This heavily influence the user experience and I plan to start working on this soon.

So, there are some work for done before Cantor will support what I call the "maximum plan". With this I understand the ability to garantee the conversion between two formats when openning or saving projects to happen without any substantial loss of information relevant and critical for the consumption of the project file.

To achieve this, I want now to invest more into testing with more notebooks and closing the remaining gaps but also into writing automatic tests for Cantor covering this new functionality in Cantor. The latter are important to also prevent any kind of regressions introduce during bug fixing activities in the next weeks. This is something for the next week.

In the next post I plan to show a working test system and how Cantor are passing its tests.

Last weeks have been crazy for me. Since the GSoC began, I have been rushing everything related to university and my life to dedicate exclusively to the development. Besides the two classes I was taking, Static Code Analysis and Approximation Algorithms, I had my obligatory teaching internship in Project and Analysis of Algorithms for the postgraduate program, where I was responsible for creating and evaluating assignments for 50+ students and answering general questions.


Besides that, I was in the organization of the Latin & American Algorithms, Graphs and Optimization Symposium during June 2nd to 7th, where I was responsible for a plethora of things before and during the event (Although it was a lot of fun, a lot of researchers from all around the globe and incredible research). And, just as I got back, I had to delve back to tests, assignments, seminars…

One of the problems for brazilians in taking the GSoC is that the beginning of the program does not match exactly with the end of our classes. But now, as everything is (finally!) ending, I can focus entirely in the GSoC and my project. Just before the GSoC (and before even creating my project), I had compiled to KDE Framework 5 and the ROCS software, so most of the development environment was already set.

I am using as my environment the Qt Creator, and I am focusing in the algorithm for creation of specific graph classes inside the generategraphwidget. I have already implemented algorithms for Paths, Complete and Complete Bipartite graphs, besides fixing some details here and there. These modifications are still only in my local machine, as I am having some problems pushing the commits (I must be doing something wrong in my configuration).

I noticed that the calculation of the position of the graphs generated is strange, as it put the graphs almost ouside the view (and we can’t push the view there), so probably the positioning must be corrected. There is a function for calculating the center there, I will compare that function to the point where the view always come back and adjust accordingly. Another detail is the symbols of the view tools, that are not showing correctly.

Friday, 21 June 2019


Hello everyone! I'm participating in Google Summer of Code for the second time. I'm working on KDE's LabPlot, just like last year. I'm very happy that I can work again with my former and current mentor Kristóf Fábián, and with Alexander Semke, an invaluable member of the LabPlot team, who is like a second mentor to me. At first, let me introduce you my current project: 

"There are many internet pages providing data sets for educational and academic purposes concerning various fields of science, and not only (astrophysics, statistics, medicine, etc.). Some tools used in the scientific field provide some "wrappers" for such online sources and allow the user to easily investigate these data sets and work with them in all kinds of applications, whilst the technical details and methodology like the fetching of data from the server and parsing are done completely transparent for the user. The user doesn’t even know what happens in the “background”.
The goal of this project is to add similar functionality to LabPlot. This would make LabPlot more fit for educational purposes, students and teachers could use LabPlot for visualizing and analyzing data connected to the currently studied field. And also could bring LabPlot into the life of the average student."

If the synopsis caught your attention and you are interested in the project itself, you can check out my proposal, to find out in detail what the project really is about.

Bonding period

Let's start with the bonding period. I used this time to investigate/analyze already existing solutions for uploading/downloading with KNS3 also its API documentation, checking out various welcome screens of other applications to get some inspiration, checking out some simpler caching implementations.

I communicated with my mentor and others from the LabPlot team to properly  design the project and the course of implementation. I also tried to get involved in the KDE community.

First month

At the end of the first month I can state that fortunately I was able to make a quite good progress. Everything is successfully implemented from what was proposed for the first month, and I could also proceed to other tasks. Now let's see what's been done.

Dealing with datasets

The very first step was to implement a new widget, called ImportDatasetWidget which could provide the functionality to:
  • list the available categories and subcategories of datasets
  • list the available datasets for a certain subcategory
  • refresh the list of datasets and delete the downloaded metadata files

The user can select from the categories and subcategories of the available datasets, as visible in the picture above. In order to visualize these I used a QTreeWidget. When the user clicks on a subcategory then every dataset, belonging to it, is listed in a QListView. The user is also provided with the possibility to search a particular category/subcategory, since we estimate that there will be a considerable amount of datasets by the end of the project. This is also the case with the dataset list.

We had to create metadata files in order to record additional information about datasets, and also to divide them into categories and subcategories. We use a metadata data file which contains every category and subcategory and a list of datasets for every subcategory. Additionally there is a metadata file for every dataset containing various data about the dataset itself.

In the "Datasets" section we highlight every dataset the metadata of which is locally available (in the labplot directory located in the user's home directory). When the user clicks on the "Clear cache" button every file is deleted from the above mentioned directory. The "Refresh" button provides the possibility to refresh the locally available metadata file, which contains the categories and subcategories.
In order to make possible the import of datasets into LabPlot, and saving them into Spreadsheets I had to implement a helper class: DatasetHandler. This class processes a dataset's metadata file, configures the Spreadsheet into which the data will be loaded, downloads the dataset, processes it (based on the preferences present in the metadata file) then loads its content into the spreadsheet.

ImportDatasetWidget basic functionality

There also is a "Add new Dataset" button. This makes it possible for the user to add own datasets to LabPlot's list. When the button is clicked a new dialog is shown to the user: DatasetMetadataManagerDialog

Adding new dataset to the collection

This dialog provides an interface for the user, so the user can easily set the options necessary for the dataset's metadata file. The user doesn't have to create the metadata file himself/herself, the dialog does this instead based on the data provided by the user. The dialog also adds the new dataset's name to the categories' metadata file. Therefore the user can easily add new datasets, and later load them easily, using the ImportDatasetWidget. 

 Adding new dataset

While implementing these functionalities we were faced with some problems, which still need to be solved. We wanted to make possible the download and upload to, using the KNS3 library.  So users could really add new datasets to the basic list, and could download only those metadata files which are needed. This was our intention, however KNS3 gave us a hard time. It provides its functionality only by two dialogs, which we wouldn't prefer to use. We want to incorporate the dialogs' functionality into LabPlot somehow, but we didn't figure this out yet. but, we are thinking about it. Another problem with KNS3 is that according to KDE's mailing list, uploading with KNS3 is disabled for an indefinite amount of time due to errors caused by the library. Therefore the question arises: Do we need downloading if uploading is not possible? 

Initial Welcome Screen

Due to successfully implementing quite fast the dataset part and also to the difficulties caused by KNS3, I started to design and to create a prototype for our Welcome Screen. The first step was to decide what technology we want to adapt in order to implement this welcome screen. We considered creating a widget based GUI, or using QML for this purpose. We chose QML, because despite  it being more complex and cumbersome to work with, it offers a greater freedom to implement ideas. So this is the main reason this technology was chosen. Then we had to think through, what functionalities we want to be provided by the welcome screen. We came up with:
  • Recently opened projects
  • Help section: Documentation, FAQ, etc.
  • Exploring datasets
  • Example projects
  • Latest release information 
  • News section
The current state of the welcome screen
Every part, except the Examples section, is fully functional. In the recent projects section the user can choose from the lastly opened projects and load them only by a click. The help section navigates the user to the Documentation, FAQ, Features and Support part of LabPlot's web page. In the release section the user can read about the last release. The news section is connected to the RSS feed of LabPlot's webpage, so the user can see the new posts of the web page. A central piece is the "Start exploring data" section where the user can browse the available datasets, display information about them, and open them with only one click. The functionality of the welcome screen is presented in the following video:

Finally I'd like to say some words about the next steps. The first will be implementing the "Examples" section of the welcome screen. In order to do so we'll have to design a metadata file for the example  projects and nonetheless we'll need to create some example projects to have something to work with. When functionally the welcome screen works, we can proceed to refining the design itself, making it more pleasant and adapting it to the user's theme's color. We'll still have to figure out what to do with the KNS3 library, should we use it or not, and if yes then how, in what manner. Nonetheless, we have to collect more datasets in order to provide the users of LabPlot with a considerable dataset collection.

This is it for now. I will continue to work on the project alongside Kristóf and Alexander. I think we form a quite good team. I'm thankful to them, for their guidance. When anything new will be finished and running I'll let you know. 
See you soon!

I spent my first two weeks of GSoC (and the three weeks before it starts) trying to figure out how the Khipu’s code works but I didn’t get it. I was putting my effort trying to plot vectors but there were a enourmous structure of the code that I’d need understand before and it was unexpected for me. So, one of my menthors, Tomaz, suggested that I could change my project and try to refactor Khipu. So this last week I started a new interface, because the current interface is very simple and can be better.
I’m studying QML and already started the new interface, you can see below:

I’m in the end of my semester at college, so I need to split my time with GSoC and my college tasks, so now I’m going slowly but on the next month I have my vacation and I’ll have all of my time dedicated to it.
My menthors have helped me a lot so far, and I would like to say thanks for the patience, and say sorry for KDE for my initial project and for waste the first weeks on a thing that didn’t produce anything.

Over the past few weeks I have been working on the Snapshot Docker, and now it is finished already. -))

The idea of snapshots is to make copies of the current document and allow users to return to them at a later time. This is a part of my whole Google Summer of Code project, which aims to bring Krita a better undo/redo system. When fully implemented, it will fully replace the current mechanism that stores actions with one that stores different states. That is to say, Krita will create a snapshot of the document for every undoable step.

Snapshot Docker is not only a feature requested by artists but also a experimental implementation of the clone-replace mechanism. It has the following key parts:

  1. Cloning the document, which is provided by KisDocument::lockAndCloneForSaving(), which is already implemented in master.

  2. Replace the current document by another one, which is previously cloned.

Part (1) is already implemented so the work falls mainly on Part (2). My original approach is to replace the document and image pointers in KisView and KisCanvas, but it is not viable since other parts of the program have signal/slot connections on the KisDocument and KisImage, and directly replacing the two pointers will not only fail to work but also cause weird crashes. After discussing with Dmitry, we find out that it is probably better not to touch these two pointers, but to replace the content within KisDocument and KisImage. It is therefore suggested that two member functions be made, namely KisDocument::copyFromDocument and KisImage::copyFromImage. These functions copies data from another document/image to the current one, avoiding the changes to the pointers inside the original instance. Eh, except for the nodes, since we have to reset and refresh the nodes in the image.

It is also important to notify other parts of Krita about the change in the document. One important thing is tell the layer docker about the changes in the nodes (they are completely different), which is done using the KisImage::sigLayersChangedAsync() signal. The current activated node is also stored and restored, by using the strategy of linearizing the layer tree using a queue, and then finding the corresponding node in the cloned image. Note that when restoring, we are unable to find layer by uuid, since they should change when copied to the current image (the comments in KisImage says the only situation where we should keep the uuids is for saving).

Another interesting thing is the palettes. Krita 4.2.0 allows documents to store their own, local palettes. The palette list is but a QList<KoColorSet *>, meaning that only creating a new QList of the same pointers will not work. This is because, the palettes are controlled by canvas resource manager, which takes the responsibility to delete them. Therefore, when taking snapshots, we had better take deep copies of the KoColorSets. And then another problem comes: the snapshots own their KoColorSets because they are not controlled by the resource manager in any way; but the KisDocument in the view does not. So we have to set up another flag, ownsPaletteList, to tell the document whether it should delete the palettes in the destructor.

And now the work has shifted to the refactoring of kritaflake, the library that mainly handles vector layers and shapes. I converted the whole KoShape hierarchy to implicit sharing where possible, but some tests are broken. I am now on Windows, where unit tests do not run. I will continue the development of flake as soon as I get access to my Linux laptop.

Tuesday, 18 June 2019

Finally done with the first phase of the feature I wanted, 4 years back. Though just the unit test for the algorithm is implemented. At least for now, we can detect edges and stick to it.