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