Hi, this is going to be a quick review of what I did last week

Just a little about how cantor works

Cantor is divided in two main parts:

Worksheets –  An interface that allows user to interact with available back ends. Each worksheet is associated with one back end

Back ends –  Back ends are implemented as plugins

The whole back end architecture is divided in several parts. I am going to discuss the ones on which I worked last week

Classes:
* Back end – Stores static information about back ends, like name, version , what all features(syntax highlighting, tab completion etc) a back end supports

* Session – This is where a connection to back end is established and destroyed. To be specific, the method login() is used for initiating a connection  and logout() is used for ending the connection with back end

* Expression – Every command sent by the user is treated as an Expression . The class is also responsible for storing the result of the expression

Last week I successfully completed:
* Establishing connection with Qalculate back end
* Using streams for I/O
* Parsing the output returned by Qalculate

That’s it for this blog. If you have any questions/suggestions, please get in touch.

Cheers!

Hi everyone, is everything ok? I hope so.

Today, I will talk about my week working on Krita during this first week of the coding period.

1. Implement a new output widget to scripter

In the start I'm intending to implement just a "clear" action to the output widget, but I figure out that this behavior can happen in other moments. What is it? My widgets can have children and your children can have children... Sometimes, I need to communicate with then from a different widget through the uicontroller. Now, in the findWidget method, I need to send two arguments: root/parent widget (A widget registered in the uicontroller when the scripter starts) and the searched widget (optional). The second one must be a child of the root widget.

My implementation in a nutshell:

• findWidget method improved
• New OutputWidget with the clear action inside it.
• ClearAction that clears the OutputTextWidget
• I change the old OutputWidget to OutputTextWidget

Review D6057 and created and commit pushed to my remote branch.

2. Trying to discover a problem with Scripter’s debugger.

That's a problem that I figure out some weeks ago and promise to myself that I would implement that. I will try to explain that in a few words: It's HARD.

When I tested the debugger feature some time that was working properly to all Python/PyQt scripts, including some basic method from the Krita API. Someday, I resolve to test all the methods in the API and ... SURPRISE... some methods was not working properly, but why?.

I tested this method in the normal execution and everything was OK, so I told to my mentor about it and he said, it could be a problem in the SIP or C++ code, then I relax and I focused in my exams and GSoC proposal (yeah, I was approved xD).

When I was selected to GSoC, this problem was in my mind and I promise to myself that I would try to understand that.

The first thing to understand my problem is to understand how I implemented this feature, so I did this prints below.

The action that starts the debugger, calls the "start" method in DebugController, create an object that represents the current debugger class and calls start method in the Debugger. You can see a snippet of the debugger class, showing the start method.

If you understand a little about asyncio, you know that the line 90 is waiting a asyncronous call. I'm using async, because I don't know when the Queue in display is not empty.

I have another process running executes the Debugger class that innerits from bdb.Bdb. Everything is working well, exept for one thing: I can't writein shared objects(Krita objects). When I started this implementation, I didn't figure out that and now, I have a huge problem.

I did try to solve that using threading module, but when I use this another problem is created, because if we try to write in some object that's in use, we have a race condition(Nooooo) and resolve that, my friends, it's really awful :/.

I have some ideas to solve this using generators from python with yield to save a state from debugger session, but I will try this in the future, because I need to implement some plugins to YESTERDAY.

3. Planning to implement a generic plugin/script to setColorSpace

• I will implement a script or plugin to setColorSpace where the parameters can be selected from the script.

• I need do implement one method to each set of parameters in the C++/SIP API.

• Implement a method to validate the join of this parameters

That’s it for now, until the next week. See ya!!

I have been very happy with my printer except for one thing my printer uses a melzi board. The only issue is there is only one firmware for melzi. This makes testing firmwares in AtCore more difficult since I can’t test on a real machine. In order to do that I need to move to a RAMPS kit. This will allow me to flash just about any firmware that I want. I will keep the details to a minimum for this post would be really long otherwise.

RAMPS kit

After ordering the nessasary parts all the extra stuff I needed to complete this project I can finally begin. The first step is to build the ramps kit and then install some firmware with a sane configuration. For the first firmware I have decided to go with Repetier 0.92 since its the same as my old firmware.Using repetiers web configuration tool I ran thru all the steps only changing the required items. I was able to download and build this firmware and flash it in no time. The first test of the firmware and the screen didnt show anything. Checking the config I can see that I picked the wrong screen. With that fixed I could discover my next problem the control knob moved backward from what I was used to, it was to fast and had to high a repeat rate . So after a few more configs attempts I was able to get everything worked out and my board was now loaded with firmware.

Mid board swap

Time to take the old control box apart and wire up the new one.. There is only one problem the plugs dont all fit on the new. Every wire needs new connectors. I made all my crimps, wireed the new board and fired up the machine. But there were problems. Y moved in the wrong direction and the Z motors were spinnng wrong. It didn’t take long before I had these issues fixed. With the motors all checked and working I was ready to try the heaters. That was when the fun really started, almost instantly you could see smoke and the mosfet for the bed was burning up. This killed that ramps board so i had to order another.

After a few days of waiting I receved my new ramps board and an external mosfet for the heated bed. With those installed every thing was ready to be put into the old case. I had to made a ramps holder that didn’t push the reset button . I did this by printing a few ramps holders and chopping them up and glueing them back together in way that worked in my case.

Boards mounted in the old case

After that hack job was assembled I still needed to mount the mosfet board. Luckly I was able to find another mount and modify it to mount on the two unused melzi mouning posts.I also needed a way to get some space inside the case and a place to put my usb B external plug so we can plugin the ramps nicely from outside the case. I modified a 120mm fan adaptor to include space for my usb port and put the whole thing together to test. Its been working fine for about two weeks now and its printed about half of its new homes parts.

Some while ago I wrote about a little git hook that automatically sets up your commit author identity after git clone based on the remote origin address. Recently I learned that in git 2.8 a new pre-push hook was introduced, and I immediately knew it will fix my second biggest pain point: accidentally pushing directly into git instead of Gerrit.

If you often switch between different projects where some use Gerrit for code review and some don’t, it’s very easy to just mistakenly do

git push master

when in fact you wanted to

git push HEAD:refs/for/master

There are some tricks how to make it harder for you to accidentally do this, like creating a “gpush” alias that pushes to refs/for/master and disabling pushing into the ‘origin’ remote by changing the push URL to something invalid. That, however, is not perfect because there are still ways how to by-pass it. And it becomes complicated if you use more than one remote and it’s clumsy if you sometimes do want to push directly into git (for example to submit a large patch series).

With a custom pre-push hook, we can check if the remote that we are pushing into is a Gerrit instance and then check if the remote ref that we are pushing into is a “Gerrit ref” (refs/for/foo) instead of a regular branch and we can have a nice “Are you sure you want to do this?” prompt:

#!/usr/bin/python3
# -*- coding: utf-8 -*-
#
# (C) 2017 Daniel Vrátil <dvratil@kde.org>
# License: GPL

import os
import sys

def remoteIsGerrit(remoteName, remoteUrl):
    # if the remote is called "gerrit", assume it's Gerrit
    if 'gerrit' in remoteName:
        return True
    # if the remote URL contains the default Gerrit port, assume it's Gerrit
    if ':29418/' in remoteUrl:
        return True

    # TODO: Add custom checks to match your non-standard Gerrit configuration

    return False

def main():
    # name and URL of the remote we are pushing into is passed as arguments
    if not remoteIsGerrit(sys.argv[1], sys.argv[2]):
        # If we are not pushing into gerrit, then simply allow the push
        return

    # The pushed refs are passed in via stdin
    for line in sys.stdin:
        # line = "localRef localRev remoteRef remoteRev"
        remoteRef = line.split(' ')[2]
        # Check if the remoteRef contains the typical Gerrit 'refs/for/foo'.
        if not remoteRef.startswith('refs/for/'):
            print('!!')
            print('!! You are pushing directly into git instead of Gerrit !!')
            print('!! Do you want to continue? [y/N] ', end = '', flush = True)
            if open('/dev/tty', 'rb').readline().decode().strip().lower() == 'y':
                return
            else:
                sys.exit(1)


if __name__ == "__main__":
    main()

Save this a file as “pre-push” and move it into .git/hooks/ folder in your local repository clone. Remember to make the script executable.

Here is how it works: trying to push into “gerrit” remote to branch “5.9” directly gets intercepted by our new hook and if you press ‘n’ the push gets aborted. If I would’ve pressed ‘y’, then the push would proceed.

$ git push gerrit 5.9
Enter passphrase for key '/home/dvratil/.ssh/id_rsa.qt':  
!! 
!! You are pushing directly into git instead of Gerrit !! 
!! Do you want to continue? [y/N] n
error: failed to push some refs to 'ssh://dvratil@codereview.qt-project.org:29418/qt/qtbase.git'

Now when we try to push to the correct ref (refs/for/5.9) the hook accepts the push without any complaints:

$ git push gerrit HEAD:refs/for/5.9
Counting objects: 6, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 407 bytes, done.
Total 4 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2)
remote: Processing changes: new: 1, refs: 1, done    
remote: 
remote: New Changes:
remote:   https://codereview.qt-project.org/......
remote: 
To ssh://dvratil@codereview.qt-project.org:29418/qt/qtbase
 * [new branch] HEAD -> refs/for/5.9

To have the hook automatically copied into every new repository that you clone, save it as “pre-push” into .git-templates/hooks/ and run the following command:

git config --global init.templatedir ~/.git-templates

Git will automatically copy everything from the ‘templatedir’ into the .git directory after every new git clone, so you don’t need to bother with doing that manually. Unfortunately for all your existing checkouts, you have to copy the hook manually

KStars has a long history and many developers touched the >136000 lines of C++ codes. The goal of my GSOC project to do a major overall improvement and bring the modern C++ features to improve the stability as well as fix the memory handling errors. I have the following goals in June to make KStars better:

May 30th to June 26th:

 ● Add ccache support
 ● Add hardening support to the CMake build system (improve security)
 ● Add Clang specific improvements to the CMake build system
 ● Add Clang sanitizers to the CMake build system
 ● Run the KStars application with the sanitizers enabled and fix all memory error found by these tools
 ● Add Unity build to the CMake build system to cut the build time
 ● Refactor codes to modern C++11/C++14 what I get in touch while fixing bugs.
 ● Add documentation about the improvements and the sanitizers to the wiki pages.

My mentor: Jasem Mutlaq

After all that FreeBSD shuffling, I’m going to move myself, too. For the past six years I’ve been commuting by train to Utrecht, where I worked at the Dutch Association of Audiological Centres on patient systems, financing, some data analysis and all the other stuff that happens in a small organization with a broad remit (also “help! the website is down!”). Starting today I’ll be moving less far, and commuting to my office upstairs instead.

As of today, I’m an independent contractor; the domain cnossos.nl which I registered ages ago when I last worked with Sebas is now in use.

As of today, I’m working with Blue Systems on the Calamares Installer Framework. Not a KDE project, but an independent, Qt-based, Free Software project used by Linux distro’s like Manjaro and Netrunner (which in turn ship KDE Plasma Desktop images). As a FreeBSD person, it feels a little weird to be writing Linux installers, but I have a secret hobby project for Calamares, too: adding ZFS install support and maybe even getting it to work as a FreeBSD installer. But that’s hobby, outside of the regular maintainence work I’ll be doing.

As of today, I’m working with the ARPA2 project on LDAP tooling and the IdentityHub project. That’s a lot of bit-banging, sometimes in C, which feels a little primitive when coming from a C++ background (I should look at Go sometime).

As of today, I’m still working with the Dutch Association for the Evaluation of Hearing Aids, but only as their occasional website-and-database-futzing dude.

As of today, I’m a full time freelance Free Software contributor. I’ve got a mantra: “if I use it, I’ll aggressively improve it”. Which means there’s plenty of patches coming down the line, for Charm time tracker for one thing.

This is the second post in my GSoC series. You can read the first one here.

When creating anything from scratch you really have to choose the best resources and tools for the job: if you are baking a cake you want the best ingredients, if you are building a table you want the best wood. The same goes for creating software, one should alwasy aim at using the best technologies availbale.

Finding the best tools in Web Development is sometimes not an easy task, this field moves so fast that one can’t possibly keep up with all the new libraries, frameworks and methodologies (That’s why sites like Days Since Last JavaScript Framework exists).

The best possible way to find the right combination of tools for a project is by experimenting with as many tools as possible, discarding the one you don’t like and keeping the one you like the most (or, sometimes, dislike the less).

And this is exactly what I started to do in the last months. I got out of my web development comfort zone and gave a try to some new things. Some I didn’t like and many others I loved. Yes, sometimes it felt like this article but I am learning tons of new stuff, which is what matters.

During this Google Summer of Code I will keep experimenting and use many of the concepts I learnt recently: let’s wait no more, here is an overview of what I will be using to create WikiToLearn new frontend.

Frontend

Since we are building a PWA the most (and for many use cases, the only) important thing to consider is the frontend technologies.

Since we are building something a little bit complex it is definitely worth it to use some kind of frontend framework. There are many out there (React and Angular are probably the most popular) and after trying a few of these I decided to choose Vue.js.

Not only it is one of the most lightweight (and fast) framework available, it is actively developed and has an awesome and welcoming community. It is far from being as popular as React or Angular but in the near future I hope it will reach their popularity, because it deserves it.

I choose it because it is simple enough for newcomers but powerful for experienced users. Its templating language is also very easy to understand: I never liked React and its JSX.

Out of the box it only provides the minimal required functionalities: it is more of a micro framework that you can complete with additional (but alwasy optional) libraries. In our case we will use Vuex for state management (think of it as a global variable which does control the state of the application) and vue-router for route managament (it does basically control which parts of the interface to display based on the links you click).

Writing code

For writing HTML code for components and views we decided to use pug instead of plain HTML. This is because pug forces you to indent your code properly (in the same way Python does): it may seems like a small reason but this means that one is forced to write clearer code, something very important when working on a open source project.

For styling the interface we are using Sass. We have been using this for some time and it does it job very well. Since we already have some parts of the interface styled in Sass it will be easy to port them.

For Javascript we will be writing ES6 Javascript: this allows us to write cleaner and easier to understanand code, all thanks to the syntatic sugar it provides. Of course many browsers don’t understand ES6, that’s why we are transpiling it to ES5 Javascript using buble.

Bundling with webpack

A few years ago there were Bash scripts, then grunt came, then gulp. Nowadays everyone is moving to webpack. Although all the previous mentioned solutions are still valid (and one may say compltely different from webpack), webpack does allow faster development and better building for production.

When executing our build-for-production configuration, webpack takes care of many interesting tasks:

• delete unused code and minify used one
• compile pug to HTML, Sass to CSS, ES6 to ES5
• localize the PWA to different languages
• inline images by converting them to Base64
• build an HTML file with all the scripts and styles already linked
• automatic generation of a service worker for caching
• much more

Although all of these (actually not all) were probably possible with the existing tools it is definitely worth it to invest time in learning webpack: with webpack you just specify the configuration, without defining the work pipeline (in Gulp you had to control which tasks to execute in which order).

Coding Conventions

Since it is very important to write consistent code in term of conventions, we will be using linters all over the codebase. Most importantly we will lint the source Javasript (via EsLint), using Google’ style guide as a base, but we will apply a few customizations to it. We will also lint our CSS via stylelint.

Linters will be running both when developing and when building for production, forcing the developer to fix the existing code according to the linters: you won’t be able to run your code unless it is written correctly.

And yes, we will be using tabs, not spaces: this is where EditorConfig is very important:

EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs.

Backend

Server Side Rendering

Since we want to keep basic compatibility for people without Javascript and for slow devices we decided to implement server side rendering.

This means that every request will be pre-rendered server side before reaching the browser; Most of the Web Application out there don’t pre-render the code, sending to the browser just an almost empty page, leaving to the browser the work to render the interface: this means that if you don’t have JS enabled, you are out of luck, nothing will display.

With SSR, even if you don’t have JS, you will at least be able to use the basic functionalities of the website, such as reading pages.

Serving the PWA

For serving the PWA to the public we will use a Node.js server, running Express. Node.js is absolutely needed because we want server side rendering: without it we could have used just a simple HTTP server such as Apache or nginx.

The template

In the past months I have been developing (together with another friend of mine) a Vue-based PWA boilerplate project which serves as a starting point for everyone looking to develop a progressive web app with Vue.

I was going to develop this template anyway regardless of GSoC, because right now there is not a single example project out there with as many features as this one: as soon as I head I was selected I began finalizing the details especially needed for WikiToLearn.

The generic template: very simple

If you are interested on the template it is available on Github. Don’t worry, there is plenty of documentation that explains everything.

What’s next?

I will be now forking the template and start using it as a base for the WikiToLearn PWA. I will be publishing the project on KDE’s git: check it out here

In the next weeks I will be developing the first few features for the web app, focusing on the browsing and reading functionalities.

Let me know what you think about this post in the comments. Expect another post as soon as I have something good to show you.

Quoting from a message Tobias C. Berner sent to the kde-freebsd mailing list:

The development repository that the KDE-FreeBSD team uses to work on the KDE for FreeBSD is moving to github. For a long time we have been using’, an SVN repository kindly hosted by PC-BSD and iX Systems. At this point in time, we believe that moving to github will make the ports a bit more accessible for users and align our ports-development effort better with the way upstream (that is, with official FreeBSD ports) works. We would like to express our thanks to PC-BSD for hosting us all this time, in particular Josh Paetzel for administering the repository. In the coming days we will be updating documentation to reflect the new source of KDE-FreeBSD ports.

The repository can now be found at freebsd/freebsd-ports-kde, where the plasma5 branch is a ports tree with all the updates from the old svn repository.

The main difference between the old svn repository and the new one is, that like gnome@ and xorg@, we now have a complete portstree. So the kdemerge script previously used is obsolete — however, this also mean, that we will lag behind ports-master, which we will try to sync with every weekend.

Thanks also to bapt@ for helping set up this ports tree, and kwm@ for helpful suggestions based on what the GNOME-FreeBSD team has done.

We’re updating the documentation (in the KDE Community Wiki), but mostly things will be simpler, and it may make sense to simply checkout /usr/ports from the KDE-FreeBSD ports tree instead of anything else. We’ll continue to call it “Area51”, even if that string doesn’t occur in its name anymore.

Cutelyst the Qt / C++11 web framework just got another important release.

WebSocket support is probably a key feature to have on a modern web framework, Perl Catalyst doesn’t look like it wasn’t designed with it in mind, the way I found to do WS there wasn’t intuitive.

Qt has WebSocket support via QWebSockets module, which includes client and server implementation, and I have used it for a few jobs due lack of support inside Cutelyst. While looking at it’s implementation I realized that it wouldn’t fit into Cutelyst, and it even had a TODO due a blocking call, so no go.

I’ve looked then at uWSGI implementation and while it is far from being RFC compliant or even usable (IMO) the parser was much simpler, but it required that all data was available to parse. Since messages can be split into frames (really 63bits to address payload was probably not enough) and each frame has a bit to know if the message is over, which uWSGI simply discards, thus any fragmented message can’t be merged back.

WebSockets in Cutelyst have an API closer to what QWebSocket has, but since we are a web framework we have more control over things, first on your websocket endpoint you must call:

c->response->webSocketHandshake()

If the return is false just return from the method to ignore the request or it might be the case that you want the same path to show a chat HTML page, this can happen if the client didn’t sent the proper headers or if the Engine backend/protocol doesn’t support WebSockets. If true you can connect to the Request object and get notified about pong, close, binary and text (UTF-8) messages and frames, a simple usage is like:

connect(req, &Request::webSocketTextMessage, [=] (const QString &msg) {
  qDebug() << "Got text msg" <webSocketTextMessage(msg);
});

This will work as a Echo server, the signals also include Cutelyst::Context in the case you are connecting to a slot.

Cutelyst implementation is non-blocking, a little faster than QWebSockets, uses less memory and passes all http://autobahn.ws/testsuite tests, it doesn’t support compression yet.

systemd socket activation support was added, this is another very cool feature although it’s still missing a way to die the application on idle. On my tests with systemd socket activation, Cutelyst started so fast that the first request that starts it takes only twice the time it would take if Cutelyst was already running.

This release also include:

• Fixes for using cutelyst-wsgi talking FastCGI to Apache
• Workaround QLocalServer closing down when an accept fail (very common when used on prefork/threaded servers)
• Fixed when using cutelyst-wsgi on threaded mode, POST requests would use the same buffer corrupting or crashing.
• A few other fixes.

Due WebSockets plans for Cutelyst 2 are taking shape, but I’ll probably try to add HTTP2 support first since the multiplexing part is might make Cutelyst Engine quite complex.

Have fun https://github.com/cutelyst/cutelyst/archive/v1.7.0.tar.gz

1 month of GSoC is already over and the coding period has officially begun. Here’s a highlight of what I did and what I plan to do for this week

Most of the time of community bonding period was spent giving college exams. By the time my exams got over,  I only had a week left to make something useful of the community bonding period time.

The last week started with a discussion with my mentor , where we decided which API to use to port the back ends.  We had to  decide between QProcess and KProcess. Just a brief of what these APIs do:

QProcess is used to start external programs and to communicate with them. The communication between QProcess and the external program happens through channels. The three standard channels used for communication are
Standard output(stdout): supplies regular console output
Standard error(stderr): supplies the errors that are printed by the process
Standard input(stdin): provides input to the process

KProcess is no different from QProcess. It inherits QProcess and extends it by by some extra and useful functionality

Since a few of the back ends of cantor were already using KProcess, we had to decide whether we actually need KProcess or whether QProcess will suffice our needs. The best  way to  decide this  was to port a back end which makes use of KProcess to QProcess.

Port of Scilab to QProcess

The port process was pretty simple and did not take more than an hour to port and test. The test was performed  on various inputs including plot commands.
You can have a look at the commit that actually does the port
Since Everything worked fine, we decided to move forward with QProcess and use it for other back ends

Plan for this week

The very first back end I have decided to work on is Qalculate. Qalculate at the moment uses libqalculate library for all the calculations.
To get rid of libcalulate, we will be making use of qalc which is the command line interface for Qalculate
This week  I’ll be concentrating on setting up basic communication  between Cantor and  Qalculate using  qalc

Let the hacking begin!

The KDE/FreeBSD website has been around for a long time. It has been the repository of much (well, maybe some) wisdom around KDE-on-FreeBSD. But as a repository of knowledge, it has been rather limited in recent years: it lives in KDE’s source-code repositories, and as such has a pretty high barrier to entry. You need a KDE developer account to edit it, for one. And then, editing PHP files in git is not fun, if you’re trying to contribute documentation, howto’s, or screenshots.

So the content has almost entirely migrated to the KDE Community wiki.

The community wiki is described as:

Community.kde.org is the working area for the KDE community. It provides a place for sharing information within the community, including policies, guidelines and coordination.

That’s most of what f.k.o does, so putting it somewhere more accessible, and easier to edit, makes sense.

There’s only two things really left in git: the team page, describing who is on the team, and the in-memoriam page for Alan Eldridge. Neither of those is, in my opinion, up for community-editing-debate.

So now’s the time for FreeBSD-using KDEsta’s, and KDE-using FreeBSDudes, to get the content together!

Few hours to go for the start of the coding period of GSoC, and here are my plans for the first week.

As mentioned in my proposal, I will be starting off with the Pilot a Submarine activity. In this week, I will be focusing on the tutorials and the basic structure of the levels of the activity as follows (may be subject to change, depending on feedbacks):

• There will be 10 levels approximately in the activity, in 3,4,3 format (first 3 = beginner level, next 4 = intermediate and last 3 = challenging)
• The initial levels will be tutorial levels. It will be mostly used to explain the various components of the submarine: the enigne, rudders and the air tanks. This will take up the 3 basic levels, with each of the components being explaned in each of the first three levels.
• The intermediate level will mostly contain items like obstacles and jewels in the form of pickups to increase the difficulty curve of the levels
• The final challenging levels (the number of levels of this types may be reduced to one, depending on the difficulty) will require the player to react a bit faster, the “gate” (from the original “Pilot a Submarine” activity) will be closing instead of opening and the player will need to complete the level before the gate closes, thus require the player to act faster compared to that of the previous intermediate levels.
• If time permits me, I will move on to implement the functionalities of the submarine using box2d. Also, I will be looking forward to improving the controls of the submarine to make it more intuitive for the children to understand. Any suggestions regarding it is always welcome!

More in depth on the progress of the implementation and mockups of the levels will be posted in the blog, as the work progresses.

For any feedbacks related to the plans, feel free to contact me regarding it:

• Email: rudra.nil.basu.1996@gmail.com
• Freenode IRC nick: rudra / rudra_

Following blog post from Patrick Griffis about new themes support in Flatpak, we started working on supporting this new feature too. Currently wherever you start a Qt application, it would always look like a KDE application or something would be missing, like icons so you would end up with bad experience and mixed feelings. This is going to change now as we now support Gnome in form of icons, widget style and Qt platform theme and with this, when you run a Qt application in Gnome, it will look definitely better and more natively than before. We packaged regular adwaita icons which are used by default in Gnome as extension of freedesktop runtime. For widget style we use adwaita-qt style, which is a Qt style attempting to look like Gtk’s adwaita and the most important part putting this all together is QGnomePlatform, a Qt platform theme which reads your Gnome configuration and applies it to running Qt applications. QGnomePlatform also enforces Qt apps to use adwaita icons and adwaita-qt style by default so that’s another reason why it is important. Both adwaita-qt and QGnomePlatform projects are by the way authored by Martin Bříza, a collegue of mine from Red Hat so if you meet him in person somewhere buy him a beer for that he cares about Qt integration in Gnome :). Now coming to a question how to install this and make it work. Basically all you need to do is install following extensions and you shold be done:

flatpak install kderuntime org.freedesktop.Platform.Icontheme.Adwaita
flatpak install kderuntime org.kde.KStyle.Adwaita
flatpak install kderuntime org.kde.PlatformTheme.QGnomePlatform

Your Qt apps running in flatpak should then automatically pick up all of these extensions without any further modification, same way it does automatically when you run it outside the sandbox. Simply done!. I’m also aware that there are more Gtk themes, like adwaita-dark or high-contrast, both are also available in form of Qt style and we will probably package them later, but at this point it is mostly proof of concept that this can be done and works nicely. You can follow our wiki page if you want more information about runtimes, repository with applications and so on and from me it’s all for now.

Btw. below you can see okular running in flatpak and using adwaita-qt style with adwaita icons.

Hi everyone, is everything ok? I hope so.

Today, I will talk about my week working on Krita during this community bonding period that ends this Wednesday.

I will try to be more concise this week and I will explain what I've made in a short list.

1. Unit tests to Python scripting API

I made previously, the integration of python tests with cmake. Now, I implemented tests to all classes that don’t need a GUI to work, at least partially. I wrote tests to classes below:

• Action
• Filter
• InfoObject
• Extension

When you implement tests, you naturally find errors. I found some inconsistencies that I fix, but I need to understand others behaviors, like setConfiguration method in the Filter class.

Reviews(D5967 and D5982) created and commits pushed to my remote branch.

2. Improve Scripter plugin

As I told in my introduction for GSOC, I'm intending to use the Scripter to execute and edit scripts.

When I started to work in this plugin, we was using the exec function(python 3) in python to run all the code from the editor, but it's really more complex to implement and maintain the scripter using exec, mainly when using files where we can create classes and all.

Now the implementation creates a python module to refer to files, but the Scripter still using exec when the code is executed without saving files. You can see a peace of code below:

if document:
    spec = importlib.util.spec_from_file_location("users_script", document.filePath)
    users_module = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(users_module)
    users_module.main()
else:
    code = compile(script, '<string>', 'exec')
    empty_scope = {}
    exec(script, {})

If you need more details about my reasons to take this decision please read this comment in the task thread.

3. Krita community

• I’m following other tasks in the Krita to know what people have made.

• Talking with my mentors to understand some important implementations.

• Reading documentation to libkiss. Thanks, Wolthera :).

That’s it for now, until the next week. See ya!!

The KDE Continuous Integration system builds KDE software from scratch, straight from the git repositories, and usually from master (or whatever is considered the development branch). It’s been building for Linux for a long time, and has recently been expanded with FreeBSD servers as well. KDE sysadmin has been kind enough to provide two more VMs (with some more compiling “oomph”) so that we can keep up better, and the CI has just been expanded with all of the Plasma products. That means we’re now building KDE Frameworks, and the Plasma desktop.

Results are still in the sandbox, but will eventually end up in the maiin CI.

Frameworks are all blue (good) or yellow (not-quite-good .. but I can’t really tell what Jenkins’ criteria are for making something yellow). Plasma is now in-progress: what we’re trying to do is merge as much as we can from FreeBSD ports to upstream, so that code only needs maintainence once. Today’s small fix is dealing with PAM, where Linux has pam_syslog() defined in the library, and FreeBSD does not.

KDevelop 5.1.1 released

A new stable release for KIO GDrive is now available, version is 1.2.0. The main change is the integration with Plasma/KAccounts. Have a look at my previous post for more details.

You can find the link to the source code in the wiki page: https://community.kde.org/KIO_GDrive

Enjoy!

LaKademy 2017 group photo

Some weeks ago we had the fifth edition of the KDE Latin-America summit, LaKademy. Since the first edition, KDE community in Latin-America has grown up and now we has several developers, translators, artists, promoters, and more people from here involved in KDE activities.

This time LaKademy was held in Belo Horizonte, a nice city known for the amazing cachaça, cheese, home made beers, cheese, hills, and of course, cheese. The city is very cosmopolitan, with several options of activities and gastronomy, while the people is gentle. I would like to back to Belo Horizonte, maybe in my next vacation.

LaKademy activites were held in CEFET, an educational technological institute. During the days of LaKademy there were political demonstrations and a general strike in the country, consequence of the current political crisis here in Brazil. Despite I support the demonstrations, I was in Belo Horizonte for event. So I focused in the tasks while in my mind I was side-by-side with the workers on the streets.

Like in past editions I worked a lot with Cantor, the mathematical software I am the maintainer. This time the main tasks performed were an extensive set of reviews: revisions in pending patches, in the bug management system in order to close very old (and invalid) reports, and in the task management workboard, specially to ping developers with old tasks without any comment in the last year.

There were some work to implement new features as well. I finished a backends refactoring in order to provide a recommended version of the programming language for each backend in Cantor. How each programming language has its own planning and scheduling, it is common some programming language version not be correctly supported in a Cantor backend (Sage, I am thinking you). This feature presents a “recommended” version of the programming language supported for the Cantor backend, meaning that version was tested and it will work correctly with Cantor. It is more like a workaround in order to maintain the sanity of the developer while he try to support 11 different programming languages.

Other feature I worked but it is not finished is a option to select different LaTeX processors in Cantor. Currently there are several LaTeX processors available (like pdflatex, pdftex, luatex, xetex, …), some of them with several additional features. This option will increased the versatility of Cantor and will allow the use of moderns processors and their features in the software.

I addition to these tasks I fixed some bugs and helped Fernando Telles, my past SoK student, with some tasks in Cantor.

(Like in past editions)², in LaKademy 2017 I also worked in other set of tasks related to the management and promotion of KDE Brazil. I investigated how to bring back our unified feed with Brazilian blogs posts as in the old Planet KDE Português, utilized to send updates about KDE in Brazil to our social networks. Fred implemented the solution. So I updated this feed in social networks, updated our e-mail contact utilized in this networks, and started a bootstrap version of LaKademy website (but the team is migrating to WordPress, I think it will not be used). I also did a large revision in the tasks of KDE Brazil workboard, migrated past year from the TODO website. Besides all this we had the promo meeting to discuss our actions in Latin-America – all the tasks were documented in the workboard.

Of course, just as we worked intensely in those days, we also had a lot of fun between a push and other. LaKademy is also a opportunity to find old friends and make new ones. It is amazing see again the KDE fellows, and I invite the newcomers to stay with us and go to next LaKademy editions!

This year we had a problem that we must to address in next edition – all the participants were Brazilians. We need to think about how to integrate people from other Latin-America countries in LaKademy. It would be bad if the event become only an Akademy-BR.

Filipe and Chicão

So, I give my greetings to the community and put myself in the mission to continue to work in order to grown the Latin-America as an important player to the development and future of KDE.

Its been some time since I’ve posted any progress for AtCore. Some may wonder what we have been up to ..

• Implimented a Comand Queue

We would like to get some info from the printer while printing we need to have some method of flow control. AtCore now uses a command queue to send all commands. With the command Queue in place we have to handle stop and Emergency stop differently . For example Emergency Stop should skip the queue and be sent as soon as the button is pressed.

• Requesting Temperatue from the printer

After you connect to a FW plugin every 5 seconds a m105 will be send to the printer and the temperature results are put onto a pretty graph that Patrick made. In order to make the graph work we need read the M105 return and extract the data from it. While our current methods of parsing this info work its very specific to each firmwares return . Since these string can be differnt between fw versions it can crash so we are working on a way to do this better.

• Cleaned up the test Client Gui

The test clients GUI needed some love. All the widgets now live within a dock and the docks can be arranged how ever the user likes. I’ve also added a status bar to show the status of AtCore. We’ve also added a print job timer and remaining print time estimate. A Seperate axis control for relative was asked for by a user and I’ve added one that Lays wrote some time ago . It works well and allows for movements on 1, 10 or 25 units

• Fixed the windows build so that It builds and deploys correctly via craft

Lays has been working hard to get atcore buildable via craft. Now we can build and deploy AtCore (and testgui) from craft. After building we had a problem of not finding the plugins on windows and them not deploying to the correct path.I added some instructions for deploy and tweaked plugin detection on window. Everything is now working well.