Tuesday, July 29, 2014

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.

Sunday, July 20, 2014

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 :)

Wednesday, July 09, 2014

KDE/4.14 branch forked

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


Tuesday, May 20, 2014

KDE is a nice community, but we can do better!

Since a long time KDE.org has been referring to KDE as a team of people, a community, and not the software products we make.

I agree with this but sadly sometimes we struggle in being a nice community to live in.

There's a few things I think we can improve:
  • Being better 'winners': We are a big community, at some point we have to take community-wide decisions, and it's impossible we will all agree on something. If you are part of the 'winning' group, be gentle with the people that 'lost', sure you think you are right, but they think the same and think the rest is doing a terrible mistake, so when you talk with them be polite and point out that the majority is going in the other direction, but that you still appreciate all the other stuff they do, etc. They already 'lost' so there's no need to put their head under your foot and do an evil laugh.
  • Being better 'losers': We are a big community, at some point we have to take community-wide decisions, and it's impossible we will all agree on something. If you are part of the 'losing' group, be accepting that you 'lost' and try to carry on with the amazing work you do in other areas. Sure you are allowed to some venting, but it should be all within the limits of not trying to drag the discussion forever and not trying to destroy the project just because you disagree in one decision, so yes, you're allowed to some small complaining but understand that the majority decided different than what you think it's better, accept it and carry on, you'll be happier :)
  • Assuming good by default: If a sentence can be read in two ways, do not assume it was said in the worse way, assume it was said in the good. Will help keeping the discussion sane and constructive.
  • Not workarounding by default: If you find a bug or shortcoming in kdelibs, KF5, Qt or any other library, don't workaround it by default, please report it to the library people and try to work with them to fix it. Library code is not that hard and if you fix it in the source, everyone will benefit from the fix, not just the users of your software because you workarounded it and kept quiet about it to upper layers.
  • Not caring enough for the global: We produce zillions of different projects of software. It's almost impossible to have a global overview of "what the bad bugs are", so if you know there is a bug that is bad, and it's affecting quite a bit of people, don't say "someone else will fix it" and ignore it, share it with the wider community and if the current maintainers are missing or overworked I'm pretty sure we can find someone to have a look and fix that bug that is making people sad.

This doesn't happen all the time, but it happens more than I would like, so I'm just raising it up so that people think about it and try to improve :)

Of course I'm not saying I'm not guilty of the things I mentioned, but as the wise-man said: "Don't do what i do, do what i say"

Wednesday, May 14, 2014

Web developer: Help KDE with a few hours of work

At KDE we're trying to get people to donate more (I hope I don't have to explain to this audience why), one of the ideas floating around is adding a small "impulse donate" button to kde.org similar to the one at http://www.videolan.org/ (only with euros and without a "why?" link for now)

I'm not a web devel by far (though have done my fair share of copy&pasting php, html and css for KDE and other personal projects) but I understand it should not be "that hard"™, it would be basically doing some modifications of the kde.org sources, the capacity framework and doing some reuse of the existing paypal donation page code.

Anyone up for the work? If so, please contact me!

Tuesday, May 06, 2014

Commit your approved Review Requests!

By looking at KDE git Review Board I realize we have over 4 pages of "ship it"-ed review requests that are still marked as not commited.

This is nuts!

I know some of them are still work in progress (yes, it sucks that reviewboard does not let you "unship it" when you find something wrong or when some newbie mistakenly gives himself a +1) but I am pretty sure at least 3 of those 4 pages are stuff that was coded, reviewed, approved and then no one committed it :/

So please go through your reviewboard changes and commit them, or ping the maintainer of the app if you don't have commit rights (and if the maintainer is unresponsive for some reason and it's obvious you had his "Ship it" just come to me and I'll commit it for you).

Wednesday, April 16, 2014

KDE Applications 4.13 released

Today we've released 4.13 which is probably the best KDE Applications release ever :)

It also marks the second release we do with a four months schedule instead of a six month one. I think we've ended up with a pretty nice cadence in which we are faster delivering features and bugfixes to users, which at the end is what is important, since the earlier people get the features the earlier they'll find the bugs (let's accept it, all software has bugs) and the earlier the bugs are found the earlier they can be fixed. So basically it's faster progress :)

We have also made good our promise to keep our tests passing, as you can see everything from this release is green (kde-workspace is not green but is not part of the 4.13 release). So kudos to all developers for being awesome in that regard too.

Let's all celebrate on this release but not forget we need to keep working full steam ahead on the releases of KDE Frameworks 5, Plasma 2014.06 and KDE Applications 4.14.

Finally I'd like to remind you that most of the people doing KDE development are volunteers and they invest their time in making this awesome software for you to use for free.

Lots of them even spend time to travel abroad to meet each other in Sprints were they do concentrated hacking for a few days, so if you appreciate the work they do in those Sprints please donate some money so we can actually help them travel and we can make more Sprints happen :-) http://www.kde.org/community/donations/

As anecdote, I had the pleasure of meeting the guys from the KTP Sprint this Friday and after dinner they went back to hacking instead of joining some of us for some beers. That is dedication!