There are quite a few nice talks in the C++ track of Qt Dev Days this year. So many that I don’t expect to move away from that room at all.
I’ll be talking about a fun and clean way to work with asynchronous APIs on Wednesday at the Cafe Moscow in Berlin. I hope I will not get sleepy after lunch.
The talk will be about dealing with asynchronous API using futures (QFuture, std::future, boost::future, QDBusPendingReply…) and continuations. It will be about inversion-of-control, variadic templates, lazy evaluation, functors etc. There will be a few c++11 headache-inducing features demonstrated.
See you in Berlin!
Time to pack my suitcase today. I'll be on a family visit over the weekend and afterwards will head for Berlin where I'll be at the from Monday to Wednesday. All the gearheads around that like to meet in person are welcome to drop me a note (in fact, also non-gearheads, albeit their small number). I especially welcome everyone that brings his or her GPG key fingerprint and wants to cross-sign keys with me.
This year’s GSOC is over. In the last 3 months KDE Connect has grown from a dream to reality. I will not take the money and run away from it now: I’m writting this post to announce that I will keep developing KDE Connect and that I hope other developers will join me to make it an awesome connectivity platfrom!
But that’s not all I want to announce, we have got new features too! The last merge to master included the promised file transfer plugin, renamed as “Share receiver plugin”. The new name makes more sense because it can not only receive files but also text and URLs from any Android app using the ”Share to…” menu. For now this feature is only working from Android to KDE, but support for KDE to KDE and KDE to Android will come soon.
Here you can find a tarball for this version, tagged 0.3. We are not releasing a stable 1.0 version yet, because some things are still broken (like encryption, as you pointed me out in the comments of the last blogpost).
Just a quick heads up that the KDE SC 4.12 Feature Freeze is now 4 weeks away.
Full schedule at http://techbase.kde.org/Schedules/KDE4/4.12_Release_Schedule.
Bugs are a pain, especially when a fiddly one comes along involving Python bindings, the number of people who understand SIP is pretty low. So it's nice we were able to fix it quickly. In the reporter's words:
Can I just say you guys are awesome? I've used KDE with various distributions for years (and with Kubuntu for the last ~2) but never reported a bug until now. I am amazed at how quickly it was acknowledged and came to some form of resolution.
Wish we could do them all that smoothly!
I deployed a new version of KDE Pastebin today – which should be available at paste.kde.org. Here are a few things to note:
- Even though paste.kde.org will redirect you to pastebin.kde.org, the old API is still available at paste.kde.org
- The new API will be available at pastebin.kde.org. Please refer to the API specs here: http://sayakb.github.io/sticky-notes/pages/api/
- Please update your client to use the new API at pastebin.kde.org. If the users that use your client switch to the latest version of your client app, they will end up using pastebin.kde.org behind the scenes. The users who haven’t updated to the latest client app yet will continue using the old API.
- The old API will be deprecated on Jan 31 2014.
- After Jan 31 2014, paste.kde.org will also have the new API endpoints. However, pastebin.kde.org will also exist indefinitely as an alias to paste.kde.org – so you can continue using that URL.
October 2003... I had just gotten my first graphics tablet, a small Wacom Graphire, because I needed to draw a map for the novel I was working on, a map of a battlefield. It seemed a good idea, back then, to do that digitally, for ease of adding and removing layers and so on. However, I wasn't too happy with the way GIMP worked back then, not realizing it was because I wasn't familiar with digital painting at all, not because GIMP's workflow was bad or something like that.
So I started looking for alternatives, and I came across Krita. Krita had gotten its start in 1998, when Matthias Ettrich held a presentation at the 1998 Linux Kongress, which was reported by Michael Wiedman. One of the things he wanted to demo was the ease with which it was possible to hack a Qt gui around an existing application, and the application he choose to demo it with was GIMP (back then it was still called The Gimp, I think). About 1100 lines of code hacked together one evening before the congress started that integrated GIMP into KDE by giving it a KDE compliant user interface: toolbars, statusbar, menubar and made it use the KDE standard dialogs. His goal was to show that there was no reason for any duplication of effort, if a complex application like GIMP can be integrated into KDE with so little effort. KDE was two years old by then and Gnome had just started and the mood was incendiary, so the patch, named kimp, caused a something of a flamefest which left a sour taste in everybody's mouth.
Not satisfied with this situation, people within the KDE project decided to start their own image editor application (although there was some dissension). At that time, there was an application in KOffice called KImage which had been started by Michael Koch, who came up with the name KImageShop, so this can be seen as the earliest forerunner of Krita, was originally written in Qt 1.x, but had been ported to Qt 2.0 in March 1999. The codebase would later be ported to Qt3 and to Qt4!
At the 31st of May, 1999, the KImageShop project officially kicked off with a mail by Matthias Koch. Involved were also Matthias Elter and Daniel Duley (mosfet). Their plans were certainly ambitious! The basic idea back then was to make KImageShop a GUI shell around ImageMagick. (And indeed, until 2004 ImageMagick was a core dependency of Krita.) It was going to be a corba-based application with out-of-process filter plugins, compatible with GIMP plugins, which are also out-of-process, though of course not corba-based. Multiple colorspace support was planned from the outset, though it took until the Krita 1.5 release in 2006 for the project to achieve that goal. (www.koffice.org went through a reorganization in 2009, killing all old content, so this is a link to the svn version of the original announcement.) Some things planned back then still haven't been realized, such as export support for GIMP's xcf file format. Even distributed and multi threaded image filter application was already mentioned!
After an initial spurt of development, the mailing list soon became quiet. The main reason seems to have been that Matthias Elter, Carsten Pfeiffer and the other authors were busy getting KDE 2.0 ready and done. KImageShop started to bitrot and it became hard to compile.
In October 2000, John Califf became the new maintainer. He started with an enormous enthusiasm and energy and quickly make KimageShop at least compilable. During his tenure, KImageShop was renamed to Krayon, a name half-jokingly thought up by Sean Pecor. As he (and others) expected, the new name would give problems, but it seemed stick around after Bart Syszka liked it too. During this short period, TheKompany.com, led by Shawn Gordon, was active as well -- they had hired someone to work full-time on KImageShop / Krayon. But John Califf's 54th and last commit was February 12th, 2001, and nothing much happened after that for over a year.
In June 2002, Patrick Julien appeared on the scene. By then, Krayon had been disabled from compilation for legal reasons: a German lawyer thought "Krayon" too close to the name of a German website (crayon.de) which used to sell a series of graphics cd's. Crayon.de seems to have become a "lizensberater" since then, and von Gravenreuth is no more.
But back then, the first thing that had to be done was to find a new name. The discussion was long, and in the end Krita was chosen. Looking back, it seems to have been an excellent choice. We never had any legal problems since (touch wood!), and after a few years patience, the krita.org domain became available as well!
New maintainer Patrick Julien embarked upon a refactoring of Krita following the Gang of Four's Design Patterns lead.
And that was more or less the state when I started looking for something to draw maps with, using my little Graphire... The project had stagnated again by then, after the promising refactoring had basically set down the broad architectural lines Krita is still based on.
I didn't know C++ back then, but neither was I a novice programmer. I'd been earning the daily bread for me and my family for about ten years, first as an Oracle PL/SQL developer, then Visual Basic, then Java. I had written and gotten published a book on Python and Qt, so I knew Qt as well. I had no experience with graphics, though...
In October 2003 it was not possible to paint with Krita: all tools except for the layer move tool had been disabled. The paint tool was the first thing I worked on, and I was very proud when I had a tool that could place squares on the canvas -- and the size of the squares was sensitive to the tablet pressure!
And then the ball started rolling again... In 2004, I Patrick Julien handed over maintainership. Many of the people who are still working on Krita were already around by then, and by September 2004 we were ready for the first preview release of Krita! The backend had been rewritten once more (and that would happen at least two, three times again), we had working tools, plugins, filters, color models, wacom support... Get the (apparently incomplete) source code!
Then 2005 arrived, and we were driving ourselves really hard to make the KOffice 1.4 release. Originally planned for the first quarter of 2005, it actually got delayed until June. We had a great feature list (for a brand-new application):
- Layers (without fixed boundaries).
- A familiar set of tools -- brushes, selection tools and shape tools.
- Painting with filters.
- An extensible system for the addition of new color and paint models.
- Support for pressure sensitive tablets.
- The ability to read most graphics file formats, including gimp and photoshop files.
- Exporting to many graphics file formats (but not gimp or photoshop)
- A complete colour management system based on lcms.
- A useful set of filters (implemented as plugins, so the set of filters is extensible) including a CImg based image restoration plugin.
- The ability to use Gimp palettes, brushes, patterns and gradients
Real artists ship, and we had shipped! Champagne was being served, and then compilers were fired up again, because after 1.4, a 1.5 has to follow. We had a sprint at my place in Deventer. That was also around the time I discovered IRC... 24/7 presence is taking its toll these days.
A bit less than a year later, we were still hard at it, and Krita had gained adjustment layers, scripting, 16 bit/channel support, CMYK, an OpenGL canvas... And we released it with KOffice 1.5 in April.
In 2006, we were old hands at hacking and releasing and hacking and releasing. But things were changing. Google's Summer of Code program arrived, and we had our first students working on Krita and KOffice. We released 1.6, and Krita 1.6 was really a very nice, stable image editor. The first professional users started taking a look at Krita, but still found it wanting. And the long-awaited port to Qt4 got started. Oh... And Krita got the Akademy Award for Best Application!
But that really was the beginning of a time of troubles. Looking back, I'm surprised we never gave up. I had to give up, personally, for a bit of time, when I got burned out, not really because of the hacking and porting, because that was still fun, but tensions in the KOffice community got steadily worse, something that would end with the KOffice/Calligra community split in 2010.
And another problem was that we simply couldn't figure out how regain stability. The KDE 4 platform was unstable, Qt4 wasn't exactly as good as it should have been -- and we made KOffice go through a huge redesign, where much of what we had learned in Krita about canvases, tools, plugins and more was placed in the core of Calligra, in the flake library. in retrospect, we ported too quickly, and we changed too much, and we got stuck.
So, 2007 and 2008 went past, without a release. It took three years to get to the Krita 2.0 release in May 2009, and that while that release was a huge milestone, it was also completely unusable. None of the KOffice applications had anything like the stability or plain usefulness of the 1.6 release. Looking back, it's a wonder the project didn't die. Of course, we still had fun coding, there were Google Summer of Code students, there were Libre Graphics Meetings (the first I attended was the 2007 in Montreal, also the first time I crossed the Atlantic!).
But it was clear that something had to be done. And in December 2009, we all had enough. We had released Krita 2.1 in November, and while we felt we'd made progress and proudly claimed "This release marks the beginning of the user-readiness of the 2.x series of Krita.", it wasn't really. We did have our own website, now, though! And the all-new KDE web forums!
It was during a KOffice sprint in the Trolltech offices in Oslo, that Lukáš Tvrdý, a former Summer of Code student, presented his idea: he would have several months between finishing his thesis (about Krita brush engines!) and his graduation, and instead of seeking a job hacking up websites, he would like to try and work full-time on Krita, to get rid of all the pesky bugs, performance issues, all the papercuts, sock-wrinkles and plain-out filthy bugginess. But he needed money to buy bread and pay for his apartment... So the first Krita sponsored development drive was born. Crowd-sourcing avant-la-lettre, it brought in enough to keep Lukáš well-fed and happy hacking.
This really made a huge difference. We got in touch with David Revoy, the French artist who was back then working on Sintel for the Blender Foundation. His timelapse showing how he worked with Gimp and Mypaint on concept art really gave us a kick in the pants -- he should have been using Krita!
But we were honest enough to know that he could not have used Krita. So, armed with his suggestions, we went back to work. We had a goal -- "make Deevad happy with Krita", we had received the sponsorship needed for Lukáš, and we were really motivated. Krita was fun again!
We kept on releasing, though: 2.1 was released in November 2009, 2.2 in May 2010, 2.3 in December 2010 and then... The Calligra/KOffice ruckus happened. It took a long time before the first Calligra release was made, numbered 2.4. Krita 2.4 was released in April 2012.. We'd spent all of 2011 on it, and parts of 2012. It was a long release-hiatus, but it was worth it. Krita 2.4 was ready for the end-user, we felt.
At the Krita sprint in Amsterdam in 2011, David Revoy had said of Krita 2.3 that it came close, and was a nice application for amateurs, but not ready for professionals -- fun to use, but just too many rough edges, too many things that hampered workflow. Krita 2.4 fixed that. It had taken a year, since 2.3, and in fact, two and a half years since we first put "make deevad happy" as our No. 1 goal, but we'd made it. Which is not to say that we were done...
So, there's been 2.5, 2.6, 2.7 since then. Every release makes me wonder why we thought the previous release was the bee's knees -- and every release excites me, because there's so much new, so much fixed, so much polished.
Right now, we've got a Krita Foundation which owns the Krita trademark, Dmitry Kazakov will work on Krita full-time for the next four months, there's a company giving commercial support for Krita, every month the number of users increases. We've ported Krita to QML for Krita Sketch and Krita Gemini... We've got a shop full of cool swag. And my novel still isn't finished!
Looking back, I wonder -- why did I pick Krita to work on? Probably because I didn't like to start a new project, and besides -- I probably couldn't have pulled it off. I didn't know anything about graphics... And Krita was in Qt, promising, but still small and needed so much basic stuff done that I knew I could get into it. Now, in 2013, Krita is over 300k lines, excluding the Calligra libraries. Newcomers have a much tougher time of it! (But don't let that deter anyone!)
Ten years is a lot of time. In that time, I've bought and sold two houses, and am living now in the third. My daughters were at primary school back then, now they are first-year students at University. I went through three jobs, and am now working at a company I've co-founded. And I've always kept working on Krita...
Ten years is a long time! Here's to the next ten years of Krita! To an awesome community of artists and developers, to great code and lots of fun, to learning and doing, to coding and painting!
Thank you, everyone, Aaron, Adam, Adam., Adriaan, Adrian, Adrian, Albert, Alberto, Alexander, Alexander, Alexis, Alfredo, Allen, Ana, Andras, Andre, Andreas, Andres, Andrew, Andrius, Andre, Andy, Anne-Marie, Ariya, Arjen, Bar, Ben, Ben, Benjamin, Benjamin, Benjamin, Benoit, Bernhard, Bo, Brad, Bram, Burkhard, Camilla, Carlo, Chinkal, Christer, Christian, Christan, Christoph, Chusslove, Clarence, Cyrille, Dan, Dan, Daniel, Daniel, Danny, David, David, Dirk, Dirk, Dmitry, Edward, Elvis, Emanuele, Enrique, Fabian, Frank, Frederik, Fredrik, Fredy, Friedrich, Gary, Geoffry, Gioele, Giovannia, Gopalakrishna, Gabor, Hanna, Harald, Hasso, Helge, Helio, Hoang, Hugo, Inge, Ingo, Jaime, Jaime, Jason, Jakob, Jakub, Jan, Jaroslaw, Jens, Jessica, Johannes, John, Jonathan, Jonathan, Jose, Jure, Kai-Uwe, Kevin, Kevin, Kurt, Laurent, Lauri, Leo, Lukas, Lukas, Maciej, Malcolm, Marc, Maria, Marijn, Martin, Matthew, Matthias, Matus, Melchior, Michael, Michael, Michael, Michael, Mohtaba, Montel, Nick, Nicolas, Olivier, Patrick, Patrick, Pavel, Peter, Pierre, Pierre, Pino, Rafael, Raphael, Rex, Rob, Roopesh, Sahil, Samuel, Sander. Sascha, Sebastian, Siddharth, Silvio, Silvio, Somsubhra, Srikanth, Stefan, Stephan, Stephan, Stuart, Sune, Sven, Thiago, Thomas, Thomas, Thomas, Thomas, Thomas, Thorsten, Thorsten, Tim, Timothee, Tobias, Tom, Torio, Torsten, Unai, Urs, Vera, Volker, Waldo, Werner, Wilco, Will, William, Yann, Yue, Yuri, Manu, Ismail... And everyone I've forgotten to mention!
By now you probably know that i’m that “idiot” that tries to re-create KOrganizer in QML. You might wonder: “Why isn’t it done yet? You’re working on it for about a year now, right?”
Fair questions, but the answer is difficult.
About a year ago i had a working application, it just looked horrible and was made in a hacking fashion because it wasn’t at all certain if the needed data could be exposed from Anokadi to QML. No one really had done that before + the fact that QML was (and still is) very new made it extremely difficult to make something at all. I had to figure things out on my own in the QML world, asking questions was possible but not many people would be able to answer simply because i was playing in an area where knowledge is very sparse and there where just not many people into QML yet. So i wasn’t going anywhere fast and certainly not in an acceptable manner, code wise.
Then came the PIM sprint sprint, early 2013. My initial plan was to have the calendar working and released by that time. As just said, things where going nowhere so we had to come up with “some” grand plan to make calendar data from Akonadi usable for people in QML. The Akonadi structure was close to complete with the “calendaring” branch. During that PIM sprint we decided on a QML API for accessing PIM data. I had a lot of great help wrapping my mind around some odd proxy wrapping stuff to fetch the actual required data from Akonadi. By now that is known as “QML Calendar Components” and can be found here .
That PIM sprint was vital! I now had an easy way to fetch the data i want to have from Akonadi. Even though this is far from finished. Right now it still lacks:
- Todo events (easy to implement)
- Journal events (easy to implement)
- Update existing events through QML (started implementing it, editing some values is already possible)
- Create new events through QML (not implemented yet)
In fact, the components as they are there  right now is how Heena Mahour used them during the last GSoC. And quite successful i might say! She has rewritten the clock popup applet (the popup you see when you click the KDE clock) in QML using those components.
The fact that Heena was successful at creating that using “my” components means that a graphical KOrganizer replacement can now finally be written, or not?! As in representing the data, it’s a definitive yes! However, manipulating the data or adding new entries still remains a big hurdle left to tackle.
Then we still have QML itself. When i made my first proof of concept – over a year ago – i could very easily conclude that QML itself just wasn’t ready to draw the complicated features that a calendar needs. In this area things didn’t improve much. I will still have to do massive hacking to show an event in a ListView. However, things did improve greatly! It’s now very easy (without wrapper/glue) code to change your mouse pointer (resize handles come to mind) and to make proper use of the available space using the new QML Layout components that are in Qt since 5.1. But that is it as well, it will be “less hacky” then a year ago, but still very hacky. I can’t really blame Qt for that. A calendar is an odd beast with non common elements. Don’t even bother asking about events that spawn multiple days. It’s extremely tricky to display that in a week view in QML. It’s the most challenging issue i have at this moment for this project.
All of the above is the justification for the lack of finished “QML Calendar” application. However, things are changing quite rapidly at this moment. I started re-creating the calendar with Qt 5.1 (QtQuick 2.1) and it’s progressing very fast and nice. I’m not going to make promises, but i should have it working like a year ago only with the new calendar components and Qt 5.1. Stay tuned for more status updates since i plan on posting them more often from now on.
The Krita Lime PPA provides daily builds of the best free software painting application out there. For aspiring artists Krita is a fabulous app to create works of inspiration.
Krita is optimised for painting but I also use it for many image manipulation tasks, it's installed by default in Kubuntu.
See dmitryK's blog for instructions to install it.
Plasma Active ist eine User Experience für Tablet PC's und Smartphones. Sie ist einfach zu benutzen und (meist) intuitiv zu bedienen und ebenfalls vollständig Open Source.
Ich freue mich sehr, mein erstes Buch im Eigenverlag bekannt zu geben. Das Handbuch ist ein Startup-Guide zu Plasma Active. Ausserdem beinhaltet es Grundlagen, wie USB-Erstellung, Installation, Benutzung als PIM und vieles mehr.
Die Projektseite ist verfügbar unter: http://pactivehandbook.sourceforge.net. Dort finden Sie die Docbook Quelldaten, ein online lesbares HTML-Handbuch, sowie die letzten PDF's. Das beste: Es ist kostenlos zu beziehen. Wenn Sie den Autor unterstützen möchten, können Sie eine Druckversion bestellen. Einfach auf den Button drücken.
Ideen und Tips jederzeit willkommen :-)Related articles
- Plasma Active 4 - ready when you are (news.kde.org)
Plasma Active is a user experience for Tablet PC's and Smartphones. It is a easy to use and intuitive (mostly) GUI and fully Open Source.
So i'm pleased to announce my first selfmade handbook. The handbook is a startup guide for Plasma Active, and contains some useful informations about baking a Image to USB, installing Plasma Active, Using it as PIM and some things more.
The Projectpage is on http://pactivehandbook.sourceforge.net/. On that place you can access the Docbook Sources, you can read it online and you can download the last PDF file. The best: It's free.
But if you want to honor the autor you can Click the button.
Ideas, wishes and so are welcome. :-)Related articles
- Plasma Active 4 - ready when you are (news.kde.org)
This year i took part on the GSoC and i was being mentored my Martin Gräßlin. My project was to port the KWin Effects KCM to Qt5. After a bit of research we decide that it will be easier to rewrite them back from the scratch instead of trying porting them.
We wanted to have an application which is written completely in QML and we were able to do it because of the Qt Quick Controls. And in order to do that we had to make a lot of changes into the KWin Effects KCM, because it was based on Qt Gui so all the UI stuff needed to be rewritten from the scratch. So we came down to the conclusion that it would be easier to rewrite it. The name of the new application is KWincompositing. Also some of the KDE4 code did not make any sense on the world of Qt5. Furthermore, KWincompositing is using a more flexible model (QAbstractItemModel for those who are interested for the technical details) for loading the effects. The KDE4 model was coming out of a library which didn’t allow us to modify stuff. For example we didn’t had the ability to add an extra button for removing the effects which had being installed from the Get Hot New Stuff… And more cool stuff can be added, we might add an embedded video which will show the functionality of each effect.
What are the advantages of the new UI?
The new UI comes without any tabs, while the KDE4 version had 3 (General, All Effects, Advanced). The existence of the tabs was making some stuff harder for the user because he had to remember which option exists in which tab. On KWincompositing all the available options exist on one page. So you will no more have to navigate through the tabs. Also our new UI comes with more changes. E.X. the about information for the KWin Effect, the KDE4 version was opening a new windows, while the KWincompositing is showing you the information inside from a dropdown menu. At the moment the KWincompositing is under development and it is not consider to be stable.
Contact InfoIf you are interesting about KWincompositing you can contact us at firstname.lastname@example.org or in #kwin at freenode How can i build it? You can download it from here. After that you will need the kdelibs (frameworks branch), plasma-framework (master branch) and kde-workspace (master). Our code exists on master branch. then run cmake -DCMAKE_INSTALL_PREFIX=$KF5 -DCMAKE_PREFIX_PATH=$KF5 . && make && make install For more information about how to build frameworks, you could take a look at the wiki.
Following hot on the heels of the wraparound tool comes yet another very cool feature! This time, the tool that we are presenting is especially useful for game designers.The Clones Array function will help the creators of games where the world consists of a set of small tiles of different kinds.
This is a new feature developed by dmitryK and it will be available in Krita 2.8!
Watch the video to see how it will work:
Thanks to Paul Geraskin (Mifth) for this video and images :)
One of my personal adjustments to KWin is using the top right screen edge as a trigger for the Desktop Grid effect. With the switch to KWin on 5 this hasn’t worked for me any more as we don’t have code in place to transfer the old configuration to the new system.
Last week I had enough of it. It was breaking my workflow. So I had to do something about it and had the following possible options:
- Change the default: bad idea as we don’t want to use the upper right corner as that’s where maximized windows have their close button
- Carry a patch to change the default on my system: bad idea as that breaks my git workflow
- Just change the value in kwinrc
- Bring back the configuration module
As I considered just modifying the config value in kwinrc as not a durable solution I decided to go for bringing back the configuration module (KCM).
After a little bit of hacking and facing the problem that it used some not-yet ported library inside kde-workspace I got the code compiled and installed. But when I started it using kcmshell5 from kde-runtime I hit an assert.
So either my code was broken or kcmshell5. I didn’t really want to investigate the issue of the assert and decided to try the most obvious thing to me: use another implementation to test the kcm. And so I started to port systemsettings.
After about one hour of work I had systemsettings compiled, linked and installed and could start it, but alas my KCM was still hitting an assert. So what to do? Is it my KCM or is something more fundamentally broken which needs fixing in a different layer? How to test (I still didn’t want to investigate) so I started to port a few very simple KCMs from kde-workspace as systemsettings is at the moment still rather empty. And look there, they worked in both kcmshell5 and in systemsettings.
So I started to port another KWin module and that one also hit the same assert. After some discussion on IRC with Marco I learnt that he also hit the same assert in another KCM which means that there was a pattern. And finally I started to investigate. Very soon I had a testcase with a slightly reduced KCM which I could get to hit the assert with adding one additional element to the ui file. A good start to find a workaround and now my KCM loads in systemsettings and I have my screenedge back:
Screenshot is featuring both systemsettings and KWin using Qt 5 and KDE Frameworks 5!
Now all I need to do is to extract my minimum “make it crash” code as a testcase and submit a bug report to Qt.
By now you must be getting somewhat annoyed by the KDE pim sprint reminders. It’s all for a good cause :)
If you want to get a refund for your expenses then you have to register on the sprint page  before October 1st. If you don’t care about that then you can ignore the reminder part of this post.
The thing that amazes me in this sprint is the number of people that are going to attend. The sprint page lists 19 while writing this post and 2 more will be attending, but haven’t signed up on that page yet. That makes a total of 21. Hardly a small sprint for the “usual” small autumn edition! That’s awesome!
I’ll be there from Nov 14 – 19 (crappy flight dates from the Netherlands).
See you there,
Wraparound ModeIn this new mode (which can be activated by pressing 'W' shortcut) the sides of the image get connected to each other and the image becomes infinitely-cycled. The picture becomes repeated on a screen (openGL mode only) as if it is a texture being wrapped around some surface. The painting with a brush also becomes cycled: just move your stroke and it'll appear on the other side of the image!
For the lovers of psychedelic effects we also added wraparound support to the Move Tool. Just activate it and enjoy dragging the borders of the image to and fro.
Clones ArrayThis feature (which can be found in Layer menu) allows the user to create a set of clones (tiles) which are linked to the current layer and are offset to some specific position. This feature will be useful for texture painters and online games creators where the world consists of a repeated set of 2D tiles.
How to InstallNew features are already present in Krita Lime! But since these features are very new, we've packaged it into a separate package: 'krita-wraparound-wip', so that everyone could rollback to a "stable" 'krita-testing' package. During installation the system will suggest you to replace the existing 'krita-testing' package.
sudo apt-get install krita-wraparound-wip
And as usual, if you find any bug of have any comment, do not hesitate to tell us about it! :)
Filed under: Foss Tagged: KDE, planetkde
Currently we speak a lot about performance of the ownCloud WebDAV server. Speaking with a computer programmer about performance is like speaking with a doctor about pain. It needs to be qualified, the pain, and also the performance concerns.
To do a step into that direction, here is a little script collection for you to play with if you like: the DAV torture collection. We started it quite some time ago but never really introduced it. It is still very rough.What it does
The first idea is that we need a reproducable set of files to test the server with. We don’t want to send around huge tarballs with files, so Danimo invented two perl scripts called torture_gen_layout.pl and torture_create_files.pl. With torture_gen_layout.pl one can create a file that contains the layout of the test file tree, a so called layout( or .lay)-file. The .lay-file describes the test file tree completely, with names, structure and size.
torture_gen_layout.pl takes the .lay-file and really creates the file tree on a machine. The cool thing about is that we can commit on a .lay-file as our standard test tree and just pass a file around with a couple of kbytes size that describes
Now that there is a standard file tree to test with, I wrote a little script called dav_torture.pl. It copies the whole tree described by a .lay file and created on the local file system to an ownCloud WebDAV server using PUT requests. Along with that, it produces performance relevant output.Try it
Download the tarball and unpack it. After having installed a couple of perl deps (probably only modules Data::Random::WordList, HTTP::DAV, HTTP::Request::Common are not in perl’s core) you should be able to run the scripts from within the directory.
First, you need to create a config file. For that, copy t1.cfg.in to t1.cfg (don’t ask about the name) and edit it. For this example, we only need user, passwd and url to access ownCloud. Be careful with the syntax, it gets sourced into a perl script.
Now, create the local reference tree with a .lay-file which I put into the tarball:
./torture_create_files.pl small.lay tree
This command will build the file tree described by small.lay into the directory called tree.
Now, you can already treat your server: Call
./dav_torture.pl small.lay tree
This will perform PUT commands to the WebDAV server and output some useful information.
It also appends to two files results.dat and puts.tsv. results.dat just logs the results of subseqent call. The tsv file is the data file for the html file index.html in the same directory. That opened in a browser gives a curve over the average transmission rate of all subsequent runs of dav_torture.pl (You have run dav_torture.pl a couple of times to make that visible). The dav_torture.pl script can now be hooked into our Jenkins CI and performed after every server checkin. The resulting curve must never raise
To create your own .lay-file, open torture_gen_layout.pl and play with the variables on top of the script. Simply call the script and redirect into a file to create a .lay-file.
All this is pretty experimental, but I thought it will help us to get to a more objective discussion about performance. I wanted to open this up in a pretty early stage because I am hoping that this might be interesting for somebody of you: Treat your own server, create interesting .lay files or improve the script set (testing plain PUTs is rather boring) or the result html presentation.
What do you think?