Skip to content

Monday, 29 July 2019

Hello static site...

I've been writing really nothing on my previous blog, and the whole Wordpress install was too much overkill, besides doing a static website in python sounds way better to a programmer ;-)

So, i'm using Pelican and plan to revert back all my customizations that make sense.

And of course

I'm going to Akademy 2019

Saturday, 27 July 2019

Sprints are a great time to talk in real-time to other project developers. One of the things we talked about at the KDE Connect part of the “Nuremberg Megasprint” was the problem that our current discovery protocol often doesn’t work, since many networks block the UDP broadcast we currently use. Additionally, we often get feature requests for more privacy-conscious modes of KDE Connect operation. Fixing either of these problems would require a new Link Provider (as we call it), and maybe we can fix both at once.

A New Backend

First, let’s talk about discovery. The current service discovery mechanism in KDE Connect is we send a multicast UDP packet to the current device’s /24 subnet. This is not ideal, since some networks are not /24, and since many public networks block packets of this sort. Alternatively, you can manually add an IP address which then establishes a direct connection. Manual connections work on many networks with block UDP, but it is a bit of a hassle. Can we find a better way to auto-discover services?

A few months ago, a user named rytilahti posted two patches to our Phabricator for KDE Connect service advertisement over mDNS (aka avahi, aka nsd, aka …). The patches were for advertisement-only (it still doesn’t establish a connection) but they were a good proof of concept to show that mDNS works on many institutional networks which block UDP multicast since mDNS is frequently used for other things like network printer discovery which are desired by those institutional networks.

I would post a screenshot here, but I don’t want to spread details of an internal network too far 🙂

At the sprint, we talked about whether we would like to move forward with these and we decided it was useful, so Albert Vaca and I put together two proof of concept patches to start trying to establish a connection using mDNS advertisements:

The patches are not yet fully working. We can both see each other and attempt to establish a connection but then something goes wrong and one of them crashes. Given that this was less than 8 hours of work, I would call this a success!

There is still plenty to do, but it was very helpful to be able to sit in-person and talk about what we wanted to accomplish and work out the details of the new protocol.

More Privacy

Before we talk about privacy, it helps to have a quick view of how KDE Connect currently establishes a connection:

  • As described above, both devices send a multicast UDP packet. This is what we call an “Identity Packet”, where each device send its name, capabilities (enabled plugins), and unique ID
  • If your device receives an identity packet from a device it recognizes, it establishes a secure TCP connection (if both devices open a connection, the duplicate connection is handled and closed)

As long as we are talking about a new backend, let’s think about ways to make KDE Connect more privacy-conscious. There are two problems to address:

  • Device names often contain personal information. For instances “Simon’s Phone” tells you that “Simon” is around
  • Device IDs are unique and unchanging. Even assuming I rename my phone, you can still track a particular device by checking for the same ID to show up again and again

Solving the first problem is easy. We want the user’s device name so we can display it in the list of available devices to pair with. So, instead of sending that information in the identity all the time, have some “discovery mode” switch which otherwise withholds the device name until a connection to an already-trusted device is established.

This leaves the second problem, which quite a bit more tricky. One answer is to have trusted user-selected trusted wifi networks, so KDE Connect doesn’t broadcast on a random wifi that the user connects to. But what if I connect to, say, my university network where I want to use KDE Connect but I don’t want to tell everyone that I’m here?

We don’t have a final answer to this question, but we discussed a few possible solutions. We would like some way of verifying ourselves to the other device which conceals our identity behind some shared secret, so the other device can trust that we are who we say we are, but other devices can’t fingerprint us. It is a tricky problem but not yet one to solve. Step 1 is to get the new mDNS backend working, step 2 is to add advanced features to it!

Friday, 26 July 2019

Okay, good news today. I have been porting DefaultTool to the new node-replacing system and it is working now, finally, at least for the part I have already done.

The work involves combining a number of different modules in Krita: the stroke system, KoInteractionTool and its interaction strategies, and, well, the COW mechanism in Flake.

KoInteractionTool is the class used to manage the interaction with vector shapes, and is subclassed by DefaultTool. The behaviours of KoInteractionTool (and thus DefaultTool) are defined by KoInteractionStrategys. Upon the press of the mouse button, DefaultTool creates an instance of some subclass of KoInteractionStrategy, say, ShapeMoveStrategy, according to the point of the click as well as keyboard modifiers. Mouse move events after that are all handled by the interaction strategy. When the mouse is released, the interaction strategy's finishInteraction() is called, and then createCommand(). If the latter returns some KUndo2Command, the command is added to the undo history. Till now it sounds simple.

So how does the stroke system come in? I have experimented the interaction strategy without the stroke system (https://invent.kde.org/tusooaw/krita/commit/638bfcd84c622d3cfefda1e5132380439dd3fdc2), but it is really slow and even freezes Krita for a while sometimes. The stroke system allows the modification of the shapes to run in the image thread, instead of the GUI thread. A stroke is a set of jobs scheduled and run by a KisStrokesFacade (here, KisImage). One creates the stroke in a strokes facade using a stroke strategy, which defines the behaviour of the stroke. After creation, jobs can be added to the stroke and then executed at some later time (it is asynchronous).

So combining these two, we have an interaction strategy and a stroke strategy -- when the interaction strategy is created, we start the stroke in the image; when there is mouse move, we add individual jobs that change the shapes to the stroke; when the mouse released, we end the stroke. My discussion with Dmitry firstly tended to make the interaction strategy inherit the stroke strategy but later it proves not a viable solution since the interaction strategy is owned and deleted by KoInteractionTool while the stroke strategy is owned by the stroke --- which will lead to double deletion. So we divide it into two classes instead: the interaction strategy starts the stroke, and the stroke strategy takes a copy of the current active layer upon creation; when handling mouse move events, a job is added to the stroke to modify the current layer; finally when the interaction finishes, the interaction strategy ends the stroke and creates an undo command if the layer has been changed.

A problem I found lies in the final stage--if the mouse is released as soon as being pressed and no undo command is created, Krita will simply crash. It does not happen when I use gdb to start Krita so it seems to be a timing issue though it leads to difficulty for debugging as well. Dmitry used a self-modified version of Qt to produce a backtrace, indicating the problem probably lies in KisCanvas2's canvasUpdateCompressor, which is not thread-safe. However, after I changed it to KisThreadSafeSignalCompressor, the crash still happens, unfortunately.

The final inspiration comes from the comments in KisThreadSafeSignalCompressor, though. It indicates we cannot delete the compressor from other threads --- we have to use obj->deleteLater() instead, since it lies in the gui thread. And aha, that is the problem. The stroke strategy's destructor is executed in the image thread; if the undo command is not created, there is only one reference to our copied KisNode, namely in our stroke strategy, so it has to be destructed there. However, upon the creation of the KisNode, it is moved into the gui thread. So it simply means we cannot let it be deleted in the image thread. The solution looks a little bit messy, but it works:

1
2
3
4
5
KisNode *node = m_d->originalState.data(); // take the address from KisSharedPtr
node->ref(); // prevent KisSharedPtr from deleting the node
m_d->originalState.clear(); // now node is not being referenced by any KisSharedPtr
node->deref(); // the reference count is now zero again
node->deleteLater(); // it will be deleted by the event loop, later

Tuesday, 14 May 2019

Hello, my name is Sharaf. My nick on IRC is sh_zam.

My project is to port Krita to android devices. We've been successful in making the APK, but it only works if I build it, as it requires tweaking qt libraries, a bit. At the moment, my goal is to make the build system fully automatic and spit out the signed APKs for different architectures at the end.

Once I do that, I'll move on to UI, events and other fun stuff!

So, there's a lot to do and learn. Now I will go back to coding. (-:

So, thank you KDE for choosing me and I hope I'll learn a lot from this community!

Friday, 14 October 2016

One afternoon twenty years ago Matthias Ettrich and Martin Konold sat at a stone table in the cafeteria of the university Tübingen and talked computers. They talked Linux and they talked desktop. They talked about making Linux accessible to everyone. This was the moment where KDE was born. This afternoon they walked away with a mission. Matthias went on to write the call to action to found the KDE project, and Martin to create the very first KDE mailing list kde@fiwi02.wiwi.uni-tuebingen.de.


On October 14th 1996 the famous announcement arrived on the newsgroups comp.os.linux.development.apps, comp.os.linux.misc, and de.comp.os.linux.misc:

    New Project: Kool Desktop Environment. Programmers wanted!

The new project quickly attracted a group of enthusiastic developers and they pushed out code with a frentic pace. kdelibs-0.0.1 was released in November, containing the first classes KConfig and KApplication. In May 1997 the young project presented at the Linux-Kongress in Würzburg. In August Kalle Dalheimer published the famous article about KDE in the German computer magazine c't which attracted a whole generation of KDE developers to the project. On Jul 12th 1998 KDE 1.0 was done and released. The community had not only implemented a friendly face for Linux but also a bunch of applications while going, including a full web browser.


KDE did hundreds more releases over the years, continuously improving and maintaining the growing number of applications and amount of code. The community grew. It started to do annual conferences such as Akademy or the Desktop Summits and focused developer sprints such as the Osnabrück or the Randa meetings. KDE e.V., the organization behind KDE, which was founded as partner for the KDE Free Qt Foundation, grew with the community to be the corner stone of the organizational structure of KDE, using German association law as its secret superpower (read more about this in the book "20 Years of KDE: Past, Present and Future").

Millions and millions of people used KDE software over the years. Thousands of people contributed. KDE made appearances in Hollywood movies, it was subject of theses and scientific studies, and it won many awards. KDE's founder, Matthias Ettrich even received the German Federal Cross of Merit. The timeline of twenty years of KDE is an impressive demonstration of what Free Software is able to achieve.


Akademy 2014 group photo by Martin Holec (CC-BY)


KDE also was a breeding ground. Many people started their careers there. Hundreds of students went through mentoring programs such as the Summer of Code or the Season of KDE. Whole projects emerged from KDE, such as ownCloud and its sibling NextCloud, Kolab, or KHTML, which turned into WebKit and then Blink, powering most of web browsers on this planet today.

Today Linux has reached world domination in various, sometimes surprising, ways. KDE has contributed its share to that. With Plasma it provides a slick and powerful desktop which does make Linux accessible to everyone. This mission has been accomplished. But there is more. Following KDE's vision of bringing freedom to people's digital life there are amazing projects exploring new areas through Free Software, be it an application such as Krita to bring freedom to digital painters, or a project such as WikiToLearn to create collaborative text books for education. When KDE people meet you can feel the enthusiasm, the openness, and the commitment to change the world to the better just as in the days of the beginning.




I joined KDE in 1999 with my first patch to KOrganizer. I wrote a lot of code, maintained and founded applications, served on the board of KDE e.V. for nine years. Most importantly I found a lot of friends. Neither my personal nor my professional life would be what it is today without KDE. I owe a lot to this community. Thank you for the last twenty years.

Friday, 21 August 2015


Update 1: Google Play still not has the newest version, but it is incomming in the following days
Update 2: There is an open beta version now, you can get it from here from Google Play.

Marble Maps has the following features:
  • Wondering around on the map
    • You can move the map with one finger by dragging the map with it
    • It will increase the zoom if you touch double times fast to the map
    • You can also zoom with two fingers (only supported on multitouch devices)
  • Handling your position
    • You can check your position on the map
    • You can check the distance and direction to your position when your position is not visible
    • You can center the view to your position
  • Routing
    • You can plan routes via interactive placemarks, you have to search for something and after that, you can use the result as a waypoint
    • Also, you can modify the route instead of the interactive waypoints with the route editor which is available from the menu

    • To get the routing instructions, visit the menu too
    • You can select from three routing profile: with car, with bike or as a pedestrian
  • Navigation
    • You can navigate on the route what you have planned previously, or you can also navigate to a single destination
    • Marble Maps shows your position on the route with a different icon
    • It provides turn-by-turn based navigation
    • It uses the Text To Speech interface of the Android system to provide voice instructions. To use it, please install it from Google Play
    • It shows the next instruction and its distance too
    • The current speed and the distance to the destination is also visible 

Some techincal background:
Marble's base source code in this summer has become Android compatible. If you want an Android app can be built on the top of it. Any map can be loaded in, and all of the projections are available. It supports some plugins too.




And finally my personal experience about the summer:
I liked to work on this project very much because I have learned a lot of new things, like coding technics, I have got closer to QML and I also have had a deeper insight on how Android applications work. It was also good to work with the people of the community. I would like to thank to everybody who helped me this summer, especially to Dennis Nienhüser and to Torsten Rahn. Without them Marbe on Android would be still a dream.

Thank you Google for this fantastic opportunity!

But the story is not ending here, so stay tuned...