Skip to content

Saturday, 9 November 2019

It's been almost half a year since I mentioned how precompiled headers do (not) improve C++ compile times. Quite a long time, filled with doing other things, life, occassionally working on getting my patch production-ready and, last but definitely not least, abandoning that patch and starting from scratch again.
It turns out, the problems I mentioned last time had already been more or less solved in Clang. But only for C++ modules, not for precompiled headers. *sigh* I had really mixed feelings when I finally realized that. First of all, not knowing Clang internals that well, it took me quite a long time to get to this point figuring it all out, probably longer than it could have. Second, I've been using C++ modules when building Clang itself and while it's usable, I don't consider it ready (for example, sometimes it actually makes the build slower), not to mention that it's non-trivial to setup, not standardized yet and other compilers (AFAIK) do not yet support C++ modules. And finally, WTH has nobody else yet noticed and done the work for precompiled headers too? After all the trouble with finding out how the relevant Clang parts work, the necessary patches mostly border on being trivial. Which, on the other hand, is at least the good news.
And so I'm switching for LibreOffice building to my patched build of Clang. For the motivation, maybe let's start with an updated picture from the last time:
This is again column2.cxx, a larger C++ file from Calc. The first row is again compilation without any PCH involved. The second row is unpatched Clang with --enable-pch=full, showing again that way too large PCHs do not really pay off (here it does, because the source file is large, but for small ones such as bcaslots.cxx shown last time it makes things slower). In case you notice the orange 'DebugType' in the third row that looks like it should be in the second row too, it should be there, but that's one of these patches of mine that the openSUSE package does not have.
The third row is with one patch that does the PerformPendingInstantiations phase also already while building the PCH. The patch is pretty much a one-liner when not counting handling fallout from some Clang tests failing because of stuff getting slightly reordered because of this. Even by now I still don't understand why PCH generation had to delay this until every single compilation using the PCH. The commit introducing this had a commit message that didn't make much sense to me, the test it added works perfectly fine now. Presumably it's been fixed by the C++ modules work. Well, who cares, it apparently works.
The last row adds also Clang options -fmodules-codegen -fmodules-debuginfo. They do pretty much what I was trying to achieve with my original patch, they just approach the problem from a different side (and they also do not have the technical problems that made me abandon my approach ...). They normally work only for C++ modules, so that needed another patch, plus a patch fixing some problems. Since this makes Clang emit all kinds of stuff from the PCH into one specific object file in the hopes that all the compilations using the PCH will need that too but will be able to reuse the shared code instead, LibreOffice now also needs to link with --gc-sections, which throws away all the possibly problematic parts where Clang guessed wrong. But hey, it works. Even with ccache and Icecream (if you have the latest Icecream, that is, and don't mind that it "implements" PCHs for remote compilations by simply throwing the PCH away ... it still pays off).
So, that it's for a single compilation. How much does it help with building in practice? Time for more pretty colorful pictures:

This is a debug LO build on my 4-core (8 HT) Ryzen laptop, Library_sm is relatively small (36 source files), Library_scfilt is larger (154 source files). Plain 'Clang' means unpatched Clang(v9), 'Clang+' is with the PerformPendingInstantiations patch (i.e. the third row above), 'Clang++' is both patches (i.e. the fourth row above). The setting is either --enable-pch=base for including only system and base LO headers in the PCH, or --enable-pch=full for including everything that makes sense. It clearly shows that using large PCHs with GCC or unpatched Clang just doesn't make sense.
Note that GCC(v9) and MSVC(v2017) are there more as a reference than a fair comparison. MSVC runs on a different OS and the build may be possibly slightly handicaped by some things taking longer in Cygwin/Windows. GCC comes from its openSUSE package, which AFAICT is built without LTO (unlike the Clang package, where it makes a noticeable difference).
And in case the graphs don't seem impressive enough, here's one for Library_sc, which with its 598 source files is too big for me to bother measuring it in all cases. This is the difference PCHs can make. That's 11:37 to 4:34, almost down to one third:
As for building entire LO from scratch, it can be like in the picture below (or even better). The effect there is smaller, because the build consists of other things than just building libraries, and some of the code built doesn't use PCHs. And it's even smaller than it could be, because I used --enable-pch=base, as that's what I've been using up to now (although now I'll switch to a higher level). That's about 1h42m without PCHs to 1h14m with unpatched Clang (27% percent saved), and 1h06m with patches (and the 8minutes difference is still 11% of the unpatched time). Not bad, given that this is the entire LO build. Those 6 minutes for ccache are there to show the maximum possible improvement (or rather nowhere near possible, since the compiler normally still has to do the work of actually compiling the code somehow).
In case you'd want to use this too, that's not up to me now. The patches are now sitting and waiting in the LLVM Phabricator. Hopefully somebody there still cares about PCHs too.

![](https://i.imgur.com/UK3LZp2.png “digiKam 6.4.0-01) Dear digiKam fans and users, We received a lot of excellent user feedback after publishing the 4th digiKam 6 release in September 2019. We are now proud to briefly announce the new digiKam 6.4.0, a maintenance version which consolidates this feedback and acts as an important phase of this 3-year-old project. The Plugins Interface “DPlugins” Extended Again With 6.1.0, digiKam project has introduced the new DPlugins interface to customize and extend the application.
Another month, another revision of the digiKam Recipes book. This version brings the following new content: The How digiKam works chapter provides an overview of digiKam’s achitecture The Export and import keyboard shortcuts scheme section explains how to export and import customized keyboard shortcuts profiles. All digiKam Recipes readers will receive the updated version of the book automatically and free of charge. The digiKam Recipes book is available from Google Play Store and Gumroad.

Friday, 8 November 2019

KStars v3.3.7 is released for Windows, MacOS and Linux. This late autumn release packs a lot of new features and fixes across the board.

ASTAP integration


ASTAP is an astrometric plate solver, stacking of images, photometry, and FITS Viewer application available for Windows, MacOS, and Linux on multiple architectures.

KStars included support for solving via ASTAP in the Align module in addition to the existing astrometry.net solver. ASTAP employs a different method to solve images making it extremely fast  while at the same time requiring a smaller star catalog compared to other astrometric solvers.

You need to download and install the G17 Star Catalog for ASTAP to work locally.

ASTAP Solver

The error reporting was improved to show the overall error in arcsec. Furthermore, the Align module initial FOV is calculated from the camera and telescope parameters (no longer default to 0x0'). This make the initial solve with a wider search radius faster compared to a blind solve. Once the exact FOV is measured, the search radius is reset to the default value to expedite subsequent searches.

Observatory Weather


Wolfgang Reissenberger continued his outstanding work on the observatory module by adding a dedicated weather widget with live plotting for each parameter.


FITS Enhancements


Hy Murveit contributed further improvements to the FITS loading mechanism which resulted in speed ups during sequence capturing.

When capturing images, previously once the capture was complete, images were written to disk, then read back, then displayed in the fits viewer (if enabled), and finally the next image could be captured. This delayed the next capture by a few seconds.

With this change, the FITS data is displayed using (a copy of) the INDI blob sent to INDI::CCD, a memory buffer, and the FITS data is written to disk on a separate thread, which does not block the next capture nor the display of the INDI data.

Focus Module


Eric Dejouhanet Fixed HFR calculation in the FITS Data class, which was accumulating integer instead of double values.

This led to incorrect consolidation of HFR over multiple stars in the focus procedure and incoherent results in full-frame mode.


The UI received an overhaul as well to make the various settings more accessible. Each detected star HFR is now displayed next to it.

Scheduler Updates


Eric Dejouhanet implemented customizable dusk and dawn offsets (D23869). This introduces two new Ekos options, located in the Scheduler option pane. Dusk (resp. dawn) offset will apply a positive or negative hour offset to today's astronomical dusk (resp. dawn) when scheduling observation jobs.
The dawn offset and the pre-dawn offset are cumulative, but the dawn offset allows an earlier or later dawn to be used both while scheduling and executing.

The resulting dusk-to-dawn interval is displayed in the Scheduler UI on the right side of the Twilight checkbox. If the Twilight restriction is checked, the modified dusk and dawn values will be used to schedule the observation job to night time.

If the Twilight restriction is not checked, the observation job will not depend on night time and the modified dusk and dawn will be ineffective in scheduling that job.

The dusk and dawn offsets can be modified from the Ekos Scheduler options, and the night time interval displayed in the Scheduler UI will be updated when applying the changes in that dialog.

Additionally, if the Scheduler is not running, jobs will be re-evaluated to take the new dusk and dawn values into account. However, jobs will only effectively update their schedule if the night time constrain them to do so, not if the night time restriction relaxes.

Guiding & PHD2 improvements


Robert Lancaster improved PHD2 integration with Ekos.

This update is intended to fix several PHD2 problems and provide several PHD2 enhancements.


Fixes an issue where if the user hits the stop button while guiding in the PHD2 interface, then the user restarts guiding from PHD2, Ekos did not pick up the guide state change since no settling occurred and the user didn't click guide in Ekos.
Fixes an issue where the guiding data was not put into the graphs if the user did not enter a focal length into PHD2. Formerly the solution was to put a warning in the Guide log, but users ignored that. Now this tries to set the current CCD, so the backup method can work the way it was intended to work.
  1. Fixes an issue when the user had external guide frames selected, they did not appear in the guide view, and instead loaded in the fits viewer.
  2. Enables the loop and capture buttons for PHD2 along with the corresponding functions to make them work. Works well if the camera is connected to Ekos, also works if its not, but it will not display in Ekos. A message prints to the log letting the user know why.
  3. Disables the binning combo box which was enabled accidentally.
  4. If the user has external guide frames enabled, this enables the tracking box so that the lock position in the image can be reported to the user, and it also enables the user to be able to click to change the lock position for PHD2.
  5. This improves Ekos's ability to recognize the guide camera by using PHD2's report of what guide camera it is using. Then Ekos can use this information to disable or enable the receipt of image frames as well as the option to use the SubFrame checkbox.
  6. Improves the communication about the various options and status for cameras connected to PHD2 and Ekos.
  7. Enables the SubFrame method for PHD2 cameras so that they can switch quickly back and forth between the Guide Star image and full frame external guide frames at the push of a button.
  8. After I cleaned up some of the old and no longer needed methods/code, Ekos now connects to PHD2 much faster.
  9. I added the option for the user to select autostar, or to have PHD2 use the star lock position chosen by the user.
  10. Removes the External Guide Frames option since this makes it obsolete
  11. Saves the subframe option between KStars sessions and sets Ekos to receive External Guide frames or not based on it.
  12. Removes all the setting and unsetting of external blobs for Linguider, which doesn't support INDI cameras anyway, so it was pointless.
Furthermore, the guiding module now shows directional guiding label to help see which directions are affected by the pulses.

Misc Enhancements & Bug Fixes


+ Added download time estimation to the capture module. (D25138)
+ Solved several issues with guiding & dithering in both capture & scheduling. (D25110, D25105)
+ Fixed gain setting in capture module. (D24417)
+ Fixed focus HFR-averaging issue. (D24352)
+ Connect Scheduler sleep timer to Simulation Clock scale change. (D24151)
+ Handling of aborts during parking/unparking of rolloff roofs corrected. (D24064)
+ Hitting a constraint sets a job to IDLE instead of COMPLETE so that it might be restarted later. (D24232)
+ Update OpenNGC to v20191019 (D24896)

Wednesday, 6 November 2019

At the 2019 Libre Graphics Meeting, illustrator Livio Fania presented a heart-felt plea for more professionalism in libre graphics.

And that was the moment I began to think a bit. What is it that makes one project professional, and another not? Where, in this case, I’d take “professional” to mean “someone can depend on it so they can earn their daily bread with no more than the problems you always have with any software, because all software sucks, and hardware even more so”.

As Livio said in his presentation, funding makes a difference. If a project can fund its development, its continuity will be better, it will be better able to implement its vision and deliver what it promises, simply because funding equals time. That’s also what I tried to argue in my previous blog post.

In practice, it’s very hard to find funding for applications that that people do not earn their income with. Of course, there are very accomplished free and open source video players, editors or file managers. Those tend to be still completely volunteer-driven and very underfunded. And there’s a reasonably successful web-browser, which is actually funded quite well — but it’s funded to avoid Google being broken up as the monopolist that it is, mainly by Google.

And of course, there are applications that people use daily, earn their bread with and that are completely unfunded, even if they have donation buttons and money in the bank: GIMP, Inkscape, Scribus, various RAW photo applications, often by choice. This means that those projects are even more squeezed for time than a project like Krita. Just think how much difference Tavmjong Bah would make if he could be funded to work on Inkscape full-time! Tav gets $107 a month through Patreon… (Which I contribute too.)

But though Livio focused on the need to get funding to accelerate development, and it’s the first step, there’s more to creating a professional application.

The second step is: focus on the user’s needs. That starts with knowing what you want to create. If your goal is to implement a standard specification fully, as is the case with Inkscape, then is that goal sufficiently user-oriented to form the basis for an application designers can earn their daily bread with? It’s possible, but it’s something to always be aware of.

And like I argued recently, is looking inward, discussing the where’s and why’s of Free Software, no matter how enjoyable, not taking away time better spent getting to know your userbase, their needs and… The competition.

I would not be surprised if visiting the Linux Application Summit next would be less useful for Krita and its users than a week long training in Photoshop would be for me, as the Krita maintainer. We’ve all been there: we’ve all claimed we’re not competing with the big, sovereign, proprietary applications that are seen as a standard in the field where our application is the “open source alternative”.

But if you don’t compete, you cannot win. And if you don’t win, then millions of users will not use free and open source software. And I happen to believe that software freedom is important. And I’m slowly gaining the confidence to say: I am competing.

(And we are. Competing. Otherwise Adobe wouldn’t have been adding so many new features for painters and illustrators to their latest Photoshop release, some of them features Krita has had for a decade.)

And when we compete, which makes people trust us, and when our user fund our efforts, then we need to take another step towards professionalism.

That is, committing to continuity. I’ve always said “free software never dies”, but it does. Look at Amarok, which is thoroughly dead. Of course, Krita has been released since 2004, and there’s quite a bit of continuity already. But this does take commitment, which also needs to be public.

Finally, there’s the point where as a full-time project member, as the project maintainer, can no longer say “We don’t provide binaries. Get the source and build it, or wait for a distribution”. You have to provide your application in a form your users can use directly; it’s their time you’re telling them to use for something they don’t earn money with, if you ask them to build.

And then… We have to stop making excuses. Which is probably the hardest thing, because all software sucks, and all code sucks, and sometimes it’s impossible to fix a bug in Krita, because it’s in the OS, the Window manager or the development platform. Or the tablet driver, oh dear, the tablet drivers. But it’s your customer, your supporter, the person who depends on your work to earn their money who is stopped from doing that. And suddenly workarounds and hacks become necessary.

So, funding a core team of developers is the start, focusing on the field instead of the free software community, a will to compete, providing continuous improvement, making sure your software can be used and finally, not making up excuses if there are problems but fixing them.

Tuesday, 5 November 2019

We’re in autumn for a little while now and not quite winter yet… It’s time for another post about KDE PIM! I’ll be your host to cover September and October and will try to follow in the footsteps of my peers who did a great job the past few months. Unlike Franck, I won’t start with the stats though, you’ll get that at the end. Is it obvious that I’m trying to make sure the stats addicts read through. ;-)

Akademy

As you might have noticed, lots of us gathered to Milano for Akademy. Lots happened there regarding KDE PIM. It was partly covered in Volker’s post about Akademy 2019 already, but it’s good to highlight a few things.

One of the most important events there is the increasing collaboration with the Plasma Mobile team, which shows in the Plasma Mobile Akademy 2019 recap. This is to be expected in some way, after all, lots of your Personal Information Management happens on mobile these days, it’s a natural match between those two teams.

This leads among other things to Dan’s work on KAccounts integration in KDE PIM. You can see how the prototype works in the video below, it shows a Google Account integrated with KOrganizer and KAddressBook and controlled from the Online Accounts settings:

KDE Itinerary

Per usual this one is covered separately in its own series by Volker:

GUI Fixes

From Volker again, we got lots of small fixes all over the place about icon and icon size. It was motivated by preparing for KF6 work but it turns out quite nice for high dpi users as well.

KMail

Volker made the actions of the itinerary plugin for KMail easier to discover. It looks quite nice now:

KMail Itinerary Plugin

In the meantime, Laurent has been working on three new features for the next release!

First, if you ever hit send too quickly and then regretted it because you forgot to finish a sentence or such, you’re going to love this. We have the “Undo Send” feature which got introduced. This allows to define a delay before an email gets really sent. During that delay you then get a notification which allows you to cancel sending.

Undo Send Notification

Second, Laurent introduced the “Quick Text” plugin which improves snippet support. This enables the user to have variables for most fields which are usable in snippets. Later on when the snippet is inserted in the composer, all these variables will automatically match the corresponding fields (date, name, from, etc.).

Quick Text

Third, a nice feature regarding security and privacy. DKIM support is implemented straight in KMail. This allows your beloved mail client to verify that an email was really sent by the mail server it’s supposed to.

DKIM valid DKIM invalid

And of course, there’s been Laurent’s usual activity on fixing bugs, removing the use of deprecated functions and preparing to port to KF6.

Frameworks

This is the big news, some parts of KDE PIM are now in KDE Frameworks!

In particular, KCalendarCore and KContacts finally landed there and are introduced publicly in KDE Frameworks 5.63. This will definitely help users which are not part of KDE Application release which were forced to have dependencies on PIM (Plasma Mobile and Zanshin come to mind but there are more).

The next target to end up in KDE Frameworks is KDAV. The work started on it, mainly focusing on ABI stability, reducing the public link interface and adding fixes in KIO (where they belong) instead of working around them within KDAV. Also very importantly: the agreement to relicense to LGPL has been reached, so the remaining non LGPL parts can be adjusted.

Indirectly related, Dan has been cleaning up the API of KAsync which is not used a lot yet but will get more important in the future. Indeed there are plans to introduce an easier to use Akonadi client API which would depend on KAsync. Stay tuned!

Community Analytics?

So, I’ve been in a long hiatus regarding my community data analytics posts (or any posts for that matter). Some of you might wonder… is it gone? Will he ever do any colored blobs again? Fear not my friends, the opportunity was too nice, here comes your fix of data visualization.

A big shout out to all those who participated in KDE PIM work the past couple of months. Thanks a lot! It’s a very important job you’re all doing, they know who they are, but here is the activity graph of the past two months, so now everyone know who they are (offer them drinks if you get the chance!):


In the past two months, we had 25 different developers on KDE PIM. And of course, since my data is coming only from git, this unfortunately misses people who helped with bug reports, docs, design etc. Whatever your contribution you can be all proud!

I’m using the opportunity to point out an unsung hero of KDE PIM: David Jarvie! This man has been around longer than I remember, and you can see he’s still fairly active.

Now, how does the code contributor network looks like?


Unsurprisingly the two most influential ones are Volker and Laurent. You can also see three extra persons fairly central to the network: Yuri Chornoivan, David Jarvie, David Faure and Friedrich W.H. Kossebau. All those people have their hands in many pies and that’s very much needed.

You might also notice disconnected nodes in the graph. I often make the mistake to not talk much about those in my posts… But it doesn’t mean they’re not important! For an healthy open team you need some of those less connected nodes: they tend to come and go while focusing for a short time on less noticeable issues. It is very important for our users to get a nice experience in the end.

In the end, what I like about this graph in KDE PIM is that we get something relatively well balanced in term of very connected nodes and much less connected nodes.

How You Can Help

Next time, your name could be in visualizations like the ones above!

Check out the KDE PIM Development wiki and find out how to be part of something that matters. If you want your share of this or need help to get started, feel free to contact us #kontact and #akonadi IRC channels on Freenode.

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

Monday, 4 November 2019

KDevelop 5.4.4 released

We today provide a bugfix and localization update release with version 5.4.4. This release introduces no new features and as such is a safe and recommended update for everyone currently using a previous version of KDevelop 5.4.

You can find the updated Linux AppImage as well as the source code archives on our download page.

ChangeLog

kdevelop

  • Fix copyright date display in About KDevelop/KDevPlatform dialogs. (commit. fixes bug #413390)
  • FindClang.cmake: also search LLVM version 9. (commit)
  • Clang: Workaround for empty problem ranges at start of document. (commit)

kdev-python

No user-relevant changes.

kdev-php

No user-relevant changes.

kossebau Mon, 2019/11/04 - 19:02
Category
This week in Krita has been more around features, rather than bug fixing. We had around 18 bug reports but at the same time 18 bugs were fixed too. We can now import jpeg2000 files into Krita.

Sunday, 1 September 2019

Now it’s the end of Google Summer of Code 2019. As my GSoC project, the port of KDE Connect on macOS has made great progress. You can find and download it in my blog release page.

Note: This post aims at presenting the features of KDE Connect which have been implemented on macOS. If you’d like to know more information, such as compilation of your own KDE Connect binary on macOS, please turn to another post in my post Connect your Android phone with your Mac via KDE Connect. And if you’re interested in what I’ve done during Google Summer of Code, my status report of Google Summer of Code is HERE.

Features

In this chapter, I’d like to give you a preview of all features, as well as how to configure to make some of functions work.

Launch KDE Connect

First, we can click on KDE Connect application - the kdeconnect-indicator.app to open it.

Then, we can open KDE Connect configuration window from the indicator in the tray bar of macOS.

As you can see, this is the main page of KDE Connect. All available plugins are here, you can enable/disable or configure them. In addition, available devices will be listed on the left, you can choose them to pair/unpair with them/it.

Functions

Pair notification

When you pair from your Andoid Phone, you should be able to receive a notification that shows the pair request. You can accept or reject it in the KDE Connect configuration window, or you can do it with KDE Connect indicator tray icon, there would be an entry for the pair request as well.

Otherwise, if you change the notification type of KDE Connect to alert in the system preference, you should also be able to do a quick action with the notification itself. Just as I showed in Enable notification plugin in KDE Connect on macOS.

Once paired, you can enjoy your adventure on macOS with KDE Connect!

Clipboard synchronization

The text that you copy on your Mac will be shared to your phone, and those you copy on your phone will be also synchronized to your Mac.

Notification synchronization

With KNotifications support for macOS, you can receive notification from your Android phones and react to them. You can ping your Mac to test whether they are well connected.

Sending file

Sharing your file on your Mac with your Android phone is also a basic feature. You could also send a file from your Android phone, by default, the file will be saved in the Downloads folder in your Mac.

System Volume

You can control the system value of your Mac from your Android Phone remotely.

SFTP

With my SFTP browser, you can browse files in your Android Phone from your Mac, easily synchronize a file.

SMS

Thanks to SMS application of Simon Redman, sending and receiving SMS on your Mac are possible!

Running command

Run command from your Android phone. I believe that using AppleScript, more and more things that KDE Connect can do on macOS, will be discovered, maybe by you!

Mouse and Keyboard

You should be able to use your Android phone as a temporary trackpad and a keyboard. But it needs your permission to allow your Android phone to do it on your Mac. The GIF above shows how to do that.

Others

Except the functions shown above, you can also do these from your Android phone:

  • Keep your Mac awake when your phone is connected
  • Use your phone to control your slides during a presentation
  • Check the battery level of your phone
  • Ring your phone to help find it

And, you may have noticed that, in the screen capture, there are KDE Connect in dark mode and in light mode. Thanks to Qt, we are able to benefit it.

Furthermore, there is no doubt that more functions will be delivered and released in the future. We are all looking forward to them.

Issues

There are some issues that we’ve known and we are trying to fix them.

The released application package isn’t notarized and still has some lirary reference issues. So, it requires you to manually open it, if it’s rejected by Gatekeeper(package validator on macOS), like that showed in the image above.

We’ll try to fix all issues and make a release which you can run it without barricade.

Acknowledgement

Thanks to KDE Community and Google, I could finish this Google Summer of Code project this summer.

Thanks to members in KDE Connect development. Without them, I cannnot understand the mechanism and get it work on macOS so quickly :)

Conclusion

If you have any question, KDE Connect Wiki may be helpful. And you can find a bug tracker there.

Don’t be hesitated to join our Telegram Group or IRC channel if you’d like to bring more exciting functions into KDE Connect:

  • Telegram
  • IRC (#kdeconnect)
  • matrix.org (#freenode_#kdeconnect:matrix.org)

I wish you could enjoy the seamless experience provided by KDE Connect for macOS and your Android Phone!

Tuesday, 14 May 2019

Hello KDE 🔗

Sharaf Zaman sh_zam 15:55 +00:00
Atom
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!