Upgrades to the release candidate today went swimmingly. I tested on both this laptop, using the 64-bit release, and on my netbook for the 32. Everything is gorgeous. KDE 4.10 is like butter.

However, dropbox stopped working. A quick google later, and by using the code from the GetDropbox site, and instructions on setting up auto-start from Richard's (Nixternal) blog, I once more have a working dropbox, on both test boxes. I use it often to share docs between my computers, and the occasional file with the public.

Quoting from https://www.dropbox.com/install?os=lnx :

The Dropbox daemon works fine on all 32-bit and 64-bit Linux servers. To install, run the following command in your Linux terminal.
32-bit:
cd ~ && wget -O - "https://www.dropbox.com/download?plat=lnx.x86" | tar xzf -
64-bit:
cd ~ && wget -O - "https://www.dropbox.com/download?plat=lnx.x86_64" | tar xzf - Next, run the Dropbox daemon from the newly created .dropbox-dist folder.
cd .dropbox-dist
~/.dropbox-dist/dropboxd What you need from Nixternal's blog is the section Configure Dropbox to run at start-up. It would be great to have kfilebox again, but until we do, this is pretty easy.

Here we are, finally ready for the 2.3.0 release. After the 2.2 one we targeted some things to fix and features to implement. We now are in the “almost done” level, meaning that quite all things have been done and that the code push is (hopefully) release level.
So, what’s new in rekonq 2.3.0? Here is the “shopping list”:

- bookmarks && history panels, given all the requests about this feature return, it has been implemented in rekonq 2.x fashion:

- some work on web view contextual menus

- activities support (at least being activities aware on opening windows)
- activity daemon support (notifying there url && window title)

- private browsing: stop saving sessions && sharing sessions cookies by tabs of the same window

- open url as webapp option. This “easy” feature has to be inserted in a wider view. So, please wait for my next post about it to.

- session saving (load/save/rename sessions). As you guessed, you can now decide to save a session for future use, rename it and load when you prefer. Moreover, you can decide to start rekonq showing the session dialog, loading one of the saved sessions.

- some work on respecting one more of the thousand millions kde “wide” settings.

- urlbar look change (not finished). SSL icon on the left as major browsers. coloring url text (yet) missing. We have problems when the urlbar is full and text start to “scroll” on the left. And I’d really like to have an “easier” widget here, allowing rich (colored) text, instead of pixel perfect subpainting.

- Favorites (fast) management, the “opera” way (bye bye “love” icon). Just click on the star icon to set bookmarks and/or favorites.

- appmenu-qt support. Just a missing dbus registration from the rekonq window. Easy to do (2 loc), hard to understand.

- fixes fixes fixes.

Wanna more? Enjoy rekonq.

Filed under: international, rekonq

Recently I noted that there were more and more topics outside of Simon (but mostly related to KDE in other ways) that I wanted to talk about.
Therefore, I have decided to set up a personal blog: http://grasch.net/blog.

Because I don't want to maintain two separate blogs, this is also the place where I will post updates about the Simon development from now on.

The new blog will of course also be aggregated to Planet KDE.

This years Google Summer of Code in KDE is under the theme "polishing existing things". For Simon this is the perfect opportunity to polish some interface kinks.

The current Simon interface is follows a quite technical approach: Install scenarios, then match an acoustic model to it. Want to add a word? Better install a matching shadow dictionary or g2p model first.
All this makes perfect sense when one knows what happens internally, but this is rarely the case for end users.

Instead, a streamlined, user-centric resource management process could remove much confusing from setting up Simon: For example, the system could automatically detect the system language and ask the user to set up a basic system for that language. It could automatically track compatibility between different components and resolve problems automatically. Simon could even ask to install scenarios based on installed applications automatically.

If you want to work on Simons interface as part of this years Google Summer of Code, please get in touch on the mailing list: kde.org.

Tags:

• KDE
• Simon

Every April, a couple of dedicated free software enthusiasts host a conference called "Linuxtage" at the FH Joanneum in Graz.

It's an awesome little event that has grown organically over the last couple of years to the point where it really isn't that "little" anymore.
Nevertheless, great management has ensured to maintain the approachable small-town feel of the conference meaning that walking through the location you'll see everything from local seniors looking for a new challenge to Canonical employees demoing their cutting edge mobile platform.

Our very own Kevin Krammer is actually part of the organizing team and made sure that KDE always had a booth. However, staffing a booth and being responsible for literally anything else at the same time is always problematic so this year, I offered to take over the booth.

Claudia Rauch, our hardworking business manager offered to send me some t-shirts, bags and buttons to sell which were great.
Moreover, Kevin also organized a couple of KDE branded USB sticks which were a huge success.
But I also wanted something that I could hand out so that people could try out KDE software at home so I contacted the OpenSUSE promo team, which, without hesitation, agreed to send 100 freshly pressed DVDs of their newest release coupled with some additional promotional material right to my door step.

The booth itself was perfectly placed in a hight-traffic corner (apparently, it does helps to know the organizers :) and I got to show off KDE to a very diverse audience.

Personally, I've always found it hard to quickly describe "KDE" to someone outside the FOSS world so after a couple of hours I instead ended up devising an alternate strategy: Vaguely describe KDE as a "community of like-minded people working on free software" and instead focus on a specific application: I asked people about their most exotic (non-standard) application and tried to find a KDE equivalent. Interestingly, that worked almost always and I got to show off, among others, Krita, the music editor flake in Calligra Words, Skrooge and RKWard.

All in all, it was a great event. We raised more than € 200.- for the KDE e.V., got people who had never even heard about KDE excited about it, and discussed the Join the Game program with those that already were.

Tags:

• KDE

For those who don’t follow Hughsie’s blog, I’m reposting it here. It’s about helping with statics data if you use colord-kde.

What he asks is quite simple but doesn’t make sense if don’t have colord-kde installed, you don’t need to have ever touched it, colord-kde creates an edid ICC profile for your display automatically so the kded module only needed to have run once, please try:

A favour, my geeky friends:

gnome-settings-daemon and colord-kde create an ICC profile based on the color information found in the EDID blob. Sometimes the EDID data returns junk, and so the profile is also junk. This can do weird things to color managed applications. I’m trying to find a heuristic for when to automatically suppress the profile creation for bad EDIDs, such as the red primary being where blue belongs and that kind of thing. To do this, I need data. If you could run this command, I’d be very grateful.

for f in $HOME/.local/share/icc/edid-* ; do     curl -i -F upload=@$f http://www.hughski.com/profile-store.php done

This uploads the auto-EDID profile to my webserver. There is no way I can trace this data back to any particular user, and no identifiable data is stored in the profile other than the MD5 of the EDID blob. I’ll be sharing the processed data when I’ve got enough uploads. If you think that your EDID profile is wrong then I’d really appreciate you also emailing me with the “Location:” output from CURL, although this is completely optional. Thanks!

 

Thanks!

Hi,

this is short news mostly for packagers, but well I want to thank José Manuel Santamaría Lema which did most (if not all) of the changes in this release, he found a few bugs and extended the debconf protocol support. I didn’t manage to release this soon as I’m way too busy. His work was made when I got arrested in Germany last year so I’m quite late here…

Enjoy:  http://download.kde.org/stable/libdebconf-kde/0.3.0/src/libdebconf-kde-0.3.tar.bz2.mirrorlist

Next week I’ll probably do a new colord-kde release stay tunned!

About

No tablet would be complete without instant messaging. Thanks to awesome bachelor thesis work we had a non-working mockup of an active client. This active client remains separate from our desktop work.

In recent weeks I've been transforming this code to go from a non-working prototype to something working with real contact lists and text chats.

How to set up the latest ktp-active

Install the latest version of plasma-mobile-components. Personally I use project-neon for this to keep a separate environment.

Install the latest (git master, not 0.6.1) of ktp-common-internals

You will need to open system settings and change your workspace theme to "Air Mobile".

git clone git://anongit.kde.org/ktp-active

Change directory to application/package and run "plasmoidviewer"

You will need to set up your accounts using either our desktop Accounts KCM Module, or manually using the mc-tool command line tool.

This sounds awesome, how can I get involved?

See our KTp wiki page http://community.kde.org/KTp/Getting_Involved
We have a wiki page for the active project, which lists some tasks to be done. We are not accepting bug reports on ktp-active at this point.

Ping me (d_ed) on IRC for details.

After a week away at an intense dev sprint in Germany, I'm back in the home office and that means another Luminosity of Free Software episode!  This week on the menu are:

• Riak: a distributed data store that strives for eventual consistency rather than ACID. Inspired by the CAP theorem, this key value store is aimed at big data but is really fascinating for anyone with even a passing interesting in computer science.
• Little boxes: We all know how fun the Raspberry PI is and the utility one can get out of an Arduino. What would be possible with higher-spec devices with more useful base configurations that were still affordable and completely driven by Free software? That's the question I found myself asking the other day.
• KLyDE: This is an attempt to package KDE's Plasma Desktop in a more conservative way with a goal of trading out features for resources. We'll look at what they are actually dong, how it works with the Plasma Workspaces as they are now and what sort of impact this kind of effort could bring in future releases.
• Q&A: Where we explore the meaning of the universe, or at least the questions you lob at me. Leave questions ahead of time in the comments below or during the show in the irc channel.

I look forward to your questions, comments and feedback. You can leave questions for the show in the comments below or drop them live during the show in #luminosity on irc.freenode.net.
Due to daylight savings changes here in Europe, the time in UTC is being pushed back by an hour. We'll go live at 19:00 UTC this Thursday, the 25th of April. See you then!

Dear KDE Community,

meet the mailing list where you can now talk about non-technical topics relevant to our community: kde-community. From a debate about our next conference to discussing our collaboration with other organizations and our goals as KDE community, this list is for anything which does not fit on the KDE development lists.

The goals are described clear enough:

The purpose of the mailing list is to provide a place for non-technical information and discussions which are relevant to the KDE community as a whole. All people who consider themselves to be part of the KDE community are invited to join. Conversations on the mailing list are respectful, considerate, polite and constructive following our KDE Code of Conduct.

The list collects announcements, information and results from discussions in other places and offers a place to get feedback on non-technical questions or plans of relevance for the whole KDE community.
As the 'collects announcements, ...' part already hints at, we expect people to try and make a habit of summarizing discussions which do NOT take place in public on this list once a conclusion is reached. This should be the central place for KDE governance debate.

You can find the list and subscribe here.

History lessonSummer last year Cornelius wrote a blog about setting up a kde-community mailing list. It had been discussed on the KDE e.V. list that it doesn't make much sense that we have no public place to discuss governance related things in KDE.

Most of these discussions take place on the private KDE e.V. mailing list. Mirko Boehm proposed to simply open that list: what is discussed there is relevant to the whole KDE community. While there was agreement on the principle of opening up, there are things which are discussed there that probably should not be open. They are few and far between but some discussions about financial or personal matters do benefit from a less public place. Some argued that public discussions can also harm our public profile and it came up that bikeshedding could get even worse.

An alternative was proposed by Jos vd Oever: create a new list and put discussions there, unless there is a strong need of keeping them private.

After this, however, the discussion kind'a died out (I am summarizing more than a handful of mails here...). The subject came up at the e.V. board meeting in Berlin and we agreed that there's no good reason to Just Do It™. If nobody likes the idea the list will remain empty. Natural Selection FTW! I went ahead, asked our Amazing Admins to set me up, configured it and made Cornelius and myself admins who will exact our vengeance on everybody we disagree with who misbehaves.

So that's the story. The result is the KDE Community mailing list on the KDE servers. Is it official? What, you active in KDE and you don't know how nonsensical that question is? As always, the list will have to prove itself... I can only ask: please subscribe and bring your non-technical questions, comments, reminders and proposals to this list. We'll yell at the folks on the internal e.V. list if they bring things there which should be public.

And don't forget: if you want to talk to each other in person, this is where you do it. Go and book ;-)

Looking forward to your hugs at Akademy!

Looking back, I think it might be 9 months since my last “real” post. Oh, well. I have to admit my personal/work commitments (which I’m gonna be writing about soon) took me away from blogging.

Anyway, what better occasion than the latest Solid sprint could have brought me back to blogging? Many of the participants already wrote a report, so I’ll just give you an overview on how things went from my point of view.

First of all, this sprint had a peculiarity compared to our last ones: lots of new people and new faces. I can’t stress how awesome it is to have new skilled and committed metalworkers. Secondly, it has been great to see more people seriously committed to powermanagement, which up to last year has been a pretty much solo effort. Oliver, Lukas and Alex have been invaluable in helping fixing bugs, refactoring the code and adding new features. So, a quick list of what we have done:

• Refactored the logic parts of core vs. actions. The core now (finally) acts as a pure policy handler, whereas all the logic needed for each action (e.g.: suspend, hibernate, etc…) is now completely boxed into the actions.
• Refactored brightness handling. Now we have a way for reacting to brightness changes when the hardware does, which means no heuristics in trying to understand when and how the brightness changed. We are also planning to remove the KAuth helper.
• Started working towards having powerdevil’s logic completely asynchronous.
• Refactored KCM’s logic to have actions really capable of advertising their support on the system. This means now the KCM shows only those actions which are really supported.
• Fixed several bugs in keyboard brightness handling, which should be rock solid by 4.11.
• Fixed other bugs here and there, which became trivial to fix after all the work above.

Overall, this means an improved and more stable experience when it comes to powermanagement in KDE 4.11. We’re still working on making this stellar for the final release, but I can definitely say the backbone is there.

On a side note, some of our changes obviously broke backwards compatibility with our internal DBus interfaces. Thankfully Hrvoje noticed the fact that most of workspace was using those for interacting with powermanagement. Needless to say this is plain wrong. If you are a developer, you should instead use Solid::PowerManagement, which has all the needed logic for inhibiting and notifying a resume from suspend. This applies also to workspace developers, given you can actually use the very same class for requesting sleep states. This, though, has been already fixed by the Review Request linked above.

More than that, me and Lukas managed to have a quick chat and a plan for integrating solid-partitioner, which is the final result of last year’s summer of code by Lisa. We’ll come up with a joined plan really soon.

On this topic, me and Martin finally managed to sync up with the plans for Polkit in KDE in 2013. We’re planning an exciting GSoC project, so stay tuned.

I guess that’s pretty much all. We had lots of fun and did lots of work as usual; it’s really great to have a concrete taste of the community every once in a while. Speaking of which: Akademy is coming, and this year I had the honor and privilege to be part of the committee of the event. Needless to say, I hope to see you all there.

Hi!

Five months have passed since the release of kdev-python 1.4.1, and it's about time for the next release! The 1.5 release will contain various new features and bug fixes, and also will work with KDevelop 4.5, which is to be released soon.

One of the new features in kdev-python 1.5: initializing properties in class constructors via code completionNotable Bugs fixedThe following issues were fixed, among others:

• 312275 don't add brackets if importing functions
• 318802 fix quadruple-quotes from causing completion to malfunction
• 317998 issue with function definition ranges causing completion to malfunction
• 317808 correct inheritance completion with member access
• 309817 correctly build uses for declarations in some corner cases
• 309469 include documentation files for PyKDE and the rest of PyQt
• 308986 fix a rare crash with some function definitions
• 1d34b03 fix an infinite loop in the debugger plugin
• 031badc don't reparse files on session restart if not necessary

The numbers are the bug / commit IDs of the change.
Notable new FeaturesThe following new features are worth mentioning:

• 333cf91 sort completion items based on name similarity
• 6dc24ad class attribute initialization completion
• cd03cee PEP8 error checking. Enable it in "configure kdevelop" if you want to use it.
• b3ba512 support adding watches in the debugger plugin

Name-aware variable sorting: Although "the_bar" comes first alphabetically, "the_foo" is sorted first because its name matches the left side of the expression. You can still get an alphabetical list by invoking full completion.Features that didn't make it into 1.5 yetTwo things that I wanted in 1.5 but which are not there are Python 3 support, and GHNS support. The latter is just not ready yet (might be in 1.5.1 or 1.5.2, but probably 1.6), the former can only be released in Q1 2014, as explained here.
Get itkdev-python 1.5 is to be used with kdevplatform 1.5, and only 1.5 (so, kdevplatform with version numbers >= 1.4.60 and < 1.5.40). It's not going to work with kdevplatform master, or kdevplatform 1.4.
Please test this RC thoroughly and report any issues you find to the bugtracker, so the final 1.5 release can be as nice as possible! Get the tarball from download.kde.org. The sha256sum of the tarball is
441f675baddbfb9832a49458cc3c9a17daac4db55e7312c7a85d184bc0f4c776
Have fun with it! (not with the checksum, with the program I meant... you know)

When we want to create a script sieve, we need to know Sieve language, and we don’t use all days this language so it’s easier to create typo and error.

So I decided for 4.11 to create an assistant to generate sieve code.

By default end user prefers to use GUI to create filters (as sieve script is using for filter mainly). In KMail filter GUI is good. So I decided to use same interface.

This interface is separate in 2 elements:

• List of scripts: we can add several scripts
• And a second element which show conditions and actions.

I tried to add all sieves specifications and some sieve extension.

It supports default sieve specification:

actions:

• fileinto (move mails to specific folder)
• discards (discards emails)
• keep (keep emails here and stop action)
• add flags/remove flags/set flags (add/remove/set flags)
• redirect (forward emails)
• reject (reject emails)
• stop (stop script execution)

conditions:

• size (test on email size)
• address (test address)
• header (test headers)
• envelope (test envelope of mails)
• exists (test if headers exists)

But sieve has some extensions, I tried to add them, I didn’t implement all of them because we can’t add them in GUI easily.

I added:

conditions:

• Body extension (test body)
• Date, test date in header  ( for example receiver header)
• CurrentDate, test on current date
• MailboxExist, test if specific mailbox exists

actions:

• Delete headers, allows to remove some headers
• Add headers, allows to add new headers
• Notify create a notification

But I will not show all extensions when not necessary.

So you will show them when server support them.

After that it will generate for you code

I hope that it will help us to use sieve scripts.

I still 3 months to finish and debug it

Welcome to Kubuntu 13.04, a brand new version with the latest KDE software to enjoy.

Getting Kubuntu 13.04 Download 13.04 now or Upgrade from 12.10.

For full details of software included see Kubuntu on Distrowatch

13.04 Highlights

When I arrived at Tokamak 6 last week Alex was studying D-Bus communication between various applications. Before I had a chance to really sit down he complained about KWin talking to kded whenever for example a window got moved. This didn’t make much sense, so we had a look at it.

As it turned out that was KWin sending out notifications. Which immediately raised the question of why? Why would a user want a notification that he started/finished moving a window? After all it’s an action the user triggered. What should be done with the notification? Show a message? “You successfully moved a window!”, yes thank you I can see that on the screen. Play an annoying sound? Pling! Hopefully not.

Looking at what KNotify supports only logging to file or running a script make sense in response to the notifications emitted by KWin. But for logging to file it’s rather questionable why one would want that and why one would do that from inside a window manager. So what remains is running a script – fair enough that can be useful.

A closer look to the notifications emitted by KWin showed a few more things. None of them is configured to do something with the notification. By default KNotify just discards the notifications. This means we do a communication with kded via D-Bus for nothing. Two applications are getting woken up, context switches and so on for exactly nothing. Some notifications have a sound file connected to them, but are not configured to play that sound by default. We made a small quiz by me playing the sound file and letting the rest of the group guess what it’s for – I think nobody got one right. Nobody of the core workspace developers knew these sounds.

Looking at the code where the notifications are emitted highlighted another interesting fact. At all places we also emit a Qt signal which is mapped into the KWin scripting environment. And that’s actually quite awesome. Because unlike the notifications it has context. A KWin script does not only get informed about a window that gets moved, but about which window gets moved. Let’s say you are only interested in movements of Firefox windows – with KWin scripting that’s possible, with the notifications it isn’t. Given that we already identified that scripting (and maybe sound) is the only use case for the notifications emitted by KWin it’s getting more questionable why they are still around. Obviously they had been added long before we had KWin scripts. I was unable to really figure out when it got added, as git blame ends in one of the moving around code commits years ago (with more patience one can figure it out, but knowing that it’s old, was enough).

Of course we do not want to break our users’ workflow, so removing the feature is not easy. We have to properly judge whether the users’ workflow is valid enough to penalize all users by the additional overhead in code and in communication especially the context switches. Given that KWin scripting also allows to perform D-Bus calls, it should be possible to rework each of the previously existing notifications in KWin scripts.

That said: in case you were a user of one of those notifications and the removal breaks your workflow: please let me know. Please tell me how you used it and best provide your script. I will have a look at it and try to ensure that it’s still possible with KWin scripting (if it’s simple enough I will just port it).

Tweet Buffer

Members from the Plasma team assemble a couple times each year to get some face time with each other. This is good both for team building and for making large strides forward in the technology we maintain and work on. When we get together on our own, rather than as part of a bigger event, we call the events "Tokamaks". We held the sixth such meeting last week in Nürnberg, Germany where we were hosted by SUSE with additional support coming from KDE e.V.
Tokamak 6 Kaban starting line
We always set a theme for these meetings so we go in with a goal. We usually spend the first day catching up with the state of the project and each other as well as defining in detail the topics we will cover in the coming days. After the first day's presentations by attendees, we ended up with a wall full of sticky notes arranged in tracks and ready to be marched down towards the finish line.

We organized things into four tracks: the shell, kwin and Wayland, session services and startup and a catch-all miscelaneous track. Unlike some of the past Tokamaks, particularly some of the earlier ones, where we had a very clear and obvious design with implementation gaps that needed filling with code, at this Tokamak the sticky notes on the wall were dominated by design topics.

This really reflects where we are in the development lifecycle of Plasma Workspaces. Currently we have a stable desktop environment with some minor annoyances left to be addressed; bug fixes and user interface cleanups are the norm for development these days when it comes to the desktop shell. This is great for our downstream partners and users as they have a reliable environment to build upon and use.

Simultaneously, over the last year we have also been working on a few very important developments: realizing our device spectrum vision and moving to Qt5 with KDE Frameworks 5.
Single Shell TheoryMany readers of this blog are familiar with Plasma Active which is a Plasma Workspace template for mobile devices; our reference device there has been tablets, but it certainly is not limited to that in any way. This effort which started in 2011, with the first release coming in October of that year, was the next logical step in the plan to build a user interface that spans devices from phones to tablets to media centers to desktops to things we aren't even looking at right now but you might be.

In the process of creating Plasma Active (and three subsequent major updates to it) we learned a lot about the power of the Plasma framework and QML. We also learned how it could be better. Sometimes it was simply confirming what we knew needed more work and sometimes it was revelatory. It all came to a head at Tokamak 6 where we took the opportunity to put firm blueprints down on our sketches.

Perhaps the most critical development is the creation of the unified shell. Right now all of the Plasma Workspace share most of their code, but they each carry a separate binary that essentially launches the desktop layer. Bringing together the efforts from desktop, netbook, active and elsewhere, we have developed a single binary that can load any of these shells and which will be able to switch between them at runtime.

The power of this idea was aptly summed up by Marco Martin who wrote, "One interface does not fit any device, but one technology does, especially when it can give you an user interface always optimized for the device you are using in a particular moment." This is an ultimate form of doing more with less and the culmination of some 6 years of effort.

This causes an interesting series of knock-on requirements. First, we need a package that can describe what a given workspace means. What makes up a desktop, what makes a tablet, what makes a netbook? We now have a package definition that includes all custom QML for the shell, the initial setup (done with Javascript, just like it currently is), default settings, processes to ensure are started (and later stopped), window manager tweaks, etc. We are still researching some aspects of this, but a working definition was put down.

This also implies that KWin needs to be able to adjust at runtime. Much of the underpinnings are already there, so this will ultimately be a short hop for KWin. A new KDE daemon plugin (kded module) has been written that tracks what the current shell is along with its runtime attributes (e.g. does it have a mouse, or does it rely purely on touch?) to coordinate this between the different processes.

With a single shell, this also means that all the "helper" interfaces need to follow suit. Things like the lock screen, the logout interface, user switching, the login manager, etc. We've worked hard over the last few releases to make sure that all of these things can now be done in QML. In Plasma Workspaces 2 we will be introducing a new Look and Feel package that can contain QML for all of these components. This means that you can switch, customize and share themes using a single package in a single location on disk. (That's a bit of a simplification as there is a transparent fall-back mechanism, but this is already getting long enough. :)
Qt5, Frameworks 5 and WaylandComplimenting the single shell approach is the move to Qt5 and KDE Frameworks 5. These are the new releases of the libraries we currently use from the Qt Project and KDE. Thankfully, most of the API has not changed much or at all in these version bumps. Unfortunately, Plasma Workspaces uses two things that have changed a lot: interaction with the windowing system and the QML engine internals. So we've had to pick up our socks and do a lot of work on the internals of the libraries and some of the core apps. 
We've actually been able to do quite a lot of this in the Qt4 based versions, so many of you have already seen some of the benefits of this work probably without even being aware of it. After the 4.11 release this summer, however, we plan to shift our focus to pushing out the Qt5 based release.
When will that release happen? We have not discussed it with the KDE release team, nor do we have a firm fix on some aspects of Frameworks 5 so it's too early to commit just yet. We did something equally important, however: we defined what would make this release qualify as being "done" for release.
The principles we agreed to are simple:

• Do not break current workflows; what works now, must work as well or better in the new release
• Stability; it needs to be usable for daily use
• Harmonize all the interface pieces that are now on a common technology footing (QML) but do not reflect that due to disharmony in the visual and interface design

You may notice that this is completely different from our goals for the 4.0 release. This release is about rebasing a working technology on a new version of the libraries rather than making a large leap forward in technology design. We are also able to decouple the workspace development pace from library and application development as we no longer release under a monolithic and confusing "KDE" title. This means there is no pressure to release the desktop before it is ready for fear of holding up the libraries and therefore the applications.
Also part of this move is completing on another multi-year goal we've been working on: being able to support Wayland for the graphics stack and windowing system. We are relying on features in Qt5 for this and KWin has also needed much work to make the transition cleanly, but now it is all coming together. While some seem to be viewing the move away from X11 and x.org as a sprint, we have viewed it as a marathon: a long distance run that you have to plan careful and resolve to finish in the best time you can.Miscellaneous?There will also be a number of other small improvements here and there under the hood. For instance, I presented a proof-of-concept rewrite of RunnerManager which is used by KRunner, Plasma Netbook, Kickoff, Home Run and others. The goal is to simplify its threading and thread the things which aren't currently threaded for a zero-interface-thread-blocking design that is also a bit more flexible and which should also be kinder on memory.
Improvements in network management, power management and session startup are also on the table and being worked on.
I highly recommend reading some of the blogs by others who attended this or the parallel Solid sprint to get a further feel for things. That would include Marco's, Martin's, Sebastian's and Lukas' entries.

I'm pleased to announce a new episode of my open-slx Screencast. This time i'm showing you, how to add your calendar and contacts to Plasma Active, and how it looks like in Kontact Touch.

Ah… home office. The dream of any real programmer.

I was about to say ‘hacker’ but it seems that this substantive has become something that can’t be said in some circles in current ‘social sensitive’ society (but that is a topic of another post).

Can you imagine that: wake up at any time, no need to commute, have your very own office space decorated in any way you want?

I have being working in a home office setup for the last 16 months and realized a couple things that may be interesting to share with my friends and the opensource community overall.

First lesson: it requires discipline. There is no one around to push you to do your job, so unless you are a disciplined lad, probably you may get in trouble. I’ve lead teams of developers in the past, and I can say that not everyone is cut to work in a more relaxed and self managing environment. What is interesting: the majority of people when offered the opportunity to work remotely will be scared of it and will find an excuse to avoid it.

Second lesson: timezone differences are your friend. Last year I was able for 2 months to wake up early in the morning, visit a beach from 6AM to 12PM and then start working. If you have the opportunity of working remotely for a sponsor located in a different timezone, it is beneficial for both sides to explore that. You will be available at the sponsor’s timezone and at same time, it gives you freedom to do things that won’t be possible in a common 9AM to 5PM workday. Tip: since I’m using KDE, I have in my workspace analog clocks displaying the timezones of all involved parties in a project.

Third lesson: have your office. To properly turn on your mind set, have an office (which may be a room in your house) that will be your work place. When you start working, close the door and make clear to everyone that you are busy and not available. And when you are done with your daily journey, simply leave the place and close the door behind you, to help you change the mindset and be able to relax.

Fourth lesson: communication rules. Be in touch with your pals, provide daily updates and try as much is possible to be aware to what is happening in your project. Being thousands of Kms (or should I say miles to the Imperial guys?) away makes your work pretty hard to be noticed by managers and at same time provides unique challenges to be able to feel how a project is going and what the sponsors priorities really are.

Fifth lesson: you will always loose something. The trash talk at the coffee place? Not documented good practices? Some cool pet project developed by a co-worker? You will loose all that working remotely and that is a sad fact that you need to accept. There are also limits to what you can contribute back to your company while working remotely, which leads to the next point.

Sixth lesson: you will achieve the ladder’s end pretty fast. We, humans, are related to primates. Hunters in the past used to depend on facial expressions to properly assess danger and happiness. Even with current’s advances on remote communication, there are limits imposed by our own nature that won’t be overcome by technology. You need to accept that you won’t be able to achieve the top of your company while working remotely.

Seventh lesson: it requires courage and confidence on your skills. Think about it: you probably signed a contract with a foreign company that probably cannot be enforced in your local country and which gives freedom to both parties to end the aforementioned contract at any time. I personally feel that this keeps things straight and honest between both parties (you need to be happy and the sponsor needs to be satisfied with the results), but there are people who may be afraid of such situation.

Well… this is it. If I remember other things I’ve learned on this subject, I will update this post. Do you have thoughts on the subject? Let me know.

KDE Project:

• DCOP

We need you to test candidates for the 13.04 Kubuntu release. ISO tracker has the tests needed and links to the images. Chat in #kubuntu-devel to coordinate. Happy testing!

KMail has very good sieve support. But for guys which doesn’t know sieve language it’s not easy to create script from scratch.

David told me long time ago that it will good to have some templates for them. I didn’t have time to do it until now So I used same idea of kmail snippets. So by default there is default templates:

• for creating vacation script
• filtering on subject
• forwarding message
• etc.

So you can drag and drop them in editor directly. And you can add new template too. And as I want that you can reuse it in other computer you can import/export them. PS: good to write this blog I found a bug (fixed now )