Keywords vs X-KDE-Keywords on .desktop files

Seem similar, do they? But they have a *radical* difference, one is "old" (X-KDE-Keywords) and the other is "new" (Keywords). The "new" one is also an xdg standard and as such the separator is ';'. The old one is just a KConfig string list and thus the separator is ','.

Great isn't it?

TL;DR
X-KDE-Keywords uses , for separation
Keywords uses ; for separation

Third design added for the KDE End of Year 2014 Fundraising Campaign!

I hope you know we're running a Fundraiser Campaign in KDE land. As a way to say thank you donors over 30€ get a postcard.

Today we've announced the last of the three designs you can choose as a gift when donating.

Donate and get a physical copy of it ;)

KDE Gardening Love Project: KRecipes

KRecipes has been in 2.0beta since 2010 so we decided it will be our next Love Project.

Objectives:
* We want to release 2.0 "quickly" and then 2.1 in one/two months.
* Migrate https://lists.sourceforge.net/lists/listinfo/krecipes-devel over to kde.org
* Migrate http://krecipes.sourceforge.net/ contents over to https://userbase.kde.org/KRecipes
* Add krecipes group to reviewboard that mails the KDE mailing list
* Add krecipes to jenkins that mails the kde.org mailing list
* Make sure bugs/reviewboards are defaulted to kde.org and go thorugh
* Port some of the Qt3Support code (make sure don't break stuff) :D

We will be updating this list at https://community.kde.org/Gardening/KRecipes

If you want to join the initiative please join the KDE Gardening mailing list and announce yourself :)

K3b 2.0.3 released

K3b 2.0.3 can be downloaded from http://download.kde.org/stable/k3b/k3b-2.0.3a.tar.xz

I don't have access to k3b.org so can't update the news there, shows why the Manifesto is such an important thing.

Changelog since 2.0.2:
* Fixed crash in MetaItemModel on submodel item removal
* Fixed Solid predicates for AudioCd and VideoDvd media. BUG: 265819
* Set error status when CDDB query fails.
* Prefer growisofs to wodim for DVD/BluRay burning.
* Fixed improper track number in CDDB track edit window title. BUG: 276681
* Fixed crash on detecting writing speeds. BUG: 272427
* Fix problem with HL-DT-ST BH10LS30. BUG: 268307
* Fixed compilation with new FFMPEG. BUG: 274817 BUG: 300731
* Allow using CD-R90 and CD-R99 media to full capacity. BUG: 276002
* Refactor the FreeBSD SCSI/CAM interface.
* Fix crash on dvd ripping
* fix sox detection with sox >= 14.4.0. BUG: 301544
* Support more media types. BUG: 261652
* Fix file system detection. BUG: 325616 BUG: 262607
* Surround output filename for transcode with double quotes. BUG: 326097
* Fix FILE name and type detection for cue sheet images. BUG: 337201
* Rip audio tracks in ascending numerical order. BUG: 319678
* Upstream patches from NetBSD.
* Make paranoia lib detection better.
* Don't preview if called process failed. BUG: 268680
* Fix Crash while remove songs in "Mixed mode CD proyect". BUG: 323117
* Use QElapsedTimer to calculate remaining time. BUG: 330239 BUG:315463
* Fix crash in lsof wrapper. BUGS: 340515

This marks the end of the "Gardening Love Project", I'll still be subscribed
to the k3b list but won't do any more than some lurking

I think someone should stand up and start thinking for a 2.1 release.

New postcard design added for the KDE End of Year 2014 Fundraising Campaign!

You probably know we're running a Fundraiser Campaign in KDE land. As a way to say thank you donors over 30€ get a postcard.

Today we've announced the second of three designs we are planning.

Donate and get a physical copy of it ;)

KDE Gardening Team: K3b

As mentioned on other KDE Gardening Team bugs we are focusing on getting K3b 2.0.3 release out.

The release will be on 4th November if all goes to plan.

Also we are going through the bugs doing two things:

• Checking if it still happens and asking people to give more info if needed

For bugs that are easy enough to reproduce (i.e. they do not involve having 13 CD burners or writing 50GB of data to a BlueRay disc) we are trying to reproduce them and if we can't ask the reporter for more information while setting the bug status to NEEDSINFO+WAITINGFORINFO

• Classifying it regarding it's gardening potential

For bugs that we can reproduce or we think they have enough information we are classifying them in three groups using the gardening flag in bugzilla "+" for crashes that are really critical to be fixed before the release[1], "?" for bugs that seem to be relatively easy and someone could pick up and fix if has time but are not a problem if not fixed, and "-" for bugs that are out of the scope of the gardening initiative. Being out of scope of the gardening initiative doesn't mean the bug is more or less valid, it just means that it is not for the gardeners or not very involved people to fix this bug and requires people with more commitment.

You can visit https://community.kde.org/Gardening/K3b for the relevant bugzilla links.

[1] This should be a mostly empty list since we already have 2.0.2 out and doesn't make sense to delay 2.0.3 until a bug is fixed given 2.0.3 will be already better than 2.0.2

Make the World a Better Place! - KDE End of Year 2014 Fundraising

At KDE sometimes we focus in the technical parts of Free Software. This is understandable since most of us are technical people doing a technical job.

But KDE also has a huge social impact, thanks to KDE there's schools that can teach touch typing , there's people out there that can do their accounting, there's business that can fill their taxes. KDE does provide quality software for all the world to use, making it a better place for all of us.

Donating to KDE is not for you, it is for the entire world.

As a way to say thank you, starting with € 30 KDE e.V. will send a KDE themed postcard to any given address. You will get an extra card for every additional € 10 donation.

More at https://www.kde.org/fundraisers/yearend2014/

Plasma 5.1 release parties!

Plasma 5.1 is coming up in less than a month, we have already two release parties in the planning, but i'm sure you have some fellow KDE users around you want to meet and have a beer with, so hop onto your local LUG, meetup, or something, organize a party and add it to https://community.kde.org/Promo/Events/Release_Parties/Plasma5.1

The KDE Gardening Team

At Akademy I did a short talk (8 min) + herded a BoF with a title called "Quality is in the eye of the beholder".

One of the topics was that we should try to get a team of people to care about the global state of KDE software, we've decided to call this "The Gardening Team".

The mandate of the team is to:
# Find *really* important bugs and ping people to fix them
# Find stale reviewboards and ping people to fix them
# Bugzilla gardening, close old products etc
# Find projects that need love and give them some

For that we have various ideas:

Try to find monthly a bug to get people to fix it, by highlighting it as "The Bug of The Month" or something. Of course this bug can't be stuff like "Make Okular support javascript", it has to be something that is really a pain point of the whole user base and we think we can find people to fix it, it makes no sense setting impossible goals ;)

Do routine passes over reviewboard trying to identify stale requests and finding people to help moving those.

Run something called "Love Project". The idea is to pick up a project that is somewhat stale, and for a short amount of time (let's say 2/3 months) try to get a new release out, fix the most important crashers/bugs, get the review boards released, etc. This goal of the team is *not* becoming the maintainers of the project, but maybe by virtue of the "Love Project" we can attract new contributors that decide to.

Since we're only a few maybe we can't do this all, so we're focusing on a particular "Love Project" by now, but you should join and help us do more!

Our current Love Project is K3b, that had 2.0.2 released a long time ago and has a 2.0 branch with a few more bugfixes that have been never released.

We are coordinating through https://todo.kde.org/?controller=board&action=show&project_id=26 at the moment but plan to get a mailing list soon (or invade an unused existing one).

If you're interested, comment and i'll give you a shout when the list is created, no mega skills are needed (though people with mega skills are also welcome ;))

KDE Applications 14.12 Release Schedule

The schedule for KDE Applications 14.12 release is ready. As always it's available in techbase at https://techbase.kde.org/Schedules/Applications/14.12_Release_Schedule.

The Freeze is only one month away!

Okular wants to "Save"

TLDR - Short version:
We are reworking part of the "Save As" code, and we are adding the long-requested "Save" button! The old "internal implicit save" behavior is being dropped and we need your input about what to do with data saved internally by previous Okular versions.

Please visit https://forum.kde.org/viewtopic.php?f=251&t=122750 and share your opinion on the poll/comments.

KDE Community plans for Releases in the Future

Long post about releases ahead, brace yourselves!

Last week we released KDE Applications and KDE Platform 4.14.

KDE Applications, KDE Platform and KDE Workspaces were sometimes collectively referred as the "KDE Software Compilation" or "KDE SC" in short form, which is arguably a bad name, but it is what it is.

The "Software Compilation" started dying a while ago and 4.14 marks its end.

KDE Platform was 'virtually frozen' a long time ago, but we kept increasing the version number for some reasons that are now not important, so KDE Platform 4.14.x will be the last version, of course we will go to very high 'x' if there is bugfixes to be done.

KDE Frameworks 5 is the successor of KDE Platform based on Qt5, it's already on 5.1 and the team plans to release a new 5.x version with both features and bugfixes every month.

KDE Workspaces was frozen at 4.11.x, in fact if you check your distro, you are probably using 4.11.somehighnumber, the plan is to keep doing releases for at least a year if there are bugfixes available.

Plasma 5 is the successor of KDE Workspaces based on KF5, it's currently at 5.0.1. The team plans releasing a stable 5.x.y version every month with bugfixes and a 5.x+1 feature release every three months.

That leaves us with the third component of the old releases, "KDE Applications", comprised of more than 100 applications. We want those to move to Qt5 and KF5 since it's simply a better world, but we're not going to do it all at once as we did in 4.0. We will give the maintainers the choice to move as they feel the quality of their KF5 port is good enough.

KDE Applications has been having feature releases every four months, with bugfix releases in the three months in between.

We don't plan changing that, but to highlight that applications can be used independently of the libraries used to build the desktop you are using, we're just going to use a time approach for version numbers, that is, next release will be "KDE Applications 14.12"

And that marks the end of the SC era since libraries, desktop and applications are now in a separate release schedule.

Also, if you are at akademy we're having a short session Sunday at 10:40, and I guess i'll schedule a BoF later in the week.

Akademy 2014 needs *you*

Akademy 2014 is just 3 weeks away.

If you haven't registered, you should register now, but since probably you are registered already, the next step is thinking if you want to be a volunteer.

Every big event needs volunteers: infodesk people, session chairs, video operators, etc.

If you want to make Akademy 2014 a success please go over to https://community.kde.org/Akademy/2014/Volunteers and sign yourself up!

KDE Randa Meetings 2014 - The End

Everything, good or bad, reaches to an end. So will do the KDE Randa Meetings 2014 in a few hours.

I can't say all the great stuff that has happened here the last few days, but i'll try to summarize:
* The book is looking great and something that would help us grow
* api.kde.org got some love and more to come in the future.
* Planning on making life easier for newbies trying to compile and contribute patches
* KF5 ports of lots of programs in progress
* Lots of planning on automating tasks
* GCompris being more KDE
* Bugfixing everywhere
* Awesome people all around

Thanks to everyone that donated in the Randa 2014 fund-raiser.

Thanks Mario for such a beautiful event.

And of course, do not forget about the next big KDE event you should to attend: AKADEMY 2014 in 3 weeks!

KDE Randa Meetings 2014 Day 4

Time flies when you're in good company, i planned to blog every day and now i realize we're on day 4 already.

Well, here comes some of the things i've been doing
* Participated in a few discussions about "the KDE SDK" Aleix seems very promising to recruit new developers :) Let's see if I can convince Aleix to blog about it
* KGeography port to KF5 started by David Gil is now complete.
* Started and finished Blinken port to KF5
* Made some patches for some frameworks while porting KGeography

Some of the cool things I've seen:
* kdenlive cleaning up their code to ease maintaince
* GCompris, a nice educational tool for children
* The KF5 Book is shaping up nicely
* Lots of KF5 porting and refining everywhere

Let's keep rolling!

KDE Randa Meetings 2014 Day 1

I wasn't planning on attending KDE Randa Meetings 2014 but last Wednesday I decided to, so bought some not so cheap plane and train tickets (don't worry, I payed from my own pocket) and here I am surrounded by awesome KDE hackers in the middle of the Swiss Alps.

I want to thank the more than 400 people that helped us fund KDE Randa Meetings 2014, you are awesome and directly responsible of improvements that are to come to millions of users in the world.

And remember we still need money to fund more sprints and stuff, so head over to our donations page and help us improve the world!

Help the KDE promo team do their work

We KDE developers have been working on the KDE Applications 4.14 release for the past four months, we've implemented features and important bugfixes. Now the release is near, and we have to write release notes so that our users get the message.

The thing about writing release notes is that you can't write about stuff you don't know, and KDE Applications is biiiiiiiiig so it's impossible for a small group of promo people to know all that happened to it in the last 4 months.

This means *you* developers have to help the promo team write the promo highlighting the most important changes you did to your app and writing them at https://notes.kde.org/p/release_4.14_kde-devel_notes so they can write a more distilled and promo-like text.

Please help them help you.

Logging in into Picasa 3.9 under Linux

A few years ago I showed my father Picasa under Linux, he liked it and started to use it to upload his photos, and has been using it for almost 6 years, even Google discontinued Picasa for Linux at version 3.0 (Picasa is at 3.9 now).

Unfortunately a few weeks ago seems Google decided to kill support for old APIs in the server side and Picasa 3.0 for Linux was giving back an error when trying to upload an image ("Could not find POST url" or similar). I suggested to wait to see if they would come back, but it seems they haven't and so i've had to fix it for him.

Since he's heavily invested in Picasa I've had to install Picasa for windows under wine to make it work. It has not been trivial to get to work so I'll share it here for others that committed the error of trusting privative software and services.

The story is this: Installing picasa 3.9 for windows under wine is pretty easy (next, next, next). The problem is once you are running it, being able to log in. First problem is that the webview using for login doesn't even show. Most of the interwebs suggest installing ie8 using winetricks to solve that and it indeed solves the problem of the webview not showing, but still i can't log in (interestingly the webview will tell you if you wrote the password wrong).

At this point i was stuck for a few hours, even found some dude that claimed he had installed Google Chrome Frame for Internet Explorer and that had fixed for him. But not for me.

After a few hours, I stopped trusting the internet and started to think. I have a windows installation laying around, and i can log in from there, and once logged in Picasa does not ask for the password again, so it must be storing something no?

So I made a copy of the Program Files folder and compared it after loggin in, folders where exactly the same. So it was not stored there, which makes sense since log in is per user not per machine. Next i tried in that weird Personal Folder (Windows $HOME) but could not find any change either. Last chance was the registry, i used http://www.nirsoft.net/utils/reg_file_from_application.html and saw that when logging in, Picasa writes a few entries in HKEY_CURRENT_USER\Software\Google\Picasa\Picasa2\Preferences namely GoogleOAuth, GoogleOAuthEmail, GoogleOAuthServices and GoogleOAuthVersion, so I copied these over to the wine installation (with "wine regedit") and now my father can run Picasa just fine again.

Lessons learned:
* Non Free Software will eventually come back and hit you, if possible don't use it for stuff that is critical to you
* Think about your problem, sometimes is easier than just googling random instructions from the internet.

My way to develop with git in KDE repos

From time to time there is the discussion of which workflow is better to develop with git, etc.

I'm not going to try to convince anyone on which workflow to use, i'm just going to explain what i do and explain why i think it's useful (and even more in the multi-developer KDE environment).

Let's picture the scenario we had a few days ago where there were lots of projects with three "live" branches, i.e. KDE/4.13, KDE/4.14 and master.

What is my way to develop?
* Bugfixes go to oldest "live" stable branch
* Features go to oldest "live" non frozen branch
* Branches are merged up

So let's say that I develop a new feature to support a whole new document format to Okular. Since that is a new feature it would go to the "oldest live non frozen branch", that in this case was master since KDE/4.13 and KDE/4.14 where already feature frozen. So I commit it to master and then "Branches are merged up" which in this case means nothing since there's no branch "up" from master.

Now let's say there's a crash bug when opening a file with three monitors. Since that is a bugfix, it'd go to the "oldest live stable branch", that in this case would be KDE/4.13. And then "Branches are merged up", so i would mean 4.13 into 4.14 and after that 4.14 into master. Ensuring that 4.14 and master also have the bugfix.

I think that this is a very useful way of developing using git branches for a lot of reasons, but the biggest of them is that for a random person it is easy to know if a "branch high in the hiearchy" has all the bugfixes or not, he just have to go to KDE/4.14 and to "git merge origin/KDE/4.13", if no change is brought over, it means that for sure all the bugfixes and code that was in the 4.13 release will be in the 4.14 release, otherwise it is hard to know.

So now that 4.13 is not going to be released anymore and 4.14 is a very young fork of master, i suggest that for every push you do to KDE/4.14 you go to the master branch and merge origin/KDE/4.14. This way you will have a master that is always fully merged with 4.14 and a third party person looking at your code (like the release manager) won't have to worry if it contains all the code or not.

Happy hacking!

And of course if you disagree with me, that's fine, not that i'm happy if my reasons did not convince you :)

KDE/4.14 branch forked

KDE/4.14 branch forked, master is now open. Next applications release will be a kdelibs4 and KF5 mix!

http://mail.kde.org/pipermail/kde-cvs-announce/2014/000147.html