Do you have any invitations for picassaweb ?

Hi, it seems it is now closed even for users with google account. I've raised a request at picasaweb help center and pointed them to this URL. Pending any feedback.

Stepahane, I have an account and I'll be looking into it soon.

Larry, nice!

it it possible to send invitations yet ?

about the implementation, what about writing it as a plugin... :)

As Miguel de Icaza posted in his blog:

<quote>
And he [Gonzalo] also just uploaded Google Sharp to subversion (module google-sharp). With GoogleSharp you can authenticate your application with Google and access some of their services. The one that both Gonzalo and myself care about is PicasaWeb. The code has everything for F-Spot to start exporting my pics there. 
</quote>

You can find the code here:
http://svn.myrealbox.com/viewcvs/trunk/google-sharp/


This will make the implementation a _lot_ easier.

Created attachment 69816 [details] [review]
Export to picasaweb

This patch will allow export to picasaweb.

It's feature complete (as in PicasaWeb features), that means that it support multiple google accounts, creation of albums (private or public ones) and upload pictures to them.

It require google-sharp !

Created attachment 69842 [details]
Crash log

(In reply to comment #6)
> Created an attachment (id=69816) [edit]
> Export to picasaweb
> 
> This patch will allow export to picasaweb.
> 
> It's feature complete (as in PicasaWeb features), that means that it support
> multiple google accounts, creation of albums (private or public ones) and
> upload pictures to them.
> 
> It require google-sharp !
> 

This code crash for me ! 
I'm using the HEAD CVS version with your patch.

Steps to reproduce the error:
  1. Open f-spot
  2. Select an image
  3. File->Export->Picassa
  and crashes !!

I attach the output.
Thanks for all !

Lluis, it's not a crash of the patch.
The first lines of the report log indicate that f-spot can't find the Mono.Google assembly.
I solved that in my install by cp  Mono.Google.dll to the same directory as f-spot.exe (in your case: /home/llpamies/applic/f-spot-bin/lib/f-spot/)

Hi Stephane.

I just tried your patch and it works perfectly.

To address the issue that Lluís had, I suggest having a copy of Mono.Google.dll inside f-spot module and install it in ${prefix}/lib/f-spot/, at least until Mono.Google.dll makes its way into the GAC.

The only thing I don't like is storing the username and password in a plain text file. What about using gnome-keyring for that?

Keep up the good work!

Gonzalo (comment #10),

thx for the report.

I store the credentials in a file mainly for 2 reasons:
*) that's how is done in the GalleryExport code (and the GoogleExport code is a modified version of GalleryExport)
*) there's no (AFAIK) gnome-keyring support included in Mono. I can probably do it with gnome-keyring-sharp (http://russell.rucus.net/2005/gnome-keyring-sharp/), but it will add another dependency for compilation...

Hi,

I have just tested this, it works pretty fine except two points:

* it crashes when creating an album in french locale (I think it is Mono.Google the culprit here, it does not handle non-english date format)

* picasaweb does not handle the orientation EXIF tag (at least I think so), images should be really rotated before upload (AFAIR, I have seen a similar bug on the gallery export, but I do not have a gallery to test right now)

nice (and fast) work anyway!

PS: on the above crash: I also had a problem with the assembly not found, but for me it crashed at startup.

* Can I get a stack trace of the crash when using french locale? And also the DateTime string, please.

* When uploading a picture to picasa, there's a parameter that tells the orientation. I have never set it to anything other than 0, but I could test if it is honored, in which case, I can add new overloads for UploadPicture

(In reply to comment #12)

> * picasaweb does not handle the orientation EXIF tag (at least I think so),
> images should be really rotated before upload (AFAIR, I have seen a similar bug
> on the gallery export, but I do not have a gallery to test right now)

I indeed fixed that on GalleryExport and other export schemes. I'll do the same trick on picasa export

Btw, gnome-keyring-sharp just landed in mono svn. It's a fully managed implementation of the library that might be useful as an alternative for password storage instead of the xml files.

Created attachment 70063 [details] [review]
updated version

This version add the rotate capability, as requested in comment #12.

Banshee has also imported a copy of gnome-keyring-sharp into their source tree, I think this should be done here, too.

Hope to see this stuff in HEAD soon =)

I'm ok to store accounts info in gnome-keyring, but do you really thing that it bring a new level of security or it only keep all credentials in one (not-so-safe) place ?

I'm in favor of storing all credentials in one place, definitively, and gnome-keyring is the place to do it.
But don't be too confident in gnome-keyring, and let me give an example: at home, I'm using a wifi connection, and the connection is made bu NetworkManager. So, as soon as my session is opened, my keyring is unlocked. And everyone having physical access to this machine (but I trust my wife;) ) can open gnome-keyring-manager and see all my credentials. Not more secure than having a file read-only for my user ...

Just to remind you that you can't say: my passwords are stored in the keyring, then they're ultimately safe !

Implementing accounts in gnome-keyring is on my todo list for this patch, with having async login to picasa. Both with an equal importance, and I guess that none of them are showstoppers to have this in CVS.

This is off-topic here, but... I'm not saying that storing the passwords in the keyring is the holy grial, but keeping the passwords in a text file is definitely worse (imagine your laptop is stolen).

If gnome-keyring-manager can see all the secrets it is because you authorized gnome-keyring-manager to read them. One can also lock the keyring (or all of them) after retrieving what she wanted.

I just tried this out, love it, and vote to get it into CVS asap.

1) There are 2 outstanding todo's, but by leaving the patch here you accomplish next to nothing, other that letting it get more and more bittrotten. If its in CVS, its far more likely to get the attention needed.

2) This is a major contribution from an outsider, upon inclusion, we make him more a part of the community, if he puts all the work into an awesome and well-done patch like this, then never gets included, we lose his potential to contribute more.

3) Gnome keyring is a nice solution, but as with any open source software, if someone really, really wants your account, anything you do cryptographically can be reverse engineered, or brute forced once they have the file, and for something somewhat trivial (like a picasa username/passwd combo) I think much effort beyond that is silly, we should just warn the user that if they save their password, it may not be secure.

My $0.02, but I just think we should get this out their asap.

re 3): the problem is that the username/password for picasaweb is the same as for Google Checkout... So we're talking about money here :-). If my laptop is stolen I have time to change the passwords. I'll add support for the keyring after this patch is in.

Kevin (comment #20):
 1) I agree with you, CVS is the place to fine-tune and make final reviews...
 2) :-) thanks for the 'major contribution'. I already have some of my patches in f-spot, and this one is the one that will stop me.

Gonzalo (comment #21): I'm already writing support for the keyring...

Created attachment 70528 [details] [review]
with credentials sotred in gnome-keyring

Find attached my updated version.
As requested, the credentials are stored in gnome-keyring.

Created attachment 70529 [details] [review]
with credentials sotred in gnome-keyring

Find attached my updated version.
As requested, the credentials are stored in gnome-keyring.

require both google-sharp and gnome-keyring-sharp

Awesome. Thanks a lot Stephane.

It would be nice if the password was stored as a network password having, for example, a "object" property as "Google Accounts" so that one can have more than one user/password stored.

Also, once the patch makes it way to CVS, feel free to import Gnome.Keyring to f-spot (it's small and is not going to be changing a lot, as it is now feature complete). The same goes for Mono.Google.

I did'nt implemented it as NetworkPassword, but you can already have multiple user/password pairs stored... try it, it works.

But if you say that it's better to implement it in an other way, I'll do it ;)

Is Mono.Google also feature complete ? (caption for images ?)

Oh! Nice. I didn't realize that. That fine by me.
I'll add support for picture captions later today. Feel free to ask for anything that's missing from mono-google (email).

How do I get the missing dll (google-sharp and gnome-keyring-sharp) into my dapper system. Would prefere not to compile it...
Also, for us to ship this patch, I would assume we need to ship the dll's as well, at least until they are included in mono...

In reply to comment #29:

We'll probably import the google-sharp and gnome-keyring-sharp code into the f-spot cvs tree until the modules are released as part of mono/gtk-sharp.

I've been changing working on this, so expect some news soon.

Managed to get it working...

First impressions... Cool :)

First check. Used the wrong account name (forgot the @google.com) and got the following in the console

System.Net.WebException: Error getting response stream (ReadDone2): ReceiveFailure ---> System.Exception:
   at System.Net.WebConnection.HandleError ()
   at System.Net.WebConnection.ReadDone ()
   at System.MulticastDelegate.invoke_void_IAsyncResult ()
in <0x000ad> System.Net.WebConnection:HandleError (WebExceptionStatus st, System.Exception e, System.String where)--- End of inner exception stack trace ---

in <0x00158> System.Net.HttpWebRequest:EndGetResponse (IAsyncResult asyncResult)
in <0x00047> System.Net.HttpWebRequest:GetResponse ()
in <0x003f9> Mono.Google.Authentication:GetCookieContainer (System.String user, System.String password)
in <0x00054> Mono.Google.Authentication:GetAuthCookies (System.String user, System.String password, GoogleService service)
in <0x0002f> Mono.Google.GoogleConnection:Authenticate (System.String user, System.String password)
in <0x00064> FSpot.GoogleAccount:Connect ()
in <0x000c9> FSpot.GoogleExport:Connect (FSpot.GoogleAccount selected)


I then fixed my userid and managed to connect, and started to upload a photo. Nothing seemed to happend. Just hanging there... Apparently, it was a large file (original size) 3 MB. Would be nice with an indication that something is happening.

Console states "Started Upload" Upload to what? If this text should be there, perhaps change to "Started Upload to Picasaweb"

I also ticked the "Open album in browser when done uploading" but nothing happend in my firefox session. (Apparently commented out in the code!)

No tooltips in the gui

LoadPreference has no default switch statement.

In all, the code do look very nice and clean, easy to follow. Very good job.

Nitpickying...
Perhaps rename the main .cs file to PicasaWebExport.cs ?

The first issue is a Mono.Google crash. I'll try to see if I need to catch that exception or...

The 2nd one, about big files. I did'nt manage to find out the max file size for PicasaWeb.

Console output is for debug only. but I can fix it.

Open album in browser is not connected yet. I'm still wondering if I remove that or connect it to open your public album. (I vote for the second one).

Nope, No tooltips. Do you want tooltips everywhere ?

about LoadPreference, do I really need this:
default:
     //this will never happens
     break;

I'll try to fix some of those asap.

Tooltips would be good to have in F-Spot to a much greater extent, at least I think so.

The code as it is now will not break, but imagine you add a new preference, or spell it wrong... the code will crash, but no compilation fault though.

Big files, or many files. Perhaps have a better indicationm that something is happening? Running total of how many bytes been transfered?

Could we reuse the Resize Email patch's function with Tiny, Small, Medium, Large, XLarge, Original and its associated original size and estimated size? Would help a bit I think.

Created attachment 71203 [details]
Tar containing google-sharp & gnome-keyring-sharp

This tar contains both google-sharp & gnome-keyring-sharp and includes them in the f-spot autotools chain.  To test this out you should extract the tar in your f-spot checkout folder, apply the extracted patch and perform a "./autogen.sh && make"

Nothing has happened to the patch itself, a review is for later ;-)

Thanks,
Thomas

Created attachment 71349 [details] [review]
the same in an unified patch

This version do not contains anything new, but is now a patch (vs a tar).

Also cleaned the build garbage packaged with the previous patch.

Created attachment 71352 [details] [review]
updated version (again)

At least, this version introduce some new things:

something new:
- open in browser checkbox works

minor fixes:
- GoogleExport.cs renamed to PicasaWebExport.cs
- Stacktrace on bad credentials replaced bu a more explicit log message
- replaced the log message 'Starting uplad' by 'Starting Upload to Picasa'
- added a Changelog

and as a remember, this patch contains everything you need to build Mono.Google and gnome-keyring-shaap (thx Thomas).

Bengt (comment #34), 
- I did not add tooltips (yet)
- about the default in LoadPreference: still did'nt add a default. even a typo in a call to LoadPreference will not break anything (the LoadPreference method does not return anything)
- about the indication: when you start an upload, a progress bar is displayed saying 'uploading picture blah' before the upload starts. Do you need something more ?
- about the size: users will prefer setting the size precisely. (not as in send mail patch, where only the file size matters)

A small review...
File menu : Export -> Picasa
	Should be Export -> Picasaweb (or something like this)
	
The export window should still present file size I think, although 250 MB is a lot... 
Would it be possible to indicate how much space is left before upload is started?

Perhaps have default resize to a sane size?

Is it to much information to show connecting, loggin on etc in the uploading Pictures window?

Auto Rotate seems not to work. Always rotating.	Since I am also resizing to 400pix
	Perhaps make it disabled if picture is resized?
	
Very few comments in the code...	

Uploading Pictures status window.
Perhaps you can indicate
- To wich album
- Total file size  (still think this might be good, since a lot of web sites have a limited space)

Sorry for a rushed review... not to much time here...

Created attachment 71401 [details] [review]
last one for today

Again, an updated version.

- display quota usage in an human readable way
- set default values for rotate, scale and size
- set the rotate_check to unsensitive when resize is checked
- file menu entry: change from 'Export to Picasa' to 'Export to Picasaweb'

About Bengt's comment (comment #39)
- at the time the upload starts, connect and log on are already done !
- IMHO, showing the album name in the upload dialog will not add any value. At that time, it's to late to change :( (and you can still see it in the export dialog)
- yeah, it could be nice to have an idea of the total exported size for all the export schemes. But I don't think I'll implement it before this patch reach CVS HEAD.

Stephane, I really like your patch. It is very clean, and it is very difficult to find something to complain on :)

Anyway, here goes.

Ok, here comes another small, quick and dirty review.

+		public const string EXPORT_GOOGLE_SCALE = "/apps/f-spot/export/google/scale";
+		public const string EXPORT_GOOGLE_SIZE = "/apps/f-spot/export/google/size";
+		public const string EXPORT_GOOGLE_ROTATE = "/apps/f-spot/export/google/rotate";
+		public const string EXPORT_GOOGLE_BROWSER = "/apps/f-spot/export/google/browser";

Would suggest these preference variables are called EXPORT_PICASAWEB_xxxx and stored in /apps/f-spot/export/picasaweb/xxxx

Perhaps modify the if (scale).... else if (rotate)..... else upload... code to
   if(scale) upload_photo (false) else if (rotate) upload_photo (true) else upload...
That is, refactor it to not have duplicated code.

Just after you select File->Export->Picasaweb, f-spot seems to freeze for 10 seconds or so.
No indication is given to user what is happening.

The quota usage indication is very nice, but in my screen I get the following:
"<small>Quota usage :12.2 MB / 250 MB</small>"
Perhaps it is only me, but I would like to have a " " (space) after the ":"
Also, (nitpicking) perhaps Quota : 12.2 MB used, 237.8 MB unused?

Created attachment 71458 [details] [review]
updated version

the latest version so far...

- changed references to google with picasaweb in the preferences
- fix the issue with Quota display, improved quota display
- quota not displayed when not connected

Bengt (comment #41):
- for the 10sec delay, I'll apply bmon's patch to make gallery async to picasa, but not before he's really happy with it. Until then, no workaround, not even a small dialog.

Nice patch, seems to work flawlessly and the code looks very clean.

I have two comments:
* i would be nice if both the gallery export and google export used the same glade dialog, with the specific implementations being tucked away in two classes implementing an interface (to create the connection, get available albums, upload photos,...) .  But i can't really tell how easy this would be.

* there seems an issue with the way you calculate the used space percentage.  You divide the used quota by the maximum quota; but i guess you have to multiply that by 100 to achieve a percentage.

About the first comment: I actually have plan for unifying a lot of code for all the export dialog, but I keep those for the refactoring that will happens with the export plugin.

And about the second, I did'nt really test it, I'm currently really using 0% of my quota ;) I fix that today.

Created attachment 71577 [details] [review]
The one where percentage means something

fixed the issue raised by Thomas

Created attachment 71602 [details] [review]
The one with the progressbar

As Gonzalo updated the Mono.Google lib this morning, I updated the export to picasa code to use his latest new things.

What's new:
- updated the google-sharp included in f-spot
- fixing removing a blank space in the dialog
- showing the progress during import. Screenshot here: http://picasaweb.google.com/sdelcroix/FSpot/photo#4967218685328162834
- sending comment with photo (not tested yet)

The progressbar needs a bit more work to be consistant (the progressbar should reflect the progresstext).


Please discuss...

check the new screenshot with the solution I'll publish soon: http://picasaweb.google.com/sdelcroix/FSpot/photo#4967294199557783570

Why hasn't this been put into the main tree?

It's on its way :) Its one of the Goals for next meeting. (http://f-spot.org/Meetings)

Thanks. :)

Created attachment 71837 [details] [review]
The one where the size is approx.

This new one fix the progress dialog and update the Mono.Google code to the latest version available.

When exporting full size images, the dialog looks like this: http://picasaweb.google.com/sdelcroix/FSpot/photo#4968684609954054162

And when exporting resized images, the dialog looks more like that: http://picasaweb.google.com/sdelcroix/FSpot/photo#4968692526880391186

enjoy