Created attachment 105471 [details] [review]
evolution-vcs-import

patch provides a command-line tool to import VCS data. patch can process multiple VEVENT, VTODO and VJOURNAL components within a VCALENDAR component OR a single VEVENT / VTODO / VJOURNAL component

patch can be improved to accept VCS data from files rather than the command-line, but we already have a funky GUI importer to do that ;-)

Hi Suman, are you willing to do it other way? I have few things:

a) Why do you use N_() for localization? I thought _() is better, even I do not
   know why.

b) Please add there the error and print it to user when something fails, and
   also with proper component, not the general message, so one will know which
   component does trouble and why.

c) One should be able to define destination calendar, not everything will
   come to system/default calendar.

d) I saw few complains and requests of command line tool to import multiple
   *files* to Evolution, which is hard with GUI importer because of single file
   selection only. Thus I think it would be better to import not from the
   parameter, but from files, the best with wild cards support.

Anyway good idea to do such tools.

e) I forgot, why do you use 'exit' instead of 'return'? I know here is no 
   difference in this particular case, but... :)

(In reply to comment #2)
> a) Why do you use N_() for localization? I thought _() is better, even I do not
>    know why.

I don't know either ;-).. but I will switch to _() if you prefer that (in my next patch). 

> b) Please add there the error and print it to user when something fails, and
>    also with proper component, not the general message, so one will know which
>    component does trouble and why.

Like you suggested, I'll try to print summary of imported components :-) (Although it might make the tool a little slower)

> c) One should be able to define destination calendar, not everything will
>    come to system/default calendar.

Like I explained on IRC, this is unfortunately not possible with VCS data, as a single VCALENDAR component can have VEVENT, VTODO and VJOURNAL components inside it. So, you can't ask for 'one' uri. If you see my other patch for VCF importing, I have that option. 

> d) I saw few complains and requests of command line tool to import multiple
>    *files* to Evolution, which is hard with GUI importer because of single file
>    selection only. Thus I think it would be better to import not from the
>    parameter, but from files, the best with wild cards support.

I like the idea of importing multiple files. I will try to implement that. 
Although, I have a different view when it comes to wildcard support. I think it should be like { if (filenames) read_from_files else read_from_param }. Reason: This tool was written for use by 'other' applications. And, for most applications, like Firefox, it is easier to send data as a parameter to a local application rather than dump data on stdout (which btw might be flooded with other crap). I hope I've explained my point :-)

(In reply to comment #3)
> e) I forgot, why do you use 'exit' instead of 'return'? I know here is no 
>    difference in this particular case, but... :)

exit instead of return - ".. exit () is used to exit the program as a whole. In other words it returns control to the operating system. After exit () all memory and temporary storage areas are all flushed out and control goes out of program. In contrast, the return () statement is used to return from a function and return control to the calling function. .." 
I think exit() is more appropriate here.. 

I will try to put up the updated patch over the weekend, but I guess it doesn't matter for 2.22 ;-)

N_() marks static constants for translation, but you have to call gettext() explicitly to fetch the translation:

   static gchar *text = N_("Translatable string");

   void foo()
   {
       g_print (gettext (text));
   }

_() does both, but can only be used in a function:

   void foo()
   {
       g_print (_("Translatable string"));
   }

Hope this helps.  :)

You should also add a .desktop file with NoDisplay=true so it can register the mime-types.

It should probably also show the Calendar item, and offer the user to either dismiss the dialogue, or add it to their local calendar. It should also check for duplicates and show them to the user before adding them to the calendar.

Bumping version to a stable release.

bug 225903 dupe ?

(In reply to comment #8)
> bug 225903 dupe ?

either that, or the other candidate is bug #588093 (for this and the older one). Up to you.

Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 588093 ***